LoRaWAN examples update

[HeadBoffin]

LoRaWAN_End_Device.ino and LoRaWAN_End_Device_Reference.ino have been updated & tested to 6.4.2 along with links to the coming soon wiki and a date & version of test.

I've removed the DevEUI to stop people trying to drink the coffee and to solve the JoinEUI conundrum by putting in the legitimate all zeros EUI. The AppKey & NwkKey have also been sanitised.

Consequently the sketch won't compile until they put their own credentials in. This is how LMIC forces registration to stop the first time user compiling, flashing to device and then wondering why it's working but they can't see anything.

There is a link to the WIP wiki page for LoRaWAN and how to copy over the credentials from TTN.

I have a total noobs sketch that fits in a page that comes with notes on how to register etc. It needs a little more love before release then we can copy those notes over to the wiki as well.

[jgromes]

Thank you for these updates! I left some comments, though nothing major, I think everything can be addressed quite easily, and then we can move onto the 6.4.3 release.

[HeadBoffin]

Thanks for the feedback - there's bits of my working practises, knowing how well maker level users get on with the starter files for LMIC (& others) and trying to keep to the RadioLib style.

The noobs version is radically cut down as a starting point for people to add in functionality as they get to grips with the different function points. It may be that you consider it worth making it the LoRaWAN_End_Device.ino. I'll branch my dev repro and put it up there so you can see my thoughts.

[jgromes]

@HeadBoffin I realized one more thing - because the examples are now intended to not compile without user changes, they will also not compile in CI runs, that's a problem. I think we will need to #define the EUI/keys and wrape them in #ifndef so that we can define them from the CI sketch.

#ifndef LORAWAN_NODE_EUI
#define LORAWAN_NODE_EUI   0x---------------  // hey user, change this!
#endif

And then in CI: arduino-cli compile --build-properties compiler.cpp.extra_flag=-DLORAWAN_NODE_EUI=0x12345678

[HeadBoffin]

Probably best to get you sight of the Noobs version which moves the EUI's & Keys over to a config.h which also automagically selects the board, radio & pins for common kit before hacking on the examples more.

[HeadBoffin]

I've added the starter code - it is very much Work in Progress so please don't get in the weeds and I've not implemented ifdefs as suggested above - but the two* general concepts are:

1. One screen full of code
2. Separate config / support file
3. Accompanying notes in the sketch folder

In the Arduino IDE these open in three tabs.

The Next Steps sketch will do downlinks (change uplink rate and a parameter) and sleep. And an accompanying one will add an I2C device.

How do peeps feel about this?

• off by one error

[jgromes]

but the two* general concepts are

So far I've been trying to keep the examples somewhat limited in scope, without additional documentation, trying to avoid overloading new users. But I guess we can try out a slightly different approach and see how it works for out. If it does, perhaps it can be adopted in other examples as well.

And an accompanying one will add an I2C device.

Not sure how I feel about that one, how is an I2C device related to this library? But I'll wait for the finished thing.

[HeadBoffin]

trying to avoid overloading new users.

The Starter file is the bear minimum and I know the notes look a lot, but they are designed to assist the new user with getting to a point where they have their own credentials to fill in and if this is their absolutely first outing with LoRaWAN, ie they heard it was a good thing but they know no more than that, they are signposted to the background information that TTI consider the fundamentals (literally, the entire syllabus for the fundamentals certificate is the Learn section).

Because LoRaWAN isn't just two radios a few meters apart with no external requirements, I feel the overwhelm comes from the first moment they start and can just carry on until they finally hammer in to shape a config that works for them or they learn all the bits that trip people up or they stop.

I get what you mean by the I2C, I'll put that in to the next steps version (with downlinks) so that people can see how they might go about implementing the typical sensors and we can review. For this part two, the supporting notes would be much shorter.

I'll get a revision of the current examples plus finalise the Starter this coming week - I've 100 x LGA-16 to hand place in the coming days so it will likely be the second half.

[ropg]

  uint32_t minimumDelay = 300000;                 // try to send once every 3 minutes

3 minutes would be 180000 ms.

  both.print("[LoRaWAN] Next uplink in ");
  both.print(delayMs/60);
  both.println("s");

and ms / 60 != seconds

[jgromes]

@ropg please add reference to lines you are commenting on, e.g. like so: https://github.com/HeadBoffin/RadioLib_DevCopy/blob/a926d5e13ad6548c683eefce88d52394a05f8115/examples/LoRaWAN/LoRaWAN_End_Device/LoRaWAN_End_Device.ino#L157

Also, the point about 180000ms was already reasied in the review, no need to do so again.

[jgromes]

I've 100 x LGA-16 to hand place in the coming days

@HeadBoffin I do not envy you - of course, take as much time as you need. Thanks for the continued contributions, and for putting thought into this entire thing.

[HeadBoffin]

This is running slightly behind whilst other issues are being attended to ...

[HeadBoffin]

and ms / 60 != seconds

Brain fart because I'm an old fart.

