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
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
