In LoRaWAN receiving data does have value. ADR for instance requires downlinks to be processed and allows the back-end to minimize transmission time and power which creates a better network for all nodes near the gateway. By not implementing downlinks you are missing out on the optimization options in the network. And that is harmful for everyone using the same frequencies near your deployment.
Ah, better the gateways sparks zombies around.
First of all, there should be a network and not just gaps. if you throw out all the hobbyists because what was no longer possible, trust in ttn is playful. and the old nodes continue to send anyway …
(sorry my german to english comes from google)
I understand the frustration. However, technology progresses and matures and so do LoRaWAN and The Things Network.
TTN V2 was quite forgiving but TTS V3 is more strict and requires better LoRaWAN compliancy.
This means no TX-only devices and also renders older ATmega32x 8-bit AVR MCU architectures less/un suitable due to their now limited memory resources. Newer, better compliant LoRaWAN libraries like recent versions of MCCI LMIC require more memory resources than its now obsolete predecessor.
Thats the case for the ‘8-bit AVR MCU’ nodes that use the ATmega328P but the ATmega1284P has four times the Flash and 8 times the RAM, that should be enough ?
What would the point of an internationally agreed standard be if it wasn’t kept to.
You’d be upset if you filled your car up with something like petrol but not and broke down in the middle of the road blocking traffic, causing inconvenience to those that used the standard fuel.
But I think the most striking thing here is that people offered at the beginning of the year to help, they continue to offer help but it seems you really just wanted to get something off your chest.
If that’s not the case, how can we help. As I said above, you can setup the device to minimise downlinks.
I’ve just moved “descartes-device-number-two” which is a Pro Mini with RFM95 on it. I think it has LMIC Classic 1.5.0+arduino-2 on it, so not exactly compliant. It’s been sent two downlinks and now all is quiet. So TTS isn’t causing mayhem.
Whilst I’m using the ATmega4808/9 (6KB/48KB) as I can get them and if a client needs it, I can make it talk Arduino, I’ve not got any issues with LMIC 4.1 which is LoRaWAN 1.0.3 fitting in to a Pro Mini (328) for a couple of sensors on I2C using OTAA, downlinks, ADR and all the trimmings.
Using an ATtiny with send only ABP was a compromise the day it was launched.
You can never trust a technology that excludes old hardware when changing versions. This is not progress, but arbitrariness. Whether the TTN network is better helped when old nodes do Lora without Wan from now on? In any case, it doesn’t fill up the return channels. What about V4? Do you then need new hardware again? It’s good that you weren’t responsible for the WLAN standard …
Unfortunatly some ‘old hardware’ whilst it may have sort of worked, has not followed the published standards, so should non-complaint hardware continue to be supported in the future ?
Yes, the brave new world is now that every stupid temperature sensor or door contact needs a return channel that fills the spectrum and eats electricity.
With less/un suitable I was referring mainly to ATmega32xx and ATtiny.
The average DIY TTN hobbyist uses (cheap) ready made microcontroller (LoRa) development boards.
For 8-bit AVR this usually meant ATmega328 or ATmega32u4 based boards.
ATmega1284P may be suitable but is not often used for LoRa applications. I haven’t yet seen popular commercial small development boards based on the 1284P. The 1284P also seems relatively expensive.
We (the TTN community) were not responsible for the LoRaWAN standard either. Or for nodes that knowingly were incompatible with the standard from the day they were created. If something not compliant happens to work and later on breaks you can fix it or dump it. Or move to another LoRaWAN network where it might continue working for now (until an upgrade over there breaks it as well).
I have also not seen any commercial uses either, although size wise there would not be much difference, it is available in QFN.
I use them for hobby stuff quite a bit and have my own node PCB that uses all wired components (so easy build) and a DIP 1284P. It has a single Mikrobus socket for a choice of LoRa modules, size is 80mm x 33mm.
upset with change - but technology evolves, get over it
Toys out of pram/leaving the party
Someone (actually a few) recognised value and benefit and needs of V3, and fact that earlier ok operation of non compliant nodes was a bonus but isnt/wasnt sustainable long term
TTN one of the few (non commercial) networks that lets small user sna developer play with/use the technology, and commercial networks even more constrained wrt types of nodes and need for (near) compliance with standards/specifications
No new arguements evolved, and no new participants joined in so discussion died after a few days with ‘agree to disagree’ stand off
Sad but guess we cant take everyone with us… V2 is dead, long live V3
Mr @temp99707 appears to say he doesn’t use LoRa, so as well as being factually wrong in his first post, his opinion is rather irrelevant and it seems no one really agrees with him anyway, so I’m not sure it’s a problem to leave him behind.