I’ve made my Pro Micro/Mini ISP breakout board and Raspberry Pi nRF24L01+ breakout board as per my previous post and decided to get on with trying out RF24Mesh. The problem there was that with the newer commits to RF24 and RF24Network, I was getting no response from the Arduino’s to the RPi.

After some debugging with the author of the libraries on GitHub, we managed to find the culprit – not really the clone issue or the differing module issue, but actually a bit of an oddity in how dynamic payloads and dynamic ACKs work together. So with the Development branch re-opened, we now have the modules talking again. It may need some more work to get mesh working though. So for now I’m sticking to RF24Network, not RF24Mesh.

I’ve migrated all of my various sensor modules to a more streamlined setup – essentially there’s a daemon listening on the Pi which directly populates the database now, rather than the previous separate cronjob. It also handles taking measurements from the DS18B20 sensor on the Pi breakout. The daemon also accepts TCP connections should I want to use an ESP8266 sensor, its also handy for debugging using netcat. Each module sends each sensor reading separately, so each RF24 transmission is under 16 bytes long, rather than pushing the 32 byte limit.

One of my new modules is a 3.3v 8MHz Pro Mini 328, from which I have removed the LED’s and regulator to drop the current use. I’ve also configured its fuses and boards.txt to run at 1MHz from the internal oscillator and set all unused digital pins to INPUT_PULLUP. Now its using under 4uA at sleep. The boards.txt entry looks like:

promini1mhz.name=Pro Mini 328 (1.8v, 1MHz internal osc, BOD off)
promini1mhz.upload.maximum_size=30720
promini1mhz.upload.maximum_data_size=2048
promini1mhz.upload.speed=9600
promini1mhz.upload.protocol=usbasp
promini1mhz.upload.using=usbasp
promini1mhz.bootloader.low_fuses=0x62
promini1mhz.bootloader.high_fuses=0xD4
promini1mhz.bootloader.extended_fuses=0x07
promini1mhz.bootloader.unlock_bits=0x3F
promini1mhz.bootloader.lock_bits=0x0F
promini1mhz.bootloader.path=atmega
promini1mhz.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
promini1mhz.build.mcu=atmega328p
promini1mhz.build.f_cpu=1000000L
promini1mhz.build.core=arduino
promini1mhz.build.variant=standard

I then added the BH1750FVI light sensor to the circuit and found that the sleep current was the same as when it was awake taking readings, about 110-145uA, instead of 5uA the manufacturers claim. So I switched to using the BH1750FVI library as it had better sleep support. Alas that didn’t fix things and I decided the module simply wasn’t sleeping. After some reading of the datasheet and playing with code I finally figured out that after calling power_on and reset to wake the device from a power_down, you have to set the resolution mode again. I also found that disabling the pullup resistors on the I2C pins helps, as the module already has internal pullups. I’ve tested it down to 1.5v, which is quite far below any of the components ratings, but it works….

// include libraries
#include <Wire.h>
#include <BH1750FVI.h>
#include <RF24.h>
#include <RF24Network.h>
#include <SPI.h>
#include <LowPower.h>

// global vars
BH1750FVI lightMeter;

// init network ce,csn
RF24 radio(9,10);
RF24Network network(radio);
const uint16_t this_node = 4;
const uint16_t other_node = 0;

void gotoSleep()
{
    // sleep radio
    radio.powerDown();

    // sleep mcu for 225x8/60=30mins
    for(int i=0; i<225; i++)
    {
        LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);
    }

    // wake radio and sensor
    radio.powerUp();
    lightMeter.Reset();
    lightMeter.SetMode(OneTime_H_resolution_Mode);
    delay(200);
}

void setup(void)
{
    // set unused digital pins to input pullups to save power
    const int unusedPins[] = {0,1,2,3,4,5,6,7,8,14,15,16,17};
    for (int i=0; i < 13; i++)
    {
        pinMode(unusedPins[i], INPUT_PULLUP);
    }

    // init sensor
    lightMeter.begin();
    lightMeter.SetAddress(Device_Address_L);
    lightMeter.SetMode(OneTime_H_resolution_Mode);

    // disable pullups as sensor already has them
    pinMode(SDA, INPUT); // a4
    pinMode(SCL, INPUT); // a5

    // init radio
    SPI.begin();
    radio.begin();
    network.begin(90, this_node);
    radio.setRetries(15,15);
    radio.setDataRate(RF24_250KBPS);
    radio.setPALevel(RF24_PA_MAX);
}

void loop()
{
    // pump network
    network.update();

    // take a sensor reading, pad to 2dp
    long lux = lightMeter.GetLightIntensity() * 100;
    if (lux == 0)
    {
        // take another reading, its not ready
        delay(200);
        lux = lightMeter.GetLightIntensity() * 100;
    }

    // create data structure - bh1750=type11
    char txBuffer[16] = "";
    sprintf(txBuffer,"%d;%d;%ld",this_node,11,lux);

    // transmit
    RF24NetworkHeader header(other_node);
    network.write(header,&txBuffer,sizeof(txBuffer));

    // sleep
    gotoSleep();
}

I finally got my hands on a Particle Photon. However I found a bug in the way it reports its error status to dfu-util, it flashes ok but says it hasn’t. The fix is in 0.4.5 but requires a bootloader ID upgrade, so it won’t be 100% fixed until 0.4.6, unless I get a JTAG programmer to set it in the meantime. Otherwise it seems to be more mature than the Spark Core – well they fixed most of the issues there before working on the HAL for the Photon I guess.

I’ve also started playing with an MRFC522 RFID reader/writer and some cards/keyrings – worrying how easy it is to clone those things! I’ve also got some HC-05 Bluetooth modules to play with next.

We’ve also made a few commits to arduino-mk this month.