Is V3 the end for TinyLora?

TTN V2 to V3 Upgrade V3 Devices
18

The Things Stack officially only supports LoRaWAN-compliant end devices and the devices described here are not compliant.

We’re doing our best to add options that make The Things Stack work with non-compliant develoment devices, but if you’re building a serious solution, you should really use LoRaWAN-compliant end devices.

Downlink messages are an essential part of the LoRaWAN specifications, as they let the network to optimize the data rate of a device (ADR), tell the end device to use more or different channels, but also set a duty cycle for (accidentally or intentionally) misbehaving end devices.

Allowing devices that don’t support downlink will hurt the overall network quality in the long term, so I’m not sure we should even want to have these kind of end devices on our network. The best solution is really to make your device LoRaWAN-compliant.

Registering ABP devices in v3 is a bit more complicated than with v2. Of course you should be using OTAA unless you really have a good reason not to, but if you really need to use ABP, you need to make sure that the network parameters on the device and the network server are exactly the same.

This means that when you register the device, you must fill in all fields in the Advanced settings with the exact settings that you programmed in the end device. I’m not sure what happens if you modify these settings afterwards (@roman?).

Yes, this is an issue. We’re doing LoRaWAN here, not plain LoRa.

Yes. In v2, the Network Server at some point just gave up sending MAC requests/responses (which in some cases just bricked a device). Doing this in The Things Stack would make the Network Server non-compliant, and we don’t want that, because we eventually want to have a LoRa-Alliance-certified Network Server. What we could perhaps do, is add an advanced option to the Network Server that would disable the entire MAC layer for an end device, so that the Network Server doesn’t generate downlinks anymore.

These downlinks are likely generated because the MAC state of the end device (as far as the Network Server knows) doesn’t match the desired MAC state. If you register an ABP device with the default settings, the NS thinks that there are only 3 channels configured, and will try to configure the other 5. It will think the RX delay is 1 second, and will try to change that to 5. Depending on the frequency plan, it will also try to reconfigure the RX2 data rate from SF12 (the LoRaWAN default) to SF9 (the default on TTN).

LoRaWAN-compliant devices will send a response to acknowledge that they processed the MAC commands.

This actually makes sense. If you didn’t tell the Network Server that your device uses those channels, it will not consider your device when matching the uplink, and will try to configure those channels with a downlink MAC command.

4 Likes
19

By definition some devices/use cases do not need/should not use ADR hence a simpler device is/should be possible (strip out ADR handling from firmware allowing smaller footprint etc.?) I’m thinking e.g. Asset trackers and other mobile nodes or devices that may change location frequently?!

also

