David Allmon replied to the topic 'How do I get the focus position in the FITS header' in the forum. 3 days ago

Thank you both! I'll give that a try.

Read More...

David Allmon created a new topic ' How do I get the focus position in the FITS header' in the forum. 5 days ago

Hi,

I see the focus position in the FITS header in the FITS Viewer, but it is zero. I have a Moonlite clone and it shows the position as 5500. Is there a way to get that position into the header?

Thanks!

Read More...

David Allmon replied to the topic 'Can't change mount driver' in the forum. 7 days ago

Maybe a silly question, but do you have LX200 set as the telescope on the remote server? I have similar results, only with the ccd, when I have the ccd simulator on the server and try to run SBIG on the client.

Dave

Read More...

David Allmon replied to the topic 'Re:Running out RPi of USB ports' in the forum. 1 week ago

Mohamed,

With nothing plugged into the hub you should see the hub using the lsusb command.

Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The Genesys Logic lines are my hub. Yours are likely different. If you see that, the cable is good and the hub is talking. If not, you have a USB port, cable or hub problem. When you plug one device cable in and run lsusb you should see that one device added to the lsusb list. If not, you may have a power supply problem. If you do see the one device, then the hub is functional, and you probably have a power supply problem. If you no longer see the hub, you also may have a power supply problem. I didn't think it was important before, but I have a 4A 5V supply for the Pi, which could explain why I can run six devices off of the Pi.

Dave

Read More...

David Allmon replied to the topic 'Running out RPi of USB ports' in the forum. 1 week ago

mhammady,

I would check the USB cable you have between the Pi and the hub.

I'm using 5 USB-2 peripherals - 4 on an unpowered hub and one on the RPi directly, and one USB-3 for a. little SSD, and have also run a USB-3 hub, but with USB-2 peripherals. It all works, and I don't recall doing anything special. I had a bad cable at one point.

Dave

Read More...

David Allmon replied to the topic 'I think there is a logic problem in the flip_flat driver' in the forum. 2 weeks ago

When Ekos is controlling it, it does it correctly, turning the light off before opening the flap. You have to do it manually to get it in the odd state. I suppose if I were to do it manually I could be expected to do the same as Ekos.

Read More...

David Allmon created a new topic ' I think there is a logic problem in the flip_flat driver' in the forum. 3 weeks ago

Hi,

Sorry if this is not the correct area. I couldn't find a flip-flat area.

When I open the flip_flat, then try to turn the light on, it says I can't. I'm good with that.
When I turn on the light, open the flip_flat, then try to turn the light off, it says I can't. I'm not so good with that. I have to close the flapper then turn the light off, then open the flapper again.

It seems to me one should either be able to turn off the light with the flapper open, or not be able to open the flapper with the light on. My preference would be the first option. I know this is a little nit-picky, and it really doesn't prevent it from working, but it seems like it needs fixing.

Disclaimer: I don't have a Flip Flat, I just use the commands to control an EL panel, so it _really_ doesn't affect me.

Read More...

xthestreams,

I just made those changes to your published code and it works with the FlatMan driver on my Raspberry Pi.

[2020-07-23T20:20:32.519 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] Connecting to /dev/ttyACM0 @ 9600 "
[2020-07-23T20:20:32.521 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] Port FD 3 "
[2020-07-23T20:20:32.522 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] Connection successful, attempting handshake... "
[2020-07-23T20:20:32.523 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] CMD <>P000> "
[2020-07-23T20:20:32.541 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] RES <*P19000> "
[2020-07-23T20:20:32.544 MST INFO ][           org.kde.kstars.indi] - Flip Man :  "[INFO] Flip Man is online. "
[2020-07-23T20:20:32.545 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] Configuration successfully saved for DEVICE_PORT. "
[2020-07-23T20:20:32.561 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] Configuration successfully saved for DEVICE_BAUD_RATE. "
[2020-07-23T20:20:32.561 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] Configuration successfully saved for CONNECTION_MODE. "
[2020-07-23T20:20:32.562 MST INFO ][           org.kde.kstars.ekos] - "Flip Man" Version: "1.0" Interface: 33792 is connected.
[2020-07-23T20:20:32.563 MST DEBG ][           org.kde.kstars.ekos] - 3  devices connected out of  5
[2020-07-23T20:20:32.637 MST DEBG ][           org.kde.kstars.indi] - < Flip Man >: < FLAT_LIGHT_CONTROL >
[2020-07-23T20:20:32.646 MST DEBG ][           org.kde.kstars.indi] - < Flip Man >: < FLAT_LIGHT_INTENSITY >
[2020-07-23T20:20:32.651 MST DEBG ][           org.kde.kstars.indi] - < Flip Man >: < Status >
[2020-07-23T20:20:32.661 MST DEBG ][           org.kde.kstars.indi] - < Flip Man >: < Firmware >
[2020-07-23T20:20:32.665 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] CMD <>V000> "
[2020-07-23T20:20:32.665 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] RES <*V19001> "
[2020-07-23T20:20:32.666 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] CMD <>S000> "
[2020-07-23T20:20:32.668 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] RES <*S19010> "
[2020-07-23T20:20:32.668 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] CMD <>J000> "
[2020-07-23T20:20:32.669 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] RES <*J19000> "
[2020-07-23T20:20:33.556 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] CMD <>S000> "
[2020-07-23T20:20:33.572 MST DEBG ][           org.kde.kstars.indi] - Flip Man : "[DEBUG] RES <*S19010> "


Read More...

Sorry for spamming. To be more clear, changge this code:

		  sprintf(temp, "*P%d000", deviceId);
		  Serial.println(temp);

to this:
		  sprintf(temp, "*P%d000\n", deviceId);
		  Serial.print(temp);

And do that for each message you send back to the driver.

Read More...

Your code - not the driver. You just need to change your Serial.println() to Serial.print(), then put a newline in each message. You can do it in the sprintf, like this:

sprintf(temp, "*P%d000\n", deviceId);

Serial.print() just sends what is in the buffer, without adding a CR to it.

Read More...

You're sending CR and LF at the end of each message. Per Arduino Serial.println() docs:

Prints data to the serial port as human-readable ASCII text followed by a carriage return character (ASCII 13, or '\r') and a newline character (ASCII 10, or '\n').


That is why it is horking on your response. You need to stuff a newline at the end of your message and then call Serial.print()

Read More...

I changed the sketch to read one character at a time, and key off of 0x0a or 0x0d.

Read More...

I made one the other day, similar to yours, but instead of printf of decimal numbers I just used strings. Works fine, however I used FlipFlat as the id, and I did have trouble with the driver. It seems sometimes it sends newline and sometimes it sends return. I had to code for both.

Dave

Read More...