More sensor interfacing with the Bus Pirate

After interfacing the TMP102 temperature sensor recently with the Bus Pirate, the next step on my agenda was to integrate this with the Web Platform along with a HH10D humidity sensor.  Unfortunately I realised a bit late (entirely my fault rushing an order) that although the HH10D was an I2C sensor, the humidity was actually read through a frequency output pin; the I2C EEPROM was only for calibration data.  Bus Pirate to the rescue once again!

This, like the TMP102 is an 3.3V sensor and needs pullup resistors on the I2C bus to read the EEPROM.  I wasted spent a number of hours with this getting nothing but garbage data with the first sensor I tried (the calibration values were completely wrong), on the second try with a backup sensor I had much better luck, getting good results almost immediately.

We’ll be doing a similar setup to the TMP102: using I2C and turning on the power supplies but in this case the AUX pin should be set to HIGH-Z for input/reading.

HiZ> m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. KEYB
9. LCD
x. exit(without change)

(1)> 4
Set speed:
 1. ~5KHz
 2. ~50KHz
 3. ~100KHz
 4. ~400KHz

(1)> 3
Ready
I2C> c
a/A/@ controls AUX pin
I2C> @
AUX INPUT/HI-Z, READ: 0
I2C> W
Power supplies ON
I2C> (1)
Searching I2C address space. Found devices at:
0xA2(0x51 W) 0xA3(0x51 R)

Good.  Now if you take a look at the datasheet for the M24C02 EEPROM to do a random address read you’ll need to send a start bit, device select (read only; R/W set to 0), address, then another start bit, device select again (but with R/W set to 1), then read commands.  The HH10D datasheet mentions there are 2 calibration factors we need to read: sensitivity and offset and each are 2 byte integers, making a total of 4 bytes.  These start at address EEPROM address 10.  Using the BP, we do the following:

