mcci-catena / arduino-lmic Goto Github PK

If you try to turn on LORA_DEBUG_PRINT mode, you get compile errors (in addition to the errors due to using printf w/o #include <stdio.h>. With the new logging system, the prints are very useful... so this should be fixed.

When I use the example sketch for OTAA, in combination with a Murata module, I can't get it working. In my gateway I do see an activation package coming in from the node. But then the activation never happens and the device just keeps sending activation packages, instead of uplink packages containing the payload.

I did check OTAA in the combination with my gateway and an RN2483 module and that worked well.

I suspect the Murata module is somehow not receiving the activation package sent by the gateway. I am not sure whether this is an actual bug, or that I am overlooking something to correctly configure LMIC 2.1.5 to work with a Murata module and TTN.

Thanks in advance for your help!

hows send to address to another node with raw.ino?

i could not find address section

LMIC_setDrTxpow() doesn't really do anything.

Although calling it sets LMIC.adrTxpow to the input parameter, the value is then never used inside the LMIC library. This is because LMIC's radio.c uses LMIC.txpow, and in US915, lmic.c::updatetx() sets LMIC.txpow to 30 for 125kHz channels, and 26 for 500kHz channels, ignoring LMIC.adrTxpow. Finally, radio.c configPower() limits the value to 17 dBm, and doesn't turn on the +20 dBm option if over 17 dBm. This wouldn't cause much of a problem in Europe, as you're limited to 16dBm EIRP, and so we have to subtract 3 dBm anyway. But in the US it's a limit.

Exact rules in the US (per LoRaWAN 1.0.2)

• 30 dBm Tx power is allowed if you're using more than 50 channels.
• 26 dBm Tx power is allowed if you're using 500 kHz bandwidth.
• 21 dBm Tx power is allowed if you're using fewer than 50 channels at 125 kHz.

At present, however, it seems that neither manual nor automatic TX power control can set the power above 10 dBm; and (in the US), the TX power is fixed at 10 dBm.

To fix this:

• fix the handling of > 10 dBm in radio.c
• fix the US updatetx() so that ADR works
• test ADR in US, EU, etc.

Neither the EU868 nor the US915 beacon offsets match the offsets in the spec. The EU868 code looks for a one-byte CRC on the time, but the regional params now clearly require a 2-byte CRC in that case. Probably everything needs a close look, and of course there's the small matter of testing....

Hi,
I saw an issue in the original repo (matthijskooijman#120) which I am wondering about as well.

I am, just as that guy, using a single channel gateway, and am in need of locking my node to a fixed channel. As discussed in that thread, I've been trying to lock out the unwanted channels with LMIC_disableChannel(x) without success, and resorted to a nasty quickfix to get it up running.

How do I achieve this, to reduce the wanted channels to a single one, preferably to the one where the join negotiation successfully happened?

Should LMIC_disableChannel(x) be used in a specific way to achieve this?

Cheers,
Chris

The 3 second delay is much too long for the US, because the US has a 400ms max airtime. Possibly wrong for other regions, too. This can be wasteful of power. This needs to be regionalized

Is there any way I can configure it to work with SX1278 + single-channel gateway (my gateway seems to be working already) ?
I tried this, but it didn't help:

LMIC_setupChannel(0, 434500000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);

Thanks!

Oops. I omitted a few key files for as923. Will fix shortly.

It doesn't capture it from the JoinAccept, and it always acts as if it were zero.

1. These are standardized under ISO 3166-1 alpha-2 (see Wikipedia)
2. Should indicate that we always use lower-case by convention
3. consider C++ versions in a header file that doesn't bring all of LMIC into scope. (ArduinoLoRaWAN?)

We need listen-before-talk for AS923 certification in Japan.

I always manage to screw up git pull requests, so I hope you don't mind a diff file (I'm a Subversion guy).

This is against commit ab06411.

Adds printf() support on non-AVR platforms (works on Feather M0)
Adds missing timestamps on three debug prints.

diff -r arduino-lmic-master/src/hal/hal.cpp arduino-lmic-jcw/src/hal/hal.cpp
264a265,266
> #if defined(__AVR)
> // avr-libc provides an alternative (simpler) way to override STDOUT
281a284,307
> #else // defined(__AVR)
> //
> // On other platforms, use the somewhat more complex "cookie"-based
> // approach to custom streams. This is a GNU-specific extension to libc.
> //
> static ssize_t uart_putchar (void *uart, const char *buf, size_t len)
> {
>     return ((Uart *) uart)->write (buf, len);
> }
>
> static cookie_io_functions_t functions =
> {
>     .read = NULL,
>     .write = uart_putchar,
>     .seek = NULL,
>     .close = NULL
> };
>
> void hal_printf_init()
> {
>     if ((stdout = fopencookie (&LMIC_PRINTF_TO, "w", functions)))
>       setvbuf (stdout, NULL, _IONBF, 0);
> }
> #endif // !defined(__AVR)
304a331,334
> #if 1
>     printf("FAILURE %s:%u\n", file, (int)line);
>     fflush(stdout);
> #else
309a340
> #endif
diff -r arduino-lmic-master/src/lmic/lmic.h arduino-lmic-jcw/src/lmic/lmic.h
33a34
> #include <stdio.h>
diff -r arduino-lmic-master/src/lmic/radio.c arduino-lmic-jcw/src/lmic/radio.c
616c616
<   LMIC_DEBUG_PRINTF("start single rx: now-rxtime: %lu\n", now - LMIC.rxtime);
---
>   LMIC_DEBUG_PRINTF("%lu: start single rx: now-rxtime: %lu\n", now, now - LMIC.rxtime);
624c624
<         LMIC_DEBUG_PRINTF("RXMODE_RSSI\n");
---
>         LMIC_DEBUG_PRINTF("%lu: RXMODE_RSSI\n", os_getTime ());
841c841
<       LMIC_DEBUG_PRINTF("rxtimeout: entry: %lu rxtime: %lu entry-rxtime: %lu now-entry: %lu rxtime-txend: %lu\n", entry, LMIC.rxtime, entry - LMIC.rxtime, now2 - entry, LMIC.rxtime-LMIC.txend);
---
>       LMIC_DEBUG_PRINTF("%lu: rxtimeout: entry: %lu rxtime: %lu entry-rxtime: %lu now-entry: %lu rxtime-txend: %lu\n", os_getTime (), entry, LMIC.rxtime, entry - LMIC.rxtime, now2 - entry, LMIC.rxtime-LMIC.txend);

LoRaWAN 1.0.2 has 3 MAC commands that are not in the LMIC code. They need to be:

• added to lorabase.h
• implemented, perhaps guarded by a conditional compile.

Hi

I am trying to make this library work with the RAK811 module, but I can not find the correct configuration, I think my problem is in the definition and use of the pins

RADIO_RF_CRX_RX PB_6 //CRF3 (ANT_SWITCH_TX_BOOST)
RADIO_RF_CBT_HF PB_7 //CRF2 HF (ANT_SWITCH_TX_RFO)
RADIO_RF_CTX_PA PA_4 //CRF1 PA (ANT_SWITCH_RX)

// LORA
#define RADIO_RESET_PORT PB13
#define RADIO_MOSI_PORT PA7
#define RADIO_MISO_PORT PA6
#define RADIO_SCLK_PORT PA5
#define RADIO_NSS_PORT PB0
#define RADIO_DIO_0_PORT PA11
#define RADIO_DIO_1_PORT PB1
#define RADIO_DIO_2_PORT PA3
#define RADIO_DIO_3_PORT PH0
#define RADIO_DIO_4_PORT PC13
//#define RADIO_DIO_5_PORT PA4

#define RADIO_RF_CRX_RX PB_6 //CRF3 (ANT_SWITCH_TX_BOOST)
#define RADIO_RF_CBT_HF PB_7 //CRF2 HF (ANT_SWITCH_TX_RFO)
#define RADIO_RF_CTX_PA PA_4 //CRF1 PA (ANT_SWITCH_RX)
#define RADIO_XTAL_EN PH_1

My Pin mapping

const lmic_pinmap lmic_pins = {
.nss = RADIO_NSS_PORT,
.rxtx = RADIO_RF_CRX_RX,
.rst = RADIO_RESET_PORT,
.dio = {RADIO_DIO_0_PORT, RADIO_DIO_1_PORT, RADIO_DIO_2_PORT},
// the RAK811 module needs D29 high for RX, low for TX.
//.rxtx_rx_polarity = 1
.rxtx_rx_active = 0,
// the Murata module is direct-wired, we can use 8 MHz for SPI.
.spi_freq = 8000000
};

Datasheet: https://github.com/RAKWireless/WisNode-LoRa/blob/master/Doc/RAK811%20SCH.pdf

sx1276-board.c: https://github.com/RAKWireless/RAK811_BreakBoard/blob/master/src/boards/RAK811BreakBoard/sx1276-board.c

Thanks

Lengths are expressed in the LMIC code as 5 + the payload including the mac header -- I guess for the phy header. However the lengths for the EU code are wrong in two ways:

• there's a field that's 123; it should be 128 by the above reasoning
• lengths above 123 are translated to 0xFF. This should be 230 + 5, by the same reasoning.

Needs study.

us915 doesn't work as of 04cc035 (on TMM-bandplans-1 branch).

The problem is a cut/paste error in the us915 bandplan settings during the refactor.

If you actually define -DLMIC_DEBUG_PRINTF MyLmicDebugPrintf you get warnings in compilation because it isn't declared in the LMiC modules.

I recommend adding a declaration immediately after #define

     #define LMIC_DEBUG_PRINTF(f, ...) LMIC_DEBUG_PRINTF_FN(f, ## __VA_ARGS__)
     extern void LMIC_DEBUG_PRINTF(const char *fmt, ...);

These lines don't match the spec:

Even though it's not clear exactly how these relate to the ADR_ACK_LIMIT and ADR_ACK_DELAY constants in section 2.x.9 of the 1.0.2 regional spec, it's clear that they don't match, as the DELAY and LIMIT values should differ from each other by 32 (and normally should be 32 and 64 respectively).

the LORA_DEBUG_PRINT option is hard-coded to use printf(), which isn't always available or suitable. In MCCI's environment, log_printf() is a suitable substitute, and it is much lighter on CPU load than trying to go through Serial.print() directly. Need to add the ability to inject a headerfile from the command line or configuration environment; and need the ability to specify what function to use.

• lorabase.h defines MAX_LEN_FRAME as 64, and this value is used most places (either as such or as MAX_PAYLOAD_LEN).
• lmic.h defines MAX_FRAME_LEN as 64, and this is never used (but it has a doxygen tag as an API value).
• radio.c calls writeReg(LORARegPayloadMaxLength, 64); to set the max frame length.
• lmic.c has a macro maxFrameLen() that returns the max frame size for a given data rate. However, that macro is not used.
• lmic.c checks the size of data, before copying into LMIC.pendTxData[], but then doesn't check against the data rate being used.

There seems to be no good reason that a larger frame can't be supported; the LMIC code uses the fifo in half-duplex mode, so with a larger frame buffer, bigger messages could be handled (up to the 250 byte max defined in the spec). But there also doesn't seem to be a good reason that the length is not validated against the current uplink rate before calling LMIC_setTxData().

Hai ,
Iam new to lora,
Iam using this example https://github.com/mcci-catena/arduino-lmic/tree/master/examples/raw-feather and i configure config.h file to (#define CFG_in866 1 and #define CFG_sx1276_radio 1) and iam using the adafruit M0 board (https://www.adafruit.com/product/3178).
My compilation success ,after uploading the code ,i got the following error
Starting
FAILURE
/home/neelgreev/Arduino/libraries/arduino-lmic-master/src/lmic/oslmic.c:55
can u please tell me where is the problem??where should modification occurs in code??

On some boards, SPI.begin() is used to set SPI pins:

SPI.begin(5,19,27,18);

Currently, this is hardcoded in the library, but it may be best to leave it for the user sketch.
https://www.thethingsnetwork.org/forum/t/big-esp32-sx127x-topic/10247/131

When we added random channel hopping, we added an assert if there is no 500 kHz channel enabled. This was a mistake, because the network can administratively disable 500 kHz and we should continue to work.

The Things Network recently enabled ADR for US and AU bandplans.

Unfortunately, this uncovers a bug in the LinkAdrReq processing, which causes an assert:

FAILURE .../arduino-lmic/src/lmic/lmic_us_like.c:122

Root cause: the ChMaskCntl values of 6 and 7 (especially 7) are not handled correctly. TTN sends (per the spec) 0x70 (7) and mask 0x0002 -- we are suposed to turn off all 125kHz channels, and then use the mask to turn on/off the specified 500kHz channels. We did the first, but used 7*16 == 96 as the base channel number for the 500 kHz channel.

While fixing this, code review showed that the code also doens't handle ChMaskCntl == 5 (which is effectively a subband on/off command).

I have patches tested for TTN. Need to do more testing with the RWC5020A to check the other subbands.

We probably should not assert when no 500kHz channel is enabled, but that's a different issue.

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.

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.

In preparing bandplan extensions, I noticed that three #if defined(CFG_...) are actually written as #if CFG_.... Although this has the same effect, as long as CFG_... is defined with a non-zero value, it's not robust. (Technically: the C pre-processor is required to return 0 for an undefined symbol in a #if. Since CFG_us915 and CFG_eu969 are always defined as 1, and since only one is defined, we get the same effect.)

With more than two band-plans, things are going to change and robustness is important. So.. change this.

According to LoRaWAN 1.02, section 7 (page 37), lines 21 and following:

the interval between the end of the RX2 slot and the next uplink retransmission shall be random and follow a different sequence for every device (For example using a pseudo-random generator seeded with the device‘s address)

A table that follows is hard to read, but it apparently shows the following:

The base delay is called T0 in the specification and is not used expect on that page. I believe that the implementation can choose it, but it's not clear.

In any case, the LMIC implementation doesn't do anything like this. Apart from bug #1, which leads to fairly unpredictable behavior once the first JOIN cycle fails, the delay doesn't take into account any of the above considerations.

Possibly need to consider FRAM storage of the partial join state, as devices that are power-cycling still want to delay joining (if they're in the field).

Example code doesn't build for non-US/non-AU deployments because we it uses LMIC_selectSubBand() -- needed for the US, but not even implemented as a stub for EU.

Solution probably is to provide a stub that ignores it -- or pull in some of the MCCI Aruino LoRaWAN library into LMIC so that this can be hidden from the users.

When I try to compile an LMIC example sketch with the suggested settings for the Catena 4551 board, I am getting the following error:

const lmic_pinmap' has no non-static data member named 'rxtx_rx_polarity

I have read in the Catena Arduino Lora Wan lib that I should install LMIC 2.1 version of the library to avoid this issue.

But when I followed the link there, I ended up in this repo, which does not seem to contain the correct version? Or at least the error is (still) there when I try to compile an example sketch.

assert()s are generally harmful, particularly as they cause a device hang in this implementation (rather than a restart) -- you'll have to roll a truck to get the device going again.

A code review is needed so that places where we currently assert instead:

• return errors passed back to the caller,
• continue by substituting sane values, or
• shut down the LMIC code (potentially reinitializing later)

The LoRaWAN 1.0.2 spec defines the NbTrans bits in LinkADRReq. The LMIC code correctly decodes the values in the MAC request, and copies NbTrans to LMIC.upRepeat; but after that, the values are not used.

Per 2.2.4 of LoraWAN Regional Parameters, "If the CFlist is not empty, it is ignored by the end-device".

However, the code actually discards the JoinAccept in this case.

Hi there and thanks for sharing your code fork. I'm running with your feather example. I'm using a Adafruit Feather 32u4 with LoRa Radio Module MCU. This Feather 32u4 LoRa Radio uses the RFM95W 868/915 MHz SX1276 based radio module with SPI interface.

I've left your lmic_project_config.h as is

// project-specific definitions for otaa sensor
#define CFG_us915 1
#define CFG_sx1276_radio 1
//#define LMIC_USE_INTERRUPTS

I've set

const lmic_pinmap lmic_pins = {
    .nss = 8,                         // CS pin on feather
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 4,                         //rst on feather
    .dio = {7, 1, LMIC_UNUSED_PIN},   // pin 1 jump radio dio01
};

I've jumpered DIO1 to pin 1 (TX) and from the responses back those settings seem to be working. After "EV_JOINING" is issued the code cycles through "Unknown event" and eventually "EV_JOIN_FAILED".

In Australia I need the following support

1. Sub-band 2 or Channels 8 to 15 - starting at 916.8 Mhz
2. Public Network

For setting sub-band 2 I've called

LMIC_selectSubBand(1);

Is this correct?

I've had a reasonable look through the code but cant see anything about setting Public Network option. Is there an option to do this, or is the stack already Public Network by default?

Many thanks, Dave

Defined in lmic.h conditionally; never used. Remove it.

Bandplan isn't issued yet, but when it is, we need to add support.

I had a problem with a hang when waiting for a large number of osticks (100 ms worth) running on the Feather M0 LoRa with the MCCI 1.0.4 BSP.

Investigation with prints() revealed that os_getTime() was limited (over a very large number of calls) to a range of 62 values.

junk.txt

The following awk command was used to investigate:

$ awk 'BEGIN { Max = 0; Min = 2000000; } { if ($3 > Max) Max = $3 ; if ($3 < Min) Min = $3; } END { printf("min: %x max: %x diff: %d\n", Min, Max, Max-Min); }' /c/tmp/junk.txt
min: 1069a9 max: 1069e7 diff: 62

I have not yet investigated the source of this; looking at hal_ticks() it seems that the only way this can happen is due to a bug in micros() (for example, it is only a 16-bit value). But this needs to be fixed!

When I use the LMIC library with the 868 band configured in lmic_project_config, I get an error when I compile the ABP example. The error indicates that BAND_MILLI and BAND_CENTI are not configured. Am I supposed to configure them myself in my sketch, or is this an omission in the library?

After some searching, I had the impression that BAND_MILLI should be 0, and BAND_CENTI should be 1. When I hard code these numbers in the example sketch, I can indeed send data in combination with ABP.

More detailed information about these constants would be greatly appriciated!

The example/raw-feather sketch doesn't support au921, as923jp, or in866.

Now that we can handle so many regions, it makes sense to add two APIs:

1. LMIC_getConfiguredRegionName() should return the region name as a string: "as923", "us915", etc.
2. LMIC_getConfiguredRegionIndex() should return the region index. Positive numbers 1..n should match the subsection within section 2 for the LoRaWAN regional spec.

Eventually we should have functions to map from region index to region name and vice versa. But that can wait until we switch to using function tables and allow support for multiple regions with a single codebase.

If you run the lmic code for long enough while configured for US915 without being able to join, it will assert:
FAILURE {somepath}/src/lmic/radio.c:452

Analysis of the code shows that it's failing because radio.c thinks it's been asked to transmit on FSK, and things are not set up for FSK (since there's no FSK here).

The join code continually lowers the data rate on every join failure.

I speculate that lowerDR() (from lorabase.h) is getting fooled by the data-rate lowering code into choosing an invalid/untested path, due to something from the conditional compiles.

This code looks wrong.

1. If pw is 16, it will pass through unchanged, but then the mask with 0xF will cause bits 3..0 of RegPaConfig to be set to zero instead of the desired 0xF.
2. if pw is 2..15, it will be written to RegPaConfig, but since bit 7 is also set, the output power is interpreted as 17-(15-OutputPower) [or OutputPower + 2]. So pw == 2 sets output power = 4 dBm; pw == 15 or >= 17 sets 17 dBm; and pw == 16 sets 0 dBm.

It would be best to revise this code along with the fixes for #46 so that we can handle PaSelect == 0; in that case MaxPower should be set based on the region's maximum output power, allowing finest control and then OutputPower would be adjusted within the resulting range. (We could get as low as -4.2 dBm.)

The us915 code implements duty cycle limitations for 500 kHz channels, but skips them for 125 kHz channels.

wrong RegPaDAC register number in radio.c
RegPaDac has register number 0x4D, not 0x5A, referencing to Semtech SX1276 datasheet.

The LMIC code correctly handles mac commands that are sent as options. But it doesn't handle mac commands that are explicitly sent to port 0.

This results in test failures when working with the Redwood Communications RWC5020A LoRa tester. It's also not compliant.

The default state for output pins is LOW, which is active for nss. Users will need at least one call to LMiC initialization code within setup() prior to any other peripheral engaging in SPI communication.

LMIC needs an API to set the antenna gain for regions that control maxEIRP.

Per @Cyberman74

For me it seems LMiC code in radio.c selecting the PA Output pin of SX1276 is erroneous. Always Pin PA_BOOST is selected. This can cause malfunction, if board hardware does not wire this pin, because it uses the RFO_HF / RFO_LF pins only.

Code review and checking datasheet says that current code does not actually activate high-power on PA_BOOST. It always sets RegPaDac bits 2:0 to 4. Datasheet says that to activate high-power on PA_BOOST, RegPaDac bits 2:0 must be set to 7.

However, bit 7 of RegPaConfig is always set to 1, so the output port is always the PA_BOOST at +17dBm (section 5.4.3).

There are a number of constraints on duty cycle, etc., in section 5.4.3 when using +20 dBm mode.

See also #50 (just simple errors in power-setting code).

More entries are needed in the lmic_pinmap structure to specify the board configuration re LF/HF/PA_BOOST pins of the radio. This should be combined with the SPI setting changes for #37.

For additional background see mcci-catena/ibm-lmic#15 and matthijskooijman#33.

Need support for TTN Asia 923 band plans (there are effectively two plus listen-before-talk).

The Arduino LMIC US915 code has MAX_XCHANNELS, which are channels that are supported beyond channel 72, apparently for repeaters. This concept is not present in LoRaWAN 1.0.2, and is not supported by networks. It probably should be removed.