Well its one week since I installed this bird box to the archway just outside our conservatory.
This post covers some of the highs and lows.
The really good news is that the local blue tits have been very helpful, arriving every morning to assist with testing the system.
For the first 3 mornings they were only prepared to poke their heads through the entrance hole a few times, but that was fine, it was a good test of the control circuit.
Pictures at last
On Monday morning, one or more blue tits plucked up the courage to enter the box for a closer look.
 |
| Feel free to click on this picture for a closer look |
This image was extracted from a short motion video sequence. I like it!
A couple of points to note:-
- The only light is from the 30mm entrance hole (left of picture)
- I think the broken vertical lines (and other blobs & blocks) are caused by Motion encoding the images into MP4 video. When I'm able to get some straight jpegs, I expect the quality will be much better.
The other encouraging thing is that todays video shows our friendly blue tit wing-flapping, and picking up small pieces of debris and removing them from the nest. This is typical behaviour, but still no guaranty that they will move on to the next phase; bringing in their own nest material.
In fact I noticed this morning that they flew from this nest box to one of the very old ones at the bottom of our garden. I suspect they have a morning circuit, taking in all the available local accommodation. Its a buyers market at the moment, with very few birds and many empty properties.
Designed To Crash
I often power-off Raspberry Pi computers without bothering to shut them down. I've never really had a problem, but with this project, when the system has unexpectedly shut down, I have lost the contents of my Gambas project settings file. This is probably because this file is updated every 5 seconds, so there is a good chance of corruption.
The Gambas settings file is like a Windows ini file, containing the current values of check boxes and text boxes for my applications user interface.
When these settings are lost, new default values are created by the code. So in order to ensure that the program will start up and run Motion, I've simply changed some of the defaults to make the system fail-safe.
For example:-
chkMotionEnable.Value = Settings["Settings/MotionEnable", True]
chkMotionLink.Value = Settings["Settings/MotionLink", True]
chkAutoLights.Value = Settings["Settings/AutoLights", False]
vbThreshold.Value = Settings["Motion/Threshold", 1500]
chkUseStills.Value = Settings["Settings/MotionStills", False]
chkUseNTP.Value = Settings["Settings/NtpCheck", True]
Now if the file is lost, Motion will be enabled by default, ensuring that the system will still capture any action.
Anyway, the system is designed to crash without scrambling the settings file by not writing to this file when it looks like the power is about to be turned off. A couple of changes to the software earlier this week seems to have fixed this tendency for the system to power off unexpected. One of them simply involved widening the pulse that re-triggers the controller monostable.
Time & Date from local server
The Raspberry Pi has been setup to get the time & date from a local server, located in the garage. This is not going as well as I expected.
This extract from my AppLog shows it working quite well:-
Basically the software keeps kicking the controller to keep the power supply on for 30 minutes after the last detected activity at the entrance to the box. Once this 30 minute over-run time has expired, the software stops saving data to the settings file and stops kicking the controller (monostable). In the log extract above, the system lets go of the controller at 20:36:16. The controller would have powered down the Pi about 90 seconds later.
When the system is next powered up, the Pi clock reads 20:19:32 (the hour is as expected, not sure where the mm:ss comes from) and the system successfully resets the clock to 07:40:20.
As the system shuts down and restarts during the course of the morning, the system time is generally reset correctly. But if the system is down for a few hours in the afternoon, when I power the system up late afternoon/early evening, the time is not updated. However, the following morning the time is often re-synchonised successfully once again.
The NTP service was not a good choice for resetting the clock. In this application the system is powering on/off quite frequently, and NTP does not like making large and frequent corrections.
Maybe a better solution would be to get the garage server to write the time/date to a text file (say) once each minute. The Pi could then read the file during startup and use the Linux date command to reset the clock.
No comments:
Post a Comment