This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DS90UB936-Q1: Bt656 stream with DS90UB936-Q1

Part Number: DS90UB936-Q1
Other Parts Discussed in Thread: DS90UB913A-Q1,

I am using DS90UB936-Q1 deserializer, , but facing an issue that the other side is DS90UB913A-Q1 transmitting BT656 (8 bit YUV)  in a RAW10 format.

Do we have a solution or alternate deserializer that could output RAW YUV over a MIPI CSI2 link , the issue is the microctonroller that we are suign can't decode BT656 video stream.

  • Hello Rajendra,

    This question has been answered multiple times on E2E previously. 913A->936 can not support BT656 because BT656 does not contain sync signals. Sync signals are required by the 936 in order to generate the MIPI CSI-2 packet structure. 

    https://e2e.ti.com/support/interface/f/138/t/784043

    Best Regards,

    Casey 

  • Casey,

      I read through those threads, We understand that BT656 doesn't require additional HSYNC and VSYNC .

    In this case the transmitting microcontroller in addition to sending BT656 sends discrete HSYNC/VSYNC digital input to 913A serilaizer.

    On reception side the HSYNC and VSYNC are received , will the deserializer in this case convert the received Data to CSI2 and forward to SOC

  • Hello Rajendra,

    Ok, so can you describe in more detail what problem you are seeing here? Have you set register 0x70 to match the expected data type for your video?

    Select the desired RX port with 0x4C

    Set 0x70 = 0x1E for YUV422 8 bit 

    or 

    Set 0x70 = 0x18 for YUV420 8 bit 

    or 

    Set 0x70 = 0x1C for YUV420 8 bit chroma shifted

    Best Regards,

    Casey 

  • Casey,

      The Issue is that Serializer input is a BT656 (YUV) Stream with EAV and SAV fields.

    We wanted to understand  , if HYSNC and VSYNC pulses are sent along with BT656, Will De-Serializer construct the CSI-2 packets using the external HSYNC and VSYNC?

    The assumption is that Since the SAV , Blanking and EAV fields are during the HSYNC , they will simply be ignored by 936 while constructing the CSI packet and the same applies to VSYNC.

    If this is the case, we could look into register configurations/VSYNC/HSYNC adjustments.

    The register 0x70 is configured to 0x1E and RX port is set to 0x4C .

  • Hello Rajendra,

    If HSYNC/VSYNC are sent along with the data, then it can work. The HSYNC and VSYNC signals are used to generate the CSI-2 packet structure. There should be no configuration needed for this. What issue are you seeing?

    Best Regards,

    Casey 

  • The Output is being fed to a CSI 2 Peripheral of a Qualcomm 6150 Microcontroller.

    We are getting a Image front end overflow error, Initially we were suspecting if the BT656 encoded stream was being sent on the CSI-2 packets , It is now clear that only YUV 4 22 raw packets are part of the CSI 2 packets.

    We will now look into whether the VSYNC and HSYNC pulses are synchronized with the BT656 packets sent , Do you have any suggestions or areas we can look into

  • Hello Rajendra,

    I would suggest taking a look at the DS90UB936-Q1 registers for the RX port which is attached to your camera. Specifically 0x73-0x76 which show information on the received line count and line length. You can check those during operation to see if they meet expectations.

    Also, you can map out frame valid and line valid signals to 936 GPIO which is described in the datasheet. This will allow you to probe the sync signals for the incoming video to help diagnose any issues

    Best Regards,

    Casey 

  • Casey,

       Thanks for the support, We are able to get the feed after increasing the resolution to 1280*960, the register read confirmed 935 lines, closing the issue.

    Also can you add an note on datasheet that giving HSYNC/VSYNC enables compatibility with BT656 feed and that CSI packets could be constructed this way for 913/936 pair?

  • We are facing a minor issue. We could see a green patch at the end, as told earlier, we see 935 lines from de-Serializer, we are checking with i.mx6 input as well in parallel( we suspsect a wrong video configuration), but wanted to understand if there is a possibility that de-Serializer does a pass through of the data during VYSNC instead of sending CSI-2 Blanking packets?

  • Hello Rajendra,

    Your analysis is correct. If video lines are sent during the vertical blanking period (HSYNC still toggling while VSYNC is low), then this will be forwarded as additional lines after the FE packet, and the data type will be the same as the active video that you configure in register 0x70. That is most likely what is happening here, and this is a somewhat unusal implementation since BT.656 doesn't typically include HSYNC/VSYNC signal separately. 

    I can see two ways around this:

    1. Consult with NXP if the HSYNC signal can be held low during the vertical blanking interval 

    2. Adjust the CSI-2 RX SW to ignore video lines which are sent between FE->FS packets 

    Best Regards,

    Casey 

  • Casey,

     Thanks for the support, We will  try the workarounds suggested further to debug the issue or we could simply crop the unnecessary lines in application before displaying, The issue is resolved