We’ve been seeing this in Haarlem too, since ages. Could be a different device, of course. It surely is the same type, as the payload is exactly the same as above. And maybe that’s what I hate most about this: the payload could have been empty for whatever they’re using this beacon.
We could compare timestamps if anyone wants to know if this is the very same device. Given that the minutes and seconds almost match the last posts above, it might very wel be. Last packets I got, all at 868.1 MHz:
06:34:11, rssi: -114, snr: 1.2
06:44:10, rssi: -114, snr: 1.8
06:54:11, rssi: -114, snr: 1.2
Given that the following decodes to an uplink with a human readable DevAddr, I’m quite sure it’s actually LoRaWAN, not just LoRa, even though we cannot be sure as we cannot validate the MIC.
I feel quite stupid for not trying earlier, but: this is using the default Semtech key for at least the NwkSKey, so its MIC can be validated. And assuming the same value for the AppSKey this might yield a decrypted payload of 4E18A782C05E69CA27026B2D7AB75A9B4D35, which is not plain text…
Also, I’ve found someone who actually knows where the node is (or a similar one), and who owns it, and I’ve asked him to refer the owner to this very topic. So, hopefully to be continued. And though I don’t care a lot about SF12 (and SF12 does not interfere with other spreading factors), maybe its usage will be made clear, or maybe it will be taken offline then…? Or if its location is known, others might use its transmissions for experiments too?
(And for future reference: there might be another one in Brussels, with DevAddr “BEACE100”.)
So at least the static, plain text payload is limited in size a bit by some reverse Base64 (rather than just using the DevAddr and an empty payload to reduce the airtime).
Okay, maybe the fixed SF12 does not imply the beacon is not compliant, but what about the fixed channel of 868.1 MHz?
End-devices may transmit on any channel available at any time, using any available data rate, as long as the following rules are respected:
The end-device changes channel in a pseudo-random fashion for every transmission. The resulting frequency diversity makes the system more robust to interferences.
In a related topic, BEACE001 was found too. So, the list I know of now:
DevAddr
Decoded payload
BEACE001
ThingsBeaconWalem001
BEACE100
ThingsBeaconBrussel1
BEACE101
ThingsBeaconBrugge01
BEACE102
ThingsBeaconVreren01
BEACE103
ThingsBeaconAmsterdam001
Like mentioned before: if anyone would know exact locations, then at least someone could use those for localization experiments… (Assuming people would not replay the very same packets from totally different locations.)
They are actually quite handy to test your gateway, and also receiving sensitivity over a period of time.
The ic880a board are sometimes failing when there is lightning in the neighborhood, and then the receiving sensitivity is 20db less.
