Categories
arduino particle

Moteino -> Arduino Nano -> Particle Boron ->Particle Cloud

I’ve been working on Particle devices, specifically trying to build RFM69 gateways with them for battery-powered sensors. This cool guy forked the LowPowerLab.com library for use with the Particle Photon, which works perfectly. However, I want to use the Particle Boron, which is an LTE-enabled microcontroller (I can’t access wifi where it’s meant to be deployed). The Boron is a 3rd Gen Particle device and is does not compile with the aforementioned library, which stinks (and I’m not knowledgeable enough on RFM69 to fix it). But – I am able to use an RFM69 breakout with an Arduino Nano, and I am able to have the Nano communicate with the Boron via serial – so, I chained them up that way. And it works!

Nano to Boron to Particle Cloud
Nano to Boron to Particle Cloud

So the impetus for all of this is that I need a reliable (and enterprise-friendly) backend to sensor networks, and Particle seems really great. But, I need my sensors to be able to run on batteries (a wall plug isn’t always available) for a long time and be able to communicate readings back from a decent distance while still not using much energy from the batteries (RFM69 is good in this regard, wifi is bad, both on energy and distance). I am using Moteino right now for the sensors (although the idea is to eventually create custom PCB’s). The sensor below is using a VL53L0X breakout to measure distance – in the previous screenshot you can see the data being transmitted: [2] (node #) 30.00(mm distance), -32 (RSSI). When the sensor is actually in the field, it won’t have the FTDI connector, it’ll have two lithium AA’s.

moteino sensor
moteino sensor

I realize that this isn’t any great breakthrough, but I was pretty happy that I can now deploy the gateway and maybe attack the library issue later.

Categories
arduino Uncategorized

Converting Radiohead ASK Transmissions to ASCII

This is a quick one, mostly because I don’t want to forget it. I’ve been playing with rtl_433 (a super-easy SDR package), and have been piping all of the transmissions received to a local mosquitto server to be used within node-red. I run this command to start receiving:

rtl_433 -F json -M utc | mosquitto_pub -t home/rtl_433 -l -h localhost

Once that’s running, you can add the MQTT node in node-red, using topic “home/rtl_433”. If you’re lucky, you’ll start getting semi-interesting stuff right away (I get inundated with signals from tire pressure systems). I noticed that when I was testing 433Mhz transmissions with the RadioHead library on Arduino, I would get these transmissions:

{"time":"2019-06-13 13:31:52","model":"RadioHead ASK","len":29,"to":255,"from":255,"id":0,"flags":0,"payload":[87,101,108,99,111,109,101,32,116,111,32,116,104,101,32,87,111,114,107,115,104,111,112,32,100,117,100,101,33],"mic":"CRC"}

This was really welcome at the time because I was having a difficult time with the hardware receivers.  The problem is that the payload is received in ASCII, so we need a way to decipher it in node-red, and there is not a pre-made node built to handle this (surprisingly). This snippet within a function node did the trick for me.

var stream = msg.payload.payload;		
msg.payload = String.fromCharCode.apply(null, stream);
return msg;

This converts the array of ASCII values into a readable string.

Welcome to the Workshop!

Now that we’ve got that, we can use the RadioHead library and the cheap 433Mhz transmitters to send something meaningful and have it acted upon within node-red. Thanks to DroneBot Workshop for the transmitter code and thanks to Steve’s Internet Guide for node-red javascript function help.

UPDATE: If you use commas to separate what you’re sending, here’s the code that you want. This examples just has two elements.

var output = msg.payload.split(",");
msg.payload = {
    id :output[0],
    range : output[1] 
}
return msg;