[aprssig] How to deal with DTMF keypad differencesbetweenmanufacturers

[Garrett Sloan]

Just since I happen to end up working on many phone systems & data entry
systems, the published ITU Standard (ITU E.161) for DTMF arranged keypads
follows the Yaesu and Telephone implementation of 1-(none) 2-abc ... 7-pqrs
8-tuv 9-wxyz.
Before this became the "standard" the difference was with q&z which were not
labeled, but if they were, they were assigned to either the "1" or "0" key
on some phones.
Every phone system I've worked on follows the ITU.161 spec for 7-pqrs
9-wxyz, and every automated directory system I've used defaults to saying
"for Q press 7, or Z press 9".
Q & Z were the "mobile" ones, Looking at my 2 Linemans sets, my "old" one
has Q&Z on the "0" key, while my newer fluke has them properly on 7 & 9.

There's a PDF available at: http://www.itu.int/rec/T-REC-E.161-200102-I/en
linking to the E.161 document on "Arrangement of digits, letters and symbols
on telephones and other devices that can be used for gaining access to a
telephone network"

Garrett Sloan
VE6RKY
 

-----Original Message-----
From: aprssig-bounces at lists.tapr.org [mailto:aprssig-bounces at lists.tapr.org]
On Behalf Of Robert Bruninga
Sent: September 30, 2008 7:45 AM
To: 'F5SMZ Jean-Philippe'; 'TAPR APRS Mailing List'
Subject: Re: [aprssig] How to deal with DTMF keypad
differencesbetweenmanufacturers

> 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
format.

*** 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...?

Bob, WB4APR


_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig