Bug in the LMIC code or not? channels and frequencies, transmission strength

Have I found a mistake here or not?
I think I have found an error in the LMIC code. According to TTN (link below 1) there should be 8 frequencies (channels) for eu868…:

868.1 - SF7BW125 to SF12BW125
868.3 - SF7BW125 to SF12BW125 and SF7BW250
868.5 - SF7BW125 to SF12BW125
867.1 - SF7BW125 to SF12BW125
867.3 - SF7BW125 to SF12BW125
867.5 - SF7BW125 to SF12BW125
867.7 - SF7BW125 to SF12BW125
867.9 - SF7BW125 to SF12BW12

These are also in
lorabase_eu868.h (link below 2 ) with

enum {
        EU868_F1 = 868100000,      // g1   SF7-12
        EU868_F2 = 868300000,      // g1   SF7-12 FSK SF7/250
        EU868_F3 = 868500000,      // g1   SF7-12
        EU868_F4 = 868850000,      // g2   SF7-12
        EU868_F5 = 869050000,      // g2   SF7-12
        EU868_F6 = 869525000,      // g3   SF7-12
        EU868_J4 = 864100000,      // g2   SF7-12  used during join
        EU868_J5 = 864300000,      // g2   SF7-12   ditto
        EU868_J6 = 864500000,      // g2   SF7-12   ditto
};

However, in lmic_eu868.c (link 3) there is only the following :

static CONST_TABLE(u4_t, iniChannelFreq)[6] = {
        // Join frequencies and duty cycle limit (0.1%)
        EU868_F1 | BAND_MILLI, EU868_F2 | BAND_MILLI, EU868_F3 | BAND_MILLI,
        // Default operational frequencies and duty cycle limit (1%)
        EU868_F1 | BAND_CENTI, EU868_F2 | BAND_CENTI, EU868_F3 | BAND_CENTI,
};

There are too few channels and channels are awarded twice and it contradicts itself with:

void LMICeu868_initDefaultChannels(bit_t join) {
….
…
        (void) LMIC_setupBand(BAND_MILLI, 14 /* dBm */, 1000 /* 0.1% */);
        (void) LMIC_setupBand(BAND_CENTI, 14 /* dBm */,  100 /* 1% */);
        (void) LMIC_setupBand(BAND_DECI,  27 /* dBm */,   10 /* 10% */);
}

1 :https://www.thethingsnetwork.org/docs/lorawan/frequency-plans/

2 https://github.com/mcci-catena/arduino-lmic/blob/4ceb2b049b59bb2390491f2db63e4951b986d277/src/lmic/lorabase_eu868.h#L70

3 https://github.com/mcci-catena/arduino-lmic/blob/4ceb2b049b59bb2390491f2db63e4951b986d277/src/lmic/lmic_eu868.c#L104

1 Like

Depends on what or who you are referring to :wink: You may want to look at the context - does LMIC work and has this issue been found before? Or might it be a knowledge gap?

The LoRaWAN spec requires EU to join on one of only three channels, the rest are setup by the Join Accept.

1 Like

I would note that LMIC, having passed through a number of versions of specification & maintainers, is the very definition of code soup, not helped by the faux RTOS/scheduler that was embedded from the start. Some parts seem critical but are no longer used and some parts like the debug only really work on an AVR which is problematic given that it no longer fits in to most of them.

2 Likes

Ah good hint, so if I assume that I am only on the ttn network because it has more channels than the LoraWan specs specify (I just looked in the “lorawan_regional_parameters_v1.0.3reva_0.pdf”). If I “connect” another LoRaWan network, there is a possibility that the transmitted data will not be received if I adjust the values. So now you would have to make a separate list for each LoRaWan network on which channels are transmitted. LMIC still has a lot of tinkering to do.

Thank you for your answer

But instressant they (perhaps) have made a small mistake according to the specifications, a fixed frequency of 869.525 is prescribed for RX2 (according to lorawan allience). I don’t think I’ve seen anywhere at LMIC that this is specified. (page 19)

yes unfortunately I have been looking for an alternative for months and have already had to change, delete or add thousands of lines of code to LMIC. If you have a tip for an alternative I would be very grateful.

I hear someone whispering RadioLib… (bonus: 3 minutes ago 6.4.0 is released with many improvements to LoRaWAN!)

1 Like

