Is this overlay still being maintained? I attempted to add it and layman complained. I tried doing a curl on the URL you have listed, and it returned an HTTP 404 response.
The qhy_ccd driver is indeed the correct one. The polemaster is effectively the same as the QHY5L-IIM.
The problem, however, is that the manufacturer is incredibly hostile towards any efforts to utilize the Polemaster as a capture device. For a while, the ASCOM capture driver for the QHY5L-IIM would work with the Polemaster, but the manufacturer found out about it and quickly revised the driver to explicitly disable Polemaster support.
You can attempt to add in the correct ProductID for the polemaster to match the QHY5L-IIM (1940 is PID for Polemaster if my memory serves, and 1921 is the 5L-IIM) What you'll find is a message that states "SDK no longer support camera" indicating that, indeed, functionality has been removed. It's a shame, really, the polemaster can thus 1) not be utilized within linux and 2) sits more or less useless on your polar axis during an imaging session. The maker could have capitalized on this by selling a c-mount/1.25" adapter and other accessories for aiding in repurposing the polemaster as an imager.
I was planning on buying a QHY5L-IIM as a guider to do away with needing to do it in software, but the maker's hostility towards those with technical prowess has left me looking elsewhere for my guider.
On the older Pi computers, if you overcurrent the USB, you'd either:
1) experience USB wonkiness
2) have the Pi lock up
3) experience an immediate reboot of the Pi
It was usually #3.
They used to use a thermal fuse which would eventually reset. It was a giant pain, sometimes plugging in a keyboard would reboot the Pi. I'm not sure about the current incarnations of the Pi, but one thing you could do is monitor the voltage on the USB bus. If it starts to sag, you are probably pulling too much power. I'd use a powered hub just to be safe.
What version is your gphoto2/libgphoto? Support for that particular camera was only solidified in the past few months, so older versions may still have issues.
There is certainly something odd about this camera when using longer duration. I tested with a pristine installations.
If you capture with a 1.0 sec exposure, the image downloads almost instantly.
If you capture with a 10.0 sec exposure, it takes about 11.5 seconds to download the image after exposure stops.
If you capture with a 15.0 sec exposure, the image downloads almost instantly.
If you capture with a 18.0 sec exposure, the image downloads almost instantly.
If you capture with a 20.0 sec exposure, the image never downloads and EKOS will just hang waiting for the data. Have to kill indiserver and the indi_qhy_ccd driver, as well as unplug and re-plug the polemaster to resume capture.
21.0 sec exposure is fine.
29.0 sec is fine.
30.0 sec bombs just like 20.0 sec did.
40.0 sec bombs just like 20.0 sec did.
50.1 sec took 52 seconds to download after exposure ended.
89.0 sec took 91 sec to download image.
93.0 sec worked fine.
118.0 sec worked fine.
It appears that multiples of 10.0 seconds will cause issues with the driver and/or camera. Getting close to a multiple of 10.0 sec can sometimes trigger a situation where it appears that a second image is captured and sent since the delay in downloading appears to be equal to the exposure time.
As promised, here is the code :
This is probably the dirtiest kludge I've ever performed. I simply took two projects and mashed them together, cutting out the need for USB->Arduino link. I need to test on RaspberryPi, but it is working on my Pine64.
Try at own risk, I'm not responsible if your OTA starts spinning wildly and your rig takes off like a helicopter.
Well, there isn't a "3rd party" driver for the canon, so to speak. From my understanding, canon_ccd is supported by the base INDI package. I always add in indi_gphoto_ccd when starting INDI and my Canon connects right up. I am using a 20D though. The only other thing that I can think of is 1) make sure the camera is not in PTP communications mode and 2) try using the [M]anual mode if you aren't already doing so.
Also, starting indiserver with -v or -vv may show more details, specifically which parameters are failing.
I think I had issues until I compiled the indi_gphoto_ccd 3rd party driver. Maybe try other USB ports on the Pi?
I managed to use the Polemaster as a guider in EKOS last night with my rPi GPIO ST4 implementation. I did run into an issue while attempting to use it for imaging. It appears to have problems when exposure times exceed 45sec or so, where images returned were just black and contained no data. It could have been a software issue on my end, I'll test again this evening with a pristine installation of INDI.
I get that about needing level shifters and optoisolators, etc. The software still needs to be there.
Do you have a listing of the capabilities of your AstroHat? Will it be able to send guiding via ST4, focusing, DSLR shutter control, etc?