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
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
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.
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
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?
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
Agree. In the interest of spectrum preservation, NoTHiNG should be set to keep trying forever…that is just antisocial imo!
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.
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
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).
1 Like
Newly created application or device?
I meant device (not application)
edited your post to fix that
@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
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.
This gives the following response.
There are no set-up requests anymore and the device is reportig on all 8 channels. So I am happy with the result. 
1 Like
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
- 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.
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.
Wasn’t aware of a 9th channel (never to old to learn). So far haven’t seen any negative effects by not entering it in the set-up
Which is fine, as long as the device’s stack can process the MAC command. For many devices with much older builds, this may well have been hard coded.
It’s on my todo list to check when this level of support was introduced.
In my case the network keeps sending downlink messages. 
I updated network settings but I see no change unfortionately.