开云体育

What has kept me from buying most mobile rigs is the lack of a computer interface that lets me download and upload memory files to and from the radio.

Its beyond me why any computer interface to a radio doesn't always include that feature... or why bother at all eh?

The ability to load frequencies of interest based on current events going on in the world (ham and swl), and for different travel destinations is important to me. It takes a lot of time to manually load frequencies. It takes a long time to create memory files too for various interest support. But when done, it is so fast and convenient to change those memory channels, even on the road with a lap top.

Keep in mind I prefer the radio to be as free of a computer connection to work fully and completely. I don't want a computer to have to be connected to fake the memory files for me that are not there when the radio is bare bones.

73 from Bill - WD8ARZ

You can already download memory files to the IC-706... there is software that does this very well.. It uses the C-IV interface on the 706.

You can already download memory files to the IC-706... there
is software that does this very well.. It uses the C-IV
interface on the 706.

Unfortunately that's not 100% correct. The memory storing and loading
capability offered by the IC-706 over CI-V does not allow to write/read
the full contents of a memory channel. For example it is not possible to
write the alphanumeric memory name. Also the split frequency cannot be
read/written directly.

On the other hand all modern Icom radios like IC-756ProII/III or IC-703
offer an extended command (1A 00) that allows to read/write the full
content of the channel. On the IC-703 for example it is possible to
write split frequency, CTCSS and repeater tone and even the alphanumeric
memory name with this extended command. As the IC-703 is very similar to
the IC-706MKIIG (with respect to the firmware) that would have been also
a great addition to that rig.

The bottom line is, I really hope the IC-7000 will provide that command
and (more important) Icom will document it properly as they did for
IC-R8500.

Regards
Ralf

From: "Ralf Reiterer" <ralfreit@...>

You can already download memory files to the IC-706... there
is software that does this very well.. It uses the C-IV
interface on the 706.

...

On the other hand all modern Icom radios like IC-756ProII/III or IC-703
offer an extended command (1A 00) that allows to read/write the full
content of the channel. On the IC-703 for example it is possible to
write split frequency, CTCSS and repeater tone and even the alphanumeric
memory name with this extended command. As the IC-703 is very similar to
the IC-706MKIIG (with respect to the firmware) that would have been also
a great addition to that rig.

Where in the data field returned by the 1a 00 command does the ProII
return repeater offset? It returns tones and whether tones are in use.
It rather ignores the concept of offset as far as I can find. It's another
"failing" on the part of ICOM in the ProII. And if the firmware cannot
be updated in the ProIII there are undubtedly some similar failures that
it endures. I wonder if the 7000's firmware will be updateable.

{^_-}

Where in the data field returned by the 1a 00 command does
the ProII return repeater offset? It returns tones and
whether tones are in use. It rather ignores the concept of
offset as far as I can find.

Yeah, it seems so since it also does provides split operation only by
command 0F but no shift state (DUP-, DUP+). Unfortunately I have not
found any documentation about the contents sent by the IC-756PROII and
III for command 1A 00 . As I'm currently writing a
IC-756/PRO/PROII/PROIII driver for my software (www.radioctl.com) any
documentation for that command would be helpful.

It's another "failing" on the
part of ICOM in the ProII. And if the firmware cannot be
updated in the ProIII there are undubtedly some similar
failures that it endures.

Unfortunately that not only convers the ProII or III firmware but almost
any. Take the IC-706MKIIG, it has the same front panel than the IC-703
but unlike the radio the MKIIG does not allow controlling volume or
squelch via CI-V - a feature/command that has already been available
when the IC-R7100 came out! Another example is the new R20. It has
exactly the same command set than the R10 although the radio itself has
many more features. I really have no idea why they place such
unnecessary (virtual) limits in the firmware...

I wonder if the 7000's firmware
will be updateable.

I really hope that it will be. Man each modern computer allows the BIOS
to be updated, so shouldn't it be standard for all modern radio devices
too!?

Ralf

From: "Ralf Reiterer" <ralfreit@...>

Where in the data field returned by the 1a 00 command does
the ProII return repeater offset? It returns tones and
whether tones are in use. It rather ignores the concept of
offset as far as I can find.

