1
\$\begingroup\$

First, let me apologize in advance if this isn't the correct exchange to post this question on.

I have a 50 MHz PWM signal (it's actually a 50 MHz 50% DC clock with a 1PPS clock embedded with PWM) that I would like to transmit over the 2.4 GHz ISM band with as low latency as possible. My original thought was to digitize the clock with a high-speed ADC, then stream the samples to GNU Radio and transmit via SDR, then recover on the receive side and playback the samples with a high-speed DAC. The problem I'm running into is that the only capture cards I've been able to find capable of running at the sample rate needed (>500MS/s) and streaming in real-time to GRC are prohibitively expensive ($8000+).

My question is, is anyone aware of any alternative methods of transmitting the 50 MHz PWM over ISM? I would be willing to entertain a different method of streaming to GRC or an entirely different setup. I don't know of any radios that could take the signal as input directly and transmit it, then receive it and output it directly, but admittedly I am new to the world of RF so it's possible there's a solution that exists that I'm simply unaware of.

The end goal is to transmit this clock and recover it at the other end, with both the phase and embedded 1PPS intact, so that it can be used for synchronization.

\$\endgroup\$
10
  • 6
    \$\begingroup\$ A very warm welcome to the site. As @vir correctly says, is there a need to transmit the 50 MHz waveform at all? Could just the 1 PPS signal be transmitted and then the 50 MHz added at the receiving end? If it could, then it'd simplify things a lot and cost very little, I imagine. Can you also give an idea of volumes - how many of these are you making per month/ever? \$\endgroup\$
    – TonyM
    Commented Aug 2, 2022 at 17:05
  • 1
    \$\begingroup\$ Ah sorry I deleted my comment; I saw the 1 PPS and decided there was probably something I was missing, perhaps phase synchronization? \$\endgroup\$
    – vir
    Commented Aug 2, 2022 at 17:12
  • 2
    \$\begingroup\$ Why wouldn't you just phase-modulate the 2.4 GHz carrier directly with the 50 MHz signal? That would surely be a lot less latency than the long signal chain you're proposing. \$\endgroup\$
    – Dave Tweed
    Commented Aug 2, 2022 at 17:17
  • 2
    \$\begingroup\$ What are you trying to achieve (not how)? \$\endgroup\$
    – Andy aka
    Commented Aug 2, 2022 at 17:19
  • 1
    \$\begingroup\$ your considerations about the sampling rate seems completely off! You need to read up on complex equivalent baseband if you want to do RF stuff, especially with SDRs. \$\endgroup\$ Commented Aug 2, 2022 at 18:12

1 Answer 1

5
\$\begingroup\$

The end goal is to transmit this clock and recover it at the other end, with both the phase and embedded 1PPS intact, so that it can be used for synchronization.

Then you need to have a clock recovery at the receiving end, no matter how you transport the clock.

Using PWM is a useless waste of bandwidth. Simply: don't! And: you don't realize (yet), but your receiver needs to recover the exact carrier frequency (no two oscillators in this universe are exactly identical, especially not the one in your transmitter and your receiver; so, the phase of your received PWM would quickly drift, and a low becomes a high at a 180° phase shift!). So, to recover a clock from your PWM signal, you first need to recover the clock that was used to modulate your PWM signal up to 2.4 GHz. At which point the PWM signal becomes completely superfluous!

So, to synchronize clocks, you'd ideally just transmit a single tone. Observe the tone at the receiver, adjust your receiver's local oscillator such that the frequency is "correct", tada, your receiver now has the clock you've transmitted, reproduced locally. There's a very common technique for that, it's the Phase-Locked Loop (PLL). That tone has (nearly) no bandwidth at all, not 50 MHz!

For the PPS: Easy-peasy. Instead of just transmitting a single tone, you invert the tone's phase every 500 ms (by the way, that's just BPSK). You need 2 Hz of bandwidth, not 50 MHz. The sign of the error signal of your PLL is directly usable as edge of a PPS signal.

In a more advanced system, you don't just invert the phase twice a second, you multiply with a known, pseudo-random sequence of {-1, +1} (so-called "chips") at a higher chip rate (say, 1 Megachip/s) and correlate your received sequence (after frequency-recovery as above!) with the known sequence; the position of the peak gives you the exact timing position. That's how systems like GPS do it! The advantage is a drastically improved SNR and hence lower clock jitter. You need a sample rate of 1, maybe 2 MS/s for that, not the > 500 MS/s you bring up (which, honestly, I can't understand; this number arises from none of your system requirements).

\$\endgroup\$
13
  • 2
    \$\begingroup\$ @user253751 exactly! You can't even get an accurate phase of the oscillator, since you cannot physically predict the phase of the wireless channel. \$\endgroup\$ Commented Aug 2, 2022 at 18:51
  • \$\begingroup\$ I appreciate you taking the time to reply. Unfortunately, the solution you propose doesn't work for my problem. If I was able to dictate the parameters of the clock signal to be transported, then I would have set it up exactly as you suggest and wouldn't have needed to post the question at all. However, the transmitting node generates the clock as I have described and the receiving node expects that signal. \$\endgroup\$
    – aerophage
    Commented Aug 3, 2022 at 16:05
  • \$\begingroup\$ In fact, my plan originally was to treat the clock signal as an arbitrary serial data stream and convert it to BPSK to transmit once I had the samples in GRC. However, the digitization of the clock at a resolution necessary to not lose the 1PPS information is proving prohibitively expensive (500 MS/s gives a resolution of 10 samples/cycle, which would be able to resolve the duty cycle of each period with a granularity of 10%, sufficient to capture the 1PPS information with adequate fidelity). \$\endgroup\$
    – aerophage
    Commented Aug 3, 2022 at 16:06
  • \$\begingroup\$ Since that will not work, I am looking for alternatives to that approach to transmitting the signal. I described the signal as I did because that is the problem I have to solve. \$\endgroup\$
    – aerophage
    Commented Aug 3, 2022 at 16:06
  • 2
    \$\begingroup\$ Correct. However, I need to sample the clock in order to find the PPS event, and to do that I either need to digitize the clock and analyze it in software, or design a piece of hardware that generates some kind of flag when it detects the PPS event. I suspect this is not a unique problem and was looking for input on ways something like that could be achieved that I had not thought of, which is why I posted the question. The focus of the question isn't necessarily the RF path, it's the digitization of the clock with enough fidelity that I can transform it into something that can be transmitted. \$\endgroup\$
    – aerophage
    Commented Aug 3, 2022 at 16:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.