| |
ZL3AI > APRDIG 13.06.04 10:19l 809 Lines 30175 Bytes #999 (0) @ WW
BID : 3445-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 07, 1/7
Path: DB0FHN<DB0FOR<DB0MRW<DB0WUE<DK0WUE<HA3PG<HA8FY<HG8LXL<VK4TTT<VK7AX<
ZL2BAU<ZL3VML
Sent: 040613/0512Z @:ZL3VML.#80.NZL.OC #:25746 [Chch-NZ] FBB7.00i $:3445-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Monday, June 07, 2004.
1. Re: OPENtrack Binary Versus ASCII
2. Re: APRS user beware part 2
3. Re: APRS user beware part 2
4. RE: KISS mode is not always the answer !
5. Re: APRS upgrades to accomodate OPENtrack
6. Re: KISS mode is not always the answer !
7. Re: APRS in the field. Big step forward...
8. Re: KISS mode is not always the answer !
9. RE: Bob Versus Scott
10. Re: New APRS Digi-Object-Maintenance format
11. Re: New APRS Digi-Object-Maintenance format
12. BINARY OPENtrack on APRS
13. RE: APRS user beware part 2
14. RE: APRS extensibility and OPENtrack
15. Re: OPENtrack Binary Versus ASCII
16. RE: DIGIpeater OBJECTS
17. APRS Users beware #3
18. Re: APRS user beware part 2
19. Re: [ Robert Bruninga ] OPENtrack for programmers, APRS for users
20. RE: DIGI-OBJECT-MAINTENANCE format
21. Re: The OpenTrac Debate and BS!
22. RE: KISS mode is not always the answer !
23. Re: B2V path
24. RE: DIGI-OBJECT-MAINTENANCE format
25. Re: APRS user beware part 2
26. RE: The NEXT Greatest thing to APRS!
27. RE: APRS extensibility and OPENtrack
28. Re: New APRS Digi-Object-Maintenance format
29. Re: New APRS Digi-Object-Maintenance format
30. RE: New APRS Digi-Object-Maintenance format
31. APRSdos 3D projections of Altitude
32. RE: APRSdos 3D projections of Altitude
33. Re: BINARY OPENtrack on APRS
34. RE: KISS mode is not always the answer !
35. RE: KISS mode is not always the answer !
36. Re: APRS Users beware (part 1)
37. New worldwide maps available for FindU
38. My summary
39. Re: New worldwide maps available for FindU
40. Re: [ Robert Bruninga ] Re: APRS user beware part 2
41. Voice Alert on 144.390 / 100 Hz
42. Re: Voice Alert on 144.390 / 100 Hz
43. RE: APRS extensibility and OPENtrack
44. Re: BINARY OPENtrack on APRS
45. Re: New APRS Digi-Object-Maintenance format
46. RE: New APRS Digi-Object-Maintenance format
47. RE: APRS extensibility and OPENtrack
48. Re: APRS user beware part 2
49. Re: BINARY OPENtrack on APRS
50. Re: OPENtrak incompatibilites not needed.
51. Re: Too many personalities
52. Re: OPENtrak incompatibilites not needed.
53. RE: The NEXT Greatest thing to APRS!
54. Re: New worldwide maps available for FindU
55. USB TNC challenge
56. Re: New worldwide maps available for FindU
57. Re: Voice Alert on 144.390 / 100 Hz
58. USB TNC challenge
59. Re: [bob_vs_scott_sig]
60. RE: Introducing "OPENAPRS"
61. Re: Voice Alert on 144.390 / 100 Hz
62. Re: New APRS Digi-Object-Maintenance format
63. RE: New APRS Digi-Object-Maintenance format
64. Re: APRS user beware part 2
65. Re: OPENtrak incompatibilites not needed.
66. Re: [bob_vs_scott_sig]
67. RE: The NEXT Greatest thing to APRS!
68. Re: Voice Alert on 144.390 / 100 Hz
69. RE: Introducing "OPENAPRS"
70. Kenwood APRS radio...
71. Re: APRS user beware part 2
72. Re: USB TNC challenge
73. RE: Kenwood APRS radio...
74. Re: Kenwood and KISS mode
75. RE: APRS extensibility and OPENtrack
76. Re: USB TNC challenge
77. Re: Kenwood APRS radio...
78. APRS Touchtone Wow
79. Re: USB TNC challenge
80. Re: Kenwood APRS radio...
81. Re: APRS user beware part 2
82. Re: APRS user beware part 2
83. Re: USB TNC challenge
84. RE: Introducing "OPENAPRS"
85. APRS Protocol - A Modest Proposal
86. Re: Kenwood APRS radio...
87. RE: The NEXT Greatest thing to APRS!
88. Re: Kenwood APRS radio...
89. Re: Kenwood APRS radio...
90. Re: OPENtrak incompatibilites not needed.
91. APRSttone calls
92. Re: APRS Protocol - A Modest Proposal
93. RE: Introducing "OPENAPRS"
94. Re: APRS user beware part 2
95. Re: APRS Protocol - A Modest Proposal
96. Re: New worldwide maps available for FindU
97. Re: Kenwood APRS radio...
98. Re: Kenwood APRS radio...
99. Re: APRS Protocol - A Modest Proposal
100. Re: APRS user beware part 2
101. Re: APRS Protocol - A Modest Proposal
102. RE: How about making OpenTrak part of APRS SPEC?
103. Re: APRS Protocol - A Modest Proposal
104. Re: APRS user beware part 2
105. RE: Introducing "OPENAPRS"
106. Re: APRS Protocol - A Modest Proposal
107. APRS OBJECT Caching (Rev 1)
108. Re: APRS user beware part 2
109. Re: APRS OBJECT Caching (Rev 1)
110. Re: APRS OBJECT Caching (Rev 1)
111. Re: '...I'll just take my ball and go home!"
112. Re: APRS Protocol - A Modest Proposal
113. Re: APRS Protocol - A Modest Proposal
114. NBAA Intl Ops, Region I: North America > Expect GPS Outages in Canada June
2004
115. RE: How about making OpenTrak part of APRS SPEC?
116. RE: Introducing "OPENAPRS"
117. Re: Kenwood APRS radio...
118. Arizona's upcoming Disaster Drill
119. Re: APRS OBJECT Caching (Rev 1)
120. RE: Introducing "OPENAPRS"
121. Re: APRS Protocol - A Modest Proposal
122. Re: APRS Protocol - A Modest Proposal
123. RE: Introducing "OPENAPRS"
124. PID 77 in AX.25 spec?
125. RE: APRS Touchtone Wow
126. RE: APRS Touchtone Wow
127. Thoughts on a proposed replacement for D700
128. RE: APRS Touchtone Wow
129. Ref: Expect GPS Outages in Canada
130. RE: APRS Touchtone Wow
131. RE: Thoughts on a proposed replacement for D700
132. RE: APRS Touchtone Wow
133. Re: APRS user beware part 2
134. RE: Thoughts on a proposed replacement for D700
135. RE: Thoughts on a proposed replacement for D700
136. Re: APRS user beware part 2
----------------------------------------------------------------------
Subject: Re: OPENtrack Binary Versus ASCII
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 21:06:35 -0400
X-Message-Number: 1
>>>Jeff King <jeff@aerodata.net> 6/6/04 2:27:25 PM >>>
>>Programmers whining again.
>
>The ITU differs with you.
>1.56 amateur service: A radiocommunication service
>for the purpose of self-training, intercommunication and
>technical investigations carried out by amateurs,...
Absolutely, But that doesnt mean that you can start investigating PSK-31
in the middle of an SSTV net, or experimenting with CW on an SSB net, or
OPENtrack BINARY protocols on an existing APRS net which has a clearly
stated purpose, a clearly stated protocol, and a clear mission.
I have nothing aginast OPENtrack, I just oppose it on the APRS channel.
Dual systems have never worked in the past in HAM radio and there is
nothing that indicates it will work here... AS WE HAVE CLEARLY SEEN...
BOb
----------------------------------------------------------------------
Subject: Re: APRS user beware part 2
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Sun, 06 Jun 2004 22:59:21 -0500
X-Message-Number: 2
The obsolecence of any equipment only happens if people have a better
choice. Whether or not OpenTrac ever gains enough ground to provide a
differentiating user base, I can still use my THD7A. I can even use the
APRS on any applicable frequency where packet radio is supported with the
PID of F0 dedicated to APRS traffic.
My radio keeps on working and I can keep using it...
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: APRS user beware part 2
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Sun, 06 Jun 2004 22:55:21 -0500
X-Message-Number: 3
>>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...
Element #18 is a freeform comment element. If you want someone to read
something, you can send this element and it will be readable for all users.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: RE: KISS mode is not always the answer !
From: Sean Jewett <sean@rimboy.com>
Date: Sun, 6 Jun 2004 22:33:29 -0500 (CDT)
X-Message-Number: 4
On Sun, 6 Jun 2004, AE5PL Lists wrote:
>If you use aprsd, you could use the Linux ax25 kernel support which
>allows multiple applications to share the same TNC running in KISS mode.
>javAPRSIGate makes use of this so people can use much more powerful digi
>software such as Digi_Ned. There are versions of aprsd that make use of
>the Linux ax25 kernel support, as well.
>
>So yes, KISS is an option and a powerful one, at that.
Aside from what I've found here:
http://www.febo.com/packet/linux-ax25/index.html
does anyone have any other good places to find configuration info on how
to get AX25 up and running, better yet, talking to everything (and not
from linuxdoc)? I've found it to be quite a pain to get up and running In
fact, when I last played with it I never had any luck getting it running.
I agree that it's a good option but given the hoops it seems to be a
little less confusing to run aprsd w/ a TNC connected to the serial port.
Sean...
--
The punk rock will get you if the government don't get you first.
--Old 97's
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
KG4NRC http://www.rimboy.com Your source for the crap you know you need.
----------------------------------------------------------------------
Subject: Re: APRS upgrades to accomodate OPENtrack
From: "Kurt A. Freiberger" <kurt@badgers-hill.net>
Date: Sun, 06 Jun 2004 23:08:06 -0500
X-Message-Number: 5
Robert Bruninga wrote:
>>>>"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...
So, code that doesn't bother to screen its input and protect itself should
be allowed to continue with impunity? It strikes me that it's a rather
large flaw where someone that sends binary can seriously disrupt a whole
system. Better that the writers bullet-proof their code rather than using
security by obscurity. Even the mighty Micro$loth has awakened to that
fact, although they won't admit it. It's an old Net axiom that says, "Be
liberal in what you accept, conservative in what you send". OT has simply
shown up a rather large unzipped fly, or Achilles Heel, for those of a
Classical bent. Good thing I'm not an Evil Terrorist bent on disabling the
World Wide APRS Network! Muah ha ha.
Surely there is a way to identify a signature so that a proper filer could
be devised and emplaced.
This binary in an "ASCII environment" is an old chestnut. When I was
running IP, I was told that certain channels were ASCII only, because my
goldarned TCP/IP stuff was messing up their screens. Then there was those
"Donald Duck" guys messing up my AM bands.... And, lest we forget, "What's
all this brapping ony MY direct frequency?"
Lastly, enough with the electronic testosterone emissions. My MTA has had
enough.
No thirty.
>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...
--
Kurt Freiberger, WB5BBW kurt@badgers-hill.net Austin, TX
----------------------------------------------------------------------
Subject: Re: KISS mode is not always the answer !
From: Sean Jewett <sean@rimboy.com>
Date: Sun, 6 Jun 2004 22:36:49 -0500 (CDT)
X-Message-Number: 6
On Sun, 6 Jun 2004, Earl Needham wrote:
> It's a GREAT option, IF you try UI-View32. Does IGATE and
>digipeating (WIDEn-N, TRACEn-N, RELAY, whatever you like) wonderfully, with
>the TNC in KISS mode.
Does UIView run on Linux? Some of us really don't want to run Windows
unless we have to. It's not necessary to run Windows to play APRS. And I
would not say the problems Neil outlined are best resolved by running
Windows.
>From what I've seen UIView is a great program. aprsd, digi-ned, and
xastir are all more than capable clients under linux though.
Sean...
--
The punk rock will get you if the government don't get you first.
--Old 97's
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
KG4NRC http://www.rimboy.com Your source for the crap you know you need.
----------------------------------------------------------------------
Subject: Re: APRS in the field. Big step forward...
From: John Hall <n5jrh@houstonhams.org>
Date: Sun, 06 Jun 2004 23:13:46 -0500
X-Message-Number: 7
As a Kenwood D700 user, I am all in favor of OpenTrac.
John
At 06:59 PM 6/6/2004, you wrote:
>>>>"Spider" <spider@rivcom.net> 6/6/04 12:19:12 PM >>>
>>Bob, your consistent defense of the Kenwoods is
>>simply amazing! I really do use APRS in the field and
>>have yet needed a Kenwood to do it, and I find
>>them to be outdated and very limited.
>
>Then why are 90+ % of ALL Mobiles and portables
>using them?
>
>I only defend them becasue APRS users have them.
>
>I see no reason to stop supporting them or their users
>just because some programmers want to add a few
>tweaks to the protocol which they could EQUALLY
>well do in a manner that would not obsolete the
>kenwoods...
>
>>I'd really like to know because it's so obvious to me
>>that these Kenwoods are a major factor in stopping
>>forward movement of the State of the Art..
>
>Programmer propaganda. How is a kenwood
>stopping you from doing what you want? If you dont
>want to use a kenwood, dont use it. But dont set
>out to purposefully OSOLETE those users just because
>you dont personally use them...
>
>Bob
----------------------------------------------------------------------
Subject: Re: KISS mode is not always the answer !
From: Earl Needham <needhame1@plateautel.net>
Date: Sun, 06 Jun 2004 22:19:03 -0700
X-Message-Number: 8
At 08:36 PM 6/6/2004, Sean Jewett wrote:
>On Sun, 6 Jun 2004, Earl Needham wrote:
>
>> It's a GREAT option, IF you try UI-View32. Does IGATE and
>>digipeating (WIDEn-N, TRACEn-N, RELAY, whatever you like) wonderfully,
>with
>>the TNC in KISS mode.
>
>Does UIView run on Linux? Some of us really don't want to run Windows
>unless we have to. It's not necessary to run Windows to play APRS. And I
>would not say the problems Neil outlined are best resolved by running
>Windows.
I don't recall the original message mentioning any aversion to Windows,
simply that he couldn't run his TNC in KISS mode. I outlined one way to do
this, others have posted methods to use KISS in Linux.
7 3
Earl
Earl Needham, KD5XB, Clovis, New Mexico DM84jk
SETI@Home: 11589WU/7.52yrs
----------------------------------------------------------------------
Subject: RE: Bob Versus Scott
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 21:21:41 -0700
X-Message-Number: 9
Thanks, Bob. I have great respect for you and what you've accomplished. I
think we're just going to have to agree to disagree on certain subjects,
corny as that sounds.
Scott
N1VG
-----Original Message-----
From: Robert Bruninga [mailto:bruninga@usna.edu]
Scott,
By the way, Scott. After 24 hours of this debate I admire your strength
and your ability to keep above the fray...! I do not mean to attack you
personally either in any way.. You do great work. Just wish I could get
more out of you in the compatiblity with existing users area...
And I also don't mean any of my comments about programmers to be taken
personally. They are like lawyers... great targets, but essential to keep
around.
Didnt mean to use the "duh" in the last email... But its been a long
day.... Forgive me if I slip up occasionally on the interpersonal skills a
bit...
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: New APRS Digi-Object-Maintenance format
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 00:33:47 -0400
X-Message-Number: 10
>>>Greg Kulosa <greg@kulosa.org> 6/6/04 11:05:58 PM >>>
>Ahh, but we are not talking about using this for moving
>objects. We have only talked about _VERY_ static objects.
If I drive into your area during a situation and am looking for the EOC
which is only being transmitted once an hour, I probably will never see it
in the time frame that I need it. APRS is a real time system. If the
information' is of value, then it must be transmitted often enough to serve
someone who just turned on his radio or drove into the area, or just got
into his car.
If it is of so little significance that no one needs to know it within a
time frame of 2 hours or more of being ON the air, then I wonder what its
value is to a tactical realt time network? Seems useless. Or it should
just be integraated into the maps...
Bob
----------------------------------------------------------------------
Subject: Re: New APRS Digi-Object-Maintenance format
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 21:35:52 -0700
X-Message-Number: 11
>Scott, what do you think about this? Should the Digi transmit
>only DIRECT, or with a path?
I think it should transmit with the path it was given. Just like it
actually received the packet in real time, direct.
As far as non-direct digis caching it in the first place - I'm not sure.
Probably not a good idea. And besides, if the digi's sending out the
newly-cached packet with the tocall indicating that it's been cached, other
digis shouldn't cache it anyway.
Also, the nearest caching digi might be a hop or two away, but if your path
got it there through non-caching digis, it'd still have the cache request
attached since it hasn't already been cached. On the other hand, it'd have
to cache it using the reduced, partly-exhausted path or risk propagating the
cached packet on to even more remote digis.
To illustrate, let's say you send out a WIDE3-3 packet. Two hops away, it
gets cached with one hop to go. If the digi sends the cached packet with
one hop, it'll never reach back to your local area, and the originating
client will have to beacon as usual, also reaching the caching digi and
generating no reduction in total traffic. If it sends it out with the
original WIDE3-3, it'll reach beyond its intended area, possibly reaching
more caching digis that will in turn pass it on further.
So... it'd seem to me that restricting the caching to direct-only digis
would make the most sense.
Scott
N1VG
----------------------------------------------------------------------
Subject: BINARY OPENtrack on APRS
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 00:40:58 -0400
X-Message-Number: 12
>>>gregg@skymaster.cytetech.com 6/6/04 11:11:51 PM >>>
>You didn't jump up and down and tell all the
>IGATES to stop sending packets until everyone
>of them had a fix for MIC-E decoding did you?
No, because Mic-E is part of APRS, its in the spec, and if code was choking
on it, then that code needed to be fixed right away...
>It did cause a lot of discussion and a lot of people
>had to do a lot of investigation and work to get rid of
>that issue.
You bet! So why in the world would we invite that on ourselves by orders
of magnitude because we want to allow OPENtrack to throw BINARY at us that
as you know, can contain just about ANY possible character in just about
any possible position in the packet. SOme of these CAN be interpreted as
perfeclty VALID APRS packets. This risk destroys the integrity of APRS as
a communications system.
Im not talking about GARBAGE positions, I'm talling about binary data that
CAN perfectlyl match an APRS format and be totally witihin all context
checkers and still not even be APRS though it will produce a perfectly
VALID but WRONG interpretation...
BINARY simply CANNOT exist without problems on a channel that was not
designed for it... any programmer surely must agree with that...
Bob,. WB4APR
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: RE: APRS user beware part 2
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 21:44:24 -0700
X-Message-Number: 13
>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
I've said it before, but I think this point bears repeating. If you've got
a national frequency allocation available, APRS would benefit FAR more by
establishing an alternate input frequency. Pick a digi that hears several
weather stations directly. Add a 145.55 receiver, and QSY the weather
stations. The digi can then retransmit the packets as soon as the primary
channel is clear.
It's something that can be instituted with existing hardware, on a
site-by-site basis, and works directly to improve the situation on 144.39.
Doing this on one busy digipeater would probably give you a greater
reduction in channel usage than eliminating all the OpenTRAC packets that
currently traverse the system on a day-to-day basis.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: APRS extensibility and OPENtrack
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 00:52:09 -0400
X-Message-Number: 14
>>>"Scott Miller" <scott@3xf.com> 6/6/04 11:17:05 PM >>>
>>We told you it would cause problems for us, and it seems
>>unfair for you to then insist that we all must ... write new
>>APRS code so that it wont be harmed by OPENtrack
>
>Bob, you're grossly exaggerating the situation...
>To suggest that I'm insisting APRS must be...changed
>to coexist is absurd. NO APRS code need be changed
>at all - it's a simple TNCconfiguration change
>to ensure complete immunity to cross-protocol interference.
Ah, now exactly how does every one of the 20,000 APRS users do that? The
only way I know of that it can be done reliably enough is to RE-ISSUE every
existing copy of APRS client software so that it now INCLUDES the proper
TNC set-up routines to avoid this OPENtrack problem.
Sure, its a trivial change, but it must be made by every-single copy of
APRS that is running in order to reliably fix the problem. Again, seems
unfair...
Bob
----------------------------------------------------------------------
Subject: Re: OPENtrack Binary Versus ASCII
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 21:59:15 -0700
X-Message-Number: 15
>Hence there will never be a full, dual compatible
>program. Hence the only way for OPENtrack to
>succeed is to totally abandon APRS users, trackers
That's quite a leap in logic. Xastir is already on its way to dual-protocol
support. I don't think anyone so far has suggested writing an OpenTRAC-only
client from scratch. We're simply adding to what's already been written.
Adding new features to Xastir doesn't require removing those that are
already there.
>having to upgrade every single piece of existing
>sofware so that is can tell the TNC to ignore
>all but PID F0 even if they could...
Well, just to nitpick, AGWTracker for one shouldn't need any sort of update.
I don't think it has any converse-mode support. And we've already been over
the fact that in most cases it's a simple config file change. And of
course, there's the fact that only the HamHUD has been shown to have a
problem with inadvertent OpenTRAC traffic, and we may have fixed that
already.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: DIGIpeater OBJECTS
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 01:08:28 -0400
X-Message-Number: 16
>>>"Scott Miller" <scott@3xf.com> 6/6/04 11:33:51 PM >>>
>Here's how I see it working:
>
>Client transmits a posit/object/whatever to APxxyz
There is the problem. APxxyz is not available since there is a near
infinite number of combinatinos of APxxxx already in use... By switching
to OBJxyz, I avoided all of those problems...
Hold on. If I can just find ONE APx that is still available and can grab
it, then we can do it your way, which ISS better.... ARGH, ALL in use...
Ah HA! Nothing wrong with AP0xyz (That's a ZERO)
OK, that's solved...
>Case 2:
>
>Client transmits a posit/object/whatever to APxxyz
>Caching digi stores packet, digipeats it to APqqyz
Perfect. Yes, the APxxxx uplink and downlink must change, else it is an
infinite loop. Now how much of the XYZ do you need. If we can get by with
just the two bytes, then we can use AP0Rxy for the REQUEST and AP0Cxy for
the cached result. The "x" which was th enumber of hours requested counts
down until it is zero. This way it can be seen as a time remaining.
Looks like i t will work to me!
>Now, I just wish we could get Kantronics to support
>this sort of thing to start making use of all that RAM
>they've got.
Well, at least UIDIGI and DIGI_NED can do it immediately. I STRONGLY
hesitate to suggest putting it end user digiepating code like UIview
because it could EXPLODE on us if users use it wrongly...
Bob
Scott
N1VG
----------------------------------------------------------------------
Subject: APRS Users beware #3
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 01:13:39 -0400
X-Message-Number: 17
>>>gregg@11:33:58 PM >>>
>I'm not going to get emotional about this Bob.
>Its not the APRS channel. It is 144.390mhz.
I defy you to find any recorded frequency coordinator, AMSAT, or the ARRL
or ANY other listing of 144.39 for ANY OTHER purpose than APRS.
Were you here when we had the GREAT QSY? It was a NATIONAL event unheard of
in all of HAM radio history, where ALL bodies, ARRL, AMSAT, and all
freqeuncy coordinators got togehter and all AGREED that 144.39 would be the
North Americal Continent APRS channel.
If you think it is not for just APRS, then I think you should review a
little history...
Bob
----------------------------------------------------------------------
Subject: Re: APRS user beware part 2
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Mon, 7 Jun 2004 01:16:58 -0400
X-Message-Number: 18
>>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...
So, I guess you manually take APRS positions off your telnet screen and plot
them on a paper chart, right?
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] OPENtrack for programmers, APRS for users
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 01:20:41 -0400
X-Message-Number: 19
>>>"Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU> 6/6/04 11:44:22 PM
>>>
>Why is implementing both in the same software
>shooting one's self in the foot??? I don't get it?
Because its entire advantage and the reason all programmers want to do it
is because it is simpler and easier than APRS. (I agree).
But If they also have to do APRSanyway in the same software so as not to
abandon all those existing users, then why do OPENtrack as yet just more
work!
The advantage of OPENTRACK is that it doesnt have to implement the KPC-3
trackers, or the TinyTracks, or the Kenwoods, or the Mic-E's or the GPS or
NMEA trackers. It only has to do one format, the new OPENTRACK format.
But if you have to do them all to be able to still support all of them, you
have gained nothing in the claimed advantages of not having to do any of
them!
Back to ssquare one.
Bob
-----Original Message-----
From: Robert Bruninga [mailto:bruninga@usna.edu]
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.
----------------------------------------------------------------------
Subject: RE: DIGI-OBJECT-MAINTENANCE format
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 01:30:30 -0400
X-Message-Number: 20
>>>"Scott Miller" <scott@3xf.com> 6/6/04 11:46:00 PM >>>
>One further thing I think needs clarification is the
>from-call used. I'd assumed the digi would continue
>transmitting the cached packet using the original
>from-call, not its own - and not using object format.
>Are we on the same page, or did you have something
>else in mind?
Wow, totally different pages,
No an object is just an object, once the digi gets it, it is now the owner.
Thus it transmits it as from itself. Thus no need to preserve the TOCALL
version ID from the original sender. The object now belongs to the digi.
It has to be the identical format or it wont cancel the original sender.
that is how APRS ojects work. Somone takes over an object simply by
transmitting it (exactly the same way). Anyone who sees someone else
sending an identical object stops sending it and lets the other station now
do it.
That is what I meant by its already being in all existing code and needing
no changes to any end user client.
Thus the only thing we needed to add was how to signal the DIGI to tell it
to TAKE OVER. You provided the excellent suggestion to do it via the
TOCALL... and that is perfect, becsue it allows the object so be totally
identical, so that all the existing OBJECT handoff stuff works, without any
changes to any (of the 20,000 existing users)
That's why its so slick. and we can do it only with new code at the digi.
Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
