Just cleaned and recompiled everything from current GIT, couldn't reproduce the alignment crash anymore, but "Warm CCD" remains grayed out even though the camera has cooling and capture tab correctly shows the temperature control. What also happens is that most tabs are totally grayed out until I switch optical train to another one and back.
Also noticed that Ekos -> PHD2 connection has some recent issue that it tries to send DEC guide mode setting to PHD2 before it has connected, doesn't receive response obviously, and starts deferring all further requests so that connection doesn't progress at all. It stays waiting for equipment connection to complete, but PHD2 hasn't received the request in the first place. Commenting out sending the DEC guide mode setting works around this issue and Ekos connects to PHD2 normally.
I'm not sure when these issues have appeared as I have had my equipment offline for maintenance for the summer and only recently started preparing for the season.
I have similar problem with current git version that Ekos doesn't seem to reliably register devices that are already connected in the INDI server when Ekos connects to the server. This causes boxes in scheduler to be grayed out, but also causes other issues like crash in align where the code tries to access mount device via a null pointer. Disconnecting and reconnecting devices after connecting with Ekos partially works around the issue, but for some reason capture tab doesn't seem to notice the filter wheel and doesn't show filters which prevents me from actually capturing anything as my sequences have filters set and capture just shows -- and doesn't proceed. Filters are correctly shown in align and focus tabs though. I have quite full set of devices from Ekos point of view (mount/cooled camera/focuser/filter wheel/dome/dustcap/lightbox) and they seem to be a bit randomly registered or not, usually not. Might be a timing issue due to all devices getting "connected" at once when Ekos connects to the already running INDI server?
Yes, or INDI actually, just configure the correct focuser as snoop target of your camera and you get:
FOCUSPOS= 1861 / Focus position in steps
FOCUSTEM= -6.950E+00 / Focuser temperature in degrees C
EQMod driver has setting called LED Brightness if the mount has polarscope with LED. My current EQ8 doesn't but I think my previous HEQ5 did show it.
Ah, it actually is documented in the pdf I linked, just hadn't noticed it:
Note1: The Select New filter command will always rotate the filter wheel in a
clockwise direction to arrive at the target filter. If 128 (0x80 hexadecimal) is
added to the “New Filter number” then this will allow the filter wheel to
rotate the wheel in either direction to reach the target filter in the shortest
I added unidirectional movement as an option, will submit a pull request after some quick testing.
ZWO just released an updated SDK today and change log says fixes the ARM64 issue, github.com/indilib/indi-3rdparty/pull/626
It does also mention some optimizations for 678 cameras so I'd guess they are supported by this version.
There is now a new SDK available and change log mentions fixing this issue. I made a pull request at github.com/indilib/indi-3rdparty/pull/626 if you want to test before it's merged to main branch.
I took some USB traffic dump using the Windows program SX provides to see how it implements one-way rotation, but haven't had time to look at it in detail yet. There is also one other option to implement this by some work in the driver so that if a decreasing filter number is selected, the driver would first select the last filter, then the first filter and then move to the selected filter. That way motion would always be into the same direction.
The undefined symbol error is common for having a 3rd-party driver and base INDI library out of sync (C++ is notorious for introducing ABI-incompatibilities when pretty much anything in the base class changes), recompiling the 3rd-party driver fixes it.
Ah well, just as I feared. If I remember correctly back in the day Linux on ARM used to work in such a way that unaligned memory accesses (trying to access for example 32-bit data that is not in 32-bit aligned address) caused trap in the kernel and depending on options the kernel either fixed up the access or raised SIGBUS as it's usually a bug and slow in any case and older ARM processors didn't support unaligned access at all.
I made a short test program that does exactly this and it works on both my Raspberries (Pi 4 running 64-bit and Pi 3 running 32-bit RaspberryOS). It needs to be renamed to unaligned.c (forum doesn't allow .c files) and compiled with -O0 or the compiler optimizes the access away and just prints the value. It should print "Value 0x8010203". This might be totally red herring and have nothing to do with the issue, but checking that on the problematic platforms would at least narrow the search a bit.