Hello Andy,
The Multipsk code is not better than the Pawel's design. If I had to rewrite
the code, I would prefer to use the Pawel's design because it is simpler.
Simply when I wrote it, I was used to do this way (as with MFSK16, PSK31...)
and moreover, I had doubts about the precision of a double-estimation by
symbol. 10 estimations per symbol seemed to me much better, but of course, it
would have be necessary to load much the CPU, so I forgot it.
But I was wrong, because under a good S/N, this precision (double-estimation by
symbol) is not necessary and under a bad S/N, it all cases this precision is
homogeneous with the precision of symbol estimation.
Note: it is reminded that, under noise, the quick degradation of decoding is
due to :
* the loss of symbol synchronization,
* the imprecision of the symbol estimation.
This can be seen in an "eye" diagram.
73
Patrick
----- Original Message -----
From: Andrew O'Brien
To: digitalradio@yahoogroups.com
Sent: Sunday, November 23, 2008 6:08 PM
Subject: Re: [digitalradio] Re: Olivia mode comparisons, testers needed.
So does this mean that Patrick has IMPROVED on Pawel's design and the "true"
implementation within DM780 is not as effective, or is DM780 slower but better
at decoding ?
Andy
On Sat, Nov 22, 2008 at 4:34 PM, Patrick Lindecker <[EMAIL PROTECTED]> wrote:
Hello Votjech,
>I believe the difference between Patrick's MultiPSK and Pawel's
>original Olivia code is in the way how the sync time is adjusted after
>the initial sync is reached. Partick's code locks in time and only
Yes it is as you described (you are perspicacious!). The symbol
synchronization is done as in MFSK16, or other mode with a non-linearity and a
PLL to follow slight variations.
However, I use the complete Pawel strategy for RS ID.
> synchronization and for decoding very weak signal, additionaly
> introduced 1 second lag in case of Olivia1000/32 is annoying.
I don't think there is some issue for weak signal.
I tried here comparing Mixw, Multipsk and OliviaAid with a very noisy
transmission: the decodings are more or less equivalent.
The results are the following (with a signal at -13 dB of S/N Gaussian
which is the limit for Olivia 32-1000 decoding):
* OliviaAid: 120 characters decoded,
* Mixw: 164 characters decoded,
* Multipsk: 208 characters decoded.
However, I tested on Gaussian noise, when real conditions could be very
different from a Gaussian noise (QSB was not simulated for example) and so the
results could be different...
73
Patrick
----- Original Message -----
From: "Vojtech Bubnik" <[EMAIL PROTECTED]>
To: <digitalradio@yahoogroups.com>
Sent: Saturday, November 22, 2008 4:14 PM
Subject: [digitalradio] Re: Olivia mode comparisons, testers needed.
> Hi Andy.
>
> Let's say one works with Olivia 1000/32. Olivia sends/receives 7bit
> ASCII letters. Each 7 bit letter is coded by Walch-Hadamard
> transformation into 2^(7-1)=64 bits. One of 32 tones modulation codes
> 32=2^5 combinations, which equals to 5 binary bits. Olivia is
> spreading 5 7bit letters over 64 MFSK32 tones. It takes 64/31.25=2.048
> seconds to transmit one block of 5 letters. I hope this explains why
> the received letters appear in groups of five and why there is a
> considerable lag, which cannot be lower than 2 seconds for any decoder.
>
> Olivia receiver searches for the Walch-Hadamard coded blocks in time
> and space. Pawel Jalocha's code is running matrix of decoders spaced
> by one half of Olivia tone spacing in frequency and one half of tone
> spacing in time. He is calculating signal level (or quality,
> correlation or whatever one wants to name it) of each of the decoder
> in the matrix to check, whether and/or where a valid Olivia block was
> received.
>
> I believe the difference between Patrick's MultiPSK and Pawel's
> original Olivia code is in the way how the sync time is adjusted after
> the initial sync is reached. Partick's code locks in time and only
> slightly adjusts the sync time to cope with differences in RX/TX sound
> card clock callibration the same way his or any other MFSK16 decoder
> works. Pawel's code is always looking up one half of block time after
> the expected sync time. While Pawel's strategy is good for initial
> synchronization and for decoding very weak signal, additionaly
> introduced 1 second lag in case of Olivia1000/32 is annoying.
>
> I believe Pawel's code may be improved to decrease time lag in case
> the decoder is already locked to a strong signal. Also if a strong
> correlation is detected, one does not need to wait another 1 second
> for even stronger signal, because this is highly improbable. I believe
> Patrick's MFSK is doing both.
>
> Also if the signal is very strong, then one may break into a middle of
> a block and the block will be detected correctly with the prerequisity
> that the decoder will be flushed at the time one changes frequency
> either on waterfall or by tuning knob. I don't think any Olivia
> decoder is flushed at tuning change.
>
> It sounds like a challenge for my PocketDigi code, but don't tell my
> wife I have a new project :-)
>
> 73, Vojtech OK1IAK
>
>
> --- In digitalradio@yahoogroups.com, "Andrew O'Brien"
> <[EMAIL PROTECTED]> wrote:
>>
>> Folks, when Simon was first adding Olivia to DM780 he studied Pawel
>> Jalocha's coding and consulted with him about the correct
> implementation.
>> The lag noticed in DM780 is reportedly as the Pawel Jalocha
> intended. What
>> I am looking for is people to get on the air with Olivia and see if the
>> applications that may have less lag , have any noticeable decoding
>> degradation. Since I know Olivia in MixW and Multipsk work well, I am
>> wondering if the "proper" implimentation of Olivia in DM780 is worth the
>> delay and issues this causes during a QSO (those not knowing about
> the lag
>> think we are not coming back to them and start a transmission again )
>>
>> Andy
>>
>> On Thu, Nov 20, 2008 at 3:18 AM, Simon Brown (KNS)
> <[EMAIL PROTECTED]>wrote:
>>
>> > The lag is in the software - it's part of the design for the error
>> > correction. Where error correction is part of the design then *in
> general*
>> > with Ham modes you have to wait a while before text is decoding is the
>> > error
>> > correction is applied. The lag is not caused by CPU load.
>> >
>> > To really understand this it's best to analyse the Olivia design
> although
>> > this can be rough for the brain :-)
>> >
>> >
>> > Simon Brown, HB9DRV
>> > www.ham-radio-deluxe.com
>> >
>> > ----- Original Message -----
>> > From: "captcurt2000" <[EMAIL PROTECTED] <captcurt%40flash.net>>
>> >
>> > > Sooo. a 500Mhhz machine running at 20% is going to perform the
>> > > integrations and decoding same delay as a 2 Ghz machine running
> at 20%??
>> > >
>> > > That seems counter intuitive to me..
>> > >
>> > > I'm sure you're right but I don't understand how that can be.
>> > >
>> > > I thought the load information talked about resources not speed of
>> > > execution.
>> > >
>> > > Help me understand..
>> >
>> >
>> >
>>
>>
>>
>> --
>> Andy K3UK
>>
>
>
>
> ------------------------------------
>
> Announce your digital presence via our Interactive Sked Page at
>
http://www.obriensweb.com/sked
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
--
Andy K3UK
