2
$\begingroup$

This question has been suggested in the comments to a closed question a couple of days ago. I have nothing to do with the original question, but this aspect of the problem made me quite curious, so it would be great if someone could make an attempt at answering it. The context of the question is long-distance transmission over HF.

No particular constraints on locations, equipment or power other than those following from amateur radio regulations (HF: mostly 400W maximum power), but more efficient (low-cost or low-power) and more reliable solutions are preferred. The time between start of transmission and finished decoding shall not exceed 4 ms.

Assume that no communication channel has yet been established, and no additional infrastructure is to be used besides a transmitter and a receiver.

Assume there's no need to decode the callsign

$\endgroup$
  • $\begingroup$ so, added latency: added to the transmission duration, or after that? $\endgroup$ – Marcus Müller Jun 29 at 13:04
  • $\begingroup$ I was thinking of the latency between the start of the signal and its recognition with reasonable certainty (99% if you want a number). I've removed the word 'added' from the title for clarity. Also, the 4ms is just something I copied from the other question, so that's not set in stone if a different number makes more sense. I guess what I'm interested in is the general principle of transmitting a very short message through a very unreliable channel with low latency. Finally, I realise that regulations will also require sending identification, but that can be done after the 1-bit payload. $\endgroup$ – zrnzvxxy Jun 29 at 13:26
  • $\begingroup$ well the identification will inherently be much more data than the payload, so how many bits in total? $\endgroup$ – Marcus Müller Jun 29 at 14:03
  • 1
    $\begingroup$ Ignore the id for the purpose of the question. Just assume it will be sent in whichever way is most convenient and complies with applicable requirements. But the receiver should recognise the 1-bit message before the id gets sent. $\endgroup$ – zrnzvxxy Jun 29 at 14:10
  • 1
    $\begingroup$ define QRP: For me, it's < 1 mW, other people tend to have other opinions ;) $\endgroup$ – Marcus Müller Jun 29 at 16:59
4
$\begingroup$

So, I'll go ahead and include the callsign, if we're sticking to regulation, in what needs to be decodable (though not necessary within the 4 ms). I'll also assume 4ms is from the point in time the signal starts reaching the receiver until it knows what was sent. Makes no sense to include the propagation delay: 4 ms is only 1200 km of distance at speed of light, and the original question was about 10000 km (and HF travels slower than vacuum speed of light).

WSPR reserves 28 bits for a callsign, and that seems about right, so I'll go with that.

Together with a 1 bit payload, that makes 29 bit.

We have 400 W in 4 ms, so we can send 4·10² W · 4·10⁻³ s = 1.6 Ws = 1.6 J. Not bad at all!

What matters at the receiver is that we make the right decision about having detected a 0 or a 1. That's an data estimation from a noisy observation, and that's pretty simple to model: We receive something, quantify it as a number, and mark somewhere that "left of this mark, it's a 0, right of this mark, it's a 1". All we have to find is a sensible method of mapping our received signal to a number, then find the optimal place to set that decision boundary.

Now, we have to deal with noisy reception. That means that the receiver can never be actually sure what was sent, because the received signal is added to noise.

We can put a number on how likely it is that it was wrong, a bit error probability, however, on a system, as soon as we understand how the noise amplitudes compare to the signal amplitudes.

Typically, this looks like this:

Say, this is your noise probability density function (PDF). Noise is a bit unnerving, because it's not a deterministic thing: Noise is by definition random. We can't know what its value is, and we thus can't simply subtract it from what we've observed. But we can describe that random variable by its pdf:

Normal distribution PDF
Normal PDF, Tmennink / CC BY-SA

You need to read it as such: "The probability that the noise amplitude is between 1 and 2 is the area below the curve, below the points (on the horizontal axis) 1 and 2", or "The probability that the noise takes a value lower than -2 is the area under the curve (that's an integral, by the way) from -infinity to -2", or "The probability that an absolute amplitude no higher than 1 ocurred is the area between -1 and +1".

Let's do an example; imagine this: you know that your transmitter sends a positive +1 to signal a "0" bit, and a negative -1 to signal a "1" bit.

However, you don't know how much your channel attenuated your signal. So, your +1/-1 might have been shrunk to +0.1/-0.1 or to +0.00000000000001/-0.00000000000001(= +10⁻¹⁴/-10⁻¹⁴) (more realistic for a long range channel...).

You observe a negative value -0.45. What was sent?

  • Either, a negative -amplitude was received, and the noise didn't add enough to make it positive, so that you're still seeing the negative value, or
  • a positive +amplitude was received, but the noise added enough negative amplitude, so that the noise converted your positive value to the negative -0.45.

