[aprssig] How to deal with DTMF keypad differences betweenmanufacturers
Robert Bruninga bruninga at usna.eduTue Sep 30 13:37:48 UTC 2008
- Previous message: [aprssig] How to deal with DTMF keypad differences between manufacturers
- Next message: [aprssig] How to deal with DTMF keypad differences betweenmanufacturers
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 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
- Previous message: [aprssig] How to deal with DTMF keypad differences between manufacturers
- Next message: [aprssig] How to deal with DTMF keypad differences betweenmanufacturers
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
