Feather M0 EV_JOIN_TXCOMPLETE: no JoinAccept problem

End Devices (Nodes) LMIC
14

Hi,

Ok plopped it in after the init and the reset. I waited for a few loops of the no JoinAccept and still not connecting. At this point I’ll thank you for all your help. I don’t want to waste anyone’s time. I have multiple different boards winging their way in from China so I’ll probably have more questions in the future.

Thanks again.

// LMIC init
os_init();
// Reset the MAC state. Session and pending data transfers will be discarded.
LMIC_reset();

LMIC_setClockError(MAX_CLOCK_ERROR * 3 / 100);
LMIC_setLinkCheckMode(0);
LMIC.dn2Dr = DR_SF9;
LMIC_setDrTxpow(DR_SF7,14);
//LMIC_selectSubBand(1);

// Start job (sending automatically starts OTAA too)
do_send(&sendjob);

15

Hi,
Willem messaged me and I found I had made a very stupid error when manually converting the big to little endian. I feel quite embarrassed but I wanted to make sure he is thanked.

Again thank you for your time everyone. This has been driving me crazy for days. Before this I had all sorts of issues on Windows and the Com ports refusing to work. Irritated me so much I installed Ubuntu and set it all up again.

1 Like
16

No, not for the OTAA Join Accept downlinks; only for regular downlinks.

FYI: TTN Console can do that for you.

2 Likes
17

Even though the issue here seems to be rather old, I’m running into it anew.

My setup:

  • Feather M0 LoRa with the D-stepping silicon (so there should be no problem with SPI timing)
  • Latest Adafruit SAMD BSP, v. 1.6.1
  • MCCI LMIC 3.2.0

Pinmap:

const lmic_pinmap lmic_pins = {
.nss = 8,
.rxtx = LMIC_UNUSED_PIN,
.rst = 4,
.dio = {3, 6, LMIC_UNUSED_PIN},
.rxtx_rx_active = 0,
.rssi_cal = 8
}

I used the example application ten-otaa-feather and adjusted the band for eu-868. I registered an application and my device at the TTN console and correctly entered APPEUI, DEVEUI and APPKEY, respecting endianness. I adjusted the clock error tolerance and set the RX2 listening mode to SF9 - all recommendations from various threads here.

Yet, OTAA joining repeatably fails on the first attempts, even though I can see the packets arriving in the TTN console. That is, even the first join packet at SF7, 125kHz arrives at the TTN, but the reply seems to get lost. In the TTN console, I do see how the radio increases the spreading factor with every other attempt. After about 10 trials, at SF10 or SF11, a join finally succeeds. However, by then, four or five gateways are picking up the signal (I’m in central Berlin) - so, coverage is definitively not the problem.

I found similar problems in various threads here, dating back to 2016. By now, boards, libraries and the TTN have evolved, so I suspect things should work fine. What am I doing wrong? How can I pinpoint the problem?

Thanks very much for your help!

18

I can confirm that this problem persists, even with severe bugfixes of MCCI LMIC 3.2.0. I did deep analysis of timing, RF radio etc., with the conclusion that the join accept message is for some reason not sent by the gateway. My assumption is that this is a network congestion problem, maybe caused by duty cycle limits of EU868 band or by some bottleneck in TTNv2 backend. Could not yet test with v3. I gave up my efforts trying to fix this with TTN.

1 Like
19

See Using LMIC_setClockError on MCCI LMIC [HowTo] for notes about LMIC_ENABLE_arbitrary_clock_error and differences between SFs.

To debug you’ll need to keep an eye on everything: SF, maybe even on the frequencies that work/don’t work, and which of the gateway(s) that received the Join Request is selected to transmit the Join Accept and which work and which don’t. (But you’ll need access to the gateways to see that.)

For OTAA, that’s an error. It should only be configured for ABP in EU868. It will probably only affect joins on SF12 though, if anything at all.

20

Thanks very much for your suggestions!

I removed the RX listening mode and tried the LMIC_ENABLE_arbitrary_clock_error flag, but to no avail. Going through the different SFs for the JOIN request via LMIC_setDrTxpow did not seem to work, either. The TTN Console always reported SF7 for the first JOIN message it received.

Unfortunately, I do not have access to my own gateway, so I cannot see if the network always transmits a JOIN_ACCEPT message, and via which gateway of 4-5 I am in range of.

I’m also having trouble with two additional aspects. Maybe someone here can give me a link to additional resources?

21

I don’t know for sure how LMIC determines the first data rate to use for OTAA. (Indeed, I thought it started joining using whatever was set using LMIC_setDrTxpow, but maybe not.)

However, an OTAA Join Accept downlink is not much different from a regular downlink (except for RX1 being 5 seconds rather than 1, RX2 being 6 seconds instead of 2, and for RX2 in EU868 using SF9 like configured automatically in the EU868 Join Accept). So, it may be easier to test regular downlinks first (maybe even using ABP, along with manually setting LMIC.dn2Dr = DR_SF9 for EU868).

Also, to increase the chances a specific gateway is used (if you suspect that some gateway may not transmit the Join Accept, like due to network latency of that very gateway), you may want to move closer to a specific gateway, to see if that helps. If duty cycle limitations allow for it then TTN will usually select the gateway with the best reception of the uplink (Join Request) to transmit the downlink (Join Accept).

1 Like
22

I would agree, if your at a dead end then just ensure that basic downlink functionality is working by setting up as ABP, this then takes the question off the table - you can obviously send downlinks from the console to the device then and watch the device logs as the downlinks are received, I like to test with ACK set too.

24

Your problem looks similar to when (D)IO1 of the RFM95/SX1276 LoRa module is not correctly wired/mapped.

