After merging the XC0348 code I had which was receiving the data transmitted by the outdoor sensors with the Xively code there was a bit of tweaking to do to get the sketch to play nicely. The last step was to add the code back for the pressure sensor. This was problematic as the sensor uses I2C and soon as I added the Wire library the whole thing stopped running properly. After some reading I wondered if I was just running out of memory so I commented out a whole lot of serial print statements and it this got things working again. Of course, without the print statements there was a whole lot less debugging going on.
A couple of things that still need attention:
the pressure sensor has been timing out often, so I get false values where a negative error code is returned. I’ve increased the timing loop and am seeing if this works better
we had a heap of rain overnight and my rainfall figure suddenly dropped because I was only using the LSB, and the count had overflowed. A bit of trial and error and now it is showing the true total. A problem with rainfall is that the sensor reports total rainfall, so this will just keep going up and up. I need some way to keep daily totals. Perhaps I need to add a real time clock?
my light values are related to the resistance in the photoresistors, so the curves are inverted i.e. when it is light the value is lowest FIXED Apr 10 – I chose an arbitrary dark value of 1000 and am using that as a reference point to subtract from, so now a bigger value does mean more light rather than more dark!
wind direction is returned as an integer between 0 and 31, which seem to correspond to 16 compass points. I think there might be some sort of moving average calculation used by the base station to reduce errors due to rapidly fluctuating wind shifts.
I’m thinking I might have to back this one, which has already reached its target after less than 24 hours. It’s Aussie-designed although being made in the USA. Read more on Kickstarter. Now what could I use it for …
Home early from work and a beautiful afternoon, so I thought, it’s time to install the weather station sensor array on the roof. There is a pipe from a flue or something up there that is doing nothing and ideal. Didn’t take too long, used the compass on the phone and checked the satellite image on Google Maps to get a good idea of where North is. Even whilst I was up there I could see that it was picking up much more wind rather than when it had been down low and sheltered.
There’s a whole heap of updates still to write, but this is now sending data to my Arduino which is getting pushed to the internet along with some data from sensors inside the house.
These articles together form the source that I drew inspiration from. I didn’t have to do my own signal timing analysis which sounds fascinating but complicated. The above code examples however are written either for Raspberry Pi, or for Arduino using different models of Fine Offset sensors and transmitters.
The next step was to figure out how to receive the sensor data being transmitted to the display base station. There’s plenty of articles on the web describing parts of the puzzle, but I didn’t find any one article that explained it all. For testing I used a Freetronics LeoStick and a 433MHz RF receiver module set up on a breadboard, so I could leave the original sketch still running on my desktop feeding data to the web. The LeoStick was particularly easy to use as I could just plug it into a USB port and test code from anywhere in the house without being tethered to power.
My birthday was coming up and an online retailer had a tempting online discount so I ordered one of these:
It’s a common ‘generic’ model made by Fine Offset, WH-1081, sold here by many retailers as an XC0348. Of course I had to wait until my birthday to actually ‘receive’ it and then it was back to work and no time to play. Finally it did get put together, and it has sat out the back on a small table to test it. Firstly I haven’t had an opportunity to get on the roof, and secondly, if I want to do some decoding of the data it is much easier if you can observe it close up, and test the sensors individually. Although some data is probably inaccurate, such as wind, the readings generally agree with the weather bureau. Here’s its current position:
I ran some testing code on the MPL3115A2 breakout board and that worked fine first time, giving me altitude and temperature readings immediately. I then tried to incorporate that code into my existing sensor reading sketch, using the barometer mode. At this point things suddenly stopped working nicely. The serial monitor debugging showed it just stopped when trying to initialise ethernet. I began cutting out bits of code, so that it wasn’t reading other sensors. It then seemed to start sending data and then restart, but the loop would not run.
Next night I sat down and started over with the existing sketch, but with it only sending the barometer reading, and it worked. I was able to add the other sensors back in, one at a time, and it still worked. I did cut out some unnecessary debug statements here and there to try to cut the code size down. Finally, I have everything working, but can’t explain why it didn’t work before and why it does now. I was thinking that perhaps the EtherTen wasn’t up to the task, and I might need to go up to a Mega board.
Obviously there is a bit of redundant data here, so it is just a useful way of testing the different device interfaces. What is somewhat hard to explain is why I have 3 different temperature readings given these devices are supposed to be calibrated to a high degree of accuracy. For example at the moment readings are 24.37 °C (DS18B20), 23.80 °C (DHT22) and 22.75 °C (MPL3115A2).
I put in an order to Little Bird Electronics at Christmas to take advantage of a 10% discount coupon, so I added a few bits and pieces that might come in handy. First off was a DHT22 temperature and humidity sensor, which is readily available with lots of examples around. First I tested it with some sample code, and then modified my existing ‘weather’ station code. So now I have two different measures of light levels, two temperature readings and humidity. There is a slight difference of about half a degree between the two temperature sensors, so I wonder which one is more accurate? The Xively feed immediately picked up the two new data streams, and as a bonus my iPhone app also recognised them.
I also bought an MPL3115A2 barometer/altitude sensor which looks interesting, but it is my first experience of the I2C bus and it appears that to run long distances to an outside sensor it needs a bus driver of some sort, so this one is going to take more effort. The code looks rather daunting too.