• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 33 subscribers
  • Views 728 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

DS90UB960-Q1: Simultaneous I2C access to all FPD-LINK ports

DS90UB960-Q1: Broadcast Write Mode

Luis III Buno
Prodigy 90 points
Part Number: DS90UB960-Q1

Hi,

We are trying to use the broadcast write mode to synchronize the trigger of two identical sensors with TI 953 serializers connected to the TI DS90UB960 deserializer. The sensors don't have a functional hardware frame sync trigger for synchronization, but both are operating using the reference clock provided by the deserializer. We wanted to forward the stream of the two sensors in line-concatenation mode to our frame grabber, which doesn't support virtual channels.

However, even if we set up the broadcast write mode to send the i2c start stream command to the identical slave ID/alias of the sensors, the two still have an offset between their frame starts by ~800 us. The stream command sends a total of 8 bytes to the sensor. Is this offset expected in a broadcast write mode? Is the i2c write still being multiplexed to identical ID/alias addresses? Is there a way to send the i2c write at the same time?

Thanks.

  • 0
    TI__Guru** 108400 points
    Hello Luis,

    for using Line-Concatenation there are few requirements:

    1) Videos arriving at input ports should be synchronized within approximately one video line period
    2) All enabled ports should have valid, synchronized video
    3) Each port must have identical video parameters, including number and size of video lines, presence of synchronization packets, and so forth.

    That means you must have frame sync signal from the same source to both sensors.
  • 0 in reply to Hamzeh Jaradat
    Prodigy 90 points
    Hi Hamzeh,

    I updated my deserializer broadcast write settings to write to the sensor simultaneously with deserializer register 0x4C at 0x0F value.

    I configured the 960 GPIO to output frame and line valid signals from the two Rx ports and verified that they are within one video line period aligned. I also set-up the other GPIOs to output the frame valid, line valid and synchronized signals from CSI Tx port 0. However, the synchronization is still not achieved.

    The two sensors have identical stream format (RGB888), frame rate and frame size. The CSI Tx port 0 only shows frame valid signal for the first few video lines, and then the signal drops to ground. No complete frame was buffered and sent by the Tx port.

    I also tried RAW12 format from the sensors and I was able to get some frames transmitted but it was inconsistent. The synchronization and frame valid signals are interrupted in the middle of a frame randomly.

    Do you have any advise on what else to check to maintain synchronization?
  • 0 in reply to Luis III Buno
    TI__Guru** 108400 points

    Hello Luis,

    As I said, Frame sync signal is a must if you want to use synchronous modes. As I understood you are using only the back channel clock only to synchronize the serializers, but the imagers need to be synchronized using FSIN signal.

    So what you are seeing is at the beginning of the streaming the imagers are synchronized because of the used back channel clock, but after few mS there is not more synchronization that's why the Deserializer stops sending data out.

  • 0 in reply to Hamzeh Jaradat
    Prodigy 90 points
    Hi Hamzeh,

    The sensors are triggered at the same time using the broadcast write mode so they are actually synchronized within 1 video line. Also, they are driven by the same clock with the same frame rate so the synchronization should still be maintained throughout the stream. This is why we are assuming that this would still work with the synchronous forwarding mode of the deserializer. Another observation that doesn't make sense is that the Tx frame line are dropped after a random number of lines. If it is due to synchronization issue, it should also be at a specific line. Also, the synchronization actually recovers at random and a frame is transmitted. We are thinking that there might be other reasons why the lines are dropped in the CSI Tx port buffers during synchronous forwarding.

    In any case, we also tried out a different sensor with frame sync signal enabled. The frame sync signal is internally generated by the deserializer at ~30FPS, 10% duty cycle. In this scenario, we actually encounter the same behavior where the lines are dropped at random in the Tx port buffers. Could there be any CRC/ECC checks in the Tx port buffers that causes the dropping of the frame lines? Individually, the sensors work continuously without any frames being dropped during streaming with the same settings that we are using in the synchronous mode.
  • 0 in reply to Luis III Buno
    TI__Guru** 108400 points
    Luis,

    In the 954 reg 0x7C you can check if the frames are discarded if the line size or the frame size is changed. Also if the frames are discarded in case of Parity error.
    Please also read the following registers to see if the 954 is detecting errors:
    0x04, 0x05, 0x06, 0x36, 0x37, 0x4D, 0x4E, 0x55, 0x56, 0x57, 0x7A, 0x7B, 0xB9, 0xD0.
  • 0 in reply to Hamzeh Jaradat
    Prodigy 90 points
    Hi Hamzeh,

    There seems to be other requirements in the synchronization.

    I was able to get synchronized streaming without FSIN signal for 4 sensors. I checked the line valid signals and it showed that the gap between two lines is 16.6 us. This is running at 30 fps with line length = 4400. However, when I decreased the line length to 2200, I could no longer get synchronized streaming. The gap between 2 lines is now ~2 us.
    The frame rate also changes to 60 fps. But I don't think this is a just a max data rate issue because the bits/pixel is the same and the product of line length and FPS is also the same (4400*30 = 2200*60).

    Is there a minimum line-to-line time gap for line-concatenated/interleaved synchronized streaming?
  • 0 in reply to Luis III Buno
    TI__Guru** 108400 points
    Hello Luis,

    the discussion is going in another direction now which is not related to the original question. Can you please close this ticket and open new ticket with proper title to reflect the content of the question?
    Thanks
  • 0 in reply to Hamzeh Jaradat
    Prodigy 90 points
    Hi Hamzeh,

    Ok, thanks for your support on my initial problem.

    I will open another ticket for this new problem.