1D TOF measurement with RTS-CTS-NULL-ACK ?

[wolfgangr]

Hello, cnlohr,
Great project!

For surveillance of crop irrigation systems,
I am looking for a 1D-distance in the range up to 350 m, with ~10m accuracy.
I think this is feasible with wlan directional antennae.

From an earlier google scan, I kept this link (in German only):
https://chemnitzer.linux-tage.de/2011/vortraege/folien/653_haustein.pdf
According to them, the RTS-CTS-NULL-ACK sequence is part of IEE 802.11 standard and travels 4 time the transmit line with little jitter.
They use a linux MAC80211 driver, which obviously allows the required manipulations.
They report 1 µs, but by repeating measurements (n >> 1000), they end up at ns resolution.

For my 10m accuracy target, we'd need ~ 100 ns for quadruple path.
Their setup is a master sender/receiver at a fixed location, a slave receiver close to it, and the target receiver at the moving distant target. I think a raspberry or so might be a good master, and esp8266 suitable slaves.

How does this approach fit into the work you have done till now?
Would you like to share efforts?

Wolfgang Rosner

[cnlohr]

I don't currently have any interest to develop against this sort of thing. I think it is very cool, and very well may be used by the ESP with some more hacking, however, I am not that interested.

For future notes of anyone who wants to attempt this, it makes me think of another feature. The ESP does seem to get interrupts called on send and send "success" so perhaps one could use the time delta between those. I intend to leave this ticket open but not work on it.

Thank you for bringing it to my attention.

[wolfgangr]

Thank you for hosting my request :-)

For the moment, my limited time is overbooked with more basic tasks, but when I see a viable chance for a solution, I'd like to pick up the TOF-Idea again.

So maybe if somebody is stumbling across this post who had a deeper look into the wifi API of the espconn, may I ask him to leave a note whether and where we could look for hooks to the RTS-CTS / NULL_ACK mechanism.

[jonathanmuller]

@wolfgangr
Are you still on this idea ?
I'm currently working on that

[wolfgangr]

I've put it on my large pile of nice-to-have projects.
It' bogged down to the area, where composting starts ;-{
What's the current state of your work?
How could I help?

[jonathanmuller]

@wolfgangr
I'm currently using an ESP32 and trying to optimize TOF.
Currently I'm :
Sending a RTS frame
Getting the internal CPU counter value
Listening for CTS
Getting the internal CPU counter value
Subtracting the 2 values

Theoretically with the CPU at 240MHz one could achieve a 1.2 meter resolution (in a perfect world).
By doing the RTS/CTS exchange multiple time it can be averaged.

It all depend on your knowledge level on C/assembler and the time you want to invest in it .. ?

[wolfgangr]

Theoretically with the CPU at 240MHz one could achieve a 1.2 meter resolution

this sounds promising.

It all depend on your knowledge level on C

still not far beyond novice. I can write litte hello worlds, grasp a rough idea on complex projects and do some limited modifications there. Haven't ever a done a major project on my own.

assembler

far far ago. In the late 1970ies, I hexcoded the 6502.
Last year, I played a litte bit with assembler (hello world level) in arduino and with on taret debugging. But don't call it expertise...

and the time you want to invest in it .. ?

hm... How much were required?
Can you give an estimate?

[wolfgangr]

At the moment, I am looking for a forth implementation for the ESP8266
Forth is infamously known as a close-to-metal hardware-hacker-language.
You can write tiny (3 to 10 lines are common) Assembler or C low level modules for real hard time critical tasks and use them hands on in an interactive way.
It is supposed to run as fast as not-well-optimized C-code.
This might save the cumbersome edit-build-upload-debug-cyles usually encurred with embedded systems.

Might that help? May I just quote you

Sending a RTS frame
Getting the internal CPU counter value
Listening for CTS
Getting the internal CPU counter value
Subtracting the 2 values

To me, this sounds like 4 low level primitives ( send - listen - gettime - alltogether_in_tough_timing) to be implemented. Maybe some more to play interactively with the WiFi-setup.

[jonathanmuller]

and the time you want to invest in it .. ?

hm... How much were required?
Can you give an estimate?

I have absolutely no idea. With luck and skills it can take few days, or it could also miserably fail after 3 years

At the moment, I am looking for a forth implementation for the ESP8266
Forth is infamously known as a close-to-metal hardware-hacker-language.
You can write tiny (3 to 10 lines are common) Assembler or C low level modules for real hard time critical tasks and use them hands on in an interactive way.
It is supposed to run as fast as not-well-optimized C-code.
This might save the cumbersome edit-build-upload-debug-cyles usually encurred with embedded systems.

Might that help? May I just quote you

Sending a RTS frame
Getting the internal CPU counter value
Listening for CTS
Getting the internal CPU counter value
Subtracting the 2 values

To me, this sounds like 4 low level primitives ( send - listen - gettime - alltogether_in_tough_timing) to be implemented. Maybe some more to play interactively with the WiFi-setup.

I don't really know Forth, but if it is even slightly slower than well optimized C it might be too much to have TOF.
For each CPU cycle late, this is 1 meter error added, oo I would stick to C/assembler as much as possible. But it may also work !

[wolfgangr]

Yes, of course, the time critical measurement istself has to be performed in Assembler.
This is what I wanted to indicate with "alltogether_in_tough_timing".
But usually, you have lots of preparation before and after, repeated calls, calculations, statistics, ...whatever, that might easier be performed in a interpreted hands on high level language.

But I haven't any operating forth yet, so there's no reason to shy horses, so far...

[wolfgangr]

Hi @jonathanmuller ,
on the way of implementing forth, I get acquainted a little bit with disassembling, reverse engineering and ESP8266 implementation quirks.
Having this TOF-idea in mind, there were some findings that did not sound very encouraging to me.

https://www.kickstarter.com/projects/214379695/micropython-on-the-esp8266-beautifully-easy-iot/posts/1501224
(though we don't write micropython, we may face similiar challenges)
https://cdn-shop.adafruit.com/product-files/2471/0A-ESP8266__Datasheet__EN_v4.3.pdf
http://www.danielcasner.org/guidelines-for-writing-code-for-the-esp8266/
Quote from the last link:

Peripherals
All of the MCU peripherals (UART, I2S, Radio, etc.) seem to have been developed custom by Espressif and are a bit idiosyncratic so they take some time to get used to.
One of the most significant speed limitations is that all register reads / writes are surprisingly slow so they should be kept to a minimum.

Does this hold for the WiFi peripheral registers as well?
As far as I can see, ESP8266 is implmented as "system on a chip" aka "SOC" .

The die picture does not look like some dedicated processor hardware were present.
Just the WiFi stuff, and the rest is +- uniform pattern.
So, I conclude both the processor and the interface to the wifi hardware are loaded on some generic gate array, maybe aka PLD aka programmable logic device

So if there is a quirky hardware layer between processor and WiFi hardware, it will be very different to analyze the timing behaviour. If the I/O-access layer injects irreproducible delays in the order of many processor cycles, this would severely spoil TOF precision, of course.

But I know, there are many eagerly motivated and trained people out there in reverse engineering ESP8266.
So. I would be glad to see you disproving me :-)

And the datasheet mentions

1.5. Major Applications
...

• WiFi Location-aware Devices
• WiFi Position System Beacons

So maybe Espressif has provided for precise TOF, but covered it with some obscurity layer still to be uncovered? Just like with early GPS signal distortion for civil use?

My next question were if the PLD is of the field programmable FPGA type, or of some factory write-once-only kind. As far as I can remeber, FPGA with volatile ram-cell-like programming are much cheaper than persistently programmed ones. So the hope is, for a low budget chip like the ES8266, we have a RAM-programmed FPGA.

