Bug #5967
openFTM-3200DR - Checksum Failed [064A-06C8 (@06C9)]
Added by Tom Kissinger over 6 years ago. Updated over 2 years ago.
0%
Description
Getting a Checksum Failed [064A-06C8 (@06C9)] Error when doing read from radio with model FTM-3200D selected.
Radio Firmware:
CPU: 2.11
DSP: 4.15
CHIRP daily-20180707 - Using both Win7 and Ubuntu 16.04 platforms.
Files
debug.log (177 KB) debug.log | Tom Kissinger, 07/22/2018 07:41 PM | ||
debug.log (23.6 KB) debug.log | Tom Kissinger, 06/27/2020 04:37 PM | ||
debug.log (180 KB) debug.log | Tom Kissinger, 06/27/2020 04:43 PM | ||
debug.log (189 KB) debug.log | Josh Kesecker, 04/03/2022 09:04 PM | ||
debug.log (189 KB) debug.log | New chirp, new drivers, win 10/64 updated to latest | Edward Clarke, 04/20/2022 09:14 PM |
Updated by Tom Kissinger over 4 years ago
Tried again today with CHIRP daily-20200622 on Ubuntu 20.04 also. The same error.
Updated by Josh Kesecker over 2 years ago
I am also experiencing this error, running Windows 10 x64 with RT Systems USB-29F cable. With their software, this cable is functioning correctly on a 3100, so it should be operational.
I have:
*verified a FTDI-based chipset (as recommended on cable guide page recommended on BUG #6089)
*installing RT Systems' driver, device manager indicates this is the source of the current driver
If I start the download, and transmit from the radio, chirp & radio start progress bar, but at the end generates a checksum error, every time.
Looking at the debug log file, it appears to complete the Read operation, then throws an exception:
[2022-04-03 13:47:55,375] chirp.drivers.yaesu_clone - DEBUG: Clone completed in 58 seconds
[2022-04-03 13:47:55,375] chirp.ui.common - ERROR: -- Exception: --
[2022-04-03 13:47:55,375] chirp.ui.reporting - DEBUG: Reporting exception
[2022-04-03 13:47:55,375] chirp.ui.common - ERROR: Traceback (most recent call last):
File "chirp\ui\clone.pyo", line 255, in run
File "chirp\drivers\yaesu_clone.pyo", line 246, in sync_in
File "chirp\drivers\yaesu_clone.pyo", line 241, in check_checksums
RadioError: Checksum Failed [064A-06C8 (@06C9)]
Updated by Josh Kesecker over 2 years ago
Josh Kesecker wrote:
I am also experiencing this error, running Windows 10 x64 with RT Systems USB-29F cable. With their software, this cable is functioning correctly on a 3100, so it should be operational.
I have:
*verified a FTDI-based chipset (as recommended on cable guide page recommended on BUG #6089)
*installing RT Systems' driver, device manager indicates this is the source of the current driver
*updating to the latest daily version of chirp: 20220402If I start the download, and transmit from the radio, chirp & radio start progress bar, but at the end generates a checksum error, every time.
Looking at the debug log file, it appears to complete the Read operation, then throws an exception:
[2022-04-03 13:47:55,375] chirp.drivers.yaesu_clone - DEBUG: Clone completed in 58 seconds
[2022-04-03 13:47:55,375] chirp.ui.common - ERROR: -- Exception: --
[2022-04-03 13:47:55,375] chirp.ui.reporting - DEBUG: Reporting exception
[2022-04-03 13:47:55,375] chirp.ui.common - ERROR: Traceback (most recent call last):
File "chirp\ui\clone.pyo", line 255, in run
File "chirp\drivers\yaesu_clone.pyo", line 246, in sync_in
File "chirp\drivers\yaesu_clone.pyo", line 241, in check_checksums
RadioError: Checksum Failed [064A-06C8 (@06C9)]
Updated by Edward Clarke over 2 years ago
I'm getting the same problem with an FTM-7250D. I have purchased and tested TWO of the RT Systems USB-29F cables. One difference is that I have these lines in the debug file from the latest version of Chirp and a new driver from RT Systems -
[2022-04-20 17:00:08,729] chirp.ui.inputdialog - ERROR: Traceback (most recent call last):
File "chirpw", line 68, in
AttributeError: 'NoneType' object has no attribute 'split'
Updated by michael hassler over 2 years ago
Same message as others Checksum Failed [064A-06C8 (@06C9)] Successfully programmed a FT-2800m with the USB-29F cable prior to trying to read the FTM-3200D with Radio Firmware:
CPU: 2.11
DSP: 4.15
ChirpDaily 20220703