Add DJI drones and Dronetag Beacon to transmitting devices

[lukasbrchl]

Following up at #53 where I discarded DJI drones from the list. We have now retested with the latest firmware and I can confirm the following.

• DJI Mavic 3 and DJI Mini 3 Pro support Wi-Fi Beacon
• DJI Matrice M300, M30 and M600 don't support anything yet

However, the implementation on the DJI side seemed quite weird to me. Even though I disabled Wi-Fi throttling in developer options, I was getting one message per ~30 seconds most of the time. I also was quite surprised about the range which was below 500 meters.

I recorded a simple video showcasing DJI Wi-Fi Beacon implementation on my smartphone OnePlus 8T in the countryside. The device starting by 1581 is Mini 3 Pro and the one 1596 is our Dronetag Mini for comparison.

https://user-images.githubusercontent.com/18639856/176988862-7b0e6c15-3708-4d2c-8eab-e96e2af49251.mp4

[friissoren]

There seems to be a bug with the open street map implementation that it doesn't auto update the red trail showing where the drone is flying until you manually zoom the map. I will open and issue for this.

[janusw]

* DJI Mavic 3 and DJI Mini 3 Pro support Wi-Fi Beacon

I'm slightly surprised that the Mini 3 is supported as well. It won't be required to transmit Remote ID in the EU (but in Japan). I also heard that the Air 2S received Remote ID support with a recent firmware update, but only for Japan.

It may be that DJI's implementation transmits only in some regions (depending on where you fly).

However, the implementation on the DJI side seemed quite weird to me. Even though I disabled Wi-Fi throttling in developer options, I was getting one message per ~30 seconds most of the time.

This matches my general experience with most WiFi transmitters (when receiving on an Android smartphones): Updates are slow and irregular (both for NAN and Beacon). The best I have seen is the Parrot Anafi, which provides regular updates every 2.5s.

I wonder why the ASD-STAN whitepaper quotes a "high" update rate for WiFi NAN (it's not clear what "high" means after all, but from what I've seen it's usually much lower than BT).

I also was quite surprised about the range which was below 500 meters.

I'm not so sure if it's a good idea to quote ranges on the transmitter page. They are tough to measure precisely and depend on a number of factors (including receiver device and environment). Maybe the update rate would be a better quantity to be included on that page?

[lukasbrchl]

I'm not so sure if it's a good idea to quote ranges on the transmitter page. They are tough to measure precisely and depend on a number of factors (including receiver device and environment). Maybe the update rate would be a better quantity to be included on that page?

In normal circumstances, I would completely agree with you. However, we have tested those drones among 10 different smartphones + tablets and the range was poor on all of them. BUT, the refresh rate varied significantly - some devices didn't get any message in 2 minutes, and some of them got it more frequent (~30 seconds).

I don't defend the added range there, I just wanted to point out that there is definitely something weird in the current implementation. Or we just had really a bad luck with 10 receiving devices...

[lukasbrchl]

Btw, the best reception of any signal was so far on my phone OnePlus 8T. Here I am able to receive Bluetooth DRI from Dronetag Mini to up to 2.6km.

[janusw]

I'm not so sure if it's a good idea to quote ranges on the transmitter page. They are tough to measure precisely and depend on a number of factors (including receiver device and environment). Maybe the update rate would be a better quantity to be included on that page?

In normal circumstances, I would completely agree with you. However, we have tested those drones among 10 different smartphones + tablets and the range was poor on all of them. BUT, the refresh rate varied significantly - some devices didn't get any message in 2 minutes, and some of them got it more frequent (~30 seconds).

I don't defend the added range there, I just wanted to point out that there is definitely something weird in the current implementation. Or we just had really a bad luck with 10 receiving devices...

Well, I don't actually doubt your results.

I assume that the bad reception range is, at least partly, caused by the low update rate: If you get several updates per second, it's not a problem if some of them are lost, but if there is only one update each minute, and you may even miss some of them, then you're almost receiving nothing at all.

And I somehow start to get the feeling that these bad WiFi rates are a general problem, not just a peculiarity of the DJI implementation. I'm not aware of any device that provides WiFi updates to an Android smartphone with a rate of more than 0.4 Hz (this value is what I get from the Anafi - and I'd consider that as rather low already).

In fact the ASD-STAN standard requires an update rate of at least 1 Hz for the dynamic messages (see chapter 5.6), and it requires this to be achieved on a "mobile receiver device" (see chapter 4.5).

AFAICS neither the Anafi nor the Mavic 3 actually satisfy this requirement, right?

[friissoren]

The standards only specify the rate on the transmitter side. There are no specific requirements for the receiver side rate etc. because it depends on so many variable things.

[janusw]

The standards only specify the rate on the transmitter side. There are no specific requirements for the receiver side rate etc. because it depends on so many variable things.

True. I also looked it up today.

Still I find the current situation with DRI over WiFi quite unsatisfying:

• iOS / MacOS do not support it at all.
• On Android, you need to enable developer mode and disable scan throttling, in order to get reasonable reception rates.
• Even with scan throttling disabled, there seem to be device-specific limits on Android, which often throttle the rate to fractions of a Hz. I have been testing a couple of phones and none of them reached 1Hz (the best one was 0.4 Hz, tested with an Anafi as transmitter). **

Having rates as low as 1 msg per 30 seconds, as reported by @lukasbrchl for the Mavic 3, is really pretty bad (compared to the 1Hz promised by ASD-STAN). I wonder if the requirements in the standards shouldn't be tightened a bit, otherwise DRI might not be very useful in practice.

** Maybe this device dependence should be documented by adding the WiFi reception range to the list of supported smartphones?

[janusw]

However, the implementation on the DJI side seemed quite weird to me. Even though I disabled Wi-Fi throttling in developer options, I was getting one message per ~30 seconds most of the time. I also was quite surprised about the range which was below 500 meters.

Could the bad range possibly be caused by the drone transmitting in the 5 GHz WiFi, which has smaller range than 2.4 GHz?

@lukasbrchl Do you have the possibility to check the rate at which the device is transmitting (as opposed to the rate at which Android receives), e.g. using a laptop with WireShark? And maybe also check in which WiFi band it is transmitting? That would be very helpful, in order to judge why the DJI devices are performing so bad.

[lukasbrchl]

Yeah, we could do that. I think we will do some short article about it or a hands-on video. I think we will have time for this in early August.

[janusw]

Cool, that would be great. (I'd do it myself, but I currently don't have access to these DJI drones.)

If there is anyone else with access to a Mavic 3, who can help to clarify the reasons for the bad performance, please chime in ;)

[friissoren]

Still I find the current situation with DRI over WiFi quite unsatisfying

The issues you list are valid and were known already during the standardization. The problem was that there was a very clear requirement to be able to receive the signals on commonly available devices (= smartphones) and many existing drones are already using Wi-Fi for controlling the drone, so there was a clear desire to be able to re-use this radio interface without having to add additional HW. The NaN and Beacon methods were the only identified options that would fit these requirements.

Since the typical design goal for a smartphone is to save power, they are not continuously scanning all Wi-Fi channels, even with the throttling disabled. There is still a possibility that Google could implement an API specifically for remote ID that would allow more consistent reception rates. And we can only hope that Apple at some point also will see the benefit in supporting reception of remote ID signals (they do have a tendency to do things their own way). Let's see what happens once remote ID becomes fully mandatory in the US.