FYI I went back to 1.6.1 stable. No issues there, updating is also fine.
Thought I replied to this solution already but don't see it.
But I had tried that already and it did not do anything. Same packages are kept back. So I can't upgrade kstars on my stellarmate 1.7 beta.
I am also on the 1.7 beta.
I have no issues with the 1.7 beta when I image it. ZWO camera's work fine.
But as soon as I update the image my camera's keep crashing ZWO1600/294mc and it keeps reloading the asi driver.
I don't know if its relevant. But also note this when i try to update.
stellarmate@stellarmate:~ $ sudo apt-get update
Hit:1 deb.debian.org/debian bullseye InRelease
Hit:2 security.debian.org/debian-security bullseye-security InRelease
Hit:3 archive.raspberrypi.org/debian bullseye InRelease
Hit:4 deb.debian.org/debian bullseye-updates InRelease
Hit:5 ppa.stellarmate.com/repos/apt/stable bullseye InRelease
Reading package lists... Done
N: Skipping acquire of configured file 'main/binary-armhf/Packages' as repository 'ppa.stellarmate.com/repos/apt/stable bullseye InRelease' doesn't support architecture 'armhf'
stellarmate@stellarmate:~ $ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
indi-bin kstars-bleeding kstars-bleeding-dbg libindi1
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
This also means I am stuck with the kstars build dated 31-12-2021, I actually wanted to update because of a fix for the flat calibration issue I posted a few days ago.
What can I do? This issue is easy to reproduce. I have tried 3 times now.
Thanks Jasem, as always much impressed with the speed you show in fixing things.
Will check and report back with the results.
I gathered the logs.
I have 1 log for my stellarmate (which is on the 3.5.7 beta) and 1 log for kstars/ekos on my ubuntu laptop latest stable 3.5.7.
Behavior is the same. Just look in the logs for where it says ADU in acceptable tolerance and the next frame with same exposure time will get an unexpected high ADU, the preview also is visibly very bright.
One thing that I also notice is that although the settings on both instances are the same, i haven't touched or changed the light source, the calculated exposure time is very different. almost double on my laptop.
Hope this helps.
Please let me know if I can help you (help me) with more information or tests.
Yes that is exactly what's happening here.
Some good frames and then a very bright one in the preview and then Ekos starts over again with a lower exposure time to compensate the brightness.
I too "solved" it by just noting down the calculated exposure time and take flats manually.
Hope this info helps.
After a one year pause I dusted off my equipment. Installed stellarmate on my new Pi. Did my first session and wanted to take flats in my usual way through Ekos using the flats option and have Ekos calibrate to my desired ADU of 25000.
Tried this with my ASI1600MC and ASI294MC-Pro.
Ekos starts taking frames, then decides on the exposure time to fit my ADU setting, then the next image is taken with the calculated exposure time, then calculates the ADU and this is more than double the ADU you would expect so it discards the frame and starts calibrating again, It will do this indefinitely.
Here are some examples, same exposure time, m22-01-20T22:54:10 Download Time: 59.00 s, New Download Time Estimate: 36.83 s.
2022-01-20T22:54:08 Capturing 0,573-second image...ore than double ADU:
2022-01-20T22:55:54 Current ADU is 51570 Next exposure is 1,008488 seconds.
2022-01-20T22:55:53 Capturing 0,599-second image...
2022-01-20T22:55:53 Current ADU 24997 within target ADU tolerance range.
2022-01-20T22:55:53 Download Time: 99.52 s, New Download Time Estimate: 35.84 s.
2022-01-20T22:55:51 Capturing 0,599-second image...
2022-01-20T22:54:13 Current ADU is 50573 Next exposure is 0,557522 seconds.
2022-01-20T22:54:12 Capturing 0,574-second image...
2022-01-20T22:54:11 Current ADU 24004 within target ADU tolerance range.
2022-01-20T22:54:11 Download Time: 60.81 s, New Download Time Estimate: 37.02 s.
2022-01-20T22:54:10 Capturing 0,574-second image...
2022-01-20T22:54:10 Current ADU is 23982 Next exposure is 0,573908 seconds.
2022-01-20T22:54:10 Download Time: 59.00 s, New Download Time Estimate: 36.83 s.
2022-01-20T22:54:08 Capturing 0,573-second image...
Just to make sure it's not my stellarmate setup causing the issue, I installed Ekos in my Ubuntu desktop, latest stable version. Same issue.
Anyone familiar with this?
Appreciate your help.
Same here. No fix with gpsd. Running 1.4.4. on RPI4
DrawsACircle wrote: @AstroNerd, have you had a GPS connected (gpsd driver)? Mine connects, but detects no signal from the gps, no gps fix, it only takes a couple of seconds with 1.4.3.
Derpit, I think a saw you mention in another post that backlash compensation turned up as a setting in the driver. Care to share your experience?
Verstuurd vanaf mijn ONEPLUS A5010 met Tapatalk
Would you know where I could check out the features of the numerous drivers, seems I can only see it when I actually have device connected.
I'm about to upgrade from the standard skywatcher auto focuser combined with the Hitec Astro DC focus to the more robust ZWO ASI EAF.
Would anyone owning the ZWO ASI EAF care to share the experiences you have until now?
One thing that the driver for the Hitec Astro dearly missed was backlash compensation which renders the setup useless.
Does the Indi driver have backlash compensation built into it?
I just tried moving 22GB in older captures from a USB drive to the NanoPi. No issues moving loads of data, CPU heat about the same when capturing.