February 2011 - Users - lists.chirpmyradio.com

[chirp_users] [CHIRP] #77: Want bulk delete or CSV importing of blank channels
by CHIRP Tracker 10 Feb '11

10 Feb '11

#77: Want bulk delete or CSV importing of blank channels ---------------------------+------------------------------------------------ Reporter: n7ss@… | Type: Feature Status: new | Priority: Would be nice Milestone: | Component: Memory Editor Version: 0.1.9 | Keywords: Platform: Windows | ---------------------------+------------------------------------------------ Let's say I have a template with channels 0-199 filled. I want to create a new template with only channels 0-99 in that same radio. How do I get rid of the old channels 100-199? I can delete them individually - time-consuming and complicated if the new template has unused channels in the middle (because the old ones still appear in the blanks). I could do a factory reset on the radio and download the empty radio to use as a starting point for all my templates. That is also complicated for managing multiple radio models that may have other setting I want to retain. I suppose I could directly edit the IMG file and remove the channels I don't want but that invites error. A cleaner solution would be to allow deletion of a range of channels or even import of blank channels via CSV. Thanks! -- Ticket URL: <http://trac.chirp.danplanet.com/trac/ticket/77> CHIRP <http://trac.chirp.danplanet.com/trac> CHIRP Development

1 2

[chirp_users] [CHIRP] #80: Unable to export vx-8r file to csv
by CHIRP Tracker 10 Feb '11

10 Feb '11

#80: Unable to export vx-8r file to csv -------------------------------+-------------------------------------------- Reporter: gdiffey@… | Type: Bug Status: new | Priority: Functionality Milestone: | Component: Import/Export Version: | Keywords: Platform: Linux | -------------------------------+-------------------------------------------- I've successfully downloaded and uploaded from chirp however I'm unable to export to csv format for editing. I suspect the problem is to do with independant offset memory entries. where the uplink and downlink are completely independant. I'm using version 0.1.10 which doesn't appear in the version dropdown list. -- Ticket URL: <http://trac.chirp.danplanet.com/trac/ticket/80> CHIRP <http://trac.chirp.danplanet.com/trac> CHIRP Development

1 5

[chirp_users] [CHIRP] #78: Error on writing to an empty memory slot
by CHIRP Tracker 09 Feb '11

09 Feb '11

#78: Error on writing to an empty memory slot -------------------------------+-------------------------------------------- Reporter: chirp@… | Type: Bug Status: new | Priority: Stability Milestone: | Component: Memory Editor Version: | Keywords: write empty RadioJob KeyError Platform: Linux | -------------------------------+-------------------------------------------- When I was doing some testing (I think I accidentally tried to write to an empty memory slot: -- Exception running RadioJob: 54 -- Exception: -- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirpui/common.py", line 70, in execute result = func(*self.args, **self.kwargs) File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirp/kenwood_live.py", line 174, in erase_memory del self.__memcache[number] KeyError: 54 ------ -- Ticket URL: <http://trac.chirp.danplanet.com/trac/ticket/78> CHIRP <http://trac.chirp.danplanet.com/trac> CHIRP Development

1 1

[chirp_users] [PATCH 1/2] allow flashing by block numbers on THD-72
by Vernon Mauery 07 Feb '11

07 Feb '11

The current thd72.py module already can flash by block numbers based on a dirty block list maintained by the memory editor, but this adds the ability to do the same from the command line. This allows intrepid users to manually (or programatically) modify an image and flash back those individual blocks. This is especially useful for doing things that the gui doesn't do yet, like modifying the startup splash screen. Signed-off-by: Vernon Mauery <vernon(a)mauery.com> --Vernon N7OH

2 3

[chirp_users] TH-D72A setup
by Paul Campbell 07 Feb '11

07 Feb '11

Does Chirp connect via the TH-D72A usb port ? Is there setup information? ( I looked back a couple of months in archives and also looked at beginners guide)

3 2

[chirp_users] Thoughts on TH-F6A support and looking for D710 support
by David Ranch 06 Feb '11

