| |
ZL3AI > APRDIG 12.05.04 10:27l 268 Lines 11707 Bytes #999 (0) @ WW
BID : 3218-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 23, 1/10
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<DK0WUE<HA3PG<HB9OK<WB0TAX<VK7AX<
ZL2BAU<ZL3VML
Sent: 040512/0740Z @:ZL3VML.#80.NZL.OC #:23797 [Chch-NZ] FBB7.00i $:3218-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Friday, April 23, 2004.
1. Re: display the position data?
2. New APRS software - netAPRS - Replaces OziAPRS
3. Re: APRS greater precision
4. Everlasting discussions, Smart Move/Transition?
5. APRS station setup information page is up
6. Re: Additional thoughts on the great debate....
7. RE: Everlasting discussions, Smart Move/Transition?
8. The Kenwood TH-D7 is obsolete ?
9. APRS+SA programming
10. Re: Everlasting discussions, Smart Move/Transition?
11. RE: Everlasting discussions, Smart Move/Transition?
12. Help with a Trace
13. Re: Help with a Trace
14. RE: Everlasting discussions, Smart Move/Transition?
15. Re: Everlasting discussions, Smart Move/Transition?
16. Re: Help with a Trace
17. Re: Everlasting discussions, Smart Move/Transition?
18. LAN and LINKn-n (long)
19. Re: Help with a Trace
20. Re: Help with a Trace
<LYR36507-196213-2004.04.23-14.13.09--mikejp#videotron.ca@lists.tapr.org>
21. Re: Everlasting discussions, Smart Move/Transition?
22. Re: Help with a Trace
<LYR36507-196219-2004.04.23-14.40.00--mikejp#videotron.ca@lists.tapr.org>
23. Re: Everlasting discussions, Smart Move/Transition?
24. Re: Ambiguity?
25. Re: Additional thoughts on the great debate....
26. Re: APRS greater precision
27. Re: Additional thoughts on the
great debate....<LYR36507-195826-2004.04.22-12.06.35--m
28. Re: Additional thoughts on the great
debate....<LYR36507-195826-2004.04.22-12.06.35--m
29. Gaps in gated weather data
30. Re: Gaps in gated weather data
31. Re: Additional thoughts on the great debate....
32. Re: Gaps in gated weather data
33. Re: Gaps in gated weather data
34. Compromise proposal (was: Re: The APRS-WG and spec improvements.)
35. SW controled TH-D7 display (Was: Re: Everlasting discussions, Smart
Move/Transition?)
36. Re: Gaps in gated weather data
37. Re: Everlasting discussions, Smart Move/Transition?
38. Kenwood D700 remote mounting?
39. RE: Everlasting discussions, Smart Move/Transition?
40. Re: Gaps in gated weather data
41. Re: Everlasting discussions, Smart Move/Transition?
42. RE: Everlasting discussions, Smart Move/Transition?
43. Re: Additional thoughts on the
great debate....<LYR36507-195826-2004.04.22-12.06.35--m
44. Re: Gaps in gated weather data
45. Re: Compromise proposal (was: Re: The APRS-WG and spec improvements.)
46. Compromise proposal (was: Re: The APRS-WG and spec improvements.)
47. Re: Additional thoughts on the great
debate....<LYR36507-195826-2004.04.22-12.06.35--m
48. Re: Everlasting discussions, Smart Move/Transition?
49. Re: Compromise proposal (was: Re: The APRS-WG and spec improvements.)
50. RE: Everlasting discussions, Smart Move/Transition?
51. Comments on the D7
52. More Positionless Weather!!!!
53. RE: More Positionless Weather!!!!
54. Re: Objects and D7 are easy.
55. Re: More Positionless Weather!!!!
56. RE: More Positionless Weather!!!!
57. Re: Objects and D7 are easy.
58. Re: Help with a Trace
<LYR36507-196219-2004.04.23-14.40.00--mikejp#videotron.ca@lists.tapr.org>
59. Davis Barometer Errors
60. Fw: BalloonSat 9 to launch April 24th around 10:30 am CDT from Huntsville AL
61. Re: Davis Barometer Errors
----------------------------------------------------------------------
Subject: Re: display the position data?
From: "KC2MMi" <kc2mmi@verizon.net>
Date: Fri, 23 Apr 2004 01:36:32 -0400
X-Message-Number: 1
<< but just hit the POS (3) button. The degrees and minutes symbols with
flash at 1 Hz as long as good NMEA is coming into the D7. >>
KMC? Take a good look. The D7 display is: DDD.MM.mm
and the GPS display, as I posted, is: DDD.MM.mmm
The D7 is not capable of displaying the eight-digit standard display from a
typical consumer GPS, in any of the D7's normal position displays.
Or if it is, they've managed to hide that very nicely.
----------------------------------------------------------------------
Subject: New APRS software - netAPRS - Replaces OziAPRS
From: "Darryl Smith" <Darryl@radio-active.net.au>
Date: Fri, 23 Apr 2004 15:42:12 +1000
X-Message-Number: 2
People
Twelve months ago I released OziAPRS - an APRS program to interface to
OziExplorer (www.oziexplorer.com). Since then the program has undergone many
improvements, but at the same time the OziAPRS internal architecture was
starting to break down as more features were added. Once a new feature got
added, something would break. This is not surprising considering that the
program was only ever intended as a quick demo for a consulting job.
With this in mind it has long been my plan to re-write the software from the
ground up. I have moved away from Visual Basic 6, and moved to the more
modern VisiualBasic.Net. This has allowed me to significantly improve the
user interface and create a more 'object oriented' program. Internally I
have implemented a packet switching engine allowing packets to be routed
between parts of the software using a unified architecture.
The software not only sends data to OziExplorer, but also to Microsoft
MapPoint. [This feature was added to OziAPRS a few months back]. The program
will plot the positions for up to 1000 vehicles in OziExplorer, follow one
of automatically with self-centering maps, and Snail Trail 70 of users.
In the coming weeks I will be adding
* Automatic download from Garmin RINO's [Already a feature of
OziAPRS]
* Database logging and Playback
* Serial Port, UI-View and TNC interfaces
* State saving
* Polling of field units
* Documentation
OK, so what are the downsides. Well, many of the features have not been
extensively tested. Some have not been tested at all. And the biggest issue?
Well, .Net requires most people to download an extra 25 MByte library.
[Well, in reality if you run Linux sometimes you need to download similarly
size libraries, so there is nothing strange here :-) ].
You can get a copy of NetAPRS from
http://www.radio-active.net.au/web/tracking/netaprs.html
If you try it please let me know your comments...
Darryl
---------
Darryl Smith, VK2TDS POBox 169 Ingleburn NSW 2565 Australia
Mobile Number 0412 929 634 [+61 4 12 929 634 International]
www.radio-active.net.au - www.radio-active.net.au\web\tracking
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: "KC2MMi" <kc2mmi@verizon.net>
Date: Fri, 23 Apr 2004 01:50:18 -0400
X-Message-Number: 3
---------------------------------------------------------------
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 22 Apr 2004 15:38:09 -0400
X-Message-Number: 33
>>>"KC2MMi" <kc2mmi@verizon.net> 4/22/04 11:39:25 AM >>>
>Look on the bright side: A radio like the THD7 is already
>obsolete, it DOES NOT support the existing APRS capabilities.
Interesting comment from someone who doesnt own one.
---------------------------------------------------------------
Bob? I don't own one? You mean, the one that's two feet away from me is a
counterfeit? Or did I steal it and forget?
Me and Kenwood both think I own it, there's a credit card company and an
authorized Kenwood dealer who are under the same delusion.
Either the TH-D7 is incredibly poorly documented, or it doesn't support very
much of what APRS provides for. Well, we all know the docs are printed in
"Yng Glitch" but that beats asking me to read the original in Japanese.<G>
You tell me, if I send compressed posits, where is the radio going to
display them? We can start from there.
----------------------------------------------------------------------
Subject: Everlasting discussions, Smart Move/Transition?
From: db2fm <db2fm@jfsattv.de>
Date: Fri, 23 Apr 2004 10:43:12 +0200
X-Message-Number: 4
Following this list's discussions the last days (and also for the last
2...3 years) I'd like to say what my opinion is.
When I met APRS the first time 4 years ago (sorry for being so late :)
it really fascinated me from day one. As I always do, I downloaded the
specs to get the most complete information source available.
It took me several days to read it completely, not to say weeks
(and I'm a graduated engineer for electronics special interest
information and communication technics)!
There were too many different possibilities to encode things: position
can be send as raw NMEA, "generic" APRS-format, compressed (Base-91)
and MIC-E encoded data.
I thought: why to have so many differnt formats for one thing? - Is that
a standard? O.k. readable ASCII and compressed (to save air-time) both
made sence to me, but one is not possible with the other. Why isn't
there ONE standard?
One thing might be, to offer the possibility to use just an old TNC2,
adding a GPS-receiver and - you're set-up! But: You had to change
TNC-firmware anyway to have more APRS-functionality incorporated, so why
not do it right? (You see: also dumb old TNCs can be upgraded ;)
Next thing: wheather reports. The same thing! How many different formats
do we have now, because weather-stations of any kind should be on-air
with using just the old TNC?
An easy solution would have been to use a small PCB with a PIC and
modify the data from the weather-station to ONE GENERIC format!
(Same appies for the position when insisting on using TAPR 1.1.8!)
By the way, the often mentioned HamHUDs can easily be upgraded
in minutes (OT-code would save a lot of code-space especially in the
16F876 based ones, where it is short at the moment)!
Also modifications and extensions had been made over time to the APRS-
"standard". The problem was solved with adding some special characters.
What's special on an exclamation-mark? I know several stations using
them in a complete different way in their position comment (same applies
to other "special" characters). And that's NOT a misinterpretation of
the APRS-standard! They are allowed!
Sometimes I feel like APRS IS the tower af bable...
Some time ago Scott intruduced his new protocol: OpenTRAC.
I really found his ideas fascinating ! (Again, like with APRS!) Last week I
donwloaded the specs and found: a very consistent spec, that is EASILY
EXPANDABLE for everything, uses only ONE type of formats, can be easily
implemented for application authors (I've been told, I'm not a programmer)
it has less overhead, destination addresses do NOT contain data (like MIC-E
does) and several benefits more. (I initially wanted to name them all here,
but that would make this mail far too long. Only an important one: position
accuracy is shown with it's exact values from NMEA-data.)
So, why do some people only see "black and white"? (Bob? I remember an
email to all Kenwood users! That was politics, not developement or
argumentation. I own a D700 and USE it daily! And I'd like to get it
upgraded to OpenTRAC, if needed!) WHy not see the smooth grey-scale in
between?
My vision is a smooth move or transition to a new REAL STANDARD.
As I proposed two days ago:
1. use both protocols in parallel in devices capable of both
(Every client can read at least the old APRS-data)
2. use only new protocol on new devices (smart applications
like Xastir (hopefully UI-View, which I use, too) can
translate for the older ones.
This step can last for years, Enough time to even upgrade
the Kenwoods, too. They can be upgraded, at leats the D700s,
as has been shown with the Version 2.0G for extended NMEA)
3. IF new protocol is better, old APRS will "retire".
IF not, nobody will use it after a short period of testing.
What shouldn't be done, is to use OpenTRAC on a complete seperate frequency
with a seperate IS, That would never make a smooth transition possible.
Only my two cents...
73 de Juergen
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
