Yes, I have deployed many and if you use search on the Forum you will see that historically this was a problem. They used a proprietary payload and ack as developed originally for a specific customer and one where audit of cold chain was required at that. It meant that in the early days we could only get infrequent readings without breaching FUP. Laird then added option for Cayenne LPP which many of us adopted. There is also option for confirmed or unconfirmed uplinks introduced at the same time. Though I would highlight that even unconfirmed option still requests a confirmation every 10 messages to help node determine if still live and see on network. If not it can take action to try and reconnect or increase SF/Tx power to correct for any change in local RF environment. The fact they still use some confs does mean that you have to consider reading frequency carefully to ensure you still remain within FUP. They have since gone on to update their firmware further to allow other option (explore their Bluetooth control app and a recent build if interested).
That’s a relief and good to know so likely no doomsday scenario though we still require you to play nicely if using TTN CE as your network
Standard text, all good
Orange text, not visible to user because they have had everything turned off and their email address blocked.
Red text, message upon login with PDF of letter sent to that countries authorities.
I just side-graded to a Jaguar X-Type, lovely bit of kit, press the gas pedal to the floor on the motorway and I accelerate fast. I bet I can exceed 110mph with ease, our motorways set to a 70mph limit.
I don’t expect a green light for within the law driving, and orange when I’m just breaking the law a bit and a red one when it’s a lot. I expect a blue light in the rear-view mirror. And harsher punishment for parole violators.
If you were, maybe it’s worth have a protocol in your organisation not to turn them on until they have been neutered, so this is less likely to re-occur.
Recently my gateway is observing traffic from an “Experimental Node” at SF7 and forwarding the data to TTN.
The traffic is always a 36-byte payload but anoyingly it is sent about every 10 seconds and always on the same channel 868.1 MHz.
Cynically, I suspect whoever is responsible for the node is probably well aware of duty cycle and FUP because they appear to send a couple of hundred payloads, then change their device address and the pattern repeats!
Not sure if they are trying to operate below the radar but I am suspicious because the RSSI and SNR show little variablility when the node gets a new device address, so it’s probably is from a fixed location and from a single device.
In the grand scheme of things this is a trivial amount of data, but as the number of nodes increase in the future, such behaviour is likely to start impacting the performance for other LoRaWAN users.
I was not clear if the plans for “Non-Compliant End Devices” (linked earlier in this thread) has a strategy to deal with deliberately misbehaving nodes/users?
Perhaps you, @Vaelid Simon, and some of the others in the Swindon/Wiltshire area can go on a bug hunt?
Dont currently see any GW’s active and public under the N Wilts community so not sure where your GW is or if others around the area. Are you the TTN West Swindon Gateway? To far south to come under N.Wilts. When you next see a Dev Addr change post a few sample data points to give some feel for signal condition (and hence range) and perhaps device might otherwise be identified…or claimed/corrected by a Forum reader
Guys thanks for the suggestions! I’ll hopefully reach out to @vaelid and perhaps track down the device once so more data has been gathered.
Yes you’re right: I’m the “TTN West Swindon Gateway”, it’s a fair cop.
There are few (public) gateways showing up on the map (well within about 20 Km of me), though it’s just possible that “Chippenham Standard Gateway 1” may have logged similar traffic as me this afternoon. For me in Swindon, the RSSI is usually in the range -119 to -108 and snr sometimes as good as 4.75, so I would imagine unless there’s some tropo going on, the device in question can’t be too far away.
The dev_addresses I saw this afternoon (sequentially) are…
If that is over a year it is 0.005% DC = still legal! If over longer period then no issues. If registered on TTN it would be ~3x FUP allowance if running since TTN start in 2015! Its Dev Addr suggests experimental node, so could be being used on almost any network(public or private). GW will pick up any Tx in range so no way of knowing I guess.
Lots of early devices such as the original LoRaMOTEs were shipped as 00 or 01 Dev Addr (have a few myself), and given count could have been running since then Also may be running under ADR, (though in that case likely to have taken a network specific DevAddr), with SF ramping up and down over time depending on signal conditions and environment …may have started on SF7 and moved out(*)… so no way of knowing if ~44hrs accurate or not. Worth keeping an eye on though!
(*Have seen a water meter in garden pit start on SF7 run fine for months then when a rubbish skip dropped on top for some building work it moved to SF11 then dropped back to SF8 once the skip moved some weeks later (never did find out why ont back to SF7!)).
I didn’t know that the TTN backend ignores this dev addr. Then it could make sense to block these range in the gateway already. Or let only dev addr pass that are within the TTN address range.
The TTN backend ignores all traffic for unknown nodes. It has to as any gateway might receive transmissions from nodes of commercial and private LoRaWAN networks. Only when there is a packet broker ‘connection’ to the other network traffic might be forwarded, however for the experimental address range that won’t happen as no network operator owns this range.
Filtering at gateway level has been discussed multiple times but isn’t worth the effort unless the gateway uses a metered internet connection. (And even then there must be quiet a lot of traffic to make a difference)
The resource where nodes like this cause the most harm is airwaves, that is a shared resource with limited capacity. Internet bandwidth and processing at the backend isn’t that limited.
