| |
ZL3AI > APRDIG 11.06.04 10:17l 644 Lines 29080 Bytes #999 (0) @ WW
BID : 3428-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 05, 4/8
Path: DB0FHN<DB0FOR<DB0SIF<DB0CWS<DB0FP<DB0TTM<DB0WUE<DK0WUE<HA3PG<7M3TJZ<
F6KMO<EA5DVS<EA5RQ<VK7AX<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040611/0700Z @:ZL3VML.#80.NZL.OC #:25629 [Chch-NZ] FBB7.00i $:3428-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: updating databases over aprs?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sat, 05 Jun 2004 11:33:28 -0400
X-Message-Number: 52
>>>"David John Walsh" <david.walsh@vodafone.net> 06/05/04 11:03 AM >>>
>I am about to start to build a database that will need
>to have multiple clients attached to the server (for a Scout
>hike, over amateur radio). It is my intention to use APRS
Yes, we have dont things like this with APRS before. I suggest you
seriously consider placing the data in the MESSAGE format since anyone with
only a TH-D7 HT can then enter the data base with only the keypad on his
HT. This makes quick and easy reporting very rapid.
Also then. plan on structuring your format to minimize keystrokes. APRS
now even supports position reporting (by checkpoint number) using only the
TH-D7 keypad. See http://www.ew.usna.edu/~bruninga/aprs/D7points.html
>My second question is how would you go about it,
>has anything been done like this before
Yes, I love these kinds of applications. Tell us the key data elements
desired, and Ill suggest a way to fit it best into APRS...
>The reasoning behind this is that we as a group use and
>appreciate APRS, but with the requests coming in now,
>we need the ability (with no more equipment in the car!)
to give the checkpoint operators to send in their data.
Then by all means plan on entering it just from a TH-D7 keypad using the
APRS message format and you will have a real practical piece of work...
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: DIGIpeater OBJECTS
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Sat, 05 Jun 2004 10:34:06 -0500
X-Message-Number: 53
>But I do strongly object to your original stated purpose of
>letting the digis take over reporting responsibilties for all
>home stations for the same original reasons I said before:
>
>1) APRS is real time. When I get a packet from a home
>station, it tells me his is LIVE and avaialble now, and an
>active participant of the real-time net.
Scott included a lease time in his design which means that the digi would
stop transmitting at the end of the lease time if the station does not
renew its lease by rerequesting the operation. Thus, you get the required
removal from the network when the station is not there, and you get the
network optimization by reducing the bandwidth by 1/2. In situations where
the true status of the object is vital, you wouldn't use this mechanism.
But, for objects that have a reasonable chance of not instantly
disappearing, you can use this mechanism to optmize net bandwidth.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: 30 Meter Policing needed.
From: "Clayton H. Owen" <aa3jy@winlink.org>
Date: Sat, 5 Jun 2004 10:49:18
X-Message-Number: 54
Sounds like we need our beacon station(s) back again...
----------------------------------------------------------------------
Subject: New APRS Digi-Object-Maintenance format
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sat, 05 Jun 2004 11:49:47 -0400
X-Message-Number: 55
>>>"Scott Miller" <scott@3xf.com> 06/04/04 10:58 PM >>>
>I propose an encoded TOCALL field to indicate cache
>[digipeater-maintained-objects] requests.
>
>Comments anyone?
Yes, I LIKE that idea. It fits in well and seamlessly with the mechanism
already in place for doing this task. So Here is a suggestion on how we
can flesh this out a bit and accomodate DIGI-OBJECT-MAINTENANCE reporting
in APRS that is fully backwards compatible:
OBJECTIVE: A format to signal to a digipeater or other specialized APRS
station to take over reporting responsibility for a given object:
FORMAT: Identical to existing OBJECT format
TOCALL: OBJxyz
Where: x = expiration time in hours from now
y = periiodiciy in minutes
z = tbd
where x and y are base 36 (1-9,A-Z)
RESTRICTIONS: The packet must be heard DIRECT.
DETAILS: This is fully backwards compatible with existing APRS, it is only
a means of signaling a request by an originator to ask a digi or other
responsible software to take over reporting responsbility for the object.
Although taking over responsiblity for objects has always been fundamental
to APRS, this new format proposed by Scott Miller allows the sender to
explicitly designate his object for taking over instead of depending on an
APRSdos program with NET-CON enabled to be running nearby.
The restriction on the packet that it must be heard direct is to limit the
damage that APRS spammers can inflict to only their own neighborhoods.
ANything I missed?
Thanks.
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: updating databases over aprs?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sat, 05 Jun 2004 11:55:37 -0400
X-Message-Number: 56
But why not make it easy to transmit from the field from a handheld? The
TH-D7 is an excellent reporting device on a hike (which was his stated
objective.) Again, NO NEED to creat more and more unique protocols... just
send it in a message from an HT...
Bob
----------------------------------------------------------------------
Subject: Re: Proposed NWS policy change
From: Gerry Creager N5JXS <gerry.creager@tamu.edu>
Date: Sat, 05 Jun 2004 11:18:01 -0500
X-Message-Number: 57
This has been available for review for at least a couple of months.
I've seen nothing that will pose even a potential adverse impact to
APRS. It offers the potential for more data availability. That's what
it's all about, getting NWS-corporate to let loose some control they
really don't need to exert.
gerry
n2iph@comcast.net wrote:
>I was on the NWS site this AM and found this, thought others may be
>interested as it relates to access and dissemination of information by
>NOAA/NWS which could affect (good or bad is yet to be seen) Skywarn and
>APRS WX.
>
>http://weather.gov/fairweather/policy.php
--
Gerry Creager -- gerry.creager@tamu.edu
Texas Mesonet -- AATLT, Texas A&M University
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.847.8578
Page: 979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sat, 05 Jun 2004 17:14:10 +0200
X-Message-Number: 58
Quoting Robert Bruninga <bruninga@usna.edu>:
>>>> "Scott Miller" <scott@opentrac.org> 6/4/04 11:48:40 AM >>>
>>First, as Wes pointed out OPENTRACK is exactly compliant
>>with both the APRS spec and the AX.25 spec.
>
>1) No it is not. As Jeff clearly points out, the spec says APRS
>packets are to be transmitted with the PID of F0.
Which means that all APRS applications should only accept packets with a
PID of F0 since all the other packets are invalid for APRS. If any APRS
application that accepts packets with another PID and still parse it as
APRS packet, it is broken and in need of repair.
As you know Kenwood made a lot of programming errors in their AX.25
implamentation in TH-D7 but even they got this FUNDAMENTAL AX.25 proprety
right, which fact alone shows how BASIC this is to any AX.25 application.
The TH-D7 has no problems listening to a channel with TCP/IP, ARP, NetROM
datagrams and APRS packets (which are all using UI frames) and will only
pick up the APRS packets and leave the datagrams alone. In PACKET mode the
monitor of the TH-D7 does not print out ASCII text-representations of
packets with another PID than Text (= F0). Switching TRACE to ON does show
all packets as binary dump but there is no attempt to print it is ASCII.
Kenwood did it right this time and the Kenwoods can co-exist with OpenTrack
without problems.
It is short-sighted to blame OpenTrack for the failure to comply with the
APRS protocol specification. Whining over having to addapt... It's like
building a crapy house and then blame colapsing on the first storm that
passes by. You should be glad your crapy house did not collapse earlier and
lasted as long as it did. Likewise you should have been glad that you got
away with a bogus APRS implementation for so long. Those that need to fix
their system should not blame anybody but themselfs for not adhering to the
APRS protocol specification in the first place.
As you may have noticed the discussion is purly focused on the US network.
In Europe I have never seen any co-existence problems between APRS and
other AX.25 protocols. We ran APRS over RF interlinks that also carry AX.25
conneced packets (with PID F0), TCP/IP packets, NetRom, INP and even an
experimental protocol that uses yet another PID. Nobody here is that stupid
to use a man-machine interface as machine-machine interface, the Europeans
had to learn this because we still have RF-packet networks with a lot of
binary protocols sharing te same QRG.
The protocol ID, aka PID, is part of AX.25 since the very first version of
it (it is in the long obsolete AX.25 V1.0, which TNC's you should only find
in a museum, and in each and every AX.25 V2.0 implementation, which was
concieved by TAPR in 1982). It is a very FUNDAMENTAL part to discriminate
between different protocols (hence Protocol ID). It is FUNDAMENTALLY WRONG
to disregard it. Although there are many flaky TNC designes, I think you
will have a hard time to find any that doesn't know about protocol-ID's.
Okay, I shut up now. Impact of this message will be zero anyway but I could
not resist any longer to post a reaction anyway.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sat, 05 Jun 2004 17:36:03 +0200
X-Message-Number: 59
At 18:19 4-6-2004 -0400, Robert Bruninga wrote:
>Yes, all of which are incompatible with the very
>fundamnental basis of APRS. Hence our suggestions
That's why OpenTrack does not transmit the APRS protocol but transmits the
OpenTrack protocol (as indicated by the Protocol ID). If tomorrow I decide
to transmit the Applepie protocol no other AX.25 protocol should fail,
provided that I use an uniq Protocol ID to define the Applepie protocol. If
your AX.25 application fails because you forgot to check if you received
the right protocol then you deserve the work to fix your failure.
I never encountered any protocol specification (including the APRSSPEC)
that uses the QRG as protocol specifier as you seem to want for APRS. I can
assure you that I've seen a lot of protocols. If I wouldn't know better I
would think you are pulling some practical joke. Sad thing is that you
realy seem to sugguest that any packet on 144.390 does not need any
aditional protocol checking and you can blindly assume it must be APRS
since it appears on this QRG.
My suggestion is to keep these valueable future protocols on the QRG and
fix the bogus implementations that fail to check what kind of data is
received.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sat, 05 Jun 2004 18:23:31 +0200
X-Message-Number: 60
At 20:06 4-6-2004 -0400, Robert Bruninga wrote:
>Or scan for all kenwoods, That should give you
>about 3 thousand on any given day... is that enough?
Kenwoods, safely ignores all OpenTrack packets, so no problem here.
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sat, 05 Jun 2004 17:55:30 +0200
X-Message-Number: 61
At 19:00 4-6-2004 -0400, Robert Bruninga wrote:
>4) APRS allows extensions just just fine.
Not true, APRS relies on ASCII and the current practice (at least in the
US) uses a lot of TNC's in text mode. You can't extend APRS with a pure
binary protocol, the first 0x0d in the datastream for example would break a
lot of APRS implementations. You can only imagine what happens when
tranmitting bytes between 0x00 and 0x20 and 0x80 to 0xFF. I think any such
extention would realy break things. I even read that some characters need
to be avoided because they represent a TNC "switch" character or some such.
I don't know how you envision to squeeze in a binary protocol based on
short elements that can be combined at will like OpenTrack as APRS
extension without breaking much more than just making a separate
independent protocol not tied in into APRS and using a separate protocol
identifier.
You used to be a man of vision, did you loose that? Why can't you see
futher than you nose-length anymore? Or... are you just not willing because
OpenTrack is not your idea?
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: db2fm <db2fm@jfsattv.de>
Date: Sat, 5 Jun 2004 18:32:59 +0200
X-Message-Number: 62
Am Freitag, 04.06.04 um 14:34 Uhr schrieb Jason Rausch:
>Scott said:
>>Ijust glanced over the HH2 source code, version 2.7.001d, and it
>>looks like
>>it's not using KISS. Is this right? I could've sworn I heard that it
>>worked ONLY with KISS TNCs.
>
>Exact opposite. The orginal code only worked with a Kantronics KPC-3. I
>wish it was KISS based because long ago I would have replaced my KPC-3 with
>Hansen's TNC-X or somthing similar.
I also would like to have that! May be you could contribute to the HH group
and the II+-board could be reality for all of us (not just Steve ;) and we
could have a different processor (not a PIC) on it - with or without TNC-
functionality!
>Back when my KPC-3 was the ONLY TNC I
>owned it was dedicating it to the HUD. Now that I have about 8 TNC's laying
>around including a second KPC-3, its not as bad. But I still want to see
>the day when I can replace it with a KISS modem and put it INSIDE the case
>with the HH2 it'self.
>
>One goal was achieved by Dale on the last revision, which was also a port of
>the code from a PIC16F876 to a PIC18F252, was to make the code universal
>with just about nay TNC-2 clone TNC. He currently is using a MFJ himself
>for testing. I made a quick attempt to use one of my MFJ's but it failed.
>I'm sure I had a parameter set wrong and a little more time would prove it
>works.
Also the 'old' PIC16F876 code works with (nearly) any TNC2-clone with TAPR
1.1.7 firmware or newer (tested in a TNC2C and a TNC2S, both German
models)!
>My ultimate goal is to put the HH2, TNC and and one of my Motorola Oncores
>all in one box. I'll have to keep the radio seperate since I'm dead set on
>my Motorola VHF Maxtrac, we Moto techs are just like that :o)
Mine too, but using a Bosch KF161.
>>Seems odd to be developing new stuff for
>>converse mode when we've had KISS for so many years, and now at least a few
>>KISS-only TNCs.
>
>Steve's explanation of that is, he had a KPC-3 at the time he started the
>project and just decided to write the code to that, that simple.
>
>Hope that clears some things up.
>
>Jason KE4NYV
I hope that some people on this list will calm down and don't exclude
progress to be made any longer. I sometimes think it's only because THEY
didn't have the ideas! .... or we could go back to our caves and paint
pictures on the walls of animals we ate to survive and get rid of these
round things called wheels! (just kidding!)
Still 151 mails to read on this list...
----------------------------------------------------------------------
Subject: '...I'll just take my ball and go home!"
From: "Brian Riley (maillist)" <n1bq_list@wulfden.org>
Date: Sat, 05 Jun 2004 12:50:12 -0400
X-Message-Number: 63
On 6/5/04 7:38 AM, <someone@somewhere.net> wrote:
>2,999 of them signed off the sig a while back because of the BS. Which
>is what I am going to do. 73.
You know this is the third instance of this I have seen during this
particular melee ... Usually each is followed by three more threats to leave
in case anyone didn't notice the first few and beg them not to be hasty. My
general reaction to these messages is "Good, don't let the door hit you in
the butt, when it closes behind you!" It leaves more bandwidth for those of
us who care. What's the matter didn't these people ever here of the Delete
key or a 'killfile' ????
I will say, once again, we all learn from these melees ... It gets stuff
out in the open and discussed, no-holds-barred. Granted it would be tiresome
if they went on for ever, but even the most cantankerous of the combatants
has to take a 'nice'-break once in a while! ;-)
Cheers ... 73 de n1bq
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] Re: Too many personalities
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Sat, 05 Jun 2004 11:57:11 -0500
X-Message-Number: 64
>You are wrong on several key points:
>
>1) it is a distributed network intended to update EVERY
>participant in the net to the CURRENT real-time tactical info.
>Thus it assumes everyone on the net has implemented the
>APRS protocol and that EVERYONE is privy to the SAME
>and to ALL information transmitted. When someone transmits
>the data in a real event, he has to ASSUME that everyone
>had a reasonable chance of getting it.
This is a response to this thread, not directly to Bob!
If Scott reformatted his packet to be a user defined packet to hide it from
parsers that had problems, then it would still not be useable by existing
APRS clients. If Scott encoded new types of data into a comment field, it
would still not be recognized by existing APRS clients.
By using the PID of 0x77, he has made it possible for KISS based software
packages to integrate new parsers that make use of a different structure of
data. This new structure, might someday replace the existing APRS data
formats. But, it might not. We have is the ability to operate at the same
time. If a station transmits only opentrac data, it will be, on the average,
less channel use than if it transmitted APRS data. This would be no different
use of the channel than if he stuck on {T at the beginning to say it was a
user defined packet, which would make you and everyone else happy. Instead,
he used 0x77 instead of 0xf0 as the PID which adds no channel overhead, and
still allows conforming TNC configurations (which seem to be well defined
configuration changes in the TNC setup) to ignore the data in the same way
that APRS applications would ignore the {T packets.
I think that it is interesting to try and find ways to continue to shoehorn
more functionality in to our APRS design. But, what I and apparently other
software authors are finding is that it is problematic in software design to
use such complicated formatting rules. From a formal language design
perspective, there are context issues that make it possible for programmers to
misunderstand the true position or context that they will find a particular
item in. Conditional processing becomes very cumbersome in embedded software
in particular, where such things add considerable code space in a restricted
environment.
OpenTrac makes it very explicit where data items are and how they are
structured. This makes it very trivial for embedded software applications to
extract exactly the items they can handle without having to conditionally
search.
Dynamic memory allocation in embedded applications can be very problematic.
So, APRS specifying the maximum length of fields is a good thing. But, what
it does is cause people to allocate fixed length buffers that will overflow
when improperly formed packets are on the air. This will then crash these
software systems, typically. OpenTrac specifies the length explicitly, so
that there standing programatic requirement to deal with the length issue. It
becomes a theme of the software design, and this makes for more robust
software.
We have a lot of people that seem interested in the transmit only telemetry
devices. There are less issues for software stability when you are
constructing packets. But, there are devices that handle data receipt (such
as the HamHUD) which have had problems with poorly formed packets for years on
end, because of the nature of APRS packets non-rigid format design (the spec
spells things out, but people can transmit anything). The more rigid
structure of OpenTrac is truely a benefit to the software design and writing
process. There is the packet type checks and the 2 length checks (do you have
a buffer to hold that much data and did you receive that much data) that
pretty much allow software to firmly establish the initial ability to safely
receive and evaluate the data.
Languages such as Java and your favorite, QBASIC, help the user by making
these length issues explicit in the constructs of the language and its library
of built in functions/methods/operations. Your experience with QBASIC
probably isolates you from the issues that many of the embedded systems
designers on this list continue to encounter while trying to use APRS in
restricted programming environments.
There are PIC-BASIC environments, and there are Java based microcontroller
environments. But, I think that the fundamental issue is still that the
structure of APRS packets doesn't provide the programmer with enough fixed
pieces of information to make sure that they can be successful.
OpenTrac's use of binary data for everything eliminates transformations that
can be coded incorrectly. The MIC-E transformation and the Base-91
compressions are both examples of your desire to reduce bandwidth. I am not
sure why there are two different ways to do the same thing, in the spec. But,
I suspect that you found certain problems with one that you tried to deal with
in the other.
This is where OpenTrac is comming from. Scott found problems in the existing
Amatuer Radio packet telemetry system, APRS, and is trying to do some
investigation to design a new way that doesn't have the same problems that he
found in APRS.
The whole evolution of the HF digit modes from CW through PSK-31 (and the
like) shows that there are better ways to do digital mode exchanges. There
are portions of the bands preallocated to particular modes on HF, because of
the propigation and operational characteristics of these modes. They have no
digipeaters. For a larger group of people to participate in OpenTrac and to
learn about it and make the decision of which mode they like best, a
digipeater infrastructure is needed.
To make APRS work with a digipeater infrastructure, we had to convice people
to move their TNCs and packet stations/digipeaters to a new frequency. Now
that this has happened, it seems like the community would be best served by
letting OpenTrac operate on this infrastructure. The channel load on
144.390mhz will not be any different, because if OpenTrac was using a user
defined APRS packet, it would still be on 144.390mhz. Instead, it is using a
different PID which can be properly digipeated in most circumstances. Just
like there was a slow change to get APRS digis on frequency and then to get
digis and igates configured to work correctly, there will be some time needed
to get the digis and igates further updated to provide seemless digipeating of
different types of packets.
Again, this doesn't increase the channel load, it just puts the same data on
the same channel with a different format. OpenTrac might never become as
pervasive as APRS is now. But, if APRS software authors make the switch to
operating only in KISS mode by default (converse can be used still in places
where OpenTrac won't be used or where KISS is not supported), they can take
the step towards using the PID to distinguish different protocols, and thus
plug in parser suites. I know this seems like a long way off, but, it does
provide a very critical enabling capability that would allow the digipeater
infrastructure to be utilized for needs that we can't all know now.
My JeAPRS (Java enabled Amateur Packet Radio System) project on source forge
was originally conceived by my perception that this is the direction that
should be persued. But, the combative attitude for progress on this list has
made me less than interested in doing something new. The technical
discussions never happen. Instead, those who have some cursory knowledge of
software and networking come screaming in with emotional arguments and can't
see the real issues because of their ignorance of these issues. Instead, they
have a very confined view of world, and show this with statements of obviously
incorrect details and assumptions.
So, we have to fight about everything it appears. Everyone believes that they
know everything about how things should work in the future because they
believe that they know everything about what the issues are now. So many of
the issues are direct attributes of poor software and systems design that
exists in the implementation of APRS today.
There are professional software engineers, network engineers and embedded
systems designers here that just can't get past the gatekeepers that are
screaming so loudly.
We have newcomers to the list that are leaving because of the screaming. We
have responses on this list to initial enqueries or statements that are always
initially provoking, insulting or accusational. These responders always
believe that they know everything involved and that there is not any missing
information it seems.
I'd suggest that everyone take a step back. The pro OpenTrac line is having
to reargue the same points because the anti OpenTrac line is not listening.
It seems like there is some common ground here, but it will never be reached
if we can put the ignorance and emmotions asside, and try to learn about the
opposing view in a way that makes it easy for everyone to participate in the
process
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: wes@johnston.net
Date: Sat, 05 Jun 2004 12:54:39 -0400 (EDT)
X-Message-Number: 65
I am so glad you brought the issue of DX Cluster to the table. Bob's own
APRS DOS tx'es DX Cluster type packets for satellite spots for the benefit
of the kenwood users. It would seem that the ends justify the means.
I will write Bob and ask him to cease transmitting DX Cluster packets on
the APRS _only_ channel.
Wes
On Sat, 5 Jun 2004 09:58:48 -0500, "hasan schiers" wrote:
>repeaters. We are not required to digipeat OT, if we don't want to. And no,
>simply being packet misses the point entirely. DX Cluster is packet...it's
>not welcome either. The equipment belongs to "us", and we decide how it will
ham callsign: kd4rdb
find me: http://wesvan.zapto.org
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Scott Miller" <scott@3xf.com>
Date: Sat, 5 Jun 2004 10:11:29 -0700
X-Message-Number: 66
>But APRS is a distributed NETwork designed for everyone to share
>the data for the mutual benefit of all. APRS is a one-to-all
>NET. Everyone participates, everyone expects to see the data.
>Adding incompatible OPENtrack packets to that network at the
>expense of collisions designed so that no one else can see
>them seems to me to be taking unfair advantage of the resources
>of others and at their expense.
Now, designing a packet so that no one else can see it would be a pretty
silly way to design a broadcast-based protocol, wouldn't it?
If I was to uuencode (not that the spec requires it) OpenTRAC traffic and
place it in a user-defined APRS format, what's the difference? None, except
that now anyone watching APRS is subjected to big strings of alphanumeric
garbage that they can't read either, rather than being able to ignore the
traffic completely.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Scott Miller" <scott@3xf.com>
Date: Sat, 5 Jun 2004 10:13:56 -0700
X-Message-Number: 67
>DIGIPEATER OBJECTS:
>I fully addressed this in a prior email and showed how it is
>fully supported already in APRS protocols. But that having
>DIGIS repeat all OBJECTS heard has all kinds of negative
>impacts on the net and is not a wise idea.
When did I say anything about having digis repeat ALL objects? If you'd
read my proposal, you'd see that it would require a specific cache request
from the originating station.
Please, read what I'm suggesting. It would reduce traffic for static
objects by quite a bit and reduce the number of collisions.
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
