I think I'm experiencing a bug, but I'm not sure if it's with the device firmware or the Indi driver. The issues is FlipFlap driver not recognizing a state change from Parked to Unparked and and vice-versa. I am not using a filter wheel, as I've seen in other threads, but am experiencing a failure when I'm running KStars 3.6.0 on RPi4 with with Arduino Nano flashed with El Flat Panel firmware . I can Unpark and Park the flap from within the indi Controll panel manually, but the status light stays red and the Unpack button tries to turn green but flashes back to grey and the Parked button turns green again, even though it is in fact unparked. This isn't a huge deal, but when I try to run the scheduler it sees the cap as "Parked" when it's really "Unparked" and aborts the job. I've run thru this with verbose logging turned on and there isn't much info that I can see. I've attached a log and the cap errors out towards the bottom of the log. Any help or direction would be greatly appreciated. Here is the section of the log the error presents itself:
"2022-11-02T21:07:06.724 CDT DEBG ][ org.kde.kstars.ekos.scheduler] - "Checking Startup State (6)..."
[2022-11-02T21:07:06.725 CDT INFO ][ org.kde.kstars.ekos.scheduler] - "Unparking cap..."
[2022-11-02T21:07:07.724 CDT DEBG ][ org.kde.kstars.ekos.scheduler] - "Checking Startup State (7)..."
[2022-11-02T21:07:07.725 CDT INFO ][ org.kde.kstars.ekos.scheduler] - "Cap unparking error."
[2022-11-02T21:07:08.724 CDT INFO ][ org.kde.kstars.ekos.scheduler] - Scheduler is stopping...
[2022-11-02T21:07:08.724 CDT DEBG ][ org.kde.kstars.ekos.scheduler] - Job ' "Soul Nebula" ' is stopping current action... 0
[2022-11-02T21:07:08.726 CDT INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'Soul Nebula' has not been processed upon scheduler stop, marking aborted."
I use a 3d printed shutter, connected to this
. It's purched on a 3d printed platform at the end of my dew shield. I use the servo blaster driver to control its opening and closing. I attached an
EL panelEL panel
to the inside plane of the shutter and while flats are not 100% automated, the servo blaster driver is picked up by Kstars and allows for automated darks and biases. And a remote triggering of flat capturing sequence.
The only problem I'm still trying to tackle from a DIY perspective is 100% automated flats. Which would then let me capture flats while using the Scheduler module. For now I have to manually engage the EL panel when I need to capture a fresh batch of flats and current configuration is not dimmable, but that will be changing soon.
To do this, I use the astroberry relay driver to flick on an RPi relay hat . Since I'm using a dedicated astro camera I can take advantage of the ADU auto flat capture feature within Ekos. So at least part of the flat capture process is automated.
Hope this helps.
Thank you for the insights!Given the nature of my question regarding code, I obviously see no dumb questions, ever, which is a blessing and a curse. I’m just grateful you’ve shared your thoughts. Yes, I am controlling the EL Panel with the relay board mentioned in my original post. As of right now, I am not too concerned about controlling the brightness of the EL panel. I’m shooting with one light pollution filter on a one shot color camera so I don’t need to adjust brightness for multiple filters at this point, that will be a bridge across later I suppose. For now, I want Ekos’s capture module two turn on the EL panel when servoblaster has my automated dust cap closed via the calibration settings for flats. The EL Panel is mounted to the inside of my dust cap. Automated flat capture is my final step in complete rig automation. I’d like this to be a pi based solution if possible without adding another component to the mix. As far as the question about Ekos adjusting the brightness for a static exposure, I don’t know. I’ve never seen that behavior offered from the system before. But I do like that idea, it could check a lot of boxes, not that my opinion carries much weight. Any suggestions on how I can modify a driver to fit my needs or a good place to start to learn how to accomplish that?
If this is in the wrong place or there is already thread containing this info it please let me know. I just didn't see one.
First, I have very very limited coding experience, but am looking for some help in controlling an EL Panel via the Calibration settings within the capture module of Ekos. I have an RPi 4 running astroberry with a Raspberry Pi Expansion Board, Power Relay . I'm using a 3d printed shutter on a servo driven by servoblastercap. The cap closes properly/automatically when it comes time to taking darks so that's not an issue. I had planed to control el panel via the relays on the hat. I found Astroberry DIY including the Astroberry Relay, and while I can manually flick the relays on within the INDI Control Panel, I can't seem to get it to respond to the calibration settings. I also found a driver written dokeeffe on GitHub call qik_flat, which at first glance looks exactly like what I'm trying to do, but again I'm code dumb and don't know. So I'm humbly asking the community for help. Any direction would be fantastically appreciated.
Since my previous post I have upgraded to Kstars 3.5.4 on the remote machine and updated/upgraded the Astroberry. I have not seen the crash and all seems to functioning properly. Can’t say for sure the crash has been resolved as I’ve only had one night of imaging since the updates/upgrade.
I can’t say thank you enough to all of you that manage and maintain the software.
I’m not completely sure I’m posting this in the proper location, but I can’t seem to find any other info about what is happening. If this should be posted elsewhere please let me know.
Kstars crashes while guiding is active.
I’m running the latest version of Kstars on MacOS. I have a RPi4 running Astroberry and connect to it remote from the Mac to control my imaging sessions. I’ve had great success with this set up until the most recent update/upgrade. I updated Astroberry and Kstars. At that point Kstars began crashing after the first two or three frames were captured. The crash only seems to take place while I have guiding active. I’m using the internal guider, but have not tried PHD2 at this point. Has anyone else been experiencing this issue/crash. I’m grateful for any help you can offer.
I believe I’ve captured debug logs and can supply those if needed. (I’m on my phone at the moment and away from the imaging comp.)
Hi There, I am new to this site and am hoping you don't mind me piggy backing on this convo. If this should have been posted else where, I'm sorry and please let me know.
I just completed building the indi_servoblaster_cap driver as described in one of your previous posts knro . And I should say thank you for that post and all the documentation. I'm running Astroberry on RPi 4, and using Indi Web Manager in concert with KStars and Ekos on another comp. I have two question:
a. How can I get Indi Web Manager to see ServoBlaster as an optional driver from within the local driver drop list? It does not appear within the Auxiliary section, however it does appear when using KStars on the RPi 4, which leads me to my next question.
b. While in KStars, on the RPi 4, I can set ServoBlaster Cap as an auxiliary driver within one of my Ekos profiles and start it, no problem. However, in the subsequent Indi Control Panel, I can not get the servo to move when I click park/unpark. The servo is plugged into the GPIO pins as follows (and from what I can tell, matches your table in the previously mentioned link). Power to pin 2, Ground to pin 9, and signal to pin 11. On the Calibrate tab I choose servo ID 1, as per the table it correlates to pin 11. You should also know when I built the servo driver, I did skip the USBRelay2 Roof and Wiring PiGPIO as they were stated as being optional. Is Wiring PiGPIO required for manual operation of the dust cap or is it more for the automation within a capture sequence as describe earlier in this thread? What I'm I missing?