| |
ZL3AI > APRDIG 12.06.04 23:41l 764 Lines 30920 Bytes #999 (0) @ WW
BID : 3433-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 06, 1/9
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040612/1900Z @:ZL3VML.#80.NZL.OC #:25694 [Chch-NZ] FBB7.00i $:3433-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Sunday, June 06, 2004.
1. RE: OPENtrack verus APRS format example
2. Re: The OpenTrac Debate and BS!
3. Re: The OpenTrac Debate and BS!
4. RE: How about making OpenTrak part of APRS SPEC?
5. RE: New APRS Digi-Object-Maintenance format
6. Re: The OpenTrac Debate and BS!
7. RE: New APRS Digi-Object-Maintenance format
8. RE: How about making OpenTrak part of APRS SPEC?
9. RE: How about making OpenTrak part of APRS SPEC?
10. Battery questions
11. High speed APRS link
12. Re: Health reports using APRS
13. Re: The OpenTrac Debate and BS!
14. New National OPENtrack freq
15. Re: The OpenTrac Debate and BS!
16. Sounds like Programmers Convenience to me....
17. RE: New APRS Digi-Object-Maintenance format
18. RE: How about making OpenTrak part of APRS SPEC?
19. Re: Battery questions
20. Re: New National OPENtrack freq (How pathetic)
21. Re: 30 Meter Policing needed.
22. Re: New National OPENtrack freq (How pathetic)
23. The NEXT Greatest thing to APRS!
24. Re: Solar tetroon Sky Diamond - signal loss????
25. Re: Battery questions
26. Re: OPENtrack incompatibilities
27. APRS in the field. Big step forward...
28. Re: The OpenTrac Debate and BS!
29. Re: OPENtrack incompatibilities
30. Re: The OpenTrac Debate and BS!
31. RE: updating databases over aprs?
32. Re: APRS in the field. Big step forward...
33. Re: The OpenTrac Debate and BS!
34. Re: APRS in the field. Big step forward...
35. Looking for a few NC APRS Users...
36. Kenwood and KISS mode
37. Re: The OpenTrac Debate and BS!
38. Re: The NEXT Greatest thing to APRS!
39. OPENtrack Binary Versus ASCII
40. Re: The OpenTrac Debate and BS!
41. Re: 30 Meter Policing needed.
42. RE: New National OPENtrack freq
43. RE: Sounds like Programmers Convenience to me....
44. RE: How about making OpenTrak part of APRS SPEC?
45. Re: APRS in the field. Big step forward...
46. OPENtrack for programmers, APRS for users
47. Re: OPENtrack Binary Versus ASCII
48. RE: The NEXT Greatest thing to APRS!
49. RE: How about making OpenTrak part of APRS SPEC?
50. Introducing "OPENAPRS"
51. Re: 30 Meter Policing needed.
52. Re: OPENtrack Binary Versus ASCII
53. Re: The OpenTrac Debate and BS!
54. Re: OPENtrack Binary Versus ASCII
55. Re: OPENtrack for programmers, APRS for users
56. RE: OPENtrack for programmers, APRS for users
57. RE: Introducing "OPENAPRS"
58. Re: Introducing "OPENAPRS"
59. RE: The NEXT Greatest thing to APRS!
60. RE: OPENtrack for programmers, APRS for users
61. Re: New APRS Digi-Object-Maintenance format
62. RE: NEW TOPIC!
63. B2V path
64. RE: OPENtrack for programmers, APRS for users
65. Re: Sounds like Programmers Convenience to me....
66. Re: [ Robert Bruninga ] Re: OPENtrack incompatibilities
67. Re: APRS in the field. Big step forward...
68. DX spots on APRS!
69. help with oncore gps
70. KISS mode is not always the answer !
71. Re: [ Robert Bruninga ] OPENtrack for programmers, APRS for users
72. APRS extensibility and OPENtrack
73. DIGI-Object-Maintenance
74. Re: DX spots on APRS!
75. Re: OPENtrack incompatibilities
76. RE: OPENtrack DIGIpeater Objects
77. RE: DIGIpeater OBJECTS
78. Re: OPENtrack incompatibilities
79. Re: DX spots on APRS!
80. Re: KISS mode is not always the answer !
81. Re: DX spots on APRS!
82. RE: KISS mode is not always the answer !
83. RE: KISS mode is not always the answer !
84. RE: APRS extensibility and OPENtrack
85. RE: OPENtrack DIGIpeater Objects
86. RE: DIGIpeater OBJECTS
87. Re: DX spots on APRS!
88. Re: The OpenTrac Debate and BS!
89. Re: APRS in the field. Big step forward...
90. Re: DX spots on APRS!
91. RE: OPENtrack DIGIpeater Objects
92. RE: KISS mode is not always the answer !
93. Re: The OpenTrac Debate and BS!
94. Re: APRS in the field. Big step forward...
95. Re: The OpenTrac Debate and BS!
96. Re: DX spots on APRS!
97. Re: The OpenTrac Debate and BS!
98. RE: How about making OpenTrak part of APRS SPEC?
99. Re: APRS in the field. Big step forward...
100. Re: APRS in the field. Big step forward...
101. Re: OPENtrack for programmers, APRS for users
102. RE: The NEXT Greatest thing to APRS!
103. Re: OPENtrack Binary Versus ASCII
104. RE: How about making OpenTrak part of APRS SPEC?
105. RE: How about making OpenTrak part of APRS SPEC?
106. Re: Introducing "OPENAPRS"
107. RE: KISS mode is not always the answer !
108. Re: OPENtrack Binary Versus ASCII
109. Re: DX spots on APRS!
110. Re: OPENtrack Binary Versus ASCII
111. Re: OPENtrack for programmers, APRS for users
112. Re: OPENtrack Binary Versus ASCII
113. Re: DX spots on APRS!
114. RE: OPENtrack for programmers, APRS for users
115. RE: Introducing "OPENAPRS"
116. RE: How about making OpenTrak part of APRS SPEC?
117. Re: OPENtrack Binary Versus ASCII
118. Re: New APRS Digi-Object-Maintenance format
119. RE: The NEXT Greatest thing to APRS!
120. RE: How about making OpenTrak part of APRS SPEC?
121. Re: DX spots on APRS!
122. Re: DX spots on APRS!
123. Re: OPENtrack Binary Versus ASCII
124. Re: APRS in the field. Big step forward...
125. Re: [ Robert Bruninga ] OPENtrack for programmers, APRS for users
126. APRS upgrades to accomodate OPENtrack
127. RE: APRS extensibility and OPENtrack
128. Re: DX spots on APRS!
129. RE: Introducing "OPENAPRS"
130. RE: OPENtrack DIGIpeater Objects
131. Re: OPENtrack Binary Versus ASCII
132. RE: DIGIpeater OBJECTS
133. APRS Users beware (part 1)
134. APRS user beware part 2
135. Re: New APRS Digi-Object-Maintenance format
136. DIGI-OBJECT-MAINTENANCE format
137. Re: [ Robert Bruninga ] APRS upgrades to accomodate OPENtrack
138. RE: APRS extensibility and OPENtrack
139. Re: B2V path
140. Re: DX spots on APRS!
141. RE: The NEXT Greatest thing to APRS!
142. RE: DIGIpeater OBJECTS
143. Re: [ Robert Bruninga ] Re: [ Robert Bruninga ] OPENtrack for
programmers, APRS for users
144. Re: [ Robert Bruninga ] OPENtrack for programmers, APRS for users
145. Re: DX spots on APRS!
146. RE: DIGI-OBJECT-MAINTENANCE format
147. Re: APRS Users beware (part 1)
----------------------------------------------------------------------
Subject: RE: OPENtrack verus APRS format example
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sat, 05 Jun 2004 19:57:08 +0200
X-Message-Number: 1
At 00:21 5-6-2004 -0600, Bill Herrmann wrote:
>Note: If you don't want to read the technical stuff skip to the next to
>the last paragraph.
>
>At 06:13 PM 6/4/2004 -0700, Scott Miller wrote:
>>In hex:
>>
>>0C 10 18 DC 17 7B AA 5D 7A D6 0F 89 BC 05 11 3E 38 3E 6E 05
>>34 D8 19 0D 15 07 16 E6 96 87 E5 AD 97 04 13 9C 04 57 83 05
>>00 0C 84 05 03 00 F0 04 12 41 42 43 03 14 00 0D
>
>Ok, so why not tunnel that through APRS by adding the "user-defined data
>format" header from page 87 of the APRS Specification? (page 97 of 128 in
>the PDF)
Best case you would only get:
0C 10 18 DC 17 7B AA 5D 7A D6 0F 89 BC 05 11 3E 38 3E 6E 05
34 D8 19 0D
And loose the rest since in the APRS ASCII format 0D is a line terminator.
The rest:
15 07 16 E6 96 87 E5 AD 97 04 13 9C 04 57 83 05
00 0C 84 05 03 00 F0 04 12 41 42 43 03 14 00 0D
would be interpreted as a new APRS packet, needless to say that all those
APRS programs processing ASCII and with apperently minimal checking will
not be happy with this...
Extending APRS with a space-efficient flexible binary protocol like
OpenTrack is at most only possible in theory but most certainly not
possible with the current way APRS is applied in practice.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: The OpenTrac Debate and BS!
From: "Scott Miller" <scott@3xf.com>
Date: Sat, 5 Jun 2004 20:49:13 -0700
X-Message-Number: 2
>accurate and OT is simpler to implement code-wise, then why not support
>authors implementing the OT code in their own program and start a transition
>over to a better code (I think Bob said that it had 20-20 hindsight). We
Doing that now, or trying. There's example code out there that Xastir has
already assimilated, and on the Windows side I've developed an ActiveX
control that does all of the heavy lifting, makes it very easy to add
support to existing programs, and lets you update the entire parser by
changing one file when updates are made.
I'm hoping someone with more Unix coding experience can come forward and put
together an API that'll make it as easy to integrate on non-Windows
platforms. But since Windows is by far the most popular platform, and
Curt's got Xastir covered already, I'm focusing on the ActiveX decoder as
the preferred way to push adoption. An encoder is in the works, too.
I wrote a test program in Visual Basic to try out the decoder, and it takes
about three lines of code to set it up and parse a position.
>AND, with hind sight being 20-20, I won't buy the next Kenwood APRS radio or
>any other APRS radio in the future that won't support flash upgrades to
>update it to the current spec.
Let's hope the manufacturers get the message and start getting with the
program. Even better, let's convince a manufacturer to provide an interface
API with full access to the user interface and back-end features of the
radio and we can make the radios do what we want.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: The OpenTrac Debate and BS!
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Sat, 05 Jun 2004 23:02:46 -0500
X-Message-Number: 3
>I'm hoping someone with more Unix coding experience can come forward and put
>together an API that'll make it as easy to integrate on non-Windows
>platforms. But since Windows is by far the most popular platform, and
>Curt's got Xastir covered already, I'm focusing on the ActiveX decoder as
>the preferred way to push adoption. An encoder is in the works, too.
>
>I wrote a test program in Visual Basic to try out the decoder, and it takes
>about three lines of code to set it up and parse a position.
Quite some time ago, I created a parser in Java as well, and it is available
to anyone who wants it. With Java, I took advantage of dynamic code loading
so that you could use anyones parser for any element by just including it in
your classpath in the appropriate place/way. This makes it trivial to extend
a Java based OpenTrac system as new elements are defined. With a registry on
the web somewhere, jar files could be provided in one place to help make it
really easy.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: Gerry Creager N5JXS <gerry.creager@tamu.edu>
Date: Sat, 05 Jun 2004 23:21:26 -0500
X-Message-Number: 4
Actually, Layers 6-7 with the occasional thought of wandering down to 2
and 3. But Layer 3 is poorly implemented and mostly ad hoc -- but NOT
ad hoc in the more recent sense used in wireless networks today.
Let's get our reference layers right.
The radios and copper reside at layer 1
TNCs reside at Layer 2, as do the digipeaters for most actions
Source routing and the WIDEn-n construct are exceptions
WIDEn-n allows further propagation and is a quasi-layer 3 function
really happening at layer 2
javAPRS and APRSd are essentially at Layer 4.
The various clients are at Layers 5-7 to varying degrees.
The spec talks to all of these without bothering to mention the OSI
reference model...
Neil Johnson wrote:
>(I know I'm going to regret responding to you Jeff, but here it goes).
>
>Unfortunately APRS straddles both Layer 2 (Data Link) and Layer 3 (Network) of
>the standard network model. In a perfect world there would be separation of
>two, but that is the legacy of APRS.
>
>In fact, the reason the APRS protocol is the way it is is because Bob was
>making it COMPATIBLE with the AX.25 network protocols.
Now I'm really confused.
>Imagine were APRS would be today if Bob had used a completely different packet
>format, and told us all that we would have to "fix" (buy) completely
>different hardware in order to run APRS. It would have died on the vine.
>
>By making APRS so it could run on EXISTING packet technology WITHOUT causing
>problems is an important reason why APRS is where it is today.
No... APRS was adapted to the packet hardware that was available. I'm
just glad we didn't end up specifying Vancouver modems.
>As for the frequency thing. I seem to remember that we grudgingly but
>appropriately moved our frequency to 144.39 after complaints from satelite
>users about us INTERFERING with their operations.
Only partially correct.
deletia...
--
Gerry Creager -- gerry.creager@tamu.edu
Network Engineering -- 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: New APRS Digi-Object-Maintenance format
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Sun, 6 Jun 2004 00:47:26 -0400
X-Message-Number: 5
Yeah... What happens when one of these digis start sending out 20 or so
objects using WIDE5-5? Which unproto path will be used?
73s,
Eric KF4OTN
kf4otn@amsat.org
-----Original Message-----
From: Robert Bruninga [mailto:bruninga@usna.edu]
>>>"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: The OpenTrac Debate and BS!
From: "DG2JW" <dg2jw@privateasylum.com>
Date: Sun, 6 Jun 2004 07:50:06 +0300
X-Message-Number: 6
Hello again everyone.
I just thought about getting comments to this idea.
Regarding manufacturers, I am sure that in the current typical Japanese
business model, it is not their position to open hardware or firmware up
to end users or partners. I know this from doing many projects with Sony
professional, Panasonic, Kenwood and others on the broadcast side. With
that in mind I offer this idea which is a bit off topic from our current
Open Trac discussion but makes a valid point.
Why not a Linux or Windows Mobile based pocketpc/ipaq with GPS, radio
and TNC built into an expansion pac? The idea of using a pocketpc/ipaq
would give freedom to the individual to choose which client application
he runs on his packet enabled handy, or if it runs APRS at all. It could
be an OT enabled device. The point being, give the community a choice. I
really like my D7, except that I cant change it or enhance it to meet my
needs and requirements. Using a pocketpc/ipaq as the user interface for
what ever generic hardware platform I choose to use, gives me the power
to make up my own mind. Does it mean I may have to build my own client
apps? Sure, but then again having the freedom to write or choose my own
software for generic hardware means no one will be a slave to Kenwood
any longer. It also means that Kenwood, which has no reason to better
its products (because of a lack of competition), would be forced to add
more value to its D7/D700 line in order to stay competitive and
attractive to the ham radio community.
Its not really just about APRS or Open Trac. Its also about giving hams
the freedoms to experiment and having "good generic" platforms on which
to do it. There will always be a place for legacy systems. However those
systems should not get in the way of innovative new ideas which empower
hams to drive technology forward.
Best regards
Julian
OH8GEJ
----- Original Message -----
From: "Scott Miller" <scott@3xf.com>
----snip----
>Let's hope the manufacturers get the message and start getting with the
>program. Even better, let's convince a manufacturer to provide an interface
>API with full access to the user interface and back-end features of the
>radio and we can make the radios do what we want.
>
>Scott
>N1VG
----------------------------------------------------------------------
Subject: RE: New APRS Digi-Object-Maintenance format
From: "Scott Miller" <scott@3xf.com>
Date: Sat, 5 Jun 2004 22:09:10 -0700
X-Message-Number: 7
>Yeah... What happens when one of these digis start sending out 20 or so
>objects using WIDE5-5? Which unproto path will be used?
The digis should be sending cached objects with the same path they'd be
sending if the originating station was still sending them normally. If
they're sending WIDE5-5, it's because the station was set to WIDE5-5,
hopefully for a good reason. You could probably impose a limit on cached
objects, though.
It might also be a good idea to have digis clear their cache if they hear
that another digi's already picked it up and cached it. Then again, if it's
only sent with a single WIDE and you've got digis on opposite sides of a
valley, it'd probably be good to have both of them cache it.
The digis should have a certain amount of flexibility in honoring the
intervals to support aggregation of multiple packets. And with a little
more work, you could probably have adjacent digis listen to each other and
work out compatible timeslots for their aggregated transmissions.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: Bill Herrmann <bherrman@spro.net>
Date: Sat, 05 Jun 2004 23:47:09 -0600
X-Message-Number: 8
At 11:26 PM 6/5/2004 -0400, Jeff King wrote:
>OpenTrak does conform to the APRS spec, in that it should be treated as a
>alien format (non 0xF0 PID), and discarded.
Actually, that is not what the APRS spec says. (at least I sure haven't
been able to find it)
The spec says that APRS uses a PID of 0xF0. Nowhere does it say anything
about the use other than to say that it uses that PID.
However, it also says: (on page 89)
Packets that do not meet any of the formats described in this document are
assumed to be non-APRS beacons. Programs can decide to handle these, or
ignore them, but they must be able to process them without ill effects.
I've not seen any definitive comment on whether any transmitted OpenTrac
packet started out like a valid APRS packet. However, a high percentage of
them should have fallen in the category of ignore, but that ignore is based
on the identifier byte not the PID. (The quoted section above is very
clearly referring to the identifier byte and other pieces that distinguish
APRS packets if you read it in context.)
Bill
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: "Scott Miller" <scott@3xf.com>
Date: Sat, 5 Jun 2004 23:14:09 -0700
X-Message-Number: 9
>I've not seen any definitive comment on whether any transmitted OpenTrac
>packet started out like a valid APRS packet. However, a high percentage of
They shouldn't start out that way. Even if they did disregard leading
'garbage' bytes, a parser should still never get a complete and valid
decode.
I've been looking over the HamHUD II code - the only parser known to have
failed, aside from the closed-source FindU parser - and I've found at least
one candidate bug so far. And it's not a binary-handling bug. While
parsing the source and destination calls, it stores them in a 10-character
buffer. It stops when it finds a '>' character or fills up all 10 bytes.
Trouble is, it then adds a terminating null on the end, so if you've gone 10
bytes without a '>', you've just written a zero God-knows-where in memory.
This could easily happen if a carriage return byte in the middle of an
OpenTRAC packet made the parser think a new packet had started.
It's a simple off-by-one error that's common and easy to do in C. I can't
say for sure that this is the particular bug that caused the lockup, but
it's at least illustrative of the kind of thing we're looking for. It's not
a binary-related bug, and it's not a PID-decoding bug. The code makes an
attempt to validate what it's getting, but it's subtly flawed in how it does
it.
There's an old saying in the field - if architects built buildings the way
programmers write programs, the first woodpecker that came along would
destroy civilization. Bugs happen... you find them, fix them, and move on,
and your code's that much better for the effort.
I've posted the details to the HamHUD list, and I'll be doing some more
review of the code as I get a chance.
Scott
N1VG
----------------------------------------------------------------------
Subject: Battery questions
From: "Scott Miller" <scott@3xf.com>
Date: Sat, 5 Jun 2004 23:35:18 -0700
X-Message-Number: 10
Got a couple of battery questions... with all this discussion of smarter
digis, I dug up my single-board digi_ned system to start messing with it
again. Step one was building a power cable to adapt it to APP connectors,
of course. =] Then I started looking at the battery situation.
Anyway, I've got a ton of questionable UPS batteries around here (12 V, 7.5
AH VRLA) constantly, and I've got two chargers. One's a smart
charger/conditioner/maintainer with whiz-bang anti-sulfation features and
such. But it refuses to do anything with a battery at less than 10.5 volts
charge, so to get 'em started I've got the dumb 2-amp auto/marine deep cycle
charger.
Earlier today I checked on a battery connected to the dumb charger, and
found it hot to the touch. I disconnected it of course, and now several
hours later it's still warm. I can't imagine it's just held that heat this
long. It's still registering around 10 volts.
Is this a sign of a shorted cell? The battery's toast in any case, I've
just never seen one do this.
Next question... the setup I'm using for my weather station test setup uses
a couple of these 7.5 AH batteries. The batteries (as with the rest of my
big deep cycle batteries) have a 50-amp Anderson single pole connector.
Another single pole connector splits it out to 30-amp power poles. One goes
to the load and one goes to a 5-watt solar panel with an internal blocking
diode.
I seem to remember hearing that this setup is allowable for panel sizes up
to 10 watts or so. Is that correct? Does it start boiling off electrolyte
after that?
Just for fun, I've now got the digipeater computer running off the big (84
AH) battery, and a 5-watt panel. Not that that's going to help much, with
the computer drawing up to 10 watts. Now, I've seen suggestions before on
commercial solar charge controllers, but does anyone have a recommendation
for a dual-mode charger? I'd like to set the thing to work off both a wall
wart transformer and a solar panel.
Scott
N1VG
----------------------------------------------------------------------
Subject: High speed APRS link
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sun, 6 Jun 2004 18:17:49 +1000
X-Message-Number: 11
Hi,
Has anyone hooked up a GPS to one of these RF modules ? RS232 in, RF OUT
vice versa
I think they are 2.4 GHz ?
Would make for and interesting LIVE gps link for only a short distance
Andrew VK4TEC
----------------------------------------------------------------------
Subject: Re: Health reports using APRS
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 07:26:28 -0400
X-Message-Number: 12
Actually, in re-reading this, I think the health data would
best go in the STATUS packet of a station. Bob
----------------------------------------------------------------------
Subject: Re: The OpenTrac Debate and BS!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 07:52:46 -0400
X-Message-Number: 13
>>>Danny <danny@messano.net> 6/5/04 10:40:04 PM >>>
>There are flaws in the APRS system.
I wouldn't call them flaws, but hindsight. Of course, things can be put
together more streamlined with a total re-invention of the wheel, but why?
When it would sacrifice all existing users? If you think there are
insurmountable flaws, please list them so we can see what you are talking
about?
>Much of it could be improved with an APRS Spec 2.0.
Like what? And what would be the disadvantage of obsoleting 20,000 users.
Probably 10,000 of which have hardware THAT WOULD NOT WORK ANY LONGER?
APRS is not for basement couch potatos to just command a global map. Its
for people to get off their duff, get out into their local community and DO
something.
Couch potato's can upgrade their latest software toy in about 1 minute. The
rest of the APRS network and most of those that actually do something with
it cannot "change" without ABANDONING what they have worked so hard to
build and going out and buying new toys.
They are the silent majority.
Newcommers who just want to add new bells and whistles without having to
study the spec and figure out how to add the bells and whistles within the
existing FULLY EXTENSIBLE structure are the ones that are willing to
sacrifice the majority who are doing just fine with a working system for
the sake of the basement couch potatos with an attention span of about a
day...
>Perhaps it would be incompatible with APRS 1.0.
>Perhaps authors would have to do some rewrites for 2.0.
And all 10,000 owners of Kenwoods and HAMhuds and all the owners of
existing trackers would have to start over...
That is the purpose of the APRS-WG, to make sure that things continue to
work and that any thing that is new that cannot be done within the existing
strcuture is added to the spec. So far, nothing we have seen cannot
already be done within the flexibility already built into the existing
spec.
Bob
----------------------------------------------------------------------
Subject: New National OPENtrack freq
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 08:17:28 -0400
X-Message-Number: 14
A good idea to allow OPENtrak to grow unimpeded by concerns for backwards
compatibility and the needs of existing users would be to find a national
OPENtrak frequency. I suggest 145.55 MHz
This is one of the best kept secrets that I have been holding in reserve in
case APRS ever needed a second frequency. But it looks like now that time
has come.
This frequecny is probably clear in almost all areas in the USA. because
it WAS the NATIONAL SPACE packet frequency reserved for the Shuttle, MIR
and Space Station.
But in response to the INTERNATIONAL move of the new space station to
145.800 globally, the original NATIONAL APRS frequency had to move from
145.79 to 144.39. This left 145.55 (a single Nationally Cleared frequency)
quietly empty. I have always kept my eye on this frequency as an alternate
for APRS.
Now maybe it is time to explore using this frequency if available locally
to see if it can be used as an OPENtrack experimental frequency... This
would allow it to grow unfettered by existing users, legacy systems, and
any need for backwards compatibility.
Check your area. Use it for OPENtrack if you can.
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: The OpenTrac Debate and BS!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 08:29:26 -0400
X-Message-Number: 15
>>>"Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU> 6/5/04 11:29:31 PM
>>>
>We keep worrying about backwards compatibility
>when it really shouldn't be an issue. The most popular
>"brands" of software are typically being updated quite
>frequently (Xastir and UI-View) and it shouldn't take
>long before most users to be compatible.
Wow, At any APRS real-event in the field wher it was designed to serve a
real mission, 90 to 95% of ALL assets are not SOFTARE but hardware. You
can fill a tent with OPENtrack users and flashy PC's playing with
themselves, but there is nothing to do. They dont provide the service APRS
was designed to do...
>As for the D700s/D7s, these units were flawed from
>the day they hit the shelves and continue to be a thorn
>in the sides of designers and code writers today.
Why, because they are too lazy to read the APRS spec and see how to
communicate with them? Again, all these points you are making are the
propoaganda you have been fed by programmers who simply are not interested
in figuring out how to make things work, but just want an easy way to write
more and more incompatible code to do what can already be done...
Wow, see if the remainder of this fits YOUR vision of APRS. It surely
doesnt fit mine:!!! It fits the descritption of I only want APRS for*me*.
Not someone who goes out into his community and tries to use APRS to help
serve their communications needs.
>I don't know who uses these units to monitor the area
>traffic, but I find it quite useless to "see" who is around
>me. I DO use mine to send and receive messages
>and to act as a tracker. If I can't decode an OT tracker
>next to me because the Kenwood won't do it, so be it!
>I'll hook up a laptop to it and run a software decoder to
>"see" it. AND, with hind sight being 20-20, I won't buy
>the next Kenwood APRS radio or any other APRS
>radio in the future that won't support flash upgrades to
>update it to the current spec.
Duh... The kenwoods ARE compatible with the current spec!
>Now, I CHALLENGE all the APRS brains out there to
>think twice before sending another piece of crap to the
>SIG. I would love to have the five or ten
I wont even bother with the rest of this useless propaganda... Just think.
Is this guy who you want on your next public service event? Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
