Welcome.

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.

Read More...

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.

Read More...

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.

Read More...

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.

Read More...

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?

Read More...

David James replied to the topic 'Alternatives to Raspberry Pi4?' in the forum. 3 weeks ago

AstroNerd wrote:
Nice idea...BUT
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.... :)


I can see that would become an issue with larger loads and much longer extensions, but we're talking about a weight that's still less than that of a single counterweight that comes with the mount on a mount that's designed to take at least three of them (all told there's currently less total weight being carried in payload and computer combined than the mount carried in counterweights alone for its original payload).

For comparison, here's what the counterweight loading looks like when the mount is carrying the original 10" Newtonian with a mirrorless camera attached.



The moment of inertia of all that has to exceed that of the mini computer sitting another 2" further out. It's like 3½lbs vs 30lbs.

Read More...

David James replied to the topic 'Alternatives to Raspberry Pi4?' in the forum. 4 weeks ago

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



It's about the size of a counterweight and weighs almost as much as well. To mount it I also bought a VESA bracket that holds the computer and which is usually intended to suspend the unit off the back of a monitor or television (obviously not one that's actually mounted to a VESA mount). I built a receiver for the VESA bracket out of plywood that attaches to the end of my EQ6's counterweight bar, so it acts as a counterweight.



It almost weighs enough to properly counterweight the rest of the rig (!), at least when the Evostar72 is on and would probably do so if the guidescope were omitted. I only have 10lb weights (the mount originally carried a 10" Newtonian which I still have) and if I add even one right at the top of the bar it dramatically overbalances the counterweight end, so I'll need to find a way to add some smaller weights to the rig but it is pretty close to balanced already.



As you can see I have a powered USB 3.0 hub velcroed to the backside of the EQ6, so all rig-related USB cables emerge from here. The hub itself uses 12v, so it can be powered from the same distribution centre as everything else, which I have velcroed onto the control panel side of the EQ6.



What's great about this is that the SSD is big enough for all the Astrometry.net FITS for plate solving and with fast processors aboard it solves in a second or two. The SSD also has legions of space for saving FITS from the camera.

Read More...

David James replied to the topic 'Installing on Kubuntu' in the forum. 4 weeks ago

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

The data pkg is about 300 MB, the gsc package is only a few dozen kB.

Read More...

Someone in another thread ( www.indilib.org/forum/ekos/8293-solved-m....html?start=12#64234 ) posted that he used the SynScan controller to factory reset the mount and that that cleared the issue up.

Read More...

David James replied to the topic 'QHY183C not detected' in the forum. 4 weeks ago

If you take a look at the SDK install script, it does this:

cp -a sbin/fxload /sbin/fxload

... so you may well have the QHY version installed without even knowing it.

You can check which it is... the original 2008 vintage fxload installed by Ubuntu (0.0.20081013-1ubuntu2):
$ md5sum /sbin/fxload 
cf5820edbf0ac2adaadc0366cecc7c62  /sbin/fxload

... or the newer QHY version:
$ md5sum sdk_linux64_20.11.28/sbin/fxload 
163119db651909a3dd4b5f0be5000162  sdk_linux64_20.11.28/sbin/fxload


Read More...

David James replied to the topic 'QHY183C not detected' in the forum. 4 weeks ago

knro wrote: The fxload issue is not an issue on Ubuntu.

Are you using KStars + INDI from PPA? what's kstars version reported?


Umm, that's not true. At all.

The fxload IS, repeat *IS* an issue on Ubuntu.

The ONLY way I've been able to get my QHY294C to run with INDI on *three separate Ubuntu installs* is to download the QHYCCD SDK, extract the archive and copy across their fxload to replace the Ubuntu fxload.

Read More...