Non-arduino C LMIC

[mrx23dot]

Are there any active Non-arduino C (not C++) implementations of LMIC?

To be used with standalone projects (outside arduino).

[terrillmoore]

I use it that way with some of our internal projects. Pure C works. I realize now that I should probably push that to GitHub. You basically replace the hal.cpp with a hal.c. It might be good to have a totally working example that was in CI. Some people have argued "this is Arduino LMIC" but I don't think that Arduino should mean exclusive.

[mrx23dot]

That would be great! Thanks.

How does this project relate to the reference library from Lora organisation?
https://github.com/Lora-net/LoRaMac-node
What's the benefit for this over the original lib?

[terrillmoore]

Relationship: no relation. This project is based on code from IBM Zurich in 2014/2015, and is designed to be small. The LoRaMac code is reference code that is intended to be complete.

Benefit: for me, the benefit is code that I completely understand, that is reasonably small (in lines of code as well as in bytes of object code). For others, the benefit is small size -- it will run on ATmegas, leaving enough room to do other things. Since many people don't really need to use Class B or Class C, and are often building special things that will only be run in a single region, the limitations are real but not uncomfortable in practice. We've also been using this code forever (since before there was a reasonable LoRaMAC implementation for the US); so it saves us from having to change and requalify everything. It also doesn't require an RTOS or elaborate timer mechanisms. The project is kind of limited by that choice, but... it's not an invalid choice.

Other people may have other opinions.

Best regards,
--Terry

[mrx23dot]

That's a sound reason, I will give it a go then.

I would also like to look into sending one packet over TTN plus Helium, for coverage redundancy, so run time credential switching, and hopefully not many things are compiler switched for that.

Is the DIO feedback necessary for RFM95? When I design drivers are always go for polling, because

• slave can crash anytime (so you already have to poll for it)
• edge changes can be missed for whatever reason (e.g. isr concurrency)
• one extra wire to route
• optionally it can still be used to wakeup the MCU, but driver can ignore it

[terrillmoore]

If you search for the discussions about saving / restoring state, it should be clear what to do. All the network-specific code at this point is in "Arduino LoRaWAN", a wrapper for this; nothing for TTN vs Helium. The reason for the separate Helium example is historical; originally, they used a different FSB in the US than TTN, and joining took too long. With 4.1, the logic for probing the 64-channel space is based on a shuffle, so joins don't take too long, even if you don't have a subband selected. So subband selection now is really for ABP, not OTAA.

There may be things that need to be saved that have been overlooked, of course. Class B or Class C won't work nicely, but that's probably not an issue for this use case.

As for DIO1: the LMIC really needs to catch the time of DIO1 for timing purposes; polling with SPI is possible but I have not tried it. I know it's inconvenient to have to wire DIO1, but it's just too hard to test all the various possible configurations. There are forks (and PRs) that implement using SPI polling, you can possibly find what you need.

As it happens, MCCI doesn't use interrupts from DIO1 in our systems (we use DIO1, but we don't enable interrupts from it). The LMIC doesn't actually expect interrupts; by default, when you call os_runloop_once(), it checks the GPIOs for state changes, and logs the time. (Interrupts shortcut this, by logging the time.) If you use ISRs, it still works the same way; the ISR never causes the LMIC code to run, it just captures a timestamp. Then when you call os_runloop_once(), it processes the interrupt before running any jobs. ISR concurrency is thus not an issue with this architecture.

However, the LMIC itself is not, in my judgement, suitable for safety-critical apps at this time. I think it's reasonably robust, small, and reviewable; but I would not run it in a kernel. It should be in user-mode code, and on a small micro, there's no such distinction. (This is not really a criticism; I'm not sure any code complex enough to run the LoRaWAN MAC would be suitable for kernel incorporation. But I'm the kind of person who strongly believes the same thing about TCP stacks, and USB stacks -- only the lowest level hardware access should be in the kernel, and must be carefully implemented and as tiny as possible. Everything else should be in user mode and performance complaints should be mitigated by careful architecture. But I digress!)