I understand lots of devices get ‘stuck’ on SF12 (e.g. after falling back on the SF’s to repeatidly try and connect to gateways that may be further away or where a previously close GW allowing lower SF goes offline/is removed (or now perhaps is migrated from V2 to V3 :scream: ) and many - if unable to pick up on the TTN RX2 SF = 9 end up unusable. If

Then should we not have option to allow RX2 @ SF12? if that is indeed the default?

…must confess hadn’t realised TT Stack wasnt LoRaWAN Compliant/Certified… I must have been sleeping! :wink:

20

The code that lets the server change the rate/power is small potatoes (or should be).

Some implementations can fit a full 1.0.4 feature set into ~15K on an ARM Cortex M0+. The new STM SoCs have up to 256K of flash.

With ABP the app must pre-configure RX2 along with the channels. Misconfiguration is too easy when using ABP and optimising away the downlink doesn’t help.

I expect you can if running a private instance.
:slight_smile:

21

This explains that error message which I keeps seeing but it would be super useful if, when setting up ABP, it automagically filled in the rest of the channels if requested as this will be a HUGE PitA for migrating lots of ABP devices. I’ll look at the import & API docs as solutions, but still none the less …

1 Like
22

That is excellent news for people using those devices, however if you read the forum you should be aware a lot of people use RFM95 and some kind of early Arduino or equivalent Atmel chip. These are readily available, cheap and can be programmed with Arduino IDE. More capable hardware poses challenges for those users. (Complicated development environment, hardware hard to obtain and program etc etc)

For TTI this issue doesn’t present itself as for professional users the business case to use different hardware and spend less hours fiddling is obvious. For TTN Community network for a lot of the participants hourly rates is not a concern, having an easy to use programming environment with cheap and readily available hardware is.

The current change in behavior of the stack is a surprise for many of the TTN Community users.

Adding an option for the network server to stop sending these commands after a certain number of attempts (may be make that the configuration option with the default being to retry indefinitely) would certainly help.
Also assuming an ABP device does not know about the additional channels when all available example code explicitly adds these on ABP devices feels wrong. The assumption for ABP has always been that it is the firmwares responsibility to add the 5 additional channels and set RX2 parameters. Now the stack is based on different assumptions, this will break hardware out in the field.

3 Likes
23

Yes, that’s why you can disable ADR.

  • There is no compliance certification for LoRaWAN network servers (yet), so none of the Network Servers out there are actually certified.
  • Because of various workarounds for non-compliant devices, and because it defaults to SF9 (instead of SF12) for RX2 in EU868, our v2 stack indeed isn’t LoRaWAN compliant.
  • In our v3 The Things Stack we’re strictly following the specification for the defaults. We don’t build workarounds for non-compliant devices, or put them behind some advanced option, so that the defaults are fully compliant.

From experience we know that doing something “after a certain number of attempts” is too confusing, because then something can “suddenly stop working”. So we either keep trying, or we don’t try at all.

The assumption in The Things Stack is that those who use ABP devices, will tell the Network Server what settings those ABP devices use. These settings must be filled in the “Advanced settings” section of the “Network layer settings” when registering a device.

Screen Shot 2021-02-01 at 13.10.40
Screen Shot 2021-02-01 at 13.10.401336×1140 43.8 KB

Edit: With v3.11 (for which the release candidate is already running on eu1.cloud.thethings.network) it is going to be possible to work with “device profiles” in the device repository. With that, we could set non-standard ABP configuration in the device profile, and the Network Server should use that when registering ABP devices. I’ve created an issue on GitHub to fix and test this for The Things Uno / The Things Node. Hopefully that will make it easier to at least register these devices. I don’t think we’d allow non-compliant devices in there, but this should at least make things easier to align MAC parameters for ABP devices.

1 Like
24

TTL has proven to be very useful in the IP protocol (not the same but nonetheless).

Too confusing for who?
What would be wrong with setting default value to ‘to retry indefinitely’ but also allow to change it?

25

Or some more reasonable number, lest a whole pile of devices in an area are happily uplinking but not responding to the MAC commands which results in the airwaves flooded with MAC downlinks …

1 Like
26

Agree. In the interest of spectrum preservation, NoTHiNG should be set to keep trying forever…that is just antisocial imo!

27

That was my thinking. I like this solution.

[i added numbers]
I agree, but for mobile devices only the 3) statement is valid. Even for that case, (for misbehaving devices), you can do anything. I can send a command that I accepted the MAC command, but in reality I do nothing.

Let me repeat that for the best energy consumption, I would not like to listen for downlinks.

In the end of the day. For the good of the network, ideally I agree that is essential to listen for downlinks according to my idea of white zones. But this is not an easy task for me. And I don’t even know If a can fit LMIC in 32k flash. In fact I made some test without beacon and I think it was almost 100%. The debugging would be difficult for me.

Thank you for your great answers.

28

While that’s not untrue, relying on downlink actually working is simply not practical, particularly in the case where downlink not working generates a traffic flood that’s only likely to make it stop working for nodes which actually do implement it correctly in less busy situations.

