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