If so, the setup procedure had to load the 'IP' (aka intellectual property kernel, which is the definition of the logical circuit) onto the chip first. So this were easier accessible for reverse engineering (albeit still verey difficult to understand, as I'm afraid). It could reside somewhere in the ROM or even in the espressif blobs to be flashed, or both, obviously.

Looking at the die picture and missing any processor there, in case of FPGA, there were a boot stage needed were the processor itself is loaded to the chip first.
There are 64k Boot ROM at 0x4000000.
This would be the first place to look at.
Has this already been disassembled?

Thinking in terms of booting up a SOC into an FPGA, ESP8266 weird memory scheme gains meaning.

• pull one line up, the rest low - this is Adress 0x40000000 - right where the boot rom starts
• have some hardcoded memcopy circuit to load first FPGA circuitry from boot ROM
• implement RAM and flash access circuitry as FPGA gates
  Still no full fledged microcontroller yet - but maybe flash cache manager
• load flash beginning at 0x420... into ram.
  this might contain the IP-kernel with the MCU.
  And the WiFi-controller, and the interface between both.

Consequence: the processor itself were defined on the flash image and in principle accessible to reverse engineering. Of course, it may be protected, maybe just by bare encryption.

Yes, I have FPGA (Altera) lingering beyond my desk.
No I haven't done anything yet beyond a pure look at them.
So yes, all this is just a bunch of not-really-educated guess.
So if I'm boring or distracting you with my speculations, just let me know.

[wolfgangr]

following this line of thought....
.... I find my assumptions confirmed, as well as people hacking along this way....

https://www.reddit.com/r/electronics/comments/2jq22l/esp8266_wifiserial_chip_decapped_its_actually/

ESP8266 WiFi-serial chip decapped. It's actually ESP8089.

....

I wish I could tell you which of the plain-looking sections was CPU and which was on-chip memory, but it all looks the same to me

....

Linux kernel driver source code for ESP8089: https://github.com/linux-rockchip/kernel_rockchip/tree/radxa/radxa-dev-kk/drivers/net/wireless/esp8089

https://hackaday.io/project/8678-rpi-wifi

Enter the Eagle

....

I remembered this blog post showing a decapped ESP8266, noting that in the corner is printed "ESP8089". The post mentioned that ESP8089 is another Espressif part, a commodity SPI and SDIO to WiFi chip. That got me thinking that, if the ESP8089 and ESP8266 are the same die, then there is a good chance that an ESP8266 module could work as an SDIO WiFi adapter on the Pi.

see also
https://zeptobars.com/en/read/Espressif-ESP8266-wifi-serial-rs232-ESP8089-IoT

So my Idea:
If the ESP8266 is generic hardware and gets its functionality just by flashing some firmware on it, maybe some other firmware might allow more bare-to-metal access to WiFi-TOF-measurement?

I think a dissection of the ESP8089- linux-driver might be the next step

[jonathanmuller]

I totally agree with you on the fact that flashing it with some custom firmware could probably allow TOF.
I can't remember where but I saw espressif talking about implementing TOF, so the hardware probably has this ability.
Unfortunately I don't (currently have) the necessary hardware to go further into the investigation.

If you are interested I have de-assembled some part of the code and found some interesting functions/properties.
I can't openly talk about that but do not hesitate to contact me (or anyone interested in that) [mail on my bio]

You seem to know more that I do on the hardware of the ESP, so I can't answer them, but hopefully someone can !

My hope is that some "high" level (in fact low level) function allow direct modifications of the WiFi function of the chip, which could allow for direct TOF without code included.

For example "CSI" frames require a nanosecond precision, so I expect that the chip has something related in its guts

[wolfgangr]

Unfortunately I don't (currently have) the necessary hardware to go further into the investigation.

what's required?
I have differnet types of ESP8266 laying around
(ESP-01, ESP-07, ESP-12)
some usb-serial adaptors as well

This guy
https://hackaday.io/project/8678-rpi-wifi/details
uses a raspberry. I have some of those as well.

But shouldn't this SDIO flashing as well be possible over the serial port of any linux work station?
I don't want to include the function in my running kernel.
I just want the ESP8266 behaving as a thumb (maybe ESP8089) WiFI controller.

And maybe this is not necessary at all?
Does it depend on the flashing path which binary goes onto the module?
Maybe we can get it to behave like a ESP8089 loading from an embedded flash?
Well, it may require som minor modification which may be impossible to find out by simple guess.
So starting off by analyzing a precise clone of a setup that is known to work may be advantageous.
OK, just ordered some ESP-03 from CN to be prepared to do so.

You seem to know more that I do on the hardware of the ESP,

not knowledge, just bold speculation, but getting confirmed when I was digging deeper, which made me somewhat more confident in my assumptions

And I haven't much knowledge on WiFi, either.

[wolfgangr]

Just recall the finding in one of the above mentioned reverse engineering links that espressif was obviously heavily building upon open source projects.

There are CPU-cores for FPGA in the public available as well.
The opencore projects alone counts nearly 200 of them - from emulation good old legacy 6502 and Z80 up to 32 bit risc controllers:
https://opencores.org/projects?expanded=Processor
My browser counts 18 hits of the number "32", so that reduces it to a managable tasks for diligent kids ;-)

So may be they did the same thing with CPU code than they did with lwip etc?
Would realy be a hit if we could indentify the ESP8266 core bening listed there :-)
Would ease reverse engineering quite a lot :-)))

[jonathanmuller]

