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@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@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
