Since a few days I’m receiving a packet with identical payload every 10 minutes. It appears to be a valid packet, however the counter is not increasing and remains at 1. Dev addr appears not to be a valid TTN. Anyone has seen something similar?
If repeating counter of 1 then it could be a device powering up & TXing once then either deep-sleeping/resetting and restarting @ count = 1 again or perhaps running off energy scavenging - TEG, Solar, Vibration, etc. - taking ~10 mins to accumulate enough charge to TX once, exhausting and then waiting to recharge…even a duff battery might do that if it’s chemistry recovers enough to then restart b4 collapsing again. though that wont likely continue for long before battery totally dies?!
The Idea of TEG as source for short TX was one I have been thinking about/playing around with on LP radio for years…put TEG with radio enabled sensor on say radiator in cold room…Initiate boiler/pump which runs & heats radiator…starts to generate charge…powers temp sensor with radio, tx result…power down sensor/radio and wait for more charge build up…rinse & repeat…as room warms frequency of tx will fall as TEG temp diff reduces and takes longer to build charge, if room warm enough based on temp sens data or even just the fact of the TX event switch of boiler/pump etc. Similarly using vibration harvester for monitoring machinery (motors/pumps etc) - stay quiet for months/years then as bearings start to degrade vibration increases causing TX that then triggers preventative maintenance! 
Signal strength suggests you are getting this from a distance or poss a unit set to TX at low power (we don’t all need top ‘shout’ at +14dbm !) - perhaps to conserve any scavenged energy and reduce time between TX’s as threshold of stored charge to achieve TX would be lower if running TX at say 0dbm or -6 or whatever…
When I look at payloads on my gateway console I often see info on Network /Net ID /Region - can you see anything similar? Mine shows between Dev Addr field and Physical Payload field. e,g. something like :-
Network: Experimental nodes
Net ID: 0x00
Region: Local
…do you see anything similar for more clues?
I’ve seen these on my gateway along with Things Connected in the Network field.
Not managed to track down the node, but could be one of my very early ones that is still active but the application has long since been removed.
Andrew
nope no clues, however looking thru the log of my gateway i count 32606 hits …
I also receive the packer every two minutes.
(as an experiment I have a ~20dB preamp connected and no GPS yet).
Have you seen that there also is a new gateway near Amstelhoek (langs de Kromme Mijdrecht) since a few days? Maybe that owner is experimenting.
no have not, where are you located?
Mijdrecht, gateway b827ebfffef37f7f.
It seems that “BEACE103” now only sends once every 10 minutes.
Also managed to capture it with my RTL-SDR-dongle. That is coupled into the antenna via a 3dB coupler and preamplifier. 
1 Like
Sorry about posting to an old topic. I was going to create a new but found this on search.
Suddenly it seems one of my gateways is also picking this up now. And at around every 10 minutes.
To be honest I’ve had a lot of LoRa odditys over the last week. So think this could be another one of them.
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:
- 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.
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”.)
3 Likes
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)
5 Likes
echo -n 4E18A782C05E69CA27026B2D7AB75A9B4D35 | xxd -ps -r | base64
ThingsBeaconAmsterdam001
2 Likes
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