Programming memory locations from Linux
- HI everybody,
I enjoyed programming my Kenwood TH-D7A(G) memory locations with a
homebrew Perl script (download it from my website, referenced at
qrz.com/kb1oiq - its GPL). It was simple - the protocol was
documented. I've also noticed that the protocol is documented for my
IC-746PRO in the manual, and many other ham radios.
However, now I'm interested in a mobile rig, and an open specification
for a programming interface is a requirement for me. I don't need rig
control, but at least I want to load and dump the memory locations via
Linux. Please don't suggest Windows, a) I don't do Windows, and b)
this is the *linux*ham group. :-)
I'm having no luck finding the interface specifications for radios
which I'm considering. Am I blind or do these things not exist? If
not, why not?
Mobile rigs which I'm considering, and for which I'd like to find a
programming interface spec:
IC-208H, IC-V8000, IC-2200H, FT-7800R, FT-2800M , FT-1802M, FTM-10R,
I'd appreciate hearing your thoughts on the subject and any pointers
to helpful information.
Thanks, and 73,
On Thursday 01 May 2008, andykb1oiq wrote:
[programming fm mobile radios]
> I'm having no luck finding the interface specifications for radios
> which I'm considering. Am I blind or do these things not exist? If
> not, why not?
I have been looking into that for a while, and it seems as if most recent fm
mobile radios offer a cloning capability. I.e. they do offer a form of CAT
control, at least for the memories.
The downside is that none of the manufacturers I looked at (Icom, Kenwood,
Yaesu) publishes the protocol. For whatever reason.
A while ago I tried to understand the cloning protocol of an Icom handheld, I
am assuming that the protocol used here is similiar to that on a fm mobile
rig. Unfortunately I was not able to crack the encryption used there. It
should be easy and has been done before, but my knowledge of cryptography is
So, yes, fm mobile radios mostly do offer what you are looking for, but no,
the protocol specifics are usually not known. One reason I can think of is to
protect the market for their own programming tools, which are sold at a
- Hi Ekki,
Thank you for the reply. I have noticed this cloning capability and
assumed that it would be relatively easy to reverse engineer. I
suppose if it were so easy, it would have been done by now and
documented somewhere on the internet.
What strikes me as oddly inconsistent is that the vendors will publish
a programming specification for some radios but not others.
What about radios with those "fancy" microphones with many buttons
that allow all sorts of controlability of the radio from the
microphone? Has anybody documented or reverse engineered the
microphone inputs to the radio? I have found many sites with the
pinout documentation, but I have yet to find any description of the
Thanks, and 73,
- --- In email@example.com, "andykb1oiq" <kb1oiq@...> wrote:
>I'd like to have all open protocols, also, but I can understand why
> Hi Ekki,
> Thank you for the reply. I have noticed this cloning capability and
> assumed that it would be relatively easy to reverse engineer. I
> suppose if it were so easy, it would have been done by now and
> documented somewhere on the internet.
> What strikes me as oddly inconsistent is that the vendors will publish
> a programming specification for some radios but not others.
the vendors might not do it, on advice of lawyers and/or the FCC.
There have been some rigs on the market that you could reprogram to
operate out of spec -- outside ham bands (but what about MARS freqs?),
bad distortion, etc. Possibly you could cause the rig to fail by
changing bias levels, firmware code, or whatever. The vendors have to
prevent that or they might not get FCC type acceptance -- or they may
worry about warranty issues if rigs are getting "bricked".
If a vendor is going to provide a published, plain text user
interface, they have to do more work to sanitize it for the "hostile"
public. Many times (e.g. for typical VHF/UHF mobiles), they may
figure the demand does not warrant the effort.
Or that's my take on it FWIW.
73, Martin AA6E