dFrameNumber in the firmware

[931436690]

Hi,
I think dFrameNumber of DAQ should sending 3 bytes. 2 bytes of dFrameNumber, sending from DAQ to PC software, has max number, 65535. When camera using more than 36 minutes, 2 bytes of dFrameNumber will lead to the negetave number of dropped frames, for example -65528.
I suggest to modify the firmware code like this:

                else if (wValue == CY_FX_UVC_PU_CONTRAST_CONTROL) {
                	glEp0Buffer[0] = CY_U3P_DWORD_GET_BYTE0(dFrameNumber);
		glEp0Buffer[1] = CY_U3P_DWORD_GET_BYTE1(dFrameNumber);
		glEp0Buffer[2] = CY_U3P_DWORD_GET_BYTE2(dFrameNumber);//adding one byte
                	CyU3PUsbSendEP0Data (3, (uint8_t *)glEp0Buffer);//three bytes sending
                }

[ximion]

Admittedly, I haven't looked very closely at this yet, but I don't think this solution would work since the contrast control value, according to the UVC specification, is a 2-byte unsigned integer and therefore has a maximum value of 65535 (unlike, for example, the exposure time control which is 4-byte unsigned).

Because it's unsigned though, I wonder how you actually got a negative number out here....

[931436690]

Yes, it doesn't work, I just test it. We should change another way to send a large number.DFrameNumber seperates to three byes, sending twice , like the bno data. That should work. Next time, I will make sure the result first, then give the solution.The second byte of CY_FX_UVC_PU_GAMMA_CONTROL should be an option,
I 'm testing now.
DAQ firmware changing code like this:
else if (wValue == CY_FX_UVC_PU_GAMMA_CONTROL) {
// Handles external trigger
CyU3PGpioSimpleGetValue(TRIG_RECORD_EXT,&GPIOState);
glEp0Buffer[0] = GPIOState;
glEp0Buffer[1] = CY_U3P_DWORD_GET_BYTE2(dFrameNumber);
CyU3PUsbSendEP0Data (2, (uint8_t *)glEp0Buffer);
}
QT software changing code like this:
*daqFrameNum =(cam->get(cv::CAP_PROP_GAMMA)/256)*65536 + cam->get(cv::CAP_PROP_CONTRAST) - daqFrameNumOffset;

QT software is calculating like this：
vidDisplay->setDroppedFrameCount(*m_daqFrameNum - *m_acqFrameNum);
After camera running more time, larger than 36 minutes, m_daqFrameNum from DAQ sending to PC software will become 0 again, m_acqFrameNum of PC software is like 65535, then we will get a negative number at the miniscope interface.

[daharoni]

This is one of many reasons why I am working on moving away from using UVC and instead working on implementing a more generic USB protocol. Will use the USB control channel for configuring the DAQ and Miniscope and a Bulk transfer endpoint (very similar to UVC) to transmit imaging data. Bulk transfer packets, and therefore, frames will be accurately timestamped.

I am also working on a methods for synchronizing multiple DAQs over USB so all incoming data will be accurately timestamped.

Hoping to have something running in the next week or two.

[931436690]

I'm looking forward to hearing good news. Without the affect of UVC control, we can get stable timeStampes.

[ximion]

I've actually fixed this in 6c9596c - by using UVC_CT_EXPOSURE_TIME_ABSOLUTE_CONTROL you should get frame numbers which can go a lot higher than before :-)