Adafruit TinyLoRa

End Devices (Nodes)
1

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.

Any known issues with TinyLoRa ?

1 Like
2

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.

3

Thanks for the comments.

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.

4

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! :wink: 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.

5

Edit: (Not TinyLoRa but relevant to your list)

If you want OTAA you can try this implementation.

Stripped back with one radio driver and no debug messages it will fit into 23678B flash and 720B ram.

A sketch with one radio, debug messages, sleep, and a DHT sensor occupies 27742B flash and 734B ram.

No known issues because no-one uses it :wink:

6

all known to mankind :alien:

7

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.

8

I had a quick review. It’s bare bones, are lot of lines are just for the AES implementation.

  • be aware channel randomisation is determined by the MIC and that channels are allowed to repeat
  • no timing is performed by the library (duty cycle limit or RX window lockout)
  • library will block forever on TX complete line if radio misbehaves (make sure you run a watchdog)

The hardware requirements are actually more complicated than they need to be. They could poll SPI for TX complete and get rid of the IO line.

9

Does not support SX1272, not an issue as such, as the library was written for RFM95/96.

10

Hi all,

Maybe RIOT-OS support of LoRaWAN could be interesting for you?

It has out of the box support for LoRaWAN (see this example at https://github.com/RIOT-OS/RIOT/tree/master/examples/lorawan)

There’s support for some Adafruit boards so I maybe it works for you.

1 Like
11

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.

2 Likes
12

Why ?

Most LoRaWAN node applications are fairly simple and often spend 99% or more of their time asleeep.

So what for instance would be the advantage (for LoRaWAN applications) of ‘a preemptive, tickless scheduler with priorities’ ?

13

Can TinyLoRa be used for 868Mhz, I could not find how to set it.

14

Its in TinyLoRa.h;

/** 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.

15

Thank you, it’s running now. Good for a small temperature sensor without a requirement to receive data.

16

I have been working on ‘TinyLoRa2’ a version of the TinyLoRa library that supports the SX1272.

It just happens that I have a few SX1272 based modules here (from Dorji) so it makes sense to use them.

17

Oooh. I look forward to this. Especially if it can all be driven from an Arduino mini pro. I shall keep looking for updates on your excellent GitHub.

18

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.

May take a couple of weeks.

3 Likes
19

Hello, a question about the pin mapping of the RFM95W in TinyLoRa on a ATmega328 LoRa Radio Module.
With the LMIC lib:

const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = 9,
.dio = {/dio0/ 2, /dio1/ 5, /dio2/ 6},
};

it works perfect

With the TinyLoRa lib:

TinyLoRa lora = TinyLoRa(2, 5, 6);

12:57:25.364 → Starting LoRa…Failed
12:57:25.364 → Check your radio

Can I find somewhere the correct pin mapping definition for TinyLoRa?

20

If you follow the ’ API Documentation’ link in the Readme.md file thats part of the downloaded library, you get to this page;

https://adafruit.github.io/TinyLoRa/html/class_tiny_lo_ra.html

Which says that to start TinyLoRa you use this;

TinyLoRa lora = TinyLoRa(int8_t rfm_dio0, int8_t rfm_nss, int8_t rfm_rst)

So specify the pins in this order, DIO0, NSS, RST…