Hi Tim,
Thanks for the test. Your findings indicate that the hack does not work, clearly too much has changed in the library interface.
If you have not already done so you can revert the hack fully with these commands :
At this point I see only three remaining paths forward:
- github.com/rkaczorek/astroberry-server/i...suecomment-828265566 . This is a lot of work and not all RPI will have the needed working space for it.
- manually backport the needed libraw20 changes into libraw19 and create a new so.19 library . Noone has done this yet to my knowledge.
- wait for raspbian to upgrade to a newer debian release
-- Hans
Read More...
I may have a workaround here ->
indilib.org/forum/astroberry/7875-astrob...anon-250d.html#71128
-- Hans
Read More...
I may have an intermediate solution for astroberry users.
I've made Debian installation packages for libraw_0.20.2-1 for arm7 (RPI) as a backport of 'bullseye' release. My astroberry version is Raspbian version 10 which is based on Debian 'buster'.
The packages are attached in a zip file and can be tested.
Installation instructions :
# Unzip the zip file on your astroberry
unzip astroberry-libraw_0.20.2-1_armhf.zip
# This extracts two package files : libraw20_0.20.2-1_armhf.deb and libraw-bin_0.20.2-1_armhf.deb
# Install both packages
sudo dpkg -i libraw20_0.20.2-1_armhf.deb libraw-bin_0.20.2-1_armhf.deb
# This upgrades libraw-bin from 0.19.2-2 to 0.20.2-1 and installs libraw20:armhf next to libraw19:armhf
# Now the tricky part, we still have libraw19:armhf and its libraries are used by kstars etc.
ls -la /usr/lib/arm-linux-gnueabihf/libraw* | grep -v libraw1394
# This produces :
# lrwxrwxrwx 1 root root 18 Jan 10 2019 /usr/lib/arm-linux-gnueabihf/libraw_r.so.19 -> libraw_r.so.19.0.0
# -rw-r--r-- 1 root root 837144 Jan 10 2019 /usr/lib/arm-linux-gnueabihf/libraw_r.so.19.0.0
# lrwxrwxrwx 1 root root 18 Oct 19 2020 /usr/lib/arm-linux-gnueabihf/libraw_r.so.20 -> libraw_r.so.20.0.0
# -rw-r--r-- 1 root root 1007808 Oct 19 2020 /usr/lib/arm-linux-gnueabihf/libraw_r.so.20.0.0
# lrwxrwxrwx 1 root root 16 Jan 10 2019 /usr/lib/arm-linux-gnueabihf/libraw.so.19 -> libraw.so.19.0.0
# -rw-r--r-- 1 root root 837144 Jan 10 2019 /usr/lib/arm-linux-gnueabihf/libraw.so.19.0.0
# lrwxrwxrwx 1 root root 16 Oct 19 2020 /usr/lib/arm-linux-gnueabihf/libraw.so.20 -> libraw.so.20.0.0
# -rw-r--r-- 1 root root 1007808 Oct 19 2020 /usr/lib/arm-linux-gnueabihf/libraw.so.20.0.0# We have both libraw version 19 and 20 libraries. Now the dirty part: we can repoint the symlinks :
sudo ln -sf /usr/lib/arm-linux-gnueabihf/libraw.so.20.0.0 /usr/lib/arm-linux-gnueabihf/libraw.so.19
sudo ln -sf /usr/lib/arm-linux-gnueabihf/libraw_r.so.20.0.0 /usr/lib/arm-linux-gnueabihf/libraw_r.so.19
# This way only the libraw version 20 will be used.
That's it. Test away. I cannot test myself as my Canon camera is too old and has a broken USB socket.
In case you want to revert :
sudo ln -sf /usr/lib/arm-linux-gnueabihf/libraw.so.19.0.0 /usr/lib/arm-linux-gnueabihf/libraw.so.19
sudo ln -sf /usr/lib/arm-linux-gnueabihf/libraw_r.so.19.0.0 /usr/lib/arm-linux-gnueabihf/libraw_r.so.19
sudo apt remove libraw-bin libraw20:armhf
sudo apt install libraw-bin # this gets you the 19 version back from the repository
-- Hans
Read More...
It can be, the challenge will be finding a developer that wants to work on it. I for one am not interested at this point in taking up yet another driver project.
You can help any future developer by finding documentation about the programming interface of the focuser (API docs) and publishing that here, or add a URL to it.
-- Hans
Read More...
For the record, it's this device ->
astro-gadget.net/gadgets/control-of-focu...reampro-crayford-kit
ps. I do not have one.
Read More...
I recognize the issue you ran into. I have not much to add other than that I know it is being worked on.
As a stop-gap intended for observatories that can close a roof or shutter I wrote a small python program Ekos-Sentinel.py that can park and close the roof in case of emergency (like rain or mains power is out and UPS battery is about to die) when EKOS does not handle it because it is stuck, or waiting for something, or just crashed.
You can find it at
github.com/d33psky/rolloffroof/blob/mast...kos/ekos_sentinel.py
This does not fix your second-schedule-does-not-start though.
-- Hans
Read More...
The
sudo make installhas always annoyed me and I do not use it anymore. I proposed an option to indiserver long ago (which got merged in) to accept paths to the drivers.rickbassham wrote:
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug ../ make sudo make install
So in my build directory I run :
./indiserver ./some_driverDrivers in the list without a path are the system-installed drivers, those with a ./ or some other relative path are for the drivers that I'm working on.
This is also convenient if you develop on another system.
-- Hans
Read More...
ZS1RA wrote: My first post here. I had my EQ6R PRO running with Astroberry. I have just received my new Mesu 200 mount and couldn’t find a driver for it. Is this going to be pursued, if so I’m willing to assist in anyway I can. Do know that I know nothing about coding but could make my machine accessible via the Net for development purposes.Thanks
Shaun
Hi Shaun,
Given the info in this thread I think the best approach for you is to reach out to SiTech as a customer and ask them to rewrite their SiTechExe .NET program like Jasem already said a few posts up to an SDK/API that is usable without their .NET/Mono app.
Ideally this would be an open source driver in C or C++ that can run natively on all of Windows+Mac+Linux, is not limited to Intel architecture and exposes something as well known as the LX200 protocol. But that's probably too much to ask.
-- Hans
ps. I do not have a Mesu mount, but I've met Lucas a few times and think his mounts are really great.
Read More...
