Banding and no more frames + ASCOM interface with QHY

[Simon_M]

Hi Robin

How do I get the QHY1785III-178M to work with SharpCap Pro?

I will eventually always get banding in the image after making any of these changes and the frames don't update (see the attachments):

1. Wait a few seconds;
2. Wait a few minutes;
3. if I change from MONO8 to MONO16.

I have tried a simple setup - I'm setting up QHY camera again to try to resolve some software issues:

1. Fresh install of Windows 10 on my laptop;
2. QHY driver;
3. ZWO driver;
4. SharpCap Pro 3.2;
5. SharpCap patch from QHY.

At this time I have no ASCOM, no WDM, no Broadcast and no other other astronomy apps e.g. PHD2, FireCapture etc.

The sequence (2), (4) and (5) are the recommended steps from QHY for their cameras - SharpCap is their preferred QHY piece of software.

I have tried SharpCap 3.1, 3.2, 3.2 64 bit with/without the SharpCap patch from QHY. All fail eventually the same way.

I'm using the QHY driver from the list of cameras.

If I add:

6. ASCOM;
7. QHY ASCOM driver.

When I start using it a dialog is displayed warning not to use the ASCOM interface and use the native interface. At the same time, the program then gets memory access violations. This suggests that QHY ASCOM interface doesn't work reliably.

I also have a ZWO ASI294MC OSC. If I substitute the ZWO camera it always works.

I read one of your earlier updates suggesting trying SharpCap Pro 3.1 - hence the reason to try it (as above).

I wasn't sure about using the SharpCap patch from QHY. It replaces DLLs in SharpCap directory. I found it will copy the same files to 32 bit and 64 bit folders - it can put them anywhere e.g. even my Documents folder or a clean folder: Program files/XXXX.

I'm getting the impression that there is no single QHYCCD.dll that works with all QHY cameras. The software will work with newer cameras but it doesn't continue to work with older QHY cameras. To try and fix this, QHY attempt to supple/replace the DLL with an older one from 2017. This also isn't very successful/stable.

I noticed that QHY ask you to download drivers/software for their individual cameras, but ZWO have just one set of drivers/software. So if ZWO have a problem they can update the driver once and after a regression test, use it everywhere. For QHY this becomes more difficult because they have to issue the fixes for each camera - I don't think they maintain software for older cameras. In some senses, ZWO seems a safer option when getting a new camera.

Simon

[admin]

Hi,

I have to admit that I see far more of this type of report from qhy owners than I do from ZWO users, even though I think several times more people use SharpCap with ZWO cameras that with qhy cameras

I personally don't recommend applying any of the QHY patches to SharpCap – when I release a version of SharpCap that has a new QHY SDK in it, I test with some cameras and make any adjustments needed to the SharpCap code. If you then go and put a different SDK DLL in, particularly an older one, who knows what will happen. If there is a new update to the SDK then I try to get a version of SharpCap out within about a week with that new update on it.

I think you are correct to say that the support for older cameras can get broken new updates, which is frustrating. I was testing with my 178C yesterday and was noticing intermittent problems with the picture breaking up into sections that were correct and sections that were obviously shifted sideways. This was something new to me and only seem to have an in eight bit mode..

If you are having problems with freezing then is certainly worth trying different values of the USB traffic control if you haven't already adjusted that and also simplifying your USB connection (single, shortish cable, straight back to the computer with no hubs or extensions).

I think the problem with the Ascom driver is that it also uses the qhy SDK DLL, and has its own version. However if SharpCap's version gets loaded first then the Ascom driver has to deal with a version that it isn't expecting and may crash. You may get better results if you restart SharpCap and select the Ascom driver straightaway without trying the native qhy support.

Cheers, Robin

[Simon_M]

I have to admit that I see far more of this type of report from qhy owners than I do from ZWO users, even though I think several times more people use SharpCap with ZWO cameras that with qhy cameras

I personally don't recommend applying any of the QHY patches to SharpCap – when I release a version of SharpCap that has a new QHY SDK in it, I test with some cameras and make any adjustments needed to the SharpCap code. If you then go and put a different SDK DLL in, particularly an older one, who knows what will happen. If there is a new update to the SDK then I try to get a version of SharpCap out within about a week with that new update on it.

I think you are correct to say that the support for older cameras can get broken new updates, which is frustrating. I was testing with my 178C yesterday and was noticing intermittent problems with the picture breaking up into sections that were correct and sections that were obviously shifted sideways. This was something new to me and only seem to have an in eight bit mode..

If you are having problems with freezing then is certainly worth trying different values of the USB traffic control if you haven't already adjusted that and also simplifying your USB connection (single, shortish cable, straight back to the computer with no hubs or extensions).

I think the problem with the ASCOM driver is that it also uses the QHY SDK DLL, and has its own version. However if SharpCap's version gets loaded first then the ASCOM driver has to deal with a version that it isn't expecting and may crash. You may get better results if you restart SharpCap and select the ASCOM driver straightaway without trying the native QHY support.

