Modified LMIC, sleep and other parameter

[grazy]

Hi,

I have modified LMIC to be able to understand it and to get LowPower, my version is here, I only keep class A code :
https://github.com/ngraziano/lmic-arduino
I use Arduino Mini Pro and RFM95
I manage to get it sleep between TX windows

I have some question:

• did someone succeed to get arduino sleep between TX and RX1 and RX2 and keeping enough time precision to get RX work (or OTAA join) ?
• I see that RX1DRoffset is not implemented. it seems not to used by TTN
• Same for TxPower in LinkADRReq, it is read but not used. Is it important ?
• LINK_CHECK_INIT seems to be too low ( 12 instead of 64 (ADR_ACK_LIMIT)).

Where can I find the lorawan feature used by TTN to make a minimal compatible version of LMIC ?

Thanks

[bluejedi]

@grazy

did someone succeed to get arduino sleep between TX and RX1 and RX2 and keeping enough time precision to get RX work (or OTAA join) ?

If I’m not mistaking the core of LMIC is not event/interrupt driven. LMIC handles the timing between TX and RX1 and RX2 windows itself. Therefore the microcontroller should not be put asleep between TX and RX1/RX2.

For certain non-AVR microcontrollers like ESP32 that would be even more complex because ESP32 does not actually wake up from sleep but does boot instead.

[arjanvanb (Arjan)]

Also, if sleeping between two transmissions is giving you problems, then read the whole topic quoted below:

@matthijs

the fact that micros() does not update might even be the cause of your problem in the first place: you queue a new packet after the duty cycle delay is over, but because you’ve been sleeping, LMIC doesn’t know that time has passed. Ideally, the micros() counter would be adapted to compensate for the sleep time which requires some changing some global variable internal to the Arduino code, but that might not be so portable. I wonder if Arduino should get a API to do this instead…

[grazy]

Bluejedi you are right LMIC is not interrupt driven, the 2 second between TX and RX2 is not worth the effort to try to gain this little mAh, I already manage to get 3 month with two AA NiMh. (If ESP32 is like ESP8266 it will be hard to save the current state in RTC ram or EEPROM when sleeping)

Ajarn, thanks for the share, I will read it in detail, I try to implement similar time compensation in hal_ticks when AVR is in sleep, it is not very precise but I manage to sleep the 5 minutes I want between TX.

[arjanvanb (Arjan)]

@grazy

(If ESP32 is like ESP8266 it will be hard to save the current state in RTC ram or EEPROM when sleeping)

Well…

@CurlyWurly

You can now use SPIFFS for ESP32 (Remembers things even after a powerdown)
arduino-esp32/libraries/SPIFFS at master · espressif/arduino-esp32 · GitHub

This is great explanation of how it is used for the ESP8266
https://www.youtube.com/watch?v=jIOTzaeh7fs

[GryKyo]

I am no expert but in my own experience up to 20km is feasible on sf7 but does rely on a matched antenna for whatever frequency scheme you use and more importantly, good antenna placement with line of sight from node to gateway.
I would tend towards proving the hardware combination you use but at shorter ranges to then experiment with environment (placement of node/gateway) as you will have base data to evaluate your physical installation. You may indeed find your hardware is not ideal, I for example have some unmatched antennas that consume much of the link budget before range enters the equation at all.

HTH?

G

[UdLoRa]

Can you tell which antennas do you use? Beginner me too, I agree with GryKyo that the antennas and their placement are crucial, software is a secondary aspect. Gateway antenna in particular, of course.
With the same node (either based on LMIC + 8.6 cm wire or MKR WAN 1300 + GSM dipole) I was able to reach an unknown gateway 27km far (SF12 and SF9), but with my own single channel gateway, outdoors, with 20cm rubber duck antenna, no more than 1 km, trying to improve it with elevation. If you aim at long distance, start with SF12 and maybe ABP because with OTAA both sides should be able to send and receive at the same level.
Regarding power, if you are in EU, no more than 14db.

[coeus]

Andreas Spiess did a very good YouTube video explaining antenna optimisation using a vector inpendence analyser (VIA)
With my limited experience, a lot of the LoRaWAN devices, both gateway and nodes, are shipped with poorly designed antenna. And because LoRaWAN works in a relatively narrow band, an antenna designed NOT to be used with your desired frequency will affect the range significantly.
I think if you want to get serious about LoRaWAN, an VIA is a tool worth investing in.

[GryKyo]

I agree with everything you suggest here but again just my findings trying various things out over the last couple of years. @coeus points out something very important; if you are buying dev boards from China you are not necessarily buying from anybody who understands or really cares about your antenna tuning. Andreas Speiss’s video linked above shows this clearly.
This was what I discovered empirically, many of my nodes worked very well until I started to move away from my gateway. I found that nothing worked like my home made ground plane antenna to the drawings which you will find in the labs examples of the TTN homepage. None of the attractive looking Chinese units worked as well as this simple 82mm long piece of copper wire.
Right now I tend to use the antennas I got with my Pycom LoPy4 dev boards as I trust that these will be matched to some degree. They are not cheap and I could contact Pycom to complain if not so I feel safer assuming they are OK in this case.
Line of sight and distance over the ground seem to be big influences to basic setup in my experience. The ABP above OTAA makes a lot of sense with regard to random packet preamble being detected and the message received by a gateway in long range applications. I was trying to do some long range transmits (circa 100km range from some altitude) yesterday, I think my node uses OTAA. I must review my code and try again!
Thanks, G