Hallo Du!
Bevor du loslegst den Talk zu transkribieren, sieh dir bitte noch einmal unseren Style Guide an: https://wiki.c3subtitles.de/de:styleguide. Solltest du Fragen haben, dann kannst du uns gerne direkt fragen oder unter https://webirc.hackint.org/#irc://hackint.org/#subtitles erreichen.
Bitte vergiss nicht deinen Fortschritt im Fortschrittsbalken auf der Seite des Talks einzutragen.
Vielen Dank für dein Engagement!

Hey you!
Prior to transcribing, please look at your style guide: https://wiki.c3subtitles.de/en:styleguide. If you have some questions you can either ask us personally or write us at https://webirc.hackint.org/#irc://hackint.org/#subtitles.
Please don't forget to mark your progress in the progress bar at the talk's website.
Thank you very much for your commitment!

========================================================================



 The next talk is held by Beefy. He's already here and he is working in cartography. So he's building maps with the help of cameras. But he also likes to, well, repurpose things that he finds useful for other things. And that is also what he will be talking about. And this talk here, it's about Wi-Fi broadcast. So he will show you how to convert standard Wi-Fi dongas until digital broadcast transmitters give him a warm applause for his talk. Yeah. Thank you very much. Today, I would like to present to you my work on modifying Wi-Fi tunnels to serve purposes that they are not intended for by the Wi-Fi standard. And yeah, one example would be to do digital broadcast transmitters. But I will also mention some other examples that you could use them for and the way I intended. So coming to the contents, I will start with the motivation, because the obvious question is why would we even need to change something with Wi-Fi devices? Because we are using them all day. They're working quite well. This is true for the intended applications, but there are a class of applications in which the Wi-Fi standard well, failed pretty much. And this is what we will be addressing in this talk. Then after the motivation example, I will show you the basic principle and building on top of that. I will introduce some improvements that I introduce to make such a broadcast transmission really bullet proof. And finally, I will give you some usage examples to show whether it's really easy to use and also give you some real video footage that has been transmitted using this broadcasting scheme. So coming to the motivation. So my personal motivation and a rather good example of an application for this technique is if you would want to build a free open source first person view drone so this can be any type of drone. I just depicted here. Quadcopter could be land based on it doesn't matter. The important part is that this drone has a camera attached to it and light streams the video down to the ope
