I tried running PAA with the new SM OS 1.7 beta: same issue. I can no longer slew at reasonable speed without
getting "Mount aborted. Please restart the process and reduce the speed". Im trying 8x slew which is brutally slow.
CCD: ZWO ASI533
I did a update / dist-upgrade to my Pi4B+ running SM OS
KStars build 2022-01-23 stable release thinking the issue with polar alignment
would resolve, no go. I have been successful before with the same gear and
setup for many months but for the past few weeks the PA aborts, parks the mount
and recommends slowing the speed, which doesnt fix the issue. Is there something
in the stellar solver I should change or is there a log I can post for review ?
Cam is ZWO ASI533, 100 gain, 1.5s exp, offset 10, scope is WO GT71 with 0.8x FR.
Regular slew to target / capture and solve is working fine. I have checked all cables,
nothing dragging, nothing changed since before when PS was previously working fine
your group and mode values are incompatible maybe ? seems like group 2 only goes up to 87:
the section starting at "Which values are valid for my monitor?" looks like it has
the info you need
I also run SM OS on a pi 8Gb with SSD drive. Disadvantage: pi 4B+ wifi for me was flaky. I had problems
with wifi connectivity from my LAN to the pi on 2.4Gz channel but remedied that by running an extender at
the opposite end of the house and 2 floors up from the main router. I added a wpa_supplicant file to name
the SSIDs and priorities of the router/extender and I set the priority of the stellarmate hot spot to the lowest value. I use
VNC Viewer (RealVNC) to remote to the pi from anywhere inside now.
Ron, slight typo in my prev response: file should be /tmp/astrometryLog.txt .
If you are concerned about the file size, when you are done with KStars, in a command shell you can
truncate the file to zero length with
truncate -s0 /tmp/astrometryLog.txt
Hy, thanks for responding, I will dig deeper in the thread and see what I can learn.
I find it odd that within one month of development the solve speed has gone down
for my software environment. At first the new stellarsolve was literally unbelievably
fast .. as in OMG! Ron, I had my settings for logging as Default instead of File and unchecked
the specified file path... I found the astrometyLog.txt in /tmp
Hy, can you post some documentation on the drop down Options profiles or provide a link
to that information ? I was able to get plate solving going but much slower than
before my apt updates tonight. Hoping for insight on fine tuning.
a bit more info. I focussed with bhatinov mask using the ZWO EAF hand control then refined the focus
with the Ekos focus module. My Ekos profile is correct and has not been changed since before last update.
I then changed my settings for PAA / StellarSolver:
source extraction method: Internal SEP, solving method: Internal Solver, options profile: 1-Default
I have under Scale & Position Use Scale and Use Position unchecked. The Load all indexes in Memory is
now unchecked in the profile. PAA works but is very slow and now I cant get the solver to plate solve on
a star in Cassiopia to work on building my alignment model.
I did sudo apt update && sudo apt dist-upgrade as of tonight. I am running SM OS on rpi 4B+ 8Gb.
I have tried multiple option permutations to get the PAA so solve and it eventually times out
and fails. I am using ASI533MCpro as my main camera, ASI120MMmini as guider attached
to ZWO OAG, so the CCD to plate solve with is the ASI533. Prior to this upgrade which had the
old PAA using on-board astrometry everything worked fine. This is extremely frustrating as
tonight is the first clear night here since Dec 31 2020! I have Ekos debugger running in case
of a crash and have verbose logging going to /tmp/astrometryLog.txt ... Can someone please
help me salvage this evening ? I cant even do a basic two star alignment model: nothing will solve.
funny I was working on the same things with Ekos fits viewer (EFV) and ASIFitsView (AFV) last night to
sort out offset on my ASI533MCPro. Like you, I see funky results in the EFV histogram and stats
reporting. Minimum is always zero in Ekos stats but AFV seems to be reporting the lowest non-zero values for
minimums and highest non-zero for maximums. For darks, those maximums can be quite high due to a single hot
pixel which is near impossible to see on a histogram (freq. of 1). I was shooting at 120 gain, 10 offset
but wanted to drop the gain closer to the 100 gain setting where you get a discontinuity drop in read noise. So now
I am trying 110 gain and may go to 105 just to ensure that drop is firm: I cant explain it, but I just don't trust
the exact 100 gain value to transition the drop.
AFV plots and stats for 30 sec exp, 110 gain, 20 and 40 offset, -10C. Pretty substantial shift away from zero for each offset 20 increment.
build works now! but docker_compose up bonks...
I am setting
and I use an ASI533MC Pro (OSC)
that is an absurdly long to build almost anything! thanks for the heads up. I will hang in there.
LiveStack looks very promising and I would like to give it a try on my pi 4B+.
I installed docker (v20.10.1 build 831ebea) with curl and docker-compose (v1.27.4) with pip3.
I'm running into an issue during the docker-compose build