LW examples updated for new initialisation / join sequence

[HeadBoffin]

Somewhere we need to make it clear that we've put in some breaking changes - not a whole rework required but the startup sequence is so much clearer now - setup keys, restore NVM as appropriate, enough feedback to know what will happen next when you activateXXX.

The previous flow was OK but got messy when debugging edge cases so this mostly this informs the more savvy developer what is going on.

It will also make it easier to do "interesting" things like maintain more than one session with different backends - useful when switching networks if you are moving and/or a device switches, fails to join and switches back, or a backup session is in place.

ALSO: Some of the pinmaps were borked, I've fixed the ones I originally made so that they work again and kept the new entries but marked them as needing review

[HeadBoffin]

Plus the error codes are printed in plain text if using the debug() function

[StevenCellist]

LGTM. The board definitions are still something that need work; I will check my box of boards to make sure that whatever is in there works with the current state of config.h before merging.

[jgromes]

Without wishing to block this PR, I cannot help but notice:

Some of the pinmaps were borked

The board definitions are still something that need work; I will check my box of boards

Maybe this board definition automagic thing isn't working out...

[HeadBoffin]

Maybe this board definition automagic thing isn't working out...

Worked fine for years when it was only on my SSD's. I put in ones from boards I had and can test. And it's continued to work just fine since - I swap boards a lot - like I have most of those boards online somewhere on my desk and I just hit the compile & upload button.

Other contributors adding pinmaps that they were given by other sources means we are two steps away from knowing their provenance. Some of the board defines don't jibe with what I see else where & there were some duplicates. So I've disabled the ones I can't immediately test or validate right now.

I believe that is the source of the problem, not the actual system.

[HeadBoffin]

Additional: We run a Pi on my desk that has up to four boards plugged in for testing using PIO Remote, so re-validation with the aid of loud music, snax & beer is feasible but only warranted as an excuse for loud music, snax & beer.

[StevenCellist]

I disagree that this would work just fine even if contributors tested themselves. To demonstrate, here are the Heltec board defines as per the esp32 package for Arduino IDE:

heltec_wifi_32_lora_V3
heltec_wifi_kit_32
heltec_wifi_kit_32_V3
heltec_wifi_lora_32
heltec_wifi_lora_32_V2
heltec_wireless_stick
heltec_wireless_stick_LITE

Next, as per the Heltec-esp32 package for Arduino IDE:

HELTEC_WIFI_KIT_32
HELTEC_WIFI_KIT_32_V3
HELTEC_WIFI_LORA_32
HELTEC_WIFI_LORA_32_V2
HELTEC_WIFI_LORA_32_V3
HELTEC_WIRELESS_PAPER
HELTEC_WIRELESS_SHELL_V3
HELTEC_WIRELESS_STICK
HELTEC_WIRELESS_STICK_LITE
HELTEC_WIRELESS_STICK_LITE_V3
HELTEC_WIRELESS_STICK_V3
HELTEC_WIRELESS_TRACKER

But then, there is PIO:

heltec_wifi_32_lora_V3
heltec_wifi_kit_32
heltec_wifi_kit_32_V3
heltec_wifi_lora_32
heltec_wifi_lora_32_V2
heltec_wireless_stick
heltec_wireless_stick_LITE
Wireless_Track

This doesn't make sense, and I don't see a nice way to make it work automagically for all users regardless of how they use RadioLib. Heltec and PIO define the Tracker, Arduino doesn't. Arduino and Heltec define the Stick Lite V3, PIO doesn't. Etc. etc...

While I myself profit from the autoselect for PIO remote and also local testing, I think that is a feature that a user must implement themselves as it is too dependent on their environment. We are probably better of providing a nice table that provides all the pins and the radio that's on board, so that users can enter those themselves.. something like this:

#define RADIO ...
#define CS .
#define RST .
#define DIO0 .
#define BUSY .

// SX1262 table
| Board           | Radio   | CS/NSS | DIO1 | RST | BUSY |
| Stick Lite V3   | SX1262  | a      | b    | c   | d    |

// SX1276/8 table
| Board           | Radio    | CS/NSS | DIO0 | RST | DIO1 |
| Stick Lite      | SX1278   | a      | b    | c   | d    |

[StevenCellist]

