# Is V3 the end for TinyLora? **URL:** \ **Category:** V3 Devices\ **Created:** [January 30, 2021, 6:20pm UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525 "2021-01-30T18:20:44Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![LittleJoeMuc](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/littlejoemuc/32/35718_2.png) [@LittleJoeMuc](https://www.thethingsnetwork.org/forum/u/LittleJoeMuc)\ **Post date:** [January 30, 2021, 6:20pm UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/1 "2021-01-30T18:20:44Z")
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. 😩 ![new channel request](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/7/a/7a29cc23d2b912e732a0ae4fc05fe305ec0a1c87.png) ---
**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\ **Post date:** [January 30, 2021, 7:03pm UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/2 "2021-01-30T19:03:12Z")
What settings did you use when creating the device? OTAA/ABP, which MAC version? Did you change any ‘advanced’ settings? ---
**Author:** ![LittleJoeMuc](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/littlejoemuc/32/35718_2.png) [@LittleJoeMuc](https://www.thethingsnetwork.org/forum/u/LittleJoeMuc)\ **Post date:** [January 30, 2021, 7:12pm UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/3 "2021-01-30T19:12:40Z")
ABP (I think OTAA is not even possible with TinyLoRa) I tried all MAC-versions, same problem with all. With 1.0.0 there was no connection at all if I remember correctly. Didn´t try 1.1 I enabled “reset frame counters”, no other changes in advanced settings. ---
**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\ **Post date:** [January 30, 2021, 7:41pm UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/4 "2021-01-30T19:41:11Z")
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. ---
**Author:** ![LittleJoeMuc](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/littlejoemuc/32/35718_2.png) [@LittleJoeMuc](https://www.thethingsnetwork.org/forum/u/LittleJoeMuc)\ **Post date:** [January 30, 2021, 10:10pm UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/5 "2021-01-30T22:10:24Z")
Added these in the network layer advanced settings. Still same results. The standard 8 channels should work anyway without this? Set MAC to 1.0.1 ![channels](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/5/8/58d6aff19970b0a4933a83a74a4a8e500a638aa7.png) ---
**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\ **Post date:** [January 30, 2021, 10:53pm UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/6 "2021-01-30T22:53:23Z")
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. ---
**Author:** ![clv](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/clv/32/46568_2.png) [@clv](https://www.thethingsnetwork.org/forum/u/clv)\ **Post date:** [January 31, 2021, 10:08am UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/7 "2021-01-31T10:08:27Z")
I have the same problem. Thanks to TinyLoRa as a newbie I am able to join the network relatively easy. set device as ABP \> send a message \> check the network. In fact I find it very cool because it uses less airtime for non-critical applications. I would like a solution, pleeeaaaasssseee! ---
**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\ **Post date:** [January 31, 2021, 10:41am UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/8 "2021-01-31T10:41:30Z")
> [@clv](#): > > I would like a solution, pleeeaaaasssseee! Alter it to work? ---
**Author:** ![clv](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/clv/32/46568_2.png) [@clv](https://www.thethingsnetwork.org/forum/u/clv)\ **Post date:** [January 31, 2021, 11:08am UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/9 "2021-01-31T11:08:31Z")
> [@descartes](#): > > Alter it to work? 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. ---
**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\ **Post date:** [January 31, 2021, 11:11am UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/10 "2021-01-31T11:11:43Z")
> [@clv](#): > > c. I have other pririorities 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. > [@clv](#): > > d. What’s the reason for those downlinks? 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. ---
**Author:** ![clv](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/clv/32/46568_2.png) [@clv](https://www.thethingsnetwork.org/forum/u/clv)\ **Post date:** [January 31, 2021, 11:21am UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/11 "2021-01-31T11:21:51Z")
> [@descartes](#): > > but you don’t want it done that much you want to do it yourself. Sorry, I didn’t get both (+MAC) statements. ---
**Author:** ![rvdvoort](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/rvdvoort/32/35697_2.png) [@rvdvoort](https://www.thethingsnetwork.org/forum/u/rvdvoort)\ **Post date:** [January 31, 2021, 11:25am UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/12 "2021-01-31T11:25:32Z")
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. ---
**Author:** ![pe1mew](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/pe1mew/32/45049_2.png) [@pe1mew](https://www.thethingsnetwork.org/forum/u/pe1mew)\ **Post date:** [January 31, 2021, 11:43am UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/13 "2021-01-31T11:43:54Z")
I have a suggestion worth investigating: Paperinode ([GitHub - RobPo/PaperiNode: Selfpowered E-Paper Node for LoRaWAN](https://github.com/RobPo/PaperiNode)), running on an ATMEGA328, is using an Ideetron LoRaWAN stack: [GitHub - Ideetron/Nexus\_LoRaWAN: Arduino Sketch to make your Nexus board function as a LoRaWAN mote](https://github.com/Ideetron/Nexus_LoRaWAN). This one fits in the ATMEGA328 and even supports OTAA (not verified by me) ---
**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\ **Post date:** [January 31, 2021, 1:18pm UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/14 "2021-01-31T13:18:12Z")
> [@rvdvoort](#): > > If no solution is found it will force me to go private (Chirpstack) 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? ---
**Author:** ![cslorabox](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cslorabox/32/35697_2.png) [@cslorabox](https://www.thethingsnetwork.org/forum/u/cslorabox)\ **Post date:** [January 31, 2021, 2:26pm UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/15 "2021-01-31T14:26:33Z")
The more productive questions would be: 1. 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 2. 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? ---
**Author:** ![rvdvoort](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/rvdvoort/32/35697_2.png) [@rvdvoort](https://www.thethingsnetwork.org/forum/u/rvdvoort)\ **Post date:** [January 31, 2021, 7:18pm UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/16 "2021-01-31T19:18:01Z")
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) ---
**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\ **Post date:** [January 31, 2021, 9:49pm UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/17 "2021-01-31T21:49:20Z")
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) ---
**Author:** ![htdvisser](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/htdvisser/32/45312_2.png) [@htdvisser](https://www.thethingsnetwork.org/forum/u/htdvisser)\ **Post date:** [February 1, 2021, 9:45am UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/18 "2021-02-01T09:45:35Z")
**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?). * * * > [@kersing](#): > > Is a non standards compliant device an issue on TTN? Yes, this is an issue. We’re doing LoRaWAN here, not plain LoRa. > [@kersing](#): > > Generating excessive downlinks does of course cause issues due to the gateway spending too much time transmitting in stead of listening. 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. > [@cslorabox](#): > > 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 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). > [@cslorabox](#): > > What exactly is the network server looking for in terms of confirmation from a node that these configuration downlinks have been received? LoRaWAN-compliant devices will send a response to acknowledge that they processed the MAC commands. > [@rvdvoort](#): > > 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” 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. ---
**Author:** ![Jeff-UK](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/jeff-uk/32/35697_2.png) [@Jeff-UK](https://www.thethingsnetwork.org/forum/u/Jeff-UK)\ **Post date:** [February 1, 2021, 10:30am UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/19 "2021-02-01T10:30:08Z")
> [@htdvisser](#): > > optimize the data rate of a device (ADR), 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 > [@htdvisser](#): > > reconfigure the RX2 data rate from SF12 (the LoRaWAN default) to SF9 (the default on TTN) 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 > [@htdvisser](#): > > eventually want to have a LoRa-Alliance-certified Network Server 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! 😉 ---
**Author:** ![cjhdev](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cjhdev/32/35697_2.png) [@cjhdev](https://www.thethingsnetwork.org/forum/u/cjhdev)\ **Post date:** [February 1, 2021, 11:15am UTC](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/20 "2021-02-01T11:15:09Z")
> [@Jeff-UK](#): > > strip out ADR handling from firmware allowing smaller footprint etc.? 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. > [@Jeff-UK](#): > > 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 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. > [@Jeff-UK](#): > > Then should we not have option to allow RX2 @ SF12? if that is indeed the default? I expect you can if running a private instance. 🙂 [Next page](https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525.md?page=2)