QHY294C Live stream delayed response with USB2

QHY294C Live stream delayed response with USB2
« on: May 25, 2020, 03:02:48 PM »
I am trying to write a program that will focus my telescope using a live stream from my QHY294C.  I can only use USB2. This issue I have is that when I command the focuser to change position it can take several seconds for the live stream from the QHY294C to show the change in focus.  This is also true if I command the mount to move.  The live stream will take several seconds to show the movement. I want the live stream to be fast so I am using a Region Of Interest that is roughly 1/2 of the full image. I am also binning the image 2x2.

-I have tried to turn off DDR memory usage but I believe this ability is not available for the QHY294C. Is this true?

-I have experimented with increasing the USB Traffic which can make the live stream quicker to respond but this seems difficult to repeat. I need to always be certain that the image delay is minimized.

-I have also noticed that sometimes the image will jump erratically.  I suspect this happens when the camera fills the DDR memory and has to wait.

-I suspect that the camera is able to take several images and save them in the DDR memory at a rate that is faster than I can read them using USB2.

What are your suggestions for reducing this image delay and the image jumping erratically?

« Last Edit: May 25, 2020, 03:07:48 PM by pmwolsley »

Re: QHY294C Live stream delayed response with USB2
« Reply #1 on: May 25, 2020, 04:42:44 PM »
I did some more testing today and I believe there is an issue when using Live stream that can be easily fixed. Here is my understanding of the problem.
When using Live Stream there are two significant time delays 1)The exposure time chosen for the Live Stream 2)The data transfer time from the DDR memory to the program requesting the image. When using USB2 there is a more significant time delay involved in data transfer.  This data transfer time can easily become larger than the exposure time.  When this happens the images taken by the camera are queued up in the DDR memory.  This is a good thing because there may be other programs running that cause random delays. In these cases the DDR memory can help avoid losing  Live Stream images.

But when the fastest data transfer time is always longer than the exposure time this causes the DDR memory to fill up.  This results in the delayed response because we are only able to retrieve the oldest image.  This also causes the image stream to become erratic because, if the DDR memory fills up, the camera will not save the images until the data transfer is able to free up DDR memory.

In my specific instance I have found that the 2x2 binned image of a Region Of Interest (ROI) takes 215mS on average to be transferred and processed, at USB2 speed, from the camera to my program.  The solution I have found is to used an exposure time that is greater than 215mS...say 250mS.  My program is able to perform the data transfer and process the image in less than 250mS which means that the DDR memory never gets a chance to fill up.  The result is that the Live Stream is now smooth, with no erratic images and the images respond immediate when I focus or move the mount.  I have also experimented with using large values for UsbTraffic but they did not change the situation.  They may have slightly increased the data transfer time but I'm not convinced.

The huge downside to this is that I now need to use 250mS exposures.  I have always been using 200mS or less exposures but today I pushed this up to 300mS and discovered this fix.  Longer exposures can be a problem if the image saturates. I am typically trying for focus on bright stars which easily saturate. I thought of a simple solution that QHYCCD would need to implement...

Right now, when one image is ready, the data is saved either to DDR or sent via USB and the next image immediately begins exposing.  If QHYCCD could provide a DELAY parameter that would cause the camera to wait for DELAY milliseconds this would allow me to use shorter exposure times to avoid overexposed images and prevent the camera from filling it's DDR memory which causes the Live Stream delayed response.

« Last Edit: May 25, 2020, 04:46:23 PM by pmwolsley »

Re: QHY294C Live stream delayed response with USB2
« Reply #2 on: May 25, 2020, 08:25:20 PM »
    Yes,you are right,the DDR can store image data to avoid drop frames.And traffic can adjust FPS,make you can setup a suitable FPS for your PC.And BIN and ROI can decrease image data transfer every times to make transfer time less.But all of these parameters is more suitable for USB3.0,USB2.0 rate is too slow,too slow rate will make these parameters can't get ideal result.
    And which version SDK and system driver do you use?
Best Regards,

Re: QHY294C Live stream delayed response with USB2
« Reply #3 on: May 26, 2020, 09:01:02 AM »
Thank you for your reply  USB2 is much slower than USB3 but to update to USB3 is very difficult because all of my hardware is USB2 (Focuser, USB-RS-232C, Arduino UNO and NANO, QHY5II-M).  The update rate I am experiencing is acceptable for me but the delay caused by the accumulation of images in the DDR is my biggest problem.
The qhyccd.dll version date is 2020.02.28.  I have downloaded the latest version 2020.05.22 and will test using it today.  I believe the extra delay achieved using the USBTraffic parameter is very small.  Can you tell me how much delay is achieved using the maximum (255) value for USBTraffic?

Do you think that Single-Frame stream mode would be able to update my program at the same data transfer rate?  I could change my program to wait until an Single-Frame exposure is complete and then download the image.  I could then request the next exposure and perform any calculations I need to do in my program while the camera is exposing.  When the calculations are done I could, once again, have my program wait until an exposure is complete.  If the data transfer rate using the single-frame stream mode is the same as Live-Frame stream mode then I believe this method will eliminate the delay caused by the accumulation of images in the DDR.


Re: QHY294C Live stream delayed response with USB2
« Reply #4 on: May 26, 2020, 02:59:52 PM »
I have been experimenting with Single-Frame stream mode for my application. In order to get a continuous update of single frames I have my program waiting until the exposure is done and then reading the image.  Then the program immediately asks the camera to begin another exposure.  This method seems to cause my program to immediately crash.  I believe that reading the single-frame image and then immediately asking for another single-frame causes the crash.

The two functions are:
If I call them with no delay then the QHY294C driver hangs. Is there a better way to accomplish this?


Re: QHY294C Live stream delayed response with USB2
« Reply #5 on: May 26, 2020, 08:36:05 PM »
    I tested QHY294 16bits mono live mode with SharpCap3.2 via USB3.0 and USB2.0.For USB3.0,when I setup traffic to be max value(255),its FPS will decrease to 1.5~1.8,DDR on or OFF will get same result.For USB2.0,when I setup traffic to min value(0),its FPS is 1.8~2.2,but its transfer is not stable,its frame rate will have drastic change,sometime its FPS will decrease 1.1.And with USB2.0 it also will effect image data,make image occur shift issue.
    For Single Mode,you need run ExpQHYCCDSingleFrame after GetQHYCCDSingleFrame has run completely,before that,can't run ExpQHYCCDSingleFrame.
Best Regards,

Re: QHY294C Live stream delayed response with USB2
« Reply #6 on: May 27, 2020, 11:30:59 AM »
Thank-you for your testing.  For my live stream activities I am using the QHY294C in 8 bit mono mode and binned 2x2.

When I tested using the SIngle frame mode I can confirm that I have my program executing GetQHYCCDSingleFrame and once this returns it's data I then run ExpQHYCCDSingleFrame. I may need to insert some kind of time delay.  I suspect that when trying to quickly take single frames using USB2 there may be an issue of some kind.

Re: QHY294C Live stream delayed response with USB2
« Reply #7 on: May 27, 2020, 08:33:50 PM »
    When I use USB2.0 cable and USB2.0 port,and setup camera work on 8 bits mono mode BIN 2X2 with traffic max value(255),its FPS is about 0.6.

Re: QHY294C Live stream delayed response with USB2
« Reply #8 on: May 28, 2020, 03:07:45 PM »
Can you list the SDK calls you are using?  I just can't figure out how to run the QHY294C in Single frame mode and taking pictures quickly.  Maybe just list the C code you are using.


Re: QHY294C Live stream delayed response with USB2
« Reply #9 on: May 28, 2020, 08:10:18 PM »
    Here is the list of default call list,it include necessary parameters setting,if you want setup other parameters,you need do it before setup expose time:
