Hans replied to the topic 'Canon EOS Ra' in the forum. 10 hours 10 minutes ago

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.  

File Attachment:

File Name: astroberry-libraw_0.20.2-1_armhf.zip
File Size: 421 KB

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


Hans replied to the topic 'Support for Astro-Gadget FocusDream Pro' in the forum. 1 week ago

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


Hans replied to the topic 'Support for Astro-Gadget FocusDream Pro' in the forum. 2 weeks ago

For the record, it's this device ->  astro-gadget.net/gadgets/control-of-focu...reampro-crayford-kit
ps. I do not have one.


Hans replied to the topic 'Scheduler strategy : help needed' in the forum. 1 month ago

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


Hans replied to the topic 'Driver development tutorials' in the forum. 4 months ago


sudo make install
part of

rickbassham wrote:

sudo make install

has 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.
So in my build directory I run :
./indiserver ./some_driver
And that can be run directly from an IDE like QtCreator in debugging mode.
Drivers 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


Hans replied to the topic 'Mesu Mount 200 Driver Request' in the forum. 4 months ago

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

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.


Cool that it works for you.
I have not found the cause for Latitude roundings (like your 23.9 to 24.0) . I saw it only in EKOS, and could not reproduce in DCD.py . (<a class="bbcode_url" href="http://dcd.py" target="_blank" rel="nofollow noopener noreferrer">dcd.py</a> did not round)