06 Feb '11

Hello Everyone, KI6ZHD here. I just discovered Chirp as I was looking for some way of synchronizing the memories across my F6A, two D710s, and a VX5 in a Linux-only environment. I did some tests and it seems that the Kenwood TH-F6A support is close but it's missing the memory's NAME which is very important to me. I then tried the Kenwood D710 which communicated but didn't support and a Yaesu VX5 didn't work at all. I also noticed I couldn't save any downloaded data nor upload anything back to the radios (see below). The F6A and D710 are the priority radios for me and the VX5 is a backup. Any thoughts on getting the F6A and the D710 working? Taking it a step further, I'm ideally looking for is a memory syncronization tool across different radios. I'm not looking for full backups (though that would be nice like Kenwood's Windows applications) but memories is good enough. Any possibility of coming up with a system that would: - load multiple radio's data at the same time - merge and navigate conflicts (move memories I added in the Car or at Home) and allow me to move them into free slots - come up with a new master file - program them back into each of the radios I know that I could manually do this with Chirp with say CSV files but I think a merging feature like this would be a fantastic. --David Chirp 0.11.b4 Running on Centos 5.5 GTK 2.10.4 PyGTK 2.10.1 Three radios here are tested - Kenwood TH-F6A - Kenwood TM-D710 - Yaesu VX-5 ------------------------------------------- Kenwood TH-F7A ------------------------------------------- Recognizes TH-F6A fine !! does NOT download memory's names !! cannot select File --> Save As !! cannot Radio --> Upload to radio recognition sequence -- [dranch@hampacket chirp-0.1.11b4]$ ./chirpw PC->V71: ID V71->PC: ID TH-F6 PC->D7: ID D7->PC: ID TH-F6 Talking to a TH-F6 PC->D7: AI 0 D7->PC: ? Starting memedit Bank Index supported: False Bank supported: False DTCS Code supported: True DTCS Pol supported: False Mode supported: True Offset supported: True Name supported: True Tune Step supported: True Name supported: True ToneSql supported: True Cross Mode supported: False Started PC->D7: MR 0,000 D7->PC: N PC->D7: MR 0,001 D7->PC: MR 0,001,00145390000,0,2,0,1,0,0,12,08,000,000600000,0,0 PC->D7: MNA MNA 0,001 . . . -- ------------------------------------------- Yaesu VX5 (non-R) ------------------------------------------- Selecting Radio VX3 Program reports 000: 98 80 06 18 78 86 80 60 ....x..` 008: 78 06 00 00 00 00 00 00 x....... Selection of VX3, VX6, and VX7 does not work: VX5 commander (Windows) DOES work for me: http://www.kc8unj.com/vx5.html --> Cancel does NOT work program shows -- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirpui/cloneprog.py", line 58, in <lambda> cancel_b.connect("clicked", lambda b: cancel()) File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirpui/clone.py", line 200, in cancel self.kill(CloneCancelledException) File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirp/chirp_common.py", line 765, in kill import ctypes ImportError: No module named ctypes -- ------------------------------------------- Kenwood D710 ------------------------------------------- PC->V71: ID V71->PC: PC->V71: ID V71->PC: PC->V71: ID V71->PC: ID TM-D710 --- Exception Dialog: Unsupported model `TM-D710' --- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirpui/clone.py", line 153, in run cs.radio_class = detect.DETECT_FUNCTIONS[vendor](cs.port) File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirp/detect.py", line 117, in detect_kenwoodlive_radio raise errors.RadioError("Unsupported model `%s'" % r_id) RadioError: Unsupported model `TM-D710' ----------------------------

3 13

[chirp_users] [CHIRP] #79: Memory merging and conflict resolution
by CHIRP Tracker 05 Feb '11

05 Feb '11