I think Espressif probbaly got inspiration from already existing open-source project but for sure they modified it a lot.
They took particular care to not divulge their IP (the possible FPGA WiFi core), and my bet is here is no legal way to find it.
I think, but this is only my personnal opinion, that reverse-engeneringb the possible FPGA core is a level of abstraction too low. Of course this would give access to extremely precise TOF, but I don't think it is at a reachable complexity level.
On the other hand, I hope that the SDK code (particularly the one which is not documented) should be enough the do TOF, but this is only my bet.

[wolfgangr]

Hi @jonathanmuller ,
thanks for your inspiring hints.

I just rescanned my informations and found this elaborate:
https://chemnitzer.linux-tage.de/2011/vortraege/folien/653_haustein.pdf

IEEE 802.11y setzt die Laufzeitmessung in Zukunft Hardware-seitig um.

translates to english:
" in the future, [ the standard ] IEEE 802.11y is implementing time of flight measurement at the hardware level

I think IEEE 802.11 is anything about wifi,
So if we could find pointers to this "y" flavour , that might be great.

Do you know this document?
At page 4, it refers to RTS-CTS-NULL-ACK method
can your read this?
Does it help to have it translated?
Have you found something similiar/better in english?

this one
http://hackaday.com/2014/09/26/esp8266-distance-testing/
points to here, so we are in a loop.

'========================
http://bbs.espressif.com/viewtopic.php?t=467

In order to use radio technology for real time location system, it seems measurement of Time of Flight is one of the best way.
Some people acheive 50cm repetability with moving target of few meters/sec (5 or so).
.... http://www.eecs.berkeley.edu/~dzats/time-of-flight.pdf

'========================
https://www.usenix.org/system/files/conference/nsdi16/nsdi16-paper-vasisht.pdf

https://arxiv.org/pdf/1505.03446

Sub-Nanosecond Time of Flight on Commercial Wi-Fi Cards
Deepak Vasisht, Swarun Kumar, Dina Katabi

looks quite comprehensive

http://www.rfwireless-world.com/Terminology/WLAN-SIFS-vs-PIFS-vs-DIFS-vs-EIFS-vs-AIFS.html

https://hackaday.io/project/4872-subpos-positioning-system

Anything in there which is new for you?

[wolfgangr]

just starting to search.

...:~/test/esp-SDK/esp-open-sdk$ grep -nri "RTS" . | wc
  56337  428113 7411467
...:~/test/esp-SDK/esp-open-sdk$ grep -nri "cts" . | wc
  70699  610358 10754634

more than 10.000 matches for RTS and CTS in the ESP sdk is still a haystack.
Well, RTS and CTS are quite frequent triplets in everyday english as well.

Whats in the binary? One needle found, and one wooden toothpick?

.../nodemcu-firmware/bin$ grep -nri "cts" 0x00000.bin
.../nodemcu-firmware/bin$ grep -nri "cts" 0x10000.bin
.../nodemcu-firmware/bin$ grep -nri "rts" 0x10000.bin
Binary file 0x10000.bin matches
.../nodemcu-firmware/bin$ grep -nri "rts" 0x00000.bin

.../nodemcu-firmware/bin$ grep -abi "rts" 0x10000.bin
184863:tx rts error 0x%x
187394:�CFirmware ONLY supports ESP8266!!!

wrosner@wjrws3:~/test/FORTH/cforth/nodemcu-firmware/bin$ xxd -s 184800 -l 200 0x10000.bin
0002d1e0: 6368 6720 6966 2564 0a00 0000 0000 0000  chg if%d........
0002d1f0: 6164 6420 6966 2564 0a00 0000 0000 0000  add if%d........
0002d200: 6169 6420 2564 0a00 6263 6e20 2564 0a00  aid %d..bcn %d..
0002d210: 636e 7420 0a00 0000 756e 636e 7420 0a00  cnt ....uncnt ..
0002d220: 7478 2072 7473 2065 7272 6f72 2030 7825  tx rts error 0x%
0002d230: 780a 0000 0000 0000 0000 0000 0000 0000  x...............
0002d240: 7478 2065 7272 6f72 2030 7825 780a 00ff  tx error 0x%x...
0002d250: 706d 2e63 0000 0000 0000 0000 0000 0000  pm.c............
0002d260: 666c 6173 685f 7265 6164 2065 7272 310a  flash_read err1.
0002d270: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0002d280: 666c 6173 685f 7265 6164 2065 7272 320a  flash_read err2.
0002d290: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0002d2a0: 736c 6565 7020 6469                      sleep di

well, not really. Just an error message - no call.

[wolfgangr]

Working down the rabbithole aka source tree.

