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

Fri Mar 30 21:14:50 EST 2018

Totally agreed on the PTT. As I mentioned, inverting wth a transistor is trivial. I was looking for the minimal parts approach and as simpleusb offered the PTT inversion, I went that path.

You have the COS issue exactly right. COS drops momentarily IF CTCSS is enabled on the node radio. Tried different HTs with same results, and from listening to the audio, clipping is highly unlikely. Additionally, when I flip the TM-V71 into Echolink mode, which mimics the COS/SQC and PTT/PKS signals into serial CTS/RTS for the Echolink application, CTS does not drop during DTMF reception on a CTCSS enabled frequency. Could be a defect in my unit, but I did find others claiming the TM-V71 couldn’t do CTCSS with Allstar. My neighbor’s got a D710. Next time I catch up with him it’ll only take a sec to put this SQC test cable on it and see how his behaves.

> On Mar 30, 2018, at 7:33 PM, Doug Crompton via arm-allstar <arm-allstar at hamvoip.org> wrote:
> 
> 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