InqBee - LoRa, Battery Powered, Remote Sensor Station

Test Hardware

Start to get some things coming together.  For a hardware rig, I still have the two WeMos boards for testing.  I've added a BMP180 for temperature and pressure and an AHT10 for temperature and humidity.  Basically enough to do a weather station with current and 48 hour weather prediction.

LoRa Library

Have progressed on the LoRa library to handle all the issues of 

• Deep Sleep control
• LoRa sending of the sensor data
• Waiting for Server confirmation
• Node / Server interaction protocol
• RTC data storage of Packet Sequence Number
• TBD - Resend of missed packets
• TBD - Node scheduling of multiple sensor node stations 

Using the library, this is the entire sketch needed to take advantage of these features.  Simply:

1. create a standard C++ struct with all the variables you want to send to the server. 
2. Call the library's constructor with this structure
3. Gather all the sensor data into the structure's variables
4. post() -  This sends the packet, puts it in receive mode and waits for the confirmation.  When received, it puts the node to sleep for the given amount of time.

#include <InqLoRa.h>
#include <Adafruit_AHTX0.h>
#include <Adafruit_BMP085.h>

// Monitor A0 for incoming voltage on ESP8266 only.
ADC_MODE(ADC_VCC);

struct InqBeePost : InqLoRaHeader
{
    u16 Volts;                  // (mV)
    float pressure;             // (mbar)
    float temperatureInside;    // (°C)
    float humidityInside;       // (%M)
    float temperatureOutside;   // (°C)
    u8 humidityOutside;     // (%)
    u8 light;
    u8 weight;
} _data;

InqLoRaNode _loRa(&_data, sizeof(InqBeePost));
Adafruit_BMP085 bmp180;
Adafruit_AHTX0 aht10;       

void setup()
{
    // Update the struct with sensor data as necessary.
    _data.Volts = ESP.getVcc();

    if (aht10.begin())
    {
        dbg(".");
        sensors_event_t humid, temp;
        aht10.getEvent(&humid, &temp);
        _data.temperatureInside = temp.temperature;
        _data.humidityInside = humid.relative_humidity;
    }

    if (bmp180.begin())
    {
        dbg(".");
        _data.temperatureOutside = bmp180.readTemperature();
        _data.pressure = (float) bmp180.readSealevelPressure(666) * 0.01;
    }

    // Send sensor data.
    _loRa.post();
}

void loop() 
{ 
}

The server side isn't full-featured yet, but it does reply and confirm receipt of the packet.  Much to do on it.  It also exposes the data on the web server and here are some GUI dashboards... current conditions and a histogram.

Power Estimates and Battery Life Calculation

But, at this point, I can make some estimates of battery life.  I was able to get some timing for all the steps needed for the packet gathering and sending.  From this topic, I have some pretty good data on power usage of the sensor nodes.

https://forum.dronebotworkshop.com/esp32-esp8266/esp8266-deep-sleep-the-darkness-returns/paged/2/#post-43697

Created a little spreadsheet to calculate the power usage during a typical sensor sending cycle and from the sleep data came up with some pretty impressive battery life.  Of course, I take this with a grain of salt till I start putting one in the field to try.

@inq NOTE, I am not familiar enough with the hardware or compiler designs to 'know' the answer so I will give a generic rule.

When I was designing high performance protocols for the financial markets, I arranged the data structure so that each element fell on it's most efficient boundary. Things like longs on  mod 4. int on mod 2. We could not use float since it was financial data. This was necessary because we also had a lot of byte sized data elements and went out of our way to avoid the extra machine instructions to fetch an int or long variable from an odd address.

We even had some wild tricks to force alignment of external data that was badly aligned. 

EDIT: Whenever we got a new piece of data to manage, I would compile with the option to produce an assembly listing then see how each structure member was accessed. In a few cases the compiler was fooled and produced very inefficient code so we would use pointers and sub structures too re-fool the compiler to force it to use efficient data access code.

Posted by: @zander

↑

@inq NOTE, I am not familiar enough with the hardware or compiler designs to 'know' the answer so I will give a generic rule.

When I was designing high performance protocols for the financial markets, I arranged the data structure so that each element fell on it's most efficient boundary. Things like longs on  mod 4. int on mod 2. We could not use float since it was financial data. This was necessary because we also had a lot of byte sized data elements and went out of our way to avoid the extra machine instructions to fetch an int or long variable from an odd address.

We even had some wild tricks to force alignment of external data that was badly aligned. 

EDIT: Whenever we got a new piece of data to manage, I would compile with the option to produce an assembly listing then see how each structure member was accessed. In a few cases the compiler was fooled and produced very inefficient code so we would use pointers and sub structures too re-fool the compiler to force it to use efficient data access code.