Both happens in reality. So, we can't be sure. What that looks like in the terms of the above plot is that if we know that a +amplitude reached us, we know that the value of signal + noise amplitude has the same pdf as noise, but with the horizontal 0 point shifted right to +amplitude, so that the "bell" now is centered around the actual received signal.
The same happens when -amplitude reaches us, but in that case, the noise pdf bell curve is shifted to the left:

Conditional PDFs

We never see that bell, it's just a hidden property of the random variable "receiver output", but that allows us to reason about things:

Of course, we want to make a decision that makes most sense. In our example, that means we'll assume that +amplitude was sent when we observe an $r$ right of the vertical axis, and -amplitude when we observe an $r$ left of the vertical axis. But note that this is only true if we assume both to be equally likely, and if our PDF is symmetrical! (this is the Maximum-Likelihood estimator, by the way.)

This lets us reason what influences the probability that we make an error. It's two things:

  1. the width of these bell curves. If they get wider, more of the area "laps" over the vertical axis, and that's our error probability! In terms of probability theory, the width of the curve is proportional to the square root of the variance of the noise, which is the same as noise power.
  2. the distance between +amplitude and -amplitude. The wider we put them apart, the less of the bells lap over to the other side, and the lower our error probability gets. Since we can't modify the channel, the attenuation is given, and the only way to influence the received amplitude is to increase the transmitted amplitude proportionally. Sadly, amplitude is the square root of signal power, so this find legal and technical bounds quickly.

What this shows us is that to design a system for a given error probability (99%, in your case), we need to think about the ratio of power in the received signal, and power of the received noise.

Now, if we really encode the one payload bit separately from the 28 callsign bits, that's a bit energy $E_b = 1.6\,\text{J}$.

Let's say we have an attenuation $a$ over the channel (in fact, $a$ will very much depend on the time of day, sun activity, weather, mood of your cat, …, so we'll have a probability distribution for a random variable $a$, and we need to pick $a$ such that it's at least as good as that 99% of times).

That means of the 1.6 J, a·1.6 J reach the receiver.

The receiver has a noise floor density $N_0$, a noise power per bandwidth. Now, bandwidth is an inverse of time, so that the physical entity $N_0$ is indeed power times duration, i.e. has the same physical meaning as the bit energy.

Hence, $E_b/N_0$, energy per bit to noise power spectral density ratio, is dimensionless. Makes sense: if we send more bits per second, we get proportionally more bit energies per unit of time, but we need proportionally more bandwidth, and with noise being white, we get proportionally more noise power.

So, doesn't really matter how much bits per second we send; the $E_b/N_0$ value is defined by the transmit power and the unit-bandwidth noise variance.


