Weird... I can't find it anymore either on the ASI site either.
I do have a copy of it; I actually sold my ASI 120 MM last summer but never deleted the files.
The thing is I doubt it'll make much difference as it made none to me when I updated mine with it. Getting a powered USB 3.0 hub is the one thing that seems to make the most difference.
I have an X-T1 and it's next to hopeless, despite been purportedly supported by gphoto2. In a way, it's worse than hopeless because I can get it to pull off one shot, and one shot only, before it crashes. That's in Entangle and Darktable; it's never once worked in INDI.
It's kind of worth using Entangle to see what the camera supports.
Interesting thread... good to see that a solution was ultimately available.
What an interesting design choice, though. It's kind of half-assed, really.
If I were designing this, I would have designed into the mount a powered USB 3.0 hub, then take an internal USB connection for the USB-serial connection of the mount controller. Then they'd be left with 3 USB ports that can be set aside as USB sockets on the control panel to connect other devices to. Or they could create a second hub to provide a total of 6 USB sockets.
I just saw El Corazon's response after posting mine... I agree, your FOV appears to be out. And that probably ties in to my discovery of the discrepancy in image scale in your log.
Is this not working in more than one setup? It sounds like you've got a RPi4 and a computer with otherwise identical setups?
My recollection of how Load & Slew works is that it solves the loaded image, slews the mount to the putative centre of the loaded image, then takes a further image, solves it, reslews and so on.
So in this, is it taking and successfully solving those subsequent images?
Reading through your log, it doesn't look like it is.
One other thing I noticed was a difference in downsampling between the loaded image and the captured ones. The loaded image is being evaluated at "Scale range: 3.85544 to 5.78316 arcsec/pixel".
The first autocapture by contrast: "[...] arcsec per pixel range: 1.94069 to 3.8505"
The second (I think) autocapture: "[...] arcsec per pixel range: 1.45551 to 2.88787"
So from my understanding, as this range decreases, you need an increasingly large library of astrometry FITS files.
And that brings me to one last thing in your logs: "Total Size of Index files: 2.44583 GB"
I've got like 18 GB worth. So perhaps you don't have enough of the higher precision FITS files installed?
One should never run an imaging rig with the counter weight that far down the shaft, it can cause huge loads on the motors when slewing, it’s much better to have much more weight and further up towards the mount head, there has been a lot of research done on this, the initial inertia with a weight that far down I’d bad for the mount....
My current rig employs a Lenovo ThinkCentre M93P 'Tiny' "desktop" machine, though it uses a laptop power connector.
The specs of mine include 5 USB 3.0 ports (no 2.0), an Intel Dual-Core i5-4570T Processor up to 3.60 GHz, 8GB RAM and a 240GB SSD. I installed Kubuntu 20.10 alongside Win10Pro. I bought it refurbished so I didn't spend an enormous amount. It also came with a rather lame USB 2.0 2G wifi stick, a cheap keyboard and a mouse that rattles (for real). I upgraded the USB wifi to a USB 3.0 5G dongle with an antenna. I also made some changes to the BIOS to allow booting without a keyboard. I run krfb on it as a remote desktop server (it seems to default to 1024x768 when no monitors are plugged in).
For some reason the 20.10 gsc packages are still not available (curiously, they are available for the forthcoming 21.04).
You can download and install the 20.04 packages manually (they're functionally the same); assuming you have a regular Linux 64 bit OS:
$ wget http://ppa.launchpad.net/mutlaqja/ppa/ubuntu/pool/main/g/gsc/gsc-data_1.3~ubuntu20.04.1_all.deb && wget http://ppa.launchpad.net/mutlaqja/ppa/ubuntu/pool/main/g/gsc/gsc_1.3~ubuntu20.04.1_amd64.deb
sudo dpkg -i gsc-data_1.3~ubuntu20.04.1_all.deb && sudo dpkg -i gsc_1.3~ubuntu20.04.1_amd64.deb
Someone in another thread (
) posted that he used the SynScan controller to factory reset the mount and that that cleared the issue up.
If you take a look at the SDK install script, it does this:
cp -a sbin/fxload /sbin/fxload
$ md5sum /sbin/fxload cf5820edbf0ac2adaadc0366cecc7c62 /sbin/fxload
$ md5sum sdk_linux64_20.11.28/sbin/fxload 163119db651909a3dd4b5f0be5000162 sdk_linux64_20.11.28/sbin/fxload
knro wrote: The fxload issue is not an issue on Ubuntu.
Are you using KStars + INDI from PPA? what's kstars version reported?