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?
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).
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.
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.
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.
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).
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.
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”.
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?
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)
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.
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.
Hi, I am having the same problem “EV_JOIN_TXCOMPLETE: no JoinAccept” but i think its due to the fact that i dont know how to register my Feather M0 Lora devide in the new V3 console.
Yes many users know because they read documentation and information already available on the forum.
You will also be able to find enough information on the forum about possible reasons for why joins are failing and only seeing EV_JOIN_TXCOMPLETE. The Search tool is there to assist you.
I could not find any topic that involver the adafruit Feather M0 Lora and TTN Console V3. I would greatly appreciate if you point me in the right direction.
The Adafruit Feather M0 LoRa is just another DIY type LoRaWAN device that uses/needs the LMIC LoRaWAN library.
There is nothing special about the device so all information related to ‘LMIC and DIY type devices’ is applicable to this device.
