PC requirements for UHD/B210 SDR

[Brett Dawson]

Hi Everyone,

For those using a B210 SDR with GNU radio, I'd like to hear what you're using for a host PC. 

I have a 12th Gen Intel® Core™ i5-12400 (6 cores), 16 GB DDR4 ram, 512GB SSD, (Ubuntu 20.04) which seems to be having problems keeping up with 2 RX running each @ > about 5 Msps.  I am seeing USRP overflow errors in GNU radio when running a basic flow graph which sinks the USRP source in two QT GUI freq sinks.  The problem seems worse with more elaborate flow graphs.

Running UHD_USRP_probe tells me the B210 is connected via USB 3, so that seems ok, though I am going to organise a dedicated USB 3 PCIe controller.

Also, on another subject (and following on from a previous post) I've had some recent success using 2 x RTL SDR's (sharing a common 28.8 MHz reference) for interferometry.  I'm going to write this up at some stage, but it essentially involved using a noise noise to achieve sample synchronization.  There is a manual process needed to find and apply the sych offset needed for each observation.  This is applied when post processing the obs data.

Thanks,

Brett

[Anthony]

Hi, I'm using this a Fanless Industrial PC, Mini Computer, Intel Core I3 4005U, Linux Ubuntu 22.04, HUNSN IM03, VGA, HDMI, LAN, 2 x COM RS232, 2 x USB2.0, 4 x USB3.0, 16G RAM, 128G SSD, 1TB HDD & dual WIFI antenna. 

I get similar issues, but not when I run the B210 & GNU at a srate of 3e6 or 2.7e6, with a bandwidth of 5e6 and rfgain set to 55. I do use dual USB external fans for cooling. The PC is on the right in the image below. The B210 isn't connected in this older image....

--
--
You received this message because you are subscribed to the Google
Groups "Society of Amateur Radio Astronomers" group.
To post to this group, send email to sara...@googlegroups.com
To unsubscribe from this group, send email to
sara-list-...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sara-list?hl=en
---
You received this message because you are subscribed to the Google Groups "Society of Amateur Radio Astronomers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sara-list+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sara-list/f2f77763-0167-48c0-a46d-234ed4a73ae0n%40googlegroups.com.

[Marcus D. Leech]

On 25/06/2023 05:53, Brett Dawson wrote:

Hi Everyone,

For those using a B210 SDR with GNU radio, I'd like to hear what you're using for a host PC. 

I have a 12th Gen Intel® Core™ i5-12400 (6 cores), 16 GB DDR4 ram, 512GB SSD, (Ubuntu 20.04) which seems to be having problems keeping up with 2 RX running each @ > about 5 Msps.  I am seeing USRP overflow errors in GNU radio when running a basic flow graph which sinks the USRP source in two QT GUI freq sinks.  The problem seems worse with more elaborate flow graphs.

The offered computation load is proportional to the sample-rate X inherent-complexity-of-DSP-flow.  So, it should come as
  no shock at all that performance issues get worse as you make the flow-graph more complex.

What you might try is adding "num_recv_frames=256" to your device arguments, which will effectively increase the
  frame-buffering in the controller.   USB controllers tend to be fairly bad at doing bulk transfers for sustained periods, and
  you can "baby" them with this device argument.

https://files.ettus.com/manual/page_transport.html

Also, is your CPU in "Performance" mode?

Are you running in a VM or on "bare metal" ?

Running UHD_USRP_probe tells me the B210 is connected via USB 3, so that seems ok, though I am going to organise a dedicated USB 3 PCIe controller.

Also, on another subject (and following on from a previous post) I've had some recent success using 2 x RTL SDR's (sharing a common 28.8 MHz reference) for interferometry.  I'm going to write this up at some stage, but it essentially involved using a noise noise to achieve sample synchronization.  There is a manual process needed to find and apply the sych offset needed for each observation.  This is applied when post processing the obs data.

Thanks,

Brett

[Dan Layne]

Hi Brett,

At DSES we use the B210 on either a  System76 desktop (32 core, 64 GB RAM, 1 TB SSD) or a System76 laptop (16 core, 16 GB, 1 TB).  Both computers run Ubuntu 22.04. We also saw GnuRadio overflow errors until we bumped up "num_recv_frames" as Marcus indicated. The B210 also worked fine at high sample rates  when the computers ran Ubuntu 20.04.