.../sdk/esp_iot_sdk_v1.5.4.1$ xtensa-lx106-elf-objdump -d lib/libpp.a | grep -i rts | wc
     63     374    3844
.../sdk/esp_iot_sdk_v1.5.4.1$ xtensa-lx106-elf-objdump -d lib/libpp.a | grep -i cts | wc
     11      59     643

a linkable object file with a dozen of hits - may that smell like a needle?
Can we focus on the entry points? yepp: '>:' will do the trick

.../sdk/esp_iot_sdk_v1.5.4.1$ xtensa-lx106-elf-objdump -d lib/libpp.a | grep -i cts | grep '>:'
0000151c <lmacProcessCtsTimeout>:
00000058 <RC_GetCtsTime>:
.../sdk/esp_iot_sdk_v1.5.4.1$ xtensa-lx106-elf-objdump -d lib/libpp.a | grep -i rts | grep '>:'
000015c0 <lmacProcessRtsStart>:
000015fc <lmacProcessTxRtsError>:
00000030 <RC_GetRtsRate>:
00000950 <trc_NeedRTS>:

get some time .... <lmacProcessRtsStart> .... <RC_GetCtsTime> ....substract times
No, It can't be that simple. People had found it ages ago.

btw:
Is there a front door?
what is this libpp for, and does it have a documentation?

[wolfgangr]

lets have some eye on it xtensa-lx106-elf-objdump -d lib/libpp.a | less

rate_control.o:     file format elf32-xtensa-le


Disassembly of section .text:

00000000 <RC_GetAckRate-0x20>:

...

00000044 <RC_GetAckTime>:
  44:   fffe31          l32r    a3, 3c <RC_GetRtsRate+0xc>
  47:   b02230          addx8   a2, a2, a3
  4a:   fffd31          l32r    a3, 40 <RC_GetRtsRate+0x10>
  4d:   050222          l8ui    a2, a2, 5
  50:   902230          addx2   a2, a2, a3
  53:   001222          l16ui   a2, a2, 0
  56:   f00d            ret.n

00000058 <RC_GetCtsTime>:
  58:   e0c112          addi    a1, a1, -32
  5b:   0139            s32i.n  a3, a1, 0
  5d:   1149            s32i.n  a4, a1, 4
  5f:   31c9            s32i.n  a12, a1, 12
  61:   2109            s32i.n  a0, a1, 8
  63:   02cd            mov.n   a12, a2
  65:   fff985          call0   0 <RC_GetAckRate-0x20>
  68:   4129            s32i.n  a2, a1, 16
  6a:   0138            l32i.n  a3, a1, 0
  6c:   0c2d            mov.n   a2, a12
  6e:   000685          call0   d8 <RC_GetBlockAckTime+0x44>
  71:   4108            l32i.n  a0, a1, 16
  73:   1138            l32i.n  a3, a1, 4
  75:   a40c            movi.n  a4, 10
  77:   232a            add.n   a2, a3, a2
  79:   018cb6          bltui   a12, 8, 7e <RC_GetCtsTime+0x26>
  7c:   041c            movi.n  a4, 16
  7e:   31c8            l32i.n  a12, a1, 12
  80:   504a            add.n   a5, a0, a4
  82:   225a            add.n   a2, a2, a5
  84:   2108            l32i.n  a0, a1, 8
  86:   20c112          addi    a1, a1, 32
  89:   f42020          extui   a2, a2, 0, 16
  8c:   f00d            ret.n
  8e:   000000          ill
  91:   000000          ill

focus on this stanza

00000044 <RC_GetAckTime>:
  44:   fffe31          l32r    a3, 3c <RC_GetRtsRate+0xc>

The label <RC_GetRtsRate+0xc> points to undebuggable ara just before <RC_GetAckTime>.
I assume ram allocated for local static variables.
So it is not a register read, yet - just memory. How does it go there?

65: fff985 call0 0 <RC_GetAckRate-0x20> ?

00000000 <RC_GetAckRate-0x20>:
   0:   1352b6          bltui   a2, 5, 17 <RC_GetAckRate-0x9>
   3:   0982b6          bltui   a2, 8, 10 <RC_GetAckRate-0x10>
   6:   442c            movi.n  a4, 36
   8:   07b2f6          bgeui   a2, 16, 13 <RC_GetAckRate-0xd>
   b:   441c            movi.n  a4, 20
   d:   000086          j       13 <RC_GetAckRate-0xd>
  10:   60a042          movi    a4, 96
  13:   042d            mov.n   a2, a4
  15:   f00d            ret.n
  17:   c0a022          movi    a2, 192
  1a:   f00d            ret.n
  1c:   000000          ill
        ...

