So I bought the recommended version of the Arduino and got it all wired up but get the same error message “Failed to get status” from SGP. Using the Arduino Serial Monitor I can send commands to the panel and it reacts properly - I can turn the light on and off and adjust brightness. I am a bit confused as to why it appears to react properly to commands sent manually via the Serial Monitor but SGP still fails to connect properly.
Can you upload a zip of the Arduino code someplace and I can take a look. It may be that the response looks correct but is missing something like an End of Line character or something is malformed.
Bingo! That works! If you don’t mind me asking, what were the changes? My knowledge is fairly basic, but from what I can tell you added in some code that appears to deal with the serial communications and changed a \r to a \n in the serialreadbytes commands. I am presuming that it was not waiting long enough to get a response or something like that and timing out too quickly.
Glad that this script works for you. Actually I am not a coding guy as well. But I learn hard to understand this lightbox coding and do a lot of research by looking at forums.
You are a better forum navigator that I, clearly! Also, I like the handle! I have shared it with a friend of mine who is a coder so perhaps he can provide some clarification. Once I get that I will report back.
I wonder if something is broken in that branch. Looks like the change was made to the “serial available” check but that seems like more of a red herring. If you don’t need the stepper motor support you may want to try the original which I created and can be found here:
Thanks Jared - keeping track of the branches and forks of these things can be a challenge for me. I downloaded that version and it works perfectly. If I leave the brightness at 255 when I disconnect the panel stays on - I will just have to remember to set that to zero at the end of a flats session.
I appreciate all of your and Tomastro’s help on this!
That’s been an issue with the flat panel for as long as i can remember with SPG. What I always do is follow my flats with at least one bias frame and that always turns the flat panel off. I never make the flats the last thing. If I do the flat panel will not turn off. Doing a bias at the end keeps me from having to remember to manually turn the panel brightness down to zero.
I thought I brought this issue up about the panel not turning off if it’s on or if it’s the last thing when SPG disconnects a while back but I don’t think it ever got looked at.
I built my own flat box based on a Atmega32U4 MCU and a TLC5947 24ch LED driver. I made a custom PCB with the ICs on one side and the LEDs on the other side. I adapted the v3 code found here (GitHub - jwellman80/ArduinoLightbox) and also the v4 code found here (GitHub - ivonnyssen/ArduinoFlatBox: Flat Box Implementation for Alnitak protocol version 44). Unfortunately none of them seems to work properly w/ SGPro. As others encountered, commands issued via a terminal yield the right behaviour and return codes. Nevertheless, when I try to connect to SGPro, the connection in closed after time out. @tomastro posted a solution, but the file he posted, cannot be loaded any more. Would be great to post the solution here for all. @Jared could you figure out, what causes the Atmega32U4 to fail, IMHO it is just sending/receiving some text via COM, it should be independent from hardware.
I also tried to implement the Gemini SnapCap command set, which is very similar to the Alnitak set, but also here, I get a timeout.
Thanks for all. If it works, I will post all the hardware and software to Github and provide a link here!
The 32u4 fails because of the way it handles serial connections VS the 328P device. I’d recommend using a 328P rather than the 32u4.
I know what the issue is but it’s not something I’m willing to address as I don’t want to cause regressions with actual Alnitak FlipFlat/FlatMan devices as this would require changes in SGP to deal with the deficiencies in the 32u4’s serial connection.
Can you give more detail about the issue, maybe there is a workaround, which could be implemented on the 32u4 side? Please understand that I have put in much effort to my lightbox, I made a custom PCB, etched it, soldered it, made a housing, … only to realize now that it won‘t work. Switching to the 328P-AU w/ FT232RL would mean to revert my project to the start. There is no Arduino here, that could be changed, the 32u4 is fixed.
I guess the issue might be related to DTR being set low by SGPro, so the 32u4 refuses to send data? Could you think of a „DIY Flatbox“ Device in the dropdown, maybe with a custom command set, so we do not have to mimic Alnitak behaviour?
I would suggest looking into the ASCOM Cover/Calibrater device which well be adding support for in the very near future. Which will add a abstraction layer between SGP and the actual implementation of the device:
There are 2 issues. 1 is the DTR, which would require the SGP changes and would likely break devices that use the 328P. The other is that you need to wait on the serial connection inside of the Leonardo as it cannot establish it later on. If I recall this is why the DTR is needed as that will reboot the Leonardo and then it can connect to the serial while the 328P does not have this limitation due to the fact that it can only handle Serial and doesn’t have the HID support that the 32U4 does.
I got it working. I searched the net and came across something they call a „ugly hack“, and I agree, but it works. One has to change a file from Arduino core libs to disable DTR check before sending data, disable IDE core cache and recompile everything. I used Tom‘s code, added some TLC5947 stuff using the Adafruit lib and boom.
I finished the Cover/Calibrator ASCOM support last night. So if you’d prefer to write your own ASCOM driver and decouple from the Alnitak protocol that option will also be available. Then you can do whatever you need to do inside of your driver or extend it beyond what the alnitak protocol supports.
I plan to make a github page, where I post the files neccessary to build the PCB, the case and the firmware. @tomastro might I upload your code with my modifications to github? How do you want to be referred to, this question also goes to @Jared, who provided the basic code.
Currently I am not into writing ASCOM drivers, I have no experience with that. Maybe I start soon
ASCOM Cover/Calibrator support would be useful to me right now. I’ve made a DIY flat planet using a tracing pad and Arduino, with the help of the Arduino code you provided. It works fine when the Arduino is connected directly to the telescope PC that’s mounted on my observatory pier.
What I’m now trying to do is tunnel the serial communications via Ethernet to another computer (Raspberry Pi) mounted on the observatory wall, in order to avoid having to run another conduit between the pier and observatory wall. I’ve set up a virtual com port on the Windows pier PC, using Pearle TruePort, which tunnels the serial communications to the Raspberry PI, which runs ser2net. This system works when I send Alnitak commands manually via a serial terminal. However, it is unreliable when the Alnitak commands are sent via SGP using the flat panel brightness slider. I suspect the problem is that SGP sends a brightness control command on every detected movement of the slider. In my case, it would be better if the commands were only issued upon release of the slider.
With ASCOM Cover/Calibrator support, I could at least write my own code that filters the rapid succession of brightness changes, and send the Altinak commands to a TCP socket without having to muck around with virtual com ports.
