Strange problem: RFM95 + LMIC-Arduino, long JOIN delays and missing frames

[bluejedi]

@tweil

Arduino Uno and Dragino Shield v1.4
Atmel 328P and Hope RF95RFM
Powered on at 9:33pm, Transmit every 20 seconds.

Unfortunately, this was one of the rare times it worked well. The JOIN was less than 1 minute:

It is more useful to do some retries and show logging where the issues DO happen.

Looking at your first logs I observe the following:

• Things Uno does a JOIN REQUEST on SF10BW125. JOIN ACCEPT received on SF10BW500.
  It does the join request on SF10BW125 and not one of the lower spreading factors.
  Is this US / 915MHz specs or a ‘feature’ of the Things Uno / RN2903 (sketch)?

• After Things Uno receives the JOIN ACCEPT the first message is transmitted on SB7BW125. How does it know to transmit on SB7, is this ADR already ‘kicking in’ embedded in the join accept? is this US / 915MHz specs? or is this a feature of the Things Uno / RN2903 (sketch)?

• The Arduino Uno starts its JOIN REQUEST on SF9BW125, not SF10BW125 like Things Uno and JOIN accept is received on SF9BW500.
  Why does it start the request on SF9BW125 while Things Uno starts on SF10BW125?

• Arduino Uno starts it first message on SF9BW125, which is different from Things Uno.
  After first (uplink) message a downlink message is received on SF9BW500. The next message is sent at SF7BW125, so apparently this is ADR kicking in. A separate downlink message appears to be used for this, that downlink message is not visible in the log for Things Uno.

• After the second uplink message another downlink message is received (at SB7BW125). What is it for? Maybe another ADR related message to adjust the power?

While the Arduino Uno + RFM95 + LMIC-Arduino combination appears to be working fine here, there are some notable differences with how the Things Uno behaves.

(FYI, as noted before I have little knowledge about US / 915MHz specs/specifics.)

[bluejedi]

@tweil

Moteino and HopeRFM95
Atmel 328P and Hope RF95RFM (device says Adafruit RFM9x, but that module was not used here)
Powered on at 9:54pm, Transmit every 20 seconds.

In this case, the JOIN was under a minute, but data did not begin to populate the Application Data for 40 minutes, and then it started at counter 109. As you can see below, the Frame Counter started at 0.

Observations:

• With the Moteino JOIN REQUEST starts on SF8BW125. This is different from both Things Uno and Arduino Uno.

• I see 3 downlink messages. For Arduino Uno there were only two, For Things Uno there were none.

• Frame counter starts at 109 instead of 0.
  The time lapse between JOIN ACCEPT and the first message visible (frame 109) is around 30 minutes.
  With around 1 uplink message every 20 seconds that whould be about 30 x 3 = 90 messages which comes close to the frame count 109.

• Message with framecounter 109 appears to be the first message that is successfully received on the backend, because you see ‘almost directly’ appear three downlink messages after that which are probably ADR related. With Arduino Uno these downlink messages came ‘quickly after’ the join accept so it is plausible that the backend sees uplink message with framecounter 109 as the first successful uplink message (which is an assumption).

• Once ‘the flow has started’ everything appears to continue normally.

Questions:

• Assuming message with frame 109 was the first successfully received message by the backend, then what could be causing this?:
  – An error on the node (in LMIC-Arduino)?
  Would it be possible that the node periodically increments the framecounter every 20 seconds without actually sending out any message for half an our?
  An error on the node appears the most plausible.
  – An error on the gateway side? Less likely (but not impossible).
  – An error on the backend side? Less likely (but not impossible).

• Is this issue US / 915MHz related?
  Would this be easy to pinpoint in LMIC-Arduino?

Todo:

• What do you see happening in Console Gateway Overview in the received messages counter, does it increment between the Moteino’s JOIN REQUEST and sending the ‘first’ uplink message (framecounter 109)?

• Similar for Console Device Overview.
  What do Status , Frames up and Frames down show between JOIN REQUEST and transmitting the ‘first’ uplink message (framecounter 109)?

[bluejedi]

In the Arduino Uno? and Moteino node logs the join requests appear to be starting at SB7BW125 and then the spreading factor is gradually increased. This is not visible on the console logs but is probably because you have not included the failed join requests in the console log screendumps()?

