OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
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


 07.07.2025 17:56:41lGo back Go up