Hi Tom,

took me a while to move to a daily build, but that's done now.

But nothing changed according to the Umlauts, here a screenshot from today, you can see locations

0, 9, 10,15,16 with incorrect characters.

I assume this is related and the hook to fix it,

http://trac.chirp.danplanet.com/chirp_daily/LATEST/Model_Support.html shows a Kenwood TH-F7 and mine is a TH-F7E. The characterset offered by the RIG seems to be extended compared to the TH-F7 by 65 characters see http://www.rigpix.com/kenwood/thf7e_thf6a_manual.pdf page 17

while trying to autodectect the Type it fails as follows

/opt/chirp/chirp-daily-20150530/chirpw 

ERROR: Timeout waiting for data

E' --- --- Exception Dialog: Unsupported model `TH-F7

ERROR: Traceback (most recent call last):

  File "/opt/chirp/chirp-daily-20150530/chirp/ui/clone.py", line 175, in run

    cs.radio_class = detect.DETECT_FUNCTIONS[vendor](cs.port)

  File "/opt/chirp/chirp-daily-20150530/chirp/detect.py", line 103, in detect_kenwoodlive_radio

    raise errors.RadioError("Unsupported model `%s'" % r_id)

E'dioError: Unsupported model `TH-F7

ERROR: ----------------------------

I did above tests while manually set to TH-F7.  I checked the code but I am not really used to Python, I am more the bash coder :) so I cannot attach a patch right now.

Give me some hints or create a TH-F7/TH-F7E switch I could extend in a local copy.

73 Christian

​

2015-05-18 17:08 GMT+02:00 Tom Hayward <tom@tomh.us>:

On Mon, May 18, 2015 at 2:55 AM, Christian Hilgers
<christian.dg7pc@gmail.com> wrote:
> Hi,
>
> I tested chirp 0.4.1 on Debian Jessie with my Kenwood TH-F7e via USB-serial
> Adapter and a serial-RIG Cable.
> It worked very well and I could read and write data from and to the
> handheld.

0.4.1 is long out of date. Best to use the daily build, currently
chirp-daily-20150513.

http://trac.chirp.danplanet.com/chirp_daily/LATEST/

> It failed while reading Frequency Names like Düsseldorf or others with
> Umlauts. I am running UTF8 on my box.

How did the failure manifest? The only issue I know of with umlauts is
when used in a Windows user name (and subsequently the home directory
path), Chirp fails to run. This is a tough one, because the Chirp code
does all the right things for UTF-8 support. We're thinking it's a
PyGTK issue (which Chirp depends on).

http://chirp.danplanet.com/issues/272

Each radio has a specific character set that it will accept for
frequency names. Many radios define this in the manual which Chirp
developers can reference to implement identical support. If the
character set is not printed in the manual, it's a bit of a guessing
game which characters the radio will support. Sometimes we get it
wrong. FWIW, I'm not aware of any radio that supports UTF-8 in the
frequency names, but extended ASCII is relatively common. Here's the
full list of what Chirp implements for each radio:

http://trac.chirp.danplanet.com/chirp_daily/LATEST/Model_Support.html

If something here differs from what the radio supports, let us know.

Tom KD7LXL
_______________________________________________
chirp_users mailing list
chirp_users@intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_users
To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com