Hans replied to the topic '10Micron Mount Modelling' in the forum. 4 months ago

> so does the Ekos mount model feature now build a 10micron model or not ?

Not afaik.

Read More...

Hans replied to the topic '10Micron Mount Modelling' in the forum. 4 months ago


I still propose you use MW4 for that.

Oh ? Maybe I can help there. For model building a good signal to noise ratio can be easily reached with strong binning, like 3x or 4x. And downscaling the image as well, I've tried up to 6x downscale and found 4x donwscale works well for my setups (F/12 and an F/5.4 systems). With this exposures of about 4 seconds suffice.

This confuses me. Do you think something got removed from MW4 or from Ekos ?

Read More...

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

Hans replied to the topic 'Ekos Optical Trains' in the forum. 10 months ago

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 :P In the end I think it will improve stability so I'm in :)
-- Hans

Read More...

Hans replied to the topic 'Baader Steeldrive II won‘t connect' in the forum. 11 months ago

Could this be an access rights issue ?

Read More...

Hans replied to the topic 'Astroberry and cr3 canon 250d' in the forum. 1 year ago

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

-- Hans

Read More...

Hans replied to the topic 'Canon EOS Ra' in the forum. 1 year ago
Hans replied to the topic 'Astroberry and cr3 canon 250d' in the forum. 1 year 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

Read More...

Hans replied to the topic 'Support for Astro-Gadget FocusDream Pro' in the forum. 1 year 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

Read More...

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

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