Project

General

Profile

Actions

Bug #5149

open

Attempting to clone a Kenwood TK-272G

Added by Jason Kates over 6 years ago. Updated over 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
09/13/2017
Due date:
% Done:

0%

Estimated time:
Chirp Version:
daily
Model affected:
Kenwood TK-272G
Platform:
All
Debug Log:
I read the instructions above:

Description

I have a TK-272G from our volunteer fire department (town of 600), it's not setup to receive pages. The chief has lent me someone else's radio to "clone".

It looks like the radio isn't fully supported thus I hope that you can help.

This is the debug:

chirpw -v --log /tmp/fooo --log-level info
INFO: Skipping existing stock config
INFO: Skipping existing stock config
INFO: Skipping existing stock config
INFO: Skipping existing stock config
INFO: Skipping existing stock config
INFO: Skipping existing stock config
INFO: Skipping existing stock config
INFO: Skipping existing stock config
INFO: Skipping existing stock config
INFO: Skipping existing stock config
INFO: Skipping existing stock config
INFO: Skipping existing stock config
INFO: Skipping existing stock config
INFO: Server reports version 20170714 is available
ERROR: The radio send 28 bytes, we need 258
ERROR: -- Exception: --
ERROR: Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/chirp/ui/clone.py", line 249, in run
    self.__radio.sync_in()
  File "/usr/lib/python2.7/site-packages/chirp/drivers/tk760g.py", line 895, in sync_in
    self._mmap = do_download(self)
  File "/usr/lib/python2.7/site-packages/chirp/drivers/tk760g.py", line 553, in do_download
    d = _recv(radio)
  File "/usr/lib/python2.7/site-packages/chirp/drivers/tk760g.py", line 436, in _recv
    raise errors.RadioError(msg)
RadioError: The radio send 28 bytes, we need 258

ERROR: ----------------
ERROR: Clone failed: The radio send 28 bytes, we need 258
ERROR: --- Exception Dialog: The radio send 28 bytes, we need 258 ---
ERROR: None

This is the version I have installed:

[jkates@localhost ~]$ rpm -qi chirp
Name        : chirp
Version     : 20170711
Release     : 1.fc26
Architecture: noarch
Install Date: Wed 13 Sep 2017 09:12:29 PM EDT
Group       : Applications/Communications
Size        : 5783695
License     : GPLv3+
Signature   : RSA/SHA256, Tue 11 Jul 2017 09:00:25 AM EDT, Key ID 812a6b4b64dab85d
Source RPM  : chirp-20170711-1.fc26.src.rpm
Build Date  : Tue 11 Jul 2017 08:34:14 AM EDT
Build Host  : buildvm-ppc64le-12.ppc.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : http://chirp.danplanet.com/
Summary     : A tool for programming two-way radio equipment
Description :
Chirp is a tool for programming two-way radio equipment
It provides a generic user interface to the programming
data and process that can drive many radio models under
the hood.
Actions #1

Updated by Jason Kates over 6 years ago

I also tested with chirp-daily-20170714 (I downloaded the .tar.gz file and ran it from: tmp/chirp-daily-20170714/chirpw -v with the same error.

Thanks in advance!

Actions #2

Updated by Travis Veldkamp about 5 years ago

I have been working on this with Pavel's kind assistance. This appears to be a timeout reading the blocks of data from the radio. The timeout was set too low when reading the 256-byte blocks, resulting in a partial block being transferred. The timeout was quite a bit larger for Windows systems, so worked fine there. Matching the Windows timeout on Linux made this issue go away completely on the models I have tested.

I will submit a patch soon.

Actions #3

Updated by Bernhard Hailer about 4 years ago

  • Target version set to chirp-legacy
  • Chirp Version changed from 0.3.0 to daily
  • Model affected changed from TK-272G to Kenwood TK-272G

Has that patch ever been submitted? Thanks!

Actions #4

Updated by Bernhard Hailer over 3 years ago

  • Description updated (diff)
  • Platform changed from Linux to All
Actions

Also available in: Atom PDF