I too used to have to dig around in those minute details about disparate machine representation of data... variable packing preferences and byte ordering (big/little endian).  This one has been optimize for the 4 byte boundaries of ESP8266 (being a 32bit processor).  I'm sure you triggered on the first variable being 2 bytes.  If this was the entire struct, this would would have resulted in a 2 byte padding between u16 Volts and float pressure being inserted.  What you are not seeing (because I didn't show it) is that data struct for that one sensor node inherits another header that the protocol underneath uses to ensure delivery, proper sequence and resend integrity... 

struct InqLoRaHeader
{
    // Order is very specific.  Don't mess with it!
    u32 CRC;
    u32 NodeId;
    u8 SeqNo;
    u8 Command;
};

...is 10 bytes long.  So...  the total struct size is minimized if the first data variable of the "user" portion is 2 bytes long.  The combined struct of "struct InqBeePost : InqLoRaHeader" is 32 bytes long.  Considering there are 31 bytes of variables in the two sub-structs, the trailing 1 byte of padding shows it is fully optimized.  As I might not be so efficient in the future about planning the user struct of some future sensor node using this library, I did also check what the sensitivity of a poorly aligned struct might be.  This example of a very poorly designed struct results in a total struct size of 44 bytes.  

// Sloppy order of struct

struct InqBeePost : InqLoRaHeader
{
      // 2 bytes padding here
    float pressure;             // (mbar)
    u16 Volts;                  // (mV)
      // 2 bytes padding here
    float temperatureInside;    // (°C)
    u8 humidityOutside;     // (%)
      // 3 bytes padding here
    float humidityInside;       // (%M)
    u8 light;
      // 3 bytes padding here
    float temperatureOutside;   // (°C)
    u8 weight;
      // 3 bytes padding here
} _data;

 The turnaround (send and wait for reply) time only goes up 2%.  I don't consider that to be that big of a hit... especially since no matter how lazy (or forgetful) I might become in the future, I can't see how I could possibly design a struct this badly.  🤣

VBR,

Inq

Overnight weather station data

I left it running over night in my office.  Note how sensitive the gauges are over the last hour since I merely walked into the office and started breathing humidity into the room and me and the computer added a little more heat.  No other adjustment to the room was made.

@inq What a coincidence. Our main data structure also looked wrong because it was preceded by 'hdr' data. Every time we got a new hire they would trip over it.

Posted by: @inq

↑

Overnight weather station data

I left it running over night in my office.  Note how sensitive the gauges are over the last hour since I merely walked into the office and started breathing humidity into the room and me and the computer added a little more heat.  No other adjustment to the room was made.

-- attachment is not available --

 

Very impressive. At some point I will want to do that for my garden, and since other people may want the same thing, do you have a source other than ebay for great prices in quantities of 10 for the two sensors?

I assume creating that graph is documented in your Inq stuff?

Posted by: @zander

↑

Very impressive. At some point I will want to do that for my garden, and since other people may want the same thing, do you have a source other than ebay for great prices in quantities of 10 for the two sensors?

I assume creating that graph is documented in your Inq stuff?

They're both extremely common.  Doing a search on your favorite vendor will likely find you tons of hits even cheaper.  Even on Amazon, I consider this to be dirt cheap.

BMP280 (Temperature/Pressure) - https://amz.run/7MlW

AHT10 (Temperature/Humidity) - https://amz.run/7MlX - I used to use the DHT11 and DHT22 in my classes and gave them out like candy.  I bet I got 50% failures with them.  I don't know if students were miss-wiring them, but I even had them go bad in working systems after a while.  I've not had one AHT10 go bad.  They're more accurate and cheaper to boot.

As you can see both sensors are on the same I2C bus and work just fine.

InqStuff 🤣 - (Remember its only on ESP8266) Yes, it is documented in several places on the website.  Even the 5 minute read of the "Quickest Start Guide" here in my signature walks through the whole process all the way to graphing one of your custom published variables (sensor data) and even to the using the wizard to pump out a custom Dashboard webpage.  

But... the InqStuff doesn't support LoRa unless you make a base station with an ESP8266 that has both LoRa and WiFi running like I did in the example above.

VBR,

Inq

@inq Those links are OOS, but a quick search on Amazon.ca turned up 10 AHT10 for $21.52 and 5 BMP280 for $11.99 so a set for $4.55, very reasonable.

You are right, I did miss that lora and wifi aspect.

Since I can't follow the Inq stuff, I will just forget about using Inq and an 8266. Too bad, it looks very cool. Ah well, google is my friend.

