| |
ZL3AI > APRDIG 05.10.03 10:32l 242 Lines 9845 Bytes #999 (0) @ WW
BID : 2092-ZL3AI
Read: GUEST
Subj: TAPR Digest, Oct 02, 2/5
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<VK6HGR<ZL2BAU<ZL3VML
Sent: 031004/1241Z @:ZL3VML.#80.NZL.OC #:9735 [Chch-NZ] FBB7.00i $:2092-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: Random backoff
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Thu, 02 Oct 2003 13:18:07 +0200
X-Message-Number: 5
Hello Bob,
At 16:07 1-10-03 -0400, Bob Bruninga wrote:
>Yes, and none of those are APRS digipeaters!
Of course they are! BayCom and SCC cards are definitely used (with
DIGI_NED), just as TNCs which in Europe most of the time have a WA8DED
hostmode PROM with NORD><LINK's TheFirmware instead of a TAPR prom and are
mainly used in KISS. PicPar and PAR96 are not used because they are 9600
baud types, they are used however on shared channels with regular packets
on a 9k6 backbone on UHF. The YAM modem could be used in a digipeater for
1k2 altough its 1k2 performance is not very good. AGWPE is used by UIview,
which is deployed as the main digipeater technology in the UK. Linux can be
used in case of DIGI_NED. UIDIGI is definitely a digipeater. So I'm talking
about digipeaters here.
>My statement that D-WAIT must be 0 applies ONLY to digipeaters and does
>not apply to ANY users of ANY other TNC or hardware, firmware or
>software...
Yes, I understood that from the beginning.
>Further in all those NEW softwares and KISS and anything else you refer
>to, IF THEY ARE A DIGI, then they MUST SIEZE the channel first for proper
>UI operation. I dont care how users fight over the persist and slots,
>that does not affect the APRS infrastructure, only their own success
>rates.
Yes! To accomplished immediate seizure of the channel in all those systems,
PERSIST shall be set to 255 and SLOTTIME to 0. This also works for the TNC
based digipeaters as deployed widely in the US. The result will be the same
as DWAIT=0, but it uses the parameters that are current today and not some
artefact of the past only present in TAPR TNC look-alikes. Its an
alternative to DWAIT=0 with the same effect and unlike DWAIT applicable for
all past, current and future digipeater solutions including UIDIGI, UIview
and DIGI_NED.
>We DO NOT WANT ANY USERS to be running Dwait of 0, or PERSIST=255 or
>SLOTTIME=0... Only the DIGIS... They get first shot at the channel.
You keep repeating this, I knew this from the start. I'm only talking about
digipeaters ok?
>Shouldnt be necessary if DIGIS just use Dwait of 0.
Or use PERSIST=255 and SLOTTIME=0... This is exactly equivalent to DWAIT=0.
>Now that we understand that I am talking about only the digis and not any
>of the users, can you clarify whether you agree that the digi should
>sieze the channel first (once it has a valid packet) or whether we need
>to continute to debate this one.
I can agree partially, I think it depends on the environment.
If the digis in the environment do not have any checking for duplicate
copies of the same packet then I think your idea is a good idea. It will
save a lot of unneeded packets even though the price to pay is that some
areas will not receive packets due to both digis jamming each others
signals to oblivion. With unneeded packets I mean just that, packets that
are not needed after everybody got a fair chance to receive the data.
If there is adequate checking in the digis then I think it should not be
done. You will get frequency reuse anyway in both cases. If you have digis
A and B and B transmits after A instead of simultaneously, then still
stations in digi A's footprint but outside the range of B will transmit
simultaneously with digi B. Since these stations are likely to be close to
digi A, their packets will be received by digi A despite that digi B is
transmitting at the same time.
When the channel is loaded to 18%, the limit the channel under ALOHA
conditions can sustain, then the latency by the digi, even if they transmit
in sequence, will be low, in the seconds range.
* If you have simple digis in the area then let them overlap since the loss
of packets in some areas outweighs the advantage of a lower load.
* If you have smart digis in the area then do not overlap since it doesn't
gain much and makes reception more reliable (the network will become a bit
more CSMA and a bit less ALOHA bound).
Of course in both cases the channel shall not be overloaded, otherwise
packets are lost due to collisions and nothing will save that, overlapping
transmissions or not.
>Thanks for your input...
You're welcome. Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: New Mexico LANn-N?
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 2 Oct 2003 09:10:18 -0400 (EDT)
X-Message-Number: 6
On Thu, 2 Oct 2003, Ev Tupis (W2EV) wrote:
>Hi Jim, The point of my post wasn't SAR, it was the fact that - with the
>best of intentions - the LANn-N proposal violates basic APRS tennants,
>both technically and philisophically. A point that still stands on it's
>own.
Ev, then you totally missunderstand APRS. Having a FIREWALL around your
LAN that BLOCKS DX WIDE7-7 trafic that is INTERFERING with your LOCAL LAN
is 100.000% in accordance with the most FUNDAMENTAL principles of APRS.
BOTH TECHNICALLY and PHILOSPOHICALLY!
APRS is a TACTICAL-REAL-TIME-LOCAL COMMUNICATIONS system. It is NOT DX!
and it cannot support 1000 users from 500 miles away! This LANn-N tool is
just an option that gives good communications planners a way to gain back
some CONTROL of their APRS system.
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: The Human Factor [was: New Mexico LANn-N?]
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 2 Oct 2003 09:14:27 -0400 (EDT)
X-Message-Number: 7
On Thu, 2 Oct 2003, Ev Tupis (W2EV) wrote:
>Bob Bruninga wrote:
>>
>>You missunderstand completely.
>>Every digi still responds to RELAY and WIDE. Thus the universal path for
>>mobiles would still work in NM EVERYWHERE. More comments b elow
>
>Then LANn-N is more profoundly weaker than the existing system is. Here's why:
>
>You have said that the problem is W5-5, W6-6, W7-7, etc. You have said if
>WIDE2-2 is good then some folks think WIDE6-6 is much better. LANn-N forces
>people who think that way to now launch as W,W,W,W,W,W to get to the "same
>place" (both geographically as well as philisophically) as before...with
channel>obliterating results.
They MUST NOT BE DOING THAT ON APRS. And now we have a means to enforce
it! APRS is not a DX system. The new paradigm is SIMPLE!!!!
1) Use ONLY local 2 hop GENERIC paths of RELAY and WIDE
2) For ANYTHING else, you MUST either, include specific digis
3) OR use one of the NEW n-N paradigm options
This allows you to go as FAR as you possibly can, and you CAN use
WIDE7-7 where it CAN be used.
BUT we are cutting off the FLOOD of junk in areas where it CANNOT be
tolerated. And this is done by SYSOPS"managing" the system with some
forethought! NOt just total anarchy as we have today..
Everyone wins.
de WB4APR, Bob
>XXXn-N replacing WIDEn-N is bad. It firewalls the packets that don't
>saturate the frequency as much, encouraging the use of packets that will
>obliterate the network.
Wrong thinking.
People are not INTENTIONALLY Killing the newtork. THey are doing it
UNKNOWINGLY. We are going to FIX that NOW.
Bob
----------------------------------------------------------------------
Subject: RE: Random backoff
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 2 Oct 2003 09:16:03 -0400 (EDT)
X-Message-Number: 8
On Thu, 2 Oct 2003, Henk de Groot wrote:
>At 16:07 1-10-03 -0400, Bob Bruninga wrote:
>>Yes, and none of those are APRS digipeaters!
>
>Of course they are! BayCom and SCC cards are definitely used (with
>DIGI_NED), just as TNCs which in Europe most of the time have a WA8DED
>hostmode PROM with NORD><LINK's TheFirmware instead of a TAPR prom and are
>mainly used in KISS.
Read my email. I am CLEARLY talkling about fixing 144.39 IN THE USA. I
dont care what they do in Europe. In the USA, I would say that NONE of the
1000 digipeater are Baycom or SCC cards!
Back to the program in progress...
Bob
----------------------------------------------------------------------
Subject: Re: APRS Linux digi, was: Re: DigiNed, was: Re: Take Control of your
DIGI part 4
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Thu, 02 Oct 2003 14:08:49 +0200
X-Message-Number: 9
Hello Sean and Scott,
At 16:44 1-10-03 -0500, Sean \\The RIMBoy\\" <sean@rimboy.com> wrote:
>On Wed, 1 Oct 2003, Scott Miller wrote:
>>It's got a CF socket built in, and I'll probably by testing it with
>>the 16 meg card I've already got on hand, but 128's are pretty cheap these
>>days.
>
>Excellent. Nice to see a company forwarding thinking a little bit.
Just thinking about it, Linux also runs from CF cards on Psion orgranizers.
These are also very small and have a low power consumption and I think they
have a standard serial port. I have no idea if they can be had cheap
second-hand. If it runs a kernel with AX.25 support then I don't think
getting DIGI_NED to run should give any problem (I tried hard to make
DIGI_NED portable so there should not be any big-endian/little-endian
problems, I guess Psion uses a ARM processor inside). If it doesn't have
AX.25 support a small piece of software has to be added to make DIGI_NED
talk KISS directly to the serial port, shouldn't be too hard to do.
People have also mentiond small HP handhelds with an XT class IBM compatibe
PC on this list before (to run APRSdos on it). When I compile the DOS
version without 80286 support it should run fine on these too, as long as
you stick to KISS type TNCs and do not attempt to use BayCom modems with
it. If they contain a 80186 or NEC V20 processor then the distributed DOS
version should run on it without the need for recompilation.
Kind regards,
Henk.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