ret = InitQHYCCDResource();
num = ScanQHYCCD();
ret = GetQHYCCDId(i,id);
camhandle = OpenQHYCCD(id);
ret = SetQHYCCDStreamMode(camhandle,0);
ret = InitQHYCCD(camhandle);
ret = GetQHYCCDChipInfo(camhandle,&chipw,&chiph,&w,&h,&pixelw,&pixelh,&bpp);
ret = SetQHYCCDResolution(camhandle,0,0,w,h);
ret = SetQHYCCDBinMode(camhandle,cambinx,cambiny);
ret = SetQHYCCDDebayerOnOff(camhandle,true);
ret = SetQHYCCDParam(camhandle,CONTROL_WBR,20);
ret = SetQHYCCDParam(camhandle,CONTROL_WBG,20);
ret = SetQHYCCDParam(camhandle,CONTROL_WBB,20);
ret = SetQHYCCDBitsMode(camhandle,16);
ret = SetQHYCCDParam(camhandle,CONTROL_EXPOSURE,2000000); // set exposure time, unit for microseconds
ret = ExpQHYCCDSingleFrame(camhandle);
uint32_t length = GetQHYCCDMemLength(camhandle);
ImgData = (unsigned char *)malloc(length);
ret = GetQHYCCDSingleFrame(camhandle,&w,&h,&bpp,&channels,ImgData);
ret = CancelQHYCCDExposingAndReadout(camhandle);
ret = CloseQHYCCD(camhandle);
ret = ReleaseQHYCCDResource();
    And here is a manual of QHY SDK API,you can check it.
Best Regards,

Re: QHY294C Live stream delayed response with USB2
« Reply #10 on: May 29, 2020, 11:22:17 AM »
Thank-you for your SDK call list.
I want to operate my QHY294C at unity gain.  I want to ensure that 1 count = 1 electron.  I am not sure what settings are required for this.  I have searched thru this forum and found a post that indicated that unity gain =1600.  Is this correct?

Also I know that the QHY294C has three whitebalance parameters.  In your SDK list they are to be set to 20.  When I use the InitQHYCCD call they are initialized to 16.  What values for CONTROL_WBR, CONTROL_WBG and CONTROL_WBB should be used to achieve unity gain?

Referring to your SDK call List I was able to get my program running in Single frame mode.  The update rate is very slow compared to Live frame update.  My system includes a 7-port USB2 HUB with multiple devices connected.  It may be that the USB2 port on my computer may not be capable of full USB2 speeds.

When I use Single frames the update rate is 1,200mS.  When using Live frames my program can update at a 215mS rate.  Ideally, I want the fastest updates so I will not consider using the Single frame mode. I have also discovered a trick for getting around the DDR memory lag. If I start with an exposure time that is larger than 215mS (I chose 250mS for my testing) the update rate will be 270mS and the video will be smooth and responsive.  If I then try changing the exposure time to something larger the update rate will follow this increase with no delayed response.  If I try to use an exposure time that is faster than 215mS then I will see the same 215mS update rate...but also the delayed response and frequently the video will jump as if frames are missing.  I think this is the effect of the DDR memory becoming filled.
So the trick is to identify the update rate for very fast exposures...this identifies the minimum exposure time to choose.  As long as you never choose an exposure time that is close to, or lower than, the minimum exposure time for your system you should be able to avoid this delayed response issue.  I did find that if you set the exposure lower than the minimum exposure time and then raise the exposure time above the minimum exposure time that this will not eliminate the delayed response.  When this happens I found that by sending a SetQHYCCDResolution command with the same parameters will cause the camera to clear it's DDR buffer and the delay response is immediately gone.

My program displays the image in a 640 x 512 pixel window.  I am requesting a 1280 x 1024 ROI binned 2x2.  My program then rescales the image to 640 x 512 for display. I am going to change this so that my program requests a 640 x 512 ROI binned 2x2.  This should require roughly 1/2 the update rate which should be ideal.  Hopefully the smaller ROI will not be an issue.  I am strictly using this program to look at stars in order to focus the QHY294C.  I use the 2x2 binning so that the QHY294C returns a monochrome image.

Thank-you for your attention and please respond to my unity gain questions.

« Last Edit: May 29, 2020, 03:35:46 PM by pmwolsley »

Re: QHY294C Live stream delayed response with USB2
« Reply #11 on: May 31, 2020, 08:34:47 PM »
    About RGB gain and gain,RGB gain is digital gain,it used to adjust white balance,and gain is analog gain,it used about overall adjustments.And RGB gain and gain have a congruent relationship,a value RGB gain setting is same with Gain 1.But I don't know unity gain and the details about congruent relationship,I didn't test it.You can check this link,there are some graph about gain.You can check if it is you need.https://www.qhyccd.com/index.php?m=content&c=index&a=show&catid=94&id=9&cut=1
    Or you can contact my colleague,Cha,he maybe tested this.His email is cha@qhyccd.com.
Best Regards,