[pskmail] Report from the trenches...
- From: "Rein Couperus" <rein@xxxxxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Mon, 13 Feb 2012 23:24:17 +0100 (CET)
While watching the OTH radar from Cyprus, which is S9+30 on 10148.0 at the
moment,
there is some time to report on the latest findings...
We enjoy the nice weather here in Spain, at the place where PSKmail was born
some 9 years ago...
Then it started as a simple ARQ system built upon PSK63, using gMFSK as a modem.
Its sole purpose was to up- and download software patches to/from the internet.
Meanwhile we are looking at the Swiss army knife of digital HF communication,
encompassing twitter, Facebook updates, HF APRS, web access, file up/download
and POP/SMTP.
The band conditions on 30 are a lot different as well. During certain times of
the day, markedly
just after sunrise and in the late afternoon, I can use a combination of
PSK500R, PSK250R,
PSK125R and THOR22 to reach a server. I can also send beacons and messages in
PSK500R
with 10 Watts, and in 90% of all cases there will be at least 1 server picking
it up. For most of
the day and night, however, these modes are not good enough for ARQ...
The reason is a strong multipath effect combined with Doppler, which cuts
almost every packet
in various parts. Leading to excessive repeats, mode downgrades, more mode
downgrades and
then premature disconnects.
I have seen this as a challenge rather than bad luck, and I have started to
analyze the problems.
The goal was to upload and download a picture of 10k using only 10 Watts during
a period of bad
conditions.
I can now report that I have been successful in achieving this, but not without
making changes
to the protocol timing and some other fine details.
The problems could be easily found. Most damage was done during file upload.
When the server missed the first <SOH> of a frame, it did not recognize a block,
timed out and started polling instead of listening. In most cases this lead to
a downgrade
to the lowest mode, including mode switching chaos and disconnect.
The solution encompasses a combination of block length control, use of TXID on
the client
during uploads, and a lot of refinement of the protocol timing. I also needed
to add a new
mode to the mode table.
So where John, VK2ETA is experimenting with speeding up and using 4 x PSK500, I
am
adding THOR4 at the other end of the spectrum. During parts of the day THOR8
and THOR4
are the only modes which allow ARQ. Even THOR22 signals are hampered by the 80
dB QSB
caused by the multipath reflections, and the signal looks really bad when it
arrives at the server
after 2 ionosphere hops and 2000 km.
It should be clear that you cannot test all this on a busy channel. I am in the
position here
to see what is happening at the remote server, which runs under VNC. I have
added a DX/QRP
channel to PI4TUE fot testing, which listens in THOR4 during minutes 3 and 4.
One minute was
too short for a connect call in THOR4.... and even RSID was not picked up most
of the time.
Boy this really is a bad channel...
THOR4 decodes even when you cannot see it on the waterfall, but the penalty is
that it does so
at only 2 characters per second...
It looks good so far. I will be testing jPSKmail-1.5.6 some more during the
next days/weeks,
provided the WX is not too good (we have 15 C and sunshine during the day.....).
73,
Rein EA/PA0R/M--
http://pa0r.blogspirit.com
Other related posts:
