QHYCCD

QHYCCD LOW LEVEL (1) USB PROTOCOL WHITE PAPER

QiuHY

  • *****
  • 5000
    • View Profile
    • Email
Re: QHYCCD LOW LEVEL (1) USB PROTOCOL WHITE PAPER
« Reply #30 on: February 27, 2017, 07:36:37 AM »
reserved
Qiu Hongyun

QiuHY

  • *****
  • 5000
    • View Profile
    • Email
Re: QHYCCD LOW LEVEL (1) USB PROTOCOL WHITE PAPER
« Reply #31 on: February 27, 2017, 07:49:49 AM »
Data Readout (Video Streaming)


Different camera may have different readout method. There is two basic readout method. One is for video streaming and another is for single frame capture.

Video Streaming:
For the QHY5II series, QHY5III series, QHY COLDMOS camera. There is the video streaming mode. In this mode, the camera will send the data continuously to the computer if there is USB read request from computer. If there is no request,or computer cpu is slow or busy and cause the read speed slower than the input data rate, the camera will still running but it will cause the data buffer in the camera get full. And then the data send from sensor to the buffer will be lost . But sensor will not stop running, it is still keeping on running. This will cause the frame is not  holonomy. This frame should be regards a bad frame and need to be filter out.

Since the data comes in continuously, only the asynchronous usb transfer can handle this. synchronous usb read can not handle this because there is a time gap between two synchronous usb read. If this gap happen within a frame, It will cause pause of the readout. Since the camrea's buffer is very small(For QHY5II is 4KB and for QHY5III is more than 100kB) The data will fill full of the buffer and cause data lost. So it can hardly to get a good frame with synchronous usb read.

Since it is the continuous video streaming. You need to make a double buffer or FIFO to handle the USB data in. For double buffer, there is buffer A and buffer B. When data is put into A , you can read the buffer B. When data is putting into B, you can read A.  For FIFO, you need to set a FIFO which size is twice than the image size. And you can put data into the FIFO and another side you can readout the FIFO. Each readout is just one frame.

Now return to the  asynchronous usb transfer, the advantage is that you can start multiple USB request. For example, you can apply 100 USB asynchronous request at one time.  These requests will wait the data coming. When data fill one request, it will begin to fill next request. So there is no gap between two USB request.

And you can use "wait" command to wait one request end. For continuous streaming mode, when you find one request is end, you need to restart this request again. Then you will have unlimited usb request.

Here is an example to show this working flow.

Code: [Select]
memsize=100;
           
             //Generic 100 USB request
            for(int i=0;i<memsize;i++) request=new UsbRequest();
            //init these usb request
            for(int i=0;i<memsize;i++) request.initialize(qconnection,qEP);
            //start these request, maxium size is 16384bytes
            for(int i=0;i<memsize;i++) request.queue(xbuffer, 16384);

            while(onStreaming==1){

                qconnection.requestWait();         //wait one request end
                rx_byte=xbuffer.position();    // one request end. get to know how many data received in this request


                if(rx_byte== 5 ){......}                   //according the data size , do the different thing
                eles if (rx_byte==xxxx) {.....}
                else {.....}

                xbuffer.clear();                             
                request.queue(xbuffer,16384);  //restart this request
 

                x++;
                if (x>memsize-1) x=0;              //cycle and cycle

            }

The key point of above working flow is that, when you get one request end, you need to restart this request. This can guarantee there always 100 request in background to receive the data. If computer run this loop is faster than the data in rate, there is always empty request exist and the data can be send to computer continuously without data lost
 


Now next thing is how to find the image head. In continuous steaming it is very important to get to know where a new frame starting. Then you can copy the data after that to the image buffer. For double buffer, once you find a image head, you can switch the buffer to receive the image data. The working flow is :


detected a image head
switch buffer
copy data in this buffer


In most of QHYCCD, they are using four or five byte as the image head. So you can detect if there is such four or five byte in sequence.

But if check each byte of the image will cause heavy CPU loading. So we should not use this global checking method. And since after this image head. The camera hardware will send a packet end signal. So it will cause the usb request finished immediately after this four or five image head.

