[chirp_users] Issue with Umlauts

Christian Hilgers
Sun Jun 28 07:35:56 PDT 2015


Dear all,

I started learning Python the past time and from my understanding the Model
send from the TH-F7E is weird, here the debug output:
(There is non-standard outout in I added to help me understand how the
parts fit together)


[2015-06-28 16:23:10,581] chirp.drivers.kenwood_live - INFO: Trying ID at
baud 9600 with delimiter "('\r', ' ')"
[2015-06-28 16:23:10,619] chirp.drivers.kenwood_live - DEBUG: PC->RADIO: ID
[2015-06-28 16:23:10,640] chirp.drivers.kenwood_live - DEBUG: RADIO->PC:
E^MID TH-F7^ME^ME
[2015-06-28 16:23:10,640] chirp.detect - DEBUG: detect_kenwoodlive_radio
called on Port /dev/ttyUSB0
[2015-06-28 16:23:10,641] chirp.detect - DEBUG:   serial set to
Serial<id=0x7fac8f7d3f10, open=True>(port='/dev/ttyUSB0', baudrate=9600,
bytesize=8, parity='N', stopbits=1, timeout=0.5, xonxoff=False,
rtscts=False, dsrdtr=False)
[2015-06-28 16:23:10,641] chirp.detect - DEBUG:   *got r_id TH-F7^ME^ME*
[2015-06-28 16:23:10,908] chirp.detect - DEBUG:     rclass.VENDOR  Yaesu


That explaines why the console output looks scrambled:
RROR: ----------------------------
INFO: Trying ID at baud 9600 with delimiter "('\r', ' ')"
E' bye --- Exception Dialog: Unsupported model 'TH-F7
ERROR: Traceback (most recent call last):
  File
"/home/chi/LANG/python/chirp/chirp-daily-20150616/chirp/ui/clone.py", line
175, in run
    cs.radio_class = detect.DETECT_FUNCTIONS[vendor](cs.port)
  File "/home/chi/LANG/python/chirp/chirp-daily-20150616/chirp/detect.py",
line 108, in detect_kenwoodlive_radio
    raise errors.RadioError("Unsupported model '%s' bye" % r_id)
*E*' byerror: Unsupported model *'TH-F7*

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

[image: Inline-Bild 1]

Not sure how to continue now

73 Christian = DG7PC

2015-06-02 13:03 GMT+02:00 Christian Hilgers <christian.dg7pc at gmail.com>:

> 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-F7*E*. 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 at tomh.us>:
>
>> On Mon, May 18, 2015 at 2:55 AM, Christian Hilgers
>> <christian.dg7pc at 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 at intrepid.danplanet.com
>> http://intrepid.danplanet.com/mailman/listinfo/chirp_users
>> To unsubscribe, send an email to
>> chirp_users-unsubscribe at intrepid.danplanet.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20150628/c5e41b4d/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 15163 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20150628/c5e41b4d/attachment.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chirp-screenshot1.png
Type: image/png
Size: 77402 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20150628/c5e41b4d/attachment-0001.png 


More information about the chirp_users mailing list