[pskmail] Re: Improved FEC for PSK modes

  • From: Rein Couperus <rein@xxxxxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Mon, 23 Nov 2009 12:39:12 +0100


I have been testing the FEC modes on-air, on PI4TUE. I have found the following 

* The FEC modes are definitely a lot more robust than the raw PSK modes, so you 
on the right track!
* Using FEC modes only, the auto speed switch works very well.

* The PSK500 FEC mode is too wide. It grabs 700 Hz bandwidth, which means we 
can not use it as is 
on 30 meters (only 500 Hz bandwidth allowed in Region 1). 
Part of the problem is the preamble, which looks very hard-switched... The 
'soft' bandwidth limiting nature 
of PSK is completely gone, and we are bound to get trouble from neighbouring 
channels when we leave it like this. 
On the other hand, this preamble forces sync immediately.

* I have been testing an auto-switching combination of PSK250 FEC and PSK500 
The raw PSK500 signal decoded only 20% of the time because the <SOH> character 
at the 
start of a block was not decoded, an extra  preamble of 'XX' did not help. 
Looks like the raw signal decoding changed somewhat..  did 
you test both raw and FEC sigs? I think PSK500 raw as the highest speed is 
important, being 4x faster than PSK250FEC...

Needs some tuning, but the results are already impressive :)


Rein PA0R


> -----Ursprüngliche Nachricht-----
> Von: "John Douyere" <vk2eta@xxxxxxxxx>
> Gesendet: 23.11.09 07:34:03
> An: pskmail@xxxxxxxxxxxxx
> Betreff: [pskmail] Improved FEC for PSK modes

> Hi all,
> I have done more work on the FEC option for BPSK modes:
> I added a second Viterbi decoder shifted by one bit and compare the
> output of both, then I select the output of the one with the less
> errors.
> Cpu load has not increased significantly, but re-synchronisation is
> now fast (typically one to 3 characters).
> I have also changed the way we send the preamble and postamble for
> PSK: I pass both through the encoder/decoder as this gives the chance
> for the encoder and decoder to be fully synchronized before the frame
> data and to flush out the remaining characters at the end of the frame
> too. This gives a different sound to the preamble and postamble of
> this mode compared to the traditional BPSK modes.
> I am still doing hard decoding.
> The result seems good based on my tests today. Still not the
> robustness of the THOR or MFSK for lighting strikes, but much better
> at handling white noise and regular qrm it seems.
> In my tests, most of the time I could get better results than the BPSK
> mode one speed below, which is a fair comparison in terms of
> throughput. And certainly much better for the same BPSK mode without
> FEC.
> PSK500 with FEC gives good results. I even did some tests mobile and
> got good copies when generally the quick fades are not very kind to
> the PSK modes.
> I feel that version is really worth a try. It could give us a nice
> speed downgrade/reliability increase for the automatic mode changes.
> Attached are two files: psk.h in the src/include directory and psk.cxx
> in the src/psk directory. These should work with any source of Fldigi
> from at least 3.13AY onwards.
> To access these modes, use the QPSK modes on the Fldigi gui, with the
> exception of QPSK31 which is PSK500+FEC. This is of course a temporary
> and quick solution since we do not use the QPSK modes in Pskmail.
> I will also do some comparisons with the Multipsk implementation of
> these FEC modes to see if I am not missing something on the coding
> gain.
> Please let me know of your results if you can test.
> Best regards,
> John (VK2ETA)


Other related posts: