Wolfgang,

Thanks again for questioning my protocol implementation. It turns out that it indeed wasn't correct. I sent replies ending in "#" where I shouldn't have and that messed up INDI. Now I have implemented it correctly and INDI is behaving as expected.

Clear, transparent, moonless skies, Wouter

Read More...

With KStars 3.6.7 I see 2 more duplicate GR commands before I try a GOTO. And I checked with SkySafari and AstroPlanner. With SkySafari I don't see any duplicate commands but with AstroPlanner I see two duplicate GR commands as well. Not sure anymore if this is related with my setup or not. In any case, it is working now with all three software so I am happy.

Thanks again, Wolfgang, for the quick follow ups!

Read More...

Thanks. That indeed doesn't show the duplicate command. A few more questions for you so I can investigate further.

What OS are you on? Which version of KStars? How is your mount connected to INDI? Via a serial cable or via TCP/IP?

I am on macOS with the latest version of KStars (I'll check the actual version when I am with my MacBook) and connect via TCP/IP.

Read More...

Hi Wolfgang,

Thanks for looking into this again. What happens after the MS command? That part is missing from the log you posted and that is where I receive two consecutive GR commands.


Wouter

Read More...

Yes, I am happy that it is working for me now. I hope someone will take some time to dig into these duplicate GR commands. My python code for the LX200 protocol worked without the need to filter that out about two years ago and now not anymore. Seems like some regression in INDI to me.

Read More...

I enabled command logging in my code and found that indeed a duplicate GR command is sent by INDI. I added some code to ignore duplicate commands and now it works in KStars and Cartes du Ciel. I think there may be some timing issue or some other problem in INDI causing a duplicate GR command to be sent. No idea why it works with the Avalon Mount though!

I will keep ignoring duplicate commands in my code so it works well with INDI.

Thanks for helping me get to the bottom of this, Wolfgang!


Wouter

Read More...

OK, here we go. When INDI sends a slew command, it sends the following commands:

2023-10-22 19:55:47,034:DEBUG:LX200Mount:Read command line: 'Sr14:16:44#'
2023-10-22 19:55:47,034:DEBUG:Lx200CommandResponder:Setting RA to 14:16:44
2023-10-22 19:55:47,034:DEBUG:LX200Mount:Read command line: 'Sd+19*03:56#'
2023-10-22 19:55:47,034:DEBUG:Lx200CommandResponder:Setting DEC to +19*03:56
2023-10-22 19:55:47,034:DEBUG:LX200Mount:Read command line: 'MS#'
2023-10-22 19:55:47,035:DEBUG:Lx200CommandResponder:Slewing to RaDec (14:16:44, +19*03:56).

So it first sends an Sr command with the RA and then an Sd command with the DEC. Finally it sends an MS command that initiates the slew. Before that, my code sends the following RA and DEC strings, to indicate that the telescope is at AZ 0.0 and ALT 0.0:

2023-10-22 19:55:45,945:DEBUG:Lx200CommandResponder:ra_str='07:43:51.18'
2023-10-22 19:55:45,953:DEBUG:Lx200CommandResponder:dec_str="49*16'37.50"

The telescope is correctly displayed on the northern horizon. As soon as the MS command is received, the telescope code starts slewing to the position of, in this case, Arcturus and sends these strings:

2023-10-22 19:55:47,982:DEBUG:Lx200CommandResponder:ra_str='07:56:56.31'
2023-10-22 19:55:48,986:DEBUG:Lx200CommandResponder:ra_str='08:51:5.20'
2023-10-22 19:55:48,993:DEBUG:Lx200CommandResponder:dec_str="57*26'6.05"
2023-10-22 19:55:49,997:DEBUG:Lx200CommandResponder:ra_str='10:22:29.87'
2023-10-22 19:55:50,006:DEBUG:Lx200CommandResponder:dec_str="60*35'29.43"

And there I see the cause of the issue. Apparently the ra_str reply is sent twice. My guess is that this is a timing issue with two consecutive commands being received to request the telescope RA but I'll dig into my code to make sure that it is not an issue on my side.


Wouter

Read More...


Like I wrote, the code works fine with SkySafari and AstroPlanner but of course that doesn't rule out that there is an issue with my code. Perhaps the format of the RA and DEC strings that are sent by my code is incorrect. Would it be possible for you to capture those strings from your mount and post them here so I can compare with my code? I'll send examples of output from my code as soon as I get access to my MacBook.


Thanks, Wouter

Read More...

Hi Wolfgang,

Thanks for the super fast follow up. What I do is this:

- Go to the device manager in KStars (under Tools) and connect to LX200 Basic via TCP/IP.
- At that moment the RA and DEC are correct.
- Slew to an object.
- From that moment on RA and DEC are swapped. This can be seen in the device control panel. If you enter a RA/DEC combination and click the Set button, you can see in the same screen that they get set correctly and then get swapped after a few seconds.


HTH, Wouter

Read More...

Hi!

It has been a while since I read this forum so it is very well possible that this already has been reported. I did a quick search on the forum but didn't find anything which is why I decided to open a topic.

I am working on a custom motor system for my dobsonian telescopes and I use the LX200 protocol. I have it working with SkySafari and AstroPlanner (only simulator so far, no hardware yet) and started looking into getting it to work with INDI. This is how I discovered the small bug in the LX200 Basic INDI driver. The bug is that, when retrieving the telescope coordinates, RA and DEC are swapped. And only when retrieving, not when setting or when sending a slew command.

This leads to very funny but slightly annoying display issues, where the telescope seems to be pointing at a very different position than it really is. The interesting thing is that this only starts going wrong after an initial slew command is given. When INDI connects to the telescope, it first displays the telescope in the correct position. As soon as I give a slew command though, RA and DEC are swapped and the display of the telescope position is completely wrong.

This is visiible in KStars and Cartes du Ciel/SkyChart on macOS. I didn't test KStars on Linux since I currently don't have a Raspberry Pi with KStars installed.

Apart from this display issue everything seems to work well with this driver. No big issue but I thought you'd like to know.


Clear, dark and transparent skies, Wouter

Read More...