Hi Robin,

I originally bought a ZWO ASI178M as a guide camera. When I tried it with a Celestron OAG and Celestron 0.7X Reducer, I realised that the Celestron instructions showing a "standard" camera wouldn't work. I needed to reduce the back focus of the guide camera by 28mm and the COAG without an extension has only 14mm less. To get another 14mm (and the rest) my dealer exchanged the ZWO 178 for a QHY 178 MINI - ZWO don't make a MINI 178.

So that's how I ended up with a QHY guide camera. I also found out that the Celestron OAG is designed for EdgeHD 800 or a Reducer with a bigger EdgeHD. NB not an EdgeHD 800 and a Reducer. If I look into the COAG prism with the Reducer, I see a half moon out of the scope - not very scientific... but a half moon of a full moon is really only 1/4 the area. I setup a target and measured the guide camera through my scope and through the COAG and the exposure for the same 22% on the Histogram is just over 5 times. that's when I realised my COAG isn't going to work and I'm looking for a new one.

I picked ZWO because they are popular and there are few complaints. QHY also seem to have the edge on technology e.g. a heated window rather than excess heat recycled to the glass - which seems less scientific. Also QHY make a USB3 version of the 178 and ZWO have yet to make one. I realise that ZWO sometimes takes several iterations to get things right. However, I thought that QHY and ZWO have had long enough to get the 178 to work. There is also Altair here in the UK, but I've not been able to get through to ask about supplies. hence I'm with QHY.

With hindsight, I see lots of issues where you try to help out on the forum but ultimately for £350 the camera should work. I also don't like the patching that QHY have done. They take your DLL and replace it. If they know there is a problem then they use a driver that's 3 years old. I don't know why they don't just roll the updates into the current driver. If there are as many drivers as there are cameras then it's obvious that they may have trouble keeping up with fixes for fixes for every camera. I think ZWO have a better solution because they have only one driver across their cameras. Again with hindsight, picking cameras is as much about the hardware spec. as the reputation for the software stack.

The picture breaking up is what I start to see - my two images show how the last frame looks. It divides the screen into 9 blocks. Then it fixes itself and then you are back to 9 blocks. Only later will it freeze.

I don't have anything between my 2020 Lenovo laptop with USB 3.1 and the QHY 178 camera. I'm using the QHY USB3 lead. There are no hubs and of course I cannot power the camera independently. I'm going to add the ST4 lead tomorrow, I can measure on the other end the RJ12 the 5v supply. Since I can plug my ZWO camera in and use it unpowered, then I suspect the voltage is just fine.

Perhaps there is something I can look for in the logs. At the moment I think you trace out what happens as the camera is used. Have you ever thought of adopting a First Failure System Trace (FFST) - you get the trace data but keep it in memory. Then when a program traps or has an error condition, you write the trace out? Most of the time, the trace isn't needed until there is a problem. So you only get a trace leading up to a problem.

If the newer cameras break the older drivers, then providing the older drivers is only OK up to a point. If I take the QHYCCD.dll as an example for a guide camera (QHY5 Series use their own driver). I have a guide QHY camera that works OK (wish I did) with one version of the driver. Then I buy an imaging camera also from QHY. If the second camera uses a more recent driver that works with the new camera but not with the older one, immediately I've bought a two camera problem. Either I can use the old driver and accept that the new one won't work, or I use the new driver and accept that the old one won't work. It's one of the reasons I don't like the patch process.

I suppose I could run SharpCap 3.2 32 bit with one camera and SharpCap 3.2 64 bit with the second camera. Or try to run them in different shells with different paths to the separate drivers - all getting a bit too complex. Perhaps they only consider users who buy one of their cameras and then switch brands?

I have used the USB traffic control. I realise that 0 and 50 or 60 can mean different things. I'm using the defaults for both cameras but also varying the USB to see what works best. Of course ant some point I want to run them both together. I'm looking for the fastest frame rate or the least CPU overhead. My laptop is an AMD Ryzen 5 3500 with AVX and AVX2. It's loaded (quite lightly) at about 25% CPU.

My Windows 10 is a fresh install from a Microsoft ISO with the Lenovo drivers - there is no bloatware. I realised that after a laptop has been used with many Apps, the number of extra processing tasks that it has to take on increases. I don't have any of the optional Apps installed e.g. MS Office. To keep the CPU cycles down I also switch off MS Defender. I may try to uninstall it later.

I do own up to being a bit of a cheapskate. Most OAG users are probably using a ZWO ASI174M MINI and I was trying to "make do" with a ASI or ZWO 178 used with 2x2 binning. I know it can work really well. One issue with always trading up is your money disappears quickly e.g. a 174 is about £500 vs £350 for a 178. The 178 is also USB3 and is a back illuminated sensor so should (in theory) outperform the 174. 290s are too small for my OTA and FOV. Perhaps you know how a 178 from Altair performs? I always assumed that the SOC chipset does most of the work, so variations between ZWO,QHY and Altair are more about packaging than anything else?

