Remote display of Pi Camera

I've just come across the first slightly strange situation with the camera where raspistill would start up and then seemingly sit there doing nothing. The Pi was otherwise working normally, nothing obviously wrong in the logs etc. Ctrl-C kills off raspistill quickly without resort to more drastic measures.

Looking in the GPU log with "vcdbg log msg" revealed this message:

mmal: mmal_port_event_send: event lost on port 1,0 (buffer header callback not defined)

I've read various stuff in the RPF forums where people have had their Pi lock up completely or loose the camera, and I'd had problems with long video captures on previous firmware.

However I'd already taken something like 100k full images with this over several days since it's previous reboot (timelapse stuff), so had assumed those issues were solved, but it seems not.

Fixed it with a simple reboot, unlike some of the other things I've read I didn't need a full power cycle.  It does seem that if you want reliable images you'll have to factor in something to check the images are created, look sane, and if not, have the ability to reboot the Pi, or possibly to power cycle it.

It seems likely that issues like this will get fixed in time, the camera is still relatively new after all, but in the meantie some defensive coding seems advisable.

Selsinork

That a very good heads up ...thanks.

In my plan, I intended to have one of the GPIO signal the RPi was completed, before allowing the controller to shut it down.

Checking for this error, and forcing it to be shutdown will effectively resolve it.

If the RPi is locked up though, this won't fix it, so I need to also have the controller check for completion within x and pull the plug anyway.

It is obviously random as you've found, and no doubt your investigation is helpful to solve the underlying issue.

Cheers

Mark

In searching for some other snippets, I ran across this blog.

Its for implementing and controlling the built-in watchdog.

http://rpihouse.wordpress.com/2012/12/06/watching-the-dog/

It also includes ways to check the load to ensure that a task isn't hogging it.

Cheers

Mark

I'd advise a little bit of caution on relying on the load average feature of the watchdog prog.

The load average is an imprecise measurement and deliberately so.  It also may not really be measuring what you'd expect.  It's an average of the number of processes either running or waiting for IO to complete. This means that you can have a high load average when you have lots of processes waiting on a slow storage device, while at the same time having a CPU utilisation that's very low and have little or no impact on system performance (assuming that slow storage device isn't your root filesystem).

There's an obvious link to the Pi here, the SDcard is a slow storage device.

Leaving that aside for a minute, the problem I saw with raspistill doing nothing appeared to be a problem on the GPU, or in the communication between raspistill and the GPU. It left both load average and cpu utilisation down at around zero, so the watchdog would never trigger.

Watchdog timers are useful to some degree, and in some situations, but not all.   Compaq used to do a thing in their servers called ASR, or Automatic Server Recovery, essentially a watchdog done in hardware/firmware such that the OS didn't need to know about it. Most people tried it once, then disabled it forevermore on all current and any future systems as it could be a bit trigger happy. Maybe it was fixed later, but it's reputation had been destroyed by then.

What I've also found over the years is that the times when you really need a watchdog tends to be the times where the hardware has somehow got itself into a mess and the onboard watchdog can't reset it. In these cases you tend to need to hard power cycle the machine to get it back, usually meaning you need to send an engineer out to do that manually.  So I much prefer the idea of a watchdog that's in an external box, is connected to the system being watched via serial usb etc for it's heartbeat, and that it's able to physically interrupt power to the watched system when needed. Of course, if the watchdog itself is a microcontroller or some such it probably needs it's own watchdog too

In your case as you're building a power controller for other reasons, I'd suggest that for reliability you have that do the watchdog duties too.

Selsinork

Thanks for that.

I have always preferred external watchdogs, for the reasons you've outlined.

In your observation, I presume the other RPi functions were non responsive?

My plan was to have the controller initiate a picture via the GPIO, and the RPi signal that it had been done by checking for the file and pulsing a pin on the GPIO.

In theory this should be a crude RPi watchdog, where the controller can then 'pull the plug' on the RPi if it doesn't respond after xx secs.

I think I'll plan for a hardware watchdog in the power monitor/switch, which the controller can utilise. (cheers )

I have one planned for the new Tow Trip controllers that I'll tackle after this project.

The  current design uses two micros, and sends serial data to the 2nd one  which checks the data and pulses its output to hold a relay on ... hence  fail to safety, but I need some extra functionality, and the KL25z are  looking like a very good alternative.

Thanks for the advice.

Mark