Access to what exactly? just the USB communication specs? or code?

The low level protocol, and at some point access to their dev board (not sure what that entails).

I have a polemaster and can offer assistance with coding, but I'm not so sure about the NDA.

The Polemaster really is just a QHY5L-IIm. In fact, it works with the older QHY5LII ASCOM drivers just fine. Polemaster support was explicitly removed from the imaging driver, so I do not expect that we will get much cooperation from the maker on this. I guess what I'm trying to say is that there already is a INDI support for this should the support for the Polemaster be re-enabled in the binary blobs.

I just pushed an update to support QHY PoleMaster. PPA users can start testing by tomorrow's update. If you use GIT, pull now and test. Please report back results.

Fantastic
I will test it tomorrow evening, I'm using the PPA, so I'll have to wait

Thanks Jasem!

I tested the new build and initially had issues:
- needed GCC 5.x for qhy driver
- my polemaster was not receiving the firmware blob upload and thus was not being recognized by indilib

My polemaster is showing up as Bus 001 Device 006: ID 1618:0940
After loading firmware, it shows up as 1618:0941. I had to modify 85-qhy.rules to include 1618:0940. Disconnecting and reattaching the PoleMaster after making this change resulted in the firmware getting loaded and the device being recognized by indilib.

I found that I was getting about 1FPS while framing. I guess this is to be expected since I am using an Intel Edison which is a dual-core Intel @500MHz, plus I am connecting via WiFi.

I did notice a message about SQM while starting the server which I didn't notice prior to loading the QHY module. Is there perhaps plans to use the PoleMaster as a SQ Meter, because that would be a cool use for the device.

I attempted to enable compression and got about the same framerate from the camera... it turns out that the CPU was limiting.

I compiled on my pine64 and connected via GigE. Framerate was about doubled, however it appears that compression is single threaded.

I left the indi server up for 2 hours why grabbing frames continuously, and I did not experience issues.

Thanks for the test, I will relay this to QHY. I updated the rules file to fix the issue. For SQM, it can be done if someone works on the math and algorithm. I have a separate SQM LE device and I wanted the SQM reading to be in the FITS header.

The camera looks to take images just fine in INDI, is there something specific we should be testing out?

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.

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.

Which software should we use(modify) to make it working ? On windows, we can use the one provided by QHY.