ZeroMQ libraries & stability / radarwatch update

I’ve been hacking with ZeroMQ for some time now…  reading through the excellent guide and working on the preliminary steps to incorporate it into the new version (migrated to GitHub from Google Code) of my Doppler radar analysis application.  Multi-threading support was on the list of original criterion and considering many of the other analysis features I’d like to eventually add, full distributed processing would be the best design.  I’m not an expert hand at SMP application design and although the implementation needs here would be fairly trivial, choosing a good library to handle the nasty bits would make things vastly easier.

So I tinkered with several of their samples designs, implemented a few of the patterns in my code and tested things out.  Initial results with just a simple multithreaded service seemed work OK at first glance but eventually dropped data caused issues so I decided to try something with reliability such as the paranoid pirate pattern (robust reliable queuing).  Thinking back, I should have realised something was up when it exhibited that issue on both inproc IPC and tcp/localhost.  No matter what I was trying to do porting examples into my code nothing remained stable; either it crashed immediately or processed a few messages then died.  C and C++ code showed similar results.  Running the examples on their own worked fine.  The front-end/client-side Python application worked fine.  I gave it a fresh shot with another example – the Majordomo pattern (service-oriented reliable queuing) again showed similar symptoms of instability.  Commenting out huge sections of my code thinking it may of had something to do with a broken pointer or some other oversight on my part had little to no results.  Eventually I started comparing the GCC invocations and noticed there were some minor differences.  After 5 minutes of testing the weeks of tinkering finally yielded some fruit… Google confirmed my suspicions: linking ZeroMQ with -pg for gprof support crashes the library.

It’s amazing how quick it can be to find what you’re looking for when you know exactly what you want.  At least now I can get back to implementing 0MQ in my code.

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.

Update & Ktux upload

So life has been quite hectic lately with the holidays and it’s time to get back to writing.  I still need to upload the final piece of my service account script which basically consists of a simple Nautilus script to invoke it.  This will be coming shortly, hopefully later this week.

As for my OS Ktux, I am uploading a tarfile with the latest code for anyone whom may care to peruse the source.  Unfortunately it’s been longer then I would have liked since this has been worked on.  However with my new laptop I will be re-creating my development environment and should have more information available soon.

Rsync script update

I’ve been using my rsync mirror script for a few weeks now and have implemented an additional one or two tweaks after deploying it on my desktop system as well.

  • Firstly, now you can you use the same script across multiple boxes – the UUIDs are configurable per hostname
  • A bug was fixed where the script would fail if the destination disks were not already mounted.
  • You can also customize the rsync invocation on a host-basis as well.  This was needed on my desktop machine where a /home account was mounted via NFS on a different file system causing IO errors and subsequently skipping the file deletion.

One final enhancement I want to add is the ability to spin the backup disk down after rsync is complete – this will not only help to increase drive life but also help reduce power use (however small it may be).  For some odd reason on my machines whenever I stop (umount, sync, then spin-down) an internal disk it works for a few seconds, then the drive spins back up again and I’m seeing ATA link reset messages as if it was just being plugged in.  External drives connected with eSATA seem to work just fine however.  Need to look into that more.

Also shortly available:

  • A similar but different script I use for syncing my RAID storage array with an backup external drive connected via eSATA.  It’s a bit of a hack in some spots, but the nice thing is that it is almost fully automated.  Use this on a machine with one of those eSATA docks and you have a good way of making a quick backup of an array or disk.
  • Sample service account script implementation with the ‘chattr’ command.

Download or wiki.

Simple rsync raid-like mirror script

When I originally build my NFS/NAS server I decided to go for a software-based RAID 1 array for the OS install itself.  The storage drive was RAID-5 based but that is a different story.  I can’t recall the specifics exactly but I do remember a few times having difficulty booting off of the second drive and during the rebuild thought a slightly different design would be worth a try.  Since I had two identical drives from the array I figured the mirroring was a good idea, it was just the mdadm driver that I wanted to avoid.  Instead a manual mirror with rsync was in order.

I did base my design upon some very good backup reference information.  Plus with this way it would be easy to boot from if ever needed and take tar archives of the data without dealing with file consistency or modification issues.

Here’s how it works:

Continue reading