Project Progress Report and possible Radio Astronomy Technique?

  • Context: Graduate 
  • Thread starter Thread starter Paul Colby
  • Start date Start date
Click For Summary

Discussion Overview

The discussion revolves around the use of Software Defined Radios (SDRs) for radio astronomy, specifically focusing on techniques for synchronizing multiple radios to measure small thermal noise. Participants explore the feasibility of using correlation measurements between the IQ samples from two SDRs and the challenges associated with achieving time synchronization.

Discussion Character

  • Exploratory
  • Technical explanation
  • Debate/contested
  • Mathematical reasoning

Main Points Raised

  • One participant describes their ongoing project using two SDRs to measure thermal noise, noting that while phase and frequency synchronization has been achieved, time synchronization remains problematic due to sample offsets.
  • Another participant suggests that the technique resembles a radio interferometer and inquires about the source of common noise that allows for time synchronization even without injected noise.
  • A participant raises a tradeoff regarding whether to synchronize the internal local oscillators of the SDRs or to build RF front-ends that avoid noisy digital hardware.
  • Several participants express confusion regarding the calculation of Johnson noise levels, questioning how a specific value of -187 dBW/Hz was derived and discussing the implications of noise power spectral density versus voltage spectral density.
  • One participant shares their experimental findings that reducing the distance between radios increases common noise, which can facilitate synchronization, while also acknowledging the complexity of noise interactions.
  • Another participant emphasizes the importance of cooling and the potential for better designs than using general-purpose radios, while also noting the limitations of their current capabilities.
  • Participants discuss the stability of the phase of the correlation peak and the need for further data collection to monitor the relative phase of the tuner chips in the SDRs.

Areas of Agreement / Disagreement

Participants express varying levels of understanding and agreement on the technical aspects of noise calculations and synchronization techniques. There is no consensus on the best approach to achieve synchronization or the implications of the noise calculations, indicating ongoing debate and exploration of the topic.

Contextual Notes

Participants highlight limitations in their understanding of noise calculations and the assumptions involved in their experiments. The discussion reflects a range of technical challenges and uncertainties regarding synchronization methods and noise sources.

Paul Colby
Science Advisor
Insights Author
Messages
1,577
Reaction score
486
Some 8 years ago I posted some experiments using 2 Software Defined Radios slaved to a common clock. The idea was measure small thermal noise by making correlation measurements between the IQ samples from each radio. This is a project that has kinda smoldered in the background where I've made progress in fits and starts. Since most (all?) RA signals are small thermal signals it seemed like the technique should be a natural approach. A recent thread discussing the feasibility of using SDRs to do amateur radio astronomy spawn another look at the technique.

By post #27 of this 8 year old thread, it looked like I had solved the problem of syncing the radios making the phase relation between the radios fixed and stable. Well, they are but I was missing a rather important point. While the phase and frequency of the radios were indeed in sync they were most definitely not time synchronous. What this means is, given IQ sample, ##A_n## from radio ##A## and ##B_n## from radio ##B##, one may not assume ##n##, the sample number, refers to the same instant of time. From a software perspective the reasons are straight forward. The system needs to start data collection threads and aren't setup to start them on the same cycle of the reference clock. Turns out the sample offset between data streams is typically large. These run 10k to 20k samples and of somewhat random sign (which radio thread starts first is a crap shoot).

The solution to this problem is straightforward by adding some additional buffering into the IQ data streams. One just needs to compute the correlation between the IQ stream and look for the correlation peak. Initially I would inject a common noise source into each radio. It turns out there is already enough common noise to do a time sync. This is both a convenience and a serious limiting problem.

The conclusion at this point is more work is needed to make it worth while. A 50ohm terminator produces -187 dBW/Hz at 290K. Under ideal conditions I've been able to get to about -182 dBW/Hz with the radios each terminated independently in 50 ohms at 20MHz. At 1420MHz there is enough common noise present to sync the radios so the system temperature is much hotter at -172 dBW/Hz.