rator of the drone and the operator flies this drone only by looking at this life stream. So there's no direct line of sight to the drone. So reliability is really important here in this application. And I imagine all of you have an idea how you would realize such a system. And actually, even on first glance, it's pretty straightforward, like you would just add some Wi-Fi hardware to the drone. You would create an access point with this Wi-Fi hardware and then on the ground your laptop and you connect to that access point. Really simple. And then from the drone, you would send down the data, video data simply by GDP packets. And this looks fairly decent, right? It should work. And if you test it at home and then you will probably notice that it works really well and then you go outside to start flying, having the time of your life and suddenly, whoops, you've lost associate she Asian. And this means, of course, you as a operator, you're instantly blindfolded. And good luck trying to rescue your drone in that situation. Well, you might think maybe it's not about Wi-Fi usually automatically reconnects. And this is true. This might help. You might not help you. So the good thing about this is you can directly go shopping parts for a second drone because your first drone will have already crashed by now. So in summary, essentially association or state for connection is something you do not really want in this application. So and that's a problem of standard Wi-Fi because standard Wi-Fi usually uses association. That's another problem I am coming to right now. So I wrote here that we are using UDP packages and this seems to be like a smart choice because it's uni directional. So you just send data from the drone to the ground station and avoid all the hiccups of, let's say, a stream oriented product called select CCP. So data could queue up. You need to send acknowledgement up to the drone, which is of course not really something you would want to do. So UDP seems to be 
a good choice, but in fact it's not because under the hood like on a network layer seems to be fine. But on the Mac layer of Wi-Fi, there would still be data flowing from the ground to the drone in the form of acknowledgements. So Wi-Fi users acknowledgments and so. You actually need to acknowledge the package from the drone. And so you have required upstream from the ground to the drone. And this is obviously something you would not want to have because then you rely on two links to be working perfectly to just to get the data from the drone down to the operator. And that's another disadvantage of this bi directionality, which is actually the term of the problem. And that is that you ideally, ideally want to have asymmetrical setups. So what would you do to increase the range of the setup? You would, for example, install a power amplifier on the drone side so that the data gets spread further. But with a standard Wi-Fi, you would need to have the same power transmitter. Also on the ground station, which is again, pretty pointless. And so by directionality is a problem. Standard Wi-Fi. There are a couple of other things. So Wi-Fi has some automatic control mechanisms like, for example, transmission rate control. So if the two devices are well at a certain distance, the signal received signal strength, of course, drops at the receiver and thus triggers a mechanism that throttles or dials down that transmission data rate on the transmission side. And this happens automatically. This is not under your control. And so imagine you are trying to send a 10 megabits per second video sync, though, and suddenly the card decides to just switch to five megabits per second. Result will be data will queue up on the drone length at sea will increase your crush. Same problem. That's also automatic power control, which makes sense and standard Wi-Fi because you want to limit the interference between close by networks. So you just send with the, let's say, minimum required amount of 
energy. But since you rely so much here in this application on this link fully working at any time, you do not really want to have it. You want to use always maximum power. In that case. And lastly, you have no signal degradation in standard Wi-Fi. So standard Wi-Fi use a CRC check sums and it just either delivers your package that have matching checksum or no packet ship packets at all. And this is a problem because let's just assume you fly further and further away from the ground station and at a certain point the video feed will just stop because FiOS CFC checksum will turn bad. And this is actually almost that crash guarantee again, because you have no warning upfront. It's just like and it's it's off. And actually what you want is you want to see the transmission errors. This gives serious good hint that it's maybe time to turn around and then you still have enough visual feedback to actually control the drone to move around. So signal degradation, again, not possible in standard Wi-Fi. And, you know, this is kind of the motivation for me to kind of flip things upside down a bit. And now we are coming to the basic principle. It's actually quite simple. So, you know, in standard Wi-Fi, you have the device classes, a station like an access point where you connect to enter device that connects to this access point and Wi-Fi broadcast. The modes in which the devices work have been renamed by me. So they are simply a transmitter and a receiver. And their hardware used for that is just plain standard Wi-Fi. Donald's eight years per piece. So it's pretty cheap. And from this same mode name. You can already infer that it's a truly unique directional data flow from transmitter to receiver and these devices work in injection mode and the transmitter, Kate. So basically you send consent with that mode, arbitrarily shaped package into packages into the air without any association and the fever runs in monitor mode, meaning it will pick up every packets that are floating, 
all the packets that are floating around in the air and with an appropriate filter. On the civil side, you just get the packets from your transmitter, and that's already established. A very primitive but surprisingly good working link that does not share all the problems of standard Wi-Fi that I mentioned in the previous slide. In theory, this is super easy to do. The API is for these special modes like injection mode and monitor mode that already can just use them implemented in a couple of lines and your you should be good to go. In reality, the injection site is quite a take, quite a bit more complicated than anticipated because we're basically leaving here the domain of standardized Wi-Fi and ah, well, hacking, fiddling somewhere outside of the standardized domain and you have no guarantees how the hardware will react and this non standardized way. So one problem I discovered was low injection rate. Many chips chipsets I tested really had a terrible injection rates like in some cases in the order of 1 percent of the outer a rate. I could only get through that. So this was pretty bad. I solve this by just selecting good chipsets in a way. Then many of these drivers and formulas I tested ignored quite crucial parameters. I requested them to obey too. So for example, takes power. I found many adapters ignoring this. This is heading and just sending at a low minimal power value, which is of course not what we want, but a simple dirty. And don't look at the actual lines. But it's just a couple of lines. Kernel drive a patch. Fix that for me. Even more importantly. Some devices ignored data rate requests, so I requested to send a packet that, I don't know, 54 megabits per second and these drivers were always sending the packet at 1 megabits per second, which is not enough for video, for example. Luckily, there is one specific wife I don't know that I showed in the pictures earlier that has open source format so I can download that former compiled it, flash it onto the
 Wi-Fi card and actually again, to have control over the data rate. It was just a one line change in the former and I could specify exactly the transmission parameters that I needed for my project. Now, with all the troubles fixed, so to say we again back at this basic simple scheme and this works already quite well. So if you install this on your drone. There is no pro problem flying around couple of hundred meters with such a setup without any special ingredients like amplifiers, big antennas and so forth. But my initial motivation for this project was more to explore the world from a bird's eye perspective. So a couple of hundred meters didn't really cut it, so I wanted to increase the possible range by by any means. And one of these means is to just add more of these cheap downloads on the receiver side can just put them in there and this will then enable you to do software diversity. And at first glance you might think, well, this looks not really helpful. We have three times receivers that receive the same data stream from the receiver. So we will have only three copies of the same data at hand. What what should we do with that? In reality, this actually helps quite a bit. And the reason for that is that in reality, you have multiples interference. So starting from this oversimplified transmission trench mission scheme, you will never encounter such a transmission here on earth, maybe in space, but here on earth you have other objects that cause reflections of the signal and these reflections will interfere at the receiver side either constructively or destructively. And it's simply pure, pure chance. Whether you work out a constructive or destructive interference and by placing several receivers at different locations, you basically can twist the bits, the shape of this triangle here. And this basically helps you to get a better chance that at least one of the receivers will not suffer from destructive interference. And actually, in reality, this really helps
 a lot. There are other cases of the software diversity. For example, you could use that to realize that internal diversity. So. Typically, if you look at these black and here, these are omnidirectional antennas giving you 360 degrees coverage. And this was already good starting point, but with antenna diversity, you can add different antennas to different receivers. So, for example, you could add to the three and a 60 degrees antenna at a very high gain. Long range directional antenna, if you know. Well, I'm just flying in that direction. Long range. You can just combine the antennas depending on your needs. And if you really invest a bit more, you can just use lots of directional long range antennas and realize, well, let's say an antenna. That's really not feasible to do with just antenna magic. Electronic means. So to say and certainly use case, of course, you can increase the special coverage. So there are situations like this top down view scenario where you have inclusions which the transmitted signals cannot pass over. And in that case you can simply place several receivers at different locations. And the software will automatically fuze the signals from these receivers so that you get in the end only one logical data stream out of that which does all the handover stuff and everything automatically from one stick to another. Let me quickly explain to you how this works. It's quite simple. So we have here an example. It's three cards and four packets of rice all, of course, consecutively. And that's just imagine Card 0 received a package with the CSIRO. So that's something wrong? We don't know exactly how much. At least one bit seems to be flipped, but could be not really severe. Could be really severe. We don't know. But the other cards received good packets. So we just pick one of the two greens and we're fine and have a good package here. Received a packet. Two might be good, uncut, zero CSIRO on count one, for example, and it might be completely missing f
