[thoop]

This is really cool. Could you build a few of these and make an interferometer?

I remember reading that interferometers are usually all connected by physical cables with physical loops to make sure the incoming data is combined at exactly the right time. But are we at a point now where that can somehow be done intelligently in software? Or are these little RTL-SDR's not accurate enough to even begin trying that?

[ooterness]

Broadly speaking, the main prerequisite to interferometry is to make sure all the RF circuits are phase-coherent, meaning that all the oscillators are operating in lockstep within some tolerance.

The accuracy needs to be within about 1/10th of a period, give or take. I'm not sure the min/max frequency range for this system, but I saw 1.4 GHz in a screenshot, which would yield a tolerance of about 0.1 * (1 / 1.4 GHz) = 70 picoseconds.

That is achievable with the right hardware, but unfortunately the RTL-SDR doesn't include an option to use an external clock reference. As a result, each dongle's ADC sample timing and RF synthesizer phase will constantly be wandering relative to the others. It's not a one-time calibration; it's an ongoing random walk that changes on a millisecond-by-millisecond basis.

In theory you might be able to pull it off if you had a separate emitter in view of each antenna, calibrate each unit based on that signal, and then synchronize everything in software. But at some point it's easier to just use hardware that has an external clock input, and avoid the whole problem.

[TigeriusKirk]

The always entertaining saveitforparts Youtuber tried to make a "very small array" from a bunch of used satellite mini-dishes. He ran into all sorts of fun issues with his ad hoc construction.

I admire the guy for having as much fun with his failures as his successes.

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

[dekhn]

The lesson I've learned (I build scientific instruments as a hobby) is not to chase the latest, greatest ideas. Many of them only work because the implementors have access to a huge knowledge base, excellent parts and facilities, and really smart people to help debug the inevitable problems.

I focus more on maximizing what i can get out of a simple hardware setup, which means skipping anything that involves complex digital analysis or extremely sophisticated and sensitive equipment; it means more time having fun and less time debugging problems where I actually don't know enough to debug the problem.

[gorlilla]

There are RTL-SDR [0] dongles that have pin headers for a common clock source already on the market.

[0]: https://www.rtl-sdr.com/rtl-sdr-blog-v-3-dongles-user-guide/...

[eskaytwo]

There’s also the Kraken project https://www.krakenrf.com/

[ooterness]

Neat! I hadn't heard about that capability. That definitely makes things a lot easier.

[zzbn00]

Could try intensity inteferometry? A good mental exercise

https://en.wikipedia.org/wiki/Hanbury_Brown_and_Twiss_effect

[ooterness]

In this case, the coherent source is the celestial object being observed. The problem here is that the "combining" step is being performed in software, and the sequence of digital samples have time- and phase-offsets that are ever-changing.

The two options are to keep those offsets under control (i.e., lock everything to a common clock) or to rapidly measure the offsets as they change and try to compensate in software (difficult).

[zzbn00]

In intensity interferometry the phase is not measured, and the timing accuracy is I believe only proportional to the desired effective bandwidth of the measurement. It was done in 1950's with bandwidths ~10 MHz -> 0.1microsec accuracy, should be do-able with SDR. Intensity interferometry is a bit of mind-twister...

(Another at first surprising thing is that radiation received from celestial sources is only coherent because of their very small apparent size -- the sources themselves are not coherent at all, because their physical size is very large)

[ooterness]

That's interesting; I hadn't heard of that before. No idea if it would work.

[thoop]

Very interesting! Thanks for the great response.

Is there a better frequency available to amateur hardware that would give tolerance within more reasonable limits?

Without a shared external clock reference, i.e. over longer distances, how expensive does the hardware get if you want to be able to accurately measure the time/phase wandering to correct in software?

Just curious if it’s a limit of the low cost RTL-SDR or if it’s a harder problem than that (or both?).

[ooterness]

Over local distances, all you need is a shared clock reference. As others have pointed out, the RTL-SDR dongle can do this with mods.

Over longer distances, this is an active area of research with many different approaches for various applications.

Two recent well-known examples are the "Event Horizon Telescope" (the network of radio telescopes that has been generating images of black holes) and optical frequency combs (a recent demo published in Nature achieved time-transfer accuracy of a few femtoseconds).

https://eventhorizontelescope.org/

https://www.nist.gov/topics/physics/optical-frequency-combs

[toomuchtodo]

Can you use GPS as clock reference?

https://www.gps.gov/applications/timing/

https://ilrs.gsfc.nasa.gov/docs/timing/gpsrole.pdf

[ooterness]

There's simpler options if all your equipment is in the same building, but yes, GPS-disciplined oscillators are a really great way to sync up clocks anywhere in the world to within a few nanoseconds. That said, it doesn't really help here because a) nanoseconds not picoseconds and b) the RTL-SDR doesn't have anywhere to plug it in.

[toomuchtodo]

Please forgive the silly question, but can the RTL-SDR receive the GPS signals software defined and process for timing?

[civilitty]

No, it's not enough to know when samples from different SDRs were taken, they must all be taken within a very small interval (tens of picoseconds in OP's example). What the SDRs really need is an electrical signal called a "trigger" that tells them to read their sensors at that exact moment which is what GP meant by plugging them in. You can use a second GPS enable device to generate that trigger but synchronizing those triggers using time of flight is very hard.

[touisteur]

Maybe you can bruteforce time correlation by shifting every source slightly, trying a yuge number of shift combinations and seeing which combination gives the 'best' (most correlated) output on a known signal? I've done that for many out-of-sync systems, and since I've started using GPUs in the two Os I've become obsessed with brute force methods :-)

[kawfey]

It is possible - https://www.rtl-sdr.com/rtl-sdr-tutorial-gps-decoding-plotti...

[civilitty]

Theoretically yes but using GPS time of flight to synchronize sensor triggers to within tens of picoseconds is so far outside of "amateur" that you might as well incorporate and start replying to DoD RFPs.

When your math starts requiring relativistic physics, it's a lot easier and cheaper to just run some fiber.

[semi-extrinsic]

You'll want to look at the KrakenSDR. It's basically a circuit board integrating 5 RTL-SDR chips driven from a single clock source and calibrated for phase coherency, for the express purpose of doing radio interferometry amongst other things. They're in stock at Mouser.

[thoop]

Whoa yeah this looks like it would be easier than doing it all by hand. $466 at Mouser. Interesting!

Looking around on Google, I don’t see anyone that has tried using this for interferometry yet but the KrakenSDR team explicitly mentions that it can be used for interferometry.

[CamperBob2]

They were pitching it for use in bistatic passive radar, which is a very similar application, until somebody put the fear of ITAR into them. Some of that code is probably still lying around.

[jesprenj]

I mirrored whatever they had when they got taken down on github: http://ni.4a.si/anonymous/krakensdr_pr/

The wiki is still public afaik.