So, as it stands, one could think about RA using this technique but one would need two antennas.
 
Last edited:
Astronomy news on Phys.org
So basically a radio interferometer? That's pretty neat, I've always wanted to do something like this.

So even when you stopped injecting noise into each you still had enough common noise to do a time sync? Do you know where the noise is coming from? Probably leakage? Theoretical Johnson noise level would be around -200 dBW/Hz right?
 
There is a tradeoff, is it easier to synchronise the internal 1'st LO synthesisers of two SDRs, or to build two RF front-ends with 1'st LOs that do not involve noisy digital hardware near the antennas or LNAs ?

Since the SDR synthesisers do not start at the same instant, with the same code, there will be a phase or time difference between the same spurs in two otherwise identical SDR signals.
 
I’m confused. Johnson noise at 290K is -174 dBm/Hz or -204 dBW/Hz. How do you get -187?
 
marcusl said:
I’m confused. Johnson noise at 290K is -174 dBm/Hz or -204 dBW/Hz. How do you get -187?
The total Johnson noise per Hz is ##4k_BTR##. For a perfectly matched network, only ##k_BTR## of it gets into the receiver. In this case it is

##1.38\times 10^{-23}\; 290\times 50 = -187 dBW/Hz##

Did I miss something? Often not a vacuous question for me
 
QuarkyMeson said:
So even when you stopped injecting noise into each you still had enough common noise to do a time sync? Do you know where the noise is coming from? Probably leakage? Theoretical Johnson noise level would be around -200 dBW/Hz right?
This is a good question. I’ve done some experimenting separating the radios and shortening the cables from the clock generator. I’ve succeeded in reducing the common noise to the point that it can’t be used for syncing them.

Every port is a two way street, noise comes in and noise definitely goes out. Connecting the radio inputs with a short cable raises the common noise considerably, often about 10 dB or so. With very thick rose colored glasses, connecting ideally matched perfectly isolated radios should be the same as terminating them independently. Of course, the noise belched out each input are correlated at detectable levels.

I should post some data and will do so. I’m out of town for a number of weeks so there will be a delay.
 
  • Like
Likes   Reactions: QuarkyMeson
Baluncore said:
There is a tradeoff, is it easier to synchronise the internal 1'st LO synthesisers of two SDRs, or to build two RF front-ends with 1'st LOs that do not involve noisy digital hardware near the antennas or LNAs ?
Yeah, starting from scratch with enough competence to actually do the design work is definitely the way to go. Also, cooling everything or most things is the way to go. There are definitely better ways than using cheap devices intended as general purpose radios for Hams. None of these are in reach for me.

Baluncore said:
Since the SDR synthesisers do not start at the same instant, with the same code, there will be a phase or time difference between the same spurs in two otherwise identical SDR signals.
The SDRs (Sdrplay products) are based on a tuner chip and a DSP chip. The tuner contains a voltage controlled oscillator that is frequency synced to a 24 MHz clock that drives the DSP chip. The DSP chip has the ADCs responsible for the IQ values. By slaving each radio to a common clock, (a product feature), I ensure the IQs streams for each radio has a fixed relative time offset. I can determine this offset by computing the correlation between two long segments. I use syipy.signals correlate function. The correlation peak is often quite pronounced (with a common noise source) being 100 to 200 times the background and 1 sample wide. When zeroed (by dropping N samples form one stream) the peak (in absolute value) remains stable at 0 offset.

Now, this only assures that IQ streams are at identical times. It does not assure that the relative phase of the tuner chips remain stable. However, I can use the phase of the correlation peak to monitor the relative phase of the tuner chips. It definitely wanders about a bit but seems stable to 5 degrees or so. I need to collect more data on this though.
 
Paul Colby said:
The total Johnson noise per Hz is ##4k_BTR##. For a perfectly matched network, only ##k_BTR## of it gets into the receiver. In this case it is

##1.38\times 10^{-23}\; 290\times 50 = -187 dBW/Hz##

