[arm-allstar] Kenwood TM-V71 / D710 notes
Jeff Karpinski
jeff at 3d0g.net
Fri Mar 30 20:00:57 EST 2018
This seems the best place to capture my notes on setting up a Pi based Allstar node with the Kenwood TM-V71 (or D710 which uses the same chassis). Yes, it’s been done before but the info is pretty scattered and I found a CTCSS bug in the radio that others apparently missed.
I went the modded CM108 approach that’s pretty well documented. Fobs secured from https://www.ebay.com/itm/272374780193 <https://www.ebay.com/itm/272374780193> for a couple bucks each. Buy a couple extras, just in case you hose one up, plus I got one unit that looked fine but spewed ungodly RF noise. Generally followed the mod details found here: http://www.garydion.com/projects/usb_fob/ <http://www.garydion.com/projects/usb_fob/>. You don’t need the right channel so don’t bother with it.
Grab an old PS/2 keyboard or mouse and wack the cable off. Strip it back and tone out all the wires. Remember, the connector is male so the pins are mirrored from what’s shown in the Kenwood manuals. Follow this layout: https://www.i2cchip.com/minidin_male_large.gif <https://www.i2cchip.com/minidin_male_large.gif>
Wire up as follows:
CM108 Male DIN
Ground Pin 2 and cable shield (ground)
COS Pin 6 (SQC)
PTT Pin 3 (PKS)
Left Pin 1 (PKD)
Mic Pin 5 (PR1)
In the Radio settings, you’ll need to set the following options:
517 DAT.BND to A or B depending on what side of the radio you want to use for Allstar operations.
518 DAT.SPD to 1200 (de-emphasized audio).
520 SQC.SRC to SQL
And via the Kenwood MCP-2A programming software on the Data Terminal page (yes, it’s the only way to change these settings):
PR1 Pin Output Level (for packet mode): 8
PKD Pin Input Sensitivity (For packet 1200bps mode): 3
If you don’t change these settings, you’ll probably have a difficult time in getting the audio levels right in simpleusb.
Speaking of, here’s my simpleusb settings:
Active simpleusb stanza: [usb]
USB device String: 1-1.4:1.0
Card is: 0
Name is: usb
Rx Level: 500
Rx no-delay: 0
Rx audio-delay: 0
Tx A Level: 300
Tx B Level: 500
preemphasis: no
deemphasis: no
plfilter: yes
rxboost: yes
PTT: Active HIGH
PTT status: Un-Keyed
CTCSS (input): Ignored
COS (input): CM108/CM119 Active HIGH
COS (test): Un-Keyed
COS (composite): Un-Keyed
OK, now down to the bugs I found. First, in hamvoip 1.5, if PTT is set Active HIGH, on boot-up the radio will remain keyed until something is transmitted. I worked around this by editing /etc/asterisk/rpt.conf and enabling a startup_macro by finding and editing the following lines:
startup_macro = *920
; Play a Node announcement
920=localplay,/etc/asterisk/local/myid
Instructions for creating custom audio files like ‘myid' from your text can be found here https://www.hamvoip.org/tts-how-to.pdf <https://www.hamvoip.org/tts-how-to.pdf>
Once asterisk starts up and plays the announcement, it gets in sync with the actual PTT status and stays good from there on.
The radio bug? I really wanted to use CTCSS to keep other on-freq traffic from leaking into connected nodes. Problem is, Asterisk would show a “hang up” after every DTMF tone received. If I disabled CTCSS, everything worked perfectly. The "View COS, CTCSS and PTT Telemetry" option in simpleusb gave a similar clue, showing COS briefly going CLEAR the moment I sent a DTMF tone from my HT. Convinced this was still a software issue, I disconnected everything and tied an LED from the SQC line to ground on the radio. Sure enough, SQC went high with keying and proper PL, but the moment I sent a DTMF tone, it winked out for a few milliseconds. CTCSS disabled, no winking. I suspect this is why a lot of other folks came to the conclusion that these Kenwood radios didn’t support COS based CTCSS control. For giggles, I tried the same setup with DCS (Digital Code Squelch) and voilà! It worked perfectly! No COS winking while sending DTMF. Since this node is just for neighborhood use, I can easily live with the DCS compromise.
I’m fully aware there are other ways to skin these cats as hamvoip / Asterisk are crazy-powerful. CTCSS decode could be done inside the software. The PPT line could be inverted with a simple transistor. I suspect everyone’s Allstar setup ends up being a bit custom, this is simply what worked for me.
One last tip, if you’re enabling Echolink. In addition to the detailed mods to /etc/asterisk/echolink.conf listed in https://www.hamvoip.org/echolink_howto.pdf <https://www.hamvoip.org/echolink_howto.pdf>, note the default echolink servers are outdated. They should be as follows:
server1=nawest.echolink.org
server2=nasouth.echolink.org
server3=servers.echolink.org
server4=backup.echolink.org <http://backup.echolink.org/>
73, N0KAI
More information about the arm-allstar
mailing list