Unfortunately I've had to abandon Raspbian Jessie and return to Wheezy.
But I'm now back on track, with both hardware and software performing as expected.
I started out using Jessie and had no problems with my Gambas applications, custom scripts and other applications that I rely on for my system, including VLC media player.
Motion
The very last one I got around to testing was Motion, which involved installing the stock version from the repository, and then replacing the exe with the motion-mmal version by dozencrows. This is when my problems started.
I ran motion and discovered dependency problems associated with libavformat53. These were unsatisfiable, so I had to install Raspbian Wheezy on a second SD card and start the build process again. There are a surprising number of files that have to be copied or modified before my system will run properly.
I tried to use the optimised motion-mmal (also by dozencrows) on Wheezy, but could not seem to get this to create video files. I could stream video and save jpegs, but not videos. So I've settled back on the non-optimised version that I used in 2014.
Gambas
I have two Gambas applications for this system; a test app called Kicker which just keeps the power supply on when I'm fiddling around with the system, and the main bird box application. These were modified on my Jessie build using Gambas 3.5.something.
On Wheezy, I opened my Gambas app in the IDE (v3.4.2) but when I tried to run from source (in IDE) I got this message:-
Cannot load class FMAIN: Bytecode too recent. Please upgrade Gambas.
This is rather odd, as I don't think the IDE should be worrying about bytecode, it should just read the source files and do what I ask! After all, when you first create a Gambas project there is no bytecode.
Either way, a quick search on DuckDuckGo revealed the easiest option was to run "Compile All" from the Project menu, and then it ran and all was good.
Queue lights, camera... ...camera?
Once I switched over from my development Raspberry Pi B+ to the final target board, a model A+, I encountered another problem. The RaspiCam just was not detected on either of the two model A+ boards that I tried!
 |
| Taking shape: still need 3 x 10mm led |
After a search on the net I discovered someone with a similar problem, which they fixed by running apt-get update & upgrade. This took a long time as my 2014 image dates back to April last year, and there have been many, many updates since then.
The camera was still not detected, but another reboot seemed to fix this.
For 2014 I'd used a die cast aluminium lens mount, and hot-melt glued it to the camera board. For this version I'm using a hard plastic mount which I've carefully filed to fit over the board components. I've used Araldite to glue the mount to the board.
This time around the camera lens, mount and board will be completely accessible to the littles guys inside the nest box. I just hope they don't peck it too hard!
I also found that the lens was a bit loose due to the interface between mount thread and lens thread. Last year I noticed that focus was not consistent across the image. i.e. at a fixed distance, the right side of the image may be in focus while the left side was not.
At the time, I put this down to a possible misalignment of the camera mount to the camera module. But this time around I found I could simulate the same problem by rocking the lens from side to side (a movement of probably just micro-metres).
Normally these lenses are locked by a grub-screw bearing down on the lens from the side. I can now see that this is not a great idea, so I found an old reel of plumbers PTFE tape, applied about 3 turns to the lens thread, and screwed it into the mount.
So now there is no movement, and the lens is as central and parallel to the mount as I'm going to be able to get it.
Your socket is too tight for my dongle!
(sorry! ...it must be time for my medication.)
I maintain that there is a problem with the USB sockets fitted to Raspberry Pi model A and A+ boards. I broke the socket contacts on my first model A by forcing an Edimax wifi dongle into it.
In the interests of quality control, when my second model A arrived, I repeated the test (I was going to remove the horizontal socket anyway, and replace with a vertical socket to reduce the board foot-print). This second unit failed in the same way.
I now have 9 RaspberryPi boards, and the 12 USB sockets fitted to my four B/B+ boards are fine. But the USB sockets on my five A/A+ boards are all too tight.
The problem is the "body clips" on the A/A+ USB sockets, which exert too much pressure on the body of the incoming device plug.
Here is a simple test that you can do if you have an A/A+ and a USB device (especially Wifi dongles and some memory sticks):-
- Insert the dongle into your regular desktop or laptop computer. Just use your index finger to push it in, and do this 5 or 6 times until you have a feel for how much pressure is required.
- Now try to insert the dongle into your Raspberry Pi using the same technique, and apply the same amount of pressure.
- If it wont go in, it is probably too tight.
I now modify any new A+ board by relieving the tension on 2 or the 6 body clips. The idea in to encourage the dongle to sit low in the socket, so that the socket contacts are not forced backwards by the blade of the dongle.
I do this by pressing down the lower two clips with a small bladed screw driver or spike.
 |
