Goodbye FT8, Hello Olivia, The MAGIC Digital Mode For HF!

Basically because I never heard of it before you mentioned it, but now it looks like I'm off to the races. Blends my two fave subjects; ragchewing, and NVIS.

 

Respectfully, I'm pretty sure that's not what he is saying. You can't "distribute" clock transitions among the symbols. The clock transitions define the symbols, or at least their edges.

If you look more closely at what he is saying, I believe he is using distributed parity data in the message to help "equalize" the content in a recognizable way, so that Doppler shift can be automatically corrected, along with a very small amount of time slip (60ms). The time slip part is apparently detected by assuming that the base PC clock is mostly correct, and that the transmitter used the same clock, and then sliding the optimization algorithm across the received data with varying offsets, and doing a best-fit to the most likely valid message.

No, not really. A schedule (in ham terms) is a one-time event that has all kinds of allowable slop. A bit clock is something that is repeated with strict and predictable accuracy, and has to track along with the incoming bits. That's not just a matter of scale. That's a matter of concept.

A one-shot isn't an oscillator. Your comparison is essentially comparing a one-shot to an oscillator. It just doesn't work.

Now, if you use a one-shot to discipline an oscillator, and then use that oscillator to discipline your modem clock, then the one-shot has a use in getting the bit-clock right. That's probably the most honest comparison with the real subject, anyway, and it's a realistic way to get a network-disconnected FT8 station working.

But that's where even that situation gets interesting... because...

Even if you used two really accurate clocks to run your FT8 modems, you still have to synchronize those clocks very tightly, and the only way you can do that is out-of-band. No two clocks are quite the same, so you have to repeat the synchronization periodically, whether that's daily, hourly, or whatever. And the repeated act of resynchronizing your local clock to the same master as the other station is implementing a PLL circuit with a really low-pass loop filter, with you in the loop. That is no different than what other data modes do for their clock recovery, except your PLL has to use out-of-band data and components to keep the loop locked, and that means that the mode requiring such external hold-in activity isn't doing clock recovery on the incoming signal. It's using a PLL that relies on another communications channel to stay locked.

And that brings us right back to what I said before, which is that the JT modes don't do clock recovery. They have to have it fed to them on some kind of external channel.

That was a good exercise to work through, though. I'm going to have to hang on to that one...

 

Your right - you keep saying that, but you say it because the clock information is not embedded in the signal:

The recovery of the sync pattern is one of the first things the JT65 decoder does. The FT8 decoder uses a different method I am trying to learn more about, from the program "characteristics" in it's announcement: "Synchronization: three 7×7 Costas arrays (start, middle, end of Tx)". Costas arrays look to be useful in auto-ambiguity functions due to their unique "fingerprint", but the point is that there is synchronization data in the signal.

OK... EVERYTHING prior to you having the QSO has to happen "out-of-band". Clock sync, frequency calibration, program download and install, heck, you can work backwards to the invention of the computer and compiler used, the standards we use, getting your callsign, language, math, etc. You can't decode the signal without first understanding the protocol - that has to happen out of band...

You couldn't have a QSO in 1950 (or today) without the 2 radios being calibrated "out-of-band" to a standard. Calibrating one's rig to WWV was much more common in 1950 than it is today because frequency references used by modern rigs have improved. But there still needs to be a standard. If PC clocks were accurate to a second or so every 10 years, setting the clock from the factory would be adequate for the life of the computer.

I think you're taking this clock recovery to the extreme... the clock IS recovered from the signal. Period. Show me where it isn't. Because you say it's so, doesn't make it true. I have referred to the technical documents that describe the clock recovery methods used, and how they are used. Show us the documentation you state you have read that contradicts this.

 

Good grief, no it isn't. A schedule is just that, whether it occurs once a week, or every 62.5uS. Decoding a timeslot in a DS3 TDMA system 20uS late, or joining a Drake net 20 minutes late leads to the same issue - missed information.

No, I am not. A scheduled event it just that, whether it's the 4th of July with a period of once a year, or a JT65 communications "slot", with a period of 60 seconds. They are repeating events with a measurable frequency.

 

Well, again, I don't think the "sync pattern" he describes is what you think it is. It isn't bit-clock synchronization for determining the edges of the symbols, because you can't "distribute" that the way he describes. The clock and data are definite artifacts that have specific manifestations in the modulated bit stream.

Now you're just being silly for the sake of argument. I'm talking about a specific feature that has to exist for any decoder to operate, not the rest of the kitchen sink you described.

Really? Did you just read your own quote? Let me read that back to you again...

I'm being extreme? Do you have a mirror handy?

