LoRa Controllers Added

[timmbogner]

I have added the ability for a gateway to send a LoRa broadcast packet (addressed to 0xFFFF) via broadcastLoRa(). LoRa nodes are now able to listen for broadcast packets, and check them for any reading IDs they're subscribed to. There is no peer registration for LoRa as there is in ESP-NOW, but you do need to run addFDRS();
One change to note is that addFDRS() now only needs to be given the function name, no timeout. So it'll be: addFDRS(fdrs_recv_cb);

At this moment there are small things to polish up, like disabling ACK for broadcasts. I still want to encourage folks to try this and send me feedback if possible!

@lamasseriadipolverara

[timmbogner]

@aviateur17 besides disabling ACK for broadcasts, do you see any issues with my LoRa changes? I pretty much just copy/pasted the gateway version of getLoRa() over the node version, then made some tweaks to make it work.

[timmbogner]

Oh, I see now that I accidentally linked the gateway code instead of the node in my comment above. Sorry about the confusion.

[aviateur17]

@timmbogner, Seems to work. I have Sensor sending ESPNOW message to gateway and then gateway sending Lora broadcast and controller is receiving the broadcasts. I would think you could easily handle disabling the Lora broadcast ACKs in the transmitLoRa function:

Insert following into line 186 of fdrs_gateway_lora.h before the pkt[] lines

if(*destMac == 0xFFFF) { calcCRC = crc16_update(calcCRC, 0xA1); }

That will recalculate the CRC with the known value indicating no ACK should be sent.

[aviateur17]

Tested that code out in gateway and it does work such that the controller knows the gateway does not want an ACK.

Incoming LoRa. Size: 20 Bytes, RSSI: -59.00dBm, SNR: 10.00dB, PacketCRC: 0xb3ef, Total LoRa received: 5, CRC Ok Pct 100.00%
Node address 0xeeee(hex) does not want ACK

[aviateur17]

Submitted PR #136 to add above code.

[timmbogner]

Perfect, thanks! I knew it was simple... and involved A1 sauce.

[aviateur17]

@timmbogner, I have some additional LoRa functionality that I'd like to add to the project.

1. I'd like to change the transmitLoRa functions on the sensor so that they return whatever CRC result is generated, if any, in order to be more robust. That result can be used to generate better messaging around LoRa transmit success or failure.
2. I'd also like to add back the ability for the LoRa sensor to ping the gateway and return the result. I have these two features ready to go now.
3. I'd like to add the functionality for the gateway using LoRa to ping nodes
4. I'd also like to work on adding NTP to the WiFi gateways and sending the time to LoRa and ESP NOW nodes.

If that works for you I'll submit the PRs within the next few days.

Jeff

[timmbogner]

This is super fun. Thanks for fixing it up.
Ping times: 3ms ESP-NOW vs 97ms LoRa. I look forward to tweaking LoRa configs to see how they affect ping times.
Two additions this brings to mind:

1. Ping will be useful to investigate range using an OLED. I might add RSSI/SNR-type stats in the DBG as well.
2. For my OLED header and your LoRa debugs, there is often a need to display dropped hex zeros (aa:bb:cc:dd:ee:1). I figure I can make a function to fix this somehow. Is there a common solution I'm missing before I try to DIY?

[aviateur17]

2. For my OLED header and your LoRa debugs, there is often a need to display dropped hex zeros (aa:bb:cc:dd:ee:1). I figure I can make a function to fix this somehow. Is there a common solution I'm missing before I try to DIY?

I was thinking the same thing about the debugs and OLED screen and limited characters. I agree that one ESP-NOW ping can be reduced to the last octet. It's nice to have the long descriptions but it is a pain to fit them on the small screen. I was creating a project that had a function to wrap the lines after a certain number of characters and store messages in a buffer so that the screen could "rotate" or cycle between different "views" or pages. I think that may be an option and some of my code may be reusable. The other option would be to limit all the debug lines and that would be my least preferred option in my mind. Also could add a second line of debug any time OLED messages are helpful and just have an abbreviated message in those second OLED debug lines.

