Anyone had any experiences with the Adafruit TinyLoRa LoRaWAN library ?
I know its ABP only.
I just converted a working GPS tracker program from the matthijskooijman LMIC library across to TinyLoRa. Its working and I get the GPS co-ordinates in the Application console OK.
TinyLoRa seems to do rather well memory wise on an ATmega328, the program uses TingGPSplus and NeoSWSerial for the GPS;
TinyLoRa;
Sketch uses 13480 bytes (41%) of program storage space. Maximum is 32256 bytes.
Global variables use 722 bytes (35%) of dynamic memory, leaving 1326 bytes for local variables. Maximum is 2048 bytes.
Compared to;
LMIC;
Sketch uses 26512 bytes (86%) of program storage space. Maximum is 30720 bytes.
Global variables use 1181 bytes (57%) of dynamic memory, leaving 867 bytes for local variables. Maximum is 2048 bytes.
I did also check the original program against arduino-lmic-mccicantena, not very good;
MCCI;
Sketch uses 31532 bytes (97%) of program storage space. Maximum is 32256 bytes.
Global variables use 2057 bytes (100%) of dynamic memory, leaving -9 bytes for local variables. Maximum is 2048 bytes.
The most obvious would be that it appears to be transmit-only, while LoRaWAN is really designed to be “transmit mostly”.
Given you can only use confirmed traffic on TTN very sparingly as downlinks are so expensive for the network, that perhaps is not a major loss.
But you won’t be able to use adaptive data rate. If you use a faster (lower number) SF than you need, your data won’t get through very often. While if you use a slower (larger number) SF than you could, you’ll spend extra time transmitting, which will cost you more battery and cost the network more capacity. If the node is in a fixed position you may be able to just tune the SF manually to something that works with reasonable margin. The same goes for the actual RF power level
And of course you don’t get any OTAA or any support of MAC command features like the server configuring the node to the proper channels, etc.
Yes, I guess the temptation is to set it to SF12 just in case, and for a GPS tracker in particular therin lies a major problem.
At SF7 a location packet has an air time of circa 67mS, so under the fair use policy you could send 486 packets a day or a packet every 3 minutes or so.
But at SF12 the air time is up to around 1500ms, so 20 packets a day or a packet every 72 minutes.
The problem with fixing on SF7 is that unless in a dense GW population many of the addition Tx’s you are allowed would never be heard given inherently shorter range and a tracker that cant be tracked is a bit useless! Compromise at SF9 or 10? Issue then is if lots in area doing same for similar functions and using similar SF’s there is a GW capacity gap created and GW’s become less efficient over all…just a thought.
Personally, I think you want ADR. I’m relatively unconvinced on the merits of OTAA, especially in a situation where you as the end user are building the firmware. It might make more sense for a pre-manufactured, pre-programmed product that doesn’t know at manufacturing time who will be using it or on which network. Even then, there are what seem to me to be serious flaws in the protocol which often cause it to do things counterproductive what actual usage needs.
Worth noting: ADR without OTAA is broken in upstream LMiC (when ADR fails it erroneously gets stuck trying to join, even though that won’t work without OTAA) but should be fixed in MCCI LMiC.
One application to which TinyLoRa is suited is TTN Mapper. The recommendation for that is to use a single spreading factor, SF7, which is a close match to TinyLoRa’s capabilities.
A TTN mapper with GPS and OLED to show the mapped location uses 62% of Flash and 49% of RAM on a humble Arduino Pro Mini.
/** Region configuration*/
//#define US902 ///< Used in USA, Canada and South America #define EU863 ///< Used in Europe
//#define AU915 ///< Used in Australia
//#define AS920 ///< Used in Asia
Yes, I think the EU863 is a typo, but TinyLoRa.cpp expects it.
The SX1272 changes appear to work, I can send packets from SF7 to SF12 and they are picked up by my Gateway.
Quite why the SX1272 needs a different configuration to the SX1276 I am not sure, the bits for setting LNA gain, RX CRC and low data rate optimisation are in different places. The sense of the device RESET pin is inverted too. However since the TinyLoRa library is RX only, even if some of these bits were wrong it should not make a difference.
I will need to document it first, setting by setting, then might suggest it to Adafruit as a TinyLoRa2 library, specifically for the SX1272.
Compromise at SF9 or 10? Issue then is if lots in area doing same for similar functions and using similar SF’s there is a GW capacity gap created and GW’s become less efficient over all…just a thought.