Given that the LMIC is not suitable for safety-critical apps on small systems, I try for reasonable robustness in the hardware interfaces; I feel that a system really needs a watchdog timer and a voltage-sensitive reset / brownout detector, or you can't make things robust in fact. Then you make economic decisions about which upsets you want to try to survive without depending on the watchdog/reset. As you make the upsets more and more obscure, it becomes harder and harder to test.

Testability is an issue for the LMIC. With all the regions and all the configurations, it takes a long time to build all the possibilities; and there's no hardware-in-the-loop testing, and no budget to develop it. We have found that PlatformIO is close to Arduino IDE, but not identical; so we can't test for Arduino IDE correctness using PlatformIO.

Best regards,
--Terry

[mrx23dot]

What suppose to happen in case I ask for a JOIN REQ, but the response never comes?
From debugger I see it sets up RX window, then it passes without any action, then it just hangs, there is nothing scheduled in the OS next. (deadline passed)
Not sure if this changed since IBM1.6.

EV_JOINING
EV_TXSTART
137258: engineUpdate, opmode=0x884
137391: TXMODE, freq=868300000, len=23, SF=7, BW=125, CR=4/5, I139371: irq: dio: 0x0 flags: 0x8
139470: Scheduled job 20000874, cb 	jreqDone:	ASAP
139606: Running job 20000874, cb 	jreqDone:	, deadline 0
139755: Scheduled job 20000874, cb 	setupRx1Jacc:	at 295354
295350: Running job 20000874, cb 	setupRx1Jacc:	, deadline 295354  -> didn't receive JOIN ACCEPT

rx window passed, now it hangs

I would expect a retry or failed event callback.
Even after I merged in major changes from this lib to lmic.c
Does it work on your end?

[mrx23dot]

Thanks for the detailed answer, I fully agree, although even in a not safety application a restart of LMIC would be annoying (say LED control, where a 2nd MCU isn't economic) because SPI/slave fault.

I tried to compile in the library with C, but it doesn't like repeated names, since compiler has a flat output structure. (build/lmic.o)
C:\tmp\FW_lmic\src\arduino-lmic-master\src\aes\lmic.c
C:\tmp\FW_lmic\src\arduino-lmic-master\src\lmic\lmic.c

Could you just zip your example here?
Cheers

[terrillmoore]

Sorry, been very busy last few days. Will try to do this. Meanwhile, suggest you rename src/aes/lmic.c to src/aes/aes_lmic.c or something. Our build system doesn't have a flat output directory so this collision didn't matter in our use case.

[mrx23dot]

How do I specify which network I join if TTN and Helium are both in range?
These two examples are effectively identical: helium-otaa.ino, ttn-otaa.ino

Frequency plan seems to match TTN's https://docs.helium.com/lorawan-on-helium/frequency-plans/
The only difference I found was:
default downlink parameters: 869.525 MHz / DR0 (SF12, 125 kHz), so I can set:

  if(network == NET_TTN)
  {
    // TTN uses SF9 for its RX2 window.
    LMIC.dn2Dr = DR_SF9;
    // Set data rate and transmit power for uplink (note: txpow seems to be ignored by the library)
    LMIC_setDrTxpow(DR_SF7, 20); // only when Adaptive Data Rate is disabled
   // why they dont match?
  }
  else if(network == NET_HELIUM)
  {
    /* default downlink parameters: 869.525 MHz / DR0 (SF12, 125 kHz) */
    LMIC.dn2Dr = DR_SF12;
    LMIC_setDrTxpow(DR_SF12, 20);
  }

Worst case I can imagine is that it constantly tries to join the bad network and never tries the other good one. (good way to jam a static node)

[terrillmoore]

You really only need to set LMIC.dn2DR if using ABP. If using OTAA, the Join Accept message sets the LMIC.dn2DR to match the network. Save and restore and you should be fine. So no need for that code, I think.

The examples originated when the LMIC couldn't really parse downlink MAC messages, and when TTN didn't really send everything needed for US915. I've done a bad job of keeping them up to date, mainly because I never use them.