Thanks. This is a feature that I have needed for some time. Looking forward to trying it out.
The source for wiringPi was pulled from the public domain several months ago. That is why you are running into the link errors. Try this link to get and install the .deb file for the Pi 4:
Sounds strange, but I can apparently duplicate the memory leak with those options disabled. Using Canon T6s, Astroberry over VNC. I duplicated with upload to client set. After a few images, I get the "Unsufficient Memory" errors.
I did some testing with the CCD Simulator (with the same frame size as the Canon) and did not notice a memory leak, even looping to the FITS viewer.
The 3rdparty drivers were recently moved to their own repository. The link on that page is the old location.
This tutorial may help get you started if you decide to write the driver for the relays :
Also, this may be of interest:
I personally use the WiringPi library with INDI drivers for GPIO control. I have recently used it to add ST4 capability to an INDI raspberry pi camera driver and it works pretty well and is easy to use.
I managed to to some more indoor testing tonight. I spent some time trying to reproduce a misalignment situation, but all 'align's were successful, with the exception of one which was not really driver related.
At 21:24, I intentionally launched KStars and aligned before the time updated on the RasPi. This caused KStars to indicate the correct time, but a date of 2/11/16, and the HC retained the pre-updated time and date. At 21:25, I powered down to avoid hitting the limit on the mount. At 21:32, I re-powered the mount from the position near the limit switch, performed the 'align', and the alignment was restored. This time issue was possibly the cause of the issue that I had a couple of days ago. I was testing hibernate and power cycling and not really paying attention to whether the time updated before launching KStars/EKOS.
One thing to note is that it did not matter whether Hibernate was enabled or not when performing the align.
Attached are the logs.
PS - I had the mount cable disconnect at 21:58. At 22:54, connection to the mount was re-established and then a successful align.
The mount always moved to the indexes without any issues when the command was sent.
The movement to the stop happened during a test slew to a selected object. The mount was pier-west pointing east. The scope was misaligned at this point, but still indicating east. I then selected an object to the west. The mount then slewed westward without performing a meridian flip, this kept the OTA continuing under the counterweight bar until the stop was reached.
During the tests, the HC was not used for any commands to the mount.
The configuration for the time settings was "KStars Updates All Devices". I will need to check the time indicated on the HC in future tests.
Thanks. Hope this helps.
Yes. My goal is to one day mount on a pier, so I will be able to park it in a known position and later get it operating without manual interaction, possibly completely automated, with the appropriate monitoring. This is a huge step in that direction.
Align button was a success! After pressing it, the mount would respond with "Align Success" displayed on the HC. The mount returned to the switch position each time it was requested. No manual interaction was performed during the testing.
During the first test, the mount seemed to point in the direction requested, but on the 2nd and 3rd tests the alignment was off enough for the mount to not execute a east to west meridian flip. The mount ended up on the safety stop switches, which is fine, because I was closely monitoring it.
I did test to see if the align button would perform both with Hibernate enabled and disabled. It would return to the switch position either way.
The logs are attached, but I am not sure if the first logs contain tests 1 and 2, or is somehow the first test was overwritten.
This looks very promising. Thanks.