| |
PA2AGA > HDDIG 25.09.99 04:17l 230 Lines 7307 Bytes #-9763 (0) @ EU
BID : HD_99_240J
Read: GUEST
Subj: HamDigitalDigest 99/240J
Path: DB0AAB<DB0PV<DB0MAK<DB0ERF<DB0HSK<PI8DRS<PI8DAZ<PI8APD<PI8WNO<PI8HGL<
PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 990924/2214Z @:PI8VNW.#ZH2.NLD.EU #:2317 [HvHolland] FBB7.00g $:HD_99_240
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA19802 ; Fri, 24 Sep 99 21:50:57 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
id AA00015901 ; Fri, 24 Sep 99 21:10:36 MET
Date: Fri, 24 Sep 99 21:02:14 MET
Message-Id: <hd_99_240J>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/240J
X-BBS-Msg-Type: B
> >> TNC, what are the best frequencies to use? Does the
> >> average Clover or Pactor controller have the capability of relaying
that
> >> kind of data to the software?
>
> >The software running on the computer controls the TNC and the radio.
> >That software simply tries a connect, and if the connect fails, it tries
on
> >a different frequency or band. Very simple actually.
>
> Of course that approach is much too simple... it is just like the
firmware
> in the old TNC's: when the CONNECT succeeds, it starts retrying the data
> transmission until hell freezes over.
>
> What you need is some link quality data on each of the available
> frequencies, and a decision algorithm to decide which is the best
frequency
> to use. That will be a bit harder to implement, so it is probably left
> for version 2.0
As you probably know Rob, the controllers (at least the HAL
controllers) do in fact report running link quality information:
S/N, dispersion, data rate obtained, etc. The software can make
whatever use of that information it wishes. But you do have to
establish a link to gather the information.
--
... Hank
http://horedson.home.att.net
>.
------------------------------
Date: Thu, 23 Sep 1999 17:21:19 GMT
From: nomail@pe1chl.demon.nl (Rob Janssen)
Subject: Those Wide, Open Spaces
Hank Oredson <horedson@att.net> wrote:
>> Of course that approach is much too simple... it is just like the
>firmware
>> in the old TNC's: when the CONNECT succeeds, it starts retrying the data
>> transmission until hell freezes over.
>This is not true.
It is. When a link is that marginal that an SABM/UA or an RR(P)/RR(F)
can be exchanged, but an I frame never makes it through, the classic
TNC firmware will retry forever.
>> What you need is some link quality data on each of the available
>> frequencies, and a decision algorithm to decide which is the best
>frequency
>> to use. That will be a bit harder to implement, so it is probably left
>> for version 2.0
>How would one acquire link quality data without establishing a link?
My software measures link quality by sending numbered UI frames on
the link and evaluating the ratio between received/missed frames at
the other end. This allows evaluation of link quality independently
in each direction, even when the link is completely dead in one direction.
This is used very successfully on node-node links. It has helped us debug
some very strange problems.
When you want to use it to find the best frequency to use, the situation
is more complicated because you have to ensure that the ends are on the
same frequency at the same time.
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1chl@amsat.org | WWWhome: http://www.pe1chl.demon.nl/ |
| AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
>.
------------------------------
Date: Thu, 23 Sep 1999 11:08:28 -0700
From: "Hank Oredson" <horedson@att.net>
Subject: Those Wide, Open Spaces
Rob Janssen <nomail@pe1chl.demon.nl> wrote in message
news:slrn7ukocf.43f.nomail@linux.pe1chl.ampr.org...
> Hank Oredson <horedson@att.net> wrote:
>
> >> Of course that approach is much too simple... it is just like the
> >firmware
> >> in the old TNC's: when the CONNECT succeeds, it starts retrying the
data
> >> transmission until hell freezes over.
>
> >This is not true.
>
> It is. When a link is that marginal that an SABM/UA or an RR(P)/RR(F)
> can be exchanged, but an I frame never makes it through, the classic
> TNC firmware will retry forever.
Ah. "... the classic TNC firmware ..."
Yes, of course it will. Nobody would run such junk anymore,
would they? Just ask the FLEXNET folks, check out what has
been done in Linux and the modern *NOS codes. Welcome to
the 90's ...
> >> What you need is some link quality data on each of the available
> >> frequencies, and a decision algorithm to decide which is the best
> >frequency
> >> to use. That will be a bit harder to implement, so it is probably left
> >> for version 2.0
>
> >How would one acquire link quality data without establishing a link?
>
> My software measures link quality by sending numbered UI frames on
> the link and evaluating the ratio between received/missed frames at
> the other end. This allows evaluation of link quality independently
> in each direction, even when the link is completely dead in one direction.
Oh, you are talking packet. Thought we were discussing HF, where
packet is not among the useful protocols.
> This is used very successfully on node-node links. It has helped us debug
> some very strange problems.
On HF?
> When you want to use it to find the best frequency to use, the situation
> is more complicated because you have to ensure that the ends are on the
> same frequency at the same time.
Um, yes ... this IS what we were discussing: HF, Scanning radios,
frequency agile links, stuff like that. Protocols of interest are CLOVER
and the various PACTOR varitiations. Propagation is the point of
interest. Many of the controllers are capable of determining link potential
by listening on the channel. As far as I know, the ham radio software does
not yet take advantage of this capability. I've written some code, but it
has not yet proved useful.
> Rob
> --
>
+----------------------------------+--------------------------------------+
> | Rob Janssen pe1chl@amsat.org | WWWhome: http://www.pe1chl.demon.nl/
|
> | AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU
|
>
+----------------------------------+--------------------------------------+
>.
------------------------------
Date: Thu, 23 Sep 1999 22:17:33 +0200
From: "E.D" <ed3@club-internet.fr>
Subject: welcome in my site
venez tous visiter mon site fraichement mis a jour
http://www.perso.club-internet.fr/ed3
>.
------------------------------
Date: Thu, 23 Sep 1999 08:41:43 -0700
From: "Hank Oredson" <horedson@att.net>
Subject: What happened to tcpip gateways?
kb5cdx on 144.97, wb7alw on 7.103 last I checked, n7fsp on 145.01.
There are tons of them.
Lots of different ways to get to the internet from packet radio.
--
... Hank
http://horedson.home.att.net
Dick Kriss <kriss@spec.com> wrote in message
news:kriss-2209992056560001@lanrover4.spec.com...
> Our gateway has been QRT for a few months (long story) and it is now alive
> and well. I have been trying to find some of the old gateways and many
> seem to be QRT.
>
> If you know of an active gateway, please send me its name and ip number.
>
> 73 de Dick, KD5VU
> kd5vu@ausgw.n5smn.ampr.org
>.
------------------------------
End of Ham-Digital Digest V99 #240
******************************
You can send in your contribution to this digest by
sending an e-mail to: hd-group@pa2aga.ampr.org
or (via BBS-net) to: hdaga@pi8vnw.#zh2.nld.eu
Read previous mail | Read next mail
| |
