I have two AZ-GTi's. Love them.
RA guiding is pretty good. DE is often quite bad. But it's still good enough for my AT72EDII.
My rig is not well balanced - need a heavier counterweight (I am using a standard 1 kg).
I have a USB3 stick plugged into RPI4 with SM 1.5.4 (now 1.5.5).
All my captures are saved there for ease of transfer.
I used to have a desktop shortcut pointing to it and Ekos was saving images on it without any problem.
Since a couple of months ago (after the switch to Raspbian from Mate?) the shortcut is not on the desktop and Ekos cannot save to the stick.
To make it available I have to go to File Manager (the stick is shown there) and click on it.
After that the shortcut appears on the desktop and Ekos is able to save to the stick.
Is this a normal behavior or something is wrong with my installation?
Yes. The log shows exactly what has happened.
The mount went off limits (below horizon), hit the tripod. I noticed that the mount stopped slewing (while being away from the mount and just watching ekos/kstars), so I tried to stop and park it.
Anyway, it was just a strange glitch.
Tonight, I braved-up and let the system do the auto-flip (after several nights of doing it manually). It went normally.
Same setup. No updates.
Wolfgang - relevant log is attached.
Wolfgang - thanks!
I am not complaining.
I'll wait until 3.5.0 is released.
Last night and tonight did manual flips just to be on a save side.
Hy - good info - thanks much!
So, in Guide Module - Control Parameters - when those go in effect?
Immediately? After dither? After re-calibration?
Also - left is for RA, right is for DEC, right?
Actually, the meridian flip never failed me before.
I didn't do it since August, I believe.
Tonight it failed - went in a wrong direction and hit the tripod.
I suppose that's just because I use a beta Windows KStars client from mid-October (with multi-star guiding but without the internal solver).
Just reporting... Nothing broke - all is well.
Jasem - thank you very much for looking into this!
I wish I could test but I only have access to official updates (and Windows KStars nightlies) .
knro wrote: I contacted SER Player author and he told me Endianess is not really respected as far as the actual astro-processing software go. At any rate, I put it now to always use BIG_ENDIAN and the results appear to be correct. Please use latest INDI and re-test.
ncdu was actually already on the system.
I ran it and it helped!
-- astrometry index files
Of course... I did download more index files on the "problem" RPI.
xsnrg wrote: If available for you system, install ncdu. It provides a nice interface to seeing filesystem hogs and allowing you to delete right from the same interface.
It should be available through your package manager on most systems.
I'll try that - thanks much!
This was reported before.
In a couple of threads it was attributed to either a too low of an offset value or to WB_R/WB_B values.
Well, there's something else.
I am not sure how consistent and repeatable this is but I had this on many occasions.
It goes like this:
-- take a sequence of long Light exposures.
-- take bias images (select Type: Bias in Ekos) - bias images will (often) be empty, no signal whatsoever.
-- to force bias images to work, I switch back to Type: Light and take several short light images at 0.1-0.001s. Probably, just one 0.001s would be enough.
-- after that bias images are taken correctly
Windows client. SM 1.5.4 on RPI4 4Gb.
Logs are less than 5Mb...
df -h gies me:
stellarmate@stellarmate:~ $ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 30G 17G 11G 62% / devtmpfs 1.7G 0 1.7G 0% /dev tmpfs 1.8G 0 1.8G 0% /dev/shm tmpfs 1.8G 9.6M 1.8G 1% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.8G 0 1.8G 0% /sys/fs/cgroup /dev/mmcblk0p1 253M 54M 199M 22% /boot tmpfs 366M 8.0K 365M 1% /run/user/1000 stellarmate@stellarmate:~ $
Can they grow this big? I'll check.
wvreeven wrote: Did you enable debug logging on the one with high disk usage? You may need to remove those logs.