Can wireless communciation be synchronous?
Yes. Kind of, at least.

As you're coming from a wired background, I'll build the analogy from there:

Where UART only works because  receiver and transmitter clocks are similar enough so that, for a short burst of bits, they don't drift apart, the same applies to wireless digital communications.

If your symbol rate is low enough, and the receiver knows exactly the symbol rate the transmitter uses, then the receiver can extract the symbols without first running logic to do clock recovery.

In high-rate, mobile and streaming systems, generally, this can't be assumed: no two oscillators in this universe are exactly the same, and hence, when you transmit many symbols, you must make very sure that the receiver has the same sample clock as the transmitter.

Now, if you tried to take the equivalent of SPI to the wireless domain:


Data signal
Square wave clock signal


you'll notice that the square wave clock signal has a really bad spectral shape – it has infinite bandwidth, and even if you accept some "rounding" on the edges, you'd still need about 5 to 7 times the actual data signal bandwidth to transport your square wave.

Hence, that is generally not done.

I'm sure earlier wireless comms had some sort of secondary carrier that was used to derive a symbol clock, but I haven't seen that in any modern standards.

You can either go what I'd call (and this is a term I just invented) the "synchronized asynchronous" route:


send a preamble of known signal, which allows the receiver to estimate its own rate relative to the rate of the transmitter, and just work from there for the duration of a burst


or the "continuous clock recovery control loop" way.

The second one is really done in a lot of different ways, depending on what system you're looking at, and how complex the designers could afford to make the receiver. 

One very typical scheme is that you realize that all digital communications are in essence pulse-shaped.

Without having the time to go fully into that: You really can't send infinitely short pulses with amplitude +1, -1, -1, +1, -1, +1 ... over a channel of finite bandwidth.

Hence, you apply a pulse shape, which serves to smooth the transition between these; the idea is that still, at the exact symbol times, the values are exactly the symbols you wanted to send, but in between, there's a smooth, bandwidth-limited exchange.

You'll already recognize this if you've worked with wired buses: you know the eye diagram. The exact same diagram is used in wireless communications, though, typically, for a good short-run wired communication, you'd expect the eye to be nearly square, whereas the pulse shaping with a rounder shape is intentional (albeit necessary, too) from the beginning in wireless comms.



This, very geometrically, implies that at the exact right times, your signal "shape" has extrema, i.e. places where your derivative is 0. 

You can now build a mechanism that looks at the slope of the signal at the times you assume your symbol times to be. If that slope is negative, oh, we're too late, better sample a little earlier, if it's positive, sample a little later. Notice that this isn't the case for all symbol transitions (same-symbol transitions usually do not have the maximum amplitude at the correct sampling time), but it's the case for most transitions, usually.

Do some minimal statistics, and you can make this adjustable to a (small) symbol rate error.

So, we wireless comms folks invest bandwidth that we could be using to transmit information (which is what we're getting paid for) into making the symbol rate synchronizable. It's not a direct equivalent to a "synchronous bus" in the wired world, because aside from a few especially strange systems that I'm sure exist (dear reader, if you know one, let me know in the comments), we'll be sure to avoid having a separate symbol clock carrier. But it's essentially the same idea: having a way of shoving the information about when the symbols should be sampled into the receiver.