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.

Camera Bus SERDES

Other Parts Discussed in Thread: SN65LV1224B, SN65LV1023A

Dear All

I am facing some problems with my camera bus.

My camera bus is an 8 bits pixel data with 2 synchronizations lines (horizontal and vertical clock), in other worlds I have 10 bits bus with a pixel clock between 10 and 60 MHz. the distance between the camera and the processor is 2 meters. That’s why I need to serialize my data

So I found the SN65LV1023A/SN65LV1224B serdes that match perfectly with needs

I still have many questions about that component:

Ideally I am looking to have an autonomous serdes system, capable to auto synchronize between them and to start crush data when they are ready. My question is about the SYNC1/SYNC2 … did they need to be driven with specific sequences? For the Deserializer   do I have to look the Lock signal or it is just for information??

Do you have any application notes about? the schematics of the evaluation board? Is it possible to have the evaluation board?

What about the life time of those components??

 

Looking forward to have your help and your comments

Feel free to propose other references

 

 

  • Hi Ziad,

    The SN65LV1023A and SN65LV1224B are the right combination of SerDer devices for you application. The SYCH pins do not need to be driven by any certain sequence. The serializer / deserializer can operate autonomously and auto synch in a couple of different ways:

    1. The sync pins on the SN65LV1023A needs to be toggled forcing the serializer to send 111111000000, allowing for only ONE 10 transition within the first twelve bit frame.
    2. A custom pattern can also be used upon start up as long as the first twelve bits only possesses a single 10 transition.

    Either of these action will cause the devices deserializer to lock.Attached is an application report with some schematics for you to review:

    7633.SN65LV1021SN65LV1212- SN65LV1023SN65LV1224.pdf

    Regards,

    Mike

  • Hi Micheal

    Thanks for your reply.

    i think now i understand well how those two components work ...

    my next issue that my camera bus is under 2.8 Volts logic,

    so for the serializer side is ok since the hight level voltage is 2.0Volts ... but for the deserializer do you have any idea ? since the deserializer output is 3.3Volts and my bus is under 2.8 Volts

    so do you have any other idea other than using buffers (or other refferances that can accept 2.8Volts Vcc)?

    best regards

  • dear Sr.

    i have a quetsion how to conect Sync1 and Sync 2 : i pull them down ? or what i have to do ? since in the datasheet they recomand to conect him to the deserializer Lock, i my case is not feasible since the deserializer is far away 

    another issue the deserialiser RefClk at 20Mhz is ok regardless of the pixel clock frequency, am i right ?

    best regrads

  • Hi Ziab,

    Today I did an experiment where I dropped VCC below the recommended operating condition to 2.8V to see if the output of the de-searilizer could be decreased. I was able to achieve the bus voltage of 2.8V by doing this but again it was outside of our recommended operating conditions listed in the datasheet. What I can recommend is that you use a voltage translator on the output of the SN65LV1024B that will convert the output voltage of the de-searilizer to an acceptable voltage level for you.

    For sync 1 and sync 2 you want pull them both low to enable the output of the serializer, this is stated on page four of the datasheet. Since you are going to be remote you will need to find a way to guarantee lock by either toggling a SYNC pin via a uC (or some other scheme) or by sending a data pattern to start data transmission that consists of only one 10 transition.

    As long as your de-searilizer clock is within the specified operating region of the clock (10-66MHz; LVTTL Levels) you will be OK.

    Regards,

    Mike