Reading tooltip for "Save sequence HFR value to file", it says that if it's checked, HFR threshold value is constant (so it won't be updated, even if it's zero).
On my 3.6.0, an in-sequence automated autofocus run correctly updated HFR threshold (with unchecked Save sequence HFR value to file).
Matteo
Read More...
Actually in Astroberry repo I can see some arm64 packages. But if system is ready or not, I think only Radek can answer....
Read More...
Hi Willy,
SkySafari driver, AFAIK, is not meant to let an indi client interact with drivers, but to let SkySafari interact with drivers as it was an indi client itself. It's not clear how are you planning to use your mount: you want to drive an astrophotography session via Ekos? Or?
Read More...
Here too it is working. Seems to me that also "Auto update" can be left checked: if unit is "app", found that changing binning updates Low and High scales with the correct numbers.
Read More...
Hy, I'm very sorry I was working and haven't seen your msg until now. Reading on I discovered you found parameters to replicate it anyway 
Super!
Read More...
Not RaspberryPI-related only: here on a intel VM, 2GB ram configured, Ubuntu 20.04 and KStars 3.6.0 from ppa, same behaviour: all-simulators profile, three error assestment solves went perfect (4 sec exposure, less than 1 sec each), adjust plate solves (same refhresh 4 seconds, tried also with 6 seconds) all fail.
Read More...
Maybe you already know, but while Ekos reports guiding error in arcseconds, PHD2 reports it primarily in pixels, and in arcseconds in parenthesis; so be sure to check arcseconds with arcseconds.
Maybe you only wrote it wrong, but to be clear: it's not "close to the horizon", it's "close to the celestial equator" (i.e. close to Dec = 0).
HTH
Matteo
Read More...
This Is open source anyways... anyone of us with enough skill can look at the code and fix It. Just to say...
Back on topic: I have just terminated 5 nights of captures changing broadband and narrowband filters during every night on two differenti rigs, and I didn't get a single filter tag missing sub. It's clear that the bug appears in very specifc circumnstances, otherwise we'd all experiment It: precise information and debug logs are essential for the developers to track down the issue and fix It.
I didn't experiment the bug, otherwise I woud have done It myself.
Read More...
Jasem you're right, at startup iOptron driver overrides MF setting in HC, it happens to me too. Fix is setting it in the driver and saving configuration, as you said.
Euripides, you have to let the mount track some time AFTER CROSSING MERIDIAN, otherwise MF is not going to happen. In iOptron at "Meridian Behaviour" setting "Flip" or "Stop" doesn't matter here, since MF will be triggered by Ekos; but the "Limit" you set does matter. Basic rule is:
0 < EKOS LIMIT < MOUNT LIMIT
Example: set Ekos to trigger MF 3° after crossing the meridian, and set mount limit to 6° after crossing meridian.
Ekos limit should be greater than 0, because Ekos and mount must exactly agree on which side on the meridian we are: allowing to track some degree after crossing it, relaxes the precision needed and accounts for small difference in models and approximations between Ekos and mount firmware. Mount limit should be greater then Ekos limit, because some time is usually needed to complete the running capture when filp time occurs (should be: MOUNT LIMIT - EKOS LIMIT > LONGEST EXPOSURE PLANNED).
And MOUNT LIMIT should be small enough to avoid the mount smashing your equipment on a tripod leg or something).
Hope this helps.
Read More...
I think that is correct: REL_FOCUS_POSITION property is used to move the focuser a relative amount in respect to where it is now; since the focuser moves, also abs position changes. To say: if focuse is at absolute position 100, and you set relative position to 20, it will move to 120. Then you set relative position to -40, and it will move to absolute position 80.
Read More...