I got it in my head to work on the environmental sensors I've had in my head for a while, but with a caveat: I wouldn't buy any new hardware until I had a working prototype or technology demonstrator. Fortunately, I was able to borrow an unused hardware platform from a friend of mine.

The basic idea is this: a variety of self-contained sensors broadcast measurements, and I can use both a Raspberry Pi in my house to pick up those broadcasts and store them, as well as use my phone to check in on the state of things. Each sensor node will have the standard environmental sensors (temperature, humidity, air pressure), and I'd like to include soil sensors, too.

The demonstrator platform is an Adafruit nRF52 feather board, which can be programmed with the Arduino IDE (but not PlatformIO yet, unfortunately). I've got a working beacon on it, but now I run into some of the challenges I need to sort out. It's been interesting because I have no experience with Bluetooth except pairing devices to my phone and cursing at them when they don't work. The sketch is surprisingly short, too.

The nRF52 Feather with a locator app

The first challenge is the size limitation of a beacon: 16 bytes as the ID field. I don't know how I'm going to fit multiple sensor readings in that; I still need to write up a quick experiment to play with sizing. There's apparently an additional 27 bytes that can be sent as an advertising response, but this has to be explicitly requested. The beacon can be described as

struct Beacon {
    uint8_t id[16];
    uint8_t major;
    uint8_t minor;

The second challenge has been getting this working from Android. The ke:tai library has Bluetooth support, but it looks like it's limited to connected devices, not advertising devices. I've never really spent any time programming Android, and I've spent almost no time writing Java, so this has been an interesting experience. I kept running into permissions problems on my Android sketches, for example --- not realising I had to include certain Bluetooth permissions. My current test sketch just uses debug printing because my UI skills are still pretty shaky.

Hardware thoughts

At this point, I'm not sure that BLE is the right approach, and might have to look into LoRa or Zigbee. There is no *bee feather from Adafruit, but there is a LoRa one. I'd also been looking at the Particle mesh series, particularly the Xenon, but the next round of boards ships out in September, and I wasn't on that. So, it looks like the feathers for actual, acquirable hardware.

The one thing about LoRa is that I need to add something to the Raspberry Pi to support it, and then figure out how to access said hardware programmatically.

Going forward

There's basically a few options I have going forward:

  1. I can find a way to get the sensor measurements inside the advertising packet. One idea I have for this is using the first four bytes as a node ID, one byte as a sensor ID and three bytes for the reading sequence number (to correlate multiple sensor readings), four bytes with the reading, and the last four as a CRC32 over the first 12 bytes. Then, the sensor will transmit one advertisement for each physical measurement it's taken.

  2. I can compact the readings to fit in 16 bytes --- not likely. This would require a fixed sensor format, which limits what sensors I can use in the network. But, if I did do this, I could use a bit field to indicate which sensors were present so as to tell a 0 as being an actual measurement v. no measurement was taken.

  3. I can switch to a connected format, e.g. having the Raspberry Pi connect to the sensors. Then, my phone would connect to the Raspberry Pi on my internal network. This would enable a larger data transfer. However, Bluetooth on Linux isn't the best, so this could be sketchy.

  4. I can evaluate an alternative mesh radio approach, e.g. using LoRa or Zigbee. I've not worked with LoRa, and I'd rather avoid Zigbee, but these are options. Using these alternative hardware formats means I now have to use the Raspberry Pi local-server plan, because my phone doesn't have the hardware to directly interact with the mesh.

I'm glad I went with the tiny demonstrator setup instead of spending a bunch of money on yet more dev boards. It's enough to get me to want to pick up some of my own stuff, though.

I'm probably going to have to invest some time into learning Android dev, because I'm not sure how far Processing will take me.

Tags: , , , ,