what's moviabout? move from io? or just within memory?
Does the fact that <RC_GetAckRate-0x20> hasn't got a name in the symbol table, but is referenced by a negative offset of the subsequent symbol, any implications?
Obfuscation?

[wolfgangr]

before you can RTFM, you have to find one - not that easy....
https://github.com/eerimoq/hardware-reference/raw/master/esp32/xtensa%20Instruction%20Set%20Architecture%20(ISA)%20Reference%20Manual.pdf

imm7 7-bit immediate (for MOVI.N)

MOVI sets a register to a constant encoded in the instruction.

hm... no read from I/O -back to start.

[wolfgangr]

Is there a front door?

google "libpp rate_control" does not reveal any public documentation.
google "libpp" finds some hits, but they seem to refer to some comletely differnt subject.

So, if I had time, I knew where I'd continue my search....

[cnlohr]

Just FYI there are no "register reads" everything is done as memory-mapped IO.

[wolfgangr]

Ah, thanks, so there is no special machine instruction to do so, I assume.
Do you have Information on the wifi control registers?
Where they are and maybe even what they are supposed to do?

Just found
https://github.com/esp8266/esp8266-wiki/wiki/Memory-Map#memory-layout

3FF00000h dport0 1000h I/O RW? Memory-mapped I/O, repeated every 100h.

Size= 1000h, repeating every 100h, next documented area 10000h above ?
Does not sound like reliable information... but the best available, I'm afraid :-(

So if we look for low level IO-access, we look for reads / writes to 3FF00?XXh ?
Or is there any remapping included?
May be in the hardware layer, maybe at flash file preparation, maybe by the linker?

[wolfgangr]

looking in the disassemby from libpp.a, I get no match for 3ff0
there are lots of fff0 matches like this, but it doesn't ring a bell.

 3f0:   000020          excw
 3f3:   000000          ill
 3f6:   700000          excw
 3f9:   000005          call0   3fc <esf_buf_recycle+0x140>
 3fc:   fff000          excw
 3ff:   ff              .byte 0xff
 400:   000a50          excw
        ...

00000404 <esf_buf_setup>:

It is at the end of previous routine, where I suspect data areas.
what's this excw?
Wasn't it a token for "decompiler does not know?"
So it's either an indicator that the current section is not executable,
or that the extensa tools don't know everything, either?

asked google, recommended me to put these under my pillow for tonight:
https://www.ratzzo.net/index.php/posts/a-guide-to-reverse-engineering-the-esp8266-internal-rom
https://www.esp8266.com/viewtopic.php?p=22148
https://forum.arduino.cc/index.php?topic=569453.0

[jonsmirl]

A common technique for determining TOF is to write code that ping-pongs packets in a very deterministic way. For example code that directly interfaces with the radio hardware and does not use interrupts. You then ping-pong say 1,000 round trips.

Each CPU takes X milliseconds to do the ping-ping. So time for 1,000 round trips = 2000 X + 2000 TOF this is a big enough number that you can use the CPU hardware clock to measure it. Do some math and you can compute the TOF.

The accuracy is a function of:

1. The two crystals on the CPU
2. How deterministic the ping-pong function is
3. the resolution of the timer measuring the 1000 round trips.

Data I have seen indicates that you can get centimeter accuracy or better.

The problem - this technique is not real time and it ties up your radio. On the other hand it is quite useful for locating fixed objects such as IOT devices. If you have three devices that you accurately know the location of, you can map out the rest of the network in 3D using triangulation.

Another techique is AOA/AOD as currently implement in Bluetooth. This could also be implement on the ESP but it requires an antenna array and an antenna switching chip. I've seen several PCB antenna arrays build for this purpose. It also requires low level access to the received radio signal. Once you have three angles you can again triangulate. Basic Idea is for one device to emit a carrier wave, and receiver then uses the switch to receive the CW from the different elements of the array. The radio receiver generate vector data that can be processed to figure out the AOA. Bluetooth does this very quickly and uses the packet preamble as the CW.

[ddrown]

The new esp32-s2 chip in beta is supposed to have time of flight measurements, this might help when the hardware and software ships.

https://esp32.com/viewtopic.php?t=11265 says about the new hardware features supported by the esp-idf libraries: "Time-of-Flight (TOF) measurements with normal Wi-Fi packets is not supported", but work is being done to add the new hardware features to the library.

[cnlohr]

That'll be cool when it goes in.