[pskmail] Re: Call for comments on open protocols

  • From: Rein Couperus <rein@xxxxxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Sun, 25 Feb 2007 10:03:17 +0100

Rud,

I have been looking at the LDGM stuff and that looks quite interesting. Maybe 
for 
use when more than 50% of the packets get damaged, and the block size is down 
to 8 characters
 (this is the case in heavy QRN). Pskmail could switch to LDGM mode when that 
happens.
Worth thinking about. I had something like this in mind for an RTTY arq mode I 
am developing,
also on packet level...

Rein EA/PA0R/P

> -----Ursprüngliche Nachricht-----
> Von: pskmail@xxxxxxxxxxxxx
> Gesendet: 24.02.07 20:03:58
> An:  'Walt DuBose' <dubose@xxxxxxxxx>
> CC: linlink@xxxxxxxxxx, pskmail@xxxxxxxxxxxxx
> Betreff: [pskmail] Re: Call for comments on open protocols


> 
> Hi Rein,
> 
> My apologies if you were bothered by my use of the term naïve. Taking your
> statement on your web site at face value it is misleading. I have seen
> similar statements by other hams. Practice with space probes, digital TV,
> etc, also show the value of using FEC. 
> 
> ARQ introduces throughput degradation, also. Is there any information on the
> tradeoffs between FEC and AQR?  
> 
> Just as adaptive techniques are used with ARQ others can be used with FEC. 
> 
> Getting into DTN touches a key consideration because it approaches the
> problem from a different perspective. Packet erasure handling raises other
> questions that may lead to different lower level protocol solutions.
> Interesting work at
> http://planete-bcast.inrialpes.fr/rubrique.php3?id_rubrique=5 uses FEC at
> the packet level to reconstruct dropped packets. 
> 
>  
> Rud Merriam K5RUD 
> ARES AEC Montgomery County, TX
> http://over50.k5rud.us/wiki/
> 
> 
> -----Original Message-----
> From: Rein Couperus [mailto:rein@xxxxxxxxxxxx] 
> Sent: Saturday, February 24, 2007 3:16 AM
> To: Walt DuBose; Rud Merriam
> Cc: linlink@xxxxxxxxxx; pskmail@xxxxxxxxxxxxx
> Subject: Re: Call for comments on open protocols
> 
> 
> 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
> 
> 
> 
> 

-- 
http://pa0r.blogspirit.com

Other related posts: