Mine always hangs at "Starting capture 0".
I have used gdb (gnu debugger) and it hangs at sem.wait() (semaphore wait) which is suggesting that it is waiting for a reply from either the camera or the kernel.
Hi Greg I have totally removed my camera and have executed the command raspistill -v -o test.jpg with no camera present and it comes up with this output:root@raspberrypi:/home/pi# raspistill -v -o test.jpgraspistill Camera App v1.3.5Width 2592, Height 1944, quality 85, filename test.jpgTime delay 5000, Raw noThumbnail enabled Yes, width 64, height 48, quality 35Link to latest frame enabled noFull resolution preview NoCapture method : Single capturePreview Yes, Full screen YesPreview window 0,0,1024,768Opacity 255Sharpness 0, Contrast 0, Brightness 50Saturation 0, ISO 0, Video Stabilisation No, Exposure compensation 0Exposure Mode 'auto', AWB Mode 'auto', Image Effect 'none'Metering Mode 'average', Colour Effect Enabled No with U = 128, V = 128Rotation 0, hflip No, vflip NoROI x 0.000000, y 0.000000, w 1.000000 h 1.000000mmal: mmal_vc_component_create: failed to create component 'vc.ril.camera' (1:ENOMEM)mmal: mmal_component_create_core: could not create component 'vc.ril.camera' (1)mmal: Failed to create camera componentmmal: main: Failed to create camera componentmmal: Camera is not detected. Please check carefully the camera module is installed correctlyroot@raspberrypi:/home/pi#Note that the machine does not hold but handles the missing camera properly so I think the SW is generally capable of not blowing upSugested options:Has suggested by Mark try the connections againTry above senario to see if not having the camera makes it work ..if it still crashes maybe you have some corruption or RPI problemTry another camera .....NOIR or standard if you have itTry another RPIWhat tool did you use to write the SDCard? I have experienced corruption using Linux dd command since it's so fast try using a bs=128K to limit the block size and speed slightly ...seems to work for me
* Has suggested by Mark try the connections again
I have removed and reinserted the cable several times at both ends.
* Try above senario to see if not having the camera makes it work ..if it still crashes maybe you have some corruption or RPI problem
I have seen that message when I put the cable in the wrong way
* Try another camera .....NOIR or standard if you have it
I do not currently have access to another camera
* Try another RPI
I have tried it in 2 raspberry pi (one of them blue!) and have the same result.
* What tool did you use to write the SDCard? I have experienced corruption using Linux dd command since it's so fast try using a bs=128K to limit the block size and speed slightly ...seems to work for me
I use a windows app whose name escapes me but it verifies the write automatically using MD5
Don't worry i remember the NZ time zone
Definately seem to be running out of options ...Sorry about that!
Looks like you will need to await supplies from E14 base camp...Good Luck
The crashing is suggesting software since it happens on 2 RPi.
For the SD card I followed the NOOBs instruction and used the SD Association's formatting tool https://www.sdcard.org/downloads/formatter_4/eula_windows/
Remember to set the FORMAT SIZE ADJUSTMENT option to ON (default is off)
After that the RPi fired up and I installed Raspbian onto the 8GB card, and did the update thing to collect the latest updates.
I am presuming that you are using the same card in both RPi, which apart from the camera is a single common factor.
Best you visit your mate who has a working arrangement, unless somewhere here is closer that can assist.
Another thought just occurred.
Your SD card isn't a class10 is it.
I understand they have issues, with some brands working, but not others.
The Class 10 is designed to be fast, but they tend to allow only one communications to one file.
I've used class 4 through to 6 SD and MicroSd with no apparent issues.
I have used a couple, the one I am using at present is a Kingston 16GB SDHC class 4
Mark Beckett wrote:
Your SD card isn't a class10 is it.
Don't be fooled by the 'class 10' rating, it really doesn't tell you very much. When you see Class <X>, all it's saying is that the card is supposed to handle a write speed of <X>MB/s
Buried in the fine print there are many different electrical signalling modes ranging from 1bit SPI mode at 3.3v and 25MHz to 208MHz @ 1.8v and on to 0.4v modes @ 52MHz and theoretical 312MB/s transfer with UHS-II. Even the basic 'Default Speed' (one step up from SPI mode) can theoretically transfer at 12.5MB/s so could be a 'Class 10'. The issues start to happen when you work out the intersection of supported modes for both the particular card and the controller. The Pi is hard-wired to only allow 3.3v, so some modes become unavailable (both the driver and the Pi's SD controller can support more, it's the stuff external to the SoC that's lacking).
I've used 'Class 10' cards in the Pi and in several other SBC's with no problems, the main advantage being that they can often give you better performance than a cheap class4 as, other concerns aside, the actual flash part of the card is faster. One problem I did notice with a recent update to the Pi firmware/kernel (for fixes to the camera stuff) was that a couple of my class 6 cards became un-bootable. The class 10 card that was problematic in the early days works fine with the update though!
According to this
One worked and one didn't.
I'm still puzzled bu the fact it seems to recognise the camera, etc but when it goes to process the image it falls over.
As far as I know all the image processing is in the GPU, which tends to indicate the memory split hasn't worked.
I wonder if its worth trying some other choices and then run type free -m to see what it reports.
Got an over night air package today with enough contents (4 out of 6 items) to get started on the review. Got my camera case, Wi-Pi, Raspberry Pi kit with SD card and PiFace Control and Display. Only missing two items (Pi NoIR and PiFace CAD case). First goal is to get it booted up, WiFi working, updated and then play with the PiFace CAD.
List is a little slow today. I have gotten my USB Wi-Pi working, seems using a good power supply that provides more than 850mA is really a good thing. Works fine for the Pi, but the Wi-Pi would not find my AP. Then got my PiFace CAD working and a little playing with Python and all is good.
I think I will play with buttons next, but this is cool.
As you have seen, the wi-pi seems to be a power hog.
Put it away, Santa is coming!
I set mine going last night using snap-camera. PiFace – How to use SnapCamera – Introduction to SnapCamera
You may wish to edit the camera.py file to increase the sharpness located in /usr/lib/python3/dist-packages/snap-camera
edit the line that builds the command from 'raspistill' to 'raspistill -sh 100' (you can also add the -ex night if you want)
(Snap Camera just sends a command in the same manner as you would from the command line/terminal, so a few more modes need to be added to it.)
My battery pack seemed to run out at 2am despite being plugged in and in theory charging, so not sure why.
I did miss someone who was checking their present ...funny how they admit it before the video evidence is presented.
The unwrapping this morning was a hoot, but the NOIR camera is a little weird on colours.
I downloaded the GoPro software GoPro Studio 2.0 Edit Software to convert and assemble it.
I'm still playing/tweaking as we started at 5 sec images, and the default frame rate is too high.
Anyway enjoy, and have a Merry Xmas