or cut too. So in that case, of course, easy choice. We pick the green one, which is fine and we have a good packet in the end. Now packet two might have a C or C completely missing. And again, the CFC. So what would we do here? Well, it's a tough choice, but the best thing we could do is to pick one off the packets with the CSIRO, maybe prefer preferably the packet with the higher receive signal strength. But besides that, that there's not much more we could do and packet three might be missing on all of the cards. And this typically happens when you have some external interference, like someone switches on the light, creates a spark and this destroys the reception on all of your receivers. And again, there's nothing we can do about that. Now, taking this combined stream of packets, this is, of course, not satisfactory. So this is still better than one card, but there are still some artifacts. And how could we deal with this? Well, simply by adding forward error correction to the data and the way I implemented it is actually quite straightforward. So to these payload data packets, I simply at forward error correction packets, two or more configurable depending on on your needs and on your link quality. And of course, now for the first two packets, there's nothing to be done. They are good. All right. And now we are dealing with the broken packages and we start with the worst case, which is the missing packet. We have no data at all here. So we can now or we should start with that one until we apply the first FCC packet to the missing packet. And you can think of these FCC packets as well, Joker cards. So to say so we can recalculate. One of the data packets by using this FCC packet. So this want to see a step and from that we could reprocess the original value of this packet. And of course, we will then do the same thing with packet 2 and. We have a good data stream again. Of course, this was known the optimal example. In reality, you sometimes have situations wher
e you used up all FSC packets before you repaired all data packets. That can happen if that happens too often. You should just dial up the number of FCC packages and you should be good again. All right. So this was the basic principle. And now I'd just like to show you some usage examples of the tools that I developed that realizes this transfer mode. So first, the artificial example is simple file transfer. So we first start the receiver because we want to capture all packages from the transceiver and not start in the middle. And this simply works by starting this our X program. This is part of the Wi-Fi broadcast software and you just specify the Wi-Fi adapter that it should use. And in case of software diversity, which just lists several adapters and it would automatically medically do the soft diversity under the hood. And what this does is basically all the data it receives will output on LCD out and you can pipe this into image matrix display program on the transmitter site. It's the same and inverse. So you just output something to LCD out file. In this case, gif file of a drone and pipe that into the TV program of Wi-Fi broadcast. And it's as soon as you execute this command it will be sent out into the air and picked up by the receiver and subsequently it is played by magic. So pretty simple, but like I said, artificial setup. This is now an actual example that I'm using, for example, on my drone. So to transmit the video. So as a as a pussy, I'm using a Raspberry Pi on it, just sitting on the drone and I start this command. So this looks a bit more complicated, but it's actually fairly simple. So the first part of this from here to the pipe, simply a standard Raspberry Pi tool that outputs H2 6 compressed video data on a study out. And again, you pipe that into the T X program and it will immediately be sent out into the air. There's no need to have any receiver enabled. It will just be emitted. India. There's another alternative. So if you do not want to 
use a Raspberry Pi, you could simply use the G string API call, which it's pretty much the same thing. So you capture from a very forgiving device compress it's two to six four and then output it to standard output and pipe that until the 26th program on the receiving end. You can do. Again the same in reverse. You use the arcs program, pipe that into G in the pipeline and display that image onto a screen. And this is already a set up that is able to fly for you pretty well. Now, Wi-Fi broadcast is actually agnostic to the data transport. So it's it's just your pipe data in and it falls out on the other side of the channel. So to say that this on its own, it's not very useful. And therefore, I developed some components that kind of complete the drone application. And one thing is, for example, I created Raspberry Pi image that you can simply burn onto two SD cards. You put these into your are except to use to express berry pie and switch them on and you have a video link running. So that's quite nice. And they are excited yet. Also, support for recording. So if you're just at UCB, stick to the Raspberry Pi, you will automatically record the video of the transmission. I also developed what's the sense for on screen display? It's a overlay onto the video that shows some telemetry information off of the drone like battery status and so forth. And I also plotted everything to Android. This was a bit more complicated than anticipated just to give you some impressions. So this is what you could mold onto your drone. Raspberry Pi 0, pretty small device weight, only a couple of grams and you get the camera ready for Raspberry Pi Foundation with it. And yeah, that's a pretty good drone setup that works even on the tiny. They are excited. So this is now my clumsy, self-made setup on the left, you see my video goggles that are cut out of some foam piece in the middle of the blue things, the battery, and on the right, the gray box is a raspberry pi. And the white thing is, of c
ourse, the Wi-Fi receiver. And this was quite a nice setup. So I have the components in the pockets of my jacket, goggles on my hat, and this is enough to fly around. This is an example of the LCD display. He see basically everything that might help you to safely get your drone back home like received signal strength, battery status, artificial horizon, a distance to your home and so forth. And we will see other examples of this in a second. This is a self captured screenshot of my Android port. So the Wi-Fi broadcast camera looks onto the tablet and the tablet shot a screenshot. And so you see the scripts that this nice recursive tunneled again wife, I don't know, connected to the Android device. And this was quite a bit nastier than expected because I needed to recompile it with the Android kernel because it didn't support, of course, the wife. I don't know. Then I need to run Y2K broadcast in a changed food environment pipe that internet cat which since the UDP packets to local port. And then on the android side I had an app that received data from the local port decodes to the H2 6 4 and displays it on the screen. So it's not exactly user friendly, but it works. So as the conclusion of my talk, I would like to show you a recording of a long range video. Transmission hasn't been done by me, but some other crazy to. I would say so. What you see here is again the old steam display and the video in the background is actually recorded on the ground. So this is the actual life footage that the drone pilot will see and use to control his drone. Yeah. So this is a fixed wing drone. You see here it accelerates to takeoff and now we're in the air. And in a couple of seconds, we should see the antenna of the drone, which is nothing special. It's just here, this gray stick, which is a standard omnidirectional antenna. And now if you take a look here at the bottom of the series, the distance to the operator, that's. And as you can see, it's crystal clear video. In this case,
 I think it's 720 P.. And this is really quite, quite a nice visual input for you to control your drone. Yeah. All right. I think I will. Let's let this running during the Q and A session. Thank you very much. And I'm happy to take your questions. Quite impressive indeed, sir. Thank you very much, Betty. Questions, please, to the microphones. We have one, two and three. So come to the microphones and we have a question on the Internet. But we start with microphones. Thank you for your talk. You said that there would be graceful signal degradation. But can you also display the connection quality, for example, by how many FCC packets did I have to use? I'm not doing that one. But there's something similar. Like if you look here up, that first number is the number of data blocks that could not be recovered by fully by FCC packets. So, yeah, I'm just wondering why this here isn't increasing, but yeah. So this gives you already quite a good indication. But I think your suggestion is also a good idea because it was the trigger earlier than this one. So yeah, that would be certainly helpful. OK, thanks. Maybe the question from the Internet, please. There's a practical question. What is the name of the wife, Donna? You knew you used. So I used to this. Let me switch back to the picture here. So this white thing here is called T L Dash W N 7 2 2. And if you buy this one, make sure to get the first revision because the later revisions redesigned the whole interior thing of the chip and of the dongle and to use a different chip microphone one please. I'm totally blown away by the kind of range that you get there, because the implication is that with essentially consumer hardware, if you go into the air, you could eavesdrop wastelands over a hundred kilometers. Is that what you're saying? Well, the setup is asymmetrical. So the standard antenna that you saw in the beginning of the video that wouldn't have a 100 km range, it's only directional antenna. And this one is observed o
