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