[timmbogner]

I agree on everything... generally I like having extra info in the DBGs, but now with OLED there will have to be more thought about brevity throughout all of the debug messages. However I actually meant in this case I wanted to add the extra zero digit, it throws me off to see it displayed without it. I think my preferred readout would be ESP-NOW Ping ... from 0x01. Similarly, in the corner of the OLED header there's a gateway's mac, which I'd like to say "MAC: 0x01" or even just "01" (currently says "MAC: 1") for clarity to beginners. What I meant was a simple function to add the "0x" and leading zero when needed.

But you still bring up something that needs to be dealt with. To accomplish the line breaks and make things look right I modified the existing line breaking function in the OLED library to work how I wanted. This is why the 1306 library comes packaged with the source now (though I plan to do it for all dependencies if allowed by licenses). I've been planning to make line-breaking functions that work more universally. If you have some code or a plan to make the OLED debug console work better, I'm all ears. It's definitely half-done.

At some point I want to find an even slimmer font for numbers, just to save a little space on timestamps.

[aviateur17]

2. For my OLED header and your LoRa debugs, there is often a need to display dropped hex zeros (aa:bb:cc:dd:ee:1). I figure I can make a function to fix this somehow. Is there a common solution I'm missing before I try to DIY?

I was looking into a way to add leading zeroes to the hex values and it turns out that I don't think it really can be done without a big hassle. The articles say that we really shouldn't be using String() in Arduino and instead use const char * because Strings use more memory, are limited in what you can do, and I think they can cause heap fragmentation. I'll link to a couple search results below:
https://forum.arduino.cc/t/adding-leading-zeros-to-hex/112146/5
arduino/ArduinoCore-API#40

[timmbogner]

I've known strings aren't the best, but I was told my implementation was pretty safe. Replacing them all would probably be a really arduous task.

[aviateur17]

Probably another off topic comment but since the code was split into different modules it would be nice to get all those ifdefs out of the functions and at a higher level like at the #include level. I was trying a bit of that last night as I was writing the NTP code and it would involve a bit of work so that will probably also be some goal of mine. Having those inside functions are distracting. I know some of that is not avoidable but I'd like to get as much out of the code as possible.

[timmbogner]

Hate to take this even further off topic, but speaking of files: Do you think fdrs_gateway_wifi.h should be renamed fdrs_gateway_tcpip.h or something, to reflect that it now covers ethernet as well?

[aviateur17]

or fdrs_gateway_net.h Unless you think there is enough code to split those two into different files. But for one file maybe fdrs_gateway_net.h

[timmbogner]

May be worth splitting, come to think of it.

The question may pop up again though, because currently USE_ETHERNET just enables USE_WIFI. However, logically there should be a separate USE_NET so that USE_WIFI can be disabled. I would say USE_MQTT, but I may want to add HTTP requests someday. So then it would be: USE_ETHERNET and USE_WIFI both enable USE_NET. Then (someday) there might separately be USE_MQTT and USE_HTTP to choose from as well. I don't know if I'll do anything with this in the new release (def not the HTTP part), but that's my general plan for that.

There will be USE_CELLULAR eventually to add an extra module.

[aviateur17]

With all of those options and associated default values and adjustable parameters might have to implement a front end menu system to allow user to select requirements and set default parameter values. Something similar to the Linux kernel configuration or DietPi configuration comes to mind. But that is probably awhile down the road.

[timmbogner]

Similar to a BIOS setup screen or more of a step-by-step process? It would be neat.
WLED and other projects have the ability to flash a device through the browser, which I've always thought was cool. Seems like that could pair with your idea.
Would a browser-based config file maker with forms be achievable through JavaScript? Not building/flashing it, but just making the config.h? I haven't used JS in ages, there's probably a better way now.

[aviateur17]

