Parallelism in Hacking

I spent yesterday morning working on the datalogger, specifically making it WiFi capable.  This morning, I slept in, made my coffee and checked the news.  Over on Hackaday, Jose has created an Arduino/Pi/WiFi/X-Bee environmental monitor.  He's got his own webspace, uc4fun, where he's hosting the notes on his project.  A lot more professional looking than mine.

He's essentially doing my project (If he knows I exist, he's shaking his head saying "That guy's doing MY project").  However, he's doing it in a completely different fashion, which is awesome.  I think he's using a mix of I2C sensors (he's using the TMP102 and the BMP085) and a Sparkfun humidity sensor (Dude!  New Product Friday.... 'cuse me while I go browse...).

I think he went with the doubled up microprocessor approach because it allows him to use the ADC's on the Arduino.  So far, I've been severely limited in the sensors I can use on my build because I'm only using I2C and binary digital sensors.  His complexity gets him some serious advantages, but is also one of the main things I want to avoid (He's probably writing code for both the Arduino and the Pi.  That'll give me headaches).  I sent him a message on the Hackaday board asking why he made the choices he did.  Looking at his build and presentation, he's going to have some good answers.

I definitely wanted to avoid the multiple radio links.  Given my history with RF links, I'd like to keep that as simple as possible.

Integrating the TMP102 sensor with the datalogger, and I2C bus lengths

The TMP102 is an I2C sensor available on a breakout board from Sparkfun TMP102.  It's pretty cheap, under $10.  It will actually allow you to have multiple sensors on the same I2C bus just by jumpering an address pin.

I'm working on creating a software module to decode the output from the sensor.  So far it isn't straight forward, at least for an amateur.  If I understand correctly, the sensor reports the readings in a backwards fashion.  I'm not sure I've decoded the output correctly, but I'm close.  Once I get that ironed out, I'll post the code up.

I started playing with I2C bus lengths.  I heard that the practical length was less than a meter.  I've got around a 2-3 meter CAT-5 cable set up running the TMP102.  It's dangling outside the window, inside a tupperware container, and appears to be working just fine.  I'm using Sparkfun RJ-45 Jacks and breakout boards.  It adds a couple of bucks to the cost of the project, but it makes for great modularity.  It's also going to let me do some cable run tests.  Eventually I'll post those up as well.

I modified the jacks and breakout boards slightly.  In place of a simple header, I used Arduino 8-pin stackable headers.  That way, I can easily add a second sensor (or more) at the cable end, while still being able to easily breadboard it.  So far it's working great.

The goal with this setup is to have two sets of environmental sensors.  One on the Raspberry Pi itself, and the other just slightly remote from the Raspberry Pi.  This sensor set could be outside a window, inside a terrarium/fish tank, inside a science project (fermenter? soil analyzer? hot water heater?), all kinds of possibilities.

If I can make the software scale-able, anyone could add all kinds of sensors to the system and have it easily recordable.  The only drawback would be writing new sensor drivers for each set of sensors.  That's where I'm having a fair amount of difficulty now.

It looks like I was wrong when I figured out the size of the data files.  Right now, the datafiles appear to be much smaller, despite my cramming more information into them (Temp1, Temp2, Pressure, Motion Sensor, Time, Log Level).  I think I want to change the logging system even further so that it creates a better record of values.  Right now I'm saving a string for each sensor cycle with just the sensor values.  The software is written so that it assumes a certain value is in a certain order in the string.  That's great, as long as no one else is adding sensors to the system, and you only look a certain way.

I'm wondering if I can create a log with each sensor cycle recording a dictionary.  Then I could easily write code to examine which sensors were polled for each sensor cycle.  I could easily pull all the sensor values, or some of the sensor values.  I could have some sensors polled more often than others.

I need to grab a second Raspberry Pi, and start thinking about how to pull all the sensors nodes together, into one easy to read display.