seems normal to me.
probably these packets are ’ dropped ’ (see trace a bit further down the screen) by the TTN backend
I have it to sometimes, what you can see is that the node is far away from you, SF 12 , RSSI -119 and SNR -15, also the air_time is ‘enormous’.
I found the weather condition the source of this… sometimes suddenly these far away (or new/other network) nodes can reach your gateway and sometimes not.
I also see it on my gateway. I’m based in Mijdrecht, The Netherlands.
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:
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.
4003E1ACBE00010001D92BEAA03E3922A1F1181B16737B0E5F590806071BBD
@htdvisser, @telkamp et al: this might be a nice use case if you want to test localization. Find that device, maybe there’s a price to win! 
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”.)
they are some kind of beacons, spread all over Europe and with one owner ?
If you do a base64 you’ll get :
BEACE101 ThingsBeaconBrugge01
BEACE102 ThingsBeaconVreren01
BEACE103 ThingsBeaconAmsterdam001
BEACE100 ThingsBeaconBrussel1
Owner is WirelessThings (WirelessBelgium)
echo -n 4E18A782C05E69CA27026B2D7AB75A9B4D35 | xxd -ps -r | base64
ThingsBeaconAmsterdam001
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).
But weird that a LoRaWAN provider is deploying devices that are not LoRaWAN compliant?
WirelessThings is LoRaWAN compliant - but not part of the LoRa Alliance.
I know WT is using a similar feature like gateway discovery in LoraServer of Brocaar
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.
- …
Because of good RF conditions I see both the Amsterdam and Brussels beacon today. 
More updates!
Move my antenna higher, I’m now picking up from the Brugge one!
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.)
| DevAddr | Name | Location |
|---|---|---|
| BEACE001 | ThingsBeaconWalem001 | 51.0613, 4.46262 |
| BEACE100 | ThingsBeaconBrussel1 | 50.838, 4.3373 |
| BEACE101 | ThingsBeaconBrugge01 | |
| BEACE102 | ThingsBeaconVreren01 | 50.7375, 5.50605 |
| BEACE103 | ThingsBeaconAmsterdam001 | 52.3457, 4.82638 |
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.
I don’t know what happened, but BEACE103 is not active anymore. Up untill two days ago I could decode it every 10mins. Now nothing…
They are watching us!
someone broke the power going to the system, its a 235 km drive for me to fix it .
This makes sense, I see the BEACE100 also and I am living in Zeeland ever 10 minutes
