Look at that moon up there.
It's so pretty.
It's shining.
I really like the moon, but I don't like the moon anywhere near as much as this thing right
here.
This is an ESP8266.
It is a uuh a little computer all on a chip.
It's got Flash and RAM and a processor and everything in there, but that's not it.
It is also able to connect to Wifi.
For about $2, these little guys can be installed in just about anything from your toaster to
your fridge to well, I don't know, I'm sure we're going to invent new appliances soon,
now that we know these things exist.
Right here, though, I am currently in my front yard.
And you might be thinking "oh, look charles, it's night time - that's probably not good
your neighbors will think you're strange."
My response to them is "that's okay, because you know what's more important than not looking
strange?"
Science.
Hello, neighbors!
Ok now I can see a little more clearly.
Hello, neighbors.
In my front yard here, I have several of these ESPs set up in a pretty much precisely arranged
set here.
Now, it's not so much that the arrangement matters, but that I know where all of the
ESPs are.
Ordinarily, the ESPs are designed to connect one and really only one thing.
Whether it be another ESP, or in this case a home router.
They ordinarily will just connect to one, but these ESPs are running special firmware
on them.
These ESPs can actually communicate to one another while they're connected to that home
router there.
But wait!
I thought ESP-NOW allowed ESPs to talk to one another while connected to a home router.
Well, that's sort of true, except with ESP-NOW, you have to know which ESPs that are not part
of the network you're going to be communicating to.
There's really no general system for broadcasting to all ESPs nearby while you're connected
to an AP.
So, now, while they're connected, they can also communicate directly from one to all
of them.
They can transmit a sort of message saying "Hey!"
You might as "what does that buy you?"
I have a custom interrupt handler written on all of them and that custom interrupt handler
will tell me the exact time to clock processor cycles which work out to somewhere in the
order of ummm about 1/160 millionth of a second.
Now, it's not perfect, there's a little bit of jitter on it.
But, it can tell me exactly when a packet was received.
I'm trying some things to see if I can tell when packets were sent, but I can tell mostly
when they were received.
I'm trying some things to see if I can also tell when packets were sent, but, I care mostly
about when they were received.
If that guy right there sends a message to that guy, that guy, that guy and that this
guy, well then I can correlate the times.
I can know that when each of these received that packet, I can then back out based on
that thing from the distance from that thing to the sender, based on the speed of light,
what time, exactly all of them had on their local oscillators when they received their
packets.
Now, once a packet is received, then they can be sent back through normal wifi directly
here to my laptop.
Ok, so here is just a massive list of all of the known transmitted and received little
note packets along with the precise time that they were received at.
Now, we can take all of this data and uuh hopefully, I don't know it's going to be a
little more effort to figure out what to do with it, but, take all that data and correlate
it and hopefully and we'll be able to take this and validate a model.
A model for where all these ESPs are.
If we can validate the model for where all these ESPs are, then we can use all of these
ESPs for triangulation.
Now, a lot of other people have thought "you should be able to do triangulation based entirely
off of Rx and Tx power - excuse me - Rx RSSI" And, that's not entirely true.
Based on a video I made where I learned a lot about this topic, umm, the RSSI changes
dramatically over even a very, very small space.
So, it's very hard to use the transmit/receive power to tell much of ... anything.
But, this system here uses time of flight.
And hopefully, hopefully, we'll be able to use time of flight to determine localization.
One other interesting thing is even if we can't determine localization with that, we
can still also get the rx and tx power as well.
So that's what the second column is here.
The RX and TX power.
So here I have the IP address of the receiver, the MAC address of the sender, the MAC address
of the receiver, whether or not it's a receive or transmit packet, the packet ID and the
exact time on the processor clock when the event happened.
It's a little bit of an unusual way I get that data.
You can actually check out the github where I go into some of the details but umm yeah
so this is hopefully gonna be something pretty neat.
Who knows!
It might actually be part of this video if I can figure it out in time.
I have my github repository available publicly here.
I explain how I collect all the data, how I intercept it, how I, well everything works
with the timing.
Uuh along with how it's collected and how I'd go about 3D localizing along with why
it's hard.
And if you want to try to solve this problem, yourself, I've made available a bunch of data
runs from this test.