@timmbogner, I have a question on LoRa addressing. It seems that the LoRa node addresses are randomly picked. I'm trying to understand the code below in fdrs_gateway_lora.h:
uint16_t LoRa1 = ((mac_prefix[4] << 8) | LORA_NEIGHBOR_1);
uint16_t LoRa2 = ((mac_prefix[4] << 8) | LORA_NEIGHBOR_2);

That seems to be a fixed LoRa address used below in that file for sending asynchronous LoRa buffer data - Line 500:
transmitLoRa(&LoRa1, &LORA1Buffer.buffer[tx_buffer_position], lora_size);

If LoRa addresses are random I'm not understanding how this was intended to work. I know the Reading IDs are fixed and manually added but transmitLoRa doesn't send data to the reading ID it sends to the LoRa node address.

[timmbogner]

LoRa nodes have random addresses, but LoRa gateways have fixed and assigned addresses same as ESP-NOW. LoRa1 is always a gateway, so it's not an issue.

[aviateur17]

Excellent - thanks for the clarification! So would be used for communication between two gateways that both use LoRa to share data.

[PerRieland]

I’m having issues with the LoRa communication.
My setup is a MQTT gateway trying to communicate with a LoRa controller / sensor.

All compiles fine. MQTT gateway connects to MQTT server fine.
I’m using the examples 0_MQTT_Gateway and LoRa_Controller.

When sending MQTT commands to 0_MQTT_Gateway, from MQTT server:
13:24:55.833 -> Connecting MQTT...
13:24:55.881 -> MQTT Connected
13:25:03.484 -> fdrs/command
13:25:03.484 -> Incoming MQTT.
13:25:03.484 -> Sending to LoRa broadcast buffer
13:25:04.264 -> Transmitting LoRa message of size 13 bytes with CRC 0xa1c1 to LoRa MAC 0xffff
LoRa_Controller seems that it is not getting the transmitting data. Only these startup message show up:
13:25:03.518 -> FDRS User Node initializing...
13:25:03.518 -> Reading ID 2
13:25:03.518 -> Gateway: 0
13:25:03.518 -> RadioLib initialization successful!
13:25:03.518 -> LoRa Initialized. Frequency: 434.00 Bandwidth: 125.00 SF: 7 CR: 5 SyncWord: 18 Tx Power: 5dBm
13:25:03.519 -> LoRa node address is ffff (hex).
13:25:03.519 -> Transmitting LoRa message of size 11 bytes with CRC 0xc1e5 to destination 0xee00
13:25:03.519 -> LoRa ping sent to address: 0xee00
13:25:03.812 -> No LoRa ping returned within 1000ms.
13:25:03.812 -> Subscribing to DataReading ID 2

What am I missing, to make MQTT Gateway send data to the LoRa controller ?

Here are my config files.
0_MQTT_Gateway : fdrs_gateway_config.h
// FARM DATA RELAY SYSTEM
//
// GATEWAY CONFIGURATION

//Addresses
#define UNIT_MAC 0x00 // The address of this gateway

#define ESPNOW_NEIGHBOR_1 0x00 // Address of ESP-NOW neighbor #1
#define ESPNOW_NEIGHBOR_2 0x00 // Address of ESP-NOW neighbor #2
#define LORA_NEIGHBOR_1 0x00 // Address of LoRa neighbor #1
#define LORA_NEIGHBOR_2 0x00 // Address of LoRa neighbor #2

// Interfaces
//#define USE_ESPNOW
#define USE_LORA
#define USE_WIFI // Will cause errors if used with ESP-NOW. Use a serial link instead!
//#define USE_ETHERNET

// Routing
// Options: sendESPNowNbr(1 or 2); sendESPNowPeers(); sendLoRaNbr(1 or 2); broadcastLoRa(); sendSerial(); sendMQTT();
#define ESPNOWG_ACT
#define LORAG_ACT sendMQTT();
#define SERIAL_ACT
#define MQTT_ACT broadcastLoRa();
#define INTERNAL_ACT sendMQTT();
#define ESPNOW1_ACT
#define ESPNOW2_ACT
#define LORA1_ACT
#define LORA2_ACT