Dan

[Brett Dawson]

Thanks for the info Anthony - you have nice setup!  A bit more refined than mine.

[Brett Dawson]

On Monday, 26 June 2023 at 00:00:29 UTC+10 Marcus D. Leech wrote:

On 25/06/2023 05:53, Brett Dawson wrote:

Hi Everyone,

For those using a B210 SDR with GNU radio, I'd like to hear what you're using for a host PC. 

I have a 12th Gen Intel® Core™ i5-12400 (6 cores), 16 GB DDR4 ram, 512GB SSD, (Ubuntu 20.04) which seems to be having problems keeping up with 2 RX running each @ > about 5 Msps.  I am seeing USRP overflow errors in GNU radio when running a basic flow graph which sinks the USRP source in two QT GUI freq sinks.  The problem seems worse with more elaborate flow graphs.

The offered computation load is proportional to the sample-rate X inherent-complexity-of-DSP-flow.  So, it should come as
  no shock at all that performance issues get worse as you make the flow-graph more complex.

What you might try is adding "num_recv_frames=256" to your device arguments, which will effectively increase the
  frame-buffering in the controller.   USB controllers tend to be fairly bad at doing bulk transfers for sustained periods, and
  you can "baby" them with this device argument.

Thanks Marcus - this has helped a lot.  I had tried larger num_recv_frames values as recommended by Ettus elsewhere on their website, but they did not help.

I'm guessing there are a number of these parameter changes that would be useful for B210 owners to know. 

 

https://files.ettus.com/manual/page_transport.html

Also, is your CPU in "Performance" mode?

OK I think I need some help with this.  What is performance mode and how is it implemented?

 

Are you running in a VM or on "bare metal" ?

Bare metal - dual boot WIN11/Ubuntu 20.04.

[Marcus D. Leech]

On 25/06/2023 18:49, Brett Dawson wrote:

On Monday, 26 June 2023 at 00:00:29 UTC+10 Marcus D. Leech wrote:

On 25/06/2023 05:53, Brett Dawson wrote:

Hi Everyone,

For those using a B210 SDR with GNU radio, I'd like to hear what you're using for a host PC. 

I have a 12th Gen Intel® Core™ i5-12400 (6 cores), 16 GB DDR4 ram, 512GB SSD, (Ubuntu 20.04) which seems to be having problems keeping up with 2 RX running each @ > about 5 Msps.  I am seeing USRP overflow errors in GNU radio when running a basic flow graph which sinks the USRP source in two QT GUI freq sinks.  The problem seems worse with more elaborate flow graphs.

The offered computation load is proportional to the sample-rate X inherent-complexity-of-DSP-flow.  So, it should come as
  no shock at all that performance issues get worse as you make the flow-graph more complex.

What you might try is adding "num_recv_frames=256" to your device arguments, which will effectively increase the
  frame-buffering in the controller.   USB controllers tend to be fairly bad at doing bulk transfers for sustained periods, and
  you can "baby" them with this device argument.

Thanks Marcus - this has helped a lot.  I had tried larger num_recv_frames values as recommended by Ettus elsewhere on their website, but they did not help.

Make sure you're adding that as a device argument, and not something else.

I'm guessing there are a number of these parameter changes that would be useful for B210 owners to know. 

 

https://files.ettus.com/manual/page_transport.html

Also, is your CPU in "Performance" mode?

OK I think I need some help with this.  What is performance mode and how is it implemented?

Your desktop environment should allow you to add a "CPU Scaling Monitor" to the toolbar.  The default in most distros
  is to run in power-saving or "on demand" mode.

The exact options offered by this app vary based on what kind of CPU you have. 

 

Are you running in a VM or on "bare metal" ?

Bare metal - dual boot WIN11/Ubuntu 20.04.

Another general observation, which isn't necessarily a "thing" in this case.  It's very easy for the naive user of
  Gnu Radio/GRC to produce flow-graphs that basically work, but which are wildly sub-optimal.  This really is
  true of ANY programming environment, whether it's something "specialized" like Gnu Radio, or something more
  general.  The environment has no inherent "clue" about what it is you're trying to accomplish, so if you're doing
  things in a naive way, it has no way of fixing that.     Eventually, with the maturation of AI, this may change.
  But "traditional" programming environments really have no inherent "semantic clue" about what you're trying
  to accomplish, and will simply do what you ask.