Consider for example the gateway in the ST LoRa kit: the gateway end has a full LoRaWan concentrator, but lacks a PA in the transmit path, so it’s maximum transmitted power is many dB below that of a typical node. Unless those are somehow going to be identified and banned from selection as a downlink path (or from the network entirely) they readily create situations where the network can hear a node, but not respond loudly enough for the downlink to be heard by a node. (That would seemingly be especially of issue with the TTN-EU non-standard SF9 RX2 relying on boosted power to make up for the reduced coding gain)

A node with a noisy power supply, or simply near other noisy equipment (especially radio equipment) could have similar issues of transmitting fine, but not hearing replies.

Practical system design needs to consider not only ideals, but graceful degradation in circumstances that are readily anticipated from the fact that they are not just theoretical possibilities, but things that can be seen to actually occur today - including in the situation of this thread.

but also set a duty cycle for (accidentally or intentionally) misbehaving end devices

That’s a useful idea, but to really work it needs to be fail-safe rather than fail-deadly.

Specifically, devices should have a duty cycle limit in the absence of downlink, and only be able to go to a higher rate when commanded to via a working downlink path, with such higher rate expiring after some period of time.

At the end of the day, having a network that works well is more important than unthinking adherence to a spec, especially when that that would create clear problems, and doubly so when those problems can be solved in ways that are not actually in conflict with the spec, but merely go beyond its baseline requirements.

3 Likes
29

I was able to get a TinyLora node to receive on all channels by adding the several frequencies in the network layer advanced section. This only worked with a newly created device (modifying an existing one didn’t work for me).

Below you can see the response in the application live view. There are no new channel requests any-more & data is received on all 8 channels. There is still a schedule for a data downlink transmission. Not sure if this can be switched off (as the device cannot receive anything).

image

1 Like
30

Newly created application or device?

31

I meant device (not application)

32

edited your post to fix that

33

@htdvisser For the sake of verification I created network layer advanced settings.
Can you please confirm or comment these? They are meant for a ABP device that works on V2 and that shall be migrated to V3.

RX1 Delay: 1
RX1 Data Rate Offset: 0
Reset frame counters: true
RX2 Data rate Index: 3 (SF9)
RX2 Frequency: 869525000
Factory preset frequencies:
  0: 868100000
  1: 868300000
  2: 868500000
  3: 867100000
  4: 867300000
  5: 867500000
  6: 867700000
  7: 867900000
  8: 868800000
1 Like
34

I think the settings mentioned are not fully correct.

  • RX1 Delay should be 5 (not 1)
  • There are only 8 channels (not 9).

I have now the following settings implemented (node with TinyLora). As mentioned this only works with a new device. Changing settings after device creation didn’t have any effect.

image

This gives the following response.

image

There are no set-up requests anymore and the device is reportig on all 8 channels. So I am happy with the result. :slightly_smiling_face:

1 Like
35

I’ve entered an Rx1 delay in to the V3 setup of an ABP device as it’s easier to do that than recompile the firmware. I appreciate that TinyLoRa doesn’t do downlinks, but many other stacks do and the V2 default is 1 second.

1 Like
36
  • RX1 Delay should be 5 (not 1)

For a new device, yes. For an existing device, the dilemma would be between trying to keep it working the way it was with a 1 second delay, vs, understanding that the longer delay was chosen because of concern that it may not be possible to get downlink packets back through more complex routing to the gateway in time to actually achieve a 1-second window.

  • There are only 8 channels (not 9).

Actually there are nine. The last one in the list you refer to, 868.8, is the FSK channel, rarely used, but it does in fact appear in the TTN bandplan. If it should be entered alongside the LoRa channels, or elsewhere or not at all is an interesting question, but it does officially exist.

37

I believe that with a 1 second RX1 delay the application will sent a downlink request to change to 5 seconds. At least that happened when I didn’t specify the RX1 value at all.

As this is for TinyLora which cannot receive/respond to the request I did change to 5 and the request was not generated (resulting in less unneeded trafic). Not sure if this will also be the case when I specifically set it to 1 (will try-out in future)

For ABP devices that can receive downlinks 1 second for RX1 is probably the way to go.