After digging through all the Arduino packages and PIO packages, I have identified the following boards:

Arduino-esp32 & PIO-esp32

CubeCell_Board
CubeCell_Board_V2
CubeCell_BoardPlus
CubeCell_BoardPRO
CubeCell_Capsule
CubeCell_GPS
CubeCell_HalfAA
CubeCell_Module
CubeCell_Module_V2
CubeCell_ModulePlus

(these should all be able to use RADIOLIB_BUILTIN_MODULE, I guess)

heltec_wifi_32_lora_V3
heltec_wifi_kit_32
heltec_wifi_kit_32_V3
heltec_wifi_lora_32
heltec_wifi_lora_32_V2
heltec_wireless_stick
heltec_wireless_stick_LITE

TBeam
TBEAM_USE_RADIO_SX1262
TBEAM_USE_RADIO_SX1268
TBEAM_USE_RADIO_SX1276
TBEAM_USE_RADIO_SX1278
TBEAM_USE_RADIO_SX1280
TTGO_LoRa32
TTGO_LoRa32_V1
TTGO_LoRa32_V2
TTGO_LoRa32_v21new

LoPy
LoPy4

Arduino-Heltec (possibly also available in PIO, haven't tried)
Items marked with x are duplicates of the esp32 package, albeit with other casing.

HELTEC_CAPSULE_SENSOR_V3
x HELTEC_WIFI_KIT_32
x HELTEC_WIFI_KIT_32_V3
x HELTEC_WIFI_LORA_32
x HELTEC_WIFI_LORA_32_V2
x HELTEC_WIFI_LORA_32_V3
HELTEC_WIRELESS_BRIDGE
HELTEC_WIRELESS_MINI_SHELL
HELTEC_WIRELESS_PAPER
HELTEC_WIRELESS_SHELL_V3
x HELTEC_WIRELESS_STICK
x HELTEC_WIRELESS_STICK_LITE
HELTEC_WIRELESS_STICK_LITE_V3
HELTEC_WIRELESS_STICK_V3
HELTEC_WIRELESS_TRACKER

The Wireless_Track from previous post was a manual modification from late last year.

By grouping identical pinmaps (CubeCell builtin, some of the Heltec V3 boards), there are 20 to 25 unique boards in here.

[jgromes]

Like I said, I don't want to block this PR, especially since it's intended to sync up examples with the current state of the LoRaWAN implementation. I will merge this as-is and then we can discuss the rest in another thread.

[HeadBoffin]

I disagree that this would work just fine even if contributors tested themselves.

Huh? I'm saying that as almost no one appears to have a handle on all the details, it's clear that contributors aren't in a position to contribute with certainty and I'd rather have two independent people providing the details if it's, well, frankly, not me or either of you. Or one contributor and a reasonably truthy source of schematic. Or a request for a board to be added which I may or may not hold in the parts bin or acquire or ask another colleague to test etc etc.

Getting pins wrong is one of the old original worn out topics on the TTN forum for LMIC, this is a useful feature that appears to have bypassed this issue for the commonly available LoRa-radio-on-board products available from Amazon & other low hanging sources.

There is no secret sauce to this, the #define has to be the semi-random string that Arduino picks up from what you select in the boards manager which is sourced from the boards.txt file from the BSP. I do this by selecting a board and then compiling (usually an empty sketch) and then cherry picking out the appropriate board - there are usually several -D flags set in the command line so sometimes some validation against the boards.txt is needed.

There is the complication that some people may be using an auxiliary BSP - like the Heltec package - which has overlap and there is also the issue that you can select a board that doesn't have LoRa on it but it will still work - like the Heltec WiFi Kit board is identical to the Heltec WiFi LoRa board in every respect, it just doesn't have a radio on it. So you can use either with the pinmap because everything else is the same.

There is no problem cross-referencing the -D flag using the handy list generated by Steven so we can increase coverage. But as we can never ever see a nice way to make it work automagically for all users regardless of how they use RadioLib. I'd not try at all. There is so much benefit in having the vast majority of easy to acquire boards work 99% of the time that removing them because of the edge cases is hard to swallow. We can ameliorate this in the docs.

[StevenCellist]

The list above is the -D flag for each board if you prefix ARDUINO_ :). It is generated using regex on all boards.txt files. But let's continue in #1106