A verbose log would be helpfull
#define LMIC_DEBUG_LEVEL 1
Are you using SF12?
checked in lorabase_eu868.h :
enum _dr_eu868_t {
EU868_DR_SF12 = 0,
EU868_DR_SF11,
EU868_DR_SF10,
EU868_DR_SF9,
EU868_DR_SF8,
EU868_DR_SF7,
EU868_DR_SF7B,
EU868_DR_FSK,
EU868_DR_NONE
};
So I assume I donât use it. Should I have to ?
About verbose, I put the line in my code, but It donât speak much more than before. Always :
Starting // about 10 seconds
EV_JOINING // Led 22 start to blink
Unknow_event // 1 second after. Led 22 still blinking forever
This preprocessor line is already in one lmic library file (Lmic.h ???), You simply have to uncomment it, then rebuild all code afterward.
This preprocessor line is already in one lmic library file (Lmic.h ???), You simply have to uncomment it, then rebuild all code afterward.
Silly me.
Here it is :
Starting
RXMODE_RSSI
EV_JOINING
1250496: engineUpdate, opmode=0x4
1725783: engineUpdate, opmode=0x4
Unknown event
1726375: engineUpdate, opmode=0x884
1726593: TXMODE, freq=868500000, len=23, SF=7, BW=12 > 5, CR=4/5, IH=0
start single rx: now-rxtime: 8
2039778: RXMODE_SINGLE, freq=868500000, SF=7, BW=125, CR=4/5, IH=0
rxtimeout: entry: 2045983 rxtime: 2039690 entry-rxtime: 6293 now-entry: 8 rxtime-txend: 309492
start single rx: now-rxtime: 8
2105157: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
rxtimeout: entry: 2121218 rxtime: 2105198 entry-rxtime: 16020 now-entry: 7 rxtime-txend: 375000
2121545: engineUpdate, opmode=0x4
I played with LoRa node in June/July, I have forgot a lot ^^.
Letâs sum things up (anyone please correct me if Iâm wrong):
- You said you use Jacâs code => OTA Auth
- Your node is trying to connect to the Gateway (âEV_JOININGâ)
- Your node wait for an answer that never arrives (no âEV_JOINEDâ)
- Then, after some time(out), your node send one message (âTXMODE (âŠ)â)
- You wait for the two optional callback messages (none received either ârxtimeoutâ)
- And all cycle again.
Do you know about the gateway(s) you are passing through?
I suppose your node is working fine, but your gateway is either too far or not able to send downlink. messages. The very long time between each message is a consequence of this degraded behavior.
Next step
- Have a look a the TTN application (or gateway) console log?
- Try a sketch using ABP instead of OTAA
Good luck!
Thank you for this analysis. What makes me crazy is the regularity of the malfunction : 19min27s. Therefore, I refuse to believe in a radio (distance, etc) issue. Or not the only one. Here a piece of functioning log :
Starting
RXMODE_RSSI
EV_JOINING
1250469: engineUpdate, opmode=0x4
1522049: engineUpdate, opmode=0x4
[...]
29696382: engineUpdate, opmode=0x884
29696604: TXMODE, freq=868100000, len=23, SF=8, BW=125, CR=4/5, IH=0
start single rx: now-rxtime: 8
30013133: RXMODE_SINGLE, freq=868100000, SF=8, BW=125, CR=4/5, IH=0
rxtimeout: entry: 30019600 rxtime: 30013046 entry-rxtime: 6554 now-entry: 7 rxtime-txend: 309620
start single rx: now-rxtime: 8
30078385: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
EV_JOINED
30193386: engineUpdate, opmode=0x800
30193500: engineUpdate, opmode=0x808
Unknown event
30194273: engineUpdate, opmode=0x888
30194488: TXMODE, freq=866500000, len=15, SF=8, BW=125, CR=4/5, IH=0
Sending:
start single rx: now-rxtime: 8
30509607: RXMODE_SINGLE, freq=866500000, SF=8, BW=125, CR=4/5, IH=0
rxtimeout: entry: 30516071 rxtime: 30509648 entry-rxtime: 6423 now-entry: 7 rxtime-txend: 309620
start single rx: now-rxtime: 8
30574988: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
30658639: process options (olen=0)
30658893: process mac commands for port 0 (olen=0x5)
30659045: LinkAdrReq: p1:01 chmap:0078 chpage:00 uprt:01 ans:87
30659226: Received downlink, window=RX2, port=0, ack=0, txrxFlags=0x22
EV_TXCOMPLETE (includes waiting for RX windows)
30662632: engineUpdate,
...
I see that it donât works⊠Then, it works⊠But I donât understand the detailled log : Could you share me your analysis ?
Many thanks for your kind help
LMIC_setClockError()
Have you relaxed LMIC timing?
See: Strange problem: RFM95 + LMIC-Arduino, long JOIN delays and missing frames
Have you tried using ABP instead of OTAA and does ABP work properly without delays?
If so then that probably indicates a timing issue.
AVR MCUâs like ATmega328 and ATmega32U4 (which is on the LoRa32U4 board) - especially the 8 MHz versions - in combination with LMIC usually require relaxation of LMIC timing to prevent delays / issues with OTAA joining.
LMIC timing can be relaxed with LMIC_setClockError()
as shown below where it is
added to the ttn-otaa.ino
example:
// LMIC init
os_init();
// Reset the MAC state. Session and pending data transfers will be discarded.
LMIC_reset();
// ### Relax LMIC timing ###
// Required for ATmega328/ATmega32U4 (8MHz) otherwise OTAA joins on SF7 and SF8 will likely fail.
#define LMIC_CLOCK_ERROR_PERCENTAGE 3
LMIC_setClockError(LMIC_CLOCK_ERROR_PERCENTAGE * (MAX_CLOCK_ERROR / 100.0));
// Start job (sending automatically starts OTAA too)
do_send(&sendjob);
Hi bluejedi. Thanks for answer.
Yep, I relaxed the timing.
I do further invests, and I know now exactly when it block : it block systematically 19 minutes27seconds just at end of the âdo_sendâ loop, just after the âSerial.println(F(âSending:â)â
-> The big question is : Do you know if the device is emitting at this stade ?
- if itâs start is emission, itâs probably blocked in a "waiting for something" from the gateway.
- if the emission is not started yet, the issue is inside the device : Or a long calculation time, or something wrong in my lib implementation.
âYour lib implementationâ? What library, LMIC or a library unrelated to LoRa?
Are you using the âstandardâ LMIC library GitHub - matthijskooijman/arduino-lmic: â This library is deprecated, see the README for alternatives.?
My advice is to use above standard library (unmodified), use the standard examples ttn-abp.ino and ttn-otaa.ino (add timing relaxation to both) and test with ABP first. Keep each message short (e.g. short fixed string) and then test again with this minimal setup to rule out other factors.
Same advice
- Be sure to use âlatestâ arduino-lmic;
- Test ABP exemple first;
- Then test OTA and so onâŠ
Are you sure Digital Pin 6 (âD6â) is well connected to DIO1 and not used for everything else in your code?
By the way, Iâm going to solder a wire just like you did
Do you have some EU source of LiIon/LiPo batteries for these boards? Thanks.
BSFrance? You can simply buy PH connectors and adapt any Li-Ion.
Remember to test polarity before plugging.
Lazy but if needed I can do it.
Hello ! Im using BSFrance Lora32u4 II v 1.2 and Im trying to get it to save power but Im not sure if my code is correct.
I noticed that after a while it just stops sending packets.
Can you help me ?
case EV_TXCOMPLETE:
Serial.println(F(âEV_TXCOMPLETE (includes waiting for RX windows)â));
if (LMIC.txrxFlags & TXRX_ACK)
Serial.println(F(âReceived ackâ));
if (LMIC.dataLen) {
Serial.println(F(âReceived â));
Serial.println(LMIC.dataLen);
Serial.println(F(â bytes of payloadâ));
}
for (int i = 0; i < int(300 / 8); i++) {
LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);
}
do_send(&sendjob);
// Schedule next transmission
//os_setTimedCallback(&sendjob, os_getTime() + sec2osticks(TX_INTERVAL), do_send);
break;
Stops completely or simply delays?
Stops completely
I just noticed that it stops sending after my application server reboots, if the board is connected to USB power, it keeps sending
Meric,
can you tel me what finally solved the issue?
Iâm struggling for days now with the problem you described.
I have the 1.2 board and made the solder as in the picture.
I run the ttn-otta example(added LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);).
Replaced the EUIâs(lsb) and APPKEY(msb) with my own values.
In my application on TTN I see that the Activation message is received, but than nothing further happens.
const lmic_pinmap lmic_pins = {
.nss = 8,
.rxtx = LMIC_UNUSED_PIN,
.rst = 4,
.dio = {7, 6, LMIC_UNUSED_PIN}
};
Some debug lines of lmic:
7698939: Running job 0x28a, cb 0x4b4, deadline 7386173
7699096: engineUpdate, opmode=0xc
7699190: Uplink join pending
7699271: Airtime available at 8982456 (previously determined)
7699438: Uplink delayed until 8982456
Thank you very much for your response.
It seems that I have a bad board or damaged it while solder directly on the chip.
With another board I used the solder points on the back see link below.
Also be aware of the lmic_pins when using this.
.dio = {/dio0/ 7, /dio1/ 1, /dio2/ LMIC_UNUSED_PIN}
I know there can be issues with serial monitor because pin-1 is also serial TX, but I have not seen problems and I only use this during debugging.
Your application server gives board power ?