| |
ZL3AI > APRDIG 12.06.04 21:27l 765 Lines 29956 Bytes #999 (0) @ WW
BID : 3440-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 06, 8/9
Path: DB0FHN<DB0FOR<DB0MRW<OK0PPL<DB0RES<ON0AR<7M3TJZ<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040612/1901Z @:ZL3VML.#80.NZL.OC #:25701 [Chch-NZ] FBB7.00i $:3440-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: OPENtrack Binary Versus ASCII
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 19:00:36 -0700
X-Message-Number: 123
>matter. We didnt use it, and we see no advantages
>to it for the end user worthy of obsoleting 20,000 users
>just so the programmers can play in binary...
You keep saying that, about 'obsoleting' 20,000 users. The phrase makes no
sense to me, and I think you're going to have to clarify a bit.
When I look up the transitive verb 'obsolete' in the dictionary, it says 'to
make obsolete.' The adjective 'obsolete' is defined as 'no longer in use or
no longer useful.'
Are you saying the APRS equipment of those 20,000 users would no longer be
used, or useful, simply because an alternative exists?
This is not a rhetorical question. I'd like an answer. Because you keep
bringing this up, presenting it like we're actively doing something to make
people's equipment somehow useless.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: APRS in the field. Big step forward...
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 22:14:18 -0400
X-Message-Number: 124
A MUST READ for APRS users:
>>>"Gregg G. Wonderly" 6/6/04 5:37:13 PM >>>
>Again, I think you are assuming that the ... mission
>of OpenTrac is identical to APRS. It isn't capable
>of that yet. The software packages, as they become
>capable of doing OpenTrac can switch to KISS mode
>support and then the PID will be the distinguishing
>factor for protocol parsing. Only when that infrastructure
>is in place, will OpenTrac have such a large following
>that the non OpenTrac compatible software and hardware
>will be at a disadvantage.
Like I said. Come back to the APRSSIG when you have that infrastructure in
place and let us know. IN the mean time as you so clearly point out, the
two are incompatible and should not be on the same channel... Either until
APRS all changes to accomodate the OPENtrack BINARY protocol or is
REPLACED...
>These guys are ... asking everyone to help make sure
>that it (opentrack) does not impact applications that are
>incorrectly having to see this data when they are not
>ready for it.
Again, why does all of APRSdom on the APRS channel have to change all of
their code to protect themselves from intentional interference from an
incompatible protocol that wants to take over their channel?
>And, in particular, the Converse mode problem of
>carriage control is a big issue, no matter what protocol
>ID and first data character OpenTrac packets are
>transmitted with. If binary data is passed in converse
>mode, carriage control is going to mess everything
>up for converse mode comms between the TNC
>and the software.
EXACTLY, And that is why we keep saying over and over that there is no way
the two can EVER share the same frequency until ALL existing APRS code is
removed from the channel...
I wonder why I dont like this idea...
Bob
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] OPENtrack for programmers, APRS for users
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 22:25:26 -0400
X-Message-Number: 125
>>>gregg@skymaster.cytetech.com 6/6/04 6:07:15 PM >>>
>But, what is happening is that I see programmers
>interested in doing a better job for the users. They
>want to be successful, and have limited time to spend
>on this volunteer effort. So, you bet, the programmers what it
>easier.
ABSOLUTELY, so they should NOT be required to have to implement both APRS
***AND*** OPENtradk.. To do BOTH is shooting one's self in the foot. THus,
there is no way to do a clean transistion. Thus there is no way other than
to move to a different forequency cold turkey and get on with it. I AGREE,
If I was a programmer and didnt care about existing users, then OPENtrack
would be 'ABSOLUTELLY the easy way to go.
>What about the users? Well, they get to keep using
>APRS.
And on their own channel without HAVING to upgrade just to protect
themseleves from OPENTRACK..
>Those who want the 'users' to see their data, will keep
>transmitting APRS information as long as the APRS
>audience can only be reached by transmitting APRS data.
Ah so now we double the load on the APRS channel by transmitting BOTH open
track and APRS! Wow, now that will do great things for an already
saturated channel..!
>The experiments will continue to happen, and if there
>is a leason to be learned, I'm sure it will be learned.
>But, who will learn which leason is left to the future...
Good, when you learn all those lessons and will no longer crash or
interfere with existing users, come let us know. Then we will see if we
are ready to throw away all our kenwoods, our trackers, our Mic-E's and out
KPC-3 trackers... and invite you onto the APRS channel.
In the meantime, do not interferer with an existing net with a known and
published protocol, and with known problems with non-compatible packets..
thankl you very much...
Bob
----------------------------------------------------------------------
Subject: APRS upgrades to accomodate OPENtrack
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 22:03:53 -0400
X-Message-Number: 126
>>>"Gregg G. Wonderly" <gregg@skymaster.cytetech.com> 6/6/04 5:31:14 PM
>>>
>We have determined standards for other TNC
>configuration options... [so] it is possible to fix this
>[APRS incompatibility] issue [with OPENtrack]
>in the vast majority of operating TNCs.
There you have it folks, So that OPENtrack can operate on the APRS channel
(where it was told it would cause problems), ALL APRS authors must release
new code, to configure ALL of the identified versions of TNC's and all
existing users must upgrade.
OK fine. As soon as we get this done we will let you know. Until then,
honor the existing users of APRS by not transmitting BINARY on the APRS
channel...
thanks for the simple solution..
I see! Now it is not that OPENtrack is incompatible with APRS, it is that
APRS is incompatible wiith OPENtrack so ALL of APRS on the APRS channel
must upgrade to new code to properly confirute their TNC's to allow
OPENtrack to take their frequency...
Wow, things happen quickly here...
Bob
----------------------------------------------------------------------
Subject: RE: APRS extensibility and OPENtrack
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 22:42:23 -0400
X-Message-Number: 127
>>>"Scott Miller" <scott@3xf.com> 6/6/04 7:21:25 PM >>>
>It [OPENtrack] is a DIFFERENT PROTOCOL. It's playing by
>the rules, and making it very clear that it's not APRS,
Then what is it doing on the National APRS channel we worked so hard to
build?
>to avoid causing undesired operation in devices
>that don't support it.
We told you it would cause problems for us, and it seems unfair for you to
then insist that we all must quit using APRS or write new APRS code so that
it wont be harmed by OPENtrack on the APRS channel...
>Auser-defined message type WOULD NOT BE
>DECODED EITHER. Would you consider
>that making an effort to make it non-decodable?
I see no reason to make either of them non decodable. If you want to use
the APRS channel so that you can contribute to the APRS net in progress,
then transmit APRS. If you do'nt want to do APRS on the national APRS
channel, it just seems prudent to go chose another frequency where you will
do no harm...
>>I agree! If it is a position report, put it in the original APRS
>>format so that all the net users benefit! That is the purpose
>And here we go on this circular argument again...
>Everyone here is sick of it, and I'm tired of typing the
>same things over and over.
If it is position data, put it on APRS so others can see it. If you need
centimeter accuracty, the other APRS users cannot use that and so put that
fine-resolution part of the data in an APRS custom user format. But put
the 1 foot accuracy PORTION of it in standard APRS format so that existing
users can still participate and see you...
I just dont see any reason to invent a new and not backwards compatible
OPENtrack position formats when you already complain of the 5 that APRS
supports.
I DO AGREE WITH YOU 100% that APRS needs a better TELEMETRY format. And I
would WELCOMEE that as a user defined pacekt on APRS. that everyone could
upgrade to... Please do it...
But please keep your position data compatible with what already exists. I
think that would be a WIN WIN for both of us..
Bob
----------------------------------------------------------------------
Subject: Re: DX spots on APRS!
From: Steve Dimse <k4hg@tapr.org>
Date: Sun, 6 Jun 2004 22:48:26 -0400
X-Message-Number: 128
On 6/6/04 at 9:19 PM Jeff King <jeff@aerodata.net> sent:
>You want to see me on a map, type my call into aprsworld. I don't transmit
>enough on 144.39 for FINDU to typically hold it, + no gateways near me, and
>more often then not, I am just puttering around.
You are right, findU does not hold positions for at least 18 months as APRS
world does, the last time wb8wka was heard there was January 11, 2003!
findU does, however, hold positions for 120 days, raw packets for 70 days,
and
weather since April 2001. There are no packets, other than the obsolete,
unregistered version of WinAPRS (2.51) that just fired up on TCP as
wb8wka-1...but that must be someone impersonating you...surely an
enlightened soul such as yourself would not use WinAPRS!
True enough, you do live in an APRS hole, but there is activity within 30
miles of you in nearly every direction, I find it hard to believe you
haven't driven 30 miles in the last 4 months.
http://www.findu.com/cgi-bin/plot.cgi?call=wb8wka-1,*
Don't blame findU or the APRS network...you simply find more pleasure in
attacking the APRS establishment than in using APRS. You shouldn't be
ashamed of that, my life would be boring without you to spar with!
Steve K4HG
----------------------------------------------------------------------
Subject: RE: Introducing "OPENAPRS"
From: Steve Dimse <k4hg@tapr.org>
Date: Sun, 6 Jun 2004 22:50:05 -0400
X-Message-Number: 129
On 6/6/04 at 9:39 PM Robert Bruninga <bruninga@usna.edu> sent:
>>We've talked about an APRS 2.0 spec many times,
>>and Bob shoots it down for the same reasons he does
>>OpenTRAC.
>
>Yes, becasue no one has showed us what they think
>APRS 2.0 is, nor how it would be backwards compatible
>to existing users...
Please, include my name in the gunnery crew. I'm proud of the fact that I
shoot down things which make programmers' lives easy at the expense of
users!
Steve K4HG
----------------------------------------------------------------------
Subject: RE: OPENtrack DIGIpeater Objects
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 22:44:31 -0400
X-Message-Number: 130
Scott,
I think we agree completely on the DIGI-OBJECT thing lets stop arguing and
get on with it. I showed how your suggestion fits perfectly in APRS as you
suggested It makes a great addition to APRS. Ill add it to the errata page
as soon as you are happy with the final version.... thanks Bob
----------------------------------------------------------------------
Subject: Re: OPENtrack Binary Versus ASCII
From: Wes Johnston <wes@johnston.net>
Date: Sun, 06 Jun 2004 22:53:13 -0400
X-Message-Number: 131
Bob, PSK31 is incompatible with SSTV. A closer analogy is that scott
invented a way to encode closed captioning in the vertical retrace of FSTV
and your software shows a jittery pic when he sends the closed
captioning. Packet is Packet is Packet.... filter on PID and you have a
solution. Filter on TOCALL and you have a solution.
CW is not the same as SSB... that is mixed mode just as in your example of
PSK31 and SSTV.
NOW.... if i started sending PSK31 or Q15X25 on the ax.25 channel APRS
uses, that would be mixing modes and would generally be a Bad Thing.
Bob, I am really disappointed... you are .... for lack of a better
term.... race baiting. You have created a line in the sand between the
programmers and the users that does not need to be there. You are running
in circles screaming that the sky is falling when indeed it is not.
Wes
----------------------------------------------------------------------
Subject: RE: DIGIpeater OBJECTS
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 22:58:32 -0400
X-Message-Number: 132
>>>"Scott Miller" <scott@3xf.com> 6/6/04 7:42:38 PM >>>
>I wasn't asking for a digipeater implementation.
Now I am totally confused. I thought the whole idea was for the digi
(which can hear everything and is the only station that KNOWS when the
channel is clear) to transmit the object more efficiently. because it
solves the hidden transmitere problem. If you arent goint to put it at the
digi, then it doesn seem like it would work...
>You said that it could all be done with currently-defined
>message formats, specifically the objectexpiration flag.
No, nothing to do with messages. The originator simply transmits the
"cache request" using the existing APRS object format, only use your idea
of the special TOCALL which is where we put the "cache request" info so
that nothign else has to change.
>I liked your suggestion of using the TOCALL. I proposed
>the format OBJxyz where "x" tells it how many hours to
>keep it up, and "y" provides the fudamental rep-rate
>in minutes.
>Isn't that an ALTNET?
Yes, because the only station that has to hear the cache request is the
digi... so nothing is lost, and also then no existing code is impacted in
anyway..
>As long as you keep it an APxxxx call, it can still
>be picked up by a dumb digipeater and no one needs
>to worry about the fact that a cache request was made.
Yes, on the output of the digi, the digi version of the object would now
use the common APxxxx TOCALL. Or maybe even better to have the digi
retransmit it now using APOBJ so that it is obvious to all observers that
it is a DIGI object now...
>A separate TOCALL would be used on the
>digipeater side to indicate that the object had been
>cached, and the time remaining till expiration.
Ah, I see. that last phrase was missing in my version. OK, lets make the
DIGI vesion use APOBJx where "x" is the hours remaining...
Wow, sounds gerat to me!
I like it.
Bob
----------------------------------------------------------------------
Subject: APRS Users beware (part 1)
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 23:01:07 -0400
X-Message-Number: 133
Again, a PERFECT discussion of the difference to the END USER: Users
please read...
>>>Henk de Groot <henk.de.groot@hetnet.nl> 6/6/04 10:23:33 AM >>>
>The difference in a nutshell is unification, structure
>and well defined backward compatibility after whatever
>extension of the protocol.
Yes, for programmers only. And note the key word "after", which means you
only get this AFTER all 20,000 existing users are obsoleted and ALL have
thrown away their Kenwoods, trackers, and HAMhuds and started all over with
this new "better" protocol for programmers... Then and only then do you
get this improved "backwards" compatiblity and then only backwards to
previous copies of only OPENtrack...
>This is one of the major problems since from a user
>point of view there is at first glance no *functional*
>difference. The key is the way it is done, where the
>structured approach of OpenTrack will allow much cleaner
>implementations.
For programmers, not end users. But it does require TOTAL OBSOLESCENCE of
all EXISTING APRS users, hardware and applications to get to this
programmers paradise...
>For the end-user this means less bugs in their programs
>and the ability to get smaller and more feature-rich devices.
Typical programmer hype. If you believe that new code will be any more bug
free than it has for the last 50 years, you are dreaming...
>If you read the SIG longer then you will have read that
>both APRSdos as PocketAPRS have reached their
>memory limit. When APRS would have been more
>structured both programs would be smaller and would
>accommodate more features.
Still no one has shown me ANYTHING that APRSdos cannot convey from one user
to another user on a local RF network within its existing protocol.
>The approach of APRS has been - in my view - a
>process where new features are added in an ad-hoc
>manner.
Yep, it grew over 12 years and added everything everyone asked for that was
reasonable for its mission.
>Take for example the way a position is reported. So now
>we have 5 formats all doing the same thing. Each APRS
>client has to implement 5 decoding routines to get a position.
The poor programmer. And so now he wants to add a 6th. OK, name one that
the END users want to give up:
1) NMEA, how many people want their GPS/TNC combos
instantly obsolete by OPENtrack?
2) How many Mic-E ownwers wnat to see thier products
instanlty obsolete with OPENtrack?
3) How many Kenwood users want to see their packets
instantly obsoleted with OPENtrack
4) How many AMSAT users want to see thier digipeated
grid-square packets via the ISS and SAREX instantly
obsolete?
5) How many APRS users of existing software wan to
see their standard APRS format obsolete.
THe answer is NONE. And SCOTT fully knows this, thus he has said he will
continue to support all of these existing formats! So then where is this
grand-unification theory? Its all HYPE. In fact, he just wants to add his
OWN SIXTH format. Now his OPENtrrack porgrammers have to support 6.
There is no advantage even to PROGRAMMERS, unless you ABANDON and instantly
OBSOLETE all existing users, applicaitons, hardware and firmware.
>But it is a waste of code space and also error prone
>since 5 algorithms need to be implemented and
>tested where it could have been just one.
I hope USERS are paying attention! You see, they MUST obsolete all
existing APRS in order to have any advantage even for programmers!
>The OpenTrack specification only has one way to
>report a position and by using a binary format it is
>both small and very accurate. A client now needs
>to have only one parser and the code-space freed
>can be utilized for other features, or one can choose
>to squeeze the client into a smaller box.
Notice, these are all advantages to programmers, and ONLY if all else is
abandoned. In other words, there is only one way to do it, and it is THEIR
way. ALL existing users be damned...
>The same story applies to WX data where APRS also
>has a whole load of formats.
Absolutely WRONG. There is only one format in the APRS spec! and one
(non-recommended variant).
>The praised Kenwoods only has a small subset
>implemented because of this...
Pure propaganda.
The KENWOODs followed the spec and only implemented the ONE REAL APRS WX
format. The reason it is not decoding any of the other formats is because
NONE Of them are APRS formats! Thus APRS tried to do exactly what
OPENtrack wants. One STANDARD extensible WX format to which you can add
any new fields you want kust by adding a format identifier character in
front ot it.
>... in a similar OpenTrack device there would have
>been only one format and you would have had a fully
>compliant device instead of a small subset.
See, the OPENtrack advertisers don't even understand the fundamental APRS
WX format. 1) it is only one format (with a WinAPRS corrolary), and 2) it
is fully extensible for any new parameters that might come along.
>APRS is not designed for extension, no matter what
>story Bob tries to pull over your eyes.
So send me what you want to add for the END USER, and Ill help show you how
to do it...
End of part 1
Bob
----------------------------------------------------------------------
Subject: APRS user beware part 2
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 23:03:00 -0400
X-Message-Number: 134
The second half of my response to Henk on why this is not good for the
existing user base:
>>>Henk de Groot <henk.de.groot@hetnet.nl> 6/6/04 10:23:33 AM >>>
>In the early days it was reasonably straight forward to
>add things to APRS but all the later enhancements were
>kludges. It started with MIC-E, which abused the
>destination call to convey data.
Most people (except for pureist progrmmers) WELCOMED that format since it
SAVED 7 bytes in every packet by taking advantage of 7 wasted bytes already
required to be in every packet. Everyone won....
>But also strange enhancements like the /A altitude flag
Which HUMANS can read. /A=011345 which means 11345 feet, and everyone
could use it instantly and did not have to have the latest download to view
it. Remember, with OPENtrack, ANYTHING that gets added will require NEW
display code since it is all binary and not HUMAN readable and must be
converted form the OPENtrack format to HUMAN format at the end...
>and even more such things that get added to the
>comment field. It is human readable but so free-format
>that it is hard to parse in a client.
Clinets dont have to parse it. The END USER IS A HUMAN who is supposed to
READ it. Again, watch out for programmers how forget who the end user
is...
>Some programmers chose do not waste time on the
>complex APRS parser... because their implementation
>breaks down at the next addition or it crashes on mal-
>formed packets (and their cheap response it to blame
>the new format instead of their own code).
Yep, no one said it was easy for the programmer. But the end user is still
the HUMAN who has to read the data on a screen...
>In my vision APRS is a prototype and proof of concept.
>Now that we know what it takes to make a good APRS
>system, OpenTrack is the technical solution to get a sound
>interface specification taking all the lessons learned into
>account. So we go from a hacked-together prototype to
>an model that applies sound engineering principles.
>Nothing strange with this, it happens in the industry all
>the time.
Users, I hope you are still with us here. Again, read between the lines.
The above propaganda means plain and simple that it must ABANDON completely
100% of all existing APRS in order to get to this programmer's heaven...
the 20,000 existing users be damned...
>This new protocol is engineered such way that it can
>co-exist with the current APRS infrastructure.
Sure, so can SSTV and PSK-31, They both use radios, and can both listen
before transmitting to avoid collisions but the SSTV users cannot ever see
what the PSK-31 users are doing nor can the PSK-31 users ever decode the
SSTV. So no one in their right mind would every insist that they share the
same frequency!
>The current infrastructure has little problems with
>OpenTrack and nothing that can't be fixed.
Its not the infrastructure that uses APRS, it is the END USER. All the
OPENtrack programmers are tyring to do is to usurp the frequency, take it
over, so that they can OBSOLETE all existing APRS completely. because then
and ONLY then, do any of the propaganda advantages even to programmers of
OPENtrack have any value...
>...The only difference this time is that Bob didn't invent it.
Nope, Scott did. But Bob is still trying to allow APRS users to continue
operations without forced obsolescence by programmers...
>The next step will be migration. First you will see
>dual-mode clients that know both about APRS and
>OpenTrack.
Ah, note, that ADDING ALL EXISTING APRS functionality to OPENTRACK for
"migration" purposes... 100% completely obviates any advantages to either
programmers or to users...
>Besides that small trackers and devices will appear that
>only use OpenTrack to take advantage of the better
>structure.
(for programmers). Notice they will be totally incompatible with all
existing users, and all existing users trackers will be OBSOLETE to
OPENtrack...
>I guess over the years more and more traffic will move
>to OpenTrack and a client builder that is forced to make
>a choice what formats too keep will opt more and more
>to kick out less-used APRS hacks first.
Yep, no problem with that. But let the USERS VOTE with their VFO's. Put
OPENtrack on 145.55 or 145.01 and let them come. But dont stick a knife in
the throat of all existing users forcing their obsolescence by programmers
with their own agenda...
>Meanwhile the struggle between APRS and OpenTrack
>will go on as long as Bob is still convinced he has room
>to add more kluges and exotic extensions to APRS,
>despite that his own program ran out of space long time ago to
>implement it all.
Pure misstruths. Show me one thing in APRSpec that APRSdos cannot do? Also
show me one thing you want to add for the END user that I cannot already to
in the existing protocol or cannot add if it is worth it.
>There is still an evolutionary path; that is to start with
>APRS SPEC 2.0 and kick out all the obsolete formats,
>for example:
How many NEMA trackers, or Mic-E's or Kenwoods are ready to chuck their
existing equipment for the benefit of Opentrack programmers?
>But still, the room for improvement within APRS is
>limited. For example the implementation of symbols is
>too simple and doesn't provide space for a lot
>of symbols that some real-life applications need.
APRS can support over 350 different symbols. How many more do you need? I
have responed to every reasonable request and added anyting that made
sense... And there is still plenty of room.
>Symbols in APRS are a scarce resource, but
>despite that even here you find redundancy, for
>example there are 2 ways to make a circled number...
Yes, the old way (1994) and the new way (after 1995) But only the new way
is recommended for transmission so that the OLD way still reserves us TEN
spare symbols that can be ANYTHING for future use.
>I think APRS should be left what it is today and focus
>should be on the next generation format, which will
>open a host of new applications and possibility that
>can never be squeezed efficiently into APRS anymore.
I agree completely. Just do it on a different NET than the APRS net, and
dont wreck existing users, who just might not want to be forced to abandon
their existing hardware for the sake of programmers nervanna.
Bob, Wb4APR
----------------------------------------------------------------------
Subject: Re: New APRS Digi-Object-Maintenance format
From: Greg Kulosa <greg@kulosa.org>
Date: Sun, 6 Jun 2004 20:05:58 -0700
X-Message-Number: 135
[BTW, I am not one of the Open-tracker people. I just consider this an
interesting technical discussion, that I think could help with channel
loading].
>Then it is of little value to a REAL-TIME TACTICAL
>event. Especially in the presence of a collision. Just
>one collision and the NEW location of a moved
>object would not be updated in 2 hours!!!????
Ahh, but we are not talking about using this for moving objects. We have
only talked about _VERY_ static objects.
>>Also, the TOCALL of 'OBJxyz' is an altnet, isn't it?
>
>Yes, since it is a directive to only the digi, then only
>the digi has to receive it...
Makes sense.
>> For some objects you might care, since the TOCALL
>>is used to set the icon (GPSxy, etc.)
>
>Never. GPSxyz is only used for raw NMEA packets.
>It would never apply to an object.
Oh, sorry. I missed that.
>>Also, if I transmit my request with WIDE2-2, and 4 Digi's
>>hear it and then start re-transmitting my objects, it will
>>actually create MORE traffic than if I just sent them myself.
>
>That is why there must be the restriction for it to only
>have been heaerd direct and to only put it out direct.
What about a way to request a specific Digi to cache the packet?
And not necessarily a Digi that can hear you direct.
>>You basically want the objects to travel the same number
>>of hops that they would if you had broadcast them yourself.
>
>Absolutley not. The whole advantage was that they are
>ORIGINATED by the DIGI and the DIGI knows when the
>channel is clear. As soon as you let a DIGI start HOPING
>the object through other digis, you are BACK TO SQUARE
>ONE and have lost all the advantages that Scott
>proposed...
But then doesn't the 2nd digi also know when the channel is clear,
since it has the same advantage as the first (Altitude)? That's
what makes it a WIDE Digi, right? Or did I miss something?
Scott, what do you think about this? Should the Digi transmit
only DIRECT, or with a path?
Greg Kulosa
N1NSY
----------------------------------------------------------------------
Subject: DIGI-OBJECT-MAINTENANCE format
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 23:10:47 -0400
X-Message-Number: 136
>>>"Scott Miller" <scott@3xf.com> 6/6/04 7:48:30 PM >>>
>This is my main objection to what I've proposed in the
>digi object caching scheme. It eliminates the
>manufacturer ID which is such a usefull place to put
>such information without affecting the packet payload.
>
>The problem is, there's just the one slot.
I assumed the DIGI has no problem like KISS and can change the TOCALL
instantaneously on the fly. WHen it ID's itself, it uses its own software
TOCALL ID. When it originates an OBJECT that it has cached for someone
else, it uses the APOBJx TOCALL...
>now you've got to make a choice between mutually exclusive
>features. Such is the nature of APRS.
Not at all. Nothign limiting about APRS at all! Every single packet the
DIGI digipeats uses a different TOCALL. It is just as trivial for it to
insert APOBJx for cached Objects and APDIGI whatever when it sends its own
ID packet...
>I'm all for teaching an old dog new tricks, but you
>reach a point of diminishing returns.
I dont understand what is missing here..
Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
