Big LoRa32u4 boards topic

meric · November 1, 2018, 3:22pm

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

Couin · November 2, 2018, 5:01pm

This preprocessor line is already in one lmic library file (Lmic.h ???), You simply have to uncomment it, then rebuild all code afterward.

meric · November 5, 2018, 1:05pm

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

Couin · November 5, 2018, 3:28pm

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!

meric · November 6, 2018, 9:23am

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

bluejedi · November 6, 2018, 9:41am

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);

meric · November 14, 2018, 3:15pm

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.

bluejedi · November 14, 2018, 4:49pm

“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.

Couin · November 14, 2018, 7:58pm

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

UdLoRa · November 21, 2018, 1:56pm

Do you have some EU source of LiIon/LiPo batteries for these boards? Thanks.

Couin · November 21, 2018, 2:13pm

BSFrance? You can simply buy PH connectors and adapt any Li-Ion.
Remember to test polarity before plugging.

UdLoRa · November 21, 2018, 9:44pm

Lazy but if needed I can do it.

brunomataloto · December 10, 2018, 1:11pm

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;

Couin · December 10, 2018, 11:36pm

Stops completely or simply delays?

brunomataloto · December 11, 2018, 12:08am

Stops completely

brunomataloto · December 11, 2018, 11:29pm

I just noticed that it stops sending after my application server reboots, if the board is connected to USB power, it keeps sending

Micktomar · December 26, 2018, 1:29pm

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.

Micktomar · December 26, 2018, 7:37pm

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.

Couin · December 26, 2018, 10:12pm

Your application server gives board power ?

Couin · December 26, 2018, 10:15pm

Good to hear!

As a hobbyist, I find usefull to have at least two boards (to make some basic send/receive tests and so on …).