Yeah, it seems so since it also does provides split operation only by
command 0F but no shift state (DUP-, DUP+). Unfortunately I have not
found any documentation about the contents sent by the IC-756PROII and
III for command 1A 00 . As I'm currently writing a
IC-756/PRO/PROII/PROIII driver for my software (www.radioctl.com) any
documentation for that command would be helpful.

You pretty much have to play around to document it. This is what I
get for the 00 command:
typedef struct
{
BYTE subcommand;
BYTE memoryNumber[ 2 ];
BYTE sel; //Sel- Scan Select flag (1 byte) $01
BYTE frequency[ 5 ];
BYTE mode;
BYTE filterbw;
BYTE flags; // Flags: &01 - when set, Tx Subtone on
// &02 - when set, Rx Subtone on
// &10 - when set, Mode LSB, USB,
// AM, FM is modified to data mode
BYTE unk1;
BYTE txtone[ 2 ]; // ? Really three bytes with unk1
BYTE unk2;
BYTE rxtone[ 2 ]; // ? really three bytes with unk1.
BYTE name[ 10 ]; // 10 bytes ascii name (Fill in end tag first)
} ICOM_memory;

And this is what I get for the three P registers, the 1a 01 contents.
Alas, there is no command to transfer the Px registers to the VFO. (Ah,
if you do know one I overlooked please pass it along.) I've not looked
too hard into the Px memories because I see little utility to it. (I am
using memory 99 as a utility memory for jam setting the transceiver when
I change bands and the like. It also allows me to play with data mode
filter selections and bandwidths.

typedef struct
{
BYTE band;
BYTE bandregister;
BYTE frequency[ 5 ];
BYTE mode;
BYTE filterbw;
BYTE unk1; // maybe subtone flags.
BYTE unk2;
BYTE txtone[ 2 ];
BYTE unk3;
BYTE rxtone[ 2 ];
} ICOM_px_memory;

I wonder if the 7000's firmware
will be updateable.

I really hope that it will be. Man each modern computer allows the BIOS
to be updated, so shouldn't it be standard for all modern radio devices
too!?

If they do it I do have experience with the "safe way" that we used
in the Motorola Inmarsat terminals. Always run from RAM. For an update
transfer to a never written to chunk of EEPROM or an actual PROM with
the necessary bootloader code. Once new code is in memory and the set
is running from that code it can be written to the EEPROM in one
relatively fast operation. If it gets interrupted the untouched part of
memory still allows you to update your radio. Otherwise those SatCom
terminals could become VERY expensive boatanchors. It was well thought
out in advance to prevent the boatanchor phenomenon. They learned from
seeing what happened with the first Intel motherboards/boatanchors that
had the EEPROM feature.

{^_-} W6MKU

You pretty much have to play around to document it.

I know. I also have done that for other radios. The easy solution for
that boring part would be that Icom document the memory layout for every
radio supporting the 1A 00 command as they did for IC-R8500 and IC-R75.
That would save a lot of time and also prevent any damage of the radio
should corrupted data be written via that command (and the firmware
didn't failed to recoginze the data as being corrupted - the IC-PCR1000
is such a candidate).

This is what I
get for the 00 command:

That pretty much looks like the layout of the PRO version. So seems that
the storing capabilities have not changed between PRO and PROII.
Wondering about how the situation is for the PROIII...

BYTE unk1;
BYTE txtone[ 2 ]; // ? Really three bytes with unk1

Just a hit: I assume that unk1 really belongs to txtone (BYTE
txtone[3];) as that is the case for other radios too. However I have no
idea why Icom needs 3 bytes for a CTCSS tone when 2 suffice. ;-)

And this is what I get for the three P registers, the 1a 01 contents.
Alas, there is no command to transfer the Px registers to the
VFO. (Ah, if you do know one I overlooked please pass it along.)

Unfortunately not. I too do not see great utility in that registers.

...I change bands and the like. It also allows me to play with data

mode

filter selections and bandwidths.

For switching into data mode, you might consider using command 1A 06.

If they do it I do have experience with the "safe way" that we used
in the Motorola Inmarsat terminals. ...