In that case downlinks will not work and hence OTAA joins will fail.
(LMIC uses DIO0 for uplinks and for downlinks it also needs DIO1.)

Example ttn-abp.ino uses ABP and by default sends / tests uplink messages only.
Example ttn-otaa.ino uses OTAA which requires downlink messages to work, otherwise OTAA joins will fail. This is why I always suggest to try the LMIC example ttn-abp.ino first.

Have you actually (manually) wired (D)IO1 to digital pin 6 (and verified this)?
This is sometimes overlooked and also bad breadboard connections/wires may cause issues.

25

Thanks for your help!
To my understanding, the Feather board seems to be wired correctly. I am using the integrated Feather/LoRa board. It has the Radio already wired up as described here, with CS -> #8, DIO0/IRQ -> #3, and Reset -> #4. In addition, I followed the setup here, which additionally connects DIO1 -> #6. This should match my pinmap.

Indeed, the downlink seems to be working sporadically. I can get an OTAA JOIN to work in something between 20 minutes and 2 hours. And with ABP and a manually scheduled confirmed downlink form the TTN console, I eventually receive that downlink within 20 min to two hours as well, when transmitting one packet per minute continuously.

26

If you check your application / device in the TTN console, when clicking on a message in the Data log you can see which gateways have received the message and with what RSSI and SNR values.
How many gateways actually do receive your messages? What RSSI and SNR does each gateway report? And what spreading factor (SFx) is reported when using OTAA?

Maybe the gateways are too far or obstructed and/or the quality of your antenna is insufficient.

The Feather M0 LoRa appears not to have an I-PEX/U.FL antenna connector mounted by default, which only leaves the possibility to solder a simple wire as antenna.
The exact length of this wire is very critical, especially if gateways are not very nearby (and being a monopole antenna, the effect of a good antenna groundplane (or lack thereof) can have major effect on antenna effectiveness). The wire antenna should also nicely standup straight in order to function properly.

Looking at some Feather M0 LoRa images of the bottom PCB side I notice that there is place for soldering an I-PEX/U.FL antenna connector on the PCB.
This would allow for attaching a better quality antenna to the board, but also requires the skills to solder tiny SMT parts.
If not already present I really don’t understand why a U.FL antenna connector (costing few cents) has not been mounted at the factory by default already (those Adafruit boards are expensive enough already).

When using ABP, do your uplink messages arrive almost instantly on the TTN console, or does that take 20 minutes to hours as well?
You really should check this (using ttn-abp.ino).

27

I’m in central Berlin, with quite a few gateways in range.

When the JOIN finally went through, at SF12 because of the flaky downlink, I could see 5 gateways in the TTN Console.

When transmitting with ABP at SF9, I consistently see 2 gateways receiving my uplink messages, with {RSSI: -120dBm, SNR: -12.5dB} and {RSSI: -120dBm, SNR: -3 dB}. For some transmissions, I see a third gateway with {RSSI: -118 dBm, SNR: - 6,5 dB}., So, the uplink seems to ok. Messages get through quickly, in a matter of seconds.

I am aware that the receiver on a small embedded radio is probably much worse than a receiver at a gateway, which typically has a much better LNA and a much better antenna. However, given that the uplink is fine at SF9, I do not think that my radio is so bad that it cannot pick up the downlink signal even at SF12 most of the time.

28

I am not a RF specialist that can judge and interpret these numbers well, but RSSI -120 dBm with -12.5dB SNR does not look exactly great to me.

Just curious, have you tried sending with ABP with SF7 and SF8 and then looked at RSSI and SNR values?

Have you tried testing your node at other locations (not nearby your current) (in Berlin)?

What about your antenna?

Question to others: is it possible that a SCPF (single channel packet forwarder) is causing the experienced downlink issues (could one of the reported gateways be a SCPF)?
Although probably less likely due to “I consistently see 2 gateways”.

29

I haven’t found the place in the LoRa specification that shows the bit-error-rate and packet-error-rate curves for each SF and coding rate vs. SNR. These would be the reference to judge which SNR values are ok and which are not. Does anyone know where to find these figures?

30

If you want to be sure that this is not a problem caused by your code, you can try the latest release of the paxcounter software. I am testing in central Berlin, too, and get immediately join with a TTGO T-Beam 1.0 and paxcounter (based on MCCI LMIC 3.2.0)

31

What use has PaxCounter on Feather M0 LoRa?

It is not ESP32 and has neither WiFi nor Bluetooth.

32

oops, sorry, didn’t look at that.

33

Here is a paper with analytical results and numerical evaluations for the symbol error rate (SER) and the frame error rate (FER) for LoRa reception in Gaussian noise and in the presence of unsynchronised interference from other LoRa transmissions. Fig. 9 provides an estimate of the required SNR for successful reception.

From Figure -12 dB SNR seems to be ok for SF10 and SF11 under the rather sever interference conditions assumed in the paper. With no interference, Fig. 2 implies that -12 dB should be ok for SF9 as well.

34

As mentioned, these not great numbers.

A possibility they raise, is that if the gateway is receiving the node that weakly, the signal from the gateway at the node may also be weak.

LoRa modulation is far more resistant to a lot of types of noise than other radio schemes, but that immunity is not total. You might consider things like trying a an electrically quieter power supply.

You might verify the antenna is of the right length, and you might stand it up and put a ground plane under it.

You might also try finding a better location to test from - ie take it up on a roof balcony, find a hill to climb, etc.

Ultimately its far easier to debug node firmware if you have physical and administrative access to a conventional gateway with open-source software running on an embedded Linux host.