No subject

always show Dayton or some other event location position
encoding grids.   Sure there are some wordings also on how to
encode universal coordinates, maidenheads, etc, but it really
is horribly messy way when compared against small helper
device squirting a MICe packet with GPS supplied coordinates.

After all, the MICe is intended as a data burst at the start
of repeater QSO to be relayed to APRS.  One way from voice
repeater input frequency to APRS channel.
(How many really implement it?  I guess that on 99% cases
an APRS digipeater co-located at the voice repeater site is
simple single port TNC without ability to do cross-channel
digipeating.)

> And that requires the user to store his DTMF callsign in his DTMF
> memory once.  Then he can report his "position" anytime,
> anywhere by pressing at most maybe 2 buttons.  1 to call up DTMF
> memory and the other to selct the memory.  Done.
> 
> For the purpose of the global APRS system, a DTMF callsign is
> all we need to hear.  It gives us this info:
> 
> 1) CALLSIGN
> 2) Date and Time of availability
> 3) Location (to nearest RF area)
> 4) Frequency he reported in on
> 5) Type of system, and range
> 6) Echolink or IRLP or other call-back node nuumber or other
> info.
> 
> For the purpose of facilitating comunicaiton between hams, the
> callsign, heard by an APRStt system is all we need.

So you really want a helper device squirting APRS message packet
"I am QRV here" (however that should be encoded) ?

Do remember that we hams are pack rats using any old junk that
possibly can be recycled to do the thing.  In this case this
very fact is both driving you to try to kludge the APRStt and
is also fighting against its implementation.

The APRStt is calling for very lattest technology at the
receiver/gateway systems in order to let the user devices to
be oldest possible.  (Essentially modern embeddable PC instead
of small micro-controller.)

Sure there are Echolink -like nodes around, but there are also
lots of voice repeaters without any sort of external linkages.
Just very simple control logic and old analog radio gear.

> And doing this two-button thing, and have the APRStt engine come
> back with "Welcome WB4APR" is just as efficient as me picking up
> the microphone and saying "WB4APR Mobile".  But the big
> difference is that the 2 button DTMF report is MACHINE readable
> and goes locally and globally.  Where the voice report falls on
> mostly deaf ears on one mostlly inactive repeater and goes
> nowhere.

Sure, and with MICe on voice repeater or on APRS channels you
get that same "BoB is here in this service area" effect.

Where the MICe usually does not pass thru the voice repeater,
that DTMF "song" does, and annoys people..

> > Sometimes your "trivial" is far from it.  Next thing 
> > is that you will hotly cry out and want bi-
> > directionality for that "trivial" thing.
> 
> Absolutely.  Once the report goes in, I want VOICE response.
> Heck, I did it in 2000 and 2001 using BASIC and I had
> synthesized voice using only 8 resistors on the parallel port.
> These days DTMF decoding by sound card and Voice synthesis by
> sound card is something that lots of programmers can do.  I just
> need to find someone that wants to do it. And is motivated to
> stick with it...

Sure.  At work when we receive specifications on something,
when it obviously is non-trivial and the spec is "quality" of
APRStt, we guess a high price for it, and multiply by 10.
Then we tell that back to the client, and also that improved
specification can lower the price.

....
> Still looking for talent...

Your changes will improve a lot with improved specification.

A GOOD specification to model your texts against is for example
IEEE 802.11 series (accessible for free from IEEE).

There are very good reasons why those papers are called Standards.
They are clearly written, covering _all_ aspects of the signals
and protocols, telling what bit combinations are valid and what
are not, what are reserved for further extensions.  How to handshake
those extensions, etc etc.

Such papers are hard to write, but they do get _interoperable_
systems out there in the field, and that is really important for
success of a system.

Right now the APRS 1.0.1 specification document is some 90% there,
and none of your small scattered text files reach even 10% of it.
One can never over-emphasize importance of good documents.

My guess is that editing the existing document fragments into APRS 2.0
will take at least a year of weekends, maybe more.  Things could get
going if one can find original source document used on editing of
that APRS 1.0.1, otherwise it takes longer to re-type all that stuff..
(And if I do it, then the editing data format will be DocBook; from
which there are excellent tools to produce clean HTML pages as well
as printable books.  Name any other tool able to do both.)

> Bob, Wb4APR

Matti, OH2MQK