#79: Memory merging and conflict resolution -------------------------------+-------------------------------------------- Reporter: chirp@… | Type: Feature Status: new | Priority: Functionality Milestone: | Component: Memory Editor Version: | Keywords: Platform: Linux | -------------------------------+-------------------------------------------- I've been looking for a Linux tool that could syncronize my various radios's memories while keeping some data unique. I realize that I can do this manually with CSV files but having this in Chirp would be fantastic. Some ideas for the UI could include: - When a radio's data is downloaded, load it's data into the table but have say the first column naming which radio it came from - When the next radio's data is downloaded, merge that into the table. If a given row is identical from both radios, change the 1st row cell's name to reflect both radios - If a given row (memory slot) are different (conflict), add an additional row reflecting the 2nd radio's name, it's data, and maybe put it in a different color - alternatively, maybe these radios have a unique ID like a serial number, user setable name, etc. so use that - offer a pulldown for this conflict row and ideally REMEMBER this decision (maybe this remembering would be more troublesome than what it's worth): - override the master row - move to memory slot: ### (drag and drop would be slick but that might be hard in Python) - keep unique to this radio - delete The reason for the "keep unique to this radio" would be say on my two D710s, one has an APRS SSID of "KI6ZHD" and another that has "KI6ZHD-9". If I could use this tool to merge data while keeping some settings unique would be ideal. -- Ticket URL: <http://trac.chirp.danplanet.com/trac/ticket/79> CHIRP <http://trac.chirp.danplanet.com/trac> CHIRP Development

1 0

[chirp_users] CHIRP 0.1.11b4
by Dan Smith 05 Feb '11

05 Feb '11

Hi all, I just posted CHIRP 0.1.11b4 with a bunch of changes. This posting includes contributions from Vernon Mauery, Richard Farina, as well as myself. If support for the VX-3R or TH-D72 interests you, be sure to thank these guys :) Changes are: - Fix IC9x detection and baud rate selection - Fix IC9x crashing the whole application - Fix VX-6 not reporting valid tone modes - Fix VX-7 tone field (Richard) - Changes to the status bar text (Richard) - Improved checksum calculation and validation on Yaesu radios - Default VX-7 memory power levels to high (Richard) - Silence the "this will take a long time" warning on file-based radios - Add Kenwood TH-F6A support - Add Kenwood TH-D72 support (Vernon) - Add ICOM IC-2100H support - Add Yaesu VX-3R support (Richard) Like always, I'll be looking for testing and validation of the new drivers listed above, as well, as reports from our model-assigned testers. As a reminder, get the latest beta here: http://chirp.danplanet.com/download/beta Thanks! -- Dan Smith www.danplanet.com KK7DS

5 6

[chirp_users] [PATCH 2/2] add THD-72 splash image manipulation tool
by Vernon Mauery 05 Feb '11

05 Feb '11

This adds a command-line based slash image manipulation tool for the THD-72. It takes as inputs an image file and a NVRAM image and mashes them together so you can upload the modified portions back to the radio and change the two splash screens. This is a useful tool to have until we can come up with a way to integrate this in the GUI. Signed-off-by: Vernon Mauery <vernon(a)mauery.com> --Vernon N7OH

1 0

[chirp_users] [CHIRP] #75: Import poblem between 880H and VX-7R
by CHIRP Tracker 01 Feb '11

01 Feb '11

#75: Import poblem between 880H and VX-7R -----------------------------------+---------------------------------------- Reporter: KN0N@… | Type: Bug Status: new | Priority: Functionality Milestone: | Component: Import/Export Version: | Keywords: Platform: Linux | -----------------------------------+---------------------------------------- 0.1.11.b4 is working very well. I have been running edits and transfers with little issue. I am puzzled why, when editing my 880 image and importing from the VX7 image, some of the 880 memory lines are grayed out. They should be valid and importable. Going the other direction (from 880 file to VX7) Everything looks good, and the D-STAR stuff is the only thing that is (properly)gray. I am attaching my 880 and VX-7 images. Thanks Dan! -- Ticket URL: <http://trac.chirp.danplanet.com/trac/ticket/75> CHIRP <http://trac.chirp.danplanet.com/trac> CHIRP Development

1 7