3.1.0.405 not working with Alnitak Flat Box

I have a Alnitak compatible Flat box and had no issues connecting with prev 3.0 branch of SGP. Now with 3.1, I get the following error in the log file:

[12/15/19 16:10:35.741][DEBUG] [Main Thread] Connecting to Alnitak Flat Box
[12/15/19 16:10:37.107][DEBUG] [Main Thread] Invalid return from serial. Val is (*)
[12/15/19 16:10:38.108][DEBUG] [Main Thread] Alnitak Flat Box - Disconnecting
[12/15/19 16:10:38.108][DEBUG] [Main Thread] Alnitak Flat Box - Could not get status.

If I connect to Flat Box via a serial client app and issue a >S000/n command I get:

*S19010

Which is correct as I understand it. More importantly - nothing has changed with my flat box and I am able to work with it fine via the serial command app.

I’m guessing your lightbox might be based on a Leonardo or Micro? We made some changes to the Alnitak Implementation a while back for better handling of the actual Alnitak Devices that set the RTS and DTR value differently. The Leonardo is rather obnoxious about how it starts the serial connection and wants these values set differently. If you can use an Uno that would likely work best. We may add some options in the future to specify how these are set but our main goal with the Alnitak Implementation is to support the actual FlipFlat devices.

Thank you,
Jared

Jared,

I use a bluetooth connection to the flat box.

I discovered that I connect to the flat box first manually, then remainder of the equipment, then SGP is able to connect.

If I connect to another other piece of equiement first then it will not connect to flat box - even if I disconnect all equipment then retry.

In this state I had to load another sequence come back and reload my cal sequence and then manually connect to the flat box fist before anything else and it works.

Seems like a bug in SGP to me.

Equipment used in seq:

  • ZWO 183mm via ZWO Camera driver
  • ZWO filter wheel
  • Custom BT based focuser
  • Custom BT rotater
  • Custom BT flatbox

What I see in the log when connecting to flat box first:

[12/15/19 16:41:27.680][DEBUG] [Main Thread] ************** END SEQUENCE DUMP **************
[12/15/19 16:41:33.817][DEBUG] [Main Thread] Connecting to Alnitak Flat Box
[12/15/19 16:41:36.397][DEBUG] [Main Thread] Alnitak Flat Box - Updating Device Variables - Model: 19 Motor Status: 0 Light Status: 0
[12/15/19 16:41:36.397][DEBUG] [Main Thread] Alnitak Flat Box - Successfully connected
[12/15/19 16:42:49.827][DEBUG] [Main Thread] PopulateDataModel: Transferring view to the data model…

I’ll test it out against my Alnitak FlipFlat this evening.

Thank you,
Jared

Jared,

I think it’s likely a timing issue. Noting that you’ve increased your threading of SGP. Bluetooth communications are much slower than regular hardware serial comms - on the order of 50ms to 2 ms or so for the same given command. If there’s some inherent expectation of response within a period of time, then that could be the source of the issue.

Again, worked fine with lastest non-3.1 build of SGP.

I tested the FlipFlat and all seems normal. About 15 seconds for the initial connection, subsequent connections are considerably faster but no timeouts with either. The FlipFlat has always had this initial delay and I’m not sure why.

The main thing we changed between 3.1 and 3.0 for the Alnitak device is that we’re disabling DTR. This is likely not completely needed but it was done to try and fix some slow connectivity to the Alnitak Devices. That change could have very likely been in 3.0 as well though as the change set is from 2017.

We’ve actually slowed down the polling by a considerable amount and all of the Send/Response transactions are Atomic.

Not really sure what else to try unless it’s something with the DTR being disabled. I was also checking this out earlier today with an Arduino Uno and that worked fine as well.

Thanks,
Jared

Thanks for looking into it.

Don’t see how DTR would affect it only in a limited context. I also use the SoftwareSerial library for BT comms - so I would think any hardware issue would not be relevant.

But you’re right, it is a leonardo micro. I have another problem with it where it PWM output isn’t consistent for a given value so it’s likely on it’s way out anyhow.

I have a work-around for now and don’t do sequence integrated flat generation.

I built a compatible model as well, it uses a UNO (explicitly this one https://www.jaycar.com.au/duinotech-uno-r3-development-board/p/XC4410 )

I get the similar messages in my log:

[02/27/20 18:09:47.193][DEBUG][Main Thread][NONE] Alnitak Flat Box - In Get Props Dialog
[02/27/20 18:09:53.544][DEBUG][Main Thread][NONE] Connecting to Alnitak Flat Box
[02/27/20 18:09:53.679][DEBUG][Main Thread][NONE] Alnitak Flat Box - Caught exception in Connect: The I/O operation has been aborted because of either a thread exit or an application request.

[02/27/20 18:11:21.062][DEBUG][Main Thread][NONE] Alnitak Flat Box - In Get Props Dialog
[02/27/20 18:11:26.541][DEBUG][Main Thread][NONE] Connecting to Alnitak Flat Box
[02/27/20 18:11:30.084][DEBUG][Main Thread][NONE] Alnitak Flat Box - In Get Props Dialog
[02/27/20 18:11:35.478][DEBUG][Main Thread][NONE] Connecting to Alnitak Flat Box
[02/27/20 18:11:36.512][DEBUG][Main Thread][NONE] Invalid return from serial.  Val is (*S1)
[02/27/20 18:11:37.514][DEBUG][Main Thread][NONE] Alnitak Flat Box - Disconnecting
[02/27/20 18:11:37.520][DEBUG][Main Thread][NONE] Alnitak Flat Box - Could not get status.

I’m really hoping to get this working - is there any way to be able to diagnose this deeper? I have no problem using the Arduino IDE serial monitor to talk to the device. Perhaps there could be an “Alnitak Compatible” option which allows certain parameters to be tweaked??

Thanks.
Rob

This seems like the response from the device is fine, but invalid for the Alnitak protocol. Where did you get the arduino code from?

Thanks,
Jared

Hi Jared,

Thanks for responding.
The code was your original code, with an update to the V4 protocol by Igor von Nyssen, and a small update from me to use a slightly different PWN pin assignment. My repo is here:

Thanks again.
Rob

We’ve had a few reports of the “V4 protocol” branch not working. It appears to be a problem with the byte alignment getting off. I would revert back to my original branch unless you need the stepper control or look into addressing the byte alignment on the V4 protocol branch.

Thanks,
Jared