That indeed is a very good strategy. It would be interesting if Icom has
chosen a (similar) safe way for updating the firmware in the IC-7800. If
not that radio would indeed turn into a very expensive brick. ;-)

Just for curiosity: what kind of software do you develop for the
IC-756PROII?

Maybe we should move the communication off list. Otherwise people might
beat us for being off topic.

Regards
Ralf, OE5ROP

From: "Ralf Reiterer" <ralfreit@...>

You pretty much have to play around to document it.

I know. I also have done that for other radios. The easy solution for
that boring part would be that Icom document the memory layout for every
radio supporting the 1A 00 command as they did for IC-R8500 and IC-R75.
That would save a lot of time and also prevent any damage of the radio
should corrupted data be written via that command (and the firmware
didn't failed to recoginze the data as being corrupted - the IC-PCR1000
is such a candidate).

This is what I
get for the 00 command:

That pretty much looks like the layout of the PRO version. So seems that
the storing capabilities have not changed between PRO and PROII.
Wondering about how the situation is for the PROIII...

BYTE unk1;
BYTE txtone[ 2 ]; // ? Really three bytes with unk1

Just a hit: I assume that unk1 really belongs to txtone (BYTE
txtone[3];) as that is the case for other radios too. However I have no
idea why Icom needs 3 bytes for a CTCSS tone when 2 suffice. ;-)

And this is what I get for the three P registers, the 1a 01 contents.
Alas, there is no command to transfer the Px registers to the
VFO. (Ah, if you do know one I overlooked please pass it along.)

Unfortunately not. I too do not see great utility in that registers.

...I change bands and the like. It also allows me to play with data

mode

filter selections and bandwidths.

For switching into data mode, you might consider using command 1A 06.

That's the way I used to do it. The switch into data mode is easy. Now
select a filter in data mode? That's the tough part. <sigh> That is
what I worked around using the memory load trick. I found it has some
utility if I do that. It's not huge. But it does work. And I get to
jam set several parameters which slightly reduces the time overhead
required to get the radio parameters fully changed. I implement 100
memories, the cannonical set of bands with WWV and 60 meters, and
3 vfos per hand. That combined with the push buttons I have anove
ny tuning rate slider makes a rather easy to use implementation. The
slider works logarithmicly. The further off center you go the faster
it tunes. And I set the rate tickmarks with buttons so I can quickly
move frequency in decade steps from 1Hz to 10MHz. I also added some
handy buttons for 3kHz steps and 5kHz steps. The 1, 3, and 5 kHz steps
make for nice manually controlled band scanning.

I've been building the thing for myself, mostly. So it works the way
I work rather than making any attempt to create an analog for any form
of receiver dial.

If they do it I do have experience with the "safe way" that we used
in the Motorola Inmarsat terminals. ...

That indeed is a very good strategy. It would be interesting if Icom has
chosen a (similar) safe way for updating the firmware in the IC-7800. If
not that radio would indeed turn into a very expensive brick. ;-)

Just for curiosity: what kind of software do you develop for the
IC-756PROII?

A remote control. If you want to see it I can send it to you. It has
one glaring problem that I need to tweak and repair and some lack of
controllability at the moment - TX tone and filter controls and the
like. Stuff I set and forget for the most part. The problem is making
changes too fast gets it confused. I have gone to considerable effort
to make the remote control safe when you make manual control changes.
That comes back and bites me a little. {^_-} I have in mind two strategies
for fixing the problem. But I'm being lazy at the moment.

If you play with C++ I can even let you have the source under GPL.

Maybe we should move the communication off list. Otherwise people might
beat us for being off topic.

<grin> At least it's more or less on topic. It is about the Pro's.

Send me email if you're interested. (And if I don't answer within about a
day send it to the list. It's rare but sometimes my VERY aggressive spam
filter misfires, particularly if the mail is not plain text or is full of
three letter combinations and odd punctuation marks. (Both are really
good spam indicators, by the way.)

{^_-} W6MKU, Joanne, (The broadcast video software I do is NOT GPL by
ANY stretch of the imagination. This remote control is recreation.)