I have some Elsys temperature and humidity sensors that have been sending every 15 minutes for almost two years and I have been very happy with them.
After looking at the data collected the last 2 years and noticed a fairly linear drop in the number of messages from these sensors of about 10%. The number and placement of TTN gateways has been stable in a city of about 200 000 inhabitants.
Society is packing a bunch of stuff (not only LoRaWan) in 868 MHz and this is anecdotal since I have not stored SNR but it does seem like there is more noise and less signal in the messages as of late. Has anyone noticed the same drop-off in expected traffic from their sensors? Or is it just me?
Sending a GPS position + some other measurements over SF12 takes about 1.5 seconds, with an all or nothing approach to messaging does this leave LoRaWan vulnerable to increased use of the 868 MHz.
If they are on v2, as implied by the duration you mention above, they will have experienced brownouts of the network as it is closed down - going away on the morning of the 1st Dec ā¦
GWās wont even be impacted then as already declared elsewhere on the forum they will continue to function(*) via PacketBroker connectionā¦Nodes, however, plan for the worst!
(*) feeding traffic for V3 devices for an as yet unconfirmed period - should still be planning full V3 transfer of GWāsā¦
If the 10% reduction is gradual and over the full 2 years then the recent brown-outs of node traffic on V2 will not materially affect/contribute to that overallā¦but 10% is nothing c/w what can be expected from Dec1/Dec2+!!!
Correct, but the question was about sensor data drop off, albeit without any details as per normal forum policy, so itās not clear if itās in the last few days, weeks or months.
Apart from the restrictions that should be imposed as per LA requirements on SF12 transmissions, you are contributing to the noise by transmitting for so long.
Youāll also find numerous discussions on here about the merits, or lack thereof, of using LoRaWAN for tracking as there is tracking and then there is tracking. What sort is yours?
This is not related to v2, all sensors are migrated to v3.
It is a trend I have seen over the last two years, it does not matter for my application but I was just curious if this is a trend.
If every message is sendt at SF12, something they are not. If you need 1.5 seconds of uninterrupted air time to transmit a message or the message is dropped. With this long on-air time, data packets are vulnerable against jamming attacks and/or interference. Just trying to understand if interference is causing high packet error rates and loss of information in noisy environments.
Sorry english id not my first language, but by linearly I mean when I count the number of messages received from my sensors every day for the last two years the number of messages received has declined in a linear manner over said periode by 10%. Hope this satisfies normal forum policy.
@tingkart I am sorry to say but your topic seems hijacked by a discussion about migration V3 migration that is not relevant nor related to your question.
From my own experience, I can say that the noise floor is rising in all our spectrum. I cannot state it with measurements like you but your experience is as expected.
It is a frustrating aspect of this forum, usually I get shut down with a āsearch the forumā or a RTFM.
Wish I had kept the gateway id, SNR, SF and RSSI when I set up these about 100 sensors two years ago; could have made for some interesting analysis. Have started to log this now, maybe I will try to revive the topic in a couple of years with more data and the v3 migration a distant memory.
I am worried that something similar to the Kessler syndrome in low earth orbit space pollution is high enough that collisions between objects could cause a cascade in which each collision generates space debris that increases the likelihood of further collisions making space unusable.
As 868 usage increases ADR keeps bumping SF, users manually setting higher SF on their sensors, start implementing some message receipt/resend functionality or increase sending frequency in hopes of something getting through. Someone might decide to roll out a fleet of sensors that transmit every hour on the hour, with increased GPS integration in sensors this synchronization is way too easy to achieve, making the spectrum unusable at certain times.
There are at least 5 private LoRaWan networks (probably more) + TTN in my small town, Helium is moving in and a ton of non LoRaWan stuff using 868 MHz. How much traffic does these generate and how many of these are misbehaving? If there is anyone abusing a licenced spectrum there will be investigations and someone fined since some company has paid a bunch of money for the privilege, but 868 MHz I suspect will not get the same attention by the authorities.
At what point does 868 become unusable with high message drop rate, increased battery usage and reduced redundancy. The LoRa chirp is robust, but physics dictate there is a limit somewhere and the long on-air time combined with an all or nothing message delivery in LoRaWan makes it vulnerable, maybe?
It would be interesting to look at some real world data and try to ascertain where this limit is.
The V2 intentional brown-outs could have been relevant. Only now we know the sensors are on V3 (which at the start of the 2 years could not have been the case) we know this isnāt the case.
However I do recall some people (may-be even you) complaining about data not being delivered in V3 so may-be V3 is relevant after all? In that case it might not be a radiowave pollution issue but a V3 back-end issue?
It is just as frustrating to have to address the same issues over and over again. At least your observations are something new.
That is a lot. In a town with 200.000+ inhabitants my gateways (multiple in town) see just 3-4 private networks and Iām hardly seeing Helium traffic.
The advantage of ADR is that a node will be instructed to use the minimal amount of transmission power required to uplink packets thereby reducing the āpollutionā.
There have been some academic reports regarding the subject. Some have been quoted or referred to on this forum over the past 5 years so you might be able to find some pointers.
Sorry but I disagree. On a time frame of 2 years of data collecting. Outages of TTN general can be easily identified with a breach in trend.
From daily measurements, I can state that in the area I monitor, through the community gateways, I see on average 625 TTN devices, 2800 KPN devices, and 18 Helium devices. Through Proof of Coverage (PoC) activity of Helium (at SF12) additional traffic is added that I do not account for in these figures.
Yes it is getting crowded. And yes, humanity acts like a bacterial colony that will perish in its own waste.
I did see the phrase ālinear trendā in the two year timescale but given the variability of descriptions of issues, as per normal forum policy**, wanted to eliminate any recent brownouts from the equation.
There have been some refinements of the duplicate uplink detection on v3 but that was in the order of 1-2% and obviously there would be a kink in the (unshared) curve around the time the devices were moved to v3 if that were the case.
The official value that TTI work to is 10% loss on the overall system - mostly before it hits the Network Server. If the goal posts could stay still for ten minutes (latest shift is due to new variant affecting any possible forays in to Europe in coming months), Iād have some hard data on drop out rates including a log of local ānoiseā - either LoRaWAN packets from other networks plus other users of the 868MHz band.
** Say āI like ChĆ¢teauneuf-du-Papeā to my wine tutor and heāll ask for the actual blend(s), year(s) and which estates Iām referring to. Detail is important!
Not a stupid question, batteries are always my first go to. I tried to scrub all the known sources like TTN outages, gateway outages, my application but I still see a nagging gradual decline in expected traffic from my sensors.
I am thinking in order to figure out this issue (if there is one) I need some cold hard data that I am currently in the process of collecting. I shall return.