I'll now tell you something that you might have guessed all along: Physics doesn't exacly like us. Physics has it that every device at room temperature sees a noise power density of -174 dBm/Hz = -204 dBW/Hz (that's $10^{-17.4}\,\text{mW/Hz}=10^{-20.4}\,\text{W/Hz}$).

Also, receivers aren't perfect. So, we can add 2 to 4 dB of noise figure to that, which is roughly a factor of 2.

So, sadly, it's not for us to choose 1., the noise variance, in what determines the probability of error.


That leaves us with choosing 2, the power of the received value.

Armed with a table for the integrals of the bell curve we've shown above, we can look up the $E_b/N_0$ value that we need for a given maximum error probability.

This table can be put into a plot: The BER curve. If we receive +1/-1, we call that BPSK, and the BER curve looks like this:

BER curve BPSK
from DSPLog

We can see that for your acceptable BER of 1/1000 = 10⁻³, we need an $E_b/N_0$ of about 7 dB.

That means that, since our $N_0=-204\,\text{dBJ}$, our $E_b$ needs to be at least $-197\,\text{dBJ} = 10^{-19.7}\,\text{J}$.

We can transmit 1.6 J of energy legally for that single bit. As long as far-range transmission doesn't impose more than about 196 dB of attenuation, we're fine.


I don't know current channel conditions on say the 40 m band. I really don't. If someone has a current table that says "with a probability of x, we see such and such an attenuation", I could tell you what is OK to assume in your 99% of cases. (By the way, that would again take the form of a PDF, not of noise as random variable, but as the channel attenuation as random variable.)

What I do know is that we don't know the channel beforehand. That means we don't know the phase that the channel imposes on us (which simply depends on the exact length, and medium effects, reflections and so on). Since that includes 180° phase shifts, we can't just transmit a single +1 or -1 with a high power, because the receiver simply couldn't tell the sign.

Also, we're far from the only people to use that band. So, just sending a tone will not work out – other do the same, and suddenly our noise isn't only the receiver noise, but also the interference from others.

So, what we need to do is to give our signal

  1. as long-as possible shape to maximize power
  2. a as-unique-as-possible shape to maximize "identifiability" among interfering signals.

The standard way of doing that is spreading the signal. So, you use a spreading sequence. Say, $+1, -1, +1, -1$. You multiply what you want to send, let's say the $+1$, with each element of that sequence. You then send the result, but with only 1/(length of sequence) of time per resulting number, so that you still send the same amount of "payload" bits per time.

At the receiver, you take the same spreading sequence, and multiply every value you receive with it, and sum up. You correlate. For example, you receive $0.2, 0.1, 0.1, -0.5$, and you know the spreading sequence as specified above. Then you calculate the sum: $0.2·(+1)+0.1·(-1)+0.1·(+1)+(-0.5)·(-1)=0.2-0.1+0.1+0.5=0.7$
Notice how 0.7 is larger than any of the noisy values you received, individually? That makes sense: the $+1,-1,+1,-1$ "content" was multiplied with itself ($(+1)·(+1)+(-1)·(-1)+(+1)·(+1)+(-1)·(-1)=1+1+1+1$, which gives you 4, i.e. the length of the sequence.

Sadly, you mustn't forget that in order to convert that single bit into four bits and transmit them, you had to use only one quarter of the original energy for each transmitted bit. But, since you added up signal, which was always the same, your signal gain is quadratic, whereas your noise gain only linear to sequence length. You generally gain SNR as a function of the length of the sequence.

That's exactly how cheap-as-hell GPS receivers can fish GPS signals from far, far below the noise floor.

A big bonus of using a sequence is also that you can use a unique one. Which means that if you correlate with some signal that wasn't shaped with the same or a similar sequence, it, just like noise, doesn't add up constructively. So, you can "isolate" your receiver from interferers. Neat!

Now, it seems intuitive that you'd want to spread as much as possible. Make your sequence a million elements long. Be totally unimpressed by any interferer.

Sadly, you need to send more symbols the longer your sequence get. Where we had 1 bit that took 4 ms to begin with, equivalent to 250 bits per second, we'd need to transmit 250 million bits per second. Since we can't transmit more than 1 symbol/s/Hz, that would require us to use a bandwidth of at least 250 MHz (assuming binary symbols). You can't get that bandwidth around 7 MHz...

Another problem with bandwidth: you'd also need to make sure that if your signal finds more than one path to your receiver, the "later" copy of the symbol doesn't disturb the next symbol. (We call that inter-symbol-interference, ISI.)

There's three ways of managing that:

  1. Simply don't. Your symbol rate needs to be low enough that all copies land in the same symbol, because the symbol is just so looooong. But that means no or little spreading.
  2. Take your wide channel and say: "hey, if I act as if this wide thing, in which symbols are so short that the echos overlap into the next one, is actually many narrow channels next to each other, and I divide my input data into these channels evenly", you've solved the hard ISI-problem by reducing it to many, "how do I deal with these many different easier channels"-problem. That's what OFDM does. And that's what Wifi, LTE, DVB-T, DAB+, but also HF modes like DRM+ and FreeDV do.
  3. Use an Equalizer. That's an algorithm that needs to estimate when later copies come in, and then adds them to the first copy and subtracts them from the symbol that they leaked into.

The first option is not an option. This system won't work without identifiability.

The second option requires a separate decision of what was sent on many channels, and requires that you really send enough data to even fill all the subchannels. Also, we can't really do many subchannels: our frequency resolution is 1/duration, duration is limited to 4 ms, so our channel spacing is 250 Hz, at least. We have at most 2700 Hz of overall bandwidth in the 40 m band, so that's at most 10 channels (there's some non-negligible overhead for such methods). 10 is not "many" subchannels. (Really useful would be 128 to 4096 or something like that).

The third option sounds best, but it requires that you estimate the channel impulse response, so that it can be reverted by the equalizer.
Now comes why it's bad to not consider the callsign alongside with the 1 bit of info:

If we need to send 29 bits in total, sending 1 bit of known preamble to allow the receiving end to identify the properties of the channel doesn't hurt much – it's less than 4% of the energy we would have invested to send the over the whole shabang. If we only send 1 bit, then that 1 bit of preamble means 50% of energy lost to channel estimation. Ouch.

Also, remember the BER above? Yeah, that's not optimal. If your $E_b/N_0$ isn't outright terrible (which we can avoid, with but a bit of spreading), and you transmit enough bits (1 doesn't allow for much) we can apply channel coding with an forward error-correcting code (FEC) to make that line better, i.e. needing less bit energy for the same amount of data. That "blows up" the amount of data you need to transmit by a factor of $1/R>1$. The good thing about error-correcting codes is that they are even more efficient than spreading at converting more bandwidth into better $E_b/N_0$, but they can't help you much with telling your signal from noise or other people's signals.


So, all in all, your transmitter would likely look like this:

  1. Add robust error correction coding to all your 29 bits that you needed to send (that's a rate of (1/R)·original rate)
  2. Use a relatively benign spreading code (maybe, length 32) to reduce the likelihood of misidentifying your signal (rate 32·(1/R)·original rate)
  3. Use a modulation that doesn't require you to intensely estimate the channel beforehand. For HF, FSK modes have proven to work well (won't go into the math why, but there's plenty of math to show that's the case). Using FT-8 as a guideline, say, 4-FSK, ie. every symbol you transmit carries 2 bits ($=\log_2(4)$). (symbol rate = 1/2·32·(1/R)·original rate)
  4. Since we're very time-constrained, we decide to use the full 2700 Hz channel, and divide it into as many parallel channels as possible to achieve the complete transmission in 4 ms = 1/250 s. That means, we need the number of channels to be 16/R. R would realistically be something like 1/2, so 32 subchannels (each of which does a 4-FSK) doesn't sound so bad. 2700 Hz / 32 = 84 Hz per subchannel bandwidth.
  5. add a bit of overhead everywhere: you're now collecting all energy of the full band in your receiver. It's not even question anymore whether you will have an interferer that has far more power than your transmitter in there, but only how many.

Notize how the FT-8 bandwidth is 50 Hz, and thus pretty close to that 84 Hz? Makes a lot of sense, FT-8 is meant to be nice for many people playing together at the same time, and doesn't have a (hard to ridiculous) 4 ms constraint.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Wow, many thanks for this detailed and very instructive answer! I really appreciate it! I still have a few questions. (1) In the first part, I understand the estimation procedure, but what is +amplitude and -amplitude? With FSK, wouldn't you measure an amplitude for each of your symbol frequencies at any time? (2) "for your acceptable BER of 1/1000 = 10⁻³, we need an 𝐸𝑏/𝑁0 of about 7 dB" -> that should be $10^{-2}$ and 4dB, right? $\endgroup$ – zrnzvxxy Jun 29 at 22:01
  • $\begingroup$ (3) "our frequency resolution is 1/duration, duration is limited to 4 ms, so our channel spacing is 250 Hz, at least" - sounds totally right, but where does it come from? And how is is compatible with the 84 Hz channel spacing mentioned later on? $\endgroup$ – zrnzvxxy Jun 29 at 22:03
  • 1
    $\begingroup$ (1) the example was indeed pretty much the BPSK receiver problem as sketched, but if you use +amplitude as the output of your frequency detector, it works for FSK, too. (however, the noise wouldn't simply be the additive gaussian noise with the nice bell curve I showed, so that's harder to quantify exactly). (2) 10⁻² is your target, but since we need to use one and the same system for every time of the day, my approach was "use something that works 1-10⁻³ of times at the target SNR, and then look up a channel "quality" that we can achieve (1-10⁻³)·(1-10⁻²)~=1-10⁻² of times". $\endgroup$ – Marcus Müller Jun 30 at 6:49
  • 2
    $\begingroup$ is a spreading code really a good idea on an HF channel? At 4ms, you're already going to be grappling with ISI on some paths. If you boost the symbol rate by a factor of 4, won't that be an even bigger problem? If what you're after is some resistance to narrowband interference and frequency-selective fading, maybe OFDM would be a better route? $\endgroup$ – Phil Frost - W8II Jun 30 at 19:29
  • 1
    $\begingroup$ VOACAP Online is one way to estimate path loss. For instance, a station transmitting 1500W in Frankfurt on 40m should have a received signal strength in Memphis, Tennessee at 03:00 UTC tomorrow of about -123 dBW, if I'm reading the results correctly. 1500 W is +32 dBW, so the path loss using "typical" antennas (dipole @ 10 m for TX, vertical over "good" ground at RX) is projected to be ~154 dB. This is the output of a simulation, so it's probably a reasonable estimate, but from personal experience I know that real-world results will vary considerably. $\endgroup$ – rclocher3 Jun 30 at 22:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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