| |
ZL3AI > APRDIG 02.10.03 10:16l 234 Lines 9935 Bytes #999 (0) @ WW
BID : 2052-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 29, 8/12
Path: DB0FHN<DB0RGB<DB0MRW<DB0ERF<DB0FBB<DB0BI<DB0NOS<DB0EA<DB0RES<ON0AR<
IW8PGT<SP7MGD<ZL2TZE<VK3KAY<ZL2BAU<ZL3VML
Sent: 031001/1406Z @:ZL3VML.#80.NZL.OC #:9452 [Chch-NZ] FBB7.00i $:2052-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Take Control of your DIGI part 4
From: "Bill Vodall - WA7NWP" <wa7nwp@jnos.org>
Date: Mon, 29 Sep 2003 16:05:36 -0700
X-Message-Number: 37
>KE4ROC-9>BEACON,WC4ADG,W4SBO-7,W4GPS-7*/1:!3440.31N/08633.13W_Remote U2000 WX
Station
>KE4ROC-9>BEACON,WC4ADG,W4GPS-7,WIDE*/1:!3440.31N/08633.13W_Remote U2000 WX
Station
>
>Go back at look at the explanation and tell me that callsign substitution
>works (reality check). The Kantronics failed.
That's exactly as expected. Kantronics does not do dupe elminination
on WIDE packets. It's a problem with their implementation.
It's one reason we need to replace Kantronics boxes with DIGI_NED systems.
>The UIDIGI failed.
That would be interesting to check with the UIDIGI folks. Maybe a firmware
upgrade is needed on the UIDIGI TNC.
73,
Bill - WA7NWP
----------------------------------------------------------------------
Subject: Re: LANn-N routing.
From: "Georgette Sampson" <georgette.sampson@cox.net>
Date: Mon, 29 Sep 2003 18:11:31 -0500
X-Message-Number: 38
>I, personally, would like to see us switch from FM to SSB and use a form of
>PSK for multi channel capabilities. We could use SSB at 15khz wide to allow 1
>at 1khz plus 7 at 2khz segments to be utilized. 1khz for rendevous, and the
>other seven, would be assigned and timed by the digi with incomming stations
>asking the digi for a slot, and the digi handing out a segment and timeslot
>based on the request from the station. The digi would be able to transmit on
>all 7 at a particular time interval if needed to balance the availability of
>inbound and outbound bandwidth.
APRS or any data-link is at best a local thing, and high baud rate versus
long training sequences keeps the frame rate high. Many police use 4FSK at
4800 baud, and the data rate is too hard for me to keep up with, as it
flows off the screen so fast. 4FSK requires better SNR than 2FSK (i.e.,
FSK) but short range is what data-link is all about. Data-link feeds
(WIDE, GATE) would be good at long training sequenced PSK, that could have
high effective baud rates at long ranges, even in the presence of various
types of interference.
My personal favorite, since it can use the GPS timing as a synchronizing
time-base, is TDMA. With a cycle time of one second and four time slots,
each tracker could transmit 256 bytes a second in their time slot using
(say) a 9600 baud system. That is:1200 total bytes per frame (second), 300
bytes per slot (256 data bits plus guard bits). Slot 1 for uplink mobile,
slot 2 for uplink fixed, slot 3 for downlink mobile, slot 4 for downlink
fixed, where uplink and downlink refer to a node (RF or Inet).
Course this is all back of the envelope stuff :-)
Bob's stuff probably took 20 years to become mainstream, so whatever people
experiment with today, as far as new data-link ideas, will be mainstream in
2023 when the B-52 is phased out of service.
----------------------------------------------------------------------
Subject: Re: An alternative to the proposed "NEW WIDEn-N Paradigm"
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Mon, 29 Sep 2003 19:09:42 -0400
X-Message-Number: 39
Nice theory...but there is nothing in place (or on the horizon) to
accomplish this. We're back to either:
o Modifying user behavior
-or-
o Maximizing network capacity
Ev, W2EV
Wes Johnston wrote:
>
>What if ..... you got dupes from a station which you knew was
>LOCAL. Rather than dropping the packet on the floor if it's a dupe, modify
>it's path (ie set the HID flag in all digipeater slots, and decrement all
>wideN-N counters) so that it will not be digipeated by the next digipeater
>in the chain. In this way, we have the ability to send as many redundant
>packets as we want, ONLY in our LOCAL area. This way, if someone is
>flooding our local network, we can get to him and wring his neck, but if we
>really really need to flood our area, we can.
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 4
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Mon, 29 Sep 2003 18:17:42 -0500
X-Message-Number: 40
>When I go to findu and request 100 stations within 100 miles of W4GPS-7 I see
>that there are perhaps way too many digis in the area. And, perhaps even
>worse, perhaps many do not have dwait=0. If there are 14 digis that hear my
>packet with RELAY,WIDE as the path, and many do not have DWAIT=0 set, then
>they will each take up a slot digipeating the packet, and you will see each of
>the digipeating it as you do in your list.
This is not the discussion and I seriously doubt that 14 digi's will hear
you in various parts of the area. You have to take the foothill's of the
Applachian Mountains into consideration before coming to a conclusion of
what is blocked by a hill and what is not blocked. No range circle will
show the actual coverage of these digi's.
>Those not doing substition are hiding their presense in your list making it
>more difficult to see the real issues. DWAIT=0 is a big issue when you have
>as man digis as I see in that list. All of them must transmit at the same
>time, or else there will be way too many copies of the packet visible to
>other, possibly broken digis, and sure enough, it will take 30 seconds for a
>single packet to be digipeated...
Even if 14 digi's did indeed fire off, we have a bigger serious problem
with callsign substitution and packet duplication. We have TRACE to use for
those debug functions, we do not need callsign substitution when it does
not work like we think it should. That does not solve anybodies problem
when it is broken.
The data log collection proves that callsign substitution does not work
like Bob has explained. It is evident that the callsign substitution digi's
are duplicating their own already digipeated packets. Even if all the
digi's responded to the first RELAY, does not explain why they continue to
duplicate packets heard in the second and third digi.
My point has been stated and I believe that callsign substitution is bad
because of the way it is implemented. It is obvious that these digi's DO
NOT, I REPEAT, DO NOT look at the actual payload to determine if the packet
has been digipeated. Thus, if a packet path has been altered by callsign
substitution the digipeater is brain dead to the fact that it has already
digipeated the payload. My point has been made the case has been presented
as the reality of today's network.
Now, we can continue to ignore the reality of the network in how it really
performs or ignore it and hope the firmware in all the digipeaters will be
upgraded in the future, but I am not holding my breath that long. We have
to make do with the current reality and work on the future.
Tim - N8DEU
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 4
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Mon, 29 Sep 2003 18:21:07 -0500
X-Message-Number: 41
>>KE4ROC-9>BEACON,WC4ADG,W4SBO-7,W4GPS-7*/1:!3440.31N/08633.13W_Remote U2000 WX
Station
>>KE4ROC-9>BEACON,WC4ADG,W4GPS-7,WIDE*/1:!3440.31N/08633.13W_Remote U2000 WX
Station
>>
>>Go back at look at the explanation and tell me that callsign substitution
>>works (reality check). The Kantronics failed.
>
>That's exactly as expected. Kantronics does not do dupe elminination
>on WIDE packets. It's a problem with their implementation.
>
>It's one reason we need to replace Kantronics boxes with DIGI_NED systems.
>
>>The UIDIGI failed.
>
>That would be interesting to check with the UIDIGI folks. Maybe a firmware
>upgrade is needed on the UIDIGI TNC.
I would be the UIDIGI can be fixed quickly. I might lose my breath on
Kantronics. Not everybody is going to switch to DIGI_NED even though it
works as Bob has explained.
In this event if you want commonality in a network you have to go with the
least common denominator. We know what that suggests, but can we bring
ourselves down to it as a starting point the reality of what can be done
now.
----------------------------------------------------------------------
Subject: Re: LAN n-N routing.
From: "Georgette Sampson" <georgette.sampson@cox.net>
Date: Mon, 29 Sep 2003 18:25:47 -0500
X-Message-Number: 42
>And who will pay for all the new hardware?
If it's fun, and new, then Hams will. If it's just more retread-AFSK, you
may have a point.
----------------------------------------------------------------------
Subject: RE: Daydreaming...
From: <BobDonnell@arkalmus.com>
Date: Mon, 29 Sep 2003 16:20:45 -0700
X-Message-Number: 43
>-----Original Message-----
>From: bounce-aprssig-17768@lists.tapr.org
>[mailto:bounce-aprssig-17768@lists.tapr.org]On Behalf Of Richard
>Amirault
>Sent: Monday, September 29, 2003 4:00 PM
>To: TAPR APRS Special Interest Group
>Subject: [aprssig] Daydreaming...
>
---deleted---
>
>GEE, wouldn't it be nice if we could say, "If you want to run APRS then
>FIRST you have to learn and use APRSDos for 3 months .. before
>you can use
>any other version."
What'd make more sense is if Bob B. instead of referring folks to files
that are a packaged part of APRSdos instead turned them into cohesive
hyperlinked web pages, and when referring people to his past work, gave
them a link to the proper place on the proper page(s) to explain his
thinking when he designed and wrote that information - or whatever it's
evolved into since then. Especially if Bob went to the trouble of
adding the appropriate reinforcing commentary to those documents in the
documents themselves, instead of the much more transient visibility
offered by email. Yes, the email archives can be searched, if you know
enough about what you seek - but if not, it's pretty much "Mission
Impossible" - or at best, "Mission Improbable".
73, Bob, KD7NM
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
