Bug #2505

FT-2900 split tones entered via CHIRP UI can cause lock-ups

Added by Richard Cochran about 6 years ago. Updated about 1 year ago.

Status:Closed Start date:04/06/2015
Priority:Normal Due date:04/06/2015
Assignee:Richard Cochran % Done:


Target version:- Estimated time:4.00 hours
Chirp Version:daily Platform:All
Model affected:FT-2900/FT-1900


If you enter a memory into a previously unoccupied memory via the CHIRP UI, and then upload that memory to the radio, then try to use the radio's UI to change the SQLTYPE, it can sometimes lock up the radio, necessitating a hard reset.

The problem appears to be due to a failure to initialize the split flags on the ctone, rtone, dcstone, and rx_dsctone. When these are left uninitialized, they default to 1 (set) for a previously unused memory. The radio normally leaves these flags unset (0), unless a tone->tone or DSC->DCS split is being entered. Fix is to explicitly initialize them always.

This was reported via email from and to me,

Associated revisions

Revision 2544:135494ac7732
Added by Richard Cochran about 6 years ago

[ft2900] fix lockup issue (#2505)
This fixes an issue where memories entered via the Chirp UI and uploaded
to the radio could sometimes cause lockups if the memory was later edited
in the radio to change its SQLTYPE. The cause was uninitized flags
that could erroneously flag a tone or DCS code as being part of a split
tone. Fix is to initialize the flags to zero -- there was already code
to set them to 1 when needed.


Updated by Bernhard Hailer about 1 year ago

  • Status changed from New to Closed
  • Chirp Version changed from 0.4.0 to daily
  • Platform changed from Windows to All


Also available in: Atom PDF