1

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.

Marcus Müller
  • 88,280
  • 5
  • 131
  • 237
aerophage
  • 11
  • 1
  • 6
    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? – TonyM Aug 02 '22 at 17:05
  • 1
    Ah sorry I deleted my comment; I saw the 1 PPS and decided there was probably something I was missing, perhaps phase synchronization? – vir Aug 02 '22 at 17:12
  • 2
    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. – Dave Tweed Aug 02 '22 at 17:17
  • 2
    What are you trying to achieve (not how)? – Andy aka Aug 02 '22 at 17:19
  • The 50 MHz signal is a PWM square wave. It's nominally 50% duty cycle, but it has a 1PPS signal encoded in it by means of varying the duty cycle for two clock cycles at the second mark. It would be difficult to modulate a 2.4 GHz carrier directly without destroying the phase information from the clock and losing the 1PPS modulation event. The end goal is to transmit this clock and recover it at the other end, with both the phase and embedddd 1PPS intact, so that it can be used for synchronization. – aerophage Aug 02 '22 at 17:41
  • 1
    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. – Marcus Müller Aug 02 '22 at 18:12
  • 1
    This is a classic XY problem: you got a simple problem with a complex solution that creates its own problem, whereas the original problem has a simple and well understood solution to anyone practicing in the field. Perhaps just consult an RF engineer for this one - it will speed things up significantly. Furthermore, why is your clock so special? Can't both ends of the connection just receive GPS clock, which will typically be better than whatever you can come up with? Why do you care about your clock so much? Tell us - it will make a difference in the quality of answers you get. – Kuba hasn't forgotten Monica Aug 02 '22 at 19:35
  • @aerophage try again without mentioning the method of achieving what you want. You'll feel better for it. My question is all about what you want to achieve without mention of how. – Andy aka Aug 02 '22 at 19:45
  • It sounds like what you _really_ want to do is to send a time base for synchronization, and the **way** that you _think_ you want to do it is with your 50MHz square wave with an embedded 1PPS. Perhaps what you _should_ do is tell us _what you really need_ -- which is probably something along the lines of "synchronize two boxes to within \$\Delta t\$ seconds and \$\Delta f\$ in frequency". – TimWescott Aug 02 '22 at 19:52
  • Sorry for the link-only comment, but check this out about 10ns-jitter synchronization: https://www.youtube.com/watch?v=RvnG-ywF6_s – rdtsc Aug 02 '22 at 20:48

1 Answers1

5

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).

Marcus Müller
  • 88,280
  • 5
  • 131
  • 237
  • 2
    @user253751 exactly! You *can't* even get an accurate phase of the oscillator, since you cannot physically predict the phase of the wireless channel. – Marcus Müller Aug 02 '22 at 18:51
  • 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. – aerophage Aug 03 '22 at 16:05
  • 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). – aerophage Aug 03 '22 at 16:06
  • 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. – aerophage Aug 03 '22 at 16:06
  • *The transmitting node generates… the receiving node expects* yes, I understand. The transformation from that, to something you can transmit, back to what you expect is what you *always* need to do in wireless communications :) – Marcus Müller Aug 03 '22 at 16:08
  • Why would you use 10 samples per cycle? 2 would suffice. If your PPS always applies to the next clock edge, as said, you can send basically a constant as reference tone! Then, using 1/25,000,500 samples per cycle suffices. – Marcus Müller Aug 03 '22 at 16:08
  • The 50 MHz clock has nominally a 50% duty cycle. The 1PPS clock is embedded in the 50 MHz clock by varying the duty cycle for two clock periods at the second mark. Being able to resolve the duty cycle with a granularity of 10% is sufficient to capture that, hence 10 samples/cycle. – aerophage Aug 03 '22 at 16:14
  • yeah, as said, once you stop thinking that you need to transport PWM and instead just recreate it at the receiver, you don't need that many samples. You already have though of the solution! A 10 MSymbols/s BPSK stream of constant value that only switches when your PWM value switches would do. – Marcus Müller Aug 03 '22 at 16:16
  • (to sense whether a PWM high-period was short or long, you don't need to oversample the PWM signal with an ADC. You'd just use a simple low-pass / integrator circuit to measure the duration) – Marcus Müller Aug 03 '22 at 16:24
  • 2
    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. – aerophage Aug 03 '22 at 16:32
  • ahhhh! OK; that is an interesting problem. So, yeah, you still don't need 10× oversampling, but your PWM signal would be easy food for a modern FPGA, so you'd write a minimal amount of glue that converts the PWM into a clean clock signal for modulation, and the PPS extracted from it modulated on top of that. – Marcus Müller Aug 03 '22 at 16:34
  • That could work on the transmit side, but I don't see a way around a high-speed DAC on the receiving end to playback the reconstructed clock. You've given me somewhere to look, at least. Thank you for your input. – aerophage Aug 03 '22 at 16:45
  • same FPGA could do that, basically. A 50 MHz PWM is maybe actually a bit borderline, but there's also higher-end microcontrollers that could potentially do that, though synchronization might be harder with these. – Marcus Müller Aug 03 '22 at 16:46