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.
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.
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.