Alternatives or replacements for camera flex cable?

[jamesh]

Don't know why your camera locks when you touch it - I've never had that problem.

Let me be clear that I'm not faulting the camera module here. By "touch" I mean actually making a lot of clumsy contact with the board conductors while awkwardly hand-holding it on a lab workbench instead of using a proper fixture. I would expect this to interfere with the signaling. One would not do this is a normal application. My points were (1) that this type of interference locks up the camera on the software level, so that something at some abstraction level(s) is not able to recover from noise or dropouts or interruptions in the signals, because only a reboot gets it running again, (2) dodgy cabling that is too long might exhibit the same instability, and (3) the signals are digital, so it is not like the analog pixels are being transmitted and digitized after traversing a long cable, so a longer cable is not going to degrade the images, if the digital signals get through, and if they don't, then one would expect to get lockup or other erratic response, not dropped pixels or other mild degradations.

Its very odd indeed that it locks completely. There are lot of hardware/software in the GPU to ensure that complete lockups cannot happen (you really don't want a mobile phone to lock up and require a battery removal to reset it!). So that makes me suspect the app itself, which does have a particular wait on semaphore which doesn't timeout (for some reason the timeout version of the semaphore wait was giving me inconsistent results, so I had to remove it)- it may be getting jammed there.

There again, the app is only meant as demo code, and not for production, so some issues are to be expected.

[TommyboyNL]

TommyboyNL: could you post a picture of all the components included in the package?

If you just order the kit, you'll get the following:


If you also order the ribbon cable with us, we'll turn it into this (lenth may vary ):

[sharix]

Thanks for the pics but the first link is broken
edit: is it maybe possible to provide different lengths of the thinner CSI cable?
With the right length of the middle cable, it could be shorter, maybe 5 cm or something. It would be easier to put it all in one enclosure then.

[fbutler]

Thanks for the pics but the first link is broken

I believe the broken link should be pointing at:

http://www.bitwizard.nl/rpi/dsc05254.jpg

There's also another photo at:

http://www.bitwizard.nl/rpi/dsc05253.jpg

[jamesh]

Thanks for the pics but the first link is broken
edit: is it maybe possible to provide different lengths of the thinner CSI cable?
With the right length of the middle cable, it could be shorter, maybe 5 cm or something. It would be easier to put it all in one enclosure then.

From a post Gert made earlier in this thread...

The cables can be bought from Toby UK.
This is the web page:
http://www.toby.co.uk/content/catalogue ... xx-A-xx-xx

The type required is FFC1-15-B150105160MM

[sharix]

I see they offer a 50 mm version, which would be ideal.
edit:
seems that the 15 positions cable only comes in one lenght - 160 mm.

[jbeale]

If you are looking for a shorter replacement for the stock CSI camera cable (15 conductor, 1mm spacing), here are a few.

Code: Select all

Molex 21039-0843  FFC / FPC Jumper Cables 1MM FFC JUMPER Opposite Side Contacts 6 in
Molex 21039-0841  FFC / FPC Jumper Cables 1MM FFC JUMPER Opposite Side Contacts 5 in
Molex 21039-0838  FFC / FPC Jumper Cables 1MM FFC JUMPER Opposite Side Contacts 4 in
Molex 21039-0836  FFC / FPC Jumper Cables 1MM FFC JUMPER Opposite Side Contacts 3 in
Molex 21039-0834  FFC / FPC Jumper Cables 1MM FFC JUMPER Opposite Side Contacts 2 in

Newark will sell you a 2-inch cable, qty.1 shipped direct from factory, but lead time is 84 days! http://www.newark.com/molex/21039-0834/ ... dp/91M3312

Parlex also make such a cable. http://www.parlex.com/tech_library/ps-2563.pdf
Digikey has a 2-inch long version, but only with "same side contacts": http://www.digikey.com/product-detail/e ... -ND/660127

For the second flex jumper cable needed for this extender assembly, I'm not sure if you need "Opposite Side Contacts" or "Same Side Contacts"

[TommyboyNL]

I fixed the URL.
For our extender, you will need a same-side and opposite-side flex cable. A next version will probably need two opposite-side cables.
I'll check if we can get shorter cables, but I'm afraid it will be difficult. I will post updates in this topic.

[jbeale]

If you do make such an updated extender assembly kit, is it true you could use either 2 same-side or 2 opposite-side jumper cables? Not sure if one is more commonly available than the other.

[TommyboyNL]

Yep, that should work. We think two opposite-side cables would be preferable, because everybody with a RPi camera already has one opposite-side cable. If you accidentally use the wrong cable, you might/can/will (I don't know, and don't really feel like testing this) blow up your camera and/or RPi.

[badgerpi]

A dumb question maybe, but...

Would it be possible to make extensions from Cat5 cable ?
That might make it possible to extend over longer distances and retain some noise immunity ?

[Burngate]

My thought is maybe.

At first sight, Cat5 hasn't enough cores - only 8, while the connector has 15.
But DN0 & DP0 down one pair, DN1 & DP1 down the next, CN & CP down pair 3, then GPIO & CLK fills up one cat5, using the screen for ground. A screened twisted pair (or another cat5) can carry SCL & SDA with the screen carrying 3v3 - those don't need to be so carefully timed.

So what's the data speed on the camera interface, and how does that compare to the capacity of cat5? We know as a rough ball-park cat5 handles 100Mb/s down each pair, and Gb is possible. But I haven't seen a spec for the matching between pairs - how closely do the pairs need to be matched time-wise?

The bog-standard RJ45 doesn't cater for the screen, so a different connector would be needed.

When I get my camera, I may try.

[jamesh]

1080p30 requires 622080000 bits per second at 10bpp, it's a two lane device, which halves the overall bandwidth per line = approx 311Mbits/s

I think.

[Burngate]

311Mb/s v. 100Mb/s
So it probably wouldn't get very far.
But it might

How closely do the two lanes have to be timed?

[jamesh]

311Mb/s v. 100Mb/s
So it probably wouldn't get very far.
But it might

How closely do the two lanes have to be timed?

Perfectly I would think.

[Burngate]

Perfectly, as in better than the 3ns that each bit takes? Which by my reckoning is a couple of feet of cable.
Obviously I haven't done my homework*, but if the GPU puts out clock pulses and expects the data coming back to be coincident with it, then we won't be able to go further than those couple of feet.
But if the GPU is looking at data transitions for timing, we can go alot further. And if it treats the lanes separately, only combining the data after de-serializing, we may be able to relax that <3ns.

Not that I want definitive information - trial-and-error looks like it might be more fun.

* "Sorry sir, the dog ate it / it got put in the washing machine by mistake / my sister put it on the bonfire"

[TommyboyNL]

If you want to use UTP, I'd suggest using two cables so you don't have to abuse the shielding. We might even try it monday, it sounds like a fun experiment.

[ffelagund]

I have found an interesting solution: http://65.36.150.178/products.cfm?Category_ID=7
I'll try to order some next week

[Gert van Loo]

You can find all the details in the MIPI DSI/CSI specification.
Of course I have one at my desk but I don't think it is in the public domain.

[badgerpi]

If you want to use UTP, I'd suggest using two cables so you don't have to abuse the shielding. We might even try it monday, it sounds like a fun experiment.

Will be interesting to see what's possible.

I suggested it on the basis that if the camera works over 3 or 4m using ordinary flat ribbon cable, then surely twisted pair should offer scope for even more distance...

[jbeale]

Considering that the MIPI CSI-2 standard is aimed at devices that fit in your pocket, being able to drive some meters of cabling is well outside the design goal, as far as I know. At the least I would expect higher power consumption due to the current needed to swing around the larger capacitance of a long cable, at those bitrates.

[Gert van Loo]

Considering that the MIPI CSI-2 standard is aimed at devices that fit in your pocket, being able to drive some meters of cabling is well outside the design goal, as far as I know. ......

I am astonished if it works. I would need to see a BERR before I believe it (See remark about pixel correction) Even if it works most of the time it is a credit to the engineers from both Broadcom (for building such a high quality receiver) and Omnivision (For building such a high quality transmitter).

[Burngate]

... due to the current needed to swing around the larger capacitance of a long cable, at those bitrates.

Probably stupid question ... the cable's a transmission line, so it doesn't matter what length it is, it just looks like a resistance?

[jamesh]

... due to the current needed to swing around the larger capacitance of a long cable, at those bitrates.

Probably stupid question ... the cable's a transmission line, so it doesn't matter what length it is, it just looks like a resistance?

Well, there is also the increased possibility of interferences from other lines in the cable, and external sources, as it also acts like an aerial.

Probably.

[Burngate]

Second stupid question: I assume there's no cable compensation in the SoC? - when I last used SDI, just about everything used a receiver with cable-comp built-in, but there it was assumed cable lengths could be up to 100m, and I doubt Broadcom would waste silicon on that