Differences

This shows you the differences between two versions of the page.

--- searchwing-wifibroadcast [2020/04/15 09:57]
wf68spef created
+++ searchwing-wifibroadcast [2021/04/19 13:03] (current)
swrm [Mavlink-Transport]
@@ Line 3: / Line 3: @@
 WiFi Broadcast has great potentials as link layer between the drone and the ground station. As well as link layer for video data created on the ground, e.g. between the speedboats and the mothership.
-We tested the original WiFi broadcast implementation on a TL-WN722N with a patched driver. We did tests in the noisy Berlin environment and reached a throughput of 8 to 20 MBit/s.
+We tested the original WiFi broadcast implementation on a TL-WN722N with a patched driver. We did tests in the noisy Berlin environment and reached a throughput of 8 to 20 MBit/s on a table setup.
 There are various projects that use the WiFi broadcast code:
+  * [[https://github.com/svpcom/wifibroadcast | svpcoms wifibroadcast]] most promising implementation feature wise
+  * [[https://github.com/booo/openwrt-wifibroadcast | OpenWRT package for wifibroadcast and a custom implementation of wifibroadcast]]
   * [[https://github.com/rodizio1/EZ-WifiBroadcast|EZ-WifiBroadcast]]
   * [[https://github.com/OpenHD/Open.HD|Open.HD]]
@@ Line 12: / Line 14: @@
   * ...
-The original implementation doesn't care much about the transmitted data. You can pipe whatever data you have to the tx process. Some of the mentioned implementations provided MAVLink transport, others provide a UDP interface.
+The original implementation doesn't care much about the transmitted data. You can pipe whatever data you have to the tx process. Some of the mentioned implementations provided MAVLink transport, others provide a UDP interface. For example in theory its possible to transmit a 4k video stream via H265 using a Jetson Nano Board: https://befinitiv.wordpress.com/2019/04/29/fpv-in-4k/
 The code for injecting packets is quite simple and can be adapted to our needs, e.g. improved forward error correction.
+===== Ath9k =====
+The code should work with all drivers that provide a monitor mode to inject packets. We tested the code on a Atheros AR9280 Rev:2 mini-pci card. Setting the bitrate with iw:
+iw wlan0 set bitrates legacy-2.4 5
+Result was an injection rate of around 12 MBit/s in the nosy Berlin environment.
+**We don't need a patched kernel to set the bitrate!**
+[[https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/debug#manual_bitrates_configuration|Manual bitrate configuration for ath9k/10k]]
+===== Mavlink-Transport =====
+* optional: Simulate FC-MAVLink-Data on PC - using  Ardupilot SITL on UART output:
+see [[https://www.hs-augsburg.de/homes/beckmanf/dokuwiki/doku.php?id=multicamera_pixracer_connection#sitl_computer_simulated_pixracer_pi4|SITL]]
+* Pi Sender: Send data via wifibroadcast from Serial input port data - Mavlink Data from FC
+configure UART using for 9600 Baudrate (or checkout your telemetry for correct Baud):
+''stty -F /dev/ttyAMA0 9600''
+Send data:
+''./tx wlan0 < /dev/ttyAMA0''
+* Groundstation station receiver side: Receive wifibroadcast data and pipe into QGC:
+''sudo ./rx wlp0s29u1u2 2> /dev/null | nc -l 5000''
+* QGC: New connection with TCP on Port 5000 - receives telemetry
+source tx and rx commands: https://github.com/booo/wifibroadcast/ ?
+==== Mavlink Routing ====
+Captured data needs to be sent from companion (connected to fc) to gcs.
+On the companion there might be also ROS needing access to mavlink messages.
+On the gcs side the sent data needs to be handled. QGroundControl can't handle that captured data -> needs additional software.
+Routing of pakets (ros|captured data processing)<*>companion<->fc<->radio<->gcs<*>(qgroundcontrol|captured data processing)
+- <*> routing to multiple endpoints
+- radio is long distance rfd868 or similar
+Parallel to the radio connection there might be a long distance wifi connection.
+(images|captured data processing)<*>companion<->wifi<->gcs<*>(qgroundcontrol?|captured data processing)
+open question: route (encapsulated) mavlink pakets also over wifi?
+depending on that: combine of images / captured data on gcs side - how?
+==== Captured Data Workflow ====
+TBD.
+===== Tests =====
+  * 20MBit/s in the basement in Neukölln, distance 50cm, two omni antennas with unknown dBi
+  * 4MBit/s on Tempelhofer Feld, distance ~ 200m, unpatched kernel, txpower maybe not at max, both sides small omni antennas with unknown dBi
+  * unkown MBit/s, max. distance ~ 1km, esp 201 with 1-3dBi omni, ground station Nanostation M2, unknown tx power on both sides, normal wifi, no wifibroadcasting
+  * [[https://www.hs-augsburg.de/homes/beckmanf/dokuwiki/doku.php?id=searchwing-flug-107 | Testflight with 8XX MHz]]
 ===== TODO =====
-* test in realistic environment, e.g. noiseless sea env
+  * test in realistic environment, e.g. noiseless sea env
-* range test
+  * range test
-* test antenna combinations, e.g. dipol and sector, dipol and dish
+  * test antenna combinations, e.g. dipol and sector, dipol and dish
-* implement tun/tap over wifibroadcast
+  * implement tun/tap over wifibroadcast
-* ...
+  * ...