John,
The first thing that comes to mind is whether there were any ground wave
signals mixing with sky waves during your field tests? It's been shown
that NVIS throughput can fail when the sky wave echoes interact with
ground waves. The sky waves take more time to arrive at the receiver so
you can imagine what the difference in timing does to copy when the two
signals interact. This is what the NVIS simulations were based on; two
channels, one with no delay (simulated ground wave) and the other with a
7 ms delay (simulated NVIS sky wave).
January's path tests showed that PSK-R appeared to be less robust than
BPSK under NVIS simulation while the white noise tests clearly showed
PSK-R the winner in terms of sensitivity. Your field tests seem to
reveal the same results in terms of which modes have the edge in
sensitivity, but not necessarily the edge in terms of dealing with
multi-path timing delays. I could be wrong though and there may have
been strong evidence of ground wave interaction? It can be difficult to
tell; some paths are more obvious than others. Hellschreiber is the only
mode I know of that can visually indicate this sort of thing, but that's
not an option with PSKMail.
Hope to hear from you soon John.
Tony -K2MO
n 4/1/2010 9:45 AM, vk2eta wrote:
To Tony (K2MO) in particular, but not exclusively:
Following your simulation results on these modes in January I have
done a few tests in the field and I have to say that I don't
understand the results.
Please note that I am not trying to make a point, but to understand
why the theory does not seem to match the practical side.
My tests simply revolve around examining the bahaviour of the Pskmail
server adapting speed to the conditions.
We have in the latest version a table of modes that the server can use
by shifting up and down, one mode at a time. It does so by relying on
the s/n report gathered from Fldigi and the number of repeats due to
damaged ARQ frames.
The list is arranged in an empirical order of speed vs robustness and
is the following for regions 2 and 3:
THOR8 MFSK16 THOR22 MFSK32 PSK250R PSK500R PSK500
The MFSK/IFSK family of modes are normally the modes of choice for NVIS.
This week I did some tests at 95 miles in a strait line from my server
on 40 and 80M between about 1PM to 2PM local time so obviously in NVIS
conditions.
What I noticed every time I would connect in MFSK16, the server would
progressively shift the TX mode up into the PSKR modes, up to PSK500R,
but never to PSK500.
I also noticed that there would be no fallback from PSK250R to MFSK32
after a shift up from MFSK32.
So my interpretion is the following:
If the PSKR modes had a weakness in NVIS conditions, I would see the
server moving continuously between MFSK32 and PSK250R: good reception
in MFSK32, speed up to PSK250R, poor reception, return to MFSK32, etc...
Also since it did not go up pass PSK500R to PSK500 it indicates that
in these particular cases the PSK500R modes was starting to show signs
of limitations and the server calculated that there was not enough s/n
margin to shift the speed up.
Selective fading is very visible especially on the PSK500R mode of course.
So my question is: in the simulation you performed, are there
parameters that maybe would need to be looked at to explain why these
modes seem to behave well in these conditions or are there other
variables to consider?
Also trying to get a more formal comparison, how would you design some
practical tests that minimize the effects of variation in propagation
in the field?
On this point I was thinking of sending a set text in different modes
and repeating the test several times, interleaving the modes so that
in average it would be unlikely to be just propagation. Mode1, Mode2,
Mode3, Mode4 then again Mode1, Mode2, Mode3 etc... repeated say 5
times. Then taking the average result for comparison.
Best regards,
John (VK2ETA)
--- In digitalradio@yahoogroups.com
mailto:digitalradio%40yahoogroups.com, vk2eta vk2...@... wrote:
Hi Tony,
Thank you for the simulation results. I will report any field
results for PSKR modes in NVIS conditions.
Regards,
John
__ Information from ESET NOD32 Antivirus, version of virus
signature database 4993 (20100401) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