A specific case that comes up frequently is in the design of filters.  If the transition width is only a very-small fraction
  of the sample-rate, the number of taps required to create that filter becomes very large, very quickly.   The naive
  might, for example, bring in 10MHz of bandwidth, and try to extract 1kHz from it with a very-tight filter.  This will
  lead to an ungainly computational burden.     But without the necessary DSP background, you might not have a
  good feel for this, and why your flow-graph is consuming massive amounts of CPU.    Really, Gnu Radio isn't
  "a radio with a lot of knobs to tweak"--it's a first-class programming environment for a niche set of applications.
  If you aren't already familiar with good programming practice, and DSP in general, it will be a steep learning curve.

[Brett Dawson]

Thanks Dan - these machines are more capable than mine so it seems that processor capacity is not necessarily the primary issue - that is what I really needed to know - I was hoping I was not going to be up for a new machine.

BTW I'd not heard of System76 before.  Very interesting.

[Brett Dawson]

On Monday, 26 June 2023 at 08:59:59 UTC+10 Marcus D. Leech wrote:

On 25/06/2023 18:49, Brett Dawson wrote:

On Monday, 26 June 2023 at 00:00:29 UTC+10 Marcus D. Leech wrote:

On 25/06/2023 05:53, Brett Dawson wrote:

Hi Everyone,

For those using a B210 SDR with GNU radio, I'd like to hear what you're using for a host PC. 

I have a 12th Gen Intel® Core™ i5-12400 (6 cores), 16 GB DDR4 ram, 512GB SSD, (Ubuntu 20.04) which seems to be having problems keeping up with 2 RX running each @ > about 5 Msps.  I am seeing USRP overflow errors in GNU radio when running a basic flow graph which sinks the USRP source in two QT GUI freq sinks.  The problem seems worse with more elaborate flow graphs.

The offered computation load is proportional to the sample-rate X inherent-complexity-of-DSP-flow.  So, it should come as
  no shock at all that performance issues get worse as you make the flow-graph more complex.

What you might try is adding "num_recv_frames=256" to your device arguments, which will effectively increase the
  frame-buffering in the controller.   USB controllers tend to be fairly bad at doing bulk transfers for sustained periods, and
  you can "baby" them with this device argument.

Thanks Marcus - this has helped a lot.  I had tried larger num_recv_frames values as recommended by Ettus elsewhere on their website, but they did not help.

Make sure you're adding that as a device argument, and not something else.

I'm guessing there are a number of these parameter changes that would be useful for B210 owners to know. 

 

https://files.ettus.com/manual/page_transport.html

Also, is your CPU in "Performance" mode?

OK I think I need some help with this.  What is performance mode and how is it implemented?

Your desktop environment should allow you to add a "CPU Scaling Monitor" to the toolbar.  The default in most distros
  is to run in power-saving or "on demand" mode.

The exact options offered by this app vary based on what kind of CPU you have. 

Ok understand now - yes I have looked at this.

 

Are you running in a VM or on "bare metal" ?

Bare metal - dual boot WIN11/Ubuntu 20.04.

Another general observation, which isn't necessarily a "thing" in this case.  It's very easy for the naive user of
  Gnu Radio/GRC to produce flow-graphs that basically work, but which are wildly sub-optimal.  This really is
  true of ANY programming environment, whether it's something "specialized" like Gnu Radio, or something more
  general.  The environment has no inherent "clue" about what it is you're trying to accomplish, so if you're doing
  things in a naive way, it has no way of fixing that.     Eventually, with the maturation of AI, this may change.
  But "traditional" programming environments really have no inherent "semantic clue" about what you're trying
  to accomplish, and will simply do what you ask.

A specific case that comes up frequently is in the design of filters.  If the transition width is only a very-small fraction
  of the sample-rate, the number of taps required to create that filter becomes very large, very quickly.   The naive
  might, for example, bring in 10MHz of bandwidth, and try to extract 1kHz from it with a very-tight filter.  This will
  lead to an ungainly computational burden.     But without the necessary DSP background, you might not have a
  good feel for this, and why your flow-graph is consuming massive amounts of CPU.    Really, Gnu Radio isn't
  "a radio with a lot of knobs to tweak"--it's a first-class programming environment for a niche set of applications.
  If you aren't already familiar with good programming practice, and DSP in general, it will be a steep learning curve.