This at least explains the behavior of and the difference between Arduino Uno succeeding the join at SF10BW125 and the Moteino succeeding the join at SF9BW125 (they both started joining at SF7BW125 but it is just not visible on the Console screen dumps).
This (failing to join at SF7BW125) behavior with Arduino’s and LMIC is normally fixed with relaxing LMIC timing.

It does not explain why Things Uno initally joins at SF10BW125 (which the directly switches to SF7BW125 when transmitting its first message).

[bluejedi]

The Arduino M0 uses a SAMD ARM based microcontroller which is very different from the ATmega328(u4) AVR microcontrollers. It uses a diffenrent tool chain and different Arduino core.

You could experience similar experiences but the underlying technology is different.
Another MCU that can give problems in combination with LMIC-Arduino are (certain) STM32 ARM based microcontrollers. These also use a different toolchain and different Arduino core than the Atmel AVR controllers.
In case of the STM32 the issues manifest that LMIC completely hangs, which is different from your issues with Arduino M0.

[tweil]

@bluejedi

Todo:

• What do you see happening in Console Gateway Overview in the received messages counter, does it increment between the Moteino’s JOIN REQUEST and sending the ‘first’ uplink message (framecounter 109)?

It might be worth noting that there were 4 minutes between JOIN REQUEST and JOIN ACCEPT or it might be expected. Here are the logs:

Click to see the full logs

