Proper versioning is the answer to the problem. Say, if the new version of INDI would not work with previous version of drivers, as it is usually the case, its version number should be bumped high enough to not match the drivers' dependency lists. Then, in case of Launchpad slowness, you as a user would see nothing (in Software Updater UI), or some conflict warnings (from apt CLI). At worst, it may offer you to upgrade INDI and uninstall drivers, which is still suspicious enough so that most users would cancel that.
 

Read More...

I would love extra resiliency too. Until then, there is an option to re-align at the beginning of each job. So you simply have short sequence and let the scheduler repeat it indefinitely or until certain time. In case when guider locks in wrong direction, you would only have a few remaining subs misaligned, then it re-aligns and continues nicely. My sequences are like 18×60s or 36×15s. Once in a while I get that cloud and the scheduler recovers soon enough.

Read More...

That is what I read on the internet about high speed mode too. Funny enough, I do not see the ADC width reduction with my ASI294MC (that is MC, not MM). I kinda see a slight difference in dark noise patterns with high speed enabled or disabled. But in both cases the data numbers seem quantized at 14 bit. I guess, this is why I had this mode enabled, apparently harmless. Better disable it for good.

Read More...

Right, I already added it to the top post. My problem was HighSpeedMode. Interestingly, this parameter exists for ASI294MC too, but does not seem to affect it in the same way.

Read More...

The ADC is specified to be 16-bit, not 14-bit. The ADC type and all the DR and sensitivity graphs are the same for MC and MM versions. The MC is able to produce full depth of 16-bit values, while MM is not able to do that for me. See the contradiction?

Read More...

By bringing the DR into discussion, which I am proving irrelevant with the example of ASI2600MC. Do not take it personal in any way, what you said is valid and reasonable. But to me it does not appear as a hard reason to not expect smooth 16-bit data out of ASI2600MM and that sample from ASI2600MC reinforces my expectation even further.

Read More...

OK, before the discussion went sideways, I googled somebody's raw image captured on ASI2600MC with NINA. It is a 16-bit FITS containing all possible values (mod 4), not only zeros. Now, it is different capture software and different camera, though specs seem identical for MC and MM.

Read More...

What the use of 16-bit ADC then? My understanding is that DR is a continuous measure of analog signal while ADC 'bits' is literally the width of digital signal. So whether DR is 13.7 or 2.89 in my particular scenario, I expect to see all sorts of 16-bit values coming from ADC.

Read More...

INDI 1.8.9, ASI SDK 1.16.3. The images look good overall. FITS data are 16-bit, but all DNs are multiples of 4, so really it is just 14-bit. ZWO specs say camera's ADC is 16-bit.
Does anybody see 16-bit data? I guess older ASI2600MC may behave similarly. I could not find any knobs that seem related.

Read More...

Right, as I said, I am able to script an autostart mostly. There are a few quirks that I listed. They may or may not be bugs. Devs may want to add the whole autostart scenario as a feature and make it working nicely, or just keep the bag of little features that one can use to script an autostart as needed.
The HW problem was just a nudge to think about autostart. Of course I should solve that problem somehow, but there will always be something. Every version of Ekos has a new kind of bug that may throw it off guard in a tricky circumstances, for example. I am thinking about setting up a watchdog that would restart like if no new images came out in last N minutes. External watchdog and recovery protocol is a good practice for any system that is supposed to run on its own for a long time.

Read More...

My computer that runs Ekos has a habit of hanging a few hours in the imaging session. It is unpredictable, so I haven't figured out what is going on yet. Meanwhile, I configured watchdog so it just restarts the whole thing on its own. It automatically launches KStars and runs a script that pokes at KStars/Ekos DBus and INDI interfaces. I leave a simple config file for it with a few parameters. I was able to get the following:

  1. Select configured Ekos profile and start it.
  2. Select configured telescope config slot.
  3. Load configured schedule and start it.
These are all the major steps needed, it mostly works. It even did its job a couple of times already when the computer hung in the middle of night.
Some random ideas:
  1. Some settings are not saved between sessions, like: guiding camera bin level and gain, align capture target accuracy and dark subtraction. There may be more; those I noticed and keep flipping every time I start new Ekos. Unless Ekos saves its settings immediately when changed, I would like to have a button to force sync when I'm done tweaking it, so that I am sure in case of a restart I get where I left it.
  2. Once in a while my INDI drivers fail to start. Mostly it is the SX drivers fails to find its camera, but it can be anything. There should be an easy way to tell if starting INDI was successful. Otherwise I would opt to restart the machine and try again. 
  3. Maybe have that startup sequence built into Ekos? Like a single DBus message to start with last state, optionally giving the schedule file.


Read More...

Last time I tried the latest Jan 9 version. It seems, both old problems are gone. No 'discarding start request'. Linear algorithm reverts focus back to where it started.
Yet, the focus position drifted all the way from 16500 to 28000 in 6 hours. See the attached logs.
Only a few first focus attempts were somewhat successful. After that clouds rolled in, so star detection errors are legit.
From what I read in the log, failing focus session reverts the focus asynchronously. Next focus session starts quickly before focus motor reached target position and reads current position, not the intended one. So, either the reverting operation should wait until the motor actually completes the move. Or reading 'current position' should yield the target position if there is move command in flight. My diagnosis may be wrong, of course.

Read More...