Add recommended RF bandwidths to user manual.

[tmiw]

Per email suggestion, this PR adds an additional section to the user guide that describes recommended filter bandwidths to use. This information comes from https://github.com/drowe67/codec2/blob/master/README_freedv.md.

[Tyrbiter]

To me this begs a question, would setting an Rx IF bandwidth matching the selected Tx mode ever be a good idea?

If multi-rx is enabled then probably not (because it would effectively stop wider modes working).

I use a narrower, manually adjusted, IF bandwidth in SSB-DATA mode, this switches back to the wider default BW in analog mode. Maybe add this as a suggestion in the manual, it may improve SNR with adjacent frequency SSB signals present.

[tmiw]

I think once you're sure of what the other person's using, setting the bandwidth to be the same as the received signal is fine. The question is more what should be done before that point. Based on what I've noticed, it seems that multi-RX works best with ~3K width (otherwise, false syncs seem to happen more often and can delay actually receiving a signal), hence that recommendation in the manual.

[Tyrbiter]

I think once you're sure of what the other person's using, setting the bandwidth to be the same as the received signal is fine. The question is more what should be done before that point. Based on what I've noticed, it seems that multi-RX works best with ~3K width (otherwise, false syncs seem to happen more often and can delay actually receiving a signal), hence that recommendation in the manual.

You may be right, all part of experimentation, I don't know what is best to be honest, too small a data sample of mode vs bandwidth so far.

[drowe67]

@tmiw - I'm nervous about this recommendation. All of the FreeDV waveform development assumes no additional filtering to that provided by the modem itself - a "clean" Tx and Rx path is the general rule.

The shape factor of a end user supplied filter (rectangular, slope at the band edges) matters a lot, and is beyond our control. The bandwidths in README_freedv are a rough guide to occupied bandwith - not a suggestion of additional signal processing in either the Tx or Rx path.

Do we have any objective, repeatable, controlled experiments that suggest additional filtering helps?

[tmiw]

Do we have any objective, repeatable, controlled experiments that suggest additional filtering helps?

Unfortunately, no. I do have anecdotal evidence that it doesn't seem to hurt anything (with the caveat that it's a limited sample set on only one or two radios). Perhaps this recommendation can be relaxed a bit, i.e.

For most FreeDV use, your radio's filters should be set to the widest possible (typically around 3 KHz). This allows
easy switching between analog mode as well as the various FreeDV modes. Depending on propagation conditions, narrower filters may or may not help improve SNR. For reference, the channel widths of the currently supported modes are below:

Mode	Width (KHz)
1600	1.125
700C	1.500
700D	1.000
700E	1.500
2020	1.600
2020B	2.100

(Feel free to suggest wording as appropriate.)

[Tyrbiter]

Would it help to record some samples of the input signal from the radio to freedv with different filter widths/shapes? Maybe then analyse that with octave.

Are there any input signal amplitude/group delay simulations from the codec2 development?

[drowe67]

It's worth considering the implementation of the modem. On Rx, each carrier already has it's own filter around it (you can see the filtering in the source code, especially for 700C/1600). For the OFDM modes filtering is done with an integrator - you can see the filter response on the Tx signal with compression and tx BPF off.

IIRC most of the modes already have carefully designed Tx filters, so it's hard to understand how another filter could help on Tx ... but if you get it wrong the outer carriers will be attenuated and performance will drop. Tighter filtering also makes PAPR worse, so your RMS power drops.

I guess there may be some on air scenario where more filtering helps, my tests are mainly with simulated channels. However in that case it's probably best to add a requirements for that corner case to the new mode development work - rather than put too much effort into this for existing modes. I'd also be inclined to add it in a controlled way at the libcodec2 level, that's bound to work better than add hoc adjustment by end users.

So it's fine if people want to play (that's what Ham radio is all about), but I'd be careful with any form of recomendation as I can't see any sound theory or experimental reason to do it.

[drowe67]

Would it help to record some samples of the input signal from the radio to freedv with different filter widths/shapes? Maybe then analyse that with octave.

Probably best to use the freedv_xx cmd line tools and a simulated channel to make it repeatable.

Are there any input signal amplitude/group delay simulations from the codec2 development?

Just the ch simulation that simulates a SSB filter with some ripple. I'm pretty sure it's not particularly sensitive to amplitude variations - this could also be tested with the cmd line tools.

[tmiw]

I did some more editing of the new section to hopefully make it clear that anything other than ~3 KHz for receive and transmit filtering is untested. If this is okay, I can merge this PR at least (and further discussion on testing, etc. can happen in the Codec2 repo).