Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An ESP32 based plane radar for my desk

blog.ktz.me

Post reply on HN
Print view View original

21–30 of 65 posts

Re: An ESP32 based plane radar for my desk

#21

Post by bigiain »

daemonologist wrote: post #9
bigiain wrote: post #6

Earlier quoted context omitted.

Using ADS-B and calling it a "radar" feels wrong to me. (But is is a cool project)

Agreed, and even SSR always felt like cheating imo. I wanna see someone build a primary radar on an esp 32.

Gotta admit that's what I clicked through hoping for.

I've seen a few projects that use SDR to detect doppler shifts of reflections of broadcast FM radio station off planes as "passive radar". But that doesn't get much in the way of direction info, just approach velocity. I've pondered building something that uses that and correlates it with an ADS-B receiver, to see it it can detect aircraft that are not transmitting ADS-B. But that'd get me on another "list" if I published it I suspect...

This is not the project I remember, but it's the same idea and technique: https://github.com/Max-Manning/passiveRadar

Re: An ESP32 based plane radar for my desk

#22

Post by dlcarrier »

sephamorr wrote: post #4
amatecha wrote: post #2

Looks pretty cool, though kinda "cheating" by pulling from adsb.fi - though I think you'd need something a lot more powerful than an ESP32 to receive and decode ADS-B ;)

I would actually expect the math to decode ads-b traffic is substantially less complex than, for example, a TLS connection.

TLS is supported in hardware, so it takes no more processing power than moving the data around without encryption.

In the US, ADS-B in uses 1.3 MHz of bandwidth, which would require 2.6 Msps. The ESP32-C3 running at 160 Mhz would have ~70 instructions per sample to process the data. That's probably doable, but the ESP32-C3 is one of the less capable variations of the line, and there are dual-core versions running at more than double the frequency, and those should be able to handle ADS-B in without issue.

Re: An ESP32 based plane radar for my desk

#23

Post by ustad »

alexchamberlain wrote: post #20
ustad wrote: post #19

“Finally, the firmware now supports authenticated OTA updates, so future builds can be installed through the browser instead of connecting the board over USB.” What does that mean?

OTA = over the air. ie online updates you’d expect of a more polished product

But the browser is involved. Can the browser do OTA to esp32?

Re: An ESP32 based plane radar for my desk

#25

Post by dlcarrier »

1e1a wrote: post #12
punnerud wrote: post #8

Earlier quoted context omitted.

Actually possible to receive and decode ADS-B on ESP32, but MLAT is failing (tried hard but not found a trick yet). Biggest problem isn’t that it’s not powerful enough, but the USB port bandwidth don’t match most SDR. Using some clever tricks you can receive parts of the message on a slower USB and be able to decode ADS-B

Why do you need to send the samples over USB?

The built-in ADC doesn't have a high enough sample rate to decode ADS-B in, so an external one is needed, and USB ADCs are readily available with built-in demodulators, for use as DVB-TV receivers.

Re: An ESP32 based plane radar for my desk

#26

Post by schoen »

dlcarrier wrote: post #22
sephamorr wrote: post #4

Earlier quoted context omitted.

I would actually expect the math to decode ads-b traffic is substantially less complex than, for example, a TLS connection.

TLS is supported in hardware, so it takes no more processing power than moving the data around without encryption. In the US, ADS-B in uses 1.3 MHz of bandwidth, which would require 2.6 Msps. The ESP32-C3 running at 160 Mhz would have ~70 instructions per sample to process the data. That's probably doable, but the ESP32-C3 is one of the less capable variations of the line, and there are dual-core versions running at…

> TLS is supported in hardware, so it takes no more processing power than moving the data around without encryption.

Specifically, common PC CPUs support AES acceleration, so you can get the ongoing encryption for an established connection with minimal overhead. There is still some initial overhead for establishing the TLS connection due to the need to do key exchange (with asymmetric cryptography primitives typically based on Diffie-Hellman with finite fields or elliptic curves).

Re: An ESP32 based plane radar for my desk

#28

Post by cenamus »

dlcarrier wrote: post #22
sephamorr wrote: post #4

Earlier quoted context omitted.

I would actually expect the math to decode ads-b traffic is substantially less complex than, for example, a TLS connection.

TLS is supported in hardware, so it takes no more processing power than moving the data around without encryption. In the US, ADS-B in uses 1.3 MHz of bandwidth, which would require 2.6 Msps. The ESP32-C3 running at 160 Mhz would have ~70 instructions per sample to process the data. That's probably doable, but the ESP32-C3 is one of the less capable variations of the line, and there are dual-core versions running at…

GPS is over 1 GHz, but I don't think you need to have a microcontroller running that fast to decode it?

Re: An ESP32 based plane radar for my desk

#29

Post by cenamus »

ustad wrote: post #23
alexchamberlain wrote: post #20

Earlier quoted context omitted.

OTA = over the air. ie online updates you’d expect of a more polished product

But the browser is involved. Can the browser do OTA to esp32?

The browser connects to a webserver running on the ESP32. Over wifi -> over the air. OTA doesn't mean headless or automatic

Re: An ESP32 based plane radar for my desk

#30

Post by punnerud »

dlcarrier wrote: post #25
1e1a wrote: post #12

Earlier quoted context omitted.

Why do you need to send the samples over USB?

The built-in ADC doesn't have a high enough sample rate to decode ADS-B in, so an external one is needed, and USB ADCs are readily available with built-in demodulators, for use as DVB-TV receivers.

No you don’t need an external one, it’s actually possible to sample parts of high bandwidth using a lower bandwidth because of the small buffer in most SDR. The problem is that you can’t freeze the buffer so have to gather multiple “sweeps” get parts of ADSB stitched together.

Maybe I post the Rust code after some cleanup. Now I am busy build a new database from scratch to compete with them all https://github.com/punnerud/mpedb

Post reply on HN