> Starting
> 169: engineUpdate, opmode=0x8
> Packet queued
> 2291: EV_JOINING
> 3460: engineUpdate, opmode=0xc
> 5748: TXMODE, freq=902300000, len=23, SF=7, BW=125, CR=4/5, IH=0
> 316258: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
> 377982: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 387544: engineUpdate, opmode=0xc
> 408404: engineUpdate, opmode=0xc
> 408704: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 719168: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
> 780827: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 790452: engineUpdate, opmode=0xc
> 860912: engineUpdate, opmode=0xc
> 861213: TXMODE, freq=903700000, len=23, SF=8, BW=125, CR=4/5, IH=0
> 1175677: RXMODE_SINGLE, freq=927500000, SF=8, BW=500, CR=4/5, IH=0
> 1238433: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 1247994: engineUpdate, opmode=0xc
> 1285461: engineUpdate, opmode=0xc
> 1285763: TXMODE, freq=914200000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 1596228: RXMODE_SINGLE, freq=927500000, SF=7, BW=500, CR=4/5, IH=0
> 1657888: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 1667448: engineUpdate, opmode=0xc
> 1945076: engineUpdate, opmode=0xc
> 1945378: TXMODE, freq=909700000, len=23, SF=9, BW=125, CR=4/5, IH=0
> 2265571: RXMODE_SINGLE, freq=926300000, SF=9, BW=500, CR=4/5, IH=0
> 2328264: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 2337825: engineUpdate, opmode=0xc
> 2365286: engineUpdate, opmode=0xc
> 2365588: TXMODE, freq=911000000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 2676055: RXMODE_SINGLE, freq=926300000, SF=7, BW=500, CR=4/5, IH=0
> 2737714: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 2747350: engineUpdate, opmode=0xc
> 3407805: engineUpdate, opmode=0xc
> 3408107: TXMODE, freq=902300000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 3738734: RXMODE_SINGLE, freq=923300000, SF=10, BW=500, CR=4/5, IH=0
> 3801298: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 3810858: engineUpdate, opmode=0xc
> 3840822: engineUpdate, opmode=0xc
> 3841124: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 4151589: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
> 4213249: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 4222809: EV_JOIN_FAILED
> 4222838: engineUpdate, opmode=0xc
> 4389635: engineUpdate, opmode=0xc
> 4389936: TXMODE, freq=912300000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 4720563: RXMODE_SINGLE, freq=924500000, SF=10, BW=500, CR=4/5, IH=0
> 4783127: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 4792688: engineUpdate, opmode=0xc
> 4809118: engineUpdate, opmode=0xc
> 4809420: TXMODE, freq=906200000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 5119886: RXMODE_SINGLE, freq=924500000, SF=7, BW=500, CR=4/5, IH=0
> 5181545: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 5191106: EV_JOIN_FAILED
> 5191135: engineUpdate, opmode=0xc
> 5793278: engineUpdate, opmode=0xc
> 5793580: TXMODE, freq=911700000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 6124206: RXMODE_SINGLE, freq=927500000, SF=10, BW=500, CR=4/5, IH=0
> 6186770: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 6196331: engineUpdate, opmode=0xc
> 6258031: engineUpdate, opmode=0xc
> 6258332: TXMODE, freq=914200000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 6568798: RXMODE_SINGLE, freq=927500000, SF=7, BW=500, CR=4/5, IH=0
> 6630458: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 6639955: EV_JOIN_FAILED
> 6639984: engineUpdate, opmode=0xc
> 6851697: engineUpdate, opmode=0xc
> 6851998: TXMODE, freq=908300000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 7182561: RXMODE_SINGLE, freq=926900000, SF=10, BW=500, CR=4/5, IH=0
> 7245125: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 7254760: engineUpdate, opmode=0xc
> 7299393: engineUpdate, opmode=0xc
> 7299694: TXMODE, freq=912600000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 7610224: RXMODE_SINGLE, freq=926900000, SF=7, BW=500, CR=4/5, IH=0
> 7671885: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 7681445: EV_JOIN_FAILED
> 7681475: engineUpdate, opmode=0xc
> 8361638: engineUpdate, opmode=0xc
> 8361940: TXMODE, freq=911900000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 8692502: RXMODE_SINGLE, freq=923300000, SF=10, BW=500, CR=4/5, IH=0
> 8755066: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 8764563: engineUpdate, opmode=0xc
> 8815144: engineUpdate, opmode=0xc
> 8815446: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 9125911: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
> 9187571: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 9197132: EV_JOIN_FAILED
> 9197161: engineUpdate, opmode=0xc
> 10161398: engineUpdate, opmode=0xc
> 10161701: TXMODE, freq=913900000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 10492137: RXMODE_SINGLE, freq=924500000, SF=10, BW=500, CR=4/5, IH=0
> 10554700: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 10564197: engineUpdate, opmode=0xc
> 10585533: engineUpdate, opmode=0xc
> 10585837: TXMODE, freq=906200000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 10896368: RXMODE_SINGLE, freq=924500000, SF=7, BW=500, CR=4/5, IH=0
> 10958028: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 10967525: EV_JOIN_FAILED
> 10967557: engineUpdate, opmode=0xc
> 11319325: engineUpdate, opmode=0xc
> 11319628: TXMODE, freq=906100000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 11650063: RXMODE_SINGLE, freq=925100000, SF=10, BW=500, CR=4/5, IH=0
> 11712627: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 11722135: engineUpdate, opmode=0xc
> 11757196: engineUpdate, opmode=0xc
> 11757499: TXMODE, freq=907800000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 12068031: RXMODE_SINGLE, freq=925100000, SF=7, BW=500, CR=4/5, IH=0
> 12129628: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 12139125: EV_JOIN_FAILED
> 12139157: engineUpdate, opmode=0xc
> 13027994: engineUpdate, opmode=0xc
> 13028297: TXMODE, freq=903900000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 13358731: RXMODE_SINGLE, freq=923300000, SF=10, BW=500, CR=4/5, IH=0
> 13367039: EV_JOINED
> 13367070: engineUpdate, opmode=0x808
> 13367530: TXMODE, freq=902700000, len=26, SF=10, BW=125, CR=4/5, IH=0
> 13451741: RXMODE_SINGLE, freq=924500000, SF=10, BW=500, CR=4/5, IH=0
> 13514369: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 13518741: EV_TXCOMPLETE (includes waiting for RX windows)
> 13518789: engineUpdate, opmode=0x900
> 14768789: engineUpdate, opmode=0x908
> 14769249: TXMODE, freq=902900000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 14854741: RXMODE_SINGLE, freq=925100000, SF=10, BW=500, CR=4/5, IH=0
> 14917368: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 14921677: EV_TXCOMPLETE (includes waiting for RX windows)
> 14921724: engineUpdate, opmode=0x900
> 16171724: engineUpdate, opmode=0x908
> 16172183: TXMODE, freq=903100000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 16257739: RXMODE_SINGLE, freq=925700000, SF=10, BW=500, CR=4/5, IH=0
> 16320367: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 16324740: EV_TXCOMPLETE (includes waiting for RX windows)
> 16324787: engineUpdate, opmode=0x900
> 17574787: engineUpdate, opmode=0x908
> 17575247: TXMODE, freq=903300000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 17660801: RXMODE_SINGLE, freq=926300000, SF=10, BW=500, CR=4/5, IH=0
> 17723429: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 17727801: EV_TXCOMPLETE (includes waiting for RX windows)
> 17727849: engineUpdate, opmode=0x900
> 18977850: engineUpdate, opmode=0x908
> 18978310: TXMODE, freq=903500000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 19063866: RXMODE_SINGLE, freq=926900000, SF=10, BW=500, CR=4/5, IH=0
> 19126493: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 19130866: EV_TXCOMPLETE (includes waiting for RX windows)
> 19130914: engineUpdate, opmode=0x900
> 20380913: engineUpdate, opmode=0x908
> 20381373: TXMODE, freq=903700000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 20466928: RXMODE_SINGLE, freq=927500000, SF=10, BW=500, CR=4/5, IH=0
> 20529556: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 20534003: EV_TXCOMPLETE (includes waiting for RX windows)
> 20534051: engineUpdate, opmode=0x900
> 21784050: engineUpdate, opmode=0x908
> 21784510: TXMODE, freq=903900000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 21870066: RXMODE_SINGLE, freq=923300000, SF=10, BW=500, CR=4/5, IH=0
> 21876412: Received downlink, window=RX1, port=-1, ack=0
> 21876459: EV_TXCOMPLETE (includes waiting for RX windows)
> 21879674: engineUpdate, opmode=0x800
> 23129674: engineUpdate, opmode=0x808
> 23130134: TXMODE, freq=904100000, len=28, SF=8, BW=125, CR=4/5, IH=0
> Packet queued
> 23197543: RXMODE_SINGLE, freq=923900000, SF=8, BW=500, CR=4/5, IH=0
> 23199491: Received downlink, window=RX1, port=-1, ack=1
> 23201195: EV_TXCOMPLETE (includes waiting for RX windows)
> 23205032: engineUpdate, opmode=0x800

