×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Moonlite focuser doesn't move with 3.4.3 KStars MacOS

  • Posts: 216
  • Thank you received: 120
I've been testing my Arduino Moonlite focuser, and found that on a Mac the Arduino doesn't always receive the SN command. I setup a second serial connection to the arduino that just echoes everything it receives from the indi_moonlite driver, and monitored it with screen. I see the FG command, but not always the SN that precedes it. The SN command does show up in the indi debug logs though, so I don't think it is the driver itself having an issue, but maybe the tty code itself. Everything works great on Linux though. About 1 in 20 times the SN command will be there and the focuser moves like it should. Again, works great in Linux, but very inconsistent on Mac.
Last edit: 3 years 9 months ago by Rick Bassham.
3 years 9 months ago #54804

Please Log in or Create an account to join the conversation.

  • Posts: 194
  • Thank you received: 20
I soldered a wire directly to the Rx pin and recorded with a serial port what was on the Mac output. Not only are the SN's missing, all but the first ":C#" are missing as well. I'm not sure that is a problem, though. I don't need it, but the real hardware may.

2.9.8 for Mac:
:GP#:C#:GT#:GP#:C#:GT#:GP#:C#:GT#:GP#:C#:GT#:GP#:C#:GT#:SN1D4C#:FG#:GP#:C#:GT#:GI#:GP#:C#:GT#:GI#:GP#:C#:GT#:GI#:GP#:C#:GT#:GP#:C#:GT#

3.4.3 for Mac:
:GV#:GP#:C#:GT#:GD#:GH#:GP#:GT#:GP#:GT#:GP#:GT#:GP#:GT#:GP#:GT#:GP#:GT#:GP#:GT#:FG#:GP#:GT#:GI#:GP#:GT#:GP#:GT#:GP#:GT#:GP#:GT#:FG#:GP#:GT#:GI#
Thanks,
Dave
Last edit: 3 years 9 months ago by David Allmon.
3 years 9 months ago #54832

Please Log in or Create an account to join the conversation.

  • Posts: 216
  • Thank you received: 120
Think the issue is the back-to-back sending of the data with no delay? I'd be curious if it is a timing issue, since both cases are sending two separate commands back to back with no delay in between, and the first one isn't sent. I wonder if a buffer somewhere isn't flushed out to the serial port before it is overwritten by the next command.
3 years 9 months ago #54833

Please Log in or Create an account to join the conversation.

  • Posts: 216
  • Thank you received: 120
Adding a tcdrain call after write inside tty_write in indicom.c might do the trick.
3 years 9 months ago #54837

Please Log in or Create an account to join the conversation.

  • Posts: 194
  • Thank you received: 20
I've looked through the code and I don't see anything that would pick an SN message and not send it. I have no fragmented messages, or signs of any communication problems. I would rebuild it if I could. Not having much luck, but that's a story for another day.
3 years 9 months ago #54838

Please Log in or Create an account to join the conversation.

  • Posts: 216
  • Thank you received: 120
Yeah, I'm trying to test now, but looking at Moonlite::sendCommand, it calls tcflush(PortFD, TCIOFLUSH) immediately before calling tty_write_string. tcflush is going to discard all unsent and unread data in the serial port at that moment, and since we are immediately calling tty_write back to back, I don't think the underlying serial port has actually sent the data yet. I think we need to add tcdrain in indicom.c. I'll give it a test as soon as I get it to compile on my Mac.
3 years 9 months ago #54850

Please Log in or Create an account to join the conversation.

  • Posts: 194
  • Thank you received: 20
I just commented out the tcflush(PortFD, ...) to test it and it solved the problem. I don't know if that is the solution, but it is the problem.

Thanks,
Dave
3 years 9 months ago #54857

Please Log in or Create an account to join the conversation.

So Mac flushes :SN because :FG is called soon after it? What if you replace TCIOFLUSH with TCIFLUSH ?
3 years 9 months ago #54859

Please Log in or Create an account to join the conversation.

  • Posts: 216
  • Thank you received: 120
That will probably also work. I'm willing to bet there's just a minor difference in the serial implementation in the linux kernel vs the xnu kernel.
3 years 9 months ago #54861

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
Calling tcflush just before writing data is just about standard in all drivers. However in the majority of cases sending a command is followed by reading a response.
But some moonlite commands don't return a response and in this case the driver doesn't do the read so the next tty command is the flush at the start of the next command.

At present the moonlite sendCommand has:

if (res == nullptr)
return true;

Perhaps this should be:
if (res == nullptr)
{
tcdrain(PortFD);
return true;
}

It's surprising this hasn't been more of a problem, the send takes milliseconds while the processor is working in microseconds.
3 years 9 months ago #54863

Please Log in or Create an account to join the conversation.

  • Posts: 216
  • Thank you received: 120
Yeah, a lot of serial code I've used in the past just always put a tcdrain after a write. With the amount of data any of our drivers send, the delay caused by adding tcdrain should be very short, single digit milliseconds in most cases. Adding it to the tty_write function in indicom.c may prevent these kinds of issues from cropping up in all other serial drivers as well.
3 years 9 months ago #54865

Please Log in or Create an account to join the conversation.

  • Posts: 194
  • Thank you received: 20
tcflush(PortFD, TCIFLUSH);

also works.
3 years 9 months ago #54870

Please Log in or Create an account to join the conversation.

Time to create page: 1.693 seconds