| |
ZL3AI > APRDIG 11.06.04 11:20l 799 Lines 29266 Bytes #999 (0) @ WW
BID : 3425-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 05, 1/8
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<IK1ZNW<ON0BEL<EB2BJX<GB7YKS<
GB7PZT<GB7PFD<GB7ESX<ZL2BAU<ZL3VML
Sent: 040611/0700Z @:ZL3VML.#80.NZL.OC #:25626 [Chch-NZ] FBB7.00i $:3425-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Saturday, June 05, 2004.
1. Re: Solar tetroon Sky Diamond - signal loss????
2. RE: APRS XML
3. RE: OPENtrack verus APRS format example
4. APRS XML
5. OpenTrak source code
6. Re: Solar tetroon Sky Diamond - signal loss????
7. Re: Solar tetroon Sky Diamond - signal loss????
8. Re: Solar tetroon Sky Diamond - signal loss????
9. Re: Solar tetroon Sky Diamond 6 aloft right now!
10. Re: OPENtrack incompatibilities
11. Re: OPENtrack arrogance
12. commercial
13. Re: Solar tetroon Sky Diamond 6 aloft right now!
14. Re: OPENtrack incompatibilities
15. RE: The new MicroTrak project based on the SMT TinyTrak3!
16. Re: Solar tetroon Sky Diamond - signal loss????
17. Re: Compressed posits with wx data
18. Re: Solar tetroon Sky Diamond - signal loss????
19. RE: OpenTrak source code
20. Re: Solar tetroon Sky Diamond - signal loss????
21. RE: OPENtrack verus APRS format example
22. Wanted: PIC code to gen tones
23. Empirical data on the Kenwood/APRS <> OpenTrak non-issue
24. Re: Empirical data on the Kenwood/APRS <> OpenTrak non-issue
25. Proposed NWS policy change
26. Re: OPENtrack incompatibilities
27. RE: OPENtrack verus APRS format example
28. Re: OPENtrack incompatibilities
29. OPENtrack DIGIpeater Objects
30. Re: OPENtrack incompatibilities
31. Re: Solar tetroon Sky Diamond - signal loss????
32. Re: Solar tetroon Sky Diamond - signal loss????
33. DIGIpeater OBJECTS
34. Re: Solar tetroon Sky Diamond - signal loss????
35. Re: 30 Meter Policing needed.
36. WinAPRS/TNC-X Questions
37. Re: OPENtrack incompatibilities
38. Re: OPENtrack incompatibilities
39. The OpenTrac Debate and BS!
40. RE: commercial
41. Re: WinAPRS/TNC-X Questions
42. Re: Too many personalities
43. RE: OPENtrack verus APRS format example
44. Re: OPENtrack incompatibilities
45. OPENtrak incompatibilites not needed.
46. OPENtrack versus APRS adnausium
47. Re: Too many personalities
48. Re: Solar tetroon Sky Diamond - signal loss????
49. updating databases over aprs?
50. Re: updating databases over aprs?
51. Re: commercial
52. Re: updating databases over aprs?
53. Re: DIGIpeater OBJECTS
54. Re: 30 Meter Policing needed.
55. New APRS Digi-Object-Maintenance format
56. Re: updating databases over aprs?
57. Re: Proposed NWS policy change
58. Re: OPENtrack incompatibilities
59. Re: OPENtrack incompatibilities
60. Re: Solar tetroon Sky Diamond - signal loss????
61. RE: How about making OpenTrak part of APRS SPEC?
62. Re: Solar tetroon Sky Diamond - signal loss????
63. '...I'll just take my ball and go home!"
64. Re: [ Robert Bruninga ] Re: Too many personalities
65. Re: Solar tetroon Sky Diamond - signal loss????
66. Re: OPENtrack incompatibilities
67. Re: OPENtrack incompatibilities
68. Re: OPENtrack incompatibilities
69. Re: [APRS_HF] 30 Meter Policing needed.
70. Re: Solar tetroon Sky Diamond - signal loss????
71. Re: Packet Segregation
72. Re: Solar tetroon Sky Diamond - signal loss????
73. RE: OPENtrack DIGIpeater Objects
74. RE: Digi objects
75. Re: Solar tetroon Sky Diamond - signal loss????
76. RE: DIGIpeater OBJECTS
77. Re: Solar tetroon Sky Diamond - signal loss????
78. RE: OPENtrack verus APRS format example
79. Re: Too many personalities
80. RE: OPENtrak incompatibilites not needed.
81. Re: Empirical data on the Kenwood/APRS <> OpenTrak non-issue
82. Re: Solar tetroon Sky Diamond - signal loss????
83. RE: OPENtrack DIGIpeater Objects
84. Re: Solar tetroon Sky Diamond - signal loss????
85. Re: The OpenTrac Debate and BS!
86. Re: Empirical data on the Kenwood/APRS <> OpenTrak non-issue
87. Re: '...I'll just take my ball and go home!"
88. Re: Wanted: PIC code to gen tones
89. Re: Empirical data on the Kenwood/APRS <> OpenTrak non-issue
90. Re: Wanted: PIC code to gen tones
91. Re: The OpenTrac Debate and BS!
92. Re: Solar tetroon Sky Diamond - signal loss????
93. Health reports using APRS
94. Re: [APRS_HF] 30 Meter Policing needed.
95. Re: 30 Meter Policing needed.
96. NWS for WinAPRS 275 question
97. RE: OPENtrak incompatibilites not needed.
98. Re: 30 Meter Policing needed.
99. Re: Solar tetroon Sky Diamond - signal loss????
100. RE: OPENtrack DIGIpeater Objects
101. Re: Health reports using APRS
102. NEW TOPIC!
103. Re: Solar tetroon Sky Diamond - signal loss????
104. Re: '...I'll just take my ball and go home!"
105. Re: OPENtrack incompatibilities
106. Re: [APRS_HF] Frequency Errors [Was: 30 Meter Policing needed.]
107. RE: OPENtrack DIGIpeater Objects
108. RE: NEW TOPIC!
109. Re: NEW TOPIC!
110. Two more balloon flights
111. Re: Health reports using APRS
112. Re: '...I'll just take my ball and go home!"
113. Re: [APRS_HF] Frequency Errors [Was: 30 Meter Policing needed.]
114. Re: NEW TOPIC!
115. Re: [APRS_HF] Frequency Errors [Was: 30 Meter Policing needed.]
116. Re: Two more balloon flights
117. PK-900 as a digi
118. RE: NWS for WinAPRS 275 question
119. Re: 30 Meter Policing needed.
120. Re: The OpenTrac Debate and BS!
121. Re: Two more balloon flights
122. Re: 30 Meter Policing needed.
123. Re: Two more balloon flights
124. Re: Two more balloon flights
125. Re: Two more balloon flights
126. Re: Wanted: PIC code to gen tones
127. Re: The OpenTrac Debate and BS!
128. Re: The OpenTrac Debate and BS!
129. Re: The OpenTrac Debate and BS!
130. Re: The OpenTrac Debate and BS!
131. Re: The OpenTrac Debate and BS!
132. Re: The OpenTrac Debate and BS!
133. Re: The OpenTrac Debate and BS!
134. Re: The OpenTrac Debate and BS!
135. RE: How about making OpenTrak part of APRS SPEC?
136. Re: [ Danny ] Re: The OpenTrac Debate and BS!
137. Re: OPENtrack incompatibilities
138. RE: NEW TOPIC!
139. RE: How about making OpenTrak part of APRS SPEC?
140. Re: The OpenTrac Debate and BS!
141. Re: [ Neil Johnson ] RE: How about making OpenTrak part of APRS SPEC?
142. Re: OPENtrack incompatibilities
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: Jeff King <jeff@aerodata.net>
Date: Fri, 4 Jun 2004 23:45:37 -0400
X-Message-Number: 1
On Fri, 4 Jun 2004 17:50:28 -0500, Bill Diaz wrote:
>The OpenTrac'rs are demanding that the perpetrators be praised and
>the victims be punished.
Who are the victims? That implies some damage, so please clearly state what
it was.
>They are using a protocol that is not fully defined, and obviously
>never tested in the real world until now. Unfortunately the test
>platform and path they used caused us to be bombarded.
What did you see in your station in Chicago? You might have been able to hear
it when it was over Cleveland at peak altitude.
>So bear with
>them while they re-invent the wheel. Hopefully, they will do this
>on another frequency to minimize the harm to others, but don't count on it.
Clearly state what harm it caused.
Funny thing is, (and I'm not through all the e-mails yet), only two people
have actually reported a problem. Considering the ~400,000 sq miles the test
encompassed, I'd say that is not much.
----------------------------------------------------------------------
Subject: RE: APRS XML
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 21:01:12 -0700
X-Message-Number: 2
This came up back when the project first started. Too verbose. But the
tagged format, in a more efficient binary form, is essentially what we've
got.
I'll be happy to talk with you about this off-SIG - at least, after I've
gotten some sleep. I think everyone here has heard enough for now.
Scott
N1VG
-----Original Message-----
From: Andrew Rich [mailto:vk4tec@hotmail.com]
What about the XML model ?
You send what every packet you want, you tell the other end what sorta
packet it is, and you can add new packets all the time.
<pos>29821738 </pos>
<volts>23</volts>
Andrew Rich (VK4TEC)
www.tech-software.net
vk4tec@hotmail.com
----------------------------------------------------------------------
Subject: RE: OPENtrack verus APRS format example
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sat, 5 Jun 2004 13:55:27 +1000
X-Message-Number: 3
Scott,
Can u send this via the internet ?
I would like to write some perl code to decode it
Andrew Rich (VK4TEC)
www.tech-software.net
vk4tec@hotmail.com
space - electronics - radio - aviation
----- Original Message -----
From: "Scott Miller" <scott@3xf.com>
>Sure, That's easy. Here is the Mic-E version that is not
>only APRS, but is fully Kenwood compatible too:
>'h9"l!8v/]"4%}comment/12v 75F/DOP5/6 sats
>It shows no gobbledygook on the display and shows:
> "comment/ 12v 75F/DOP5/Sats=6"
And none of the stuff embedded in the comment is machine readable.
>Please, Lets see your OPENtrack version.
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
As decoded by listen:
fm N1VG to OPNTRK via WIDE ctl UI^ pid=77(OPENTRAC) len 56
OpenTRAC decode (56 bytes):.
EID 0x10 len 11: Position: Lat 34.959000 Lon -120.424000 Alt 183.000000
meters.
EID 0x11 len 4: Time: Wed Jan 29 12:49:50 2003
EID 0x34 len 4: GPS: 3D Fix Valid SPS, 8 sats HDOP=2.5 PDOP=1.3 VDOP=2.1.
EID 0x16 len 6: Display Name: ??
EID 0x13 len 3: Course: 312 Speed: 79.991997 kph.
EID 0x500 len 1: 12 Volts.
EID 0x503 len 2: 240 Kelvins.
EID 0x12 len 3: Text: ABC.
EID 0x14 len 2: Position +/- 13 meters.
I've stripped the Kanji from this decode, but if anyone cares to see a
screenshot of either a Windows or Linux box decoding it properly, let me
know. I've included a positional ambiguity element for good measure.
It's entirely machine-readable, and the client is free to display the
information in whatever way it wants to.
Yes, you can put human-readable text in the APRS comment field all day long,
but when we're talking about adding meaningful extensions, that only goes so
far.
Notice that APRS has defined methods to present the temperature and voltage
values, but you weren't able to use them here. What about a PHGR extension?
Can a DF bearing go in there too?
Lest someone think that big string of hex means a lot of bandwidth, that's
56 characters, equivalent to this string:
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcd
Yeah, it sacrifices some bandwidth for element tagging, but you've got
position to the centimeter and time to the second, including year, plus all
the extra GPS data. And a Kanji display name.
Scott
N1VG
----------------------------------------------------------------------
Subject: APRS XML
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sat, 5 Jun 2004 13:57:02 +1000
X-Message-Number: 4
What about the XML model ?
You send what every packet you want, you tell the other end what sorta
packet it is, and you can add new packets all the time.
<pos>29821738 </pos>
<volts>23</volts>
Andrew Rich (VK4TEC)
www.tech-software.net
vk4tec@hotmail.com
space - electronics - radio - aviation
----------------------------------------------------------------------
Subject: OpenTrak source code
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sat, 5 Jun 2004 14:08:43 +1000
X-Message-Number: 5
I just downloaded the source code for the opentrak.
I am absolutley confused. It might be open source, but its free
confusion....
When I put together my PIC box, it had one piece of code, with lotsa
comments.
I get into these opentrak files and am totally lost.
Why do you need so many files to do one job ?
You have a chip, and code that goes into it. Simple.
Ideas ? Comments ?
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: Jeff King <jeff@aerodata.net>
Date: Sat, 5 Jun 2004 00:14:35 -0400
X-Message-Number: 6
On Fri, 4 Jun 2004 18:36:31 -0500, hasan schiers wrote:
>At worst this is an attempted hijacking, at best it is a parasitic
>infection. It contributes nothing to the aprs network, it merely
>steals the resources of the infrastructure, for its own self-serving
>ends.
You mean like position location? If it quacks like a duck, looks like a duck,
it might even taste like a duck.
Hasan, clearly and specifically, tell us what problems OpenTrak caused you?
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: Jeff King <jeff@aerodata.net>
Date: Sat, 5 Jun 2004 00:20:51 -0400
X-Message-Number: 7
On Fri, 04 Jun 2004 20:06:54 -0400, Robert Bruninga wrote:
>>>>Jeff King <jeff@aerodata.net> 6/4/04 4:31:04 PM >>>
>>>And why in this gentlemens service called Amateur Radio does
>>>someone think he can transmit packets that are NOT compatible with
>>>the present use of a national channel, and then insist that all
>>>20,000 existing users have to CHANGE their receivers to ignore
>>>him?
>
>>Can you name 3 people that had a problem?
>
>You can do it yourself easily.
So far, I can name two, but of course I was asking you.
I'll take that as a NO.
>Or scan for all kenwoods, That should give you about 3 thousand on
>any given day... is that enough?
Clearly and in detail, please outline the problem those 3000 Kenwoods had so
Scott can check into it. I'm fairly sure this is just more bravado from you,
but I'm willing to give you the benefit of the doubt. Describe the effect it
had on the display for example. If you didn't see it with your own eyes,
please don't pass it third hand. Pass along the call and contact info.
Thanks
-Jeff
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: Sean Jewett <sean@rimboy.com>
Date: Fri, 4 Jun 2004 22:53:21 -0500 (CDT)
X-Message-Number: 8
On Fri, 4 Jun 2004, Scott Miller wrote:
>>>Can you name 3 people that had a problem?
>
>>Or scan for all kenwoods, That should give you
>>about 3 thousand on any given day... is that enough?
>
>Funny that none of those 3,000 that 'had a problem' didn't mention it on the
>SIG.
Could it be that most of the 3,000 are not on this list because of threads
like these? This email list is far from representative of the the APRS
userbase.
Sean...
(Owning 2 D700's that were off during the QRM-fest)
--
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: Solar tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Sat, 5 Jun 2004 00:26:05 -0400
X-Message-Number: 9
On Fri, 04 Jun 2004 20:23:50 -0400, Robert Bruninga wrote:
>>>>Jeff King <jeff@aerodata.net> 6/4/04 4:42:43 PM >>>
>>>The specs say nothing about how a PID is supposed to be monitored
>>>in a TNC.
>>Those nasty web links again:
>>http://www.tapr.org/tapr/html/Faprswg.html Do note the section on
>>page 12 and how it references the AX.25 specification. Ain't
>>committing something to paper, and signing it, a bear?
>
>Yes, too bad you can't seem to understand it. READ THE SPEC and
>read my lips:
>
>>>The specs say nothing about how a PID is supposed to be monitored
>>>in a TNC.
It also doesn't say anything about how you take the data out of the TNC and
make use of it.
What was that term you used..... oh yeah, "common sense".
>What is it exactly that you cant seem to understand?
Why you won't answer the following question:
Again, please tell me exactly the problem you observed with your own eyes, at
your location in the Washington DC area.
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: Jeff King <jeff@aerodata.net>
Date: Sat, 5 Jun 2004 00:34:08 -0400
X-Message-Number: 10
On Fri, 04 Jun 2004 20:36:01 -0400, Robert Bruninga wrote:
>>>>Jeff King <jeff@aerodata.net> 6/4/04 6:13:43 PM >>>
>>Your such a wonderful person to work with Bob.
>
>Thanks, you should really try working *with* me, for once, instead
>of always against me.
Thanks for the offer.
Do note, I am not the author of OpenTrak, but I'm sure Scott would welcome
the same courtesy you are offering me. I myself would like to see it be part
of APRS without all the baggage APRS currently carries. Seems to me it is
quite doable if we can get over the fact the Kenwoods won't display it.
----------------------------------------------------------------------
Subject: Re: OPENtrack arrogance
From: Jeff King <jeff@aerodata.net>
Date: Sat, 5 Jun 2004 00:30:24 -0400
X-Message-Number: 11
On Fri, 04 Jun 2004 20:31:40 -0400, Robert Bruninga wrote:
>>>>Jeff King <jeff@aerodata.net> 6/4/04 6:13:43 PM >>>
>>>1) No it is not. As Jeff clearly points out, the spec says APRS
>>>packets are to be transmitted with the PID of F0.
>>Excuse me? I was saying it shouldn't cause a problem BECAUSE it was
>>compliant with the APRS spec, in that APRS demands a PID of F0,
>>where as OpenTrak uses 77.
>Sorry, thats about as logical as saying that because all CARS are
>required to have wheels, that since your JET FIGHTER doesnt use
>wheels, that it can do anything it wants on the public highways...
Well.... my instructor cut the engine last week, and I was over a public
highway, and he didn't seem to have much of a problem with me lining up for a
landing on it. Granted, a Cessna 172 is a far cry from a Jet, but the point
is the same.
>What arrogance!
Well, he did drill me on wires crossing the road... but I told him I did a
scan for them. Nice thing was, it was in clear farmland, so that was easy to
do..... plus I didn't have renters insurance and landing in the plowed fields
around here would have surely trashed the landing gear.
Fun stuff....
----------------------------------------------------------------------
Subject: commercial
From: Kevin Deckert <kdeckert@telus.net>
Date: Wed, 02 Jun 2004 16:46:00 -0700
X-Message-Number: 12
I am looking for info on APRS in the commercial realm, I have heard that
kenwood and icom have some sort of commercial radios for APRS and some
specializied software..anyone hear of such?
ve7whk, kevin
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Sat, 5 Jun 2004 00:40:02 -0400
X-Message-Number: 13
On Fri, 04 Jun 2004 21:09:45 -0400, Robert Bruninga wrote:
>>>>Jeff King <jeff@aerodata.net> 6/4/04 6:20:11 PM >>>
>>Fact is, it is incompatible.
>>
>>Again, show us your data. The more your weave and jive, the more
>>shallow this whole exercise becomes.
>
>Read the last 200 emails on the APRSSIG and you will get a better
>description than I could ever provide..
I've seen two people step forward with descriptions of problems it caused in
their software. I must have asked 15 people this same direct and pointed
question. I'm sure I'll be asking it a few more times. Amazing what a tribal
knee jerk reaction anything new brings out in people.... reminds me of my
college anthropology class. But I digress....
But I was asking you, what you have seen with your own eyes.
I'll take the twice non-responsive replies as a "NO PROBLEM OBSERVED".
Thanks
-Jeff
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: Jeff King <jeff@aerodata.net>
Date: Sat, 5 Jun 2004 00:41:55 -0400
X-Message-Number: 14
On Fri, 04 Jun 2004 21:30:41 -0400, Robert Bruninga wrote:
>>>>Jeff King <jeff@aerodata.net> 6/4/04 6:40:29 PM >>>
>>>I'm not sure how you can claim "non-interfering" either. Any
>>>packets that are not APRS compatible collide with other legitimate
>>>APRS packets and do not seem to me to be able to claim to be non-
>>>interfering...
>
>>OpenTrak still uses CSMA. Basic layer one stuff Bob, just like
>>APRS. TAB put out a really good book on packet radio...
>
>Ah, so just like on a voice net that is set up for passing NTS
>traffic for example, as soon as you hear the channel go silent for a
>second, you think it is your RIGHT to just bust in and send your DX
>spots?
OpenTrak sends positional reports Bob, in a manner very similar to APRS.
Smells like a duck to me.
----------------------------------------------------------------------
Subject: RE: The new MicroTrak project based on the SMT TinyTrak3!
From: Dale Blanchard <wa7ixk@arrl.net>
Date: Fri, 04 Jun 2004 22:48:13 -0700
X-Message-Number: 15
Scott Miller wrote:
>Curses, he's beat me to it! =] I proposed a similar board a couple of
>months ago... didn't know Byon already had one in the works. Looks like
>he's got my new SMT board (or the first prototype at least) beat by a bit
>for size.
>
>The Microtrak project in the GPS case looks awesome.
>
>I've still got him beat for upgradability and on-board sensors, at least.
>
>Scott
>N1VG
Scotts stuff has a lot of features I would like to use and could have a
lot more in the future. As some areas are already saturated with to much
APRS signals,much of it uneccessary. Why not have a seperate frequency for
Open Track. APRS is a vanity thing anyway. Nobody cars were my house is and
I do not care were thiers is. I only track myself and my wife don't care
where I am at. My sons do use it when we are on a trip or coming to visit
to see were we are on Findu .com. The grand kids get a small charge from
seeing where I am. For a few minutes anyway. I liked Packet when I could
pick my own paths and do keyboard to key board thru someone elses home digi
to some far place until Net Rom screwed every thing up.
Dale WA7IXK
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 22:08:04 -0700
X-Message-Number: 16
>They are using a protocol that is not fully defined, and obviously
>never tested in the real world until now. Unfortunately the test
>platform and path they used caused us to be bombarded.
Robert's not actively involved in OpenTRAC development. I don't mean to put
words in his mouth, but I think operating an OpenTRAC test bed was not a
goal in this launch. He used a tracker of my design that had the option of
using both protocols. When he asked me, months ago, I said that it
shouldn't cause any harm to select the dual-protocol option. The N6CP-11
balloon had already flown with no problems. And the network in this area
frequently sees small amounts of OpenTRAC traffic - it's unfair to say that
it's never been tested in the real world.
There was no conspiracy, and no conscious and coordinated decision to make
this an OpenTRAC test platform. The choice of beacon rate and path were
Robert's, and that's already been covered.
It certainly gave us some interesting results, and points for debate. But I
think this horse is thoroughly dead now.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Compressed posits with wx data
From: Curt Mills <archer@eskimo.com>
Date: Fri, 4 Jun 2004 21:17:50 -0700 (PDT)
X-Message-Number: 17
On Fri, 4 Jun 2004, Matt Werner wrote:
>I've asked this before and I don't think I got anywhere on it so I'll ask
>again.
>
>xastir allows the transmission of compressed posits. When combined with wx
>data, you get a packet like this:
>
>KB0KQA>APX132,WIDE3-2,qAo,W0TVD-10:=/6d9G70,R_{;C216/000g000t061r000P000p000
>b10167XU2k
>
>The problem is that findu nor aprsworld will correctly decode that packet.
>They will both decode the position correctly but will never continue to
>parse to find the trailing wx data. Is the problem in the packet or the
>parsers for each site?
Probably a problem with the parsers. Base-91 position encoding, while it
is in the official ratified APRS spec, has not been very popular. In fact,
if you do the Base-91 encoding for objects and items, Kenwood radios won't
see it, which is why Bob is against compressed objects/items. Compressed
posits are ok though.
Now, some people have implemented partial decoding for compressed mode for
posits, but there's a high likelihood that they don't parse the rest of the
sentence. We ran into the same sort of thing with Firenet when we started
sending objects with weather in them: It was ok per the spec, but nobody
had done it before. It took a while for the software to catch up.
Check the APRS spec very carefully to see if the packet you list above is
valid in all respects. If it's not, let me know what you found out. If it
is, let Steve and Jim know about it and ask them nicely if they will
support it with their parsers.
--
Curt, WE7U. archer at eskimo dot com
http://www.eskimo.com/~archer
Lotto: A tax on people who are bad at math. - unknown
Windows: Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: Curt Mills <archer@eskimo.com>
Date: Fri, 4 Jun 2004 21:03:37 -0700 (PDT)
X-Message-Number: 18
On Fri, 4 Jun 2004, Scott Miller wrote:
>>>You have the advantage of the HamHud software being easily upgraded,
>>>with several active developers. Use that advantage.
>
>>Could probably be upgraded to even handle the Opentrac format as well
>>as regular APRS.
>
>If HamHud gets KISS support, I'll be happy to provide the code.
Our Xastir Serial KISS Interface code works, I wrote it, and I'll freely
donate it to the HamHud project. They'd probably be best served by using
it as example code and re-writing it in their style though. If HamHud is
GPL'ed (not sure, didn't look), they can use any/all of our code as long as
they keep it under the GPL license. If Hamhud is GPL'ed they'll have to be
careful what they borrow, as the developer of that bit of code would have
to allow them to relicense it under whatever they use.
Like I said, the Serial KISS code is mine, and you're welcome to it for
that project.
--
Curt, WE7U. archer at eskimo dot com
http://www.eskimo.com/~archer
Lotto: A tax on people who are bad at math. - unknown
Windows: Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: RE: OpenTrak source code
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 22:27:28 -0700
X-Message-Number: 19
>I get into these opentrak files and am totally lost.
>Why do you need so many files to do one job ?
It's a matter of separating functions both for clarity and reusability.
Right now it's in transition because it's forking into a tracker version and
a weather version, so what used to be main.c is now tracker_main.c and
weather_main.c, but the split isn't complete yet.
fsk.c is the modulator (bpsk.c is just a test stub), gps.c is the GPS
parsing code, dallaswx.c is the 1-wire weather station code (still in work),
utility.c has common utility functions, hardware.c has the hardware-specific
initialization code, and so on. I won't go into the logic behind header
files and external declarations here - you can refer to a text on C for
that.
All of the firmware variants come from the same project - it just depends on
what target you build. Most of the differences are governed by conditional
compilation directives (#ifdef, #ifndef) that are controlled by settings in
the targets.
>You have a chip, and code that goes into it. Simple.
Once you get the object code, yeah. The .s19 file gets loaded straight into
the chip by the configuration program. If all you're after is pre-built
firmware, that's all you need. Heck, don't even mess with that - just click
the 'Web' button and select the firmware variant you want to load.
I'm used to dealing with large projects, and I've learned lessons about
scalability and maintainability the hard way. Now I tend to organize and
separate things compulsively. I've had to make compromises because of the
limitations of the platform, though - global variables, for example, are
typically bad style but in this case their use can save hundreds of bytes of
code.
>Ideas ? Comments ?
You'll probably want to take this to the opentracker group if you have more
questions. I'll be happy to go over specifics with you outside of this SIG.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 22:45:10 -0700
X-Message-Number: 20
>though. If HamHud is GPL'ed (not sure, didn't look), they can use
>any/all of our code as long as they keep it under the GPL license.
The Base91 encoding routines and OpenTRAC encode/decode routines in both the
listen code and OpenTracker firmware are available under the BSD license, so
they're free to do whatever they want with them. The base91 stuff's not
pretty, but it avoids floating point math. What a pain...
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