The Console Gateway Overview in the received messages counter does NOT increment between the Moteino’s JOIN REQUEST and sending the ‘first’ uplink message

Gateway Overview Before JOIN REQUEST and Before any frames appear in Gateway Traffic or Application Data. Received Messages: 26161

Gateway Overview shows Received messages increased 3 after JOIN REQUEST and 2 successful frames (frames 6 and 7) appear in Gateway Traffic and Application Data. Received Messages: 26164

@bluejedi

• Similar for Console Device Overview.
  What do Status , Frames up and Frames down show between JOIN REQUEST and transmitting the ‘first’ uplink message (framecounter 109)?

Console Device Overview before JOIN REQUEST and while waiting for Frames to populate Application Data: Frames Up/Down: 0

Console Device Overview after JOIN Accept and 7 frames received (counter 6 and 7)

[tweil]

@bluejedi

In the Arduino Uno? and Moteino node logs the join requests appear to be starting at SB7BW125 and then the spreading factor is gradually increased. This is not visible on the console logs but is probably because you have not included the failed join requests in the console log screendumps()?

I did not purposely not include failed join requests in the console log screendumps. Is there a way to make them visible? I tried to include as much as I could.

By the way, thanks so much for all the time you have put into helping me. Hopefully, we will all learn something.

[bluejedi]

@tweil

I did not purposely not include failed join requests in the console log screendumps. Is there a way to make them visible? I tried to include as much as I could.

Not a problem. The join requests will be visible in the gateway traffic log and when you then see a join accept but no transmit from the first message (‘directly’) afterwards then the node hasn’t properly pickup up the accept. This is what I call ‘failed join request’.

Your screen captures have confirmed what you already said and the symptoms are not normal, but I am running out of ideas.

Tip: Changing the title to a better description of the problem may also help get more input. (e.g. “Strange problem with RFM95 + LMIC-Arduino: long OTAA JOIN delays and missing frames” or something similar.)

Maybe @matthijskooijman, @htdvisser, @GrumpyOldPizza or @kersing have an idea of what could be happening here and how it may be fixed.

[bluejedi]

with implementations for each of the popular microcontroller families and frameworks, Arduino included.

@kersing