// LoRa Configuration
#define RADIOLIB_MODULE SX1262
#define LORA_SS 8
#define LORA_RST 12
#define LORA_DIO 14
#define LORA_BUSY 33
#define USE_SX126X

#define LORA_TXPWR 5 // LoRa TX power in dBm (: +2dBm - +17dBm (for SX1276-7) +20dBm (for SX1278))

//#define CUSTOM_SPI
#define LORA_SPI_SCK 5
#define LORA_SPI_MISO 19
#define LORA_SPI_MOSI 27

#define FDRS_DEBUG // Enable USB-Serial debugging

LoRa_Controller : fdrs_node.h
// FARM DATA RELAY SYSTEM
// Node Configuration

#include <fdrs_globals.h>

#define READING_ID 2 //Unique ID for this sensor
#define GTWY_MAC 0x00 //Address of the nearest gateway

//#define USE_ESPNOW
#define USE_LORA
//#define DEEP_SLEEP
//#define POWER_CTRL 14
#define FDRS_DEBUG

// LoRa Configuration
#define RADIOLIB_MODULE SX1262
#define LORA_SS 8
#define LORA_RST 12
#define LORA_DIO 14
#define LORA_BUSY 33
#define USE_SX126X

#define LORA_TXPWR 5 // LoRa TX power in dBm (: +2dBm - +17dBm (for SX1276-7) +20dBm (for SX1278))
#define LORA_ACK // Request LoRa acknowledgment.

[timmbogner]

Hi Per,
What module are you using? Your configs look like the Heltec LoRa32, but the BUSY pin should be 13 for that module (at least on my v3).

13:25:03.519 -> LoRa node address is ffff (hex).

Does it always say it is ffff? If so that might be an issue, though not necessarily the issue at hand. (it should be random)

[PerRieland]

Wuuhuu, you are good. Setting the busy pin to 13 solve the issue right a way.

[timmbogner]

[PerRieland]

I’m struggling a bit with the LoRa_Controller example. My goal is to let a MQTT message trigger a relay, using LoRa technology. I am starting from the 0_MQTT_Gateway and LoRa_Controller examples.

Here is my setup:
(MQTT server) <=1=> (0_MQTT_Gateway) <=2=> (LoRa_Controller)

Message from MQTT server: [{"id": 2,"type": 0,"data": 1}]
Communication 1: Working - OK.
Communication 2: LoRa can Ping Gateway, OK

My Issue is that the LoRa_Controller callback function “fdrs_recv_cb“ doesn't get called when the 0_MQTT_Gateway broadcasts the message.

What am I missing, to get the callback function “fdrs_recv_cb“ called ?

fdrs_gateway_config.h:
#define UNIT_MAC 0x00 // The address of this gateway

// Interfaces
#define USE_LORA
#define USE_WIFI

// Routing
// Options: sendESPNowNbr(1 or 2); sendESPNowPeers(); sendLoRaNbr(1 or 2); broadcastLoRa(); sendSerial(); sendMQTT();
#define LORAG_ACT sendMQTT();
#define MQTT_ACT broadcastLoRa();

---

fdrs_node_config.h:
#define READING_ID 2 //Unique ID for this sensor
#define GTWY_MAC 0x00 //Address of the nearest gateway
#define USE_LORA
#define FDRS_DEBUG

[timmbogner]

LoRa airtime of 1ms doesn't look right. I'll get back to you tonight! (~12hrs)

[timmbogner]

Unfortunately this does seem to be some new issue that must have happened recently. I'll investigate tomorrow and fix whatever's wrong.

[PerRieland]

Great, I would love to help out in anyway I can

[timmbogner]

That was simpler than I expected, just an error I made the other day. My apologies, please try again with the most recent commit.

[PerRieland]

What can I say. It's just working ;)
For the example "Irrigation", I needed to add loopFDRS(); in the loop function.
Thanks for your quick response :)