You suggested that SharpCap 3.2 users should back off to SharpCap 3.1 if they are experiencing problems with QHY 178. Can I assume that the guidance from QHY to patch the driver should be ignored. Either way there are still problems. With a license for SharpCap Pro 3.2 I would naturally prefer to use the later version especially as I can't see you updating 3.1 again. Is the QHYCCD.dll useable from one release to the next?

Just for interest there is QHYCCD.dll and SharpCap.Cameras.QHY.dll are they doing the same or different tasks?

I realised that SharpCap loads a DLL and so if you switch from Native to ASCOM, then it may not reload the DLLs e.g. reload or close will not recreate the process again or they don't unload and then load a different DLL. For the moment I simply restart the application.

It's interesting that I get a dialog saying don't use the ASCOM driver if there is a native driver. Afterwards it will immediately have a memory exception. Does this also mean that the ASCOM drivers are not useable from other programs e.g. they won't work with any other Apps? It is early days, but the next program I will get working is PHD2 - I think this might also have a direct driver for ZWO or QHY and so not be using ASCOM.

I also don't want to use a shorter USB cable or a USB2 cable - I didn't buy the camera to use with the laptop attached to the scope or to limit the speed of operation. For guiding it may be OK but when used for "lucky shot" for planetary or lunar I want to use the available speed. I might try this just to see if it shows a difference but not for taking outside.

I think it would be helpful if driver manufacturers tested their software to not check that it works but rather to test to see that it doesn't fail. I've yet to find a program that works like this! I've asked my dealer to ask the importer to ask QHY how to fix things.

Simon

[admin]

Hi Simon,

I think that your problem the right track in trying to get a resolution for this issue out of QHY. I believe they have a customer support ticketing system on their website somewhere (they used to have support forums – maybe they still do?). The symptoms that you are seeing – frames that are corrupted and the camera stopping running do sound very much like USB related issues (dropped data, etc) that is well below the level that SharpCap works. The SharpCap code for QHY cameras (in SharpCap.Cameras.QHY.dll) talks to the qhy provided code in QHYSDK.dll in a fairly high level way – for instance SharpCap may ask the SDK to capture a frame and either expects to get back a valid frame or an error code. If there is no error code then SharpCap has no way to know that the frame data might be invalid. Similarly, if SharpCap asks for a frame with an exposure of one second and never gets a response, then it is very difficult to recover from that situation.

SharpCap has two level of logging which are recorded both in the log window and also written to log files on disk (the log file gets written out within a few seconds of the events happening, but asynchronously so as not to slow down the application). Normal logging records high level program flow, user interaction and any error occurrences. Detailed logging can be turned on using a checkbox at the bottom of the first page of settings and when this is enabled, much more logging information is produced including an almost complete log of communications between SharpCap code and SDK code provided by hardware vendors (such as qhy etc). This verbose logging is disabled by default to ensure that it doesn't affect performance. I believe that qhy also have a way to log the actions of their SDK to try and track down problems. It would certainly be worth you turning on this verbose logging (make sure you do this before you open the camera, otherwise it will not take effect). Once you capture the log, feel free to send it to me – ideally along with some info detailing at what times you saw the particular problems so that I can try to match up any events in the log at that point in time with the problem.

Cheers, Robin

[Simon_M]

Hi Robin

I'm still waiting for a response from the dealer from the importer from QHY.

I do have a working solution if you are interested - see my new post "Getting QHY5 installed and working" for avoiding ASCOM and memory faults.

My laptop has two USB 3.1 ports. The first is always powered up and the second is powered only with the machine running.

1. With the 1st port, you can exit a program, reboot and the camera will remain powered up. I use this to see if there is a problem with an application running on the laptop. In this case the camera is no longer able to send frames and a reboot doesn't restart it. It IS NOT the application's fault.

2. So with the 2nd port, you can exit a program, reboot and the camera will be powered down and then when the OS is running, the USB is powered. I use this to see if the problem is with the connected device e.g. the QHY5 camera. It IS the cameras fault.

NB I do think there is a problem with my QHY5 camera - it stops sending frames unless power is recycled (and it is NOT the application's fault).

Simon

[admin]

Hi,

As I understand it, these cameras have an on-board processor that handles getting the data from the sensor and shuttling it to the USB system. I'm not sure of the software from this processor is stored on the camera is loaded from the PC, but it's certainly possible for this processor to have some sort of bug in its software and to glitch out or crash or just stop responding in the way that the PC expects. I've seen this on other camera brands too now and then. Sadly this seems to be common enough across the astronomy cameras market – if you wanted your cameras to be absolutely bullet-proof then they would need a lot more testing by the manufacturers and they'd never hit the sort of price points we have become used to. I suspect that a lot of cameras made by vendor is selling to the industrial sector are more expensive it is partly because of this sort of reason.

Glad you're getting there on tracking down the cause and on workarounds.

Cheers, Robin