They do provide a reference implementation at GitHub - Lora-net/LoRaMac-node: Reference implementation and documentation of a LoRa network node.

Reference implementation for STM32 and SAMD/SAML ARM only. No AVR, ESP32, ESP8266 and no Arduino support.

[tweil]

@bluejedi

Tip: Changing the title to a better description of the problem may also help get more input. (e.g. “Strange problem with RFM95 + LMIC-Arduino: long OTAA JOIN delays and missing frames” or something similar.)

Good idea. How do I change the title? I searched around and can’t figure it out.

[bluejedi]

Sorry, I forgot. After +/- 3 days posts cannot be edited anymore, so you can probably also not edit the title anymore. But I can do it for you, just did. (Just let me know if you want the title different.)

[tweil]

Perfect. Thanks!

[tlu]

I’m in EU so haven’t used the US frequency plans, so bear with me …

According to:
https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html#us902-928

there are a set of uplink and a separate set of downlink frequencies. I assume that an uplink on Uplink channel 1 would result in a downlink message on the Downlink channel 1. Is that how it works?

In the Arduino-lmic logs in this threads there are transmissions on frequencies that are not listed in the frequency plan, for instance 902300000 and 912600000.

Is the node using the correct frequencies for the region?

[tweil]

@tlu

According to:
https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html#us902-928

I think the US902-928 Frequency plan listed frequency plan you mention is incomplete. I am using the arduino-lmic library and selecting the US plan by using the following in lmic/config.h, so I don’t have any control over the frequencies.

#define CFG_us915 1

This document, although not the more definitive one I was looking for, has some info on US frequencies and channels and shows they start at 902.3 Mhz and go up from there.

http://193.40.244.77/idu0310/wp-content/uploads/2015/09/Sammelsaar_Kotkasets_IoT_report.pdf

US 902-928 MHz
In the United States, LoRaWAN operates in the 902-928 MHz frequency band. Unlike
the European band, the US band has dedicated uplink and downlink channels. The
band is divided into 8 sub-bands that each have 8x125 kHz uplink channels, 1x500 kHz
uplink channel and 1x500 kHz downlink channel.
US 902-928 MHz channel frequencies:
The 915 MHz ISM Band shall be divided into the following channel plans.
- Upstream – 64 channels numbered 0 to 63 utilizing LoRa 125 kHz BW varying
from DR0 to DR3 starting at 902.3 MHz and incrementing linearly by 200 kHz to
914.9 MHz.
- Upstream – 8 channels numbered 64 to 71 utilizing LoRa 500 kHz BW at DR4
starting at 903.0 MHz and incrementing linearly by 1.6 MHz to 914.2 MHz.
- Downstream – 8 channels numbered 0 to 7 utilizing LoRa 500 kHz BW at DR10
to DR13) starting at 923.3 MHz and incrementing linearly by 600 kHz to 927.5
MHz.
US 902-928 end-devices should be capable of operating in the 902 to 928 MHz
frequency band and should feature a channel data structure to store the parameters of
72 channels. A channel data structure corresponds to a frequency and a set of data
rates usable on this frequency

[kersing (Jac Kersing)]

@tweil

I think the US902-928 Frequency plan listed frequency plan you mention is incomplete

Would you care to share what you think is missing? Your quote does not clarify your statement (for me).

BTW, as the listed plan is implemented and being used by several US based users with success I think it might be alright.

For LMIC frequency control you could take a look at this ancient message: LMIC Node, dropped packets? - #9 by brandonbyrne

[tweil]

@kersing

Would you care to share what you think is missing? Your quote does not clarify your statement (for me).

BTW, as the listed plan is implemented and being used by several US based users with success I think it might be alright.

@tlu

I’m in EU so haven’t used the US frequency plans, so bear with me …

According to:
https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html#us902-928

there are a set of uplink and a separate set of downlink frequencies. I assume that an uplink on Uplink channel 1 would result in a downlink message on the Downlink channel 1. Is that how it works?

In the Arduino-lmic logs in this threads there are transmissions on frequencies that are not listed in the frequency plan, for instance 902300000 and 912600000.

Is the node using the correct frequencies for the region?

As I look into this further, I think tlu might have hit on the problem with the missing frames and slow joins. If so, I stand corrected and apologize for jumping to conclusions. I am relatively new with LoraWan and TTN, so bear with me as I try to understand and learn.

