I have been looking for a suitable self-contained live stacking program that is easy to plug in. The criteria that I used are:
1) Stack from a folder. This is useful for cases when you don't have a camera hooked up and want to be as independent as possible from the embedded target (so long as you can export a folder to the host).
2) Decent and easy to use graphics to stretch the stacked image.
3) Speed, responsive.
4) Retain stretching parameters when a new sub comes in. Of course, this only matters with decent graphics.
5) Free.
6) Cross-platform. It's nice if you can run it on host and target. However, it may be better to run it on a host to not affect the real-time target behavior.
7) Scriptable (to customize preprocessing and stretching features).
I scored ASTAP, Siril, DSS Live, AstroToaster, ASIStudio, StellarMate and SharpCap on these criteria but won't present a table here - I would have to double-check for liability reasons.
The hardest criteria turned out to be the combination of (2,4) because I found only one suitable candidate suitable, maybe two (one that I have not tried myself but that I heard was good). Without it, it's worthless regardless of how much effort was put into the rest.
Just some usability criteria from a user's point of view, HTH.
Read More...
To close this thread, I was eventually able to run the camera. This happened after - at the request of QGYCCD's support - I installed their SDK so I was forced to rebuild from source code afterwards. I can't recall what I did differently, but after that it worked. One possibility is that my first source code build crashed one time and I had to restart it; it continued where it left off, maybe something broke there. It can also be a missed uninstall of the QHYCCD SDK - I can't remember.
I was told that the original PID in dmesg is 0200, afterwards it becomes 0201 (in lsusb for instance).
So, it's a bit of a mystery but it could well be my fault. Thanks for your support.
One very useful link that I found for rebuilding from source code is: gitea.nouspiro.space/nou/astro-soft-build . This builds Ekos and KStars, server and client, all in one go and works great.
Read More...
The build completed. I can now run KStars/Ekos. The aforementioned script is fantastic (thank you so much!)
I was still unable to use the camera. I realized that I had not run the fxload build/install that is part of the suite. Did that, and wow,
henk@raspberrypi:~ $ lsusb
Bus 002 Device 002: ID 1618:0201 QHYCCD QHY200U3G20-20230106
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Note that the PID is 0201, and not 0200 as rules.d says. I had noticed in Windows' device manager that the PID was 0201 on Windows as well. At least we are consistent now. Note also that the QHYCCD info shows up clearly. I suspect that ZWO changed the PID to 0201 because it upped the version explicitly in the product name "QHY 5-III 200M (Ver. 2)".
Next, running /usr/bin/qhy_video_test works, see the listing below. Basically, it works at a pretty good level!
It still does not work in Ekos though - because its rules.d wants a PID of 0200. I edited 85-qhyccd.rules and changed 0200 to 0201 but this did not work. It made lsusb show 0200 again, and the qhy tests failed. So I reverted back to 0200 and the qhy tests work again. I think I just need a new driver that works with PID 0201. At this point I may ask ZWO for help.
Building KStars via the github instructions did not work well. It needs apt-get-repository that I don't have and there are no instructions on how to get it. It also requires XISF that was optional so far, and StellarSolver. The prerequisites make it a bit overwhelming.
On the Losmandy Hackers IO board I received a very good tip though. Check out gitea.nouspiro.space/nou/astro-soft-build . It is a build-everything KStars/Ekos/indi/ind3rdparty script that performed flawlessly until my Pi crashed. I'm guessing it got overheated.
I'll restart the Pi and see how far it got then try to resume from there.
Read More...
Switching from 32-bit Buster to 64-bit Bullseye made all the difference. The library and drivers were all built successfully without errors AFAICT, following the github instructions. I started from a plain Raspbian Bullseye release. The desktop looks a bit emptier than Astroberry. It does not have a network configuration GUI but at least VNC works fine.
I tried using the astroberry instructions for 64 bit, but I could not figure out how to work around an invalid website certificate.
Next, on to the Kstars and Ekos GUIs. Only then will I know if my camera will work - I nearly forgot why I am doing this!
Read More...
I take that astroberry 32-bit comment back - I see there is a 64 bit Bullseye release!
Dang, so many things to learn, I take a wrong turn every time. Let me check that out.
Read More...
I am on Buster, which is 32-bit armv7l, running Raspbian GNU/Linux 10 while you are on Bullseye 64-bit aarch64, running Debian GNU/Linux 11.
I built all drivers at once so the error I displayed may just have been for the last one built. When following your directions, I got different errors than the one I listed. But first, comparing your system with mine,
Thanks Norman, I'm following the github instructions right now. I'm building on an Pi4b and there are some issues. It does not build indi_qhy_ccd for me, the main QHY driver component. The error log complains about pthread_join/detach/create symbols missing. With nm I checked that my pthread .so library has them so there is something wrong with the build commands.
There are some other minor problems too but those are easy to work around.
Read More...
I may have to take back that device ID of c193. With a new QHYCCD installation lsusb now shows 0200 as it ought to be. The installation is from the QHYCCD pages, I took the 23.05.09 release. I doubt if I am doing it right because, from ldd, indi_qhy_ccd was linked to libqhyccd.so.22 that I don't have. Replacing it with the latest .so from aforementioned release is what I did, and of course that is totally improper. So in Ekos it crashes right away. In the worst case I will hghaev t learn how to build indi_qhy_ccd. I will keep trying.
Read More...
My new QHY 5-III 200M received today works in SharpCap on Windows with the latest QHY beta driver (it's too new for the stable version).
It does not work in Ekos. Some dmesg lines:
[ 88.004084] usb 2-1: USB disconnect, device number 4
[ 88.088139] usb 1-1.1: USB disconnect, device number 8
[ 88.354541] usb 2-1: new SuperSpeed Gen 1 USB device number 5 using xhci_hcd
[ 88.385083] usb 2-1: LPM exit latency is zeroed, disabling LPM.
[ 88.386109] usb 2-1: New USB device found, idVendor=1618, idProduct=c193, bcdDevice= 0.00
[ 88.386129] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 88.386147] usb 2-1: Product: QHY5III200-20220421
[ 88.386164] usb 2-1: Manufacturer: QHYCCD
The device ID is apparently c193, and it shows up in lsusb (first line):
Bus 002 Device 004: ID 1618:c193
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
My rules.d file has this line for the QHY5II200:
ATTRS{idVendor}=="1618", ATTRS{idProduct}=="0200", RUN+="/sbin/fxload -t fx3 -I /lib/firmware/qhy/QHY5III200.img -D $env{DEVNAME}"
Clearly, it has the wrong device ID 0200 - should be c193. Some basic things work like the number of rows and columns, but not much more.
Any suggestions? Is there a missing driver that I can install?
Thanks in advance!
Read More...
Thanks Juan, I started astropi3. Not quite sure if it will work for my Pi4B or what Ekos version is installed but so far, no problems.
As I was writing the above line, the installation is done in just about a half hour. Of course, it will not work all at once, that is impossible...
But it works! At least, my ASI2600MM and ASI120MM cameras are now connected, which is what I needed from this installation.
So far so good. The indi version is 3.6.0 like I wanted. That is a good start of my day. I ranted too soon.
Read More...