Bug #8601


Icom IC-V86 tone code issue.

Added by Dustin Yaremcio over 3 years ago. Updated about 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Chirp Version:
Model affected:
Icom IC-V86
Debug Log:
I read the instructions above:


I am having problems setting a unique CTCSS code per individual memory channel.

I can set the global CTCSS code for the entire radio when I enter "Set Mode Operation" through VFO page 9-1 of the advanced manual.

Page 7-1 in the advanced menu details how to set the CTCSS, but unfortunately it looks as if one is only able set one CTCSS code and then either enable or disable the different tone modes for said channels.

If this is the case this is extremely inconvenient, as I will have to carry a list of CTCSS codes with me for the 100 and some channels I have programmed in.

When I populate the CTCSS code per memory channel and the send to the radio they just disappear.......


Screenshot_20210116-200034.png (227 KB) Screenshot_20210116-200034.png Dustin Yaremcio, 01/16/2021 07:02 PM
Actions #1

Updated by Bernhard Hailer over 3 years ago

  • Status changed from New to Feedback
  • Target version set to chirp-legacy
  • Model affected changed from IC-V86 to Icom IC-V86
  • Platform changed from Windows to All

I just reviewed the manual for this radio, and it's not entirely clear. Does the IC-V86 actually save the tone information with each channel (not just "tone on" or "tone off"), when you program it manually? If it doesn't, then it's a (rather strange) limitation of the radio; if it does, then the driver needs to be fixed.

Actions #2

Updated by Dustin Yaremcio over 3 years ago

Very ambiguous indeed.
I had a call into ICOM and they could not figure this out either.
It doesn't appear that when programing from the faceplate you can store tone's per individual channels.
Rather you can only turn on of off a tone and then set one tone in the global settings. Which is a major firmware flaw.

So Icom gave me a copy of their CS-V86 software and I was able to program just as one should be able too.
Radio function as expected afterwards.
But I was unable to download into Chirp afterwards.

Talking to other people RT systems has got this dialed too, so it can be done.

Actions #3

Updated by Bernhard Hailer over 3 years ago

Ok, if the Icom software can do it, then there's a bug in Chirp's IC-V86 driver code. Thanks for your feedback. Hopefully there's a developer with this radio who can fix it.

Actions #4

Updated by Kosta A. about 3 years ago

  • Assignee set to Kosta A.

For reference, the User Manual on Page 9-2 states that when the display type for the radio is set to name (dSP.Nm) you must enter VFO mode to enter into the set mode for the radio. When the display type is set to channel (dSP.Ch) and you enter into a memories set mode only a portion of the settings will be displayed. To be able to set a memories tone from the faceplate the display type must be set to frequency (dSP.Fr) in the initial set mode and then upon entering a memories set mode you will be able to modify the tone setting for that memory.

Actions #5

Updated by Kosta A. about 3 years ago

  • Status changed from Feedback to In Progress
  • % Done changed from 0 to 100

I have submited a patch to the dev mailing list for this issue.

Some icom mobiles, fill their eeprom with one's rather than traditional zero's. Chirps memory object will by default simply write the existing read memory buffer back to memory. In some cases this results in an correct value being written to the radio but an incorrect value being read by the firmware due to the inconsitent padding. The fix resolves this by zero'ing out all memory prior to writing new memories.

If you have previously used chirp to program the radio I would recommend deleting all memories in chirp prior to re-programming the radio to verify that memories are zero'd out appropriately, but in most cases you can proceed without doing so. The software has always supported writing tones on a per memory basis as designed - this bug however was causing an incorrect value to be read by the firmware.

I do not have access to the CS-V86 software so I cannot speak to the download failures, however if an image file were provided I could take a look. Otherwise this issue should be resolved once the change is commited.

Actions #6

Updated by Dustin Yaremcio about 3 years ago

What's your email? I'll send you the software.

Actions #7

Updated by Kosta A. about 3 years ago


Actions #9

Updated by Kosta A. about 3 years ago


Actions #10

Updated by Kosta A. about 3 years ago

  • Status changed from In Progress to Closed

Applied in changeset commit:8ccb116f565c.


Also available in: Atom PDF