Re: [Freetel-codec2] FreeDV Tx power PAPR- SM1000
Hi Greg I did mention that I was only considering computing the PAPR, and then if it exceeded some threshold, produce a new sequence... On the likelihood you wont get another bad one. IE a gamble. I'm interested that you are considering what can be done at the receiver end to improve performance. g On 6/22/2020 3:05 PM, Greg Maxwell wrote: On Mon, Jun 22, 2020 at 4:55 AM glen english wrote: One thing to consider- accurate PAPR measurement (by a receiver) is hard at low SNR. That is one of the nice things about FEC based PAPR reduction, the receiver doesn't need to measure PAPR yet it exploits the PAPR reduction regardless. Think of it this way: The sender adds redundancy to improve PAPR but if the redundancy is FEC efficient then it is free in a BER vs SNR sense. And this holds even if the transmitter wasn't PAPR limited. Tone reservation is probably the lowest cost means for this setup. And backward compatible. Absolutely there. Though I don't see a way for the receiver to exploit the pilot tone. So it's only a win to the extent that it lets you increase the output amplitude. Remapping as I described this morning is probabaly reasonable, also- --given that LDPC encode is approximately a LUT and the FFT (DFT?) is very short. Codec2 frames I think are a little too long for an entirely brute force approach to work. (By brute force, I mean, consider all possible OFDM words, select the 2^(code2_bits) codewords with the lowest PAPR, an map them to the codec 2 frames... then use a maximum likelyhood decoder). ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2 -- Glen English RF Communications and Electronics Engineer CORTEX RF & Pacific Media Technologies Pty Ltd ABN 40 075 532 008 PO Box 5231 Lyneham ACT 2602, Australia. au mobile : +61 (0)418 975077 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] FreeDV Tx power PAPR- SM1000
On Mon, Jun 22, 2020 at 4:55 AM glen english wrote: > One thing to consider- accurate PAPR measurement (by a receiver) is > hard at low SNR. That is one of the nice things about FEC based PAPR reduction, the receiver doesn't need to measure PAPR yet it exploits the PAPR reduction regardless. Think of it this way: The sender adds redundancy to improve PAPR but if the redundancy is FEC efficient then it is free in a BER vs SNR sense. And this holds even if the transmitter wasn't PAPR limited. > Tone reservation is probably the lowest cost means for this setup. And > backward compatible. Absolutely there. Though I don't see a way for the receiver to exploit the pilot tone. So it's only a win to the extent that it lets you increase the output amplitude. > Remapping as I described this morning is probabaly reasonable, also- > --given that LDPC encode is approximately a LUT and the FFT (DFT?) is > very short. Codec2 frames I think are a little too long for an entirely brute force approach to work. (By brute force, I mean, consider all possible OFDM words, select the 2^(code2_bits) codewords with the lowest PAPR, an map them to the codec 2 frames... then use a maximum likelyhood decoder). ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] FreeDV Tx power PAPR- SM1000
Hi Greg RRR One thing to consider- accurate PAPR measurement (by a receiver) is hard at low SNR. Tone reservation is probably the lowest cost means for this setup. And backward compatible. Remapping as I described this morning is probabaly reasonable, also- --given that LDPC encode is approximately a LUT and the FFT (DFT?) is very short. On 22/06/2020 2:17 pm, Greg Maxwell wrote: On Sun, Jun 21, 2020 at 9:51 PM glen english wrote: I was giving some thought to how PAPR reduction might be implemented within the current framework, taking into account the limited capability of the SM1000 processor. One thing to perhaps consider is the ease at which a sufficiently advanced receiver can use the PAPR correction to enhance its own signal: The receiver knows that what the sender sent was PAPR reduced, and so it should be able to use this to enhance its demodulation. Constant envelope single carrier signals you can pretty much directly derive an equalizer from recovering the constant envelope using the constant modulus algorithm. There are many papers on using forward error correction schemes to reduce PAPR, with the idea being that you choose a scheme and constellation mapping whos valid codewords have lower PAPR. Then simply applying error correction exploits the sender's signal constraint. ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2 -- Glen English RF Communications and Electronics Engineer CORTEX RF & Pacific Media Technologies Pty Ltd ABN 40 075 532 008 PO Box 5231 Lyneham ACT 2602, Australia. au mobile : +61 (0)418 975077 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] FreeDV Tx power PAPR- SM1000
On Sun, Jun 21, 2020 at 9:51 PM glen english wrote: > I was giving some thought to how PAPR reduction might be implemented > within the current framework, taking into account the limited capability > of the SM1000 processor. One thing to perhaps consider is the ease at which a sufficiently advanced receiver can use the PAPR correction to enhance its own signal: The receiver knows that what the sender sent was PAPR reduced, and so it should be able to use this to enhance its demodulation. Constant envelope single carrier signals you can pretty much directly derive an equalizer from recovering the constant envelope using the constant modulus algorithm. There are many papers on using forward error correction schemes to reduce PAPR, with the idea being that you choose a scheme and constellation mapping whos valid codewords have lower PAPR. Then simply applying error correction exploits the sender's signal constraint. ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] FreeDV Tx power PAPR- SM1000
actually the majority of SSB generators ARE reasonably phase coherent over a relatively moderate passband with respect to their total passband. The group delay 'ears' are on the edges of the filter. staying between 600 and 2200 Hz should be OK for a 2400 Hz wide traditional lattice sideband filter that os placed with the lower passband edge at 300 Hz. Of course, new radios are all like a piece of wire. On 22/06/2020 8:58 am, Al Beard wrote: Hi Glen and all, There's something I don't understand here: In the SM1000 we have control of all the amplitudes AND phases of all the audio carriers. Thus we may be able to do something to reduce the peak levels that an IDEAL SSB generator will produce. This is where I have a problem, the majority of SSB transceivers do not have an ideal SSB generator. In particular, we loose the phase consistancy. Am I correct? Alan VK2ZIW On Mon, 22 Jun 2020 08:33:18 +1000, glen english wrote Alan it already goes through an SSB generator, and is already bandwidth constrained. The bandwidth expansion because of an excess PAPR event occurs where the signal cannot be faithfully reproduced- that is stages beyond the sideband modulator- mostly the power amplifier, but in reality all the way up the driver chain On 22/06/2020 8:15 am, Al Beard wrote: Hi David and Glen, Just how is this going to be effective when the audio signal is passed through an SSB generator? You will also have to, in the maths, factor this in. Am I wrong here? ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2 --- Alan Beard OpenWebMail 2.53 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2 -- Glen English RF Communications and Electronics Engineer CORTEX RF & Pacific Media Technologies Pty Ltd ABN 40 075 532 008 PO Box 5231 Lyneham ACT 2602, Australia. au mobile : +61 (0)418 975077 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] FreeDV Tx power PAPR- SM1000
Hi Glen and all, There's something I don't understand here: In the SM1000 we have control of all the amplitudes AND phases of all the audio carriers. Thus we may be able to do something to reduce the peak levels that an IDEAL SSB generator will produce. This is where I have a problem, the majority of SSB transceivers do not have an ideal SSB generator. In particular, we loose the phase consistancy. Am I correct? Alan VK2ZIW On Mon, 22 Jun 2020 08:33:18 +1000, glen english wrote > Alan > > it already goes through an SSB generator, and is already bandwidth > constrained. The bandwidth expansion because of an excess PAPR > event occurs where the signal cannot be faithfully reproduced- that > is stages beyond the sideband modulator- mostly the power amplifier, > but in reality all the way up the driver chain > > On 22/06/2020 8:15 am, Al Beard wrote: > > Hi David and Glen, > > > > Just how is this going to be effective when the audio signal > > is passed through an SSB generator? > > > > You will also have to, in the maths, factor this in. > > > > Am I wrong here? > > ___ > Freetel-codec2 mailing list > Freetel-codec2@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 --- Alan Beard OpenWebMail 2.53 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] FreeDV Tx power PAPR- SM1000
Alan it already goes through an SSB generator, and is already bandwidth constrained. The bandwidth expansion because of an excess PAPR event occurs where the signal cannot be faithfully reproduced- that is stages beyond the sideband modulator- mostly the power amplifier, but in reality all the way up the driver chain On 22/06/2020 8:15 am, Al Beard wrote: Hi David and Glen, Just how is this going to be effective when the audio signal is passed through an SSB generator? You will also have to, in the maths, factor this in. Am I wrong here? ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] FreeDV Tx power PAPR- SM1000
Hi David and Glen, Just how is this going to be effective when the audio signal is passed through an SSB generator? You will also have to, in the maths, factor this in. Am I wrong here? Alan VK2ZIW On Mon, 22 Jun 2020 07:49:45 +1000, glen english wrote > I was giving some thought to how PAPR reduction might be implemented > within the current framework, taking into account the limited > capability of the SM1000 processor. > > If we approach this on trying to constrain the statistical > likelihood of a PAPR event (where the peak power exceeds some value > ) : > > (That is, we accept that PAPR control is acheived some % of the time > and other times we ignore it ) > > For each OFDM frame, the sequence is generated and the PAPR computed > . This will yield a PAPR envelope for the OFDM frame. > > and: > > suggestion 0) : Implement tone reservation. This can work > effectively for low OFDM carrier counts, like FreeDV OFDM. > > A single carrier is used (not necessary from the FFT), and it's > phase and amplitude are set so that the PAPR event is substantially > neutralized. An extension on this is that multiple carriers (say > one at the bottom, one at the top of the ensemble) can be used to > synthesize a more faithful cancellation . This would also be > backwards compatible if outside the OFDM sync/eq etc frequency bounds. > > suggestion 1) Choose a different scrambling code for the encoded > voice, re-run the FEC and FFT, and use it. It is highly probable > that the PAPR event will be lower. In choosing a different code, and > of course the data FEC frame runs over a number of OFDM frames ( I > think ??) the FEC and FFT will need to be re run over a number of > frames. Some overhead will be required to signal the decoder to use > the different descrambling code. Of course with our new 'blind' > option, we might lose and PAPR might be worse. In that case, a > 'squash' wideband clipper should be used to generated an > instantaneous gain reduction of the entire ensemble. > (This is a detector with the detector value being filtered by a > short FIR say 5 taps) in order to limit the gain-control bandwidth . > > This is not perfect, as there is memory in the modulation scheme > with the RC filter between frames, but probably good enough > > suggestion 2) : similar to (1) but only change the OFDM carrier > mapping between the FEC and the FFT . That might be easier for the > encoder but the decoder may face some loss due to a new ambiguity > being introduced between the OFDM demod output and the FEC input. > > Overall I beleive we should always aim for an SSB channel width > maximum. While the 1600 mode might run 1600Hz wide, the slop and > rubbish generated can be up to an SSB bandwidth, I think, this > provides some scope for making a bit of a limited bandwith mess > inside our channel. > > -glen > > ___ > Freetel-codec2 mailing list > Freetel-codec2@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 --- Alan Beard OpenWebMail 2.53 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] FreeDV Tx power PAPR- SM1000
I was giving some thought to how PAPR reduction might be implemented within the current framework, taking into account the limited capability of the SM1000 processor. If we approach this on trying to constrain the statistical likelihood of a PAPR event (where the peak power exceeds some value ) : (That is, we accept that PAPR control is acheived some % of the time and other times we ignore it ) For each OFDM frame, the sequence is generated and the PAPR computed . This will yield a PAPR envelope for the OFDM frame. and: suggestion 0) : Implement tone reservation. This can work effectively for low OFDM carrier counts, like FreeDV OFDM. A single carrier is used (not necessary from the FFT), and it's phase and amplitude are set so that the PAPR event is substantially neutralized. An extension on this is that multiple carriers (say one at the bottom, one at the top of the ensemble) can be used to synthesize a more faithful cancellation . This would also be backwards compatible if outside the OFDM sync/eq etc frequency bounds. suggestion 1) Choose a different scrambling code for the encoded voice, re-run the FEC and FFT, and use it. It is highly probable that the PAPR event will be lower. In choosing a different code, and of course the data FEC frame runs over a number of OFDM frames ( I think ??) the FEC and FFT will need to be re run over a number of frames. Some overhead will be required to signal the decoder to use the different descrambling code. Of course with our new 'blind' option, we might lose and PAPR might be worse. In that case, a 'squash' wideband clipper should be used to generated an instantaneous gain reduction of the entire ensemble. (This is a detector with the detector value being filtered by a short FIR say 5 taps) in order to limit the gain-control bandwidth . This is not perfect, as there is memory in the modulation scheme with the RC filter between frames, but probably good enough suggestion 2) : similar to (1) but only change the OFDM carrier mapping between the FEC and the FFT . That might be easier for the encoder but the decoder may face some loss due to a new ambiguity being introduced between the OFDM demod output and the FEC input. Overall I beleive we should always aim for an SSB channel width maximum. While the 1600 mode might run 1600Hz wide, the slop and rubbish generated can be up to an SSB bandwidth, I think, this provides some scope for making a bit of a limited bandwith mess inside our channel. -glen ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
