PR is ready for testing ;
github.com/indilib/indi/pull/1609 # Add and apply Meade Protocol spec definitions
- Swap :Sh and :So
- Fix :Sd, setCommandXYZ, :SC, :SG, :Sz, :SM, :SN, :SO, :SP, :ST

Read More...

Lovely, yes given that 'most' LX200 protocol based mounts just worked with this driver with its spaces and colons for many years that does not surprise me at all.

And thanks for the 0xdf example

Read More...

Yup, ping received See brief followup in that other thread
-- Hans

Read More...

Hi Toni,
I made that patch for issue 1604 yesterday. Did not know about your thread here. I've removed some spaces but also found 1 place where the space is documented, albeit in an extension to the Meade protocol.
I'll have a look at the code snippet that you attached earlier in this thread, check it with the Meade spec and the 10Micron spec and make a new PR for it.
-- Hans
 

Read More...

Interesting idea. Some thoughts :
I would not want to make the assumption that having OAG1 in OT1 implies that that is the guider to use, or that that OAG port even has a guide camera attached. What if OT2 also has a guide camera somewhere ? Which one to use then ? I'd like to see the guide camera in the optical train explicitely listed as well. The choice which camera to use should still be with the user as we cannot deduce which one it is. Maybe the user wants to guide with the main camera of OT2. Also what if the guide camera is physically there but not to be used by INDI as PHD2 accesses it natively ? (this is what I actually use). Same for my SX-AO unit, it's there in the optical train but not to be accessed by INDI as PHD2 controls it natively.
Then on the idea of two imaging cameras, I like it and I see challenges like when to dither, both cameras need to wait for that to happen, and if 1 camera is waiting for the other to complete its sub it might have enough time to make another complete sub itself. Extrapolating to N cameras is cool, I agree we should design for N>=1 immedately when we leave N==1 where we are today.
I wonder what the purpose to INDI/EKOS is of something like a reducer in the optical train, it could be used to calculate the new focal length of course but then all spacing rings etc need to be added too ! This would be awesome to have of course.
OT-N support is very interesting, and it will be difficult to implement right without impacting N==1 stability which is already quite a challenge today In the end I think it will improve stability so I'm in
-- Hans

Read More...

Could this be an access rights issue ?

Read More...

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:

1. 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.
2. manually backport the needed libraw20 changes into libraw19 and create a new so.19 library . Noone has done this yet to my knowledge.
3. wait for raspbian to upgrade to a newer debian release

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.  

# 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

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...