Posted by: @zander

↑

@inq Those links are OOS

Well... yeah!  What'd you expect?  You asked for my links.  I don't buy my stuff from Canada to make it easier for you to find.

Posted by: @zander

↑

Ah well, google is my friend.

The graphing is purely web development stuff.  Has nothing to do with Arduino, ESP8266 or InqPortal.  It's a JavaScript library.  There are plenty of free JavaScript libraries to do any kind of graphics, dashboards, dials, gauges etc.  If/when I get the RaspberryPi server working, it'll use the same library for graphing out to a webpage.

@inq They are out of stock in the US using your links, but a simple Amazon Canada search turned up a few dozen more sellers so I have a source, thanks. I thought maybe you were sourcing from eBay which is a big hassle in Canada.

Sorry, I guess I should have explained, my training is pre internet, the only training I ever got in that area was tcp/ip and udp. Knowing all the nitty gritty details of the various headers etc isn't much help to me now plus I have forgot it all in any case. Java to me is coffee.

I did look at some of your samples, but it may as well be written in greek.

Just to put this old dinosaur in perspective, I used to submit searches on 3 part memos in the late 70's, the results would come back a few days later printed on 15 1/2" x 11 1/2" paper and occasionally if I entered a search with too broad a criteria a small hand truck would show up with a few hundred pounds of what was now waste paper, and we did't even re-cycle in those days!

Server Update

Have been working on moving to a Raspberry Pi for a server for the potentially "many" sensor stations.  I've never really worked with a RasPi for development.  I'm actually finding it pleasing.  I'm using a headless RasPi 4B for development and it actually is far faster compiling than Arduino IDE or Visual Studio on an i7 Windows box. 

I chose not to do the full "Recommended Extras" setup, but building C++ projects worked out of the box with JUST the "Desktop" install.  Getting it to work with the LoRa modules was another story.  Because of recent changes for the RasPi 5, there are many breaking changes in Pin I/O libraries and SPI libraries and thus LoRa libraries.  Most libraries are broke, deprecated or the Open-Source developer, abandoned the project.  I did finally find a combination that works and now have a bare bones LoRa server working on the RaspPi.  

LoRa Performance

In that regard I have it working non-stop on a ESP8266, sleeping client to the RasPi  server.  I wanted to give a statistic for anyone contemplating a LoRa project.  

• Delivery is not assured.  If your data HAS to get there every time, you'll need to roll your own TCP like protocol.  (Although the LoRaWan may do that)
• It is basically half-duplex.  You can't receive and send at the same time.  So while the server is sending back a response, it might miss messages from other nodes.
• I have one Node sending a message once / second.  Nothing too demanding.  They are about a meter apart.  
  • Missed messages are about 0.1% of the time.  Good - but not reliable.
  • Corrupted messages (Invalid CRC) are about 0.05% of the time.
  • I'd assume it to get worse with distance... like 300 meters! - I'll update when I get a test rig in that condition.

VBR,

Inq

@inq What library did you end up using? As far as half duplex, can you not spawn multiple server tasks to just listen on a pin and forward the message to a single processor?

Posted by: @zander

↑

@inq What library did you end up using? As far as half duplex, can you not spawn multiple server tasks to just listen on a pin and forward the message to a single processor?

Library - Unfortunately I ended up having to cobble several together.  I've gotten used to the Sandeep Mistry one @dronebot-workshop recommended for our Arduino/ESP's.  Meaning... it seemed to be a pretty clean port.  I found a Github that ported it to RasPi - https://github.com/loraraspi91/LoRa4Raspi .  However, it uses a pin library (wiringPi.h) that has been totally abandoned.  Using this page https://elinux.org/RPi_GPIO_Code_Samples#Direct_register_access , I tried to select one that is still being regularly used, seems to still be supported and has few "Issues".  They're all 3rd party and not supported by the RasPi organization.  Which is very unfortunate.  I finally decided to go with 1.5 pigpio as it has very thorough documentation https://abyz.me.uk/rpi/pigpio/cif.html#spiOpen on how to install and use it.  It also supports interrupt callbacks from its SPI functions.  Many of the other pin libraries did not.  The Sandeep Mistry library did not have code to use interrupts.  You have to poll for a message.  Very fugly!  I found a second LoRa library that uses this pigpio, https://github.com/YandievRuslan/sx1278-LoRa-RaspberryPi .  It would not work for me, after I tried to make the adjustments for North America.  I was able to read the code well enough to use some of its pigpio usage techniques in modifying the Sandeep Mistry version. 

