|
ZL3AI > APRDIG 13.06.04 07:33l 730 Lines 29177 Bytes #999 (0) @ WW
BID : 3448-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 07, 4/7
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<LU6DTS<ZL2TZE<ZL3VML
Sent: 040613/0512Z @:ZL3VML.#80.NZL.OC #:25749 [Chch-NZ] FBB7.00i $:3448-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: USB TNC challenge
From: "DG2JW" <dg2jw@privateasylum.com>
Date: Mon, 7 Jun 2004 22:31:00 +0300
X-Message-Number: 72
Hi Scott.
Im still playing with the Bluetooth Idea.
DO you really think a full features TNC could fit into a USB housing?
Best regards
Julian
OH8GEJ
----------------------------------------------------------------------
Subject: RE: Kenwood APRS radio...
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Mon, 7 Jun 2004 15:34:32 -0400
X-Message-Number: 73
Below is data from WE7U and his program...
Station Packet Rel. Verbosity Payload
Count % Count % Packets Chars Length
----- ----- -------- ---- ------- ---- ------
Ui-View: 6057 22.44 2478941 17.8 79.5 46.2 52.5 68.1
WinAPRS: 1396 5.17 684779 4.9 95.3 59.5 56.5 15.7
APRS+SA: 555 2.06 239722 1.7 83.9 48.3 52.1 6.2
Xastir: 371 1.37 104809 0.8 54.9 32.1 53.0 4.2
DosAPRS: 322 1.19 165569 1.2 99.9 56.2 50.9 3.6
MacAPRS: 56 0.21 26381 0.2 91.5 55.3 54.6 0.6
APRSce: 65 0.24 13443 0.1 40.2 16.9 38.0 0.7
PocketAPRS: 64 0.24 10394 0.1 31.5 18.1 51.8 0.7
AprsPoint: 14 0.05 6250 0.0 86.7 54.3 56.6 0.2
Aprsd: 916 3.39 241458 1.7 51.2 31.5 55.7
Ui-Digi: 267 0.99 218353 1.6 158.9 96.6 55.0
Network Node: 321 1.19 234434 1.7 141.9 80.9 51.6
Digi_ned: 128 0.47 100330 0.7 152.3 32.1 19.1
Unidentified: 8040 29.79 6405170 46.1 154.8 53.1 31.1
Kenwood: 4275 15.84 1296506 9.3 58.9 15.0 23.0
Std Mic-E: 2020 7.48 554696 4.0 53.3 11.3 19.3
TinyTrak: 1224 4.53 493845 3.6 78.4 38.1 44.0
NMEA: 463 1.72 257579 1.9 108.1 80.1 67.1
Experimental: 419 1.55 354270 2.5 164.2 101.9 56.1
Hamhud: 10 0.04 4105 0.0 79.7 40.0 45.4
Opentracker: 9 0.03 4366 0.0 94.2 45.6 43.8
----------------------------------------------------------------
Total:26992 100.0 13895400 100.0
Chars 1257219769 Avg Packet Length: 90.5 Avg Payload Length: 52.7
Posits 6578379 Compressed 68992 or 1.05% of posits
Objects 2947361 Compressed 27 or 0.00% of objects
Items 4902 Compressed 0
NMEA 2-digits 2923 or 1.41% of NMEA posits
NMEA 3-digits 87104 or 42.06% of NMEA posits
NMEA 4-digits 117077 or 56.53% of NMEA posits
Hi-Res Posits 273173 or 4.15% of total posits
73s,
Eric KF4OTN
kf4otn@amsat.org
----------------------------------------------------------------------
Subject: Re: Kenwood and KISS mode
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Mon, 07 Jun 2004 21:33:03 +0200
X-Message-Number: 74
Hello Wes,
At 12:40 6-6-2004 -0400, Wes Johnston wrote:
>Can someone explain to me the nuances of getting a kenwood radio's TNC
>into / out of kiss mode with regard to what it takes to get out of
>kissmode and talk to the radio itself (QSY, memory read/write) and back
>into KISS mode again.
KISS on is like a lot of TNCs with a TAPR type commandset:
KISS ON
RESTART
KISS off is standardized in the KISS protocol by sending command-byte hex
0xFF. 0xFF is the whole command and should therefore be delimited by FEND
flag characters (FEND has the value 0xC0 and should never appear inside the
datastream).
So you send C0 FF C0 and any KISS complient TNC should drop out of KISS
(unless it only knows KISS, in that case I suspect nothing happens or all
settings are reset or something like that).
Now the Kenwood specific part. Even in KISS you can drop out of packet mode
using the command:
TC 1<CR>
Note, TC 0 is for "on" and TC 1 is for "off", very odd.
That's the simple story since there are also TNC command that tell if the
unit should switch to APRS or PACKET mode. The simplest I think is to give
you the commands I send to the Kenwood in AX25_MAC (used by DIGI_NED).
AX25_MAC has to know this because when using a TH-D7E as digipeater the
unit may hangup occasionally. AX25_MAC detects this and uses these commands
to reinitialize the TNC in Packet mode.
Okay, ON sequence (tested on TH-D7E v2.0, TM-D700E and TS2000E):
command annotation
--------------------------------------------------
TC 1\r Drop to Kenwood command mode from whatever mode the unit
was in
\rTNC 0\r Switch APRS mode off (you can't go ditectly from TNC 1 to
TNC 2)
\rTNC 2\r Switch to Packet mode on TM-D700E and TS2000E (ignored by
TH-D7E)
\rTC 0\r Engage TNC in mode TNC 0 (TH-D7E) or TNC 2 (TM-D700E/TS2000E)
\rHBAUD 9600\r Switch explicitly to 9600 baud if you want to use that speed
\rHBAUD 1200\r Switch explicitly to 1200 baud if you want to use that speed
\rKISS ON\r Command to switch to KISS
\rRESTART\r Engage KISS
AX25_MAC does not actively monitor the response but just keeps 2 seconds
time between the commands.
To drop back to Kenwood command mode just send
TC 1\r
Note that I start a lot of the commands with \r, this is to be fail safe
not to include any buffered junk with the command, which could make the
command fail.
Note that I spoke of TH-D7E v2.0, TM-D700E and TS2000E, these are known to
work with KISS under a number of pre-conditions:
1) Be gentle, throwing too much data at the TNC makes it hangup. The TNC
only has room to buffer for at most 2 packets and you never know when that
data is flushed. I keep 2 seconds between subsequent transmissions.
2) Don't transmit while receiving data. AX25_MAC immediately cuts
transmission when it receives data and restarts when nothing has been
received in 500 ms.
When applying this at least the TNC in the TH-D7E keeps alive. If however
dispite this gentle treatment the TNC hangs up then the procedure above is
executed to bring it back to life. AX25_MAC does this when no data is
received from the TNC within 30 seconds after the last transmission. I
assume the TM-D700E and TS2000E does not require the same precaution as the
TH-D7E, but it doesn't harm.
Note that sending 2 packets back to back with this TNC is useless, it drops
out of transmission between the packets anyway.
Known NOT to work in KISS are: TH-D7E v1.0, TH-D7A and TH-D7A(G). I guess
the TH-D7E(G) works but I never had a report on that. All TM-D700's and
TS2000's seem to work in KISS, no solid data on that either except for the
E models.
Once in Kenwood command mode you can change almost all settings you like,
documents are floating on the web or you can look at the file that TH-TOOL
saves when you backup a TH-D7E (on http://www.homepages.hetnet.nl/~pe1dnn)
I hope this helps. Kind regards,
Henk.
----------------------------------------------------------------------
Subject: RE: APRS extensibility and OPENtrack
From: Jeff King <jeff@aerodata.net>
Date: Mon, 07 Jun 2004 14:35:55 -0500 (CDT)
X-Message-Number: 75
Quoting Scott Miller <scott@opentrac.org>:
>Why would they need to? The vast majority don't have a problem anyway. We
>had OpenTRAC traffic heard by how many people last week? A few hundred?
>A thousand?
See my earlier posts on Thursday about the balloon. The balloon at peak
altitude was moving between the cities of Cleveland Ohio and Pittsburg PA.
This is the population center of the industrial rust belt. Coverage extended
from the outskirts of New York city, Washington DC, Toronto and all the way
into the Chicago land. At peak altitude, which because it was a equalibrium
type balloon (open vent to the outside) was held for at least 5 hours. At peak
altitude, its RF covered a diameter of over 700 miles, encompassing an area
greater then 330,000 sq miles. Because the balloon was also moving, that area
likely was closer to 400,000 sq miles by the end of the day.
What I observed myself, with my radio on 144.39, when the balloon was hovering
over Pittsburg PA, was a 100% decoded packet, at ~S-3. My strongest digi to me
is around S-5, and I am using a AEA Isopole at 40 feet. Distance between me
and Pittsburg/balloon was ~250miles. Of course, I was not having any protocol
problems what-so-ever. When the balloon was first launched, I was getting it at
about S-6 or 7, and it was about 80miles from me at that point. Robert tells me
he was running 500mw into a wire dipole.
If I had to guess, I would say thousands heard it, if the figures of 20,000
APRS users is to be believed. And don't forget, the peak altitude bracketed
drive time and went into the early evening, let alone the WIDE, WIDE saturation
of the channel. Back of the napkin math shows in excess of 60,000 packets
generated on 144.39 during the 5 hour peak altitude period (that includes the
WIDE, WIDE multiplication). (1 transmission a minute, 2aprs/2OT packets in
each, times 60 min, times 5 hours, times est 100 wides (I didn't double it
which makes my guess quite conservative).
Yet, after all the smoke has cleared, ONE PERSON reported a real documented RF
protocol problem.
ONE.
Let me repeat that ONE, a mobile running HamHud out of Virginia.
And that is a fact Jack.... err Scott.
----------------------------------------------------------------------
Subject: Re: USB TNC challenge
From: "Curt, WE7U" <archer@eskimo.com>
Date: Mon, 7 Jun 2004 12:41:16 -0700 (PDT)
X-Message-Number: 76
On Mon, 7 Jun 2004, DG2JW wrote:
>Hi Scott.
>Im still playing with the Bluetooth Idea.
>DO you really think a full features TNC could fit into a USB housing?
You don't need a full-featured TNC, you only need KISS, which is a
_lot_ less code. ;-)
--
Curt, WE7U 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: Kenwood APRS radio...
From: Steve Dimse <k4hg@tapr.org>
Date: Mon, 7 Jun 2004 15:46:10 -0400
X-Message-Number: 77
On 6/7/04 at 3:10 PM Robert Bruninga <bruninga@usna.edu> sent:
>>>>"KC2MMi" <kc2mmi@verizon.net> 6/7/04 12:25:09 PM >>>
>>Wes, may I suggest it is well past time that the ham
>>community put some brains together and obsoleted
>>the Kenwoods for once and all?
>
>Wow, please explain this OPENtrck attitude to
>OBSOLETE the one radio we have that does all of
>APRS and which represents almost 50% of the
>packets on the air most of the working day?
>
>Would someone please do a APRS-IS statistical
>Analysis to show the TOTAL packet count from
>say 6 AM Eastern time to say 9 PM Pacific time
>of the number of Kenwood packets compared to
>all packets on the air?
>
>I think this would be an EYE opener to the biggest
>complainers on this list who don't even own one,
>and who have been misslead by programmer propaganda
>and who claim nobody uses them in their area?
>
>My bet is tht it is quite a large n umber...
Waste of time Bob. I still don't think you have internalized the difference
in attitude between the opentrack people and us. I didn't understand it
before these last few days, and I still find it hard to believe. As much as
you and I have clawed at each others eyeballs over the years, it was
because our views of what what APRS should do for the users differed. Even
in the most bitter fights with others on the sig, I never felt their
motivation was that much different from mine and yours, the vision
differed, not the goal. These people are different, they have admitted that
they have no concern for the users, and therefore the usual argument style
between us is not going to work here. Appeals for "what is best for APRS"
just won't work, because they just don't care.
It wouldn't matter if 100% of packets were Kenwood, and if at the first
sniff of an opentrack packet the Kenwoods locked up, and then caught fire.
They just do not care about the existing users, they would say the fault
lies with the way we designed the kludged protocol, with Kenwood for
producing bad devices, and the users for being stupid enough to buy one.
They have their own agenda, to "purify" amateur AVL, users be damned. I've
done my best, you've done your best, but the fact is these guys are going
to do what they are going to do regardless of any statistic or opinion
offered. Even if the silent majority were to chime in, it wouldn't matter,
they completely lack empathy...
My advice is to sign off of the topic on the sig as I have done, further
discussion there will not change anything. At this point I guess the best
we can hope for is that the local users will step up to the plate and quash
anyone in their RF net that start transmitting these packets. Clearly the
dual protocol mode will add to channel congestion, maybe that will be where
things get toned down.
Every year this gets harder to do...frankly there is a small part of me
that is hoping for the worst...if APRS falls apart from this, I'll finally
be free of all this crap. I could never walk away from findU on my own,
there are too many good people that use it and APRS for good things. Hard
to remember sometimes, but they say thank you just often enough to make me
stay...sure you understand that too.
Steve
----------------------------------------------------------------------
Subject: APRS Touchtone Wow
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 15:47:16 -0400
X-Message-Number: 78
>>>Sean Jewett <sean@rimboy.com> 6/7/04 12:35:07 PM >>>
>>"In other- words the exact way to spell WB4APR is
>>922444427A77 but in most cases, just using one key
>>press per letter or hitting 0924277 will be a unique
>>enough number [in the vicinity of THAT aprstt local
>>RF server so that] it only matches WB4APR in your
>>area without ambiguity."
>but I think it'd create too much of a problem in the long
>run. You're going to have to have some sort of registration
>process.
No, not at all. Just send the SHORT version of your call by Keypad or from
DTMF memory and if the APRStt server recognizes you it will say "WELCOME
WB4APR". If the short version decodes to two calls in your area it will
say, "Press 1 for WB4APR or 2 for WA4BRP"
At that point it sends out an APRS packet to the APRS system placing you on
the MAP within 10 miles of the location of that APRStt server using the 10
mile ambiguity symbol. Now worldwide everyone can see you... and you can
not do anyting else in APRS such as messages, queries etc. And all give
VOICE responses...
>it'll be an interesting day when WA4BPS tries to get
>on the air with the same code.
The APRStt server will notice if it has an ambiguity or not and will ask
for a clarification if needed as noted above..
>nevermind finding a good hands down application for it.
>The search continues...
Wow, I can think of DOZENS of immediate needs I have of this!
My kids would use it every day from their tiny HT's. When they get out of
school, or practice, or music, or scouts, or whenever they need DAD's taxi,
they just seleect DTMF #1 which is their call, and then DTMF #2 which has
encoded "GET ME". Or DTMF #3 which has encoded "CALL ME" or whatever. ALl
this from their $129 super tiny VX-2R HT in their pocket.
Then on my D7 I get the instant APRS message alert and can READ the message
without having to listen to the local repeater all day long...
de WB4APR
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: USB TNC challenge
From: "DG2JW" <dg2jw@privateasylum.com>
Date: Mon, 7 Jun 2004 22:51:41 +0300
X-Message-Number: 79
that was strange. I received my own message twice.
Julian
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: Danny <danny@messano.net>
Date: Mon, 7 Jun 2004 15:53:48 -0400
X-Message-Number: 80
I don't think it's fair to call this an "Opentrac attitude". Actually I
think you are being ridiculous.
The Kenwood radios are a target for many reasons. One is the argument that
APRS can't change because of the kenwoods. I realize it must be great to
have a company design a radio because of something YOU developed, but this
obsession with defending the kenwoods and making them the holy grail of the
outdated APRS 1.0 protocol is getting old. We need better than "but..
but.. the kenwoods can't do that!" Maybe you get a percentage of the sale
of every kenwood?? Hmmm...
The other reason is your constant unsubstantiated claims that they make up
some whopping ridiculous percentage of the APRS userbase. I would love to
see the number of kenwoods in operation.. a REAL number. Perhaps you are
basing your figures on sales numbers. I won't go into how absurd that is.
You seem to keep calling others to dig up the information, which shows even
more that you really have no idea what the figures are.
I would love to see a real survey of APRS clients in use. Software versus
hardware. We can even throw out every APRS station using software more
than 3 years old and label them as part of the "userbase that won't
upgrade". Better yet, we'll give those to over to the "hardware" list just
to help the "obsolete hardware" argument.
Danny
KE4RAP
----------------------------------------------------------------------
Subject: Re: APRS user beware part 2
From: Jeff King <jeff@aerodata.net>
Date: Mon, 07 Jun 2004 14:58:20 -0500 (CDT)
X-Message-Number: 81
Times move on...
Quoting Robert Bruninga <bruninga@usna.edu>:
>And those very short Mic-E formatted packets
>are what OPENtrack plans on obsoleteing by its *longer*
>opentrack format... Seems like a step backwards in my opinion...
One of the very few useful things to come out of the Clinton adminstration
was SA being turned off. This happened after MIC-E came out.
Further, WAAS is now appearing in cheap consumer grade GPS'es. That offers
additional accuracy, far far in excess of the ~60 foot(?) grainularity
MIC-E offers.
I remember once I did a live on-the-air demo of APRS to some public service
folks in Myrtle Beach SC. At a beach front hotel. I spent most of my time
explaining the VAN's really were not driving on the beach when they in fact
where waiting by the lobby to pick everyone up.
Some people need more accuracy.
----------------------------------------------------------------------
Subject: Re: APRS user beware part 2
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 7 Jun 2004 13:00:53 -0700
X-Message-Number: 82
>My recollection is that of the 20,000 APRS stations on the air
>that something like 3,000 of them were kenwoods. That
>is 16% not the 0.001 you just claimed.... and as far as the
Read my message again, Bob. I was referring to the number of OpenTRAC
stations on the air, not Kenwoods. I think 1:1000 is a close enough
estimate.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: USB TNC challenge
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 7 Jun 2004 13:07:32 -0700
X-Message-Number: 83
Full featured? No. But I could probably do a very basic KISS TNC. Maybe a
MC68HC908JB16 processor in a 20-pin SOIC, and an XR-2211 FSK demodulator in
a 16-pin SOIC. The JB16 has a built-in USB interface, just needs a couple
of external passives and a crystal. The main limiting factor is the RAM -
384 bytes for that variant, I think. Say 256 bytes for a packet buffer.
Probably enough for APRS, but questionable for normal packet. If there's
room for a LQFP 32 or 48, there are other variants with 2k or 4k of RAM.
And yes, there are probably AVRs or PICs with the appropriate features, too.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: Introducing "OPENAPRS"
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 16:08:44 -0400
X-Message-Number: 84
>>>"Christensen, Eric" 6/7/04 1:47:36 PM >>>
>>Yes, becasue no one has showed us what they think
>>APRS 2.0 is, nor how it would be backwards compatible
>>to existing users...
>
>Well, maybe what we need is a transition spec.
>One that could start to implement a cleaner code for
>APRS (or whatever you want to call it) while
>keeping the existing code [too].
Rather than having to develop now yet a third format (the interim one) I
still think that we can still have it all without creating a programmers
nightmare. Let APRS users remain on the APRS channel and let OPENtrack
develop a homogeneous OPENtrack channel that is not encumbered by all the
APRS stuff, yet let both feed the Internet.
The OT folks get their ease-of-coding and without any concern for backwards
compatibility and the APRS folks get to continue operating as normal The
APRS-IS glues them together so that users on either can talk to either.
Just like soon with APRStt, the TOUCHTONE users on ECHO link can also talk
to all too...
>But to sit back and look at tomorrow as if it will never
>come is completely wrong. It is time we started
>motivating this technology before we get passed by the
>commercial world (if we haven't already).
Absolutely! Go for it. Please. Just do it on another frequency where it
can proceed UNENCUMBERED by all the compatibility problems that will wear
down both systems if we try to SHOEHORN them onto the SAME channel! Wow,
why isnt this obvious to everyone on both sides of the argument???
OT users, please, check 145.01 in your area and see if it is available...
Bob
----------------------------------------------------------------------
Subject: APRS Protocol - A Modest Proposal
From: David Rush <david@davidarush.com>
Date: Mon, 07 Jun 2004 14:09:37 -0600
X-Message-Number: 85
I have a modest proposal for a minor change to the APRS protocol. Require
that APRS clients pay attention to the PID. If it's not F0, then the APRS
client is allowed to either discard the packet or process the packet in a
way appropriate for that kind of packet.
It seems a bit odd that, as I have heard on this sig, the protocol requires
the transmitter to use the proper PID but not the receiver. Why not take
advantage of the situation?
If such a thing were to become part of the spec, change of course would not
happen overnight, but it would be a step in the right direction.
Advantages:
1. Explicitly requires APRS clients to ignore packets they don't
understand (which they *should* do already, but it helps enforce the
practice).
2. Paves the way for multi-protocol networks in the future, where a
single packet network (not necessarily 1200 bps AFSK on 144.390 MHz, but
not necessarily not, either) could smoothly support multiple protocols.
Think of a network 1, 5, or 10 years from now that isn't just "the APRS
network", but a nationwide "UI Frame Network" that multiple protocols
could share. Digis could choose to either ignore or repeat certain
packets based on PID according to local policy.
3. Would possibly mitigate against periods of low signal-to-noise ratio
on the APRSSIG, as we have been experiencing recently.
Anyone on the WG interested in chapioning this idea? Anyone? Anyone?
I may be naive about why this hasn't been done already, but it just
seems to be A GOOD THING to do.
David, ky7dr
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 7 Jun 2004 13:14:04 -0700
X-Message-Number: 86
I'm afraid this isn't even worth my time to answer. At least Bob has had
the courtesy to keep this discussion a technical one.
Scott
N1VG
----- Original Message -----
From: "Steve Dimse" <k4hg@tapr.org>
Waste of time Bob. I still don't think you have internalized the difference
in attitude between the opentrack people and us. I didn't understand it
before these last few days, and I still find it hard to believe. As much as
you and I have clawed at each others eyeballs over the years, it was
because our views of what what APRS should do for the users differed. Even
in the most bitter fights with others on the sig, I never felt their
motivation was that much different from mine and yours, the vision
differed, not the goal. These people are different, they have admitted that
they have no concern for the users, and therefore the usual argument style
between us is not going to work here. Appeals for "what is best for APRS"
just won't work, because they just don't care.
----------------------------------------------------------------------
Subject: RE: The NEXT Greatest thing to APRS!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 16:18:08 -0400
X-Message-Number: 87
>>>"Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU> 6/7/04 1:49:45 PM
>>>
>..on aprsTouchTone... How do you input the position?
>Or does it just show you "in the area" of wherever that
>station that heard you?
See the spec: http://www.ew.usna.edu/~bruninga/aprstt.html
Yes, just entering only your callsign puts you in the VICINITY of the
aprstt server (10 mile ambituity) But if you want to enter more digits for
better position, then hit the "B" key followed by any format below that
meets your needs:
B*cccc. - In vicinity of station cccc...
B#nnn - In vicinity of numbered LOCation "nnn"
BMMRD#nnn - Road and Mile Mark number
Ba *cc - sets Ambiguity and position comment
Bmm *mm - Minutes (nearest mi +/- 30mi fm APRStt)
Bdmm *dmm - Degree/minutes (nearest mi +/- 300 mi fm APRStt)
Bmmhh *mmhh - L/L MM.HH exact posit +/- 30mi fm rptr ..
Bddmmhh*dddmmhh - L/L exact position..(N,S,E,W same as APRStt)
Notice that the simple 6 digit code of Bmm*mm will place you to the
nearest mile anywhere within 30 miles or so of the APRStt server... Its a
simple grid. This is more than adequate for my kids.
B12*34 might be at school
B34*56 might be at the pool
B45*13 might be at Joes house
B37*29 might be music lessons
etc. My kids only go about 10 places so thats all they need to know... yet
these all translate to a LAT/LONG.
Or for my kids, just use the format B#nnn where we can have 999 3 digit
pre-agreed locations...
thanks
Bob
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: Jeff King <jeff@aerodata.net>
Date: Mon, 07 Jun 2004 15:21:16 -0500 (CDT)
X-Message-Number: 88
Just trying to keep it factual...
Quoting Steve Dimse <k4hg@tapr.org>:
>It wouldn't matter if 100% of packets were Kenwood, and if at the first
>sniff of an opentrack packet the Kenwoods locked up, and then caught fire.
But of course they didn't, and has been conclusively proven here, they had
absolutely NO problem.
>They just do not care about the existing users,
Hey, don't take my word for it, go look at:
http://groups.yahoo.com/group/hamhud/
and see how little Scott cares for the ONLY USER IN a 400,000 sq mile
(inadvertent) test area to have reported a problem.
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: Steve Dimse <k4hg@tapr.org>
Date: Mon, 7 Jun 2004 16:28:54 -0400
X-Message-Number: 89
On 6/7/04 at 3:46 PM Steve Dimse <k4hg@tapr.org> sent:
>Waste of time Bob.
Geez, really shouldn't send email from work, second time I've done that
today...
Sorry all...time to perform a foot-ectomy ;-)
Steve
----------------------------------------------------------------------
Subject: Re: OPENtrak incompatibilites not needed.
From: Wes Johnston <wes@johnston.net>
Date: Mon, 07 Jun 2004 16:44:36 -0400
X-Message-Number: 90
DId the APRS Work group approve it?? lol.
Wes
At 02:28 PM 6/7/2004, Robert Bruninga wrote:
><< 2) We even added a fully backwards compatible resolution
> to one foot to APRS ...That can even be seen
> on the Kenwoods! >>
>Its the proposal that was added to the errata page
>about a month or so ago to meet the demand for higher
>precision and a datum that was backwards compatible.
>See http://www.ew.usna.edu/~bruninga/aprs/errata.html...
----------------------------------------------------------------------
Subject: APRSttone calls
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 16:43:26 -0400
X-Message-Number: 91
>>>Danny <danny@messano.net> 6/7/04 2:33:44 PM >>>
>Note that it's common for sequential callsigns to come
>from VE sessions, and you could very well have
>ke4rap, ke4raq, ke4rar, and ke4ras all in the same area.
Ah good point. But then it is easy to simply add an SSID to each by mutual
agreement. In APRStt, the SSID is separated from the call by a "0" zero.
So KE4RAP-1 would be 53472701 KE4RAQ-2 would be 53472702
Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |