TSER953: V3 Link PoC and Data for SER, Image Sensor, & IMU

Hello Lysny,

I have a few other questions I hope you can help me with as I bring this V3 Link design idea home.

• The camera modules we are using is from Leopard Imaging and has the OV12895 Image Sensor. The connector as is has four I/O pins - VSYNC, HREF, XSHUTDN, & STROBE. I am only concerned with making sure I have control over the Frame Sync and the shutdown. If I use only two of the GPIOs on the SER for VSYNC & XSHTDN, will that give me the frame sync I need? Or does the camera module need a straight pin to the FSIN on the image sensor?
• The IMU we are using alongside the camera module has I2C support. Should either the IMU or the camera module act as the Host and the other the Slave?
• If both the IMU and Image Sensor SDA & SCL are going into the single SDA & SCL Pins on the SER, how does this affect the setting choice on the CLK_OUT/IDX pin on the SER? Can both have the same address set by the choice of R-high/R-low setting of the IDX pin?

I hope these questions make sense! Thank you for your time.

All the best,

David

Hey David,

These are my answers to your questions:

1. Section 7.5.3 in the datasheet covers our frame sync support options! This should answer your question.

2. This is more of a question that your design team should be able to answer, but if I was designing this, I would make the Jetson the controller and the IMU and the camera targets. I would utilize the I2C passthrough with the SerDes to direct my communications to these devices. Please make sure that there are no identical I2C addresses used or make use of our aliasing feature to prevent I2C bus issues.

3. The IDX pin should be strapped to different values on the two serializers. Section 7.5.1 in the datasheet does a good job describing this!

Thanks,

Lysny

Hello Lysny,

Thank you for pointing me to the right areas in the datasheet for answers. I agree with your solution for the controller/targets. I read about the I2C passthrough and using the aliasing feature but got a little confused. I thought that's what it was saying, but I think I hit a little info overload and doubted my initial reading.

With the IDX pin, I have just few more follow up questions if you don't mind clarifying for me.

1. So if I have two 953's going into one 954, you're saying that each 953 should have a different value? For example, one 953 having the IDX setting #1 and the other setting #2 from the the IDX Config Table 7-9?
2. If so, what should the IDX pin on the DES 954 reference?

Thank you so much for your time on this and helping me!

All the best,

David

Hey David,

Understood! It can be a lot to digest at first!

By default the deserializers are assigned different I2C addresses than the serializers. So, the deserializer can be set to any of the IDX references. For the two serializers, yes, I would recommend setting one to setting #1 and one to setting #2.

In total the Jetson would communicate to the devices using these 7bit addresses: 0x18 for TSER #1, 0x19 for TSER #2, 0x30 for TDES. Note that the 7bit and 8bit columns are switched in the position in the datasheets. 

Thanks,

Lysny

Hi Lysny,

Yes, a lot to digest but I think it's all starting to click. Since we are still a start-up I have to do a lot of leg work at first to make sure our product is being built in the best way we can. It's a new-to-market AR device and we have the amazing fortune to have Northrop Grumman as our first client and buyer. 

A huge thank you for all your help with this!

I believe the I2C config is finally starting to make sense and I can see the the bigger picture coming together. I'll sketch out a flowchart today an see if there are parts that are still missing or not making sense.

Thank you again!!

All the best,

David

Great! Sounds good! 

Hello Lysny,

I am almost there with the overall design and just need a few more spots to confirm. I have two questions I hope you can help me with.

1. First is a question about the CLK_OUT function of the IDX/CLK_OUT pin. I understand that after the ID is registered the pin can switch over to a CLK_OUT and provide the External CLK_IN for linked components like the Image Sensor. My question is can the one CLK_OUT pin be the CLK_IN source for both the Image Sensor and the IMU at the same time as long as they can accept the same frequency?
2. The other question is about potentially needing more than just 4 GPIOs on the TSER. Does the V3 set-up allow for an I/O expander to be added on the TSER side? If so, it allows more potential control of the Image Sensor and IMU settings. It's not necessary in our design but curious if it is a viable option for the future.

Thank you as always for your time!

David 

Hey David,

1. This could potentially work, but the pin output is relatively weak. It can easily support one device, but for two it may need a buffer. I recommend testing this one out with the components that you plan to use. (Do let me know if it works in your system though!)

2. So the GPIOs are pretty flexible on how you use them as long as there are external microcontrollers / processors to control them. If you wanted to expand the GPIOs you could add a mux and adjust the sampling rate on your jetson to access additional values. The mux would need some sort of control which could be via GPIO or via another small microcontroller. 

Thanks, hope this helps!

Lysny

Thank you Lysny. Yes, this definitely helps.

I'll definitely use the CLK_OUT from the TSER for the Image Sensor's CLK_IN. The IMU, TDK's ICM42688, has a CLK_IN available but it's not necessary. Thought it would make it function better if it did have an external clock source. I'll experiment a little and see what works.

It looks like the 4 GPIOs will be sufficient, but I won't know until some more testing. Adding the mux and adjusting the sampling rate on the Jetson is a good solution and we should be able to fit it in if needed.

Thanks again for all your help! I really appreciate it.

David

Would TI's LMK1C1102 work as a buffer in this situation?

Hey David,

From a quick glance, the LMK1C1102 looks like it meets the basic specs for this application. Again, I would just do some testing and see which option gives you the most accurate IMU data. 

Thanks!

Lysny

Hi Lysny,

Thanks for double checking on the buffer. I just got the Development Kit for the IMU this week and going to start running some tests. I also go the FPD/V3 Evaluation Modules to start testing out. I'll let you know how it all goes over the coming the week.

Thanks!

David

Great thanks David!

Hello Lysny,

So trying to make the CLK_OUT/IDX link to both the Camera Module and IMU basically just started to get too complicated. I decided to use the link just for the IMU which will help get more accurate info from it. The Camera Module I'm using an external oscillator which works fine for it since I have the Frame Sync to use as well.

My next question is about the power voltage for the PoC. I read in the Application Report "PoC Design Guidelines" and it mentions that it's suggested to use a minimum of 10V supply over the forward channel. The initial design just has 5V supply with conversion to 1.2, 1.8, and 2.8.

Is it better to go up to 10V or 12V to lower current as suggested in the guidelines or it doesn't make that much of a difference by keeping it at 5V?

Thanks!

David

Thanks Lysny for the feedback. It definitely makes more sense now!

David