This means: The image head byte must be at the end of one USB request.

So that you need to check the end four or five byte of the data in one usb request data package. This will save a lot time.


For example, one USB request has 16384 byte(byte0.....byte16383). Just check the byte 16379,16380,16381,16382,16383. If this five byte is the same with the image head identity byte. It is just the image head.

Note: Sometimes you can find a short request data length, just it is four or five byte. You need to check if it is just the image head also.



Bad Frame Identity

Now next topic is how to identity one frame is a good frame or bad frame. The method is very simple. Just to count the total data length of each frame. For example, the image size is 1280*960 8bit. So the image size should be 1280*960bytes. If you find one frame data length(when not calculate the image head five or four bytes length) is just 1280*960. That should be a good frame. Any frame smaller or bigger than this size it should be a bad frame.

In most condition the bad frame has less data length than full image data length. The following two condition will cause this happen

1.CPU is busy or slow, cause the usb request paused to received the data. The camera buffer then get full and the data come later can not enter the camera buffer so some data lost.

2.The USB transfer meet the CRC error and cause some USB packet lost. (Normally the USB cable problem, USB socket contact problem, the power leak, strong EMI issue like the human static electricity, high power device switch on/off) will cause this.

In seldom condition, the bad frame is bigger than the full image data length. This is due to the image head packet is just lost due to above reason(cpu busy or CRC error). This chance is much less . But still possible happen. So please make sure you can well handle the bigger data length and avoid the buffer size not enough and cause the point exceed the buffer memory size.
« Last Edit: March 13, 2017, 10:03:22 AM by QiuHY »
Qiu Hongyun

QiuHY

  • *****
  • 5000
    • View Profile
    • Email
Re: QHYCCD LOW LEVEL (1) USB PROTOCOL WHITE PAPER
« Reply #32 on: February 27, 2017, 08:47:27 AM »
Data Readout (Single Capture)

Single Capture is much simple than the video streaming. You should know how much data length you can get for a single capture. Then you can start a synchronous or asynchronous usb request to get so many data.

Looks the asynchronous is still better than the synchronous.  Because in some camera and the QHY8L, QHY A series etc, There is no big image buffer. Although these camera can pause the CCD readout timing to wait the computer when computer is busy and it will not cause the data lost problem. But this pause time will generate the thermal noise in this pixel that it is reading and cause a white point. And it will cause other problem like some dark shadow after this white point.


Qiu Hongyun

QiuHY

  • *****
  • 5000
    • View Profile
    • Email
Re: QHYCCD LOW LEVEL (1) USB PROTOCOL WHITE PAPER
« Reply #33 on: February 27, 2017, 11:03:08 AM »
Firmware Download

The firmware of QHYCCD USB2.0 camera is HEX format. The firmware of QHYCCD USB3.0 camera is IMG format.


For HEX file. On linux you can use fx2load command
eg.
sudo fxload -t fx2lp -D /dev/bus/usb/003/016 -I 5ii.hex

Please note you must add the fx2lp parameter. Because the FX2LP version chip has 16kb RAM, The FX2 only 8kb RAM. Now most of our HEX is exceed 8KB.

if you have not find fx2load on the system (like android etc) You may need to write a function to download it in your software. Please refer to information of the FX2 HEX download on Internet. You can also take a look at the fxload soucecode.

For IMG file. You can write a function to download it. Please refer the information of FX3 IMG download on Internet. There is also some source code on github.

Before you download the firmware. The VIDPID is the VID/PID for bootloader. For example, the QHY5II series is 1618:0920. After download the firmware, the FX2/FX3 will re-enumeration and the VID/PID will become the one inside the firmware. For QHY5II series it is 1618:0921.

Once the firmware downloaded, The camera can not be downloaded anymore except you unplug the USB cable/power. Because the camera firmware has not include a bootloader inside.


« Last Edit: February 27, 2017, 11:06:24 AM by QiuHY »
Qiu Hongyun