[aprssig] Doubling APRS messaging in ham radio overnight

[Robert Bruninga]

> I know you want to make use APRStt and, 
> DTMF but only a limited subset of radios 
> can decode the DTMF to text...

Two responses:

A) I think there are more FT51 and TH78's out there than there
are D7's!  That is why implementing this simple message to DTMF
conversion is worth it and would double ham radio access to text
messaging overnight.

B) Except for A, APRStt does not use DTMF back to users.  It
uses voice.  APRStt informs the APRStt user via synthesized
voice.  So then 100% of amateur mobile and HT radios can join
the system, not just the 3% that have APRS radios.

> Sending DTMF is certainly universal, 
> but many repeaters don't pass it.

APRStt is designed for SIMPLEX frequencies, no cavities, no
repeater, no complexity, simply a radio connected to the APRStt
device.  Yes, I did try to get some repater controller mfrs to
consider adding it, but the simplex frequency is a much better
concept for many of the reasons you mention.

> I'm also willing to bet that no two 
> manufacturers use the same DTMF code 
> sequences to make a particular letter

The FT51 and TH78 are the only two DTMF text paging radios and
they are compatible.

> Composing messages....
> I tried to use APRStt those years ago 
> when you were working on the DOS version, 
> but I never did get comfortable with all 
> the thinking I had to do to compose a 
> message.  I'd rather be able to compose 
> a message off line and squirt the finished 
> message on air.  This could be done with 
> a DTMF autodialer...

Yes, APRStt has evolved with those lessons learned.  Basically,
APRStt now involves nothing more from the user than the pressing
of his DTMF memory button to send a pre-saved DTMF sequence of
his callsign.  This gets converted by the local APRStt device
onto APRS as:

His CALL and APRStt symbol
Date and time
Position on the map in the APRStt list
Voice Frequency
Event comments added by the APRStt engine

In otherwords, 100% of everything APRS, and all the sender had
to send was his DTMF memory button once.  See
www.aprs.org/aprstt.html

> Imagine an event where a new operator was 
> trying to compose a message in real time... 
> and now imagine that I'm another guy 
> waiting my turn to use the repeater...

The APRStt system works best on simplex frequencies and not via
a repeater unless the repeater is dedicated to APRStt.

> or worse, I'm speaking to a race official 
> and am irritated by 30 to 45 seconds of 
> intermittant DTMF, so I turn down my speaker...

APRStt at an event is best set up with separate input and output
channels so users don't have to hear the DTMF, but only hear the
synthesized voice responses on the output channel.  A subtone
may be used on the output channel while someone is using the
input channel so that two users do not try to enter at the same
time.

> To make composition of messages easier, 
> it would be nice to have a display so 
> I could see and correct mistakes before 
> sending.

True.  But I do not think that sending DTMF messages will be a
primary or frequent task.  In fact, I would think that users
would pre-program their DTMF memories with some pre-considered
messages that they then send with a single push button.  Also,
the APRStt speaks back the message for confirmation before it
actually sends it.  See how we use pre-prepared messages for
special event reporting form HT's:  www.aprs.org/aprsevent.html

> what if I miss hearing the message and 
> need to hear some detail within 
> it again?

The APRStt speaks it in real time.  But then periodically speaks
"Messages for XXXX,YYYY,ZZZZ".  When someone hears that, they
press their #1 DTMF memory button that has their callsign in it,
and APRStt speaks their message again.  In fact, even without
the above message list, EVERY time a APRStt user presses his #1
DTMF memory button with his callsign to check-in, not only is he
updated on the APRS net, but the APRStt reads to him any pending
messages until he kills them.

This is no more complicated to users than replaying their
telephone answerer.

> And we have to depend on a local repeater 
> to have a PC with text to speech.

No, it can all be done in a tiny PIC or microcontroler, since
text-to-speech chips with RS232 serial inputs are readily
available.  We flew them on RAFT and ANDE and are about the size
of a 24 pin DIP.

> I'd rather not depend on the repeater 
> owner, but put the responsibility in the 
> end user's hands.

That is why I gave up on getting repeateer MFRS to add it and am
back now to a tiny PIC gizmo to do it all or a PC program.  We
can put them everywhere!

> It occurred to me that since every HT 
> can use a speaker mic, that we need a 
> speaker mic with simple encode / decode 
> message abilities. 

AMEN!  And I think that devices like the HAMHUD, Byonics TT4
with its large display will be perfect!   Or the products from
Scott and his NUVI interfaces.

