things-nyc / arduino-lmic Goto Github PK

The ASSERT in _nextTx() probably need to be removed. The network can administratively disable the 500kHz channels, and the device should not crash. (Ditto for 125 kHz a little later.)

LMIC_reset();

// Set after reset becasue of this link:
LMIC_setClockError(MAX_CLOCK_ERROR * 5 / 100);

This information comes from: https://www.thethingsnetwork.org/forum/t/ev-join-failed-with-adafruit-feather-32u4-and-lmic/7252/2

This code may be necessary to get the a 32u4 working. 1 unit didn't need it but my other two units did. Once they had this code entered they joined in the first transmission. Suggest an ifdef statement and a Define 32u4 in the project config file.

Hello,
I use an ESP32 Pico D4 and an RFM95.
The last time I used it everything worked.
But now I get the following error in the Arduino IDE as well as PlatformIO:

pin map is:
#define PIN_LMIC_NSS 5
#define PIN_LMIC_RST 14
#define PIN_LMIC_DIO0 25
#define PIN_LMIC_DIO1 37
#define PIN_LMIC_DIO2 38

// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = PIN_LMIC_NSS,
.rxtx = LMIC_UNUSED_PIN,
.rst = PIN_LMIC_RST,
.dio = {PIN_LMIC_DIO0, PIN_LMIC_DIO1, PIN_LMIC_DIO2},
};

Mistake:
Compiling .pio\build\pico32\src\main.cpp.o
Linking .pio\build\pico32\firmware.elf
c:/users/laval/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa -esp32-elf/bin/ld.exe: C:\Users\laval.platformio\packages\framework-arduinoespressif32\tools\sdk\esp32\lib\libpp.a(hal_mac.o): in function hal_init': (.text.hal_init+0xc8): multiple definition of hal_init'; .pio\build\pico32\lib051\libMCCI LoRaWAN LMIC library.a(hal.cpp.o):C:\Users\laval\Documents\PlatformIO\Projects\HSN-TTN_Esp32 V1.1\HSN-TTN_Esp32 V1.1/ .pio/libdeps/pico32/MCCI LoRaWAN LMIC library/src/hal/hal.cpp:416: first defined here
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\pico32\firmware.elf] Error 1

Please how can I fix this because it can continue to work.
Thanks

Although there is an elaborate mechanism for ADR in the LMIC code, LMIC.adrTxPow (which repersents the ADR adjusted TX power in dBm) is not used.

Transmit power is controlled (in radio.c) by LMIC.txpow. For US915, LMIC.txpow is unconditionally set to 26dBm for 500kHz channels, and to 30dBm for 125kHz channels.

(Further muddling things, radio.c for the sx1276 appears to only set the power to a max of 10 dBm -- it doesn't seem to correctly program the 20dBm boost mode. In any case, the setting of LMIC.txpow has basically no effect, because both values are greater than 15, and any value greater than 15 is mapped to 15 by radio.c.)

So it appears that the Tx Power is basically fixed (for US915), and the only thing that ADR can really adjust is data rate.

Hi @frankleonrose -- nice work.

In merging back to my codebase, I noticed that setNextChannel() is called either with setNextChannel(0, 64, ...) or setNextChannel(64, 64+8, ...).

The second parameter is called end; this implies it's the last channel. But the calls are coded as "last channel plus 1". Shouldn't these be setNextChannel(0, 63, ...) and setNextChannel(64, 64+8-1, ...)?

It looks harmless, provided that the number of enabled channels is less than the count.

I'm just returning to this LMIC library to try and understand some issues I had been having (device crash/freeze at random periods), but one thing I now use it an update to case EV_TXCOMPLETE in order to show the frame counter for the last TX upload.

Serial.print(F("EV_TXCOMPLETE (inc waiting for RX windows) -> TX Frame Counter :")); Serial.println((LMIC.seqnoUp)-1);

For your consideration.

Jez

I've been testing your library and i have a doubt about this event, i've printed in serial the "ev" variable and it shows 17

Original LMiC code would pick a random channel to begin and then increment it through active channels. The LoRa spec says it should be random each time.

Looking at some of the new mDot code, they break out a new class called ChannelPlan, which has specializations for US, EU, Aus, India, etc. In the US plan, it looks like they set a timeout after using a channel such that they don't reuse it until after a wait. Might be an idea to bring to LMiC - it means a sequence of transmissions won't reuse the same channel until all have been used, but if there's a gap between transmissions longer than the timeout, all channels will have a chance of being used.

From @terrillmoore: I would much rather have a guarantee of reuse, so use a shuffle pattern. I want to know that channel n will be reused within a maximum of 8 transmissions, in case that's the only one that works. (The current random sequence has the same chance of a channel to be reused every time -- no exclusion other than it must be not the same as the last one -- but it means we can go a long time in some of the marginal deployments before a good channel gets used, much more than 6min*7 tries -- not 48 minutes, but sometimes eight hours.

Of course, the plan would have to abide by the LoraWan spec. Also, any such plan requires storing history. Therefore,

1. It would have to be opt-in. Devices unwilling to store LMiC internal state outside of active transmissions would operate in the current, history-free manner.
2. LMiC would have to introduce an API for storing its internal state and then re-initializing from that state. Using this API a device could maintain channel use history across episodes of RAM-wiping deep sleep.

Hi

Hello

Is there an example using a class C node?

Thanks

Received bytes currently does this.
23973025: EV_TXCOMPLETE (includes waiting for RX windows)
Received
3
bytes of payload

Change:
if (LMIC.dataLen) {
Serial.println(F("Received "));
Serial.println(LMIC.dataLen);
Serial.println(F(" bytes of payload"));

to:

        if (LMIC.dataLen) {
          Serial.print(F("Received "));
          Serial.print(LMIC.dataLen);
          Serial.println(F(" bytes of payload"));

Then the received byte count will print on the same line.

Suggest adding the actual received data too. I'm working on that. Sorry I'm still learning Git or I would fix these and push new code when it is fixed.

Check documentation to see if we actually refer to this in the .docx file. If not, consider removing it.

Otherwise, add an API, possibly HAL support.

The pro for actually implementing this is that LMIC clients can be portable. The con is that it's another thing to be ported and tested, and there always are local operating system equivalents.

See mcci-catena#44

TTN now sends MCMD_LADR_CHP_125OFF and then MCMD_LADR (selecting channels 0..15, enabling 8..15).

The problem is in processing MCMD_LADR_CHP_125OFF. Although we set the mask for channels 64..71 with:

LMIC.channelMap[64/16] = chmap & 0x00FF;

But we then immediately mis-set the number of enabled 500 kHz channels (we don't consider the mask), either clearing to 0 or setting to 8.

We also need to handle ChMaskCtl == 5, which is used for subband control.

radio.c defines RegPaDac to 0x5A. But the sx1276 datasheet says that RegPaDac is 0x4D, and does not document any function for 0x5A. (It says "undocumented registers are internal test registers, don't use them".)