Peter, I finally found time to work on my flat panel some more. The main issue I had was getting the LED string to be dim enough to allow an almost full range of control. Binned 2x2 Red needed a low intensity setting while unbinned H alpha needed almost full brightness to get an exposure time in the range I was looking for ( 2-10 seconds). I ended up with a series of diffusion materials and a 2-stop neutral density filter (stage lighting gel) to subdue the light intensity. The device is held together with masking tape at this time while I sort out a way to easily hold the four main sub-components together.
As a cobbled together device with bits acquired from a range of sources and 3D printed components supplied by my son, I don't feel comfortable in offering to build you one - mine is sized for my GT-71 refractor so it's quite compact. If you decide you want to tackle building one I would be happy to share with you my circuit diagram, program code, and design considerations.
Willem, I noticed this issue first with Flats and 3.5.7. I updated to 3.5.8 three days ago, just before a rare clear night two nights ago. I noticed the issue when PixInsight's WBPP script reported a number of Flat exposures fell into a "No Filter" category. This time a few light frames were effected too. Filenames properly show filter used but FITS header is missing the Filter keyword. Last time I think only Flats were involved.
I'm hoping for a resolution as individually adding the proper keyword and value to each file is time consuming. I haven't the skills/experience to write a script to automate the process.
A month ago I reported missing keyword for Filter in the FITS header. I shot more flats today and the same thing occurred - some files (a majority) were missing the Filter keyword in the header. (Causing WBPP to sort them as "no filter".
There was no response to my last post on this topic. Am I the only one? My flats are saved to my indoor laptop (client) rather than the Pi on the telescope. Camera is a QHY268M with the QHY FW3 filter wheel. Filters change as expected, filter name gets written to filename as expected, but only intermittently to the FITS header.
Anybody have any ideas on this? In this case all the exposures were short, in the neighbourhood of 0.05 to 0.12 seconds. (new flat source much brighter than expected - still experimenting)
This was with an updated Kstars - 3.5.8. Stable, Build: 2022-03-24T22:52:45Z
Sorry, should have mentioned the camera in question is a QHY268M.
While adding Flat files to PixInsight's WBPP this evenng I noticed a number of files are missing the FITS header "Filter" entry. 16 of 50 Green files were missing the keyword, 11 of the Blue also. (haven't done the others yet...). The order isn't the same in each case. I can add the keywords but it's time consuming.
Any idea what's happening? The log file seems to indicate all is proceeding as expected.
KStars 3.5.7 Stable, Build: 2022-01-24T09:12:30Z on Kubuntu
Hi Peter. Testing this week with my flat panel has shown me more work is needed. Turns out I overestimated the number of LEDs needed. I can barely dial it down enough to obtain multi-second exposures. The control program works fine though and responds to Ekos/Indi as expected.
I have other LEDs on the way but it will be a few weeks before I can get back to the project. (I had the first clear, usable night two nights ago since October 30 so I actually put the flat panel to use where I discovered the brightness issue. The upcoming forecast isn't too promising and the moon is waxing so waiting for LEDs to come isn't an issue.)
If you are interested I can send you the Arduino program and a schematic of the rest of the electrical components needed. The circuit is actually very simple - the Arduino running the code, a MOSFET (acts as an electrically controlled switch), and possibly a few resistors depending on the voltage requirement of the light panel used - LED or electroluminescent panel (EL).
A test shows the flat panel is not fully light tight when the light is off. An option to either pause the sequence when finished with flats and before starting with dark flats OR a way to save the calculated dark flat sequence and call it back (or restart it) after the flat panel is removed and the proper lens cap is installed would certainly be welcome. (by me at least).
I don't need the dark flat exposure times to be saved in a program restart scenarion, just long enough to do the light panel / lens cap swap.
(or is suppose I could just get a light tight black bag with a drawstring that drops over top of the light panel when installed on the OTA (which needs to point vertically up).)
Hi Peter, that's a generous offer, but I can't commit until I know "for sure" this this is going to work. I get back home later this coming week and will actually hook all the components together and finally test in a "real world" environment. I will let you know how things work out...
Regarding the two versions of the Alnitak command sequence protocol (Rev 3 of 2011 and Rev 44 of 2017).
I used the later one for my first cut of Arduino code (using command strings with capital "O" rather than with zeros). Initial testing back in September (Kstars 3.5.5) brought up some issues that Jasem fixed for 3.5.7. With 3.5.7 installed further testing results prompted me to monitor the USB packets exchanged between Ekos/Indi to the Arduino controller. I discovered these commands used the older version of the protocol, the one with zeros. Looking at the indi_flipflat driver source code (flip_flat.cpp) confirmed commands issued use the zeros structure (e.g. "if (!sendCommand(">P000", response))" which results in " >P000CR" being sent to the flat panel's Arduino controller.
I investigated all the Arduino programs listed in this thread but eventually settled on a modified (by me) version of the code found on the gluonfield.com site ( gluonfield.com/spacelike/content/astrophotography-flats-panel ). Basically I went back to using the zeros and the CR an LF command terminators.
As I mentioned I used a DIY LED based solution with a few 3D printed parts (courtesy of my son) to make a panel that slips over my OTAs dew shield like a lens cap. The Arduino with a MOSFET to switch the 12V required by the LED string mount on top of the panel assembly.
Although this flat panel solution has taken months of time and trial and error it did save me some money and provided an opportunity to add to my (minimal) programming and fabrication skills. Being essentially confined to home and literally having no opportunities to take astrophotos since my last session in late October this project along with a dew heater controller has kept me somewhat sane.
The flat panel can be toggled on/off. My panel is slip fit device that attaches to the OTA (refractor) like a lens cap. To use the panel it has to be manually installed for the flats sequence then removed before the scope can be covered ( front lens cap on) for the dark sequence.
A reminder to install the flat panel then remove and install the lens cap would be useful. I am not 100% sure the fit of the light panel is light tight. (I am away from the rig for a week so I can’t test for light tightness.)
My DIY LED flat panel seems to respond properly when a sequence of flats is executed. When using the new Dark Flats option in the capture module I am not prompted to cover the scope prior to the darks capture starting.
Am I missing something obvious or is this not currently possible?
Kstars 3.5.7 stable (Kubuntu 20.04) using indi_flipflat driver (Flip Man). (camera is QHY268M)
When you say driver, are you looking for an Indi driver for a flat panel that is not "FlipFlat" (indi_flipflat)? Or are you looking for a flat panel device itself that is not one of the Optec (Alnitak) offerings?
If a flat panel device itself, have you considered any of the inexpensive DIY flat panels described on a variety of internet sites. They range from rewired (to add a controller) electroluminescent panels to LED based devices controlled by a microcontroller like an Arduino. Many of these use the drive protocol initially defined by the Alnitak Generic Serial Commands (Optecinc.com site has this document) coded into the Arduino and connected to the "system" via USB.
I have one such LED/Arduino based system I am currently working the bugs out of. Kstars/Ekos/Indi controls it using the FlipFlat driver.
I run my setup with a locally mounted Raspberry Pi 4 (Astroberry from SSD) and talk to it from the house via Ethernet with my MacBook. The issues I had with WiFi reliability went away with the wired connection. I did have to add a 12V powered USB 3 hub to ensure proper voltage levels for the bus powered USB devices. The Pi is powered by an up-rated 5V supply to prevent under voltage events.
The issues now are typically weather related than computer related - a nice change.