LoRaWAN support issues that are classic gotchas

[HeadBoffin]

How would @jgromes like to handle the LW noob classics like #1004 - which was ridiculously well presented compared to the opening messages on the TTN forum as I'm sure @StevenCellist will attest to.

On this one it was clear all was good except reception - and one of the common no join issues is having the gateway & device on the same desk which can end up with channel bleed on the gateway resulting in CRC error so no join request on gateway console. Or bad keys so no join request on device console. Or just slightly out of range as this one was.

We can get stuff in to the wiki to help out, but I figure the challenge is differentiating between is it RadioLib vs is it LW and what to do if it's a protracted LW issue.

Also, can we de-emphasis the Verbose mode debug on the wiki page - make it by request only - as trawling through the SPI output to pick out the info is a royal PitA on mobile devices, or indeed my MacBook! Some wording that says if you get an error that indicates an SPI issue then feel free to add it, but not if there are no apparent radio issues.

[jgromes]

We can get stuff in to the wiki to help out, but I figure the challenge is differentiating between is it RadioLib vs is it LW and what to do if it's a protracted LW issue.

Adding to Wiki will help out, but out of experience, we will inevitably keep on getting those issues. One thing that could useful would be a list of common problems and what to do to resolve. E.g. - getting -6 on join request can be caused by: bad keys, out of range of gateway etc. - I think a list of troubleshooting steps for each of the most likely causes can go a long way. Another thing that can somewhat help is additional issue template for LoRaWAN.

Also, can we de-emphasis the Verbose mode debug on the wiki page

Yes, definitely - I'm thinking of renaming the debug macros to make the usage more clear:

RADIOLIB_DEBUG -> RADIOLIB_DEBUG_PROTOCOL
RADIOLIB_VERBOSE -> RADIOLIB_DEBUG_SPI