<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, May 4, 2018 at 11:31 AM Rich Messeder &lt;<a href="mailto:NE1EE@hotmail.com" target="_blank">NE1EE@hotmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I interpret the answer to mean that I can screw up my radio with MCP, and can&#39;t with CHIRP?<br></blockquote><div><br></div><div>First let&#39;s clarify the nomenclature: MCP is both a protocol and the first part of the name of various software programs (MCP-2A, MCP-4A, MCP-6A, etc.).</div><div><br></div><div>There are Chirp drivers that implement both the MCP protocol and live mode protocols. For example, in Chirp you&#39;ll find the &quot;TH-D72 (clone mode)&quot; driver implements MCP and the &quot;TH-D72 (live mode)&quot; driver implements live mode (basically Kenwood&#39;s rig control protocol). There have been weird bugs in the past related to incorrect implementation of the MCP protocol that affected only the clone mode driver: <a href="https://chirp.danplanet.com/issues/1611" target="_blank">https://chirp.danplanet.com/issues/1611</a></div><div><br></div><div>There have been similar bugs with data initialization in RT Systems software, which also uses the MCP protocol. Here&#39;s discussion of one: <a href="https://groups.yahoo.com/neo/groups/Kenwood_TH-D74/conversations/messages/2885">https://groups.yahoo.com/neo/groups/Kenwood_TH-D74/conversations/messages/2885</a></div><div><br></div><div>I don&#39;t know of any protocol bugs with Kenwood MCP-2A/4A/6A software, but it&#39;s still possible. The writers have the benefit of being first-party to the specifications, so it&#39;s far less likely.</div><div><br></div><div>And I&#39;ve never heard of this sort of bug with any of the live mode drivers, since the radios do a pretty good job of rejecting bad data in this mode.</div><div><br></div><div>Tom KD7LXL</div></div></div>