Hi Somsak, That’s because the LMIC throttling of bandwidth. It’s supposed that you can only send about 1% of available bandwidth, so it throttles your messages calculating the time to air and available bandwidth on channel you choosed. But you can also do frequency hopping.
Just a question. BSFrance and Adafruit modules, does use 3.3v natively on gpio or do they use 5v logic. Specs says 3.3v module. But I don’t know if it has a stepup converter to be compatible with arduino gpios.
I ask because I read from ublox 3.3v gps and I’m adding a stepdown converter from 5v to 3.3v between the module and gps. And if it’s fully 3.3v I can remove that module on channels. What do you think?
Everyone says a simple voltage divider will do the trick. But I wonder if I can get rid of it with BSFrance v1.2 module.
References:
http://www.ayomaonline.com/iot/gy-gps6mv2-neo6mv2-neo-6m-gps-module-with-arduino-usb-ttl/
https://forum.arduino.cc/index.php?topic=199304.0
https://docs.bsfrance.fr/documentation/11355_LORA32U4II/Datasheet_LoRa32u4II_1.1.pdf
- MCU : Atmega® 32u4 3.3V @ 8MHz
- Logic level : 3.3V
- Operating voltage : 3.3V – 5.0V
- Ultra low dropout 600mA 3.3V regulator
I don’t know whether GPIO pins are 5V tolerant.
Hi Couin, so I can connect it directlly to the 3.3v ublox gps. Great. Thank you for the response. And the doubt now is if it can tolerate 5v as other arduino clones do.
Anyone can clear out this doubt? Please.
Everything should be be fine if you use 3.3V Logic everywhere.
Beware of maximum draw/sink current.
Seems to be working great. Low consumption and it can lasts days on batteries. Will improve it latter anyway.
Great news!
I can’t wait to read about your future improvments 
Seems it got about 7,5Km in city. In fact from one city to the nearby one. A lot of packet didn’t arrive but few of them do.
I want to test directional antennas.
https://ttnmapper.org/special.php?node=lora-test-node&date=2018-09-10&gateways=on
Hi there !
Following your advices in lasts posts : I’m now connected ^^ so it works… but it don’t.
It take each time 19 minutes 27 seconds of computation to send the value (a simple “Hi” for now). So I retrieve my values every 19 minutes 27 seconds + duty cycle.
I did’nt change anythings since last time : Jac’s code, Couin’s Pins, and obviously correct little-endian AppEUI & DevEUI.
=> Any idea of what could be wrong ?
Thanks 
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 foreverThis 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
1 Like
Do you have some EU source of LiIon/LiPo batteries for these boards? Thanks.