I´ve got some nodes with TinyLora deployed. Trying to migrate one of those to V3 results in some Problems.
Nodes with TinyLora dont accept downlinks and they cant process MAC requests. But it seems in V3 downlinks with MAC requests are essential? Or have they alwas been there in this amount and I couldn´t see them in V2?
Because the MAC commands wont trigger any reaction by the node, the application will retry to send them after every uplink from the device - am I right with this? (At least it seems so in my test)
This would violate the fair use policy really quick!
Can MAC commands / Downlinks be disabled for these cases in the application?
Side issue:
In my testcase the node uses multichannel (1-7, confirmed), all messages were received by the Gateway.
But only messages with channel 1-3 are showing up in the V3 application!
After the application received a message it request a new channel from the node (which will be unheard). The requested channels are alwasy 4-8, so exactly the channels of which no message shows up in the application, but also were received by the Gateway.
In the advanced settings you are able to add programmed channels. You could try adding the 5 additional channels in those settings.
MAC 1.0.1 is probably the best option.
The 8 uplink channels will be received without any issue, I was hoping (without looking at any code) that you telling the backend those channels are programmed would make it stop trying to push them with MAC commands.
This is the obvious “solution”, but in that case I have to modify the library.
a. I really don’t know If I can make it
b. It’s weird that was working with V2 and not with V3.
c. I have other pririorities
d. What’s the reason for those downlinks? I don’t even know the purpose. And they will be another ones for some reason? (I suppose I need to read the LoRaWAN specs)
e. As I wrote, TinyLoRa is perfect for devices that can use even less airtime.
I will notify Adafruit, but they seem idle with this library.
How does that work - you’d like someone else to alter the library so you can use it but you don’t want it done that much you want to do it yourself.
MAC commands - the network server setting settings it would like the device to use. Some will have been happening already which TinyLoRa may or may not have been compiling with.
Same problem for me. All messages are received by the gateway but only some are received in the application.
Currently I have >20 nodes on APB with TinyLora. This is a small library perfect for my usecase. Changing to another library is not the solution for me. This is besides the fact that it will probably not fit on all my devices. Most nodes have only 32kb available and with the other applications running on it there is very limited memory to spare.
If no solution is found it will force me to go private (Chirpstack). I know it works and for my purpose the “local” range is sufficient. Unfortunately this will also mean that my gateways will not be supporting the community anymore.
What makes you think you will not have the same issue with Chirpstack? The symptoms sound like a compatibility issue, the big question is, is TinyLora not compliant or TTN triggering this and can it be fixed without introducing new issues? Given the lack of downlinks in TinyLora it can’t be LoRaWAN standard compliant (the standard calls Class A: ‘Bi-directional end-devices’, the people writing the standard [at least v1.0.1, the oldest I could find] haven’t even considered transmit only devices it seems)
Is a non standards compliant device an issue on TTN? In my opinion not if it behaves in a way that doesn’t cause issues to compliant devices and other users. Generating excessive downlinks does of course cause issues due to the gateway spending too much time transmitting in stead of listening.
@johan@htdvisser what is your take on this issue? Anything you need for diagnosing it?
Is there something in the uplink (such as an ADR bit erroneously set) which is prompting the network server to issue a configuration downlink, especially to repeatedly issue it if that is in fact happening
What exactly is the network server looking for in terms of confirmation from a node that these configuration downlinks have been received?
One of the ways of considering #2 would be to look at the exchange with a fully-LoRaWan node: what characteristics of uplinks subsequent to the configuration downlink suggest that the configuration has been received and doesn’t need to be resent?
I did a quick check on Chirpstack and it seems to work with TinyLora (at least I can see messages in the device application on all channels).
What is strange is that with TTN stack v3 only messages on channel 0,1 and 2 are received in the application. Each new receipt on one of these channels triggers 5 new channel request, one for each of the other channels.
Messages on other channels are however received in the gateway but not in the application. For these messages the gateway displays the following message “Host cluster failed to handle message: Device not found”
Not sure what I can do to fix this (besides switching library which due to memory size of the nodes is not an option)
Check if adding the additional frequencies in the advanced network layer settings helps. I had a similar issue with a node and adding them resolved it. (In the application I saw messages concerning uplink frequencies)
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.
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 ) 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!
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.
) and many - if unable to pick up on the TTN RX2 SF = 9 end up unusable. If
