More than 50% of uplinks transmitted on channel 0

End Devices (Nodes) LMIC
1

Hi,
So I am a new to LoRa and reading up on a bit on the theory. So I configured an RFM95W module with an ESP8266 to transmit on the EU bands with the LMIC library.
This is code: (default from MCCI-LMIC)

  LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);  // g-band
  LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_CENTI); // g-band
  LMIC_setupChannel(2, 868500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);  // g-band
  LMIC_setupChannel(3, 867100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);  // g-band
  LMIC_setupChannel(4, 867300000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);  // g-band
  LMIC_setupChannel(5, 867500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);  // g-band
  LMIC_setupChannel(6, 867700000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);  // g-band
  LMIC_setupChannel(7, 867900000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);  // g-band867.9
  LMIC_setupChannel(8, 868800000, DR_RANGE_MAP(DR_FSK, DR_FSK), BAND_MILLI);   // g2-band

I understand that most gateways support these 8 channels and all should at least support 3. The weird thing is that in my logs 37 out of 69 uplinks used channel 0 (868.1 Mhz, or is this channel 1?), and channel 6 was only used once.
This does not make sense to me, why are they not evenly distributed across channels? I would think this increases the chance of a in air collision massively without a good reason.

Can anybody explain the behavior I am seeing?
I searched the net but couldn’t find anything like this. All the relevant code should be in this file: https://github.com/Bartvelp/LoRa-WiFi-tracker-TTN/blob/master/_1_lora_functions.ino

Let me know if I forgot something.

2

You may have a bad random number generator in whatever ESP8266 glue code you are using. Often this is based on an ADC reading or radio RSSI, if you don’t actually implement something you may have no randomness.

Add some serial debug output to the channel selection logic to be sure; for example, make sure that the issue is already there in the attempted transmissions and not just the received ones (as might be the case if your closest “gateway” is a single channel abomination)

1 Like
3

Thanks for the reply @cslorabox , I am not seeding the the RNG my code. I couldn’t find the channel selection logic that is used by default in the MCCI_LoRaWAN_LMIC library.
Could I use channel selection logic something like the following? or is there a better way:

uint8_t randomChannel = random(0, 9);

for (uint8_t i = 0; i < 9; i++) {
  if (i != randomChannel) {
    LMIC_disableChannel(i);
  }
}

This code is mostly used for single channel “gateways” but I guess should work for me since I am only sending 1 packet and then reboot.
And yes all packets were received by 2 regular 8 channel gateways in my area.

4

You shouldn’t do that.

A LoRaWAN node must retain knowledge of what it has done before to be spec compliant.

For example, your frame count must increment without reset or reversal.

5

Well I can’t really circumvent it, I am persisting the up and down framecounters in ram. And I am using blind ADR since my node is moving.
I would like to be spec compliant ofcourse but I don’t see the problem as long as I adhere to the 30s uptime/24 hours guidelines.

6

You need to persist the frequency selection logic state, too.

If you take something intended for one pattern of usage, and force it to function in another, then you become responsible for handling the differences.

7

Yes I understand I am responsible for the node, that’s why I have created this post in the first place.
Could you maybe give a pointer to the frequency selection logic and state that is used in the LMIC library?
And I proposed a solution of using a random channel with the code in my first reply, why is this not a sufficient method?

Obviously I am still a beginner in LoRa(WAN) and radio communication in general so I am grateful for any help.