n the ground with a high gain directional antenna. So it would only work if you would install this high gain directional antenna on the aircraft. But in that case, you're totally right. You could observe Wi-Fi alarms from 100 kilometers probably. Right. Number three, please. I'd like to know which technology used to filter the packets from the receiver side. So you might sniff everything. Once you are in the monitor mode and I'd like to know what to do goes you're using to filter them. Only the one from the video. That's PPF. So the packets I'm using have well, specially crafted MAC address and I'm just applying a PPF onto that and this will do the trick. And yet there is also support. So for example, the telemetry is also sent of course with Wi-Fi broadcast and Wi-Fi broadcast house concept of ports to have through streams in parallel. And there again PPF filters used to separate the streams. All right. Number two, please. OK, hello. So one of the biggest implications in SPV flying like that, the biggest deals for like extreme or quick flying is the delay you get on the video. So how does your digital video really clear and sharp vision compared to the analog SPV we like had for many years. So what's what's the difference? Because I assume it's bigger. It is indeed. So I have an example here. This is what you get from analog SPV, quality wise, latency wise. This is, I think roughly 40 milliseconds Wi-Fi broadcasters with the Raspberry Pi in the 100 millisecond range. So it's quite a bit slower than analog. But actually Wi-Fi broadcast is not the cause of that. It's more the video compression. So Raspberry Pi uses, let's say, frame based triggering like you receive an image from the camera and only once it's completely there. Subsequent steps will be triggered and ideally you would kind of more pipeline the processing like. Start already when the first picks it's at right to process them. Unfortunately, with Raspberry Pi, the not possible because the video compressi
on is close toss, which is a bummer and to the state, I have not yet found a better alternative that gives slower latency. I looked around quite a bit and the only thing that would get better low latency would be custom hardware like in the sense of where you have full control like an FPGA thing. But I decided not to use this because Wi-Fi broadcasts should be approachable, like should just go buy an online shop of your choice. Cheap components assemble everything and you're good to go and FPGA stuff, but too special for that domain. OK. Thank you. And another western you've shown on the slide. The Rust B 0 W.. So you said it's only the rust behind the camera. But I assume you're not using the built in Broadcom Wi-Fi chip. You're using that the building, right? Correct. Right. Yeah. Thank you. Okay. Next question number two. Okay. Yeah. Thanks for the great talk. I also recognized the USP Wi-Fi dongle. I have one myself and I was thinking. The author of Chip. The first hardware revisions to manufacturer are just risks to be purchased. Actually, I haven't bought them for a while, so I don't know how. If they are still you can still get them because if you go to a shop now where you don't get this device anymore. Okay. There are some other alternatives. So for example, in the 5 gigahertz range, you you can also use other chips. There is a link on my block. It's linked to to this talk. If you're interested in that. And actually it's worth mentioning, if you're in attempt to use this for drone applications, there are, I think, three or four forks of Wi-Fi broadcasts already. That just extended the scope of functionality by, I don't know, orders of magnitude. So you should also check out definitely these folks. So they are pretty well. Thank you. Okay. Next. Yes. Thank you for your talk. It was impressive to get an idea with our signal for 10 kilometers. But one question is how do you control the drone? It's not the direction of your communication would interest me. So y
ou can use Wi-Fi broadcasts for that as well so you can run both the arcs antiques instance of Wi-Fi broadcast on the same dongle in parallel. That works, but I personally am a big fan of having the highest possible reliability on the control channel. So for that I use frequency hopping transmitters like you can buy for RC from US vendors and these are really almost indestructible. Well, they interfered with the transmission. Sometimes, but there are ways around this. But yeah. How's reliability for control and then. But below that for video feedback, that's just my personal gut feeling. OK. Thank you. Thanks. And our last question. Hi. Regarding the error correction, you've shown that if you use one of the error correction packets, you can use it to restore broken wall or even a missing one. Now taken you have two broken ones. Did you check in would be feasible to use these both and apply statistics to check if you can reconstruct it. So you mean I have two broken meaning that your C packets? Yep. And two FEC packets. Yeah. And basically if you can use the ones with the broken CRC and don't use it for their correction once. Okay. No I didn't do that. I'm so sorry. I have no for the day. Thank you. Thanks. Okay. And that last question. Okay. So here's the last one. With traditional analog video, you have the possibility of choosing a channel that you want to transmit on so multiple people could fly at the same time. You mentioned before that then Viper broadcast. There's this notion of part two separate different streams. How many ports could you currently support? Like how many drones in the air can independently strip supported? And is there the possibility of having more or less parts if you limit bandwidth? So indeed, if you limit bandwidth, you can transmit more in parallel. I wouldn't recommend to use ports to fly drones in parallel because one of their drones might not play nicely and use up more bandwidth. And then you have a problem. So I would rather recom
mend to use Wi-Fi channels to separate these. And actually the white wife I don't know. I've shown it is quite capable. You can even teach you its to transmit and two point three gigahertz. You shouldn't do that, but you can do it. Okay. Thank you. Okay. Thank you. Vivian, the warm applause for you again.