Project

General

Profile

Actions

Bug #163

closed

Tone freq not set correctly on FT817

Added by Filippi Marco over 12 years ago. Updated over 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
05/06/2012
Due date:
% Done:

0%

Estimated time:
Chirp Version:
0.2.2
Model affected:
FT817
Platform:
All
Debug Log:
I read the instructions above:

Description

User reported:

I've just gotten a FT-817nd and started playing around with it using Chirp.
Everything is looking great except one problem. It looks like if I create a
memory entry with a CTCSS tone setting and it is written to a previously empty
channel, when looking at that channel on the radio I will see a random 16 bit
number (ie, 26654) instead of a formatted tone value (like "77.0"). (they
don't appear to match; three channels all set to a 100.0hz tone will show
three different random-looking numbers on the radio.) It does not transmit a
correct CTCSS tone. There don't appear to be any other data errors.

If I overwrite the value using the radio, it then works fine. If I clone the
radio to Chirp and then write it back immediately, the values are all still
good, but I don't know if this is because it already contains valid contents
or because i'm now writing valid contents.

Fwiw I am using debian linux and the daily build package from the apt repo,
but the same thing appears to happen with the 0.2.2 tarball from the site.
Further info: it is a recent-ish US model that's been MARS modded (no special
channels) and thus I am using the "FT-817ND (Intl versions)" instead of the
US version hardware type.

Anyway, I'm happy to try any suggested experiments or provide any further info
if it would help. I also have a paid copy of FTBasicMMO which does write tones
correctly, for comparison, but i'd much prefer to keep using chirp.

thanks for a fine piece of software!
eric


Related issues 1 (0 open1 closed)

Related to Bug #88: Tone freq not set correctly on ft857 familyClosedFilippi Marco03/28/2012

Actions
Actions #1

Updated by eric volpe over 12 years ago

this looks similar to bug #88, maybe.

Actions #2

Updated by Filippi Marco over 12 years ago

You are right: I can confirm they have the same base.
I just had a debug session and I'm writing the patch right now.

Actions #3

Updated by Filippi Marco over 12 years ago

  • Chirp Version changed from daily to 0.2.2
Actions #4

Updated by Filippi Marco over 12 years ago

  • Status changed from In Progress to Feedback

A fix has been sent and will be loaded in next days for download.

I'll be waiting for feedback

To correct with chirp any "dirty" memory generated from pre-patch version
the easiest is to literally import the image into itself.
Open the image, File->Import, select the image, then click "all" to select all memories and then import.

Actions #5

Updated by Dan Smith over 12 years ago

  • Target version set to 0.2.3

Patches pushed.

Actions #6

Updated by Filippi Marco over 12 years ago

  • Status changed from Feedback to Closed

Has been reported that:

As far as I can tell, the problem I reported is not happening any more with the
patch. It's not impossible that something else is preventing it from surfacing
but what triggered it before no longer does: uploading to a memory location
in the radio from a newly entered location in chirp.

Actions

Also available in: Atom PDF