I need a HF link that will be (mostly hah) operational 24/365. Edit: at least at local daytime. The link is supposed to transmit a controlling signal (just one bit) in one direction for quite a distance (appr. 2000km Edit: appr.2500km) with the lowest latency possible. Due to the latency constrain filtering must not take longer than 1ms, if even 1 ms.

It may be a mistake, but I don't want to use any kind of FM, as it will require constant transmitting, and I only need to send the signal ~100 times a day.

  • I can use directional antennas.
  • I can not use more than 1kW transceivers.
  • I can use several trancievers on differt bands in parallel.

What else can I do? How should I modulate the signal?

P.S. I considered other options, such as GSM, sat, fiber channel, etc, but unfortunately they are not fast enough.

Reliability of 0.8 would be supergeil. (If 0.4 is the very top, I'll have to take it as well)

P.P.S. About the nature of the link - you can think of an experimental setup that generates data, computer processes it in no time and generates an output - 0 or 1 (mostly 0's). On the receiving end there's other setup and it takes this 0 or 1 as an input.

UPD: I guess, I've chosen not the best question statement. Of course, the thing I'd like keep at minimum is the overall latency. As the propagation latency is fixed, we need to sort out the transmitting and receiving latencies, which I'd wish to cram into just ~1ms (however, I've mentioned only receiving part in the original question above). The question is titled as it is in order to avoid (in other cases useful) advices to extend transmitting time to the fantastic values and gain almost 100% reliability.

Add: Given the power, there seems to be a technical contradiction between the transmission duration (and therefore latency) and reliability. Well, I'd like to optimize them both :)

Another thing about the processing latency constraint is the test I made on a couple of Yaesu's that I told about below in comments. The test shown that it've taken about 4ms on the receiving end to process the SSB signal, which seems a lot to me.

Also, I'd prefer to keep the transmitting antenna complex on the smaller side to the possible extent.

UPD2: Now that I've received a couple of such wonderful and clarifying answers, I'd be more than grateful to receive suggestions about specific equipment suitable for making smaller-scale prototype – SDRs and antenna setups.


closed as unclear what you're asking by Marcus Müller, Kevin Reid AG6YO Feb 17 '17 at 16:26

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • $\begingroup$ UPD: for the sake of simplicity (hah again) let's stick to local ~daytime only. Local – is Central Europe. $\endgroup$ – Kamerer Feb 16 '17 at 14:52
  • 1
    $\begingroup$ Well, it takes light about 6.7ms to travel 200km, so what you seek is impossible. Assuming that's not an issue, you'll also need to specify the data rate. You aren't sending just a 0 or a 1, unless you are sending the same bit for all time. If you are sending a 0 or a 1 that changes, that's just normal data like everything else. $\endgroup$ – Phil Frost - W8II Feb 16 '17 at 15:28
  • $\begingroup$ @PhilFrost-W8II 1ms that I specified concerned only processing, not propagation. Well, if we compute average day data rate it will be quite low - as I need to transmit about 100 signals a day. One may think about 1 signal\sec as a margin case, which however turns into 1kbit\s of effective data rate, as Hamsterdave pointed out below $\endgroup$ – Kamerer Feb 16 '17 at 15:44
  • 1
    $\begingroup$ You're still owing us an explanation why processing time is critical even though your path delay is much larger! I think you might be missing a lot of interesting answers by not giving us the bigger picture of what you want to build and what your actual overall latency constraints are. Look at your comment behaviour in the answers: you're admitting there's more that you could have said in the question! So do that, give is the whole idea of what you want to build. $\endgroup$ – Marcus Müller Feb 16 '17 at 17:54
  • 1
    $\begingroup$ @Kamerer there seems to be a technical contradiction between the transmission duration (and therefore latency) and reliability To a first order approximation, the reliability of receiving a bit correctly is a function of how much energy went into that bit. To put more energy in a bit, you can transmit with more power, or transmit for longer. $\endgroup$ – Phil Frost - W8II Feb 16 '17 at 20:47

You state that you need the signal to be processed as quickly as possible, but you don't state how long the signal can take to be actually transmitted. Do you need the entire TX/RX process to occur in that 1mS?

If so, I think it quite unlikely that you'll achieve the desired reliability on HF, regardless of your modulation method. At this point in the solar cycle, 7-10MHz is the only frequency range that is likely to support that long of a link reliably via ionospheric propagation, and even the top end of that range will likely be unusable for several hours a day (in the very early morning hours local time) as the MUF will drop well below 10MHz over night more and more frequently as the solar cycle approaches minimum in a few years. Already it is occasionally dipping down to 8MHz. The low end of that 7-10MHz range will likely struggle to maintain the link during mid-day hours due to high D layer absorption. This seems to mean that the only viable option would be to have a frequency agile system that can determine what band currently supports the link with the available hardware, and that would not be a particularly simple task.

A further (and probably more vexing) problem is going to be noise. If you need the entire TX and RX process to occur that quickly, your signal will never be heard above the ambient noise floor even in the best of circumstances. LOTS of stuff causes bursts of noise across the HF spectrum, with the noise becoming worse as frequency drops. Lightning can be heard for >1,000km even on 7MHz, high energy cosmic rays can cause random static crashes, ionosondes generate rapidly sweeping tones, geomagntic disturbances can wipe out the entire HF spectrum for days at a time with deafening noise and high absorption, and nearby electronics and power transmission systems can create pops, chirps, buzzing, static, and tones varying in frequency and intensity with no real predictability. Your receiving system would have to be able to tell the difference between the signal you sent, and that continuous barrage of random noise, much of which will be similarly brief in duration on any given narrow sliver of spectrum.

That doesn't even touch Sudden Ionospheric Disturbances/Solar flares, multi-path propagation, geomagnetic storms, and atypical ionospheric propagation modes like scatter and ducting that can cause sudden and spectacular variation in received signal strength (variation in received signal strength of >20dB in a matter of seconds is not all that uncommon) and noise level on single frequencies or across the entire HF spectrum at once.

Hams deal with this issue primarily by using extremely narrow signals with a bandwidth of just a few Hz to a few hundred Hz, at low data rates. A JT9 signal is just 9Hz wide, and takes a full minute to send a few hundred bits. It can frequently support contacts >3,000km with just a few watts and a fairly poor antenna, even in marginal conditions. A QRSS30 CW transmission takes 30 seconds to send a single bit, and can support worldwide links with just a few watts on modest antennas in all but the most extreme propagation conditions.

If you can transmit a much longer signal (a few tens of milliseconds at least) and average it at the receiver, a frequency agile system with good antenna diversity may be able achieve quite good reliability when averaging it over days, especially during local winter when thunderstorms tend to be less common (unless you're in the tropics, then you're probably hosed). During the summer or during periods of high solar activity, it could prove more challenging.

If you are constrained to a very fast transmit and receive cycle overall, even a system like WWV/WWVB, which uses tens of thousands of watts on very good antennas, could see 24 hour average reliability swinging from 0% to 50% from one day to the next, and I strongly suspect that achieving better than perhaps 60% would be next to impossible. It is not really exaggeration to say that the entire universe conspires to generate noise on HF.

EDIT: Thinking on this a bit more, it might JUST be possible to make a 1mS frame work at least sometimes using an intelligent, frequency agile system that can evaluate band conditions on the fly to choose 3 or more frequencies to transmit on at once. By combining the signals on multiple frequencies, you could eliminate a significant portion of the random noise, however this would be a rather demanding process. Accomplishing it within the allotted window would be an impressive feat. Large scale ionospheric disruptions, which tend to occur at least once a month and last anywhere from a few hours to a few days would still render the system inoperable, however.

  • $\begingroup$ Thanks for such a detailed explanation! Indeed, transmitting time is another difficult question. I wish I could stow both transmitting and receiving in that 1 ms. (btw, it's more like 2500km, so propagation itself will take 8-9 ms) $\endgroup$ – Kamerer Feb 16 '17 at 14:38
  • $\begingroup$ I got a couple collateral questions. Concerning transmitting: I've heard that high-power transceivers can not start transmitting in a moment, and preparing may take up to 10ms. Is it true and is there a way to avoid this delay? $\endgroup$ – Kamerer Feb 16 '17 at 14:41
  • $\begingroup$ And about filtering: I've tested two Yaesu transceivers located in front of each other and it've taken about 4ms to process the received SSB signal. That was one of the reasons I've asked the original question, may be there're better options in terms of modulation and filtering methods? $\endgroup$ – Kamerer Feb 16 '17 at 14:45
  • $\begingroup$ There is a delay on key down. Latency of the T/R relay can be a few hundred uS (or more), along with any other circuitry, like the CPU registering that the mic switch has been closed. It will be hard to reduce latency on a commercial radio, but you don't need a commercial rig. If all you need is an on/off signal, transmit the cleanest, narrowest carrier you can, no modulation. Such a transmitter could be quite simple. RE filtering: Hardware filters don't eliminate noise on the frequency of concern, only adjacent frequencies. Averaging several frequencies seems to be the only solution here. $\endgroup$ – Hamsterdave Feb 16 '17 at 15:10
  • $\begingroup$ Perhaps the best possible solution would be simply to transmit a continuous carrier and use a narrow frequency shift to indicate a 1. This would eliminate much of the latency within the radio itself, and would permit you to actively monitor the link continuously. If the 0 signal disappears, the link on that frequency is gone. Detecting a 1mS deviation in frequency would still be pretty tricky, that's effectively 1kbaud (which, incidentally, will not be legal on HF in the US). At 300 baud, it might just be possible. $\endgroup$ – Hamsterdave Feb 16 '17 at 15:20

Well the obvious: 2000 km is 6.7 ms at the speed of light, minimum. That's assuming a straight-line path through a medium with velocity factor 1. So a latency of 1 ms is impossible.

Besides that, you can do the obvious things to maximize your chances:

  • use maximum transmit power
  • use the highest gain antennas possible

Minimizing your latency you'll want to implement the demodulation in an FPGA.

You would want to transmit all the time. It's a general rule that the more you know about what you are looking for, the easier it is to find. By transmitting all the time you can maintain synchronization between the receiver and transmitter.

Synchronization comes in many forms. The more obvious are time and frequency. Path polarization on HF is changing all the time, so you'll also want to use an adaptive array to mitigate this. An adaptive array will also mitigate multipath interference, which is also constantly changing on HF. Transmitting all the time allows the parameters of that array to already be synchronized when it comes time to transmit the bit.

You can use simulations like VOACAP to predict what bands will work best at which times of day. You'll want the capability to switch bands dynamically, since conditions often deviate from the predictions. You'll also need to avoid interference from other stations. Transmitting all the time, you can negotiate the best frequencies before you need to send the bit.

Frequency diversity is a good idea. Although spreading the signal out over a wider bandwidth increases the noise power in the channel, the signal among all the possible frequencies is coherent, achieving a process gain that offsets the loss from increased noise power. This doesn't improve your SNR at all, but it does make your signal more robust against narrow-band interference and fading.

You might experiment with including multiple bands in your frequency diversity, though there's a tradeoff between diversity and wasting some of your transmit power on a band that's not the most effective. If you're using the idle time to dynamically find the best band, it might be better to concentrate all the power into the band you've determined works.

As far as modulation, I don't think there's anything unique about your situation. Just pick some existing modulation and transmit zeros until you need to transmit a 1. To reduce the latency you would want to pick a symbol rate much faster than 1/1ms so you don't waste time waiting for the next symbol to start. But when the event happens, you can transmit consecutive 1s. The receiver would then count the number of 1s versus 0s, and make some decision based on that.

You have a tradeoff to make between latency and accuracy here: some of the bits will be wrong, so if you trigger on just one 1 bit, you'll get false triggers. Waiting for a larger number of consecutive 1s will increase accuracy, but you'll have to wait longer to reach that threshold.

All these things together, you shouldn't have any difficulty achieving your goal, except when solar storms knock out the entire HF spectrum. Even then, you might overcome it with brute force. With a 1kW transmitter (60dBm) plus a 10dB gain antenna on each end, you have an EIRP of 80dBm, which is huge. HF path loss predictions such as VOACAP don't assume adaptive arrays, so add maybe another 2-8dB of diversity gain.

This is just an insane amount of power, and with adaptive techniques you should be able to mitigate most of the things that could go wrong to a large extent. In fact, you probably want to use the adaptive logic to reduce power under most situations, both to avoid overloading your neighbor's receivers, and also to reduce your electric bill.

  • $\begingroup$ Thank you! Your suggestions gave me some hope. As the setup seems to need a lot of experimentation, I'd like to turn to couple of down-to-earth questions and dare to ask some recommendations about the actual equipment. Not the final super-powerful stuff, but only enough to conduct shorter range small-scale yet realistic tests. $\endgroup$ – Kamerer Feb 16 '17 at 17:32
  • $\begingroup$ So could you recommend some FPGA-based SDRs (I guess using SDR is a good option given all said) and antennas suitable for a prototype? I haven't mentioned it before, but I'd like to keep the transmitting antenna complex on the smaller side to the possible extent. $\endgroup$ – Kamerer Feb 16 '17 at 17:32
  • $\begingroup$ @Kamerer I don't have a lot of experience with FPGA SDRs, but all the higher-end (say, over $800 USD) pretty much have them. You'll need custom programming though, which narrows the field. HPSDR is an open design so anything is possible. You might try asking in chat. $\endgroup$ – Phil Frost - W8II Feb 16 '17 at 17:41
  • $\begingroup$ At these rates, unless we're doing incredible complex stuff, any dedicated microcontroller will probably achieve that 1ms latency. Still, the question really is, why exactly do you have that latency constraint? See my comment under the question $\endgroup$ – Marcus Müller Feb 16 '17 at 17:59

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