[arm-allstar] Kenwood TM-V71 / D710 notes

Fri Mar 30 23:15:22 EST 2018

I have run two v71 with zero issues or modification, for over a year, on a 25 site linked system. They were the Allstar access point. I moved the Allstar to the system hub and intigrated a CAT800 with extender card. 
I mention this because the v71 worked perfectly for short term solution without any modification. 
David www.nctc.info

Sent from my T-Mobile 4G LTE Device
-------- Original message --------From: Doug Crompton via arm-allstar <arm-allstar at hamvoip.org> Date: 3/30/18  8:33 PM  (GMT-06:00) To: ARM Allstar <arm-allstar at hamvoip.org> Cc: Doug Crompton <wa3dsp at gmail.com> Subject: Re: [arm-allstar] Kenwood TM-V71 / D710 notes 
Jeff,

 There is one thing I am not following in you writeup.  I think the TMV71
is active low for PTT. This works fine with the default active low settings
and a FET or PNP transistor which is what you are suppose to use to drive
PTT. You would never connect PTT out of the FOB directly to PTT without
interface parts.  All FOBS manufactured for radios use a FET or NPN to
drive PTT. You can look at the various schematics and those at the
hamvoip.org site for modifying the FOBS.

On the DTMF issue dropping COS. I have not heard that one and I do not have
a radio to test. Let me make sure I have this right.
You are saying that when you key a radio transmitting to the node radio and
have good COS as shown on the simpleusb-tune-menu view display that when
you hit a DTMF tone on the radio talking to your node radio the COS drops?
This sounds more like a level issue perhaps the DTMF level is so high it is
clipping out of the node radios bandpass? It could also indicate loss of PL
from the radio you r are keying the DTMF on. Have you tried different
radios?

*73 Doug*

*WA3DSP*

*http://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

On Fri, Mar 30, 2018 at 9:00 PM, "Jeff Karpinski via arm-allstar" <
arm-allstar at hamvoip.org> wrote:

> 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
> _______________________________________________
>
> arm-allstar mailing list
> arm-allstar at hamvoip.org
> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>
> Visit the BBB and RPi2/3 web page - http://hamvoip.org
_______________________________________________

arm-allstar mailing list
arm-allstar at hamvoip.org
http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar

Visit the BBB and RPi2/3 web page - http://hamvoip.org