Stay on topic and don’t try to start other discussions in this thread.
The last posts have hardly anything to do with the topic subject (is V3 the end for TinyLora?) anymore and are not related to the V2 to V3 Upgrade at all. For other subjects a new topic can be created if desired (always first check if any relevant topic already exists).
2 Likes
Actually the behavior of V3 imposes several new requirements which the behavior of V2 did not, and that’s the whole point of the thread.
2 Likes
Fair point. Yet the target audience and usage of TTN will have an impact on when the downward compability will end. So coming back to the original topic, it would be very helpful to know how long we can operate the old hardware with ABP, disabled frame counters and no downlink response. I guess the current setup, where every misbehaved device triggers unwanted downlinks and clogs the network, will not be accepted. So it’s either changing V3 for “backward” compability or I guess the devices will be kicked out (which I guess would be fine for some).
The right answer would be for the V3 stack to gain some downlink rate limits, ideally user configuration but at bare minimum safety limits to prevent it from being DDOS’d.
If it doesn’t then a possible workaround for people with legacy uplink-only requirements would be to run an additional LoRaWan network server (individually or collectively), twin a read only copy of the gateway feed to that, and register devices there rather than in TTN, while the gateway retains a read/write connection to TTN server for everyone else’s use.
(A server that merely decrypts and MIC-checks messages is pretty simple to DIY)
Since the “private” server can’t transmit, it can’t interfere with TTN’s requests to. Excepting the case where there was enough uplink traffic to saturate the concentrator’s demodulators, this would basically be like having two gateways (one TTN, one private) covering the area. As long as someone’s airtime usage is reasonable, you don’t really get to tell them that they have to implement a particular version of LoRaWan, or even LoRaWan at all - there are a number of other protocols run on top of LoRa.
1 Like
Do you mean ‘documented new requirements for V3’?
or do you mean ‘it worked before on V2 but it doesn’t currently work on V3’?
A requirement to work on V2 has always been to be LoRaWAN compliant.
That it was possible to use non-compliant devices on the network does not mean that LoRaWAN complance was not a requirement and hence that requirement has not changed.
TinyLoRa clearly was not developed to be LoRaWAN compliant. It was developed to ‘just make it work’ (where it covers ABP and uplinks only, not OTAA, not ADR and no downlinks).
Another example of this are the so called ‘single channel packet forwarders’. They worked previously but are not LoRaWAN compliant and are now deprecated and their use codemned.
It is unfortunate that TinyLoRa based devices may currently not be working with V3, but on the other hand this should also not come as a surprise because TinyLora is not LoRaWAN compliant.
Not exactly the same but similar is building software based on and depending on internal implementations of some product that are not officially supported by the product’s manufacturer.
If the implementation changes in a later version then dependencies on any previous implementation will break. The alternative is to use the manufacturer’s supported official API which they support for multiple versions of their product. Not complying with that API’s requirements and finding out that it also works if you only satisfy half of its requirments, may work for some version of the product but not for others.
I hope the issue can be solved for current users of TinyLora. On the other hand I would understand if TTI does not want to put much efforts in getting unsupported, non-compliant hardware to work in V3.
But calling this ‘different requirments for V3’ is not fair and not correct.
It is either a bug in V3 that will have to be fixed or it concerns an unsupported implementation dependency that is now broken in V3.
Which of these is actually the case I don’t know. I have no experience with and no devices using TinyLora. I usually try to stay compliant, to prevent future incompatibilities with newer versions where possible.
1 Like
No, I don’t. I mean exactly what I said. V3 imposes requirements which V2 did not: both changes to behavior, and changes to required node settings.
Another example of this are the so called ‘single channel packet forwarders’.
We all know those are bad - though ironically the “ignore for ADR” setting added for mobile gateways would make them safe, since they could no longer ADR-walk other people’s nodes into a black hole.
While you (and I) may not like people using a single channel, there are airtime rates at which it’s legal, and they can do it outside TTN if not inside it. The actual issue was the misleading ADR, and in theory there’s a fix for that. Though of course, to repeat your own point from earlier those are outside the topic of the thread and so probably should not have been brought up to begin with.
Not exactly the same but similar to the situation of building software based on and depending on internal implementations of some product that are not officially supported by the product’s manufacturer.
If the implementation changes in a later version then dependencies on any previous implementation will break.
Ironically that’s exactly what V3 has done with respect to even fully compliant nodes in requiring them to re-register…
1 Like
Legal from perspective of national RF spectrum legislation maybe, but not compliant with current LoRaWAN and TTN requirements and policies.
If this thread continues to go off track and lacking any substantive contributions to help find the actual cause/source of the problem then I will close this topic (without further warning).
As pointed out in the previous message you were the one who introduced the off-topic subject of single channel forwarders. I’d agree this is not the right place to discuss them.
1 Like
Don’t try to play mr. wiseguy and have the thread closed for all others.
I have warned before to stay on topic
Ladies & Gentlemen I think we need to draw a line under this topic before matters get out of hand.
I am not a user of TinyLoRa and have not looked at it in any depth but from the posts and side discussions one thing is clear unless there are major changes
Is V3 the end of TinyLoRa?
To all practical purposes in the context of TTN V3 and applying Community & Forum 1st principles I’m afraid I would say the answer is Yes!
Why?
- Its TinyLoRa NOT TinyLoRaWAN
- If it called itself (ok if it was named) TinyLoRaWAN, setting an expectation, I’m sure the LoRa-Alliance would be all over it for breach and would serve notice.
- As we tell other posters on topics like S/DCPF’s, LoRa Radiohead library and other LoRa-only (not LoRaWAN) implementations TTN is focussed on LoRaWAN implementations not LoRa-only, The Forum is focussed on support for LoRaWAN (though some posters may kindly reach out and support struggling users to a limited extend and that is/has been tollerated vs encouraged).
- It is in the Communities interest to ensure minimum disruption and maximum compliance where practical
- TTN is evolving and so are the rules around it…in the early days of motoring you could drive a car without following specific rules of the road, without meeting basic needs for what we would consider a reasonable car specification today, and without complying with later requirements to have the driver pass a test and meet the requirements of those rules. Today, however, no one would responsibly dream of taking to the road - in most parts of the world! - without following the rules and having a car that is fit for purpose.
I will confer with the other Mods and we will take advice frm the TTN core team as to how to handle but for now I recommend, quietening this thread and potentially closing.
With the proviso that IF a user develops a solution for how TinyLoRa, or a suitable evolution, can implement a bare bones set of functionality that meets with the major broad requirements of LoRaWAN, and the V3 deployment, even if it isnt able to fully comply with all corner cases (we traditionally do not ask for devices to be tested as L-A compliant & certified), then they can post such a solution under a new thread. If it is judged to not meet the requirements the proposal will simply be closed and unlisted.
I propose we give it 48hrs to cool and consider then take action as needed.
1 Like
However using non compliant nodes is not something the community can prevent and the community suffers the consequences in the form of having its gateways suffer a kind of denial of service attack when someone powers on one of these devices.
I can’t prevent any of my neighbors from messing around with these non compliant nodes, yet my gateway is suddenly not listening up to 10% of the time because it is transmitting MAC commands to those nodes. And the neighbor might not even be aware (s)he is causing issues for others.
Having the code available in the Adafruit GitHub repository and an article explicitly targeting TTN on their instructions website does not help in making people aware this code should not be used. I suggest TTN/TTI contacts Adafruit to have them update the article and add deprication messages to the repository. (@johan / @wienkegiezeman )
I think the behavior of V2 to stop sending downlinks when a node does not respond (correctly) is the way to resolve this. In the community network where well willing amateurs are able to misconfigure their nodes, sometimes intentionally but most of the time simply because they’re unaware there is something wrong, the stack has to help protect us from harming the community, not add to the issues.
Adding a switch which a nodes owner needs to toggle will not resolve the issue as that still relies on the owner being aware of there being an issue and in requiring activity which the community can’t enforce.
8 Likes
I very much agree with the above - the network needs to protect itself from what it cannot control.
I’d also point out that there are two distinct categories of non-compliant nodes: those operated by those who merely “use” the network and those operated by “contributors”
“Contributors” including several apparent tinylora users posting in this thread are those who bought and deployed gateways to support their needs, and connected those to TTN so they’d also be available to the community.
If what someone is wanting to do via the gateways they operate is legal then there’s nothing TTN can ultimate do to stop it. TTN can “encourage” different behavior, but not mandate it, because the person is free to disconnect from TTN and run their gateways through a private server instead.
So the question becomes, does TTN strategically want to kick these people and their gateways out of the network?
Or where things like legal-airtime uplink-only usage cost TTN no more intereferance when run through gateways that also support TTN than they’d cost if the gateway were strictly private, does TTN want to take some very very trivial steps to be able to continue to accept the feed from those gateways, without making assumptions which cause it to DOS itself with unproductive downlinks?
Network servers and cloud instances are cheap. The real asset isn’t even gateway hardware, rather TTN’s real asset of value is the gateway site installations.
4 Likes
It seems Off Topic but it’s not. The persistence with MAC downlinks, is not even easy to handle with LMIC.
I tried with mcci + otaa and have several major issues both in V2 and in V3.
Only in V3 I have join accept, but I have repetitive unprocessed downlinks about ADR and StatusReq. I suppose I have to modify the example from LMIC.
Also my Zane trackers does not work with V3. Zane suggests to use ABP and not OTAA. I suppose they don’t have polished the OTAA firmware.
Really a nightmare for me, since with TinyLoRa and ABP I had a MOBILE device and I was ready to map the GW’s and to change SF / Power according to the location of the device / GW’s. Ideally I wanted support for downlinks, so I would update the location of GW’s remotely, but it was the last step. And now the last step is a requirement 
Now I am back at square 0.
And even if I make it.
- LMIC does not fit with my application. (I have FRAM but it just an extra obstacle)
- I have worst battery life.
- No benefit to the network (mobile device)
2 Likes
What are the issues?
Which device?
While perhaps not entirely distinct in cause, specifically debugging MCCI LMiC (vs concern about a newly found need to) really should be its own topic, either here or perhaps more productively on the repo’s issues or support forum - perhaps uniquely among LMiC’s they’ve been really trying to get it through the LoRaWan compliance test suite in a closed-RF environment such that they can run it in all regions, and not just where they are located.
Turning off downlinks entirely would be comparable to the TinyLoRa case… making them achieve proper responses is something else.
1 Like
I agree. I will post my problems, (@bluejedi thank you for your care). Still investigating. I think my problems are also subject to my GW. Not sure yet.
The ON Topic is that with my current equipment (GW + Nodes with TinyLoRa) I didn’t break the TTN rules and my app was working with V2. With V3 still trying.
@Jeff-UK TinyLoRa is LoRaWAN without downlinks. To my knowldedge LoRa does not support FramePorts 
LoRa is a modulation technique. The code is so simple that I was able to add support for FramePort, and my next step was to add an example to hope between regions during runtime. Something that LMIC does not support!
1 Like
I get your point but the above is a simplified and incorrect statement.
More correct is: “TinyLora supports LoRaWAN uplinks (only) but is not compliant with the LoRaWAN specifications”.
By not supporting downlinks it also does not support OTAA (preferred but optional), confirmed uplinks (optional) and essential MAC commands from the network like status request, dynamic adjustment of RX delay time, setting channel frequencies and setting data rate (ADR, to be used for stationary but not mobile devices).
1 Like
Not essential. Beneficial for reckless users, but not essential. That is my objection.
TTS can send email to reckless users about the bad behavior.
The only problem from above - since I have only mobile devices - is that I have to modify the chanell freq’s with physical access to the nodes. As I stated, that was the reason that I wanted support for downlinks (not for MAC commands!)
Even with a static device TTN (or should called TTS now?) a cautious user can set the power. If you see my PR on TinyLoRa I can set the power to -80dB. So when testing and static, I used this option. Someone can use that if the GW is near him.
But not anymore. 
1 Like
TTS??
TheThingsStack
(login page)
The Things Stack would like to: