Hi Dana / @meterme, I’m located in the UK West Country and regularly see device 0100DA30.
It had not occured to me that fPort may be used for identification or that there may be more than one node sharing the same DevAddr! The device (or possibly device(s)) I receive have settled down to a SF12 broadcast every 59 mins 33 secs on average and snr is typically around -8.3 with a 32 byte payload.
The FUP for TTN suggests that 14 msg/24h should be the limit for this size of message using EU868, but I’m seeing around 24 msgs per day. Since my gateway is lightly used I’m not concerned. The duty cycle is not being exceeded according to https://avbentem.github.io/airtime-calculator/ttn/eu868/32
My guess would be that you’re looking at traffic from a different LoRa network scheme that isn’t actually LoRaWAN but some other air protocol on top of the basic modulation. Even if it starts with an address near the front and ends with a checksum the internal protocol-level packet fields may be different.
In theory a non-LoRaWAN network (and maybe even a private LoRaWAN one, source differ) should be using a different preamble sync word, but the sync word detector is leaky - about 5-10% of mismatched packets get picked up anyway, which is generally okay because it’s just there to stop wasting decoder instances and backhaul bandwidth things that aren’t even possibly interesting. Deciding what belongs to recognized node is up to the server.
Are you also seeing any of this at SF12? Because in the US that wouldn’t be legal for a packet long enough to include LoRaWAN-comparable framing data on a 125 KHz channel.
Thought I recognised the Dev Addr - 0100DA30 looks like one of my GW’s also picks up similar signals - but clearly not same device in Napa US or in Wiltshire UK- or in my case a GW to east side of Warrington Cheshire, UK: e.g. this evening:-
As suggested - using apparently random FPorts perhaps to identify sensor value/pupose or identity. Always near limits of reception level… I think I have been seeing this node for >2 -2.5 years now - it was 1st noted as I upgraded the site from an internal Ant deployment to a higher, better located (and outdoor) position on the building around that time and suddenly we started picking up several more marginal signals in the -118 - -121db level… might be as @cslorabox suggested above as not quite LoRaWAN or not intended for TTN - and yes in this case its at SF12!
Perhaps a supplier has introduced a device widely sold using same stock firmware with experimental Dev Addr, or perhaps people around the world have stumbled on and started deploying the same firmware/sketch for a LoRa/LoRaWAN implementation or cloned something from GitHub et al - may have to start seaching after the Xmas/NYear vacation period to see what pops up! - might start with old friends from the LoRa & LoRaWAN world - LPRS - who IIRC used to have a small dev team north of Warrington that I think relocated to Birchwood - closer to the WA1 Gateway and may have development units in range or perhaps they also see signal and we can track down?
@hphillip Howard, if I recall I think you were somewhere North Wiltshire, north of Swindon/M4 corridor? If so might you somehow be in range of a signal from Witney Oxon? - LPRS Hq is there and that cant be a co-incidence?! (Nick - Gibbs rule #?)
I also receive since many months signals of this kind of nodes with my gateway eu-de-cologne-east. They use the DevAddr 0100DA30 and transmit 52 bytes with SF12/125kHz.
fcnt and fport varying, different RSSI and SNR, seem to be different nodes.
@Jeff-UK Yes you recall correctly: my gateway is on the West side of Swindon, Wiltshire.
I would say within range of LPRS / Witney Oxen, however being North-East of my location, it is the one direction I have no coverage
Unfortunately Blunsden Ridge completely shields signals in the line of sight for that direction, perhaps with the exception of ADS-B traffic on 1090 Mhz from sources at typically higher elevations
The other observation looking at my log is that I see a lot of toggling of “adr” : true / “adr” : false for 0100DA30 and no obvious pattern for f_cnt or f_port (both of which “appear” random).
The pattern of the received data and the spatial distribution over time, as described in the thread has a strong similarity with Howe Helium has developed over time.
Helium is using SF12 packets with 52 bytes and hotspots are challenged to send a beacon every 6 hours (approximately, and depending on the health of their sysyem)
However I would expect them not to use a 01 prefix for decades and the RFU byte as their packet is not LoRaWAN compliant.
Chirpstack is using RFU for its own “ping-system”
I will look in to it here to see what my observations are.
A quick google search b4 shut eye last night only turned up a few instances of that dev address being called out… related to cloud based deployment/timing issues on azure & aws…inc a rakwireless/aws repost (user Craig or CraigE IIRC), plus one other. So not much out there…
Probably not. The way the fcnt is also jumping makes it more likely that that this is not actually a LoRaWAN packet, but some other network or point to point scheme that doesn’t have the exact header fields in the exact places LoRaWAN would.
It would make more sense to capture a bunch of raw packets and print them in hex and see what’s changing and what isn’t. In some work in other areas I’ve even used things like sort and uniq to do some preliminary analysis of raw packet logs - see what sorts of starts are common.
I did an analysis and correlation of Helium hotspots in my “city”, trying to pin down which one (or more) of them may be manifesting as data on my gateway as 0100DA30.
I took a sample of my gateway traffic for the offending devAddr - just 6 consecutive data points yesterday evening:
I then ran an extract of data from the Helium explorer api going through the 43 hotspots that are considered within the city.
Just my luck it was #43 that came up trumps: long-felt-grasshopper
For the six data points in my gateway there is an overwhelming correlation with the Helium data.
File attached for the detail for those that are interested.
This process would have been quicker had I done a visual inspection of the more probable hotspots that I was likely to hear on the west side of town/city.
The particular Helium hotspot must be well located judging by it’s coverage.
It’s not suprising that I also hear it loud and clear. Helium2.txt (12.8 KB)
Last night I have captured all LoRaWAN traffic that the community gateways of TTN-Apeldoorn and my own (a total of 14 gateways) received over a period of 18 hours. The result is presented in the following table:
KPN is a Dutch commercial LoRaWAN operator
The analysis is done on all non JOIN request uplink messages and analysed the device address. This is not 100% exact but because of the number of packets, I expect that the results are representative:
KPN has 2286 active end devices that send 20425 packets. TTN has 364 active end devices that send 79451 packets. Helium has 16 active end devices that sent 441 packets.
From all received packets 66% are related to TTN while 17% of all packets are from KPN end devices. The rest of the packets (17%) are not related to these networks.
How about the 0100da30 end device
This device address is heard over all 14 gateways. From these gateways, 50% have no geographical binding as they are too far away for line-of-sight and they do not share the same coverage area. Therefore it is not possible that transmissions by “0100da30” are done by a single and unique end device unless it is airborne.
My conclusions so far
Although KPN has more end devices (packet rate per hour is 1135), TTN is occupying the frequency spectrum the most with 66% of all received packets and a packet rate of 4414 per hour.
With 14 end devices and a packet rate of 25 per hour, Helium has no serious presence in the 868 MHz band.
If the “0100da30” end device can be related to Helium, the packet rate of Helium end devices increases to 126 packets per hour.
When evaluating frequency occupancy, the “0100da30” end device is not misbehaving. From LoRaWAN specification point of view there may be other reasons to judge otherwise.
Such a capture may well be distorted by the use of different preamble sync words - only maybe 5-10% of mismatches will leak through, such that you see some but not anywhere near as many packets as there actually are.
LoRaWAN can use multiple syncwords. In some guidance, the one TTN uses is only for public (not private) networks. In others it is only for LoRaWAN vs other protocols. But either way, not all LoRaWAN traffic in the world uses the syncword your gateway is set to look for. If there’s traffic with a different syncword on the air in your area your gateway would be drastically undercounting the degree to which the channels are being used.
And in terms of channel occupancy it doesn’t really matter if the traffic is LoRaWAN or some other LoRa scheme.
No, it hasn’t been established that this traffic is LoRaWAN. The alleged probe requests have a lot in common with LoRaWAN packets, but they don’t seem to be within the LoRaWAN protocol, and they’re alleged to be from gateways, not “nodes”.
Just a minor aside: beware that the DevAddr is not unique. I don’t know if KPN is doing any segmentation, but surely TTN is not randomly using all 25 bits it can use for its prefix as assigned by the LoRa Alliance. Instead, TTN probably only uses 2601xxxx and 260Bxxxx for its community network in the Netherlands. And (at least in V2) it then uses more segmentation to define specific classes:
Within a region, the NetworkServer is responsible for assigning device addresses. We are using prefixes here too for different device classes (for example, ABP devices in the eu region start with 0x26011) or to shard devices over different servers
If that still holds in V3, then TTN has about 2 × 1.5 bytes = 8,192 unique values for, say, an OTAA DevAddr in The Netherlands. So, some of the unique device addresses you have seen may be multiple devices.
Good point. I should have stated “device addresses used” instead of mentioning “unique end devices”.
I do not think it does change the significance of the result.
I was distracted over the holidays, this is very interesting. Agreed, this may not be LoRaWAN traffic at all (could be syncword leakage as well). The observed correlation with Helium pings is fascinating - I’ll have to have a look at that in my case.
These frames are usually SF9 and
I do hear these “DevAddrs” sometimes rather strongly - like this one just 12 minutes ago:
rssi:-79
loRaSNR:12
but usually much less strong:
rssi:-119
loRaSNR:0
The strong ping makes me wonder if I’m generating that ping from a device - the only thing that’s changed here recently is the addition of a TTIG.
I’m inclined to agree this is not a LoRaWAN frame per se; the advice to hex-dump them is good.
First, I’ll see if I can correlate this with Helium activity in my area. Assuming these are coming from GWs, I’d sort-of expect the RSSI/SNR to relatively constant for a given source, I’m wondering if I gather these frames then bin them out based on RSSI/SNR if I’d see discrete ‘bumps’
Indeed, I correlated a ping just a bit ago with a hotspot that shows up about 3.3km north of me in the Helium explorer.
I don’t, however, know where the -79 / +12 ping came from. Nothing shows in a Helium explorer hex, but this is probably within 1-2 houses of me. Asking the usual suspects.
Received by gateway: eu-de-cologne-east
Since more than one week this node transmitts 19 bytes with SF7/125kHz every 12 seconds.
Although this still seems to be compliant to the legislation it is far away from FUP.
Maybe the owner of this node reads this and starts thinking of what he is doing.
- might start with old friends from the LoRa & LoRaWAN world - LPRS - who IIRC used to have a small dev team north of Warrington that I think relocated to Birchwood - closer to the WA1 Gateway and may have development units in range or perhaps they also see signal and we can track down?
