Detecting Starlink Satellites with a Portable Raspberry Pi and RTL-SDR (2022) | Hacker News Reader

Detecting Starlink Satellites with a Portable Raspberry Pi and RTL-SDR (2022)

rtl-sdr.com

171 pointsctoth19 comments

I always bring this up in the hope that it's seen by someone that has deep knowledge on the subject. The Raspberry Pi's USB 2.0 implementation seems to be horribly inefficient. An RTL-SDR uses over 40% of a CPU core on a Pi 4 just doing USB transfers. It's less than 5% on a typical laptop, as well as on other aarch64 SoMs such as Nvidia Xavier. What's going on? Is the peripheral itself just really cheesy? Is the driver not using DMA when it could be?

welcome to raspberry pi hardware. the usb bus has been problematic since the beginning. i thought the 4s better but it still seems off, but not sure why

I would assume the USB3 ports on the 4 would be better, as they go through a dedicated USB controller connected to the PCIe bus. The USB2 ports are provided by the SoC itself, and that controller is not the best.

Indeed, that would certainly make sense. I've wondered if this device would do significantly better or create its own problems. https://hackaday.com/2022/03/07/a-chip-to-address-the-fundam...

While that's a cool chip, it doesn't really apply here.

USB2.0 ports on the RPI4 only have 2.0 lines (from DWC2 inside the SOC). USB3.0 ports on the RPI4 have both 2.0 and 3.0 lines going to it (both sets of lines for this port coming from the same place: the pcie connected usb controller).

Even though both of the above ports come with 2.0 lines, they're quite different in how they're implemented.

The chip you linked would be useful if that pcie controller didn't come with 2.0 connections.

Ah, cool. This is great info. I just assumed the 2.0 lines would have gone to the SoC still. I'll have to measure the CPU load again and make sure I'm plugged in to a blue port.

The USB2.0 ports are driven by an ip block called dwc2. It's always been a potato. I suppose it was designed for ancient phones that mainly needed it to be as device(aka gadgets) to other usb hosts (eg: a phone connected to a computer, where dwc2 was inside a phone), it just happened that it had this feature called OTG (which is a fancy way to say you can reverse the data direction, so you have host capabilities as well). Because these host capabilities were an after thought (pretty much designed only for flash drives at most) for a niche feature of a phone, it wasn't ever implemented properly.

Another fun thing that happens is that a lot of DWC2's functionality has to be delegated to software instead of the fast hardware. In USB the host needs to send out a packet toward to devices every 1ms. In other USB implementations this happens in the background, driver/kernel doesn't even get notified about it until there's something interesting to do. In DWC2, every 1ms the driver has to do some work, I think it even has to handle 8 interrupts per 1ms. You'll notice that whenever you have any usb device connected, and you `cat /proc/interrupts` you'll probably see a steady increase of 8000/second, this is not normal.

On higher speed hardware like the rk3288, DWC2 doesn't use that much CPU, but for the lower power RPI cpu, this is a significant amount.

Absolutely sweet!

What a delight to see a rasp-pi enthusiast mix satellite detection with antenna design and junk box hacking!

Long ago, this was the ham radio mindset... still is, for some.

Speaking of ham radio mindset, I‘m continuously amazed by the existence of VHF and UHF amateur radio relay satellites, as well as the ham station on the ISS.

It doesn‘t seem like pointing a handheld radio at the sky could possibly be enough to talk to astronauts, yet it seems to work!

It’s only 250 miles, straight up!

(V/U)HF communication range is limited mostly by the distance to the horizon.

There's no horizon if you're talking to someone straight up.

There's a cool and weird scene in "Gravity" which depicts this kind of contact.

If you've already seen the film, you should check out "Aningaaq" [1].

[1] https://www.youtube.com/watch?v=qrm2fv_zXoU

There was a guy at one of the star parties I went to a few years ago that pulled out his ham gear and had a brief chat with the ISS as it flew over. He missed the first fly by, but caught it on the next two.

It was kind of cool for such a "simple" thing. Not sure how many others can say they've had a conversation with someone traveling 17k+ mph.

Love to see convergence on an open portable RTL-SDR rig like the "tricorder" in the article.

I've also tried putting together the right hardware + software but found it a little overwhelming for my lack of expertise.

Something like a HackRF with a Portapack?

https://www.youtube.com/watch?v=oEHfPPo1ZlU

Yeah, I think that's it. Maybe it just needs some more "intuitive" software?

I'd like to see this sort of hardware built into a smart phone as a matter of course, I think the Infosec specialists would find it extremely useful.

I doubt tunable hardware will ever be integrated into phones, given certification regulations,but there are apps for tuning RTL-SDR over USB OTG from Android.

I don't really know why an RPi was used in this example as opposed to a cheap used laptop that already has screen, battery and decent USB.

wild. does anyone know if linear polarization is specific to starlink? youd imagine a circular polarization would make for better reception over all.

the second example in the video may have failed as the directionality/alignment of the LNB and the use of a parabolic dish are typically encouraged for best satellite reception results. a Dish TV or direcTV setup for about $10 at a junkyard might outperform? i dont think these "branded" setups are as discrete or fine tuned as the author suggests.

https://www.reddit.com/r/Starlink/comments/s83ahf/using_dire...

ive been using PI and RTL/SDR to decode ADS-B for about a year now and i gotta say the temperature issues aside it works a treat. just waiting to see ole muskys jet pop up at some point ;)

Reply on news.ycombinator.com