It seems there are a few issues with indi_gphoto since v3, Ive raised one here too: www.indilib.org/forum/ccds-dslrs/9317-cl...mk-ii-fits-file.html
Fits files arent being captured correctly for me on my 5D mkII.
I know this doesnt help your specific issue, although I hope we can get enough attention for it to be investigated by someone who might know the code.
Hang in there, fingers crossed it get resolved soon.
Hi again Wouter,
Yes indeed I'll be falling back to cr2, although the intent of raising this here was to hopefully highlight a potential bug. It might be something that could be fixed and could be impacting others.
Is this something we can raise with Jasem?
I've tried disabling the auto debayer, and the result is just a non-debayered image in the Fits Viewer, and it doesnt change the resulting file.
I've edited my original post and added a link to the raw files in onedrive if you want to take a look.
Hi all I've just recently come back to using my DSLR and noticed an oddity with the FITS images produced by KStars/EKOS.
Compared to the CR2 file the FITS image produced seems to have lost some data in the conversion somewhere between the camera and landing on my disk through EKOS.
When captured as "Native" it come out as expected. However in FITS its has all turned green!
Yes I have turned of auto stretch and checked all my settings, RAW format and image dimensions. See attached images when pull into PixInsight below.
Any ideas would be appreciated. Thanks.
Also of note, if you have not seen already in the referenced article from above:
"If you use an OSC camera of make ZWO, caution is advised when the 'native' camera driver is used: the ZWO SDK enables the user in the acquisition software to control settings that influence the white balance of a displayed color image. This is achieved by two parameters, WB_R and WB_B, data range 1 to 100, the default values are WB_R = 52 and WB_B = 95. The intensities of the red channel will be multiplied by WB_R/50 and the intensities of the blue channel by WB_B/50. Unfortunately the results of this multiplication are also written to disk in the FITS file. So it is important to set the values of both parameters to 50 and subsequently apply 'Save Config'; only in this way, the real raw intensities will be saved to disk in the FITS files, see . Since the data coming from the camera are saved in FITS files which usually have the number format 'unsigned 16-bit integer', otherwise rounding errors and clipping of high values will arise. Such a complication is generally avoided when the ASCOM camera driver is used instead of the native driver."
This explains the issue. So with FITS files you probably wont be "loosing" any data, just making it harder for some processing applications/workflows to deal with it easily.
I use the ASI 294 with the default settings in KStars/EKOS/Indi and have not had issues.
Although I don't use PixInsights for calibrations or integration phases.
Instead I use AstropixelProcessor, which I feel gives a great result and handles the "color cast" you see in PixInsight, which I believe is an artificial cast to do with how the data is written perhaps.
Additionally, I also recommend doing Dark Flat instead of Bias frames with this sensor (this topic has been quite hot around this sensor, check the forums. As the sensor does not behave consistently at with sub-second frames)
When opening my source images in PixInsight I can confirm I get the same blue cast you describe, but this does not affect the final integration which AstropixelProcessor seems to handle well.
One question, as I expect PixInsights should integrate the channels separately, can you apply a HistogramTransform afterwards, but without the "Link RGB Channels" icon enabled. This can be found on the ScreenTransferFunction tool.
When I do this with the "Link RGB Channels" disabled, the result is a normal averaged to grey image (it is color, although the color cast has gone!)
So perhaps calibrate & integrate as normal, but apply an unlinked HistogramTransformation
I have questioned this myself in the past and played at setting these values, but found little difference in my resulting integrated images.
Also I suspect the defaults (in indi panel, WB_R: 52, WB_B: 95) have something to do with the Bayer array and sensitivity of sensor to those color relative to Green.
Hope this helps.
I have the same mount AzGTI and essentially have/had the same issue, i.e DEC axis was not moving enough and I was getting the same error in the calibration step.
Note, I use EQMOD in this case, with EKOS and KStars, have guiding going to the mount, not ST4 cable, but have a serial port directly to the AZGTI.
Interestingly I did tear down the unit and adjust gear mesh for both DEC and RA axis. This I'm not 100% sure has made a huge difference, and I think that something else is at play here, and I will try to explain.
Hopefully Jasem might also validate what I'm seeing...
Before and after I adjusted mesh & re-assembled the unit, I performed a calibration and guiding session "test" indoors on a fixed "target", with the equipment fully loaded on the mount and tripod with the main & guide camera.
How do you do a Guide Calibration indoors? ... I hear you ask
Well from what I understand and can see in the INDI panel for EQMOD, when the unit is setup and in tracking mode the RA Tracking Rate is set at 15.04... and DEC at 0. This assumes you are aligned to the celestial pole exactly and only require RA rate tracking.
However what can be done for the indoors test is to set the RA rate to 0, and make sure the Track Mode is set to Custom.
Then slew your mount/scope pointing to a fairly distant wall (or adjust focus of guide scope&cam, if walls are closer), try find a dark surface or put up a piece of dark paper, and then try simulate a tiny star (i used a tiny pinprick of toothpaste lol, something bright to contrast on the dark surface). You may need to play with exposures and gain to get to the point where the star detection/tracking works.
With your fake star in focus on your guide cam, in the Guide Module, select it and start a calibration run, and watch the behaviour of you mount... and the deviations and pulses being applied.
My observations from the mechanical mesh adjustment:
Before - The DEC would not move very much in the forward step and then take very long in the reverse direction. This was surely an indication of backlash. I would have to set very high Calibration Pulses 3000-5000 to get it move as much as RA would. Then also whilst guiding had started the DEC would eventually drift out and then start to be very erratic, being slow to react to what ever motion was detected in the image noise or slight vibrations in the floor.
After - The DEC was much more well behaved. The calibration step seemed a bit more linear in the forward and reverse phase, and when guiding it stayed within the 2 arc/sec range on DEC, and would recover fairly well if I forced some fake vibration/movement through the floor, although this was not great ans was still slow...
Additionally I also tested using the Backlash settings for DEC, this can be enabled in the Indi Panel for EQMOD. But it can be a double edge sword. The amount of movement here has to be small enough to take up the slack/backlash of the mechanical movement. Any more and you start getting overshoots, and will play havoc with the guiding algorithm. Also it is hit and miss for when the mount is instructed to execute pulses of alternate directions when it thinks its near centre, sometimes making the guiding drift out significantly. I spent a few hours trying to fine tune the amount of backlash comp. having the mount cover open but fully connected to Kstars, and issuing forward and reverse commands to visually see the amount of backlash required in the gears.
Something else at play here...?
Finally, whilst I had the unit open, and I could also observe the movement of the motor & gears, I experimented with how the tracking rates and pulse guide rates behaved.
When the Tracking Rate is set to anything over 0, like the default Sideral ( 15.04 ) then guide pulses in reverse or forward seem to have a significant impact on the current tracking rate, i.e. a speeding up or slowing down proportional to the tracking rate (for a fixed pulse length)
When the Tracking Rate is set at 0 however, like when we are in normal celestial tracking at least for the DEC axis. Then the I could see the motor not moving at all for no input pulses. When pulses are issued, then movement of the motor just a handful of micro-steps, a minute amount and seemed to me would never result in any movement on the DEC axis. It seems to me that as the tracking rate was 0, the proportional movement applied to the motor on forward and reverse commands was just an decimal error amount or some small number.
I strongly suspect there is something wrong with how this unit works with EQMOD, or what commands are issued to the DEC motors when the Tracking Rate is 0. If the required movement command to the motor is some proportional value of the tracking rate, and that is zero, then we have a problem. Also the approach used for guiding in this case is based on pulse duration, and guiding then equates to commands like: speed up/slow down motor by X for Y milliseconds...
A few things I took from this:
1. This unit will always have backlash purely from the design using a cheap reduction gearbox off the basic dc motor, a set of gears off the gearbox then the worm gear onto the DEC axis. Adjusting the mesh may give you a little better reaction time when the motor is reversing direction, however we have to balance the tightness of the mesh with preventing binding and gear wear. Adjusting the mesh for gears is quite fiddly and the adjustment I did was so small, its hard to believe it made much of difference.
2. Increasing the number of Calibration Steps to use in the settings was needed to get a clear indication of the full movement and how much backlash was evident in the hardware. My Kstars/Ekos was defaulted to 2 or 3 steps, and would always fail calibration.
3. Enabling Backlash compensation, was not very fruitful and needs fine adjustment of the amount of motor movement, for little gain I believe.
4. Whilst using the indoors fake star test, i was expecting to essentially have no movement, but interestingly the guding algorithm was issuing correction commands. I put this down to noise and how it was calculating small pixel movement in the fake star image. There are some things to get right here, like making sure the fake star is not too big in terms of pixel and maps to what you would see in practice. This is a scope/cam resolution and binning configuration exercise. This will affect the amount of correction the algorithm thinks it needs to apply on each axis.
5. I believe there may be an issue in the mount/motor commands issued in relation to the 0 tracking rate. I think there is a minimum value in the Indi Panel somewhere, but again this is a pulse length, and I don't think will impact the dc motor rotation, because anything X 0 = 0! The motor is always instructed to rotate at some rate for a Y ms pulse.
Overall, I have resolved myself to testing my mechanical fixes when I get another full clear night, although I dont think much will have changed, and that I need to invest in a better mount.
I don't think this mount can deliver even consistent 1-2 arc/sec guiding and I would benefit from not wasting the scarce clear nights we have in the UK if I had a better mount.
I just hope Jasem and the wisdom of the pros in this forum might illuminate the situation, and maybe I'm just seeing things wrong, and there is some switch/fix that would make this mount a little better...
Thanks, and I hope I haven't bored everyone!
I have day job as a software engineer now for 15 years, build and fly model electric helicopters and am quite comfortable taking things apart.
Setup is AzGTI, RedCat 51/Tamron 600, Astro Essential guide scope, ZWO 294, ZWO 290 mini, RasberyPI 4, Astroberry, latest KStars etc...
Guide Rates and config were based on defaults other than changes made for my investigation...
Wow, looks like AradoSKYindi has been on a roll and found a few issues and offered solutions!
Any chance these could be incorporated into next releases of Astroberry?
So I had my first guided session with Ekos a couple nights ago, clear skies are far a few between, and well I was not getting very far with DEC guiding.
Sometimes the calibration step would complete, although this was mostly luck probably due to apparent mount movement in the DEC from noise in the guide image.
I found a hint regarding validating that DEC guiding commands from a post that Jashem had in another discussion a few years back in the forum, and decided I would give it a go.
In the Indi Panel I provided 5000ms pulses to N and S alternatively whilst the AZGTI mount was tracking. This resulted in no effect to the N/S travel whatsoever!
Do we know if this mount with EQMod has compatibility issues?
I noticed in the Indi Panel also that the tracking rate for DEC is set at 0, and RA is set at the default sidreal value. I assume this is because the mount is in EQ mode, and hence provided you are polar aligned and after a GOTO/Solve & Slew you don't need any "tracking" in DEC.
Any thoughts or guidance?
So just to add to my previous post regarding Wifi dropping when connecting my ZWO 294 to the RPI4 with Stellarmate 1.4.6:
I flashed Astroberry 2.0 last night and used the exact same hardware, connected all my gear in the same way, ZWO 294 into the USB3 port etc, and Wifi hotspot is stable. No issues. Yipee!!!
So for me this certainly discounts any power source noise issues, low power issues (I'm using a 12v 6A), or RPI4 hardware issue.
In fact it squarely points the problems at being within the Stellarmate software/image and perhaps the drivers/kernel modules being used to run the RPI4 hardware.
Not sure what more I can do, what logs I could provide etc, so that we can get Stellarmate as stable as rock rock too as I like the product and paid for it. But I'm some sense I'm disappointed, as its been a struggle getting things up and running, and I've raised support requests with the Stellarmate team and not had any replies.
For now I will stick with Astroberry 2.0 and concentrate on getting my skills up capturing a few nebulae
Clear skies all.
I started setting up my new ZWO camera last night with the 1.4.6 which i though I would upgrade to first. However noticed some very odd behaviour.
I have a RPI 4B 4GB.
As soon as I connect the ZWO 294 to one of the USB3 ports on the RPI4 the stellarmate hotspot dissapears/drops. I tested this a number of times to make sure. Disconnect the camera usb lead from either end (the camera end or the RPI4 end) and the wifi comes up again shortly. Connect the camera and the wifi hotspot drops away.
It feels like there may be some interplay of the USB drivers and the wifi system?
I found a similar post where someone else described very similar behaviour with his QHY cam.
I suspect there is something going on with drivers/irqs/pci bus or even maybe electronic noise. I did try and issolate any affect of noise from my power sources, and even tried short USB3 leads to and from the camera and pi to limit any cable pickup/capacitance.
Can anyone duplicate this effect or experienced it? How did you resolve?
Yeah, looks like im seeing the same or similar issue.
Kstars 3.3.7 crashes on connecting with indi since I upgraded from 3.3.6.
Kstars log has no output of value indicating the issue, all I have are entries in Windows event viewer that show something related to QtWidgets.dll.
Wonder if this might be a compiler platform issue, half tempted to use the QtWidgets. dll from 3.3.6.