| |
ZL3AI > APRDIG 20.11.03 22:14l 252 Lines 10426 Bytes #999 (0) @ WW
BID : 2331-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 13, 1/14
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0BEL<CT4DK<KD7HAH<GB7BHX<GB7BHM<
ZL2BAU<ZL3VML
Sent: 031120/1713Z @:ZL3VML.#80.NZL.OC #:13181 [Chch-NZ] FBB7.00i $:2331-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Thursday, November 13, 2003.
1. RE: APRS Icon statistics
2. Station attributes -was- RE: APRS Icon statistics
3. Re: tm-d700A / Peet Ultimeter question
4. Deduced *and* Declared Personality [was: APRS' Protocol Holes]
5. Re: Adding Frequency of TX to the Protocol [was:APRS'Protocol Holes]
6. Sniffing for WideN-N's? [was: APRS Icon statistics]
7. Re: Sniffing for WideN-N's? [was: APRS Icon statistics]
8. Re: Adding Frequency of TX to the Protocol [was:APRS'Protocol Holes]
9. Re: Deduced *and* Declared Personality [was: APRS' Protocol Holes]
10. RE: APRS Icon statistics
11. Re: MULTI-ICON proposal
12. Re: MULTI-ICON proposal
13. Re: tm-d700A / Peet Ultimeter question
14. Re: MULTI-ICON proposal
15. D700 Remote Cable
16. Re: D700 Remote Cable
17. Re: MULTI-ICON proposal
18. Re: Station attributes -was- RE: APRS Icon statistics
19. Re: MULTI-ICON proposal
20. Re: MULTI-ICON proposal
21. Re: Station attributes -was- RE: APRS Icon statistics
22. Re: MULTI-ICON proposal
23. Re: Station attributes -was- RE: APRS Icon statistics
24. Re: Station attributes -was- RE: APRS Icon statistics
25. Re: MULTI-ICON proposal
26. Re: Station attributes -was- RE: APRS Icon statistics
27. Re: MULTI-ICON proposal
28. Re: MULTI-ICON proposal
29. Re: Station attributes -was- RE: APRS Icon statistics
30. Re: MULTI-ICON proposal
31. Re: Station attributes -was- RE: APRS Icon statistics
32. Re: Adding Frequency of TX to the Protocol[was:APRS'Protocol Holes]
33. Re: Deduced *and* Declared Personality [was: APRS' ProtocolHoles]
34. Re: MULTI-ICON proposal
35. Re: MULTI-ICON proposal
36. Re: Sniffing for WideN-N's? [was: APRS Icon statistics]
37. Re: Station attributes -was- RE: APRS Icon statistics
38. Re: Station attributes -was- RE: APRS Icon statistics
39. Re: Adding Frequency of TX to the Protocol[was:APRS'Protocol Holes]
40. Bob...cutting to the chase on Frequency-of-TX & Network Personality
41. Re: MULTI-ICON proposal
42. Re: MULTI-ICON proposal
43. Re: Deduced *and* Declared Personality [was: APRS' ProtocolHoles]
44. Re: Sniffing for WideN-N's? [was: APRS Icon statistics]
45. Re: MULTI-ICON proposal
46. Kantronics Talon data radio?
47. Re: Station attributes -was- RE: APRS Icon statistics
48. Re: MULTI-ICON proposal
49. Re: Bob...cutting to the chase on Frequency-of-TX & Network Personality
50. Re: Station attributes -was- RE: APRS Icon statistics
51. Re: Bob...cutting to the chase on Frequency-of-TX & NetworkPersonality
52. Re: Station attributes -was- RE: APRS Icon statistics
53. APRS Fundamental Symbology
54. Re: MULTI-ICON proposal
55. Re: MULTI-ICON proposal
56. Re: MULTI-ICON proposal
57. Re: MULTI-ICON proposal
58. Re: Station attributes -was- RE: APRS Icon statistics
59. Re: Station attributes -was- RE: APRS Icon statistics
60. Re: Adding Frequency of TX to the Protocol[was:APRS'ProtocolHoles]
61. Re: Adding Frequency of TX to the Protocol[was:APRS'ProtocolHoles]
62. Re: MULTI-ICON proposal
63. UI-VIEW fixup / features wish list
64. Re: Station attributes -was- RE: APRS Icon statistics
65. Re: [Xastir] How to show a storm front ?
66. Re: [Xastir] How to show a storm front ?
67. Re: Station attributes -was- RE: APRS Icon statistics
68. Re: UI-VIEW fixup / features wish list
69. Re: How to show a storm front ?
70. Re: [OZAPRS] How to show a storm front ?
71. Re: [Xastir] How to show a storm front ?
72. Re: How to show a storm front ?
73. Re: Station attributes -was- RE: APRS Icon statistics
74. Re: UI-VIEW fixup / features wish list
75. Re: Station attributes -was- RE: APRS Icon statistics
76. Sapphire Digipeats
77. The wrap up
78. Re: Station attributes -was- RE: APRS Icon statistics
79. Re: The wrap up
80. FW: [amsat-bb] ISS Active
81. Re: The wrap up
----------------------------------------------------------------------
Subject: RE: APRS Icon statistics
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Tue, 11 Nov 2003 23:06:47 -0600
X-Message-Number: 1
>It should! The "N" overlay character in its position report should _only_
>designate a full featured WIDEn-N digi with "NOID."
>http://web.usna.navy.mil/~bruninga/aprs/digi-overlays.html
Right, but the argument was that we shouldn't count on the content of the
packet being correctly configured, and software should be able to snoop
around to determine the capabilities of the station.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Station attributes -was- RE: APRS Icon statistics
From: Bill Herrmann <bherrman@spro.net>
Date: Tue, 11 Nov 2003 23:26:58 -0700
X-Message-Number: 2
At 09:17 AM 11/11/2003 -0500, Steve Dimse wrote:
>This is why to me, "symbols" are not the way to transmit station capabilities,
>any more than SSIDs were the way to send symbols. Rather, I believe station
>capabilities should be determined by the actual function.
At least twice today "capabilities" have been mentioned in the symbol/icon
"discussion". Wading through some of that it's very apparent (at least from
here) that the whole discussion of how to transmit the information via RF
and how to transmit the information via photons were separated.
Bob wants to make sure that the symbols convey meaningful information to
support the use of APRS as a tactical system. Others have icons and more
advanced displays with possibly untapped potential for conveying the
information that APRSDOS does via color. (and even the icon implementations
are conveying some info now - the clients I've used can put speed leaders
on moving stations. Not only does it make it obvious that they're moving
but gives you an idea where they might be.)
Would the whole discussion make more sense (and possibly actually get
somewhere) if the protocol to convey capability via RF got defined
separately from the method of displaying user to the humans? Somehow, I
doubt the designers of navy tactical systems convey the capabilities of a
given blip to another linked system by sending pictures.
Bill - who at the moment wouldn't tackle writing an APRS client with the
proverbial 10' pole!
----------------------------------------------------------------------
Subject: Re: tm-d700A / Peet Ultimeter question
From: "Andrew McDade" <amcdade@senet.com.au>
Date: Wed, 12 Nov 2003 19:23:41 +1030
X-Message-Number: 3
Gday Anthony,
Ive made up a small pic based jigga that does what you ask. But Ive set it
up for use with an WM918 weather station. I dont have any info on the Peet
Bros unit. But I would assume it could be done in a similar fashion. Have a
look at www.qsl.net/vk5ex .
73 .. Andrew VK5EX
..
>I'd be interested in knowing of any simple code (inexpensive and preferably
>complete) that can be used in between the Peet Bros and a TNC (basic stamp
>approach, etc) to convert the "data logging" mode (as opposed to packet
>mode) data into the equivalent APRS protocol specification. Many of our
>stations are at digipeater sites so we have both weather and digi functions
>going on so it would be nice to send a packet preformated to the TNC for
>transmission.
>
>Anthony (K4ARG)
----------------------------------------------------------------------
Subject: Deduced *and* Declared Personality [was: APRS' Protocol Holes]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Wed, 12 Nov 2003 06:57:27 -0500
X-Message-Number: 4
===== Agreement on two points, then... =====
>>I am advocating the idea that it is important for RF users to know what
network>>appliances exist in their RF network
<snip>
> so no big argument...
>>It would be advantageous to the APRS network to:
>>1. Identify all of the possible "Type A" network appliance personalities
>>2. Identify which of these personalities is exhibited by each APRS device
<snip>
>No argument on these two points...
===== Leaving this one... =====
>>3. Encode this information into each TX frame
>Why encode it when the data can already be deduced?
Because there are instances when it cannot be deduced.
End users must be given the opportunity to modify automated settings where
it makes sense to do so.
===== In wrap up =====
We agree that there is a need to implement a way to capture and display any
given device's network personality to others on the frequency. The
question becomes how to "capture" this information.
I advocate embedding it in each TX frame. You advocate testing for an
on-air observed personality and letting the client software do the rest.
There are potential flaws in each approach. Why not embrace both
approaches? Establish an on-air protocol that will allow the embedding of
the information in each TX frame (where it can be embedded) and also define
the personality of each possible APRS network appliance to use on the
client-side where such embedded information is not available?
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: Adding Frequency of TX to the Protocol [was:APRS'Protocol Holes]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Wed, 12 Nov 2003 07:29:18 -0500
X-Message-Number: 5
Steve Dimse wrote:
>Maybe I'm missing something...
>
>K4HG>APRS,GATE,WIDE*:....This comes via HF
>K4HG>APRS,GATE*,WIDE*:....This comes via HF
>K4HG>APRS,WIDE*,GATE,WIDE:....This comes via VHF
>K4HG>APRS,WIDE,GATE,GATE,WIDE*:....This originates on VHF, goes through two HF
>GATEs, then ends up back on VHF.
>
>All HF Gateways respond to the alias GATE, so by looking at the path you can
>tell where it originated.
HF exists from 3 MHz to 30 MHz. There is traditional APRS activity on
10.101 and 14.103 Mhz. There is non-traditional APRS activity on 14.097,
28.128, 50.620 and 144.585. Which did the above come from?
>You are proposing something that will take time for every programmer to
>implement, which can only give the desired information to some of the users,
and>which I'm arguing gives no significant benefit.
There is *no* APRS programmer that has invoked all APRS protocols (Bob's
APRSdos included). Authors will implement what they wish to implement.
On the other hand, I know of *no* APRS programmer who has implemented new
protocols outside of the bounds of the APRS spec. The goal is to get it
into the spec first, then let 'market forces' dictate it's implementation.
Ev, W2EV
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