From reading other documentation, I thought that US 915MHz LoraWan nodes could use any of 72 channels available between 902-928Mhz. I just specified US915 when using the Arduino-LMIC library with my DIY Arduino and RFM95 nodes. It seems that one has to be more specific about exactly which 9 Uplink and 8 Downlink TTN frequencies to use with Arduinio-LMIC and The Things Network, although I’m not exactly sure how to configure it. Other LoraWan 915Mhz networks may use other frequencies.

The US Frequency Plan listed on The Things Network documentation is here:https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html#us902-928

As I look at the Gateway Traffic for one of my Arduino + RN2903 nodes, similar to The Things Uno, which uses TheThingsNetwork library and specifies the TTN_FP_US915 frequency plan, sure enough I only see uplinks and downlinks on one of the 9 uplink and 8 downlink frequencies that matches the TTN documentation. The JOINs are immediate and there are no missed frames. There is nothing special one needs to do when using TheThingsNetwork library other than specify the TTN_FP_US915 frequency plan in the sketch and all the correct frequencies are used.

When I run one of my Arduino-LMIC nodes (Arduino + RFM95), I can look at both the Serial Monitor, which shows each transmitted packet along with the frequency used and I can look at the Gateway Traffic log. Each time there is a Uplink transmission shown in the Serial Monitor that is not one of the frequencies listed in the TTN documentation, nothing shows up in the TTN Gateway Traffic log. Duh! For JOINs, incorrect frequencies are rotated through until the node somewhat randomly transmits on a TTN frequency and then the JOIN works. For Uplinks, more or less the same thing happens. The node transmits Uplinks over and over with non TTN frequencies and increments the Frame Counter each time. For each of these Uplinks, nothing shows up in the Gateway log. Again, Duh! Sooner or later, the node somewhat randomly transmits an Uplink with a correct TTN frequency and the Uplink appears in the Gateway Traffic log. For some odd reason, from that point on the node always uses one of the accepted TTN frequencies for every Uplink and no more frames are missed.

So to summarize, I think the problem with the Arduino-LMIC nodes joining slowly and missing frames is that the library is not correctly configured to use only the TTN frequencies. The question now is how does one correctly configure the Arduino-LMIC library. Thank you, tlu.

[kersing (Jac Kersing)]

Take a look at the link I included in my previous message, that shows code on how to force LMIC to use only TTN supported channels.

@tweil

I thought that US 915MHz LoraWan nodes could use any of 72 channels available between 902-928Mhz

Gateways use the SX1301 or SX1308 from Semtech. These process 8 channels in parallel. Most gateways (all I’ve seen offered for sale so far) use only 1 of them so only support 8 of the available channels. Increasing the number of channels requires additional hardware (not only these controllers) so cost will increase.

[rharte]

@tweil on your OTAA problem, please be advised that there are two join receive windows RX1 and RX2 and there are stacks which have implemented only one of them. So if your sketch is only listening in RX2 and the network answers in RX1, it might seem that your join procedure is very lengthy and not robust, while in fact you are missing the join accept messages all the time.

With respect to the LMIC library: I fully agree with your observations to its complexity. We totally stripped it down and rebuilt it, and then it even fits in an ATtiny85 (8 kB)! We don’t have the full stack implemented, but all the necessary stuff is in there. This way you can make a 5 dollar node. You need to be creative with the timing because the ATtiny only has so much IO lines but it can be done. You can have robust operation, receive in RX1 and RX2, even without the DIO lines. This leaves you with one I/O for a sensor, plus the reset input that you can use (with restrictions!) for analogue input.

[Sandgroper]

The Cisco Lora Gateway supports 16 channels. https://www.cisco.com/c/en/us/products/routers/wireless-gateway-lorawan/index.html

[bluejedi]

@rharte

please be advised that there are two join receive windows RX1 and RX2 and there are stacks which have implemented only one of them. So if your sketch is only listening in RX2 and the network answers in RX1, it might seem that your join procedure is very lengthy and not robust, while in fact you are missing the join accept messages all the time.

The issues occur when using LMIC-Arduino, not ‘some other stack’. I assume that LMIC-Arduino checks both RX1 and RX2 join receive windows. If so then checking only one RX window is not the case here and not what is causing the issues here.