search

mcci-catena / arduino-lmic

LoraWAN-MAC-in-C library, adapted to run under the Arduino environment
https://forum.mcci.io/c/device-software/arduino-lmic/
MIT License
642 stars 210 forks source link

Trouble with using disabled channels... LMIC seems to ignore the disable sometimes #10

Closed mdroberts1243 closed 7 years ago

mdroberts1243 commented 7 years ago

Hi,

I've been having trouble implementing an Adafruit 32u4 Lora node that honors the TTN frequency plan at 915MHz... this fork made some improvements over the Things-NYC in that the channels seem to align properly with the Lora spec, but I still see the client go off on other frequencies and there are gaps in the counter sequence of the received application data.

Other forks will pass through the desired frequencies and I'll get eight data payloads in a row, but this fork seems to be more random about frequency selection (probably a better thing), but I don't get a lot in a row. Also, Joining takes a lot longer.

missing_packets

This is how I'm disabling everything except the eight TTN 125kHz channels and the associated 500kHz one:

  // disable channels not used by TTN
  for (int i=0;i<8;i++)
    LMIC_disableChannel(i);
  for (int i=16;i<64;i++)
    LMIC_disableChannel(i);
  for (int i=64;i<72;i++)
    if (i != 65)
      LMIC_disableChannel(i);

The packets I do see in the Console seem to be on the right channels, but there are large gaps when I don't receive any packets even though the client clearly continues to wake up and transmit.

-mark.

mdroberts1243 commented 7 years ago

I think my problem stems from when I do the disable of the channels... I believe it needs to be repeated after every LMIC_reset() and I missed doing it in the Joining section of the code... I am having very good results now.

PS My Arduino development environment may have also been referencing an older .h file, which could also have caused some confusion (unconfirmed).

terrillmoore commented 7 years ago

Hi Mark, Sorry that I wasn't able to comment earlier, but glad you managed to sort it. You are absolutely correct that this has to be done after every LMIC_reset(). --Terry

terrillmoore commented 7 years ago

By the way... in my testing (see https://ithaca-power.mcci.com, and check the "RF data" dashboard), I still am unhappy with the channel selection pattern. I am not sure we have enough entropy; and since there is no guarantee for how soon a good channel will be reused (other than that it won't be reused immediately), you can get bad results. For example, if you only have one or two good channels of the eight, as in one of our installations, the software can wander indefinitely among the bad channels before coming back to a good channel. I have an approach that solves that, which I plan to post soon.