Order Tray | Contact Us | Home | SIG Lists

[aprssig] How to deal with DTMF keypad differences betweenmanufacturers

Robert Bruninga bruninga at usna.edu
Tue Sep 30 13:37:48 UTC 2008

> Hi all,
> prototyping the APRStt engine with a soundcard 
> on Windows XX... lead me to this situation...
> Entering the callsign with the Kenwood DTMF 
> keypad is OK, following the APRStt spec with 
> my TH-D7. But when I want to use my "old" 
> FT-470 from Yaesu, my "1" is "empty", QZ are 
> elsewhere (identical as my GSM), e.g "7" and 
> "9" keys are hosting 4 different letters!; so 
> I'm currently wondering how to deal with that...

This is an important issue.  Before the TH-D7, there were very
few, if any HT's or ham radio Mic DTMF pads that had any
ALPHABET on them.  SO since the D7 and D700 were the first
radios in 2000 when we began the APRStt spec  that had ALPHABET
printed on them (that we had seen), And we were using them for
text messaging in APRS we assumed that would be a good start.  

HOWEVER, your point is well taken...  I look at my desk
telephone and cell phone and see the same arrangement you have
on the Yaesu.  So, I agree that we need to change to the other

*** Also, to my concern many years ago, ECHOLINK adopted a
different alphabet coding system for DTMF.  They use the
encoding so that EVERY character is two digits.  It averages out
longer than the Kenwood method, but it is consistent.  I do not
have a cell phone and do not text message, so we need to see how
teenagers text message...  DO they do the 2key method, or do
they do the variable method.  Or is this still different on
different cellphones?

> Another issue, was the testing of "long" callsign DTMF 
> strings, where we can easily goes up to 18 DTMF digits in 
> normal mode, obviously not in hashing mode; but various 
> tested TRX have only 15 to 16 DTMF digits memories.

In the variable method, my recommendation to save two bytes on
the input of the callsign NUMBER, was to preceed the number with
the 0 key.  So the digit 4 (in WB4APR) would be 04 instead of
4444.  But this depends on whether we switch to the new 2 digit
method or keep the variable method.  Maybe we should wait to see
what Yaesu implements?

My answer on the long strings for some callsigns is for the
operator with a long call is to send the # manually first, then
the DTMF memory and then manually send the "D" at the end.  That
saves 2 digits...?


More information about the aprssig mailing list