A small, affordable computer with free resources to help people learn, make things, and have fun
https://www.raspberrypi.org/forums/
https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=43737
rew wrote:Here is a picture that my raspberry pi camera took of it's own cable and raspberry pi....
Well. if it sounds to good to be true...jamesh wrote:I am completely amazed that that works. Are the images particularly noisy compared to the short cable?
What’s your point? to be sure, the black part under the green part is the connector.cjsm74x wrote:Well. if it sounds to good to be true...jamesh wrote:I am completely amazed that that works. Are the images particularly noisy compared to the short cable?
OK,my mistake. I was under the impression that it was the backside of a camera board.towolf wrote:What’s your point? to be sure, the black part under the green part is the connector.cjsm74x wrote:Well. if it sounds to good to be true...jamesh wrote:I am completely amazed that that works. Are the images particularly noisy compared to the short cable?
I think is this anyone that can confirm?sharix wrote:Woohoo!rew wrote:We've tested about 4m. Works fine.
Pictures coming soon.
What type of cable did you use?
From my experience decoding the RAW camera output, I see that the GPU code includes strong noise reduction. So if the noise pattern from extended cables is single pixel dropouts- even a fairly large number of them- you may never see it in the final output, due to noise reduction algorithms smoothing it out based on neighboring pixels.mikerr wrote:HAve you tested that PCB/cable with a longer (10min+) video capture, no dropouts ?
MIPI CSI-2 goes over this cable, correct? Which is serial digital with no error detection or correction? So it is either going to work or not, and any errors in transmission due to cable/connector problems are going to lock things up. Which seems to be just what happens whenever I touch the camera module wrong. It locks up and the software (raspistill, etc) no longer responds, although Linux is still otherwise running fine. I suppose the driver is written primitively as regards errors and doesn't even reset the camera hardware when starting.jbeale wrote:So if the noise pattern from extended cables is single pixel dropouts- even a fairly large number of them- you may never see it in the final output, due to noise reduction algorithms smoothing it out based on neighboring pixels.
That is indeed the cable/kit we designed, tested, and are selling right now!mlaporta wrote:I think is this anyone that can confirm?sharix wrote:Woohoo!rew wrote:We've tested about 4m. Works fine.
Pictures coming soon.
What type of cable did you use?
Something like that. When we first got it working, we played with it for about 15 minutes. I just held the camera module in my hand while filming, and we didn't experience any errors.mikerr wrote:HAve you tested that PCB/cable with a longer (10min+) video capture, no dropouts ?
No, don't think it works like that. There is some error recovery I believe, which I think is done in the HW - there is a HW interface layer between the raw CSI and the GPU drivers. This does all the hard work, so the drivers are written to this interface - means we can make simpler camera drivers, and HW layer also insulates between CSi-2, CCP2 etc.rkinch wrote:MIPI CSI-2 goes over this cable, correct? Which is serial digital with no error detection or correction? So it is either going to work or not, and any errors in transmission due to cable/connector problems are going to lock things up. Which seems to be just what happens whenever I touch the camera module wrong. It locks up and the software (raspistill, etc) no longer responds, although Linux is still otherwise running fine. I suppose the driver is written primitively as regards errors and doesn't even reset the camera hardware when starting.jbeale wrote:So if the noise pattern from extended cables is single pixel dropouts- even a fairly large number of them- you may never see it in the final output, due to noise reduction algorithms smoothing it out based on neighboring pixels.
One thing that can cause this is the micro-flex connector "J2" between camera module and camera PCB (visible at upper left in this photo). Several people have reported it being loose, and fixing it by removing and re-installing.rkinch wrote: Which seems to be just what happens whenever I touch the camera module wrong. It locks up and the software (raspistill, etc) no longer responds, although Linux is still otherwise running fine.
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.jamesh wrote:Don't know why your camera locks when you touch it - I've never had that problem.
I will try to do that tomorrow. The pictures are still on the camera, the camera is in my office, and I am at home.sharix wrote:TommyboyNL: could you post a picture of all the components included in the package?
