[pskmail] Re: Fwd: RE: [digitalradio] 16QPSK Modulation and Baud
- From: Rein Couperus <rein@xxxxxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Wed, 20 Sep 2006 21:10:37 +0200
It is interesting, and it proves that we are not far off the ideal
specification with pskmail. Except, of course the
different main specification goal for pskmail, being low-bandwidth and low
power. The modems Walt takes about must deliver lots more data per minute, but
the throughput/bandwidth ratio is a lot worse than optimum.
Pskmail actually employs the most important tools mentioned in this text, being
automatically adaptive message length,
and optimum baud rate for the HF channel.
Instead of changing the number of frames, pskmail changes the length of the
segments. A data frame always
consists of 9 segments, the 9th being the ACK/NAK.
When there is a NAK on a segment, the station increases a counter, and when a
certain quantity is reached,
the segment length is halved, so you now have only 50% chance of a segment
being damaged. Moreover,
a segment repeat will take only 50% of the time. If there is no NAK, the
counter is decreased again, and as soon
as it is at a certain minimum value the segment length is doubled.
This way the segment length varies with the conditions. At heavy QRN, the
segment length reduces to 8 data characters,
when condx are good the segment length increases to 64 data characters. If
there is only 1 damaged segment per frame nothing happens. It takes a number of
damaged segments for the length to change.
There is no point in increasing the segment length further, as the chance of a
character being kicked out of the segment approaches
100% at longer segments, and at 64 chars the protocol overhead is already quite
low.
To give you an idea, I normally start with a segment length of 16 and increases
to 32. In pactor qrm or QRN (or when the XYL uses the electrical steam iron) it
reduces to 8 characters. And when the signal is o.k. out it goes to 64. Average
length used
on a normal channel at 10 MHz is 16-32 Characters.
FEC is not wanted. FEC gives the RX a second chance to receive or reconstruct
the data. Pskmail does this by repeating only the damaged segment, and does not
suffer the speed penalty of FEC.
The text below describes a point-to-multipoint scenario. Our primary goal is to
optimize point-to-point.
Still intersting to keep in mind for the missing (ftp) mode, which may use
MT63...
There is a lot more to be said (and experimented) about this. Come and join
in!! Theory is nice,
but we are hams so we can actualy try it out!!
73,
Rein PA0R
> -----Ursprüngliche Nachricht-----
> Von: pskmail@xxxxxxxxxxxxx
> Gesendet: 20.09.06 18:15:25
> An: pskmail@xxxxxxxxxxxxx
> Betreff: [pskmail] Fwd: RE: [digitalradio] 16QPSK Modulation and Baud
>
> Hi guys.
>
> I hope this message may be of interest to all of you, especially to Rein. The
> description of choosing number of non acknowledged frames is quite detailed
> IMHO.
>
> 73, Vojtech OK1IAK
>
> # ------------ Pùvodní zpráva ------------
> # Od: DuBose Walt Civ AETC CONS/LGCA <walt.dubose@xxxxxxxxxxxxxxx>
> # Pøedmìt: RE: [digitalradio] 16QPSK Modulation and Baud
> # Datum: 20.9.2006 17:01:24
> # ----------------------------------------
> # I have talked to some scientist at a large research independent facility
> who are
> # doing HF modem research for the government. Here is some of what they
> # believe...
> #
> # For a broadcast mode, use heavy FEC. If the receiving stations have
> transmit
> # capability, let them NAK missed data periodically.
> #
> # For individual or group connections, use a small to moderate amount of FEC
> with
> # CRC and ARQ based on NAKs rather than ACKs.
> #
> # Start off with moderate FEC and send 3-7 frames depending on the
> length/size of
> # your frame. Short frames send 7, long frames send 3. If no station sends a
> # NAK, send 6-14 frames. If no NAKS, send 12-28 frames, etc. If at any time
> only
> # one NAK from one station, resend the frame and continue on. If you are for
> # example sending 6-14 frames and receive two NAKs, back off to 3-7 frames.
> If
> # sending 12-28 frames and receive two or more NAKs, back off to 6-12 frames
> OR
> # just drop back to 3-7 frames.
> #
> # They also recommend manually setting a real-time propagation index for the
> # frequency used and base your baud rate on that or use a fixed baud rate for
> # various MUFs or bands.
> #
> # There was much discussion among the group concerning using varying baud
> rates or
> # a single baud rate. About half felt that a 45.5 baud rate (or perhaps 31
> baud
> # rate) should be used on HF. The other half thought that 31, 45, 90 and 180
> baud
> # rates could be used.
> #
> # For their testing using a channel simulator close to a Watson channel
> simulator
> # (they tested to a poor CCIR channel with varying fading, noise, etc. with a
> goal
> # of 0 to -10 dB SNR).
> #
> # Their modem manually switched baud rates depending on the frequency (band)
> used
> # and of course the band chosen was based on the projected path distance and
> MUF.
> #
> # Their transmission length were from 10-30 seconds. I don't know how many
> frames
> # they sent but I do know that a 10 second transmission took 15 seconds to
> decode
> # with moderate to heavy FEC in the broadcast mode. Their 30 second
> transmission
> # produced a little over two pages (72-76 characters per line and 60 lines per
> # page) of ASCII characters.
> #
> # They were getting 3 bits of information per tone and were using multi-tone.
> # They said that their "mode" use much like OFDM and I am almost sure they
> were
> # using somewhere between 50-80 tones.
> #
> # Their ultimate goal was a full page of ASCII characters being "decoded" in
> less
> # than 15 seconds in a broadcast mode. The did mention the error rate but
> don't
> # know what it was...but I am almost sure that had to be less than 1
> character per
> # page considering the type of information the system was to send.
> #
> # I wish I could tell you more, but the entire project is considered
> intellectual
> # property by the research organization.
> #
> # Walt/K5YFW
> #
> # -----Original Message-----
> # From: digitalradio@xxxxxxxxxxxxxxx [mailto:digitalradio@xxxxxxxxxxxxxxx]
> # Sent: Tuesday, September 19, 2006 3:04 PM
> # To: digitalradio@xxxxxxxxxxxxxxx
> # Subject: Re: [digitalradio] 16QPSK Modulation and Baud
> #
> #
> # Jose Amador wrote:
> # > Taking adventage of SCS experience, they chose PSK
> # > (cannot tell by heart if differential or not, a peek
> # > to the manual is needed) as a modem, and depending on
> # > the retry rate (closely related to BER) it tries more
> # > complex constellations and more carriers. One of the
> # > "secrets" is the switchover criteria...when retries
> # > rise, then jump to the next "lower speed", whatever it
> # > means.
> #
> # I think that FEC could be used wisely...
> #
> # For instance: Initially, use ARQ, with the modulation "A", working at
> # "A" bauds. When retries rise, enable FEC dinamically. If it fails again,
> # jump to the lower speed, or even to another stronger modulation (versus
> # noise, I mean).
> #
> # When the retries diminish, it may try with more carriers, or more
> # complex constellations, or more speed.
> #
> # The key is to do it automatically, or adaptatively. The switchover
> # criteria is the most complex problem... but it could be reached even
> # with the trial and error mode.
> #
> # 73 de Nestor, CM3NA
> #
> # __________________________________________
> #
> # XIII Convención Científica de Ingeniería y Arquitectura
> # 28/noviembre al 1/diciembre de 2006
> # Cujae, Ciudad de la Habana, Cuba
> # http://www.cujae.edu.cu/eventos/convencion
> #
> #
> # Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org
> #
> # Other areas of interest:
> #
> # The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
> # DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy
> discussion)
> #
> #
> # Yahoo! Groups Links
> #
> #
> #
> #
> #
> #
> #
> #
> #
> #
> #
> #
>
>
--
http://pa0r.blogspirit.com
Other related posts:
