Prior to 3.6.3 I never gave any thought to the relationship between guiding and the fits viewer, but now every guide camera frame get displayed in the fits viewer. There is no way to turn the behavior off other than disabling the fits viewer in KStars settings. (the "Use fits Viewer" button in the Ekos Guide tab has no effect)

Read More...

Thanks, Hy. The "guider" probably is the issue in my case. As I said, I rushed a new profile to try to get some testing in the window I had. It would be helpful if the "guider" options said something like (ST4) QHY5iii462C vs (pulse) CEM40, but that might not be practical the given way those fields are populated internally.

As for the rest - I simply left them at the default and figured I'd adjust if something seemed off - but I wasn't prepared for how very off it turned out. So I went back to PHD2.

Read More...

Not much to see here, I don't think.

I have not used the internal guider for 2+ years. But last night I had an hour or so before clouds and was trying a new configuration of scope/camera so I made an internal guider profile (to save the time of also setting up a new PHD2 profile). This is with a CEM40. Slewed to near the equator and tried to calibrate guiding. I got something quite similar to the original post.

Hi Juergen, fx3load does not come with a ubuntu 22.04 install, you must go get the updated version as described here:

You end up with a newer version of the file named fxload

Read More...

Thank you for the suggestions, Sonny. I never did figure out how to completely reload the distribution from the ppa, though I did manage to reinstall libqhy (but doing so did not place a new fxload in /sbin).
Instead, I finally realized that the executable that came in the fx3load package is built for the wrong architecture. Once I recompiled it and placed the new fxload in /sbin the camera works correctly again in Ekos.

Read More...

I install from ppa on a mini-pc with ubuntu 22.04. That used to also have the correct fxload, but it got lost in some update between early January and now.

Read More...

I was hoping it would be as easy as following Kevin Ross' lead and replacing fxload in /sbin I can now see the QHY5iii462C in lsusb and it is successful with QHY's LiveFrameMode test program, but in KStars the QHY driver crashes immediately.

Running $indiserver indi_qhy_ccd fails due to missing libqhyccd.so.22 (as per Simon's post above)

Can I get libqhyccd.so.22 somewhere without building INDI-3rdParty from source?

Read More...

This issue has appeared again. After a recent update my QHY5iii462C shows up as 'Cypress Westbridge', suggesting that the firmware is not loading.

Did the newest version of INDI 3rdparty lose the correct FXLOAD recently?

Read More...

I may be having the same issue as you, but I believe it is the fault of Ubuntu and not INDI.

Running Ubuntu 22.04 MATE on a Beelink U59 mini-pc. The OS is up to date.
The QHY5iii462C is the OAG guide camera for my RC6. Had that rig out last night, the previous time out for it was early January - all was OK then. (this fits lanco's timeline)

On starting up, the camera did not appear when I ran lsusb. I re-seated plugs, rebooted the computer, powered everything down and back up, went in and fetched another usb cable, even plugged the usb cable that runs to the on-scope hub directly into the QHY camera - nothing. Obviously not an INDI driver issue - the camera simply is not there.

So I brought everything in and installed the QHY all-in-one windows package onto a windows desktop. Plugged the QHY5iii462C into that machine - and it works fine in the QT-Capture program. So it seems to not be actually dead.

Back to the Ubuntu machine, I disconnected all other external usb devices and plugged the camera in using the same cable that just worked - still no sign of it. Ran dmesg and cannot find any hint of the camera or even of a failed attempt to connect to a usb device. (the dmesg file is attached, because I don't really know my way around linux boot logs and could easily have missed it).

Any ideas? Some Ubuntu update in the 4 weeks that broke the camera's ability to be seen? I do not know how to roll back the recent Ubuntu updates.

Ahh - interesting. It is almost as if extended full well mode is "super low conversion gain" mode.

I played around with EFW a bit last night, though without the benefit of your sensor analysis. I had set HCG + EFW and gain 100. With an f/6.5 scope on the Double Cluster, I tried various exposure times, up to 120s. At 120s I still had not saturated any pixels (max ADU ~58000). Of course I have no idea what the e/ADU is for the HCG/EFW combination.

Read More...

I do not have PI, so cannot run that type of sensor analysis. However, CN user Cbaxter ran a a sensor analysis in Sharpcapsensor analysis in Sharpcap . and those results are consistent with analyses from other brand 571 cameras