What? Overuling the L-A? or is that really “many improvements to the included LoRaWAN stack implementation in this instantiation”? :rofl: just sayin’ !

1 Like

Nah I’m just very smart! (Just kidding… you’re right!)

1 Like

All EU868 networks must use the three join frequencies. This means your node should start out by using just these three frequencies and it will receive the information regarding the additional 5 channels from the network when joining. So no need to adjust or hardcode anything if you use OTAA.
When using ABP you need to adjust both your code and the network server setting to match. That is one of the reasons OTAA is by far the preferred join method.

The latter isn’t completely true, although I’m not certain for which LW versions it is and which it isn’t. My experience with v1.1 is that the LNS requests the creation of the additional channels through MAC downlinks.

??? What are you referring to? ABP mode getting additional channels through MAC commands? That is LNS dependent. TTS does attempt to set the additional channels if the LNS has no information about them being available on the device. However not all LNSes have the same features so you can’t depend on it unless it is a LoRaWAN LNS requirement and the LNS meets that specification.

Per the regional parameters of 1.1 (dynamic bands such as EU868), a device is obliged to implement the minimum two or three channels and per spec 1.1 must implement NewChannelReq, but is by no means required to implement additional channels (although it must support a means of storing up to 16 uplink/downlink channels). If the LNS wishes to use other frequencies, it must do so using MAC commands. The specification (as far as I’ve dug through) does nowhere mention the requirement of devices supporting a method to define extra channels by the user. No mentioned difference between OTAA and ABP in any way.

The most obvious alternative would be to use LMIC without interference - it’s maintained by Terry to support MCCI’s boards, is the underlying system for LMIC-node, can be configured to run on an ATmega328 albeit with restricted space for more complex sensors and runs loverly on ATmega4808, SAMD, ESP32 etc etc.

Rather like the current MKRWAN topic, after a few attempts to interpret the documentation, best to ask for guidance - once you get too far down the path of code mashing it becomes a zero sum game. As I said above, LMIC is working in a lot of places and was the go to standard for many years for Arduino devices.

If you tell us what hardware you are using we can advise you better.

It is not at all clear to who you are replying to so it is not at all clear to what ‘the latter’ may be.

If the oldies had Spock eyebrows, you’d see them moving far above our hairlines!

1 Like

That doesn’t mean that, as Jac says, a network can’t support other mechanisms for doing things - as long as they don’t override / subvert the core specification you could incorporate all sorts of extra stuff as MAC commands or even invent a hybrid class B without beacons (TimeReq from a modern MCU with an RTC leads to being able to open a receive window to listen for broadcast messages quite nicely).

Where in the specification is that requirement listed?

For regions with a fixed channel plan it shall not implement this request according to the specification. However EU868 isn’t fixed so it doesn’t apply in this case.

1 Like

Thought I’d started dreaming (which I somewhat did) - it’s in the “TR007 Technical Recommendations” document, independent of LW version. But not the actual spec.

“Dynamic channel plan regions (EU868, CN779, EU433, IN865, KR920, AS923-1, AS923-2, AS923-3 as of [RP002-1.0.2]) define a small number of default channels (two or three depending on region). Additional channels are dynamically created by the network via the CFList or NewChannelReq commands.”

1 Like

Sure, a recommendation that’s good to follow, but the main consideration here is that there is nothing in the specs that say you can’t do other things over & above it and I believe that’s the difference being expressed here.

There’s also legacy issues of compliance vs implementation - like how does an ABP device get told about additional channels - plus the rapacious desire for the LA committees to meet up and create new standards that take, literally, years to trickle down, so aren’t hugely applicable in reality as it struggles to catchup.

1 Like

Wow, so great.
Will test if RadioLib supports Class A and/or Class C.

Is mandatory/fall back for any LoRaWAN device so anything claiming support must at least do that! Still worth testing however as early days and gathering users experience and feedback likely of value and may help trap any missed bugs not already identified. Class C (or B for that matter) is optional and dev(s) will declare if they consider it supported (only then worth testing in those modes). Note there appears to be no back-off mechanism wrt failed join requests under OTAA (from limited testing on developing versions) so if device doesnt join withing the first few attempts stop and investigate why that might be the case; dont let it keep on banging away trying as wasteful of LNS/GW resources and dont say leave running overnight/days on end just in case. Hopefully this will get added/sorted in a reasonable time scale…