You (@ropg) were asked to comment on the debug function as it seemed to solve the issue you raised about the return value checks / nested ifs. Any thoughts?

[HeadBoffin]

Code fest this weekend - anticipate pushing later on today for feedback fest on Sunday!

[HeadBoffin]

Progress but not quite complete - ABP still needs updating - but I'm getting a little snow-blind as the LW API has some subtleties that catch me out, there is discussion, changes, rework, retesting, rinse & repeat. Which pretty much sums up the last 10 days or so.

I've dropped the End Device example as it is pretty much duplicated by the Starter. They are now appropriately prefixed. The DevEUI, App & NwkKey can now live in the CI config or as a line in PlatformIO.ini as required.

If you see some gross errors or are deeply unhappy with implementation, comment away. If it's more minor stuff, give me a few hours to reset my brain and do the ABP as I may well spot it later this eve or in the AM.

[ropg]

Good work!!

As you can see here, I've been doing some of the same things in a separate library, at exactly the same time. While I think it might make sense to show in examples how to do all this, I think there's also something to be said for providing the persistence functionality for others to simply plug into.

I like the safeguard for when deep sleep fails, that's a good point. I think more generally, we could/should use the ESP32's RTC to see if there's a loose battery wire or something else that's causing repeated cold starts.

[StevenCellist]

Compliments on especially the Starter code, it's looking very very good - and short!
Regarding the ESP32 sketch (also looking very good!), we may want to move it to the Persistence repository, to avoid the earlier mentioned support problems. And then include a short README in the examples/LoRaWAN folder that points to the other repository for anything persistent.

[jgromes]

@HeadBoffin I don't think this example should be in RadioLib - it's specific to ESP32 only. Yes, ESP32 is quite specific in some regards that do have impact on LoRaWAN usage in the most common cases - most notably the fact that it does not retain RAM in deep sleep.

Another point is there are other devices that also have their specifics, and we do not include special examples for those - for example, the LLCC68 radio that only supports some spreading factor/bandwidth combinations, and the user needs to be aware of that to disable ADR and select a valid join data rate.

What I'm specifically trying to avoid is this: https://github.com/StuartsProjects/SX12XX-LoRa/tree/master/examples/SX126x_examples Stuart has a great showcase of various LoRa projects that use cameras, GPS, SD cards etc., but the scope is so wide most of the commits are "update example" or "update readme". Even if that was the design goal of that repository (as stated in its readme), I prefer to focus on either the driver side, or the application side, but not try to cover both in one repository.

For cases with specific hardware (ESP32, LLCC68, CubeCell etc.), we can include some info/links in the wiki. Let's leave it to the community (e.g. @ropg) to provide examples/showcases for specific hardware that can be bit more wide in their scope than RadioLib.

[HeadBoffin]

Stuart has a great showcase of various LoRa projects

Stuart is, in my book, untouchable, so I may have to kill you now for dis'ing him but then I guess you get close with Fossasat so I'll let you off just this once ;-)

All of the above said, the most prevalent boards with LoRa radios on the market are the Lilygo and Heltec offerings so a lot of new users end up with an ESP32 based board and then come unstuck when they find out that it won't work on batteries - LMIC-node being that prime example of leading people down the path to disappointment.

And low power mode is a function of a LoRaWAN device in 99% of use cases so I'd strongly recommend lots of signposting and a repro with the canon examples for people to build on based on the architecture of RadioLib's LoRaWAN. Then support issues can devolve down to "we know this works, other libraries YMMV, go talk to them".

But as a minority user of ESP32 for LW but using it rather a lot for BLE & WiFi gateways but with my eyes on a some nice combos of ESP32+SX1262 that may make it more attractive (hence all the effort), I'm fine with a readme that says go here for more examples.

[jgromes]

Me dis'ing Stuart is not personal, I'm dis'ing everone equally :P I'm sure he's a cool guy.

a readme that says go here for more examples.

Either that or links in examples - fine as well.

[HeadBoffin]

Good work!!

As you can see here, I've been doing some
of the same things in a separate library, at exactly the same time. While I think it might
make sense to show in examples how to do all this, I think there's also something to be
said for providing the persistence functionality for others to simply plug into.

@ropg, it is not a compliment that is followed by a "look at me, look at my stuff". I think this highlights @StevenCellist's comment about the world revolving around your ESP32. To paraphrase Rene Descartes, if the spotlight isn't on you for a second it doesn't mean you cease to exist.

[HeadBoffin]

@jgromes @StevenCellist - can we merge LoRaWAN_Starter and LoRaWAN_Reference in the meanwhile?

[jgromes]

@HeadBoffin I think it can remain as-is; IIRC LoRaWAN_Reference was supposed to show off most of the implemented LoRaWAN functionality, whereas the goal of LoraWAN_Start was to be ... well, the starter sketch. But honestly I don't have a strong preference either way.

[HeadBoffin]

Closing this as the clapper is no longer findable - starting afresh from a branch so peeps can make their own changes