| Relieving a bit of the pressure |
Even with these two clips disabled (no longer in contact with the incoming dongle) there is still plenty of pressure applied by the remaining 4 clips. So no fear of your dongle dropping out.
I like your new BirdCam Pi shield. I wouldn't worry about having the camera open to the inside of the box. I've a webcam that has been open for interference in a large box that is used regularly by squirrels without issue. My birdcam box has a piece of glass between the webcam and the pi - which is suffering from led reflection since the black enamel paint I painted over the webcam's led is too thin.
ReplyDeleteHave you got any lighting in there - I cant see any leds on the underside of your perf board?
I added a led to the second picture, but it wasn't actually soldered in.
DeleteThe current plan; I'm going to cut a wider camera perf board (replacing the one in the photos) so that when the module is attached to the box, it will sit over a rectangular aperture facing downwards. I'll fix 4 upward facing studs (probably M3) to the aperture, and have 4 holes in the bit of the camera perf board that sticks out either side, beyond the width of the other boards. That way I can easily fit nuts to the exposed studs.
The 3 x 10mm leds (should arrive this week) will be fitted to the perf board and will face upwards..ish, and the perf board will be painted white to act as a reflector.
How is progress with the Pi trail-cam?
Progress is tantric... I've got the ir cut filter working using L293D ic as polarity reversing switchy thing.. It's a question of getting all the parts that work separately working together and probably building a new enclosure. V little time at the moment. Also have mark II nest box for this spring to finish. My track record seems to be to build next years box this year, as last years box is beginning to get some interest... Get a daily blue tit visit to last years box. Out of interest, with your IR illumination, do you have it on all the time, or do you have it activated by some trigger? I've got an infrared beam split triggering a couple of white LEDs to come on,but don't know whether to keep them on for a period, or what....
DeleteYeah, finding time is the problem, but I think your new bird box should get priority over the trail cam, as this years box really needs to be deployed by the first week in March.
DeleteI think I saw some posts on the forum about your filter switcher. That sounds amazing.
I'm not using iR, as I was not happy with any of the potential robin nest sites around my garden. So this year I'll put last years 32mm hole box back where it was (but maybe at an angle, like yours, but not nearly as posh). And build a new box, probably with a 25mm hole, again attached to an archway at an angle.
So the 3 leds I'm using (in both boxes) are super-bright white, pointed upwards so as not to dazzle the birds, with a white ceiling as a reflector. Once again I'll have two brightness options: nice but dim, and battery chicken mode. During the early days the system is triggered by activity which powers/boots the Pi, and once my program loads, Motion is started and the lights are typically turned on to dim mode (or however I left it since the last time an option was selected).
I only really use the bright mode when there are chicks to film (using RaspiVid not Motion).
How do you control the brightness of led in software? Mine are just connected to GPIO output with a resistor in between, so are either on or off...
DeleteTake a look at the circuit diagram in this post: http://captainbodgit.blogspot.co.uk/2015/01/birdbox2015-picaxe-controller-details.html
DeleteWhen I select dim illumination, IC1a input is driven HIGH by the RPi gpio, so its output goes LOW and the leds are affectively connected across 12V with 690 Ohms (470 + 220) in series. (the question marks by these 2 resistor values is because I may change the values during final test).
When I select bright illumination, IC1b input is driven HIGH by the RPi gpio, so its output goes LOW and the leds are affectively connected across 12V with 220 Ohms, giving a much higher current.
You could modify this circuit slightly by putting resistors in the outputs of both IC1a & IC1b. That way you could have 4 modes/options:-
Both outputs off - no lights
IC1a output on - dim lights
IC1a off, IC1b on - medium lights
IC1a & IC1b on - max brightness
I hope this helps. HOWEVER, don't use my resistor values, especially if you are using iR leds. Read this post if you don't already understand LEDs: http://captainbodgit.blogspot.co.uk/2013/11/dont-waste-power-with-leds.html
It will help you determine safe resistor values for you chosen led type (the led Vf varies, not only by colour, but for the same colour from different types).
A noob question, but what is IC1a/b? I found some websites suggesting that you could use the PWM pin to control brightness too?
ReplyDeleteIC1 is a ULN2003, which is a 16 pin chip with 7 drivers. Each driver is 5V input compatible, and each output is "open collector" so you can connect something like a relay or lamp or (in my case) 3 leds. Its a great device for driving much heavier loads than the Pi will tolerate directly on its output pins. IC1a and IC1b are just 2 of these drivers.
DeleteThese drivers invert the input; so a HIGH at the input (3.3V from the Pi) switches the driver output LOW (0V..ish), which puts 12V across the led circuits. The brightness of the leds depends upon the current flowing through the leds.
Yes, you could use PWM, but it would make the interface more complicated, and do you need such fine control of the lights? I found last year that just having 2 options (bright and dim) was all I needed. The dim option is adequate for running motion, and the bright option helps produce reasonable quality video when using RaspiVid.
I hope that helps, but if in doubt, ask.