Also note, it appears that the RasPi 5 is using a new/different pin I/O chip than all the previous RasPi's.  What this means - all these pin libraries above and the libraries (like LoRa libraries) that use them will not work on a RasPi 5!  I did not comprehensively research this because I am targeting the low-end of RasPi's.  I'm doing development on a RasPi 4, but will be running these on RaspPi Zero-W's.  I also have a Orange-Pi Zero W showing up.  I look forward to seeing what these clone boards are like.  

Half-Duplex - Nah... its not a problem I can throw software at and fix.  The libraries I've been working with have to put it in TX mode or RX mode... so having a separate thread monitoring it, is not possible.  It's like radios... you have to key the mike and while keyed, you can't receive anything.  I have nodes and servers sending and then immediately going into RX mode.  I have not experimented with contention yet, but even in perfect (6" range) conditions, packets are missed.  So its not a stretch to assume they'll be missed when in TX mode.

VBR,

Inq

Here is the RasPi 4 setup as the sever / development computer.  

Here it is running headless on my Window's desktop.

The ESP8266 "Sensor Node" sending at 1 second intervals (while development) is working out very nicely.  I haven't finished the re-sends communications yet for missed / corrupted messages.  But all the deep sleep, node registering with the server handshaking and primary data sending goals are done.  Currently with polling three sensors (2) Temperature, Humidity, Pressure and supply voltage, sending the packet and waiting for a confirmation takes 45 milli-seconds.  I'm assuming (worse case) it'll get worse with range, but that is yet to be determined.  It should have fantastic battery life.  

I've spent extra effort making the node-side library as lean as possible as I expect to make many of these nodes for different things.  I'm glad I got a 5 pac of LoRa modules.  I already have plans for them:

• One bee-hive
• One for a weather station
• One for the mailbox at about 300 yards away for notification.
• One in the attic to monitor temperature / humidity
• One in the crawl-space to monitor temperature / humidity

Here is total Sketch code.  99% is comments and sensor related... only about 3-lines of code are added to do a LoRa / Deep Sleep solution. 😉 

#include <InqNode.h>
#include <Adafruit_AHTX0.h>
#include <Adafruit_BMP085.h>

// These constants must be filled out ==========================================
// CHANNEL - A InqVault server will listen on one channel.  All nodes talking
//      to that server must use the same channel.
const u32 CHANNEL = 42;             
// FREQUENCY - Must be the same LoRa frequency as your InqVault server and
//      also comply with frequency in your region.  North America = 915000000.
const u32 FREQUENCY = 915000000; 
// META - These are descriptors of the package fields.  Nominally these are
//      sensor data being stored on the InqVault.  They get registered with 
//      the server and are exposed out to your Web Browsers GUIs.  Consists of:
//      <node name>:[<comma delmited field names with (units)>]
const char* META = "InqBee:TemperatureOutside(°C),TemperatureInside(°C),\
HumidityInside(%M),Pressure(mbar),Voltage(V),HumidityOutside(%),Weight(kg),\
Light(lm)";                         
// PACKAGE - A C struct with "float" fields of very value you wish to retain
//      on the InqVault server database.
struct InqBee
{
    float temperatureOutside;   // (°C)
    float temperatureInside;    // (°C)
    float humidityInside;       // (%M)
    float pressure;             // (mbar)
    float voltage;              // (mV)
    float humidityOutside;      // (%)
    float weight;               // (kg)
    float light;                // (lm)
};

// Sensor Declarations =========================================================
ADC_MODE(ADC_VCC);
Adafruit_BMP085 bmp180;     // Uses standard I2C bus - SCL=D1, SDA=D2
Adafruit_AHTX0 aht10;       // Uses standard I2C bus - SCL=D1, SDA=D2

void setup()
{
#ifdef DEBUG
    Serial.begin(115200);
    delay(1000);
    dbg("\n");
#endif
    // Create the package for sending data -------------------------------------
    InqBee* pkg = CreatePackage(InqBee, META, CHANNEL, FREQUENCY);

    // Update the package with sensor data as necessary ------------------------
    pkg->voltage = ESP.getVcc() * 0.01;

    if (aht10.begin())
    {
        sensors_event_t humid, temp;
        aht10.getEvent(&humid, &temp);
        pkg->temperatureInside = temp.temperature;             // °C
        pkg->humidityInside = humid.relative_humidity;         // %M
    }

    if (bmp180.begin())
    {
        pkg->temperatureOutside = bmp180.readTemperature();    // °C
        pkg->pressure = (float) bmp180.readPressure() * 0.01;  // mbar
    }
    
    // Send the package --------------------------------------------------------
    PostPackage();
}

void loop() 
{ 
}