<div dir="auto">Sounds like we are on the right track. <div dir="auto"><br></div><div dir="auto">We will do all we can to finish a demo for DEFCON, which is followed closely by several other events going into the autumn. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">-Michelle Thompson </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 3, 2022, 09:16 Howie DeFelice <<a href="mailto:howied231@hotmail.com">howied231@hotmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>
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. 
<div><br>
</div>
<div id="m_-6514502891217634854ms-outlook-mobile-signature" dir="auto">Get <a href="https://aka.ms/AAb9ysg" target="_blank" rel="noreferrer">
Outlook for Android</a></div>
<hr style="display:inline-block;width:98%">
<div id="m_-6514502891217634854divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Ground-Station <ground-station-bounces@lists.openresearch.institute> on behalf of Michelle Thompson via Ground-Station <ground-station@lists.openresearch.institute><br>
<b>Sent:</b> Saturday, July 2, 2022 10:25:12 AM<br>
<b>To:</b> Michelle Thompson via Ground-Station <ground-station@lists.openresearch.institute><br>
<b>Subject:</b> Re: [Ground-station] Adapting M17 Protocol to Phase 4 Opulent Voice uplink</font>
<div> </div>
</div>
<div>
<div dir="ltr">Here's a bit more about some performance issues.<br>
<br>
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.<br>
<br>
This can be “bought off” with higher receiver performance. Such as, a faster receiver clock. <br>
<br>
With interleaving, you can’t buy the latency hit back. There is no arguing with time. <br>
<br>
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. <br>
<br>
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.<br>
<br>
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.
<br>
<br>
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. <br>
<br>
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. <br>
<br>
If you have opinions on this subject, please share them so we can get a good solid foundation on our decisions. <br>
<br>
-Michelle Thompson<br>
<br>
<br>
<br>
<br>
On Sat, Jul 2, 2022 at 2:49 PM Michelle Thompson <<a href="mailto:mountain.michelle@gmail.com" target="_blank" rel="noreferrer">mountain.michelle@gmail.com</a>> wrote:<br>
><br>
> Greetings all!<br>
><br>
> Here's an update on the uplink.<br>
><br>
> 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.<br>
><br>
> 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."<br>
><br>
> For those curious about puncturing, it’s used in a variety of ways.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> This achieved power control, which is one way to make CDMA much more efficient.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> M17 has 2/3 code rate (0.666) instead of 1.2 (0.5) because of puncturing.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> M17 is completely devoted to CODEC2 3200 codec. Everything in the protocol is hard-coded to that particular codec.<br>
><br>
> 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.
<br>
><br>
> 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.
<br>
><br>
> 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.<br>
><br>
> The way we’ve seen this described is that convolutional encoders are designed for memoryless channels. Multipath introduces errors with memory.
<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> The downside to using an interleaver is delay.<br>
><br>
> You also have to have storage.<br>
><br>
> 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.<br>
><br>
> While there is not a whole lot of burst error problems at VHF/UHF, there are definitely multipath issues for microwave broadband terrestrial applications.<br>
><br>
> 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.<br>
><br>
> We need to look at this QPP and figure out whether it’s overkill or not for what is actually encountered on microwave bands.<br>
><br>
> 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”.<br>
><br>
> 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.<br>
><br>
> We can afford quite a bit of hardware here, but the real question is how much latency.<br>
><br>
> Comments and questions are welcomed and encouraged.<br>
><br>
> -Michelle Thompson<br>
><br>
</div>
</div>
</div>

</blockquote></div>