| |
PA2AGA > HDDIG 20.09.00 23:39l 160 Lines 7374 Bytes #999 (0) @ EU
BID : HD_2000_252H
Read: DC1TMA GUEST
Subj: HamDigitalDigest 2000/252H
Path: DB0AAB<DB0RGB<DB0MRW<DB0SON<DB0ERF<DB0BRI<DB0HAG<DB0ACH<PI8JOP<PI8ZAA<
PI8HGL
Sent: 000920/1911Z @:PI8HGL.#ZH1.NLD.EU #:16295 [Den Haag] FBB $:HD_2000_252H
From: PA2AGA@PI8HGL.#ZH1.NLD.EU
To : HDDIG@EU
Date: Sun, 17 Sep 00 16:38:24 MET
Message-Id: <hd_2000_252H>
From: pa2aga@pe1mvx.ampr.org
To: hd_broadcast@pa2aga.ampr.org
X-BBS-Msg-Type: B
groups is commonplace there, causing more grief for the other countries
where this "Diebox" software and its successors isn't in use.
>As to Junk Mail? One person's junk is another's treasure. Comparing to the
>Internet Spam, what most people don't realize is that Spam is profitable, if
>it wasn't, why would so many people be doing it?! It's part of any messaging
>system and you have to design for it and live with it.
For a simple bulletin system like the packet BBS to function, there should
be a mentality that makes everyone ask "is this really worthwile to send on
the bbs system" before sending a bulletin, especially to a wide
distribution area. It was like that in the first decade of Usenet. The
software printed a screen of text at every post, stating that the message
one was going to type was to be sent all over the world to thousands of
computer systems and that this was going to cost effort and money.
When everyone with a transceiver for sale or a cry for help would first
think about the implications of sending this @WW and about the usefullness
of a response from the other side of the world, the amount of junk would
decrease.
But there are always people posting without thinking first, so any message
network remains filled with mostly crap.
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1chl@amsat.org | WWW: http://www.knoware.nl/users/rob |
| AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
------------------------------
Date: Fri, 15 Sep 2000 08:03:04 GMT
From: nomail@rob.knoware.nl (Rob Janssen)
Subject: internet repeater linking
Hank Oredson <horedson@att.net> wrote:
>"Ed_Woodrick" <Ed_Woodrick@email.msn.com> wrote in message
>news:OOGUMyoHAHA.322@cpmsnbbsa09...
>> Charles,
>> While your idea is indeed a step above basic forwarding, it has some
>> implementation problems, especially on HF.
>> Just to make things clear, I believe that your use of the term multi-cast
is
>> a little different than the generic use of the term. It seems as if your
use
>> of technology is actually a broadcast. The difference is that a broadcast
is
>> to all stations, while multicast is actually multiple routing hubs directly
>> sending information to individual stations. But semantics aside....
>> The biggest problem with your multicast solution, especially on HF is that
>> it does not include error correction. It is very common to have to
>> retransmit packets on HF multiple times due to static or fades. Without an
>> adequate error correction method, the chances of all receiving stations
>> receiving a packet is very low. Multiply this by the number of packets in a
>> message, then the probability that messages are transferred are nil.
>This topic was done to death about 5-6 years ago. Several robust
>"request fill" protocols were proposed, none were tested.
Wrong. The protocols were designed, implemented and tested and have
been in use for over a decade now. On packet satellites.
The hidden transmitter problem is worse there, transmitters don't hear
eachother at all. Errors may be fewer than on HF, but poor stations that
miss many packets are present just as well. The re-transmissions just help
the others on the channel. When you know you have a good station, you just
wait sending the last few hole-fills until other stations seem to have
lost interest in a message and retransmits are not coming by themselves.
The transmitter station also queues and merges hole-fill requests so that
multiple fills do not result in quick retransmissions of the same packet.
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1chl@amsat.org | WWW: http://www.knoware.nl/users/rob |
| AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
------------------------------
Date: Thu, 14 Sep 2000 21:10:11 -0400
From: Gary Coffman <ke4zv@bellsouth.net>
Subject: Psk Signal Reports
On Wed, 13 Sep 2000 13:16:48 +1200, "Gerard Welford"
<gerard.welford@xtra.co.nz> wrote:
>I have been reading a number of postings to the PSK31 group in
>www.egroups.com and there seems to be a concensus of opinion that the RST
>form of signal reports is not suitable for this mode. Not only is the signal
>strength misleading due to the S meter reading within the bandpass of the
>receiver so that the loudest station on the band is recorded, but the tone
>part of the report is really only applicable to cw transmissions.
>It would appear that most favour the QRK type of report and I think if
>enough PSK operators adopt this type of report it will quickly become
>standard practice.
>73......Gerry ZL1AWW
The problem with the QRK reporting system is that it doesn't indicate
*why* the signals are bad or excellent. So the operator isn't given any
indication of what steps need to be taken to improve the link. Basically,
it is just the 'R' of the RST system.
Adding the S and T information is an improvement over the QRK report
because it gives the operator potentially valuable information on the
quantity and quality of the signal. That's why RST was instituted. What
we need to do is to refine the S and T reports to make them meaningful
for PSK31 signals.
The first thing we need to do is divorce the notion of S meter readings
from the 'S' report. Historically there is no parallel between them. The
S report merely uses an arbitrary scale that goes from very weak (1)
to very strong (9). There is no direct correlation with an S meter, which
often did not even exist on receivers in the era in which RST was
developed.
S meters on current amateur equipment generally do not follow the
somewhat mythic 6 dB per S unit anyway. They are in practice very
nonlinear from one S unit to another, and typically range from 2 dB
to 5 dB per S unit over their range. So the use of S units for reports
is very misleading. (This nonlinearity is intentional to a large extent,
manufacturers have found that amateurs tend to prefer receivers
with a "lively" S meter.)
For the purposes of PSK31 (and other sorts of signals too), the more
interesting S value is the signal to noise ratio. That information is usually
conveyed by color on the waterfall display, but it should be trivial for the
software writers to give us a number for the selected signal in the same
fashion as they now give us an IMD number.
The 'T' report is signal quality, and that's very important for PSK31. We
already have a good measure of it. It is the IMD number reported by the
software.
We shouldn't limit ourselves to single digits for each of 'R', 'S', and 'T'.
That may have been adequate in CW days where "by ear" estimates
were the rule, but our software can do better than that. I'd suggest
that the 'R' number should report percent correct copy to the nearest
10 percent, IE 00 to 10. SNR should be in dB, a 2 digit range should be
sufficient. T should be the IMD value, also a 2 digit value.
To be continued in digest: hd_2000_252I
Read previous mail | Read next mail
| |
