You know the generated UIDs/keys for a new device.
If it was only a copy paste into code then it would be fine, but most LMIC implementations require it to be reversed (2xLSB, 1xMSB), which translates to human error.
And as it happened to me I lost 1day debugging why it wouldn’t work. (as there is no feedback that these values are misstyped), or whether it’s an RF problem, wiring, module, sw.
So I suggest adding a 1byte checksum after the keys onto the website,
and we can easily implement a crosschecking function in LMIC, that ensures:
everything is typed in correctly AND
into correct field AND
in the correct endiannes.
stack is compatible with HW’s endiannes
personally I would also include a test vector for the AES128 implementation too
or why not the MIC that would also test everything
Take the last byte and display it on the website, and put it into user code’s init.
ASSERT(LMIC_selftest() == TRUE);
TTN could make a standard out of this, rest could follow.
If you don’t want to use it you don’t have to, but for the rest of us it would save time, and give some SW integrity check/confidence. (same way we write unit tests)
It could be compiler switched out, so there is zero downside.
The exact place you put the EUI’s it says what their endianness is.
There are many many other ways to be tripped up.
The sum of an EUI one endianness is the same as the other way - but you could have a two byte checksum, one for the first half and one for the second.
There is no feedback because there is no way for anything to detect it they are wrong because that’s sort of how it works - the “wrong” credentials could just be for a different network.
But if the EUI’s could be detected as wrong, the entire LoRaWAN spec will need updating to configure that as a message back to the device.
This situation is how the phrase RTFM was created.
But also, an ongoing issue with community based support over the entire technical interweb, is asking well formed questions and providing the answers in a methodical manner.
This exact issue comes up at least two or three times a month but sometimes the way people describe it and then go on to present the information asked of them is so poor that sometimes it can go on for days, so in some respects, you got off lightly!
I’m only talking about a checksum for data entry from website to code, and a local init function that recalculates the checksum offline.
Same way as your VISA card has a checksum that can be checked after dictated over the phone (which is lot shorter).
There is zero change to the standard, or RF.
There is a position dependent checksum (fletcher8/16) which is cheaper than crc.
to be specific: fletcher16( devEUI + appEUI + appKey + AES(test_plain) ) = 65512
What you are saying is that
every user should expect the suffering when running into this for the first time
use community effort to solve the same problem over and over again
figure out that his problem is endianess related, learn what endianess means (we are talking about arduino users)
This is a low hanging fruit to eliminate 20-50% of possible causes at zero cost.
(LMICs are already full of lot less useful features)
Please keep in mind not everyone is using LMIC and other libraries need different byte orders. That’s why the LMIC examples EUIs have explicit remarks regarding the byte order.
While writing embedded software knowing about byte order is (almost) mandatory. For I2C and SPI sensors you need the information to drive them and read the results. It comes in handy as well as when assembling uplink packets.
Making entry into TTN or LoRaWAN in general less daunting is certainly something to look into, however as with all technology new entrants should gain a basic understanding of the technology before starting to saturate the airwaves with radio signals. With long range radio mistakes have impact beyond your home and the immediate neighborhood.
A case of human error that is easily solved by RTFM or RTSL (read the source Luke).
Required endianness is clearly commented per key in essential examples included with the LMIC library (and in LMIC-node).
Different libraries/platforms require different endianness, that is why the TTS Console provides options to view/copy the keys in different formats.
Bolting on extra code on the end device side to check if the keys are in correct order only to solve an RTFM issue is not very useful.
More useful would be when the TTN Console provides an option where the user can select a format for the keys to be shown by selecting the name of the library/platform used.
You can add an issue with a feature request for this on the TTS GitHub repo if you would like to have such feature.
Nope, I think about 90% don’t suffer, otherwise we’d have to have this as the only entry in the forum.
I’m working on a solution too
Bicycle users can go in to a moped shop in the UK and drive away with a similar but powered device. I’d advise them to read up on the differences before they did such a thing and if they find it runs out of power, read the manual, particularly the bit about putting petrol in.
Pre-internet, programming was learnt from dead tree, programming issues were resolved by taking a step back and making sure all the details made sense. Instant gratification via the interwebs makes for someone who calls themselves a chef but actually works in the production area in a fast food restaurant where the playbook is on a screen and they have to follow along. LMIC-node is the closest we have to that spoon feeding, again 90% of users just get on with it, it is the best documented framework I am aware of and even then we have people asking questions about it that are directly answered in the top level Readme.md - praise be the author was wise enough to put in #headers so we can directly link to the bit the OP has skipped.
Preparing (learning), planning, design, testing, documentation is 80% of software development. Actual typing code is the rest.
If I recall correctly, it didn’t a year ago, which is why I have a spreadsheet called EUI reverser with a lot of EUI’s that it reversed and formatted for me! But if you tell the kids today that, they won’t believe you.
Good idea!
Or perhaps a side tab that provides a copy & paste of the code for LoRaMAC-node and LMIC-node so the 80% that are just provisioning a device don’t have to get tangled up with it.
Or perhaps a web page that does that sort of thing for you - if I ever get some time!
A year ago? Wake up! (IIRC I then created an issue/feature request to add this option consistently for all key fields.)
You will have to open a device page for these settings (not possible on application page where only copy copy buttons are shown) and select the <> button to reveal the ‘double arrow’ button that allows to switch the format of a key.
It’s a bit awkward and hidden for the eye but the functionality is present.
Below an example for an OTAA device with all options expanded/made visible: (I chose arbitrary options for the formats for below picture, formats shown below are not the defaults used by the console).
Yeah, a year ago it didn’t have that, now it does and has for some time, which was what I was trying to say, but useful screen shots for those that aren’t aware of the functionality.