I2C> [0xa2 0x0a [0xa3 r:4
I2C START BIT
WRITE: 0xA2 ACK
WRITE: 0x0A ACK
I2C START BIT
WRITE: 0xA3 ACK
READ: 0x01  ACK 0x8B  ACK 0x1E  ACK 0x32
I2C>

This is in big-endian format so the sensitivity value (at address 0x10) reads 0x018B and the offset is 0x1E32.  We’ll also do a frequency read, the first as baseline with my AC running nearby and the second breathing on the sensor:

I2C> f
AUX Frequency:  autorange 7,169 Hz
I2C> f
AUX Frequency:  autorange 6,790 Hz

The formula in the datasheet states the RH = (offset-freq) * sensitivity/4096.  Plugging these in we get 54% and 90.6% RH which seems to match the other humidity sensor in my room.  Success!

Next step was getting this working on my Web Platform.  I have some very bare-bones code working with the TMP102 already, just need to work on the HH10D a bit more and I’ll post my example up here.

Barometer OneWire sensor added

I finally got around to ordering and building a 1-wire barometer kit from Hobby Boards…  it was a fairly straightforward assembly process when you actually follow the construction tips and don’t accidentally mix up the location of the two SMT IC chips…  Oops!  Thankfully they were only 8-pin SOIC’s so it wasn’t too terribly difficult to fix.  Next time I suppose should stop watching Storm Chasers while soldering!

It took a minor hack on the DS2438 library I’ve been using to add a function to read data from the ADC without converting to a humidity value with temperature compensation to get working, but seems to be pretty good so far; my reading are within 0.02 inHg from what I’ve seen so far, though only testing over the full 3-4″ range will evaluate the precision correctly.  I’ve updated the patch on my Google Code repository to reflect the new readAD() function.

There are some minor bugs I’ve noticed, namely the DS1820 temperature sensors can report invalid readings when the Arduino is powered on.  It only seems to happen when it’s reset, a cold power-on rarely causes it and usually an additional reset or two fixes the issue.  The DallasTemperature library is coded to use parasitic power for the sensors and it’s possible I may have wired them to use +5V; I’m thinking this could possibly cause issues but will need to check.  The lightning counter code currently calculates the derivative between readings and only uploads the differences rather then the absolute value, occasionally this will give an incorrect reading as well which results in a large negative value being transmitted.  These two issues can skew the scaling on the graphs which can be annoying.

I’m also looking into better integration with Pachube, I’ve seen a nice example which use EEML XML format with the API v2 which allows for better flexibility, it could handle the invalid sensor readings better by omitting them from the feed update.  I also came across a Perl library which I may use to write a small command-line client for updating or manually changing sensor readings…  perhaps a simple hack to fix the min/max graph scaling problem.

Although I consider this project something of a success I will eventually want to develop a new version from the ground up using sensors similar to the weather sensors SparkFun carries…  it will probably be similar to the USB weather board they built (using different I2C/SPI sensors) but I want to integrate a LCD and ethernet directly on the board.  Plus it will give me an excuse to finally make a custom PCB! 🙂

Images of the build:

Pachube datastream:

Arduino OneWire/Pachube project uploaded

After uploading my radarwatch project to Google Code yesterday, I went ahead and created another one for my Arduino projects. Right now it consists of a basic weather station which reads in data from OneWire sensors and upload it in real-time to a live Pachube feed via an Ethernet shield. The sensors I’m using are from Hobby Boards and include temperature, humidity, solar, and lightning detection. I’d like to thank the developer ‘gfb’ for writing and open-sourcing an OneWire Arduino library for additional 1-wire IC’s beyond the standard DS1820 temperature sensor covered in the Arduino DallasTemperature library.

The code is pretty basic now and probably somewhat buggy.  I need to patch 2 of the OneWire libraries, one to fix a bug reading in DS2423 counters (lightning detection) and another patch to add functionality to read current from the DS2438 smart battery monitor (used as a solar sensor here).

Sensor data is displayed on a small 16×2 LCD display, echoed out to the USB serial port, uploaded to Pachube in real-time and also available via a webserver running on the Ethernet shield.  I’m not a huge fan of the sample tutorial code I used from Pachube, it seems kinda hackish.  I’ve seen better examples on there built around a nice library but unfortunately they all seem to need Processing, which I didn’t feel like using here.  Maybe if I get time I’ll put together a nice Pachube stand-alone Arduino library.

There are a few kinks to work out still and further development, such as getting the solar sensor close to the window to track daylight hours without compromising the accuracy of the thermal readings (old apartment, window insulation not so good).  I’ll try to post some pictures of the setup and maybe a schematic up soon.

If you’re curious, you can view the feed here: http://www.pachube.com/feeds/9598

Wiki entry : http://code.google.com/p/kern3l/wiki/OneWireProject

Sample graphs: (these are real-time live data)

  • Temperature
  • Humidity
  • Lightning strikes (frequently produces false positives)

Sample images of the hardware:

radarwatch uploaded to Google Code!

So I finally got around to uploading my WSR-88D NEXRAD radar analysis project source to a new Google Code project. I’ve been wanting to do this for some time now and I’m sorry to admit that there is no documentation as-of-yet. Just wanted to get something uploaded and it’s probable that I will tinker with the repository further. There are also a fairly large amount of uncommitted changes which I need to work on before adding. Hopefully I will have some wiki docs up in the near future. I also plan to great another Google Code project to upload my Arduino 1-wire weather station code to as well.

I’d just like to extend a thank you to Nathan @ IBM for publishing a tutorial on writing your own weather alerts with GD which got me started on this project in the first place.  I don’t plan on ever making this production grade but hope to implement some features similar to professional projects such as NOAA’s CODE and NCAR’s TITAN.

*Update*: Some preliminary wiki docs have been added.

DIY Radar & SheevaPlug

So I’ve decided to disable my weekly Twitter updates after seeing how annoying it would be to read.  I’ve been working on a few things lately, first is a “DIY radar” weather warning system with the help of NOAA WSR-88D radar data, libGD, and Perl.  I recall some very basic image processing algorithms and code I tinkered with in BASIC when I was much younger, but it was very simplistic and this was ages ago.  It’s fun to catch up on some old programming interests.  I’ll throw a post about it together once the code is a bit more complete.

My Linux-based SheevaPlug (embedded Linux in a wall-wart) has been occupying some time as well, tinkering with the Jaunty install and NFS and SSH.  I’m pretty impressed with the capabilities of this so far, despite the fact I managed to partially brick it for awhile. I eventually want to build a Tweet-A-Watt and use my plug for interfacing.  Wiring my 1-wire weather station to the plug makes sense as well.