Bug #8601: Icom IC-V86 tone code issue. - CHIRP

Actions

Copy link

Bug #8601

closed

Icom IC-V86 tone code issue.

Added by Dustin Yaremcio almost 4 years ago. Updated over 3 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Kosta A.

Category:

Target version:

chirp-legacy

Start date:

12/29/2020

Due date:

% Done:

100%

Estimated time:

Chirp Version:

daily

Model affected:

Icom IC-V86

Platform:

All

Debug Log:

I read the instructions above:

Description

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.......

Files

Screenshot_20210116-200034.png (227 KB) Screenshot_20210116-200034.png

Dustin Yaremcio, 01/16/2021 07:02 PM

Actions

Copy link

Updated by Bernhard Hailer almost 4 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

Copy link

Updated by Dustin Yaremcio almost 4 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

Copy link

Updated by Bernhard Hailer almost 4 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

Copy link

Updated by Kosta A. almost 4 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

Copy link

Updated by Kosta A. almost 4 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

Copy link