Let's stick to the point. Bit-clock recovery has to be done, and it has to identify the edges of every bit transition in the AFSK stream, and it has to happen for every single bit to be useful, and the source of that clock can come from one of two places. The transmitter and receiver can agree to it a priori, or the receiver can extract the bit edges from the received tones. Those are the only two possibilities. You can prove to yourself easily that the latter isn't being done by FT8 or JT65, so it has to be the former, and that can only be done out-of-band. The rate at which the clock drift occurs and is corrected doesn't change that. All other modes do the extraction from the received tones, which means they have no dependency on other communication channels. That's why performance numbers from the two approaches can't be compared.

 

And you all think I'm the one who needs to calm down.

As much fun as this has been, the bottom line is that I have provided a detailed technical explanation of my original (one-line) comment earlier in this thread. A small number of you insist on arguing based on broad generalizations and personal feeling. That's your call, but that's not engineering -- that's just conjecture and opinion. Neither of those make modems work. And neither of those will change based on me further explaining in even more detail how signal processing actually works.

 

Perhaps the biggest issue with the JT modes often quoted SNR capabilities is the channel bandwidth used - usually 2.5kHz - when the actual tone at any instant is only a few Hz wide.

There are a lot of ways numbers can "lie".

 

Which one was that? Was it this one?:

What was that about generalizations?

 

Fair enough, I have a dog in this race. It just so happens that my dog is faster and prettier. So what's your point?

 

I have used Olivia, sadly though not many contacts using it. I do use FT8 if there is no PSK activity. I do however prefer longer contacts and a proper "keyboard" ragchew.

Ade M0OJR

 

Use RTTY.

 

Nonsense.

Joe knows what he is talking about.

The quoted SNR's are extrapolations to the SNR if the the bandwidth USED was 2.5 KHz.

 

I don't think anybody really disputes that. Joe's resume is impressive, and his technical writing ability is obviously very good.

My issue with his modes technically isn't really with anything he has done himself... he seems to have specific reasons for his design choices, and that's all one can expect. The concern I have is how other people attempt to compare those modes to all the other existing digital modes using numbers that aren't comparable, because they represent different kinds of things.

If my technical writing ability was at Joe's level, I would probably have a lot less trouble getting other people to understand that.

 

Like Eric (F1ABE) above with whom I have had many Olivia QSOs on 40 meters, before I go to bed and before he goes to work, Olivia is a a great mode if you want to really communicate.

If you are a ham like me with little space and HOA restrictions that prevent good antennas yet you want to really converse with hams all over the world (that is what attracted me to ham radio more than 50 years ago), Olivia and Contestia are great vehicles for that. I recently had a QSO with a station in New Zealand that had to end after an hour of great conversation because the other station was off the grid and his solar charged battery was running low - it had been overcast that day. We were both running 30 watts with simple dipole antennas.

If you want awards (or actually your computer should get them), FT-8 is great. Our great hobby has so many facets that there is room for nearly everyone. Everyone except those who choose to run 500 watts or more on FT-8 to get DXCC in a month. I hope those operators buy their computers a beer for doing all the work.

Particularly for DX stations in far away interesting locations, wouldn't you like to know about that location and interesting person on the other end of the radio connection? These conversational digital modes are nearly as good as voice on SSB but work when the bands are ugly like they are now due the declining sunspot cycle. You don't have to have a huge budget for big antennas and high power. Or, you may have space limitations and HOA rules like me.

One feature of these modes that needs to be emphasized is low cost. You can get on the air with a very very small budget. Assuming you already have a computer, all you need is a QRP transceiver and a dipole. I started with a 1 watt SoftRock transceiver for about $100, added a Ramsey 5 watt amplifier for less than $50, and a homebrew dipole that couldn't have cost more than $25. With this setup costing less than $200 total, I worked Reunion Island which is exactly half way around the world from me - can't get any further away.

The biggest challenge of any digital mode is all of the moving parts - hardware and software - to get them setup and running. If you are operating FT-8, you have already solved all of those problems and migrating to free software like FLDIGI which supports all of these other great digital modes is easy.

Contestia and Olivia are sister modes that share the same lower level MFSK modulation. Olivia is a bit more robust with weak signals and noise while Contestia runs about twice as fast for a given number of tones and bandwidth by limiting the character set to upper case only (plus a few other tricks). Turn on the RxID (RSID) in your software which will identify that strange sounding signal for you. I use Contestia 8/250 when conditions are passable and migrate to Olivia 8/250 when nothing else works. At 30 WPM and working down to -13 dB signal-to-noise ratio, Contestia 8/250 is just a little slower than my typing speed that lets me fix a few typos.

Give it a try. You won't be disappointed.

Larry
W6LVP

 

Understood - not arguing that it's wrong, it's just that the 2.5k standard is being used for a signal occupying a smaller bandwidth. You can obviously hear signals that are being reported as below the noise floor. Eb/N0 would be a better way to compare the various digital modes we use rather than SNR over a 2500Hz BW.