WiFi NAN, bug fix transmit on channel 6, set to random MAC address

[BluemarkInnovations]

• existing code was transmitting NAN packets on channel 1. This should be channel 6 for NAN packets. Both verified with a wireshark capture
• changed the device MAC address to a local generated MAC address. This would have two benefits a) you can't track a transponder based on the MAC address b) related, typically the original MAC address is considered to be a privacy sensitive information element. So, using the original MAC address may cause issues with existing privacy laws (if you capture them by receivers). Using a local generated MAC address at every boot of the transmitter solves this.

[friissoren]

Nice. This makes the NaN reception work for me on a Galaxy S10 using the Open Drone ID application. I had been wondering why that didn't work earlier.

The reception rate is very low though (anything from 10s to several minutes), which appears to make the Android driver layers think that the NaN transmitter is a new one almost every time it finally do get a ping received, resulting in a large amount of drones showing up in the list view (there is already an issue filed to request doing something about this).

Changing the transmit interval to ~200 ms seems to greatly improve on this. Can be fixed in RemoteIDModule.ino by removing the if clause around the call to wifi.transmit(UAS_data). If you don't include that in this file I can make a PR for that.

[BluemarkInnovations]

Changing the transmit interval to ~200 ms seems to greatly improve on this. Can be fixed in RemoteIDModule.ino by removing the if clause around the call to wifi.transmit(UAS_data). If you don't include that in this file I can make a PR for that.

I need to discuss with @tridge. A few users already did report some interference. (That seems to be solved in the latest version, nevertheless increasing the number of transmissions, will potentially increase interference to other systems.) So perhaps we need to make it an option.

[BluemarkInnovations]

@friissoren It would also be interesting to know if the NaN beacon interval setting (I mailed you about), would make a difference in reception experience. Perhaps setting it to the correct interval value, will help too.

@tridge there is some field in the NaN packet that specifies the beacon interval rate for NaN packets. The current OpenDrone ID lib sets it to fixed value of ~0.52 seconds, whereas ArduRemote ID emits at 1 Hz. I don't know if this value should be adjusted and if it would make a difference in reception experience.

[friissoren]

A few users already did report some interference.

Yes. I would actually suggest that we disable NaN by default and leave only Bluetooth.

About the beacon intervals, that is not completely clear to me. I was not aware of this one that you pointed out in the email. Need to check whether that is even applied?

I tried to set wifi_config.ap.beacon_interval in the WiFi_NaN::init function but that didn't really seem to have any effect. I guess the esp_wifi_80211_tx function just triggers a single transmit ping and therefore calling it more often helps? Needs more investigation.

It would probably be a good idea to get this PR merged, just so the NaN actually starts working and then worry about the intervals in later PRs.

[BluemarkInnovations]

About the beacon intervals, that is not completely clear to me. I was not aware of this one that you pointed out in the email. Need to check whether that is even applied?

FYI changing this line in my own code, did result in a correct interval value in the captured NaN packets. If you change 0x200 to 0x3E8 i.e. ret = buf_fill_ieee80211_beacon(buf, &len, buf_size, 0x03E8); The beacon interval should be 1 s.

[tridge]

@BluemarkInnovations thanks!
I've done a bit of cleanup to have a common generate_mac_addr function in a parent class for BT and WiFi