search

opendroneid / receiver-android

Example Android receiver application for unmanned aircraft Remote ID
Apache License 2.0
211 stars 64 forks source link

WiFi-NAN devices show up multiple times #44

Open janusw opened 2 years ago

janusw commented 2 years ago

While BT and WiFi-Beacon devices only show up once in the list of devices (they have a fixed MAC), WiFi-Beacon devices show up multiple times (apparently because the NAN Id is changing frequently).

One would need to deduplicate this via the ID info provided by the device in the DRI packets, I guess?

friissoren commented 2 years ago

Hmmm.... Yes. That is probably the case.

The Android API for NaN does not provide a MAC address to indicate which transmitter a given "ping" was received from. It does give some small hash value (I suspect the range of that is just a byte?) which is different for each transmitter and stays consistent (at least for a while): https://github.com/opendroneid/receiver-android/blob/master/Android/app/src/main/java/org/opendroneid/android/bluetooth/WiFiNaNScanner.java#L101

https://developer.android.com/reference/android/net/wifi/aware/PeerHandle#hashCode()

The only NaN transmitter I have done any testing with, is the ESP32 implementation. It is quite possible that different transmitter implementations behave different and cause a (frequent?) change of this hash code. For the ESP32 transmitter, I have not done any long term testing to see if this happens.

BTW: You can see the value of the hash code in the detailed Info view for each device in the list. It is in the MAC field.

If the transmitter is following the standard, for NaN, it is mandated that message packs are used, so each ping should always contain the basic ID message. In theory, that would at least allow the app to detect that the hash code has changed but it is still the same transmitter that it is receiving from.

janusw commented 2 years ago

The only NaN transmitter I have done any testing with, is the ESP32 implementation. It is quite possible that different transmitter implementations behave different and cause a (frequent?) change of this hash code. For the ESP32 transmitter, I have not done any long term testing to see if this happens.

I see this both with the EPS32 implementation (from https://github.com/sxjack/uav_electronic_ids) and with other devices. In both cases the ID changes within a couple of seconds.

BTW: You can see the value of the hash code in the detailed Info view for each device in the list. It is in the MAC field.

Yes, the 'hash' simply seems to be a consecutive number. I see values like:

NAN ID: 119
NAN ID: 120
NAN ID: 121

If the transmitter is following the standard, for NaN, it is mandated that message packs are used, so each ping should always contain the basic ID message. In theory, that would at least allow the app to detect that the hash code has changed but it is still the same transmitter that it is receiving from.

Sounds reasonable. Without that, I guess it's basically impossible to get a longer 'track' from a NAN device (you would just see a series of single spots, each as a separate transmitter device).

friissoren commented 2 years ago

In both cases the ID changes within a couple of seconds. I don't recall it changing that fast. I might be wrong. Maybe the ESP32 SW has changed "recently"?

Unfortunately I won't be able to dive into the details of this any time soon. Getting all the SW components updated with the few changes from the final ASTM v1.1 specification will have to be done before anything else (as soon as I can find a spare moment for even getting that done).

janusw commented 2 years ago

Alright, no hurry here. I only wanted to raise the issue, since it had just occurred to me ...