CPLD-Based Synchronization Of Multiple Software Defined Radios

Forgive the click bait headline, but the latest work from [Marco Bartolucci] and [José A. del Peral-Rosado] is really great. They’re using multiple HackRFs, synchronized together, with hybrid positioning algorithms to derive more precise localization accuracy. (PDF)

Like all SDRs, the HackRF can be used to solve positioning problems using WIFi, Bluetooth, 3G, 4G, and GNSS. Multiple receivers can also be used, but this requires synchronization for time-based or frequency-based ranging. [Bartolucci] and [Peral-Rosado] present a novel solution for synchronizing these HackRFs using a few convenient ports available on the board, a bit of CPLD hacking, and a GNSS receiver with a 1 pps output.

This is technically two hacks in one, the first being a sort of master and slave setup between two HackRFs. Using the Xilinx XC2C64A CPLD on board the HackRF, [Bartolucci] and [Peral-Rosado] effectively chain two devices together. The synchronization error is below one sampling period, and more than two HackRFs can be chained together with the SYNC_IN port of each connected together in parallel. Read more about it in their pull request to the HackRF codebase.

This simplest technique will not work if the HackRF receivers must be separated, which brings us to the second hack. [Bartolucci] and [Peral-Rosado] present another option in that case: using the 1 pps output of a GNNS receiver for the synchronization pulse. As long as both HackRFs can see the sky, they can act as one. Very cool!

13 thoughts on “CPLD-Based Synchronization Of Multiple Software Defined Radios

  1. This was a little confusing at first. I’m thinking “I’ve got my GPS disciplined rubidium frequency standard connected to my HackRFs. I’ve got SYNC_CMD connected to SYNC_IN”… So what’s the point of the 1PPS?

    1. They are delightfully cheap when compared to anything with similar capability.
      Then again, with a LimeSDR you’d have two synchronized inputs without any hackery like that. Synchronizing multiple LimeSDR’s currently seems hard, a friend tried it with bad results, the phase constantly drifted.

      But I do wish we’d get the RTL-SDR or transmit capable SDR’s. That would be a fun can of worms.
      I suspect it’d come out of software modified 3g/4g dongles. The baseband stuff in those is seriously capable, but very closed.

  2. In case anyone else is wondering what the heck is going on here, I will summarize:
    These researchers want to synchronize 2 SDR’s together (for applications which require digitizing data from multiple antennas and/or on multiple frequencies outside the SDR’s bandwidth). Their solution was to modify the firmware on the hackRF so that 2 radios so that multiple radios can be triggered from an external source, instead of being triggered over USB. They did this by ANDing the USB trigger with one of the user IO pins, so that capture does not start until it has been requested over USB and there has been a rising edge on the sync line. This sync signal is chosen to be at 1Hz (configured to acquire a 1s long acquisition…) and can come from a hackRF, or an external trigger source. The latter is useful in applications where it is not practical to run a sync wire between the radios, in which case the 1-pulse-per-second output from a GPS can be used as a timing reference between units in distant locations (you would of course also need to provide accurate time bases for both units, and a way to transfer the data to a central computer…).

    They then chose a very roundabout method to verify their results, by recording GPS and LTE data (both of which provide accurate timing information) using their synchronized radios, and showing that the recovered timing information is accurate to within a nanoseconds, which less than the sample time of the analog/digital converter (20MHz).

    Finally they submitted a request to the hackRF team to add their additional sync logic into the CPLD on the hackRF so that others can try out their techniques.

    A nice example of an application where the open hardware nature of the hackRF allowed it to be repurposed for an use case the original did not design for.

  3. I have the impression that GPS time signals are not very accurate due to atmospheric disturbances. A better approach might be to use the time signal from cellphone towers. Better yet, to use a signal from the various longwave time standard transmitters. A good quality PLL could then shift up the signal to be near the band you’re interested in, so you could recover it from your data.

    That at least is how I plan on doing it once I get through my backlog of interesting projects…

    1. Good GPSDO designs can give you sub-ns accuracy and stability. They usually use a high end TCXO or atomic standard for the short-term while syncing to the GPS over sub-mHz time scales.

      Multi-band GPS timing receivers are also able to correct for ionospheric disturbances as the ionospheric delays are frequency correlated.

  4. > Like all SDRs, the HackRF can be used to solve positioning problems using WIFi, Bluetooth, 3G, 4G, and GNSS.


    Show me how to do exactly that on a 0-30 MHz KiwiSDR, or a SoftRock Ensemble setup for 160 meters / 1.8 MHz. Oh wait, you can’t, because that sentence was complete bullshit. They have nor the range nor the bandwidth do solve problems using any of those standards.

  5. I saw this and had multi resolution freq reading. Awesome project and kudos to Marco and Jose.

    We had a similar article that spoke about VHF? UHF? transponder switching. And thought about if multiplexing a bunch of those cheap USB SDR dongles and if one could rewire a few for TX for half duplex between switching.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.