search

Aharoni-Lab / Miniscope-DAQ-Cypress-firmware

DAQ firmware for V3 and V4 Miniscope platforms
14 stars 8 forks source link

dFrameNumber in the firmware #5

Open 931436690 opened 4 years ago

931436690 commented 4 years ago

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 commented 4 years ago

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).

grafik

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

931436690 commented 4 years ago

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. negetive number

daharoni commented 4 years ago

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 commented 4 years ago

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

ximion commented 1 year ago

I've actually fixed this in https://github.com/Aharoni-Lab/Miniscope-DAQ-Cypress-firmware/commit/6c9596c86fb2f1a6494bda383a0e647df38e2674 - by using UVC_CT_EXPOSURE_TIME_ABSOLUTE_CONTROL you should get frame numbers which can go a lot higher than before :-)