Many small TTN nodes only work in transmit mode. LoraWan sends replay packets on RX1 / RX2 time in the air nobody cares. It is not possible to introduce a flag in the TTN stack device configuration or LoRaWan Protocoll that identifies this? That would also help the tinyLora nodes and prevent a lot of useless data in the air.
These nodes are not LoRaWAN compliant in from TTI point of view should not be used on a LoRaWAN network. There have been extensive discussions in march/april (if I recall correctly) regarding this subject.
There was:
and lots of offers of help to get things like SlimLoRa compliant enough to cope, principally with ADR but it all fizzled out.
Due to the evolution of TTS, you will have to get all eight frequencies in to the setup for uplinks to be working properly (aka not dropped as not matching the channel plan & frame counter combo). This should stop any MAC commands setting up channels but after a while will stop ADR as I believe one of the modifications to TTS was to detect the futile attempts to adjust settings.
then is the TTI point of view for me a killer. One blocks oneself from data minimization for selfish reasons. Why should a node be forced to receive data that have no value and block the channels. A tick in the device configuration would be enough and everyone would be happy. When that is the last word, I say goodbye.
Please don’t shoot the messenger…
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.
1 Like
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.