Agreed.

[Marcus D. Leech]

On 25/06/2023 19:52, Brett Dawson wrote:
>
Assuming that you're using "num_recv_frames=256", and your CPU is in one
of its high-performance modes, then there's
  "something wrong" with what you're doing somewhere.   Your i5-12400
with 16GB of memory should be able to
  handle a couple of piddling 5Msps streams without any issue at all.

You might try installing the "cpupower" toolset:

sudo apt install linux-tools-common

Then when you run "cpupower --help", it'll tell you the name of the
additional toolset you need to install.

Once you have that, you should be able to:

sudo cpupower frequency-set -g performance

This may or may not be your issue.  I dunno.

You might share the .grc file you created that isn't running well.
Unless there's something truly broken about your
  USB controller, with your CPU, you should easily be able to process
this stuff.

[Brett Dawson]

After the change to dev args ("num_recv_frames=256")  all seems good.

I see core loads @ approx 60% (mem @ 15% utilised) with 2 x RX streams each with 30Msps.  This was the same as before (wasn't expecting a change), but I was seeing overflow errors so it seems the num_recv_frames change has made the difference.

"your i5-12400 with 16GB of memory should be able to handle a couple of piddling 5Msps streams without any issue at all" was what I was after - I didn't have a feel for the computing capability required, hence my initial question to the group.  My real question was not so much CPU/Mem but USB 3 performance, and whether anything special was needed in terms of PC build.  I noticed for example that adding a short USB extension cable (30cm) was enough to for the B210 to report a USB 2 rather than USB 3 connection (when UHD probe command was run). 

I am happy to share GRC flowgraphs.  The first is a simple 2 block config just to benchmark (ie check if there are there overflow errors) the SDR perf with something undemanding .  I did previously see overflow errors running this as mentioned before.

The second is your BAA flowgraph, with some minor changes (mainly for IF and sky freq differences, and a different source block for USRP - it needs more work to fix the buffer error).  By the way, I think your presentations to the BAA were very well done, and I'm sure there are more than a few of us that have benefited from your shared knowledge.

Thanks for the CPUpower suggestions.

[Marcus D. Leech]

On 25/06/2023 23:57, Brett Dawson wrote:

After the change to dev args ("num_recv_frames=256")  all seems good.

I see core loads @ approx 60% (mem @ 15% utilised) with 2 x RX streams each with 30Msps.  This was the same as before (wasn't expecting a change), but I was seeing overflow errors so it seems the num_recv_frames change has made the difference.

"your i5-12400 with 16GB of memory should be able to handle a couple of piddling 5Msps streams without any issue at all" was what I was after - I didn't have a feel for the computing capability required, hence my initial question to the group.  My real question was not so much CPU/Mem but USB 3 performance, and whether anything special was needed in terms of PC build.  I noticed for example that adding a short USB extension cable (30cm) was enough to for the B210 to report a USB 2 rather than USB 3 connection (when UHD probe command was run). 

I am happy to share GRC flowgraphs.  The first is a simple 2 block config just to benchmark (ie check if there are there overflow errors) the SDR perf with something undemanding .  I did previously see overflow errors running this as mentioned before.

The second is your BAA flowgraph, with some minor changes (mainly for IF and sky freq differences, and a different source block for USRP - it needs more work to fix the buffer error).  By the way, I think your presentations to the BAA were very well done, and I'm sure there are more than a few of us that have benefited from your shared knowledge.

Thanks for the CPUpower suggestions.

I don't understand what drove you to swap-out the osmosdr source block.  It's capable of talking UHD just fine.

On Monday, 26 June 2023 at 10:21:25 UTC+10 Marcus D. Leech wrote:

On 25/06/2023 19:52, Brett Dawson wrote:
>
Assuming that you're using "num_recv_frames=256", and your CPU is in one
of its high-performance modes, then there's
  "something wrong" with what you're doing somewhere.   Your i5-12400
with 16GB of memory should be able to
  handle a couple of piddling 5Msps streams without any issue at all.

You might try installing the "cpupower" toolset:

sudo apt install linux-tools-common

Then when you run "cpupower --help", it'll tell you the name of the
additional toolset you need to install.

Once you have that, you should be able to:

sudo cpupower frequency-set -g performance

This may or may not be your issue.  I dunno.

You might share the .grc file you created that isn't running well.
Unless there's something truly broken about your
  USB controller, with your CPU, you should easily be able to process
this stuff.

--
--
You received this message because you are subscribed to the Google
Groups "Society of Amateur Radio Astronomers" group.
To post to this group, send email to sara...@googlegroups.com
To unsubscribe from this group, send email to
sara-list-...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sara-list?hl=en
---
You received this message because you are subscribed to the Google Groups "Society of Amateur Radio Astronomers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sara-list+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sara-list/954a6adc-2ed2-429f-b292-86005e95dd10n%40googlegroups.com.

[Brett Dawson]

On Monday, 26 June 2023 at 14:06:18 UTC+10 Marcus D. Leech wrote:

On 25/06/2023 23:57, Brett Dawson wrote:

After the change to dev args ("num_recv_frames=256")  all seems good.

I see core loads @ approx 60% (mem @ 15% utilised) with 2 x RX streams each with 30Msps.  This was the same as before (wasn't expecting a change), but I was seeing overflow errors so it seems the num_recv_frames change has made the difference.

"your i5-12400 with 16GB of memory should be able to handle a couple of piddling 5Msps streams without any issue at all" was what I was after - I didn't have a feel for the computing capability required, hence my initial question to the group.  My real question was not so much CPU/Mem but USB 3 performance, and whether anything special was needed in terms of PC build.  I noticed for example that adding a short USB extension cable (30cm) was enough to for the B210 to report a USB 2 rather than USB 3 connection (when UHD probe command was run). 

I am happy to share GRC flowgraphs.  The first is a simple 2 block config just to benchmark (ie check if there are there overflow errors) the SDR perf with something undemanding .  I did previously see overflow errors running this as mentioned before.

The second is your BAA flowgraph, with some minor changes (mainly for IF and sky freq differences, and a different source block for USRP - it needs more work to fix the buffer error).  By the way, I think your presentations to the BAA were very well done, and I'm sure there are more than a few of us that have benefited from your shared knowledge.

Thanks for the CPUpower suggestions.

I don't understand what drove you to swap-out the osmosdr source block.  It's capable of talking UHD just fine.

The osmosdr block isn't included in GRC 3.10.5.1 (at least not in the installation I have) and I hadn't gotten around to grabbing it - there didn't seem a reason given a USRP block exists.  Is there a performance difference between them? 

[Marcus D. Leech]

On 26/06/2023 00:18, Brett Dawson wrote:

On Monday, 26 June 2023 at 14:06:18 UTC+10 Marcus D. Leech wrote:

On 25/06/2023 23:57, Brett Dawson wrote:

After the change to dev args ("num_recv_frames=256")  all seems good.

I see core loads @ approx 60% (mem @ 15% utilised) with 2 x RX streams each with 30Msps.  This was the same as before (wasn't expecting a change), but I was seeing overflow errors so it seems the num_recv_frames change has made the difference.

"your i5-12400 with 16GB of memory should be able to handle a couple of piddling 5Msps streams without any issue at all" was what I was after - I didn't have a feel for the computing capability required, hence my initial question to the group.  My real question was not so much CPU/Mem but USB 3 performance, and whether anything special was needed in terms of PC build.  I noticed for example that adding a short USB extension cable (30cm) was enough to for the B210 to report a USB 2 rather than USB 3 connection (when UHD probe command was run). 

I am happy to share GRC flowgraphs.  The first is a simple 2 block config just to benchmark (ie check if there are there overflow errors) the SDR perf with something undemanding .  I did previously see overflow errors running this as mentioned before.

The second is your BAA flowgraph, with some minor changes (mainly for IF and sky freq differences, and a different source block for USRP - it needs more work to fix the buffer error).  By the way, I think your presentations to the BAA were very well done, and I'm sure there are more than a few of us that have benefited from your shared knowledge.

Thanks for the CPUpower suggestions.

I don't understand what drove you to swap-out the osmosdr source block.  It's capable of talking UHD just fine.

The osmosdr block isn't included in GRC 3.10.5.1 (at least not in the installation I have) and I hadn't gotten around to grabbing it - there didn't seem a reason given a USRP block exists.  Is there a performance difference between them? 

No performance difference--just that I prefer to use gr-osmosdr, because it makes my applications hardware agnostic.
  I'm running Ubuntu 22.04 with GR 3.10.1.1, and I installed gr-osmosdr with "apt".

You're on earlier Ubuntu, so you would have to have installed GR from source, which would mean a source install of
  gr-osmosdr.

To view this discussion on the web visit https://groups.google.com/d/msgid/sara-list/ef19e6e8-0178-4bf1-b22a-7ad4c80af26en%40googlegroups.com.

[mike....@gmail.com]

Brett,

"  I've had some recent success using 2 x RTL SDR's (sharing a common 28.8 MHz reference) for interferometry "

I too have ponied up two sdr's with a common reference but am confused how to  synchronize the data.  I would be very interested in your article.

Thanks

Mike  W9YS

[Marcus D. Leech]

On 26/06/2023 08:49, mike....@gmail.com wrote:

Brett,

"  I've had some recent success using 2 x RTL SDR's (sharing a common 28.8 MHz reference) for interferometry "

I too have ponied up two sdr's with a common reference but am confused how to  synchronize the data.  I would be very interested in your article.

Thanks

Mike  W9YS

The general approach with RTL-SDRs is:

    o  Use a common reference clock
    o  Disable dither in the synthesizer programming
    o  Use a calibration signal at the beginning, and then use fast convolution to determine the time and phase offsets
    o  Use the above information to apply a correction

Now, you can either do this in "real time", or you can record the raw I/Q and then do the time-and-phase alignment
  post-facto (which is basically how VLBI works).

This is how KrakenSDR does it--there's nothing all that special about the RTL-SDRs they use, it's just that they've packaged
   all of the above "nicely".

On Sunday, June 25, 2023 at 4:53:44 AM UTC-5 Brett Dawson wrote:

Hi Everyone,

For those using a B210 SDR with GNU radio, I'd like to hear what you're using for a host PC. 

I have a 12th Gen Intel® Core™ i5-12400 (6 cores), 16 GB DDR4 ram, 512GB SSD, (Ubuntu 20.04) which seems to be having problems keeping up with 2 RX running each @ > about 5 Msps.  I am seeing USRP overflow errors in GNU radio when running a basic flow graph which sinks the USRP source in two QT GUI freq sinks.  The problem seems worse with more elaborate flow graphs.

Running UHD_USRP_probe tells me the B210 is connected via USB 3, so that seems ok, though I am going to organise a dedicated USB 3 PCIe controller.

Also, on another subject (and following on from a previous post) I've had some recent success using 2 x RTL SDR's (sharing a common 28.8 MHz reference) for interferometry.  I'm going to write this up at some stage, but it essentially involved using a noise noise to achieve sample synchronization.  There is a manual process needed to find and apply the sych offset needed for each observation.  This is applied when post processing the obs data.

Thanks,

Brett

--

--
You received this message because you are subscribed to the Google
Groups "Society of Amateur Radio Astronomers" group.
To post to this group, send email to sara...@googlegroups.com
To unsubscribe from this group, send email to
sara-list-...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sara-list?hl=en
---
You received this message because you are subscribed to the Google Groups "Society of Amateur Radio Astronomers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sara-list+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sara-list/9319e91e-f47a-478e-ab41-21f4b4396f7bn%40googlegroups.com.

[Hermann Fenger]

Hi Marcus,

thank you  for the 'num_recv_frames' parameter hint. It works very well and will save me a lot of headaches.

Hermann

[Brett Dawson]

On Monday, 26 June 2023 at 22:49:27 UTC+10 mike....@gmail.com wrote:

Brett,

"  I've had some recent success using 2 x RTL SDR's (sharing a common 28.8 MHz reference) for interferometry "

I too have ponied up two sdr's with a common reference but am confused how to  synchronize the data.  I would be very interested in your article.

Thanks

Mike  W9YS

Hi Mike,

I'd be happy to share the info once I get my act together.  There is nothing ground breaking in the method, and it follows advice from Marcus, Peter East and others in this group.

Cheers,

Brett