Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/1334 Thanks!
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 operator 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 for
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 where 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 course,
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 on 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
compression 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 you 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 recommend
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.