[pskmail] Auto Speed switching

  • From: John Douyere <vk2eta@xxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Fri, 27 Nov 2009 17:12:52 +1100


I tested the alpha server 0.9.27 last night and here are my comments:

1. This is working great. It is very responsive: I started mobile
stationary and it switched to the higher speed very quickly. Then went
mobile-mobile and it reverted to the slower speed (I had PSK500 and
PSK500+FEC+Interleaver as the robust mode). Came closer to home with a
stronger signal and it changed back to high speed.

2. RSID has to be reviewed. The hit rate is too low. It looks like a
pre-sentisation issue. If I send an empty frame with pre and post RSID
on, the second one has far far better chances to get picked up.

My next task is to find why we have such a discrepancy in sensitivity.
In practice it should be at least as good as a THOR22 or even THOR8 to
be of real value for our application. I am convinced it has the
capability to do what we need it to do.

3. The server may changes the timing a little too soon: I had overlaps
when it switched to the fast mode. Not sure why. Maybe the timing is
too short to start with.

4. QPSK31 for BPSK500+FEC creates a problem in that the initial
timeout is very long (it thinks probably this is PSK31). That will be
fixed when we have a separately allocated mode name and RSID for

5. One thing I propose: since the operator may connect in a different
mode (say THOR22 due to conditions), the server should be able to
still work effectively shifting speed up and down from the connect
speed. So I suggest the final solution should be a list of several
modes and the mechanism for changing is "one up" or "one down", from
the current mode. Hope this makes sense.

6. Other point: while I am on the adaptation of BPSK for ARQ
application, do you see a benefit either now or in the near future to
change the varicode in order to better the chances of the control
characters to get through QRM.

The explanation: right now a space and the letter "e" require
respectively 3 ("100") and 4 bits ("1100") to be transmitted correctly
to be received without error. In comparison the <SOH> and <EOT>
require 12 bits to be transmitted error free. If my recollection of
statistics is correct that is a factor of 9 to 16 time more chances to
be hit by QRM.

So if we are going to do something on memory ARQ or other QRM fighting
mechanism that need a start and/or end frame reference then it is of
benefit to re-arrange the varicode.

A new version of BPSK + FEC + variable (and longer) interleaver is coming.



Other related posts:

  • » [pskmail] Auto Speed switching - John Douyere