[pskmail] Re: Call for comments on open protocols

Rein Couperus <rein@xxxxxxxxxxxx> · Sat, 24 Feb 2007 10:16:11 +0100

All this is theory. 

FEC is going to bring relief in only 1% of practical cases only, viz. in the 
extreme case when you are on the borderline between copy and no copy. In normal 
practise (and we have gathered some during 2 year's operation of pskmail 
servers), you are either fighing the S9+20 pactor station which comes on your 
frequency , or 80 dB QSB in multi-path situations, or S9+20 static crashes in 
case of QRN. Sometimes these 3 effects appear simultaneously. This is nothing 
where FEC can help out, maybe only when you use extreme time diversity. And 
with extreme I mean at least 5 seconds apart, equally sending everything twice 
a priory. 
If practise is naive, than this is naive.

The gaps in the stream are not something you can repair with some degree of 
FEC, they are just  too wide. The only way is a lossless arq mechanism, where 
the holes in the stream are detected and filled in afterwards.
One thing we have not yet added to the protocol is memory receive, which 
combines the information in the frames to build a valid one in case also the 
repeat is damaged. This, combined with a block length which adapts to the qrm 
characteristics guarantees an optimum
adaptation to the actual situation on the band.

FEC is only going to slow all this down. We have compared MT63-2k with PSK63 
and found no increase in throughput on the band.
And if you compare the bandwidth/throughput efficiency ratio the MT63-2 case 
looses by a factor of 10. It is just a case of throwing precious spectrum away.

Summing it up, we'd better worry about DTN (delay tolerant network) 
technologies which work around qrm and qsb than about scratching the last dB 
out of the protocol.

73,

Rein EA/PA0R/P

> -----Ursprüngliche Nachricht-----
> Von: Walt DuBose <dubose@xxxxxxxxx>
> Gesendet: 24.02.07 05:57:50
> An: Rud Merriam <k5rud@xxxxxxxx>
> CC: linlink@xxxxxxxxxx
> Betreff: Re: Call for comments on open protocols

> 
> Rud,
> 
> I guess this all got started when Larry wrote...
> 
> ==========================
> 
> Has anyone run across this solicitation from the ARRL?
> 
> http://www.arrl.org/news/stories/2007/02/22/102/?nc=1
> 
> I would think that some of the members of this list could provide the
> most relevant input :-) .
> 
> Cheers,
> -- 
> Larry Gadallah, VE6VQ/W7
> 
> And you wrote...
> 
> Rud Merriam wrote:
> 
> I looked again at Phil's web article and tought...Oh, MT63-2K.
> 
> =====================
> 
> Then I recalled that what Rick, K9\V9U had written on the digitalradio mail 
> list...
> 
> I did not see any response to this but each of the DominoEX modes does
> have an estimated SNR
> 
> For example:
> 
> DEX4  =  -14.5 dB
> DEX5 =   -14
> DEX8 =   -13.5
> DEX11 = -12
> DEX16 = -10.5
> DEX22 =  -9
> 
> Add about one 1 db better SNR for using the FEC mode.
> 
> It does seem that DEX22/FEC works better than DEX11 without FEC in many
> cases even though the throughput speed is about the same. However, under
> weak signal condx, I suspect that DEX11 wihout FEC would work deeper
> into the noise. As I am finding out on many HF circuits, the ability to
> handle the vagaries of the ionosphere is often more important than the
> raw ability to handle AWGN.
> 
> I did think that MT-63 would do better than DEX11/FEC and DEX22/FEC, but
> it was much worse during the 160 meter test. Signal strengths were
> generally quite good though and QRN was not too bad considering the time
> of year here in the northern hemisphere. It will be most interesting to
> see what happens this summer with static crashes. It just seemed like
> DEX was able to handle static crashes better than other non-ARQ modes.
> 
> 73,
> 
> Rick, KV9U
> 
> ===========================
> 
> So perhaps if MT63 is much like what Phil, KA9Q, suggeested, then perhaps  
> there 
> IS something better...more robust.
> 
> And, there is going to be a trade-off of throughput vs robustness.  How much 
> throughput do you want and how robust do you want the mode/protocol to be.
> 
> 73,
> 
> Walt/K5YFW
> 
> > Walt et al,
> > 
> > I have been doing an awful lot of reading lately on FEC, especially low
> > density parity codes, and the distinct idea I have formed is that FEC is
> > mandatory to attain the maximum throughput. Perhaps because I am defining
> > "maximum throughput" as working to attain the Shannon limit. All the papers
> > I read have some comment along the lines of "by using this form of FEC we
> > approach N db closer to the Shannon limit". 
> > 
> >  
> > Rud Merriam K5RUD 
> > ARES AEC Montgomery County, TX
> > http://over50.k5rud.us/wiki/
> > 
> > 
> > -----Original Message-----
> > From: Walt DuBose [mailto:dubose@xxxxxxxxx] 
> > Sent: Friday, February 23, 2007 10:18 PM
> > To: Rud Merriam
> > Cc: linlink@xxxxxxxxxx
> > Subject: Re: Call for comments on open protocols
> > 
> > ...
> > 
> > ... Whatever modulation technique is 
> > used on the individual sub-carrier/tone carriers, the use of FEC in the
> > overall 
> > content of the data stream does detract from the optimum throughput.  None
> > the 
> > less, some amount of FEC may be useful.
> > 
> > ...
> > 
> > 73 & GN,
> > 
> > Walt/K5YFW
> > 
> > 
> > 
> 
> _______________________________________________
> Linlink mailing list
> Linlink@xxxxxxxxxx
> http://wetnet.net/mailman/listinfo/linlink
> 

-- 
http://pa0r.blogspirit.com

Other related posts: