If it ain't broke...

I've spent weeks trying to figure out how I broke my Raspberry Pi.  Actually... How I broke two of them.

Well, I didn't actually break them.  Just the sensors attached to them.

Well, I didn't actually break them, it's just that they weren't reading correctly.

Here's the story:

I've been working on a couple of I2C sensors to tie into my Raspberry Pi.  The idea is to read the sensors at specific intervals, log the data, and then serve up some nice graphs.  I've been using the BMP085 temperature and pressure sensor, the TSL2561 light sensor, and the TMP102 temperature sensor (All those links go to the Adafruit forums specific to those sensors and the Raspberry Pi).

A group of us were collaborating on the TSL2561 (Hi, csalty!), when I upgraded to the newer version of Adafruit_I2C and the Adafruit_BMP085.  That's where everything went sideways.

I spent days looking at the datasheet and the Adafruit_BMP085 code.  Some of the stuff just doesn't make sense to me.  It doesn't make sense to the point that I wrote the devs saying "This is broken".

It's not, and that's pretty embarrassing.  It really looks like something in the Adafruit_I2C code changed how it pulls the information from the BMP085.  If you're looking for solutions, enable the debug mode, and check your calibration information.  Mine was VERY off using that version of Adafruit_I2C (Impossible temperatures and unstable in nature reading 200 degrees one minute negative 70 the next).  Once I switched some of the functions to the older version, things went well.  The kludge-version of Adafruit_I2C that I'm using is listed here: Modified Adafruit_I2C.py.

I also made a very specific change to the Adafruit_BMP085.py code.  I allowed the code to pass a specified bus number down the "stack" to the I2C code.  By default it does not specify a bus, and will allow the new I2C software to determine which version of the Raspberry Pi is being used, selecting the default GPIO header bus.  This way, all you have to do is call the BMP085.  It will fill in the default address, the default mode, and the default bus.  If you (like me) are using both I2C buses on your Raspberry Pi, then you MUST specify when you are using the "non-standard" bus.  The way the Adafruit_I2C.py code is written, it will only look for the version of the board and assign the "default" bus.  It has no way of knowing which bus you want to use.

I also set up the BMP085 code to pass the debug state down the code stack.  I figure if you're interested in debugging the BMP085, you're also going to be interested in debugging what is happening with the I2C code.  As part of the BMP085 calibration data, I also set it up to print out which I2C bus is being specified.

I need to make these changes to the TSL2561 code and the TMP102 code.  Both of these sensors appeared to be working just fine with the new Adafruit_I2C.py code (I've checked to make sure).

I've changed my project a little bit.  Now I'm running two parallel sets of sensors on the two different buses.  Each bus has a TSL2561 and a BMP085 sensor.  I'm logging the temperature, light level, and pressure every sixty seconds or so.  I'm manually able to generate all kinds of charts, but for right now I'm going to keep it manual.  I'll let the system run while I'm at work this week (four days), and if everything looks OK, I'll work on re-writing the webpage code.

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.