[Ground-station] Adapting M17 Protocol to Phase 4 Opulent Voice uplink

Robert McGwier rwmcgwier at gmail.com
Mon Jul 4 05:06:58 PDT 2022


Irrespective of the communications channel, which is nearly white Gaussian
(space-link channel),  the interleaver still serves a purpose.  When fades
occur, you will get longish stretches of weaks symbols on the channel, the
actual whitening that occurs is to destroy the concentration of these
symbols all together before they are being presented to the decoder for the
convolutional code which HATES lengths of symbols that are weak and also
longer than the constraint length on the convolutional code.   This really
improves the performance of that decoder over the stream once the
interleaver permutation is done.   Optimal viterbi decoding does its thing
and again, the block code which usually follows corrects those remaining
few errors.

Overall, the approach you have taken is right and necessary.

N4HY


On Sun, Jul 3, 2022 at 12:35 PM Michelle Thompson via Ground-Station
<ground-station at lists.openresearch.institute> wrote:

> Sounds like we are on the right track.
>
> We will do all we can to finish a demo for DEFCON, which is followed
> closely by several other events going into the autumn.
>
> Thank you to everyone for the helpful comments and review of the uplink
> protocol over the past few weeks. It has made a big positive difference.
>
> -Michelle Thompson
>
> On Sun, Jul 3, 2022, 09:16 Howie DeFelice <howied231 at hotmail.com> wrote:
>
>> I routinely demo VoIP calls with Radio over IP interfaces to people via
>> GEO satellite links. The PTT nature of radio helps mitigate the tendancy to
>> overspeak and the brain quickly adapts to the latency of 600 to 700 ms.
>> Having good voice quality is a higher priority than latency in my opinion.
>>
>> Get Outlook for Android <https://aka.ms/AAb9ysg>
>> ------------------------------
>> *From:* Ground-Station
>> <ground-station-bounces at lists.openresearch.institute> on behalf of
>> Michelle Thompson via Ground-Station
>> <ground-station at lists.openresearch.institute>
>> *Sent:* Saturday, July 2, 2022 10:25:12 AM
>> *To:* Michelle Thompson via Ground-Station
>> <ground-station at lists.openresearch.institute>
>> *Subject:* Re: [Ground-station] Adapting M17 Protocol to Phase 4 Opulent
>> Voice uplink
>>
>> Here's a bit more about some performance issues.
>>
>> Puncturing at the decoder increases the number of symbols you have to
>> evaluate before you prune back paths and declare the winning data sequence.
>> Because you have erasures, you have to let the decoder run longer.
>>
>> This can be “bought off” with higher receiver performance. Such as, a
>> faster receiver clock.
>>
>> With interleaving, you can’t buy the latency hit back. There is no
>> arguing with time.
>>
>> If we are going to do space channels, and yes that is what we design for,
>> then they already have high latency - well, this is why there are a bunch
>> of IEEE papers about it and a lot of industry attention.
>>
>> In other words, any additional latency is not appreciated, so there’s
>> been a lot of study on how to design interleavers that don’t cost you more
>> time than absolutely necessary.
>>
>> Two-way live voice is possible at GEO, but not much beyond. Generally,
>> GEO calls require some amount of concentration or training or acculturation
>> to deal with the delay.
>>
>> We already have the idea of using voice memos (like in Whatsapp and
>> Keybase and etc). We have a way to avoid being hung up over voice latency
>> issues. However, any deployment at GEO or below, latency is a factor and we
>> should reduce it when necessary. That's why the selection of interleaver on
>> the uplink is important for us.
>>
>> M17 doesn't care because VHF/UHF communications are local. There is a
>> substantial latency hit with M17, but I don't see anyone complaining about
>> it. This could be due to the fact that all VHF/UHF ham digital voice
>> protocols have heavy overhead, and a lot of delay. M17 isn't snappy or low
>> latency because it doesn't have to be in order to compete in its market.
>>
>> If you have opinions on this subject, please share them so we can get a
>> good solid foundation on our decisions.
>>
>> -Michelle Thompson
>>
>>
>>
>>
>> On Sat, Jul 2, 2022 at 2:49 PM Michelle Thompson <
>> mountain.michelle at gmail.com> wrote:
>> >
>> > Greetings all!
>> >
>> > Here's an update on the uplink.
>> >
>> > Paul KB5MU writes "We’ve concluded that there’s no good reason to keep
>> the code puncturing from M17. As best we can tell, they used puncturing in
>> order to fit their 3200 bit per second voice codec into a conservative 9
>> kHz channel width. We are aiming at a wider channel that has no existing
>> channelization to be compatible with, and we could use the better
>> performance of an unpunctured code. If you see a flaw in this reasoning,
>> speak now to save the puncturing.
>> >
>> > There’s also a design decision to be made on the uplink interleaver.
>> M17 uses a particular quadratic polynomial interleaver. I’m not sure I
>> understand why."
>> >
>> > For those curious about puncturing, it’s used in a variety of ways.
>> >
>> > What is puncturing in the first place? It’s either deliberately not
>> sending a symbol (the smallest unit of information in digital RF signals. A
>> symbol stands for some number of bits of data) or it is the practice of
>> replacing a symbol with some other data to make a sub-channel.
>> >
>> > An example of using puncturing to put in other data is in IS-95, where
>> ever so often, power control commands (up or down) were inserted into the
>> transmitted signal by overwriting a symbol.
>> >
>> > This achieved power control, which is one way to make CDMA much more
>> efficient.
>> >
>> > When you have puncturing with convolutional coding, it’s almost always
>> used to manipulate the code rate. The code rate is the ratio between the
>> data in to the convolutional encoder and the data coming out of the
>> encoder, which is then sent over the air after the data is mapped to
>> symbols.
>> >
>> > For the convolutional encoder used in M17, it’s 1 bit in and 2 bits
>> out, for a code rate of 1/2. If you puncture, or remove a symbol ever so
>> often, then the resulting signal transmitted over the air has a higher code
>> rate. This means you get a higher data rate - the number on the top of the
>> fractional code rate valule.
>> >
>> > M17 has 2/3 code rate (0.666) instead of 1.2 (0.5) because of
>> puncturing.
>> >
>> > We know that to get something in physics or engineering you have to
>> give up something. That is true here as well. Higher code rates mean worse
>> performance at lower signal to noise ratios.Since VHF/UHF ham comms are
>> almost always done at high power, it doesn’t matter much. The vast majority
>> of M17 communications is done with internet links and reflectors, where
>> puncturing is not a factor. Repeaters are generally deployed in a way where
>> the hit to performance from puncturing is not anywhere close to the top
>> item of concern. Anyone accustomed to analog repeaters will notice a
>> performance difference in an M17 repeater, as analog gracefully
>> deteriorates while M17 will fall off a cliff a bit earlier with puncturing
>> than without it.
>> >
>> > The primary purpose of puncturing in this protocol is to reduce the
>> number of bits down to the frame size required by the use of CODEC2 3200
>> bps frames.
>> >
>> > M17 is completely devoted to CODEC2 3200 codec. Everything in the
>> protocol is hard-coded to that particular codec.
>> >
>> > Since we do not have to use such a low-rate codec, and definitely do
>> not want to use such a low rate codec due to the voice quality, we have to
>> rewrite the protocol. M17 is forced to because of datarate limitations for
>> VHF/UHF.
>> >
>> > We use a minimum of 16 kpbs OPUS. We don't have the same regulatory
>> limits for microwave communications. As a side effect of this work, we will
>> be demonstrating terrestrial microwave HTs.
>> >
>> > The interleaver is another story. There’s no multipath at VHF/UHF in
>> the same sense that we have for broadband microwave. Interleaving is
>> required to make a convolutional coding system work to its best ability.
>> Multipath is the source of most burst errors. Burst errors are what
>> interleavers, in general, are used to resolve.
>> >
>> > The way we’ve seen this described is that convolutional encoders are
>> designed for memoryless channels. Multipath introduces errors with memory.
>> >
>> > Rearranging the bits to give space between errors (scrambling or
>> interleaving) turns a channel with memory into the memoryless channel that
>> convolutional encoders really want.
>> >
>> > Since there are no significant burst errors for a 9kHz signal at
>> VHF/UHF, the interleaver doesn’t have much to do. Except one thing -
>> provide an excellent opportunity for education. The greatest value of M17
>> is quite possibly as a protocol that is easy to use over the air in
>> educational settings. It has block coding, convolutional coding,
>> puncturing, and interleaving. While the vast majority of M17 is lifted from
>> P25 (like all the ham digital voice modes) it does simplify things compared
>> to DMR.
>> >
>> > The downside to using an interleaver is delay.
>> >
>> > You also have to have storage.
>> >
>> > You want to guarantee that X symbols are separated by at least Y
>> symbols, then you do have to buffer things up or at least hold certain
>> symbols for their spot in a shift register with a commutator.
>> >
>> > While there is not a whole lot of burst error problems at VHF/UHF,
>> there are definitely multipath issues for microwave broadband terrestrial
>> applications.
>> >
>> > So yes, I think we will need an interleaver for Opulent Voice. But, do
>> we need the one that M17 selected? Quadratic Permutation Polynomials are
>> used in a variety of places, like LTE, for turbo codes.
>> >
>> > We need to look at this QPP and figure out whether it’s overkill or not
>> for what is actually encountered on microwave bands.
>> >
>> > The basic idea from QPP is there’s a linear term that distorts the
>> symbol stream, and then a quadratic term that provides finer “ripples”.
>> >
>> > The classic way of doing interleaving is lining all the symbols up in a
>> matrix and re-distributing rows and columns. You pick how many symbols in a
>> row you want to guarantee separation, and how far apart those symbols must
>> at a minimum now be.
>> >
>> > We can afford quite a bit of hardware here, but the real question is
>> how much latency.
>> >
>> > Comments and questions are welcomed and encouraged.
>> >
>> > -Michelle Thompson
>> >
>>
>

-- 
Dr. Robert W McGwier, Ph.D.
Adjunct Faculty, Virginia Tech
Affiliated Faculty, University of Scranton
ARDC Member of Board
N4HY: ARRL, TAPR, AMSAT, EARC, CSVHFS
Sky: AAVSO, Sky360, Auburn A.S., Skyscrapers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20220704/29ea0bc8/attachment.html>


More information about the Ground-Station mailing list