[pskmail] Re: PSK modes with FEC - first release of test code

  • From: Rein Couperus <rein@xxxxxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Thu, 12 Nov 2009 11:48:21 +0100

Tnx John, I will do some testing...


> -----Ursprüngliche Nachricht-----
> Von: "John Douyere" <vk2eta@xxxxxxxxx>
> Gesendet: 12.11.09 05:00:29
> An: pskmail@xxxxxxxxxxxxx
> Betreff: [pskmail] Re: PSK modes with FEC - first release of test code

> Hi All,
> Here is attached the first pass at this BPSK + FEC mode: the two files
> attached (psk.cxx and psk.h) are to replace the ones in the source
> directories respectively in src/psk/ and src/include/. Compile as
> normal.
> What do you get: despite the GUI staying the same, all the QPSK modes
> are now BPSK with FEC. Since there was no QPSK500 entry I chose to
> replace QPSK31 with BPSK500+FEC. So if you select QPSK31 you get the
> fastest BPSK mode with FEC. BPSK31 with FEC is very slow anyway and
> probably of no practical value for Pskmail in any case.
> I used the 2nd re-synchronization option from the email below and I am
> still using hard-decode, so there are improvements to be made on the
> robustness of the mode.
> But if you can give it a go and see what improvement we already get
> compared to the equivalent BPSK mode without FEC (and the BPSK mode at
> 1/2 the speed for that matter, e.g. QPSK500 with FEC versus BPSK250)
> that will tell us if it's worth pursuing or not.
> Of course you will notice that there is a delay in the decoding due to
> the redundancy and bit spreading and of course the character rate is
> half of the equivalent BPSK mode.
> The source code is still "messy" since it is only a proof of concept.
> There is also an annoying decoding of the pre-amble that I need to fix
> (it produces a string of "tatatata") but it does not interfere with
> the pskmail exchanges.
> 73s,
> John
> On Thu, Nov 12, 2009 at 10:20 AM, John Douyere <vk2eta@xxxxxxxxx> wrote:
> > Hi All,
> >
> > I have made good progress on implementing an FEC scheme for the BPSK
> > modes. It works well, with of course some delay and half the character
> > rate of the standard BPSK mode.
> >
> > The concept is as follow: I use a convolution encoder and Viterbi
> > decoder as for the THOR mode: n=1/2 and K=7. Since the coding is n=1/2
> > there are two bits to transmit for every bit of data. The output of
> > the encoder (2 bits at a time) is transmitted sequentially in BPSK
> > mode to avoid the losses of the QPSK mode.
> >
> > And here is the issue: how to synchronize on the proper bit. If I miss
> > one bit at reception I am not in sync with the encoder.
> >
> > A few concepts I am thinking of and I would like some feedback:
> >
> > 1. Run two Viterbi decoders in parallel reading the same received
> > stream but with one delayed by one bit, so that an any time one of the
> > two would be in sync and then choose the one with the best "guess
> > measure". Advantage: should be the fastest to re-sync in case of a
> > missed bit. Disadvantage: heavy cpu usage.
> >
> > 2. Use one Viterbi decoder and use the "00" sequence of stop bits to
> > check for sync: if I get no stop sequence in 12 bits (the maximum
> > length varicode is 10 bits long) I skip one bit and restart decoding.
> >
> > Any other ideas?
> >
> > I am looking to see if I can also do soft decoding rather than hard
> > decoding: at the moment the decoding to 1 or 0 is done at the received
> > bit level then fed as a 1 or 0 to the Viterbi decoder. It would be
> > much better to keep the "soft value" (i.e. the phase measured) and
> > feed this in the decoder so that it can make a decision based on the
> > redundant phase information.
> >
> > Exiting stuff really.
> >
> > I will send the code when I get the automatic re-sync working.
> >
> > Best 73s,
> >
> > John
> >


Other related posts: