Upcoming Release

[timmbogner]

There are several improvements in this PR:

• RadioLib support -- This library offers expandability to new radio chips, which will be huge. Coming shortly to this PR will be an attempt at SX1262 support, which I'll need help testing.
  This library has also helped me make the LoRa control asynchronous, ie the gateway can use LoRa without blocking other things.
• OLED support -- DBG() messages are now displayed on 128*64 OLED screen courtesy of the ThingPulse SSD1602 library. I did this in a sort of "quick and dirty" manner, and would like to revisit this and improve it fairly soon. I also plan to find an even smaller font for timestamps and re-write some debug statements to be shorter. USE_OLED is only available on the gateway at the time of writing, but I hope to bring it to the node before this is official.
• Changed the way that the user deals with ESP-NOW and LoRa neighbors. There are now dedicated functions sendESPNowNbr(x), sendLoRaNbr(x), and broadcastLoRa(). broadcastLoRa is how the gateway will address LoRa controllers. Controller nodes listening to (paired with) this gateway's address will receive these transmissions. This functionality is not enabled in nodes yet (at the time of writing), as I've been focused on the gateway.
• Splitting and re-organization of the header files. -- I'm trying to make FDRS easier to read through and tinker with. There may be additional filename changes still to come.
• Buffers are pretty much gone. They were messy. I don't think many people needed to buffer their ESP-NOW transmissions, but if you were using that feature, contact me!
• LoRa buffering still exists, but the gateway saves up data set for all destinations (neighbors 1 & 2, plus broadcast) and sends them in quick succession at a single interval defined in config. At the end of the transmissions, the gateway will display the time elapsed since the first transmission began. The idea here is to keep the transmissions in one block, making channel activity detection less tedious for everyone (when it is added). Ping responses and receipt acknowledgments will still occur on-demand.
• The timer used for releasing LoRa can also be used to schedule user-defined functions. This will make it possible for gateways to send their own DataReadings. scheduleFDRS(functionName, interval)

Some things I will add before publishing this will be ESP32 LR mode support, the aforementioned SX1262 test, and ethernet support (if all goes well). There are also a whole lot of documentation updates that will be made sometime.

[aviateur17]

There are several improvements in this PR:

• OLED support -- DBG() messages are now displayed on 128*64 OLED screen courtesy of the ThingPulse SSD1602 library. I did this in a sort of "quick and dirty" manner, and would like to revisit this and improve it fairly soon. I also plan to find an even smaller font for timestamps and re-write some debug statements to be shorter. USE_OLED is only available on the gateway at the time of writing, but I hope to bring it to the node before this is official.

Just enabled the OLED display and love it. Thanks for adding that feature. I'm using the LoRa Hallard shield (https://github.com/hallard/WeMos-Lora) with RM95W LoRa chip, some EEPROM, 2 Neopixels, a button, and SSD 1306 display so it's nice to be able to use those features. I'm thinking of adding some use to those Neopixels soonish.

[aviateur17]

@timmbogner, I'm curious why you included the OLED library into the package instead of referencing as another external library? I'm wondering if we can move it out of the src folder into another folder like utility or include but haven't found anything yet. Most other libraries don't include external libraries and require separate download. That is the nice part of including with the package as a separate download is not required before compile.

[timmbogner]

It's mostly because I needed to modify/add a function inside the library to get it to work how I wanted it to. I was under the impression it was more common to include open source (MIT licensed) libraries with another repo, but perhaps I'm mistaken. Looking around I don't see as many libraries including other libraries as I would have expected. I tried to look at how Meshtastic does it, but I can't really make heads or tails of their source at my skill level.

The easy solution would be to make a function that handles line-breaks outside of the library, then use the library's regular text plotting function to plot the lines. I just had a lot of other tasks to jump to after I added OLED, and was impatient to get it working.

[aviateur17]

It's mostly because I needed to modify/add a function inside the library to get it to work how I wanted it to. I was under the impression it was more common to include open source (MIT licensed) libraries with another repo, but perhaps I'm mistaken. Looking around I don't see as many libraries including other libraries as I would have expected. I tried to look at how Meshtastic does it, but I can't really make heads or tails of their source at my skill level.

The easy solution would be to make a function that handles line-breaks outside of the library, then use the library's regular text plotting function to plot the lines. I just had a lot of other tasks to jump to after I added OLED, and was impatient to get it working.

No worries, just curious. Not a big deal at all. In VS Code you can have an include folder and stuff all your external libraries in that include folder that way they do not need to be downloaded or you can stick with a particular version of a library or modify like you mentioned and just stay with it. I don't see anything similar to that include folder in the standard Arduino libraries. I'm thinking about adding some "rotating screens" to the OLED. I have some code that periodically changes from a page of debug output to a page of overall status and then a blank page and then back to debug again and over and over. I'm also thinking about shortening all the DBG output to be more OLED friendly.

[timmbogner]

Forgot to address

I'm wondering if we can move it out of the src folder into another folder like utility or include but haven't found anything yet.

My understanding was that it would have to be in the src folder for Arduino to find it. There may be a way to tuck it away a little better, like 'src/includes/oled_library/', but I couldn't figure it out.

If it were kosher, I'd love to include all of the dependencies in the FDRS package. Technically they're all MIT licensed, but I think I'd want to contact the authors first. ThingPulse has been a long-time supporter of the project, and I did send Squix a message about doing this.

I'm thinking about adding some "rotating screens" to the OLED. I have some code that periodically changes from a page of debug output to a page of overall status and then a blank page and then back to debug again and over and over. I'm also thinking about shortening all the DBG output to be more OLED friendly.

I like it... I want to change debugConfig to display everything very compact on an OLED, ideally splitting the display into two even columns, and also formatted to not look horrible on a console.

A feature to keep in mind with this: When a DBG() comes in, it should flash back to the console display. The alternate data displays could be thought of as a screensaver (and actually utilized, since burn-in/fading is an issue with these). It would also be good to have an option to blank the screen after inactivity. Eventually it could be taken a step further and we could power down the OLED with a GPIO when idle... not sure how much power that would actually save though.