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.
TX only nodes are not LoRaWAN compliant. TTN is a LoRaWAN network. That it worked in V2 was a coincidence, not by design. That is doesn’t work in V3 is because V3 is following the specification more closely.
If you want to use TTN you need to use devices that are compatible with the LoRaWAN standards. Both gateways and nodes.
1 Like
Having compliant devices should be a reasonable default expectation - particularly given that you can make a TinyLoRa replica using a Pro Mini, an RFM95 and the very latest LoRaWAN v1.0.3 pretty much totally compliant MCCI LMIC with, between my knowledge for raw LMIC and, for larger devices, LMIC-node with assistance from the inventor, @bluejedi, there is absolutely no reason why people can’t be making devices for under $/£/€10 including some form of basic sensor which will run on a couple of AA batteries for about two to three years.
I know this for a fact. Somewhere in my garden is Device#2, the second one I ever made. It’s not optimal as it has an older version of LMIC & like TinyLoRa, is ABP but it has only ever been sent two downlinks before v3 got the message to leave it alone.
So there is NOTHING stopping a TinyLoRa device that’s been previously deployed being setup on v3 and there is plenty of assistance for polite requests for the magic command line parameters to minimise downlink traffic to save the gateway sending pointless updates.
The ‘issue’ seems to me to be that people interpreted the expectation that we use LoRaWAN compliant devices as a ban. I’ve never seen that said.
Whilst the lack of interest in updating something like SlimLoRa seems to preclude a light weight build, for emphasis, here’s my take on the situation:
We can still build & deploy low cost devices
We can still receive data from TinyLoRa devices
(with a caveat that when it’s battery change time, perhaps they are swapped out for a newer device).
This is wrong. I continue to use LoRa only without WAN and TTN. In the middle of Germany and had the only gateway here in 1000km². So it is no problem for me to do without TTN.
I don’t use AVR or tinyLora myself. I just can’t trust a network that locks out existing hardware. If in a few years MAC V1.1 will be mandatory, will all V1.0.1 versions be banned again?
And will these users be condemned again as gamblers / crackers and hobbyists?
Nobody knows and I am not taking this risk.