If your node does not receive, how can it optimse the transmit settings in order to reduce the impact on the TTN system as a whole ?
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)
This is so untrue…
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.
Maybe you could travel hopeful?
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.
I have a PCB that is a Pro Mini compatible plugin which uses an ATmega1284P. Its mainly for DIY though.
1 Like
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 …
Like leaded petrol?
Or acoustic modems for dialup?
Or what. Sounds like a threat to me, so I think we’re going to close this as you don’t want helping and there’s no point whining.
PS, the bits missing from TinyLoRa were always in the spec, they were just left out because using an ATtiny looked like a good move at the time.
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).
Can we split this discussion into a separate topic? It is not on subject…
This is getting out of hand.
This respectless way of communicating is not tolerated on the forum.
@temp99707 If you continue to act this way I will close the topic.
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.
Found the same topic from maybe the same TO on a different forum (german) TTN V3 das Ende einer guten Idee? - Mikrocontroller.net
Basically from a quick read (TL:DR)
- trolling from a distance
- 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.
Ideally, even the moving nodes must be receiving MAC commands. I agree with you that it seems aggressive the non-welcome to TX only devices.
Probably the network is big enough and they don’t want more TX only nodes. In my country it would not be a problem. Low traffic, but I don’t have information about the TTS infrastructure.
Yes, the bar is set high now, some extra time to adapt, but you can make it.