[Updated 2021-02-21] Here’s what I’ve been thinking about for next steps for the LMIC. My biggest concern is not breaking things for existing users; but we have to keep moving forward… My second priority is completing support; and my third is adding new features.
Meta on priorities
We want the LMIC to be a platform that an Arduino user can grab and integrate with their hardware; and provided they follow the rules, they should be able to forget about it. We’re not there yet, by any means, but this constrains our flexibility.
It’s very important, when resources are limited, to stay focused.
In order of priority:
- “Do no harm” – try not to break existing applications, unless it can’t be avoided (due to technology or spec requirement changes, for example)
- Production-quality Class A LoRaWAN support for 1.0.x for the regions and features that we support.
- Prioritize features and use cases that we consider best practice
- OTAA with professional gateways is preferred.
- Remove features that are not consistent with other priorities or that we can’t test compile in CI testing due to time constraints.
- Adding features:
- additional LoRaWAN features
- additional hardware support
- debugging and deployment features
Things that we do not have time to support right now include:
- we have no time to improve support for single-channel gateways or gateways that don’t support the regional specs (by offering the minimum number of channels)
- we have no time to support non-standard LoRaWAN devices (such as devices that don’t implement downlink)
- we have no time to improve support for hardware that doesn’t properly implement the minimum features needed for supporting the radio.
Because this is an open source project, others are free to add support. However CI testing already takes close to an hour, and we intend to add more test cases; we have to focus our CI time on features important to our mission.
Near Term
Replacing Travis CI
With the changes in Travis policy (see Travis CI builds disabled by Travis OSS policy change), we need to replace CI. This probably has to be tops on the list. I have a prototype script that uses the Arduino CLI and works well enough. But I have to figure out how to integrate that with github actions or a server at MCCI that can do the builds.
Ready for TTN V3
This is a bigger issue than it might appear, because the downlink window changes. This means that we really need to make it possible to save the mac settings outside the LMIC, for devices that may be joining either V2 or V3 during the transition. Maybe only important to MCCI users, but pretty important to us. This is essentially the same as:
State saving
Many people have independently come up with mechanisms to save the LMIC’s state prior to shutting down system RAM. I’ve found that if you do this properly with an OTAA device, it works really well and is very convenient for users. But… there’s no “approved way” to do this. Again, for the user who is not really interested in LoRaWAN, but just wants to use it, not having a suitable mechanism is a headache.
Secure Element Support
See LMIC Secure Element Roadmap for details on this. Not a breaking change to V3.3 except that it makes things bigger. It also adds a crypto API that might allow use of hardware AES where it’s supported. (This is needed even with some secure elements, because LoRaWAN uses AES for hashing and randomization as well as for securing communications.)
This needs to be merged early because it’s a big change.
This also might be a place to address @zsellera’s contribution of Ability to disable RSSI-based random-number generator.
Proper Join Randomization
@ngraziano contributed a patch to implement join back-off. This needs to be tested in all regions and we need to re-run compliance tests. I’ve been without my RWC5020B that I use for compliance tests for about six months now, but I hope to have access again shortly. This is important for network health, and for ETSI 303 645 compliance.
US/AU/EU channel randomization
This one has been hanging fire because of the RAM implications, mainly. (See issue 515 for discussion.) It’s needed for compliance and proper join for non-TTN networks.
- there’s also a randomization problem for EU-like regions – see issue 619
SX126x Support
The driver architecture implemented for secure element support can also be used to add support for the SX126x register set. For this, I’d need to select a reference device. MCCI has a STM32WL-based design ready to go; we just have not had resources. At this point there are a number of other potential reference platforms. Of course, it’s easier for me to get funding if it’s a device MCCI is already supporting.
Longer Term
Multi-Region Support at Run Time
I did the multi-region support as a fast hack: correctness-preserving, but clarity-reducing. This needs to be converted to use an explicit architecture (like the SE changes), and then it probably will be possible to make this work at run time, while also making it much easier to add regions.
See issue 602
Error Logging
I found while debugging compliance testing that printfs are a bad way to debug the LMIC. They’re fine for debugging crashes, but crashes should be rare birds in released versions of the code. When debugging LMIC problems, you really want an event logger so you can look at what has happened without disturbing timing.
Deprecate debug prints in the LMIC
This comes up over and over; people see debug prints and turn them on if they’re having problems. Often, just make things work. If we have logging, we can remove debug prints.
Remove the IBM C++ logging macros
These haven’t been compiled in a very long time and are likely not to work anymore. We don’t have any way to test them. We should remove them.
Bring-up Guides and Examples
There needs to be a series of step-by-step tests for confirming that the LMIC is working. The example apps don’t provide any way to figure out what’s going on when things don’t work.
Proper C Name Prefixing
The LMIC right now uses a plethora of naming schemes, and many globals don’t use “LMIC” anywhere in the name. In addition to being confusing, it can cause collisions. This can be handled without breaking most apps by having a new client header file that follows the new rules, and modifying the current client header file to #define synonyms.
Proper C++ APIs
The LMIC is written in C. That’s not going to change. But the LMIC should come with an approved set of C++ APIs for use in Arduino (or other) frameworks that conform to modern C++ rules – minimal use of #define, preference for use of templates and namespaces to minimize namespace collisions.
Improved documents
The LMIC README has grown too large; the .docx file is not kept up to date because Word is not part of the regular workflow; and there are Doxygen artifacts here and there. Perhaps a blog site with github pages would let us do Adafruit-Learning-System-like articles for the README info, merge technical info from the .docx file into Doxygen pages, etc.
What else?
Feel free to make suggestions, etc. I’m sure I’ve forgotten things…
–Terry