Did I miss something? Often not a vacuous question for me
The units aren't correct. You're getting ##\frac{V^2}{Hz}##, which I think would be the noise voltage spectral density across the load and not the noise power spectral density delivered to the receiver.
 
Paul Colby said:
The total Johnson noise per Hz is ##4k_BTR##. For a perfectly matched network, only ##k_BTR## of it gets into the receiver. In this case it is

##1.38\times 10^{-23}\; 290\times 50 = -187 dBW/Hz##

Did I miss something? Often not a vacuous question for me
There's no R in the formula for power, only for the voltage generated by a resistance. A resistor delivers a power spectral density S=kT W/Hz to a matched load.
 
  • Like
Likes   Reactions: Paul Colby
  • #10
Paul Colby said:
I should post some data and will do so. I’m out of town for a number of weeks so there will be a delay.
So, been back for a while. I left kinda disappointed with the noise performance of these tests. Syncing two radios with a common clock is work and it takes special hardware to boot. This got me thinking about trying to do things a different way. In the interim I've been reworking software for the RFSpace radios I've collected. These radios are different than most. An ADC is used to sample at 67MHz. This is followed by an AD6620 DSP receiver chip. Unlike the SDRplay radios, the AD6620 chip and all its algorithms are well documented. So, I have personal control over most of the hardware and the API used to run it.

Okay, NTP and its snazzier step child, PTP, are network protocols designed to synchronize computer clocks. NTPs target accuracy is 10ms while PTPs is 1us. Just knowing the time of day to 10ms just by plugging into a network is kinda amazing. 1us would be well into the range of being useful for this application. For now we'll stick with Ubuntu's stock NTP.

IQ data for the RFSpace radios is collected in 2048 sample data frames at a nominal rate of 196078 samples per second. This is the (nominal) 66,666,667 Hz ADC rate decimated by 340. Recording these data frames along with their time stamps to disk gives an uninterrupted stream of data for as long as one is willing to fill a disk. After 2 minutes or so (my current attention span) of data collecting, one should have a pretty decent measurement of the actual radio data rate. Time stamps are obtained using the system call clock_gettime(CLOCK_REALTIME,&tspec). For each radio I then fit the times to a straight line,
$$
t(n) = r n + t0
$$
where ##n## is the frame number. The parameter ##r## is the frame rate and ##t0## the start time for the radio. With two radios ##r_1## won't equal ##r_2## and likewise, ##t0_1## won't equal ##t0_2##.

Given these two fits, we may select segments of IQ samples that span the same time. Initial tests with two computers didn't work so great. Random 10ms offsets between clocks moves the correlation peak to a position that can't be predicted. Also, the variations from run to run of the measured data rates varies more than I expect based on the performance of these radios as radios.

To counter these issues, I switched to a single computer. This seems to have virtually eliminated the time offset problem. The measured data rates still bounces around by much more than I expect, however, the difference in measured data rates between the radios drifts around by about one Hz which is quite usable.

To compute the correlation between IQ data streams I first select a time range, ##(t_1,t_2)##. IQs are extracted from each radio data file that span these times. For time spans of a second or so the length of these IQ arrays will differ by some 1-10 samples or so which I ignore. Next, the DC offset is removed by subtracting the average of the IQ values for each array.

The next step is key. The radio center frequency was set assuming the nominal ADC clock rate. We need to frequency shift one of the IQ data sets by the appropriate amount. At a center frequency of 2MHz this frequency shift is obtained from our measured frame rates and is about 28Hz. Doing so yields a nice correlation peak,

correlation.webp


This is from 1.7 minutes of data taken with a noise generator that's teed and fed into each radio. The time span is ##(t_1=10sec,t_210.5sec)## as measured from the start of the overlap of the IQ data.

This is still very much a work in progress. Moving to PTP from NTP should allow the radios to be on separate computers which need not be colocated.
 

Similar threads

Replies
26
Views
3K