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…
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.
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.
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.
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.
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)
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.
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!
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).
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.
Yep! As I am now in my 9th year living and breathing LoRa and later LoRaWAN, and in the early days - before the emergence of even LoRa MAC in C from the Semtech/IBM collaboration (LMIC as known to many forumites) and later what we have done to consolidate and standardise around LoRaWAN under the LoRa-Alliance, I saw a great many clients, device makes, and colleagues develop proprietary LoRa implementations. Many of which have been ‘open sourced’, and which applicable to a range of device deployments some simple 2 device link P2P through point to multi-point to star and star of stars and even meshed implementations. If I may refer to all these (whether closed or OSS/FOSS) as ‘proprietary’ here simply to discriminate from LoRaWAN standardised implementations then with respect I would consider your statement of
To be very misleading and in this context even mischievous!
Conversely what TinyLoRa is can be thought of as YALPI* that just happens to have made use of LoRaWAN uplink capabilities in part.
A very clever and elegant (within its resource and capability constraints) implementation which I would applaud, but none the less one that should not be claimed or associated as being LoRaWAN capable or compliant. (As previously stated I suspect the L-A would take a dim view of any such claim or assertion).
If the gateway’s start sending 10% of it’s time this has also a vast impact on the other users (nodes and gateways) in the surroundings. If that gateway is sending at 30meters high with a good outdoor antenna this could be an impact for km’s around. This could also impact other lora(wan) networks.
They will blame the gateway and to me, that’s correct.
LoRa is a modulation technique. The code is so simple that I was able to add 