This fits on the bifferboard onboard flash memory, with about 1MB to spare.
I created a /home/weather directory and extracted a recent pywws tar archive into it. I was very pleased that running TestWeatherStation.py produced a table of numbers as expected, so it looks as though the bifferboard is talking to the weather station ok.
Here it is:
Set up the initial weather database by doing
cd /home/weather
python pywws/pywws/LogData.py -vvv /home/weather/data
This creates /home/weather/data/weather.ini and a directory /home/weather/data/raw which contains the raw data.
Run Hourly.py for the first time to process the data, and set up the weather.ini file ready for customisation:
pywws/Hourly.py /home/weather/data
Customise /home/weather/data/weather.ini to do what you want it to do - in my case update weatherunderground....
All is looking promising here - seems to send the update ok on an hourly basis. There are two problems though:
- There is not much disk space left now I have added all of January's weather data (256kB ish)
- I am concerned that I will wreck the flash chip on the bifferboard with all this writing.
One option is to store the weather data in a ram disk and just accept that after a power-off it will need to re-initialise itself - not sure how pywws will cope with this - I will need to load some default weather.ini file from flash every time it boots, then let it update itself as best it can.
As a quick alternative I have found an old 256MB SD card and created an ext3 filesystem on it. This detects as /dev/sda1 when plugged into the bifferboard. I have modified /etc/rc.local to mount this as /home/weather. This should solve my full filesystem problems. [Note: I used an ext3 filesystem because my openWRT build could not detect ext2 - this was a bit of a surprise because I thought you got ext2 support free with every Linux kernel...].
Then it is just a matter of a cron job to do the hourly updates - crontab -e, then add:
Then it is just a matter of a cron job to do the hourly updates - crontab -e, then add:
13 * * * * python /home/weather/pywws/Hourly.py -v /home/weather/data >> /home/weather/Hourly.log 2>&1
If it works, you should continue to see the weather in our back garden at: http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=IHARTLEP2.
Mistake 1: If you put an SD card into the dual USB bifferboard, it disables one of the USB ports. This is bad if it was the one the weather station was connected to....
Mistake 2: Believe people when they say the clock on a board is no good. The Bifferboard clock is no good. Not only does it loose its time when powered off, but it drifts - by a few minutes an hour. This meant that pywws got confused about when it should update weatherunderground, because it thought time had suddenly gone back to 2009.... To avoid this I compiled ntpclient as a package and downloaded it onto the bifferboard. I now have it set to be called once on boot, then every 10 minutes by a cron job. This should keep it somewhere close - just hope the time server owner doesn't mind - If I get a complaint I will have to set up my own time server...
Mistake 1: If you put an SD card into the dual USB bifferboard, it disables one of the USB ports. This is bad if it was the one the weather station was connected to....
Mistake 2: Believe people when they say the clock on a board is no good. The Bifferboard clock is no good. Not only does it loose its time when powered off, but it drifts - by a few minutes an hour. This meant that pywws got confused about when it should update weatherunderground, because it thought time had suddenly gone back to 2009.... To avoid this I compiled ntpclient as a package and downloaded it onto the bifferboard. I now have it set to be called once on boot, then every 10 minutes by a cron job. This should keep it somewhere close - just hope the time server owner doesn't mind - If I get a complaint I will have to set up my own time server...
2 comments:
For a more accurate clock, you need to patch your kernel so the timer tick frequency is correctly defined. For RDC it's not the same as on the original PC hardware. There is a patch here:
http://bifferboard.svn.sourceforge.net/viewvc/bifferboard/kernel/2.6.30.5/0014-pit-tick-rate.patch?revision=164
But we've not managed to get it into the standard OpenWrt SVN yet.
Amazingly, this was part of the Linux kernel for some time, and then someone took it out, obviously thought it was the 'wrong' way to solve the problem. Trouble is, they didn't put anything else in to do the same thing. Don't ya just hate it when that happens?
That sounds good - I will give it a try in a week or so once the bifferboard has passed its soak test!
I should have realised it was something more fundamental than a problem with the clock - it was just loosing so much time for it just to be inaccuracy.
Post a Comment