Thanks for all the responses and help.
I did mention a Pro Mini when I was discussing prices, but the two nodes I am actually testing with are comprised of slightly faster:
- Ardunio Uno R3 with a Dragino 1.4 Shield (5V, 16Mhz with level shifters in the Dragino shield)
- Moteino R6 with no onboard transceiver
(Specifications | All about Moteino | LowPowerLab) an Atmel 328p board running at 3.3V and 16Mhz connected directly to a Hope RFM95 Lora module.
So these nodes are not slow 8Mhz Pro Mini, but I tried the relaxed timing.I put the relaxed timing command just after the reset command in each sketch. Is this correct?
// Reset the MAC state. Session and pending data transfers will be discarded.
LMIC_reset();
// Have you relaxed the timing by using
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
// Start job (sending automatically starts OTAA too)
do_send(&sendjob);
After adding the relaxed timing command my Uno/Dragino node joined during the first attempt at SF9. Sometimes the join is still failing many times until successful. Occasionally, the JOIN fails continuously until after another reboot attempt.
Should the timing be relaxed even further, and if so, how much and what is the command?
Here is the Gateway Console after a successful JOIN.
Here is the node log from a fast JOIN at SF9 :
Starting that joins at SF9
217: engineUpdate, opmode=0x8
Packet queued
2340: EV_JOINING
3509: engineUpdate, opmode=0xc
5796: TXMODE, freq=902300000, len=23, SF=7, BW=125, CR=4/5, IH=0
316243: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
377903: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
387521: engineUpdate, opmode=0xc
423391: engineUpdate, opmode=0xc
423692: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
734155: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
795816: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
805434: engineUpdate, opmode=0xc
975011: engineUpdate, opmode=0xc
975312: TXMODE, freq=908300000, len=23, SF=8, BW=125, CR=4/5, IH=0
1289771: RXMODE_SINGLE, freq=926900000, SF=8, BW=500, CR=4/5, IH=0
1352527: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
1362082: engineUpdate, opmode=0xc
1371255: engineUpdate, opmode=0xc
1371557: TXMODE, freq=912600000, len=23, SF=8, BW=500, CR=4/5, IH=0
1682023: RXMODE_SINGLE, freq=926900000, SF=7, BW=500, CR=4/5, IH=0
1743682: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
1753235: engineUpdate, opmode=0xc
1771035: engineUpdate, opmode=0xc
1771337: TXMODE, freq=905100000, len=23, SF=9, BW=125, CR=4/5, IH=0
2091521: RXMODE_SINGLE, freq=926900000, SF=9, BW=500, CR=4/5, IH=0
2097243: EV_JOINED
Here is the node log of a VERY slow JOIN that never completes after just restarting the node with no changes other changes:
Starting
181: engineUpdate, opmode=0x8
Packet queued
2304: EV_JOINING
3473: engineUpdate, opmode=0xc
5761: TXMODE, freq=902300000, len=23, SF=7, BW=125, CR=4/5, IH=0
316271: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
377931: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
387548: engineUpdate, opmode=0xc
402093: engineUpdate, opmode=0xc
402394: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
712857: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
774517: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
784135: engineUpdate, opmode=0xc
815170: engineUpdate, opmode=0xc
815470: TXMODE, freq=910700000, len=23, SF=8, BW=125, CR=4/5, IH=0
1129994: RXMODE_SINGLE, freq=924500000, SF=8, BW=500, CR=4/5, IH=0
1192750: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
1202303: engineUpdate, opmode=0xc
1252804: engineUpdate, opmode=0xc
1253105: TXMODE, freq=906200000, len=23, SF=8, BW=500, CR=4/5, IH=0
1563635: RXMODE_SINGLE, freq=924500000, SF=7, BW=500, CR=4/5, IH=0
1625295: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
1634849: engineUpdate, opmode=0xc
1652304: engineUpdate, opmode=0xc
1652606: TXMODE, freq=911700000, len=23, SF=9, BW=125, CR=4/5, IH=0
1972790: RXMODE_SINGLE, freq=927500000, SF=9, BW=500, CR=4/5, IH=0
2035482: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
2045036: engineUpdate, opmode=0xc
2058187: engineUpdate, opmode=0xc
2058489: TXMODE, freq=914200000, len=23, SF=8, BW=500, CR=4/5, IH=0
2369019: RXMODE_SINGLE, freq=927500000, SF=7, BW=500, CR=4/5, IH=0
2430679: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
2440308: engineUpdate, opmode=0xc
2495607: engineUpdate, opmode=0xc
2495909: TXMODE, freq=908700000, len=23, SF=10, BW=125, CR=4/5, IH=0
2826455: RXMODE_SINGLE, freq=923300000, SF=10, BW=500, CR=4/5, IH=0
2889019: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
2898509: engineUpdate, opmode=0xc
2942977: engineUpdate, opmode=0xc
2943278: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
3253808: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
3315468: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
3325022: EV_JOIN_FAILED
3325050: engineUpdate, opmode=0xc
4014527: engineUpdate, opmode=0xc
4014830: TXMODE, freq=903700000, len=23, SF=10, BW=125, CR=4/5, IH=0
4345439: RXMODE_SINGLE, freq=927500000, SF=10, BW=500, CR=4/5, IH=0
4408003: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
4417557: engineUpdate, opmode=0xc
4463986: engineUpdate, opmode=0xc
4464287: TXMODE, freq=914200000, len=23, SF=8, BW=500, CR=4/5, IH=0
4774754: RXMODE_SINGLE, freq=927500000, SF=7, BW=500, CR=4/5, IH=0
4836413: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
4845903: EV_JOIN_FAILED
.... much later ....
28251665: TXMODE, freq=906300000, len=23, SF=10, BW=125, CR=4/5, IH=0
28582083: RXMODE_SINGLE, freq=925700000, SF=10, BW=500, CR=4/5, IH=0
28644648: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
28654138: engineUpdate, opmode=0xc
28677971: engineUpdate, opmode=0xc
28678274: TXMODE, freq=909400000, len=23, SF=8, BW=500, CR=4/5, IH=0
28988742: RXMODE_SINGLE, freq=925700000, SF=7, BW=500, CR=4/5, IH=0
29050403: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
29059892: EV_JOIN_FAILED
29059924: engineUpdate, opmode=0xc
29831904: engineUpdate, opmode=0xc
29832207: TXMODE, freq=911700000, len=23, SF=10, BW=125, CR=4/5, IH=0
30162625: RXMODE_SINGLE, freq=927500000, SF=10, BW=500, CR=4/5, IH=0
30225189: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
30234678: engineUpdate, opmode=0xc
30234910: engineUpdate, opmode=0xc
30235284: TXMODE, freq=914200000, len=23, SF=8, BW=500, CR=4/5, IH=0
30545735: RXMODE_SINGLE, freq=927500000, SF=7, BW=500, CR=4/5, IH=0
30607395: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
30616884: EV_JOIN_FAILED
This node kept repeating the same JOIN pattern and never finished joining after 20 minutes or so.
So to summarize the JOIN behavior, the relaxed timimg seemed to help the JOIN process happen faster, but not every time and never as quickly as The Things Uno that joins immediately.
What hardware are you using? What version of the Arduino-LMIC library are you using? Have you relaxed the timing?
================================================
On to a different topic of why after a JOIN I don’t see data from the node for 15-60minutes
I didn’t explain this very well and still have the problem after relaxing the timing. It is probably a different issue. Let me try to explain again.
When you JOIN a node with OTAA, the frame counter always resets to 0 automatically and you don’t need to do anything to start getting data, which is great. (When I was using ABP in earlier single channel nodes and gateways, I needed to reset the frame counter in the Device Overview to 0 or I would miss frames.)
What I was poorly explaining is that once a node like my Uno/Dragino mentioned above JOINs, with or without the relaxed timing, I do not see data arriving in either the Gateway Traffic or the Application Data for the device for anywhere from 15-60 minutes. When it does start to arrive, the frame counter has already risen to anywhere from 15-60 (my test node sends data once/minute).
My Application Console generally looks like this. In this example, the node JOINS at 23:50. Then there is no data received in the Application Console (or the Gateway Console for that matter) until 00:24 and the counter is already at 33.
I am positive that the device frame counter resets to 0 after a successful OTAA JOIN:
During the time after the JOIN and before I see data in the Application Console, I do see is activity at the node Serial Monitor that looks like successful transmissions after a successful join at 2097243 below.
Starting
217: engineUpdate, opmode=0x8
Packet queued
2340: EV_JOINING
3509: engineUpdate, opmode=0xc
5796: TXMODE, freq=902300000, len=23, SF=7, BW=125, CR=4/5, IH=0
316243: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
377903: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
387521: engineUpdate, opmode=0xc
423391: engineUpdate, opmode=0xc
423692: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
734155: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
795816: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
805434: engineUpdate, opmode=0xc
975011: engineUpdate, opmode=0xc
975312: TXMODE, freq=908300000, len=23, SF=8, BW=125, CR=4/5, IH=0
1289771: RXMODE_SINGLE, freq=926900000, SF=8, BW=500, CR=4/5, IH=0
1352527: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
1362082: engineUpdate, opmode=0xc
1371255: engineUpdate, opmode=0xc
1371557: TXMODE, freq=912600000, len=23, SF=8, BW=500, CR=4/5, IH=0
1682023: RXMODE_SINGLE, freq=926900000, SF=7, BW=500, CR=4/5, IH=0
1743682: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
1753235: engineUpdate, opmode=0xc
1771035: engineUpdate, opmode=0xc
1771337: TXMODE, freq=905100000, len=23, SF=9, BW=125, CR=4/5, IH=0
2091521: RXMODE_SINGLE, freq=926900000, SF=9, BW=500, CR=4/5, IH=0
2097243: EV_JOINED
2097270: engineUpdate, opmode=0x808
2097650: TXMODE, freq=907500000, len=16, SF=9, BW=125, CR=4/5, IH=0
2166492: RXMODE_SINGLE, freq=924500000, SF=9, BW=500, CR=4/5, IH=0
2229249: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
2233681: EV_TXCOMPLETE (includes waiting for RX windows)
2233726: engineUpdate, opmode=0x900
5983725: engineUpdate, opmode=0x908
....
64297075: TXMODE, freq=910700000, len=16, SF=9, BW=125, CR=4/5, IH=0
Packet queued
64367068: RXMODE_SINGLE, freq=924500000, SF=9, BW=500, CR=4/5, IH=0
64429824: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
64434193: EV_TXCOMPLETE (includes waiting for RX windows)
64434241: engineUpdate, opmode=0x900
68184240: engineUpdate, opmode=0x908
68184622: TXMODE, freq=910900000, len=16, SF=9, BW=125, CR=4/5, IH=0
Packet queued
68254615: RXMODE_SINGLE, freq=925100000, SF=9, BW=500, CR=4/5, IH=0
68317371: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
68321750: EV_TXCOMPLETE (includes waiting for RX windows)
68321799: engineUpdate, opmode=0x900
So to summarize: After a successful JOIN, data does not start flowing into the Application Data Console or Gateway Traffic Console for sometimes 15-60 minutes. The device frame counter has been reset to 0 automatically after the OTAA JOIN. When the data does start to flow into the consoles, anywhere from 0 to 15 to 60 counter messages have been lost.
================================================
Last Topic, the dreaded 32U4 Arduino upload process:
I have multiple boards, but as I evaluate them and explore attaching sensors and learning how to write the code, there are many opportunities for uploading new code. If it were simply a matter of pressing the reset button for each upload, I would not mind. Sometimes, a single press of the reset button is all you need and sometimes you don’t need to press it at all. (For the Things Node you need to open the case, remove the batteries and then remove the circuit board to reach the reset button.)
Many times you need to very carefully time when you need to double click the reset button to give the bootloader 8 seconds (Leonardo bootloader is compiled with a Rest Delay) to find the correct COM port.
Here is somewhat of a general explanation fo the problem:
https://www.avrfreaks.net/forum/com-port-change-during-flash-upload
The trick is to doubleclick the reset button as the second COM port (COM6 in this example) pops up in the command window. While annoying, this works consistently UNLESS for some reason you don’t get the “Forcing reset using 1200bps open/close on port COMx” line before the COM ports get listed. Then you are toast and need to start over again. I’m not sure why the forced reset fails sometimes. Here is what it looks like when it works:
Global variables use 498 bytes (19%) of dynamic memory, leaving 2,062 bytes for local variables. Maximum is 2,560 bytes.
Forcing reset using 1200bps open/close on port COM4 (Only if this appears can you double click reset below)
PORTS {COM4, } / {} => {}
PORTS {} / {} => {}
PORTS {} / {COM6, } => {COM6, } (Double click the reset button here!)
Found upload port: COM6
When it doesn’t work, I could end up retrying dozens and dozens of times for hours sometimes until it magically works. Unless someone can explain it, I will just avoid 32U4 based boards from now on. It is too painful and there are plenty of other options for boards that have 2 hardware serial ports, one for debug and one to communicate with the RN2903.
The basic sketch for The Things Uno has a delay to allow the serial port to become ready. This part of the serial port has not been a problem:
void setup()
{
loraSerial.begin(57600);
debugSerial.begin(9600);
// Wait a maximum of 10s for Serial Monitor
while (!debugSerial && millis() < 10000 ;