Raspberry pi camera issue

0x4f525245 read "ORRE" when interpreted as ASCII. Whatever that means....

Read it backwards..

Erro(r).

Sounds like the routine is returning the pointer to the error message.

Good spotting!

Did anyone come up with a solution for this? I've bought over twenty cameras and have only a few that remain working. I teach kids, and they love using the pi's with the cameras, but it's getting way to expensive to keep the class going by replacing the cameras. I've researched a bit and have found the problem is not going away, and may be related to board resources/conflicts.

Anyone had any success with this?

You mean that you have say 20 identical raspberry pi's and 20 cameras and some have this issue? And when you buy a new camera, then the problem goes away (for a while)?

That would strongly indicate that there is a hardware problem, and not a software problem as I thought at first....

My instinct still tells me: check the boot configuration that you allocate enough memory to the GPU so that it can handle the camera properly....

What I am saying is that I purchase raspberry pi's for education, and I have well over twenty pi's, of all makes and models... and I have purchased over twenty cameras over the past two years. Since kids handle the cameras and the Pi's, I absolutely expect a breakage rate... and since the Pi's and cameras are not humongously expensive, that's OK. But the cameras are failing at a >%50 rate, meaning every year I have to re-purchase 5-10 cameras. What makes me more suspicious is that the cameras I handle are breaking at about the same rate as those the kids use. The problem follows the camera, so it does not appear to be the GPU allocation, I am typing this on a Pi 2 and the failed camera responds the same:  GPU memory bumped up from 128 to 256 - "mmal: Received unexpected camera control callback event, 0x4f525245" - these cameras appear to be really, really sensitive....

charliegalliher,

     Please take a look at this: https://github.com/raspberrypi/linux/issues/435 . They seem to think the order of loading libraries is important. Also check level of Rasbian. Please report back your results.

Cheers,

Clem

yep, Clem - I looked at that last fall followed the directions... had no effect. the problem follows the camera.

On the Pi I emailed the report / gpu bump from - I am including a screenshot with the error that many (google the error) are seeing (raspistill -o).

shut down the pi, swapped it out with a known good camera and got the following image (raspistill -o) - no chnaged to the pi2 with the latest wheezy with latest

updates as of this morning, prior to the test... BTW, I reseated and then swapped out cameras, and reset the camera on-board connector on the suspect unit today, too...

Images were taken within an hour of your last post (today)....

thoughts?

What I meant to say in the somewhat incoherent response is that I swapped out the camera cables and re-seated them, today, and that no changes were made to the pi 2 between the time the suspect camera generated the error and the known good camera was connected. I just powered off the Pi 2 (sudo shutdown -h), unplugged it, swapped out the cameras, powered up the pi and re-ran the command.

Thanks for the confirmation.

Have you also double checked that the suspect doesn't work again when you reconnect it?

Can you check the suspect camera with the flatcable from the working one?

Thanks for the confirmation.

Have you also double checked that the suspect doesn't work again when you reconnect it?

Can you check the suspect camera with the flatcable from the working one?

Yes, both on that Pi and on others. Also, the camera error (s) are the same across devices.

This is a consistent issue. My thought is that something is shorting the camera - it would be great to know what it is, and what precautions to take if no fix for this problem is planned.

Thanks

Are the cameras always plugged in with power off on the Pi? I noticed in the picture, the red light is on for the bad camera and not for the good one. Maybe this is a clue?

Clem

Also:

>Can you check the suspect camera with the flatcable from the working one?

I will not do it with this particular working one since I do not want to break the good one. I have done this in the past many times, and found that it makes no difference.

There is also a connector on the camera board itself, marked "p5v04a sunny" that I reseated as well.

the reason I am heating up this topic again is that my class will be putting our Pi's and cameras on helium balloons and launching them... They'll be using ssh to run the code and download them to their laptops using sftp. This is last year's image.

This year, we are going to adapt a project we saw on adafruit last week and make our own:

https://blog.adafruit.com/2015/04/24/sending-7-raspberry-pis-with-cameras-into-near-space-piday-raspberrypi-raspberry_pi/

 

Never mind - I hacked it, and I get nothing. no light....

No - in both shots, the cameras connected to the Pi have the red light on.

In the second shot, I have the bad camera in the pic, disconnected.

In the first shot, the suspect pi light turns on until I cntrl+c out of the raspistill -o command...

I am more than happy to mail you a few of the bad Pi's - I don't want them back... I just want to know what happened.

Eh.... bad PI? It was a bad camera, right?

I'm game. :-)

I was already secretly considering sending you a free raspberry pi camera extension kit from my shop, as well as an extra flatcable so that if that happens to be the problem you can repair one other camera with that.

Deal?

I got your hardware, and will use it if any more cameras go bad. I have shipped the bad cameras to Clem - I will let you know what he sees when he gets back to me. I will return your hardware when all this dust settles. Thanks so much for your help, Roger!

Charlie, please just test the camera extension with working hardware, and then let everybody know something like: "It works, but I've got no use for it". Or maybe you do find a use for it.... :-)  No need to return the hardware.