When dealing with 8:3 harmonics on Celestron mounts like the CGEM, it is important to record multiples of 3 runs sequentially in order for the 180 second harmonic to shift through the graph, which allows neutralization of the harmonic when averaging the runs.
The current implementation of PEC recording requires the user to click record per every run. As far as I can tell, if one clicks when the bin is not 1, recording will start from whatever bin we're in at the moment, then will proceed until the total number of bins are elapsed, and the file will be saved with bins reordered correctly to run from 1 to the maximum number.
The issue is that if the next run is not immediately restarted by the user, any missed bins from that worm period are discarded, and the recording will start from whatever bin we're at when clicking Record again. This makes it cumbersome to record continuously for the purose of averaging out spurious harmonics.
It would be great to have a lineedit field that can be filled with the number of runs required, so that when clicking Record, the driver will start from whatever bin we're at as of the current implementation, but automatically save and restart on subsequent runs. At the end of the number of runs specified by the lineedit, Recording stops and we're left with individual txt files for the runs.

Read More...

Absolutely, I was asking in order to evaluate read noise swamping and flat exposure using Kstars' reported ADU. It definitely is that way, because if I expose 3 minutes on a bright star I see it blooming, but at ~16000 adu.
Thanks for confirming!

Read More...

Hi All,
I wanted to experiment with my 450D to complement ASI1600mm and I noticed that stars will saturate at about 14000 ADU when shooting in FITS, same count as shooting in cr2.
I couldn't quite find an answer searching the forum: does this mean that indi/ekos, when saving to fits, whill place unscaled 14-bit adu values in a 16 bit fits with the counts from 16383 to 65535 kept unused?
This seems consistent with my observations in Siril, which reads saturation at ~0.25 in 0-1.0 range.

This would mean that adu counts need to be multiplies by 4 for purposes of RN swamping calculations and Flats ADU settings.

This would also mean that if I want a flat exposed to 20000 I have to aim for 5000 as read in ekos fits viewer.

Am I right or confused?

Read More...

Hi Jasem,
Tried and didn't solve the issue, however I found a way to reproduce AND solve it: if I disable "Port selector" for the profile, Trains are invoked and work correctly. If port selector is active, celestron driver inhibits recall of the correct train and new profiles don't get the first start train dialog.
Either removing the mount from the profile OR disabling port selector solve the issue

Read More...

This is still happening. I'm out right now and can't build a new profile I need. If I create a profile without the mount (indi_celestron_gps), it works, as soon as I add a mount, the trains break and if I take an exposure it crashes

Read More...

Although I still haven't the weather to test again, I wanted to confirm that yes, when the problem occurs, the alignment captures are successful, then the first Capture exposure is stuck Downloading... So this cannot be a hardware/cabling issue.

Read More...

Second session with flawless flip tonight!
For me at least, this seems solved.

Read More...

Attached is a stack trace.
This is 100% reproducible for me.
I realize it has been discussed before, but I wanted to check if it's possible to look into this without having to trash the userdb.sqlite because that means redoing lots and lots of configs in all modules and for every profile.

Basically I needed a new profile for some tests:
1)Create new profile
2)Connect
-> Expected: Optical trains popup
-> Effective: no Optical trains prompt
3)Switch to Capture or any other module using trains
-> No Train is defined
-> Edit trains button does nothing
4)Try to start a capture
-> Segmentation Fault

Attached is also my sqlite db if @Jasem wants to see if there is a case-specific corruption going on.

Nothing super explanatory in the logs, but here's the crash lines

[2024-01-07T18:48:06.652 PST WARN ][                       default] - QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
[2024-01-07T18:48:06.652 PST WARN ][                       default] - QSocketNotifier: Invalid socket 21 and type 'Read', disabling...
[2024-01-07T18:48:06.652 PST WARN ][                       default] - QSocketNotifier: Invalid socket 27 and type 'Read', disabling...

Nothing super explanatory in the logs, but here's the crash lines

[2024-01-07T18:48:06.652 PST WARN ][                       default] - QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
[2024-01-07T18:48:06.652 PST WARN ][                       default] - QSocketNotifier: Invalid socket 21 and type 'Read', disabling...
[2024-01-07T18:48:06.652 PST WARN ][                       default] - QSocketNotifier: Invalid socket 27 and type 'Read', disabling...

First session with the new build didn't freeze after flip for me.
I'd be cautious and wait for another one at least since it was not happening every time even before, but I think it might be solved!

If only we could be done with these high winds!

Read More...

Attached is a stack trace.
This is 100% reproducible for me.
I realize it has been discussed before, but I wanted to check if it's possible to look into this without having to trash the userdb.sqlite because that means redoing lots and lots of configs in all modules and for every profile.

Basically I needed a new profile for some tests:
1)Create new profile
2)Connect
-> Expected: Optical trains popup
-> Effective: no Optical trains prompt
3)Switch to Capture or any other module using trains
-> No Train is defined
-> Edit trains button does nothing
4)Try to start a capture
-> Segmentation Fault

Attached is also my sqlite db if @Jasem wants to see if there is a case-specific corruption going on.

Nothing super explanatory in the logs, but here's the crash lines

[2024-01-07T18:48:06.652 PST WARN ][                       default] - QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
[2024-01-07T18:48:06.652 PST WARN ][                       default] - QSocketNotifier: Invalid socket 21 and type 'Read', disabling...
[2024-01-07T18:48:06.652 PST WARN ][                       default] - QSocketNotifier: Invalid socket 27 and type 'Read', disabling...

I didn't have a chance to test if anything is improved with the new minimum time for flip patch, which I suspect won't cover this issue, but I would add that this is outright unsafe for the equipment because these crashes cause the camera cooler to be shutdown abruptly, which is less than ideal for thermal shock, especially if your ambient temperature doesn't get below 15C like in my case, and the camera can very well be -30 from ambient. It gets a thermal shock at every flip, and that is scary to say the least.

Read More...

Just set them to 0 and it should work

Read More...

As others have reported, it is already solved by the new workaround in the driver, but I would also add that if you go in INDI server, Camera, Controls, set both GPS controls to 0 and save the device profile, it works perfectly and it also recalls in subsequent loadings.

Read More...