> it seems the only thing...going for 
> APRS TT is that every radio has DTMF 
> sending abilities.  We still need 
> some dongle to decode the TT's into 
> text... 

Dongles yes, for those interested enough, but Dongles-NO for the
other 95% of volunteers that show up to help at an event with
their old venerable HT.  And unless they need to send any data,
they can hear the entire APRS situation via the APRStt voice
system.  This removes LOTS of redundant time consuming
information from the regular 2-way voice nets at these events.

> my point here is that we need to 
> develop some sort of kluged accessory 
> and then see how many radio OEMs 
> are willing to build-in the feature.  

Yes, that was 1996 and called the Mic-E which would fit inside
most existing speaker mics..  But still only Kenwood and finally
Yaesu have responded.  I prefer to take advantage of the
millions of existing radios that have KEYPADS just like the D7,
and have speakers, so that 100% of ham radio can participate in
APRS to some degree without having to wait on anyone to do
anything.  We just do it.

I did it in 2001, but still no one has come forward to implement
it in a complete hardwareless soundcard implementation that can
run on any PC or to implement it in a microcontroller...

I think such an individual would be come a Prince in the world
of APRS.

Bob, WB4APR

> On Sat, Jan 24, 2009 at 11:06 AM, Bob Bruninga 
> <bruninga at usna.edu> wrote:
> 
> 
> 	> I'd like to see some real effort made
> 	> to get IGate <> RF messaging working
> 	> right.  I switched to Xastir for my
> 	> IGate because I could never get APRSD
> 	
> 	> to do it...
> 	
> 	AMEN!  And that is why I proposed that all IGATES send 
> back a report (kind of like an ACK) to show how they handled 
> and APRS-IS packet-to-RF.  Then finally, the sender and 
> sysops could see where things are broken.  The description of 
> this proposal is www.aprs.org/aprs12/Igate-path-report.txt
> 	and is linked from www.aprs.org/aprs12.html
> 	
> 
> 	> I've had friends and family drive all
> 	> over the country, and I've only rarely
> 	> been able to get messages through to them.
> 	
> 	
> 	AMEN! This must be fixed as an urgent priority.  And 
> the only way to do that is to begin requiring IGates to 
> report what they are doing with messages they pass back to RF!
> 	
> 	It will take a long while, but we must begin somewhere, 
> because the current IGate system is completely undefined and 
> vulnerable to user settings and errors.
> 	
> 
> 	> As for the DTMF HTs, I just can't see
> 	> it catching on enough to be really
> 	> widely useful.
> 	
> 	
> 	If just 3 people find it useful, then in my club we 
> could DUPBLE the number of people at an event that can be 
> useful with exchanging APRS info (without tying up the 
> existing voice nets).
> 	
> 
> 	> We really need to encourage the HT
> 	> manufacturers to add some native
> 	> messaging capability.  Or shoehorn
> 	> it in there ourselves.
> 	
> 	
> 	Yep, that's what we are doing:
> 	* new VX8R
> 	* Byonics is adding messaging and keyboard to Trackers
> 	* Your opentrackers are adding such capabilites
> 	* IAPPS are being written for the IPhone and BBerry
> 	* Hopefully Kenwood is working on a new D7+?
> 	* too bad ICOM still thinks only of "tracking" and 
> refuses to even consider receipt and display of info to the
user.
> 	
> 	I say again, TRACKING is a dead end (except for special 
> event support and some other nitches).   Ham radio is all 
> about communications.  We need to bring the focus back to 
> that  so that APRS can help in all aspects of ham radio, not 
> just a few nitches.
> 	
> 	> For the PX-777 radios I carry,... it'd
> 	
> 	> be possible to cram a small MCU board
> 	> between the keypad/display panel and
> 	> the radio board.  The bad news is that
> 	
> 	> you'd still have to tap into the...
> 	
> 	I think a simple chicklet pushbutton could be the input 
> device.  User enters his info via CW, if he can see his 
> result on the display.  No, not wildly popular, but is sure a 
> simple way to add a tiny input device for a HAM radio
operator.
> 	
> 	Even the PUSH BUTTON can add message entry to any old
tracker!
> 	
> 
> 	> if you don't automatically call all
> 	> microcontrollers PICs.  =]
> 	
> 	
> 	I like typing "PICs" instead of the other mouthfull.  
> Is there a better all encompasing term for tiny thinggy's?
> 	
> 	Bob, Wb4APR
> 	
> 
> 	_______________________________________________
> 	aprssig mailing list
> 	aprssig at tapr.org
> 	https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 	
> 
> 
>