November 2008 - Users - lists.chirpmyradio.com

Re: [chirp_users] csv format
by David Tilson 30 Nov '08

30 Nov '08

G'day Dan, > Dave is working on a > detailed description of the CSV file which might be helpful: > > http://chirp.danplanet.com/wiki/DataModel When you get a chance, could you please check it for accuracy, particularly the Allowed Values column. I think there probably still needs some refinement. One thing that needs to be checked is to whether or not all of the radios can accept both Upper and Lower case characters in the Name field. I have a feeling that the ID-800H can only accept upper case characters, but I'm not sure. If it is correct then the DataModel will need to be updated to reflect this. Also, if that's correct, then what will happen if someone tries to import a .chirp or .csv file that has mixed case names??? Cheers, Davidt, VK3UR

2 1

[chirp_users] csv format
by joe camilli 30 Nov '08

30 Nov '08

Hello all, I have 2200h and was looking for a way to program the memories via a program. What is the layout of the csv file ? _________________________________________________________________ Proud to be a PC? Show the world. Download the “I’m a PC” Messenger themepack now. hthttp://clk.atdmt.com/MRT/go/119642558/direct/01/

2 2

[chirp_users] CHIRP 0.1.8b5
by Dan Smith 30 Nov '08

30 Nov '08

Hi all, I just posted 0.1.8b5 with the following changes: - Fixed up some of the callsign programming logic on 800, 2200, x82 - Added SKIP and bank information to CSV and Chirp files - Added CSV header check on import/open - Added error messages for any bad CSV data - Improve thread performance when using 9x radios - Added bank name editor for 2820 and 9x radios - Changed the display of callsigns in the memory editor to use fixed-width fonts for better alignment - Added View->Columns selection to allow limiting the view to only columns of interest Note that this change breaks the schema for the .chirp files from previous releases. In doing so, it also adds a version number so that hopefully we can tolerate changes like this in the future with more grace :) I think this is pretty much where we need to be, feature-wise. If anyone finds any (new) bugs, please let me know. Otherwise, I think I'd like to call this the official 0.1.8 and move on to some of the other GUIish features we've been discussing. Thanks! -- Dan Smith dsmith#danplanet.com, s/#/@/ www.danplanet.com KK7DS

1 0

[chirp_users] FW: chirp burp
by Dave Cooley 26 Nov '08

26 Nov '08

PREFACE: This is a follow up to previous post regarding missing memory channels using CHIRP. Okay after some exhaustive testing I have found what happens to some channels that previously were thought to be missing. I sorted by channel name to alphabetize them. I then tried to renumber them according to the new alphabeticall sort. When I entered a channel number already in use chirp deletes the old channel entry entirely. The goal is to renumber the channels by the slected sort. In otherwords download the radio sort by whatever field you desire the channel numbers should reamain intact i.e. 1,2,3,4, etc. They do not . They stay with the channel they were associated with from the radio. This is nice for viewing but accomplishes nothing if you want to program the radio with the new layout as it will write the channels with the original channel numbers and that is the default that the radio uses to pull them up. So no matter how you sort them, when you re-write to the radio it it is the same as before. I hope this makes sense. Happy Thanksgiving Dave Cooley N4DIB 1007 Centerbrook Drive Brandon, Florida 33511

1 0

Re: [chirp_users] CSV Import
by David Tilson 26 Nov '08

26 Nov '08

G'day Dan, > Dave T, you're a heavy CSV user... What would you think about > adding that to the CSV load logic? Probably a good idea, particularly while the file structure is expanding / changing on a regular basis and there is the likelihood that people have older version csv files. Currently if there is a new field I perform an export to csv and then manually compare the file structure and then make whatever changes are necessary. What would probably be even more useful (IMHO) would be to publish on the wiki a simple data model that shows each of the fields, syntax, acceptable values (and whether they are generic or radio specific), as well as any default values (if no entry made). This would help reduce errors made by people manually editing any of the files. I can probably assist, if no one else wants to, with putting together a draft (after the Xmas lights are up and running) but would need you to vet the data/format for accuracy. Cheers, Davidt, VK3UR

2 1

[chirp_users] CSV Import
by Dave Cooley 26 Nov '08

26 Nov '08

Not having much luck importing csv into Chirp using the import feature (although it is much easier to find the file now with the selectable dropdown) Here is a copy of the csv file. Can someone see what is wrong? This file was created from chirp as an export. Thanks Dave Cooley N4DIB

2 4

[chirp_users] CHIRP 0.1.8b4
by Dan Smith 24 Nov '08

24 Nov '08

Hi all, I just posted version 0.1.8b4 with the following changes: - Added real IC-V82 support - Added ability to convert a .ICF file to a .IMG file - Make File->Open browse box have appropriate filters - Add bank support to all radios Note that the ICF conversion only works for the clone-style radios, so it won't work on an ICF from RS-91 or RS-92. It has only had minimal testing, but seems to work for me. I still haven't made a decision on what to do on the filter issue for the export box, so no change has been made to this yet. The bank support seems to work for me. I don't have a GUI yet for setting the bank names on the 2820, 91, or 92. I'll get to it, but this should work for now. I didn't (remember to) add the skip flag into the CSV file, nor have I added the bank stuff yet. I haven't settled on the internal representation for the latter, and don't want to expose an external interface for it until I do. Oh, and neither skip nor bank info is in the .chirp file yet either :) -- Dan Smith dsmith#danplanet.com, s/#/@/ www.danplanet.com KK7DS

1 1

Re: [chirp_users] CHIRP 0.1.8b3
by David Tilson 24 Nov '08

24 Nov '08

G'day Dan, > Let me do the bank stuff for all the radios first, as I think > that's an > important piece of functionality. Once that's done, we can dig into > making the GUI more useful. How does that sound? That sounds great. Thanks Dan. Cheers, davidt

1 0

Re: [chirp_users] CHIRP 0.1.8b3
by David Tilson 24 Nov '08

24 Nov '08

> I bet VK3UR does a lot of sorting with radios packed to the > gills with memory locations. Dave, have you ever seen > memories fall out of the view when sorting by column? Nope, never seen the problem. I will qualify this though by saying 99% of the time I export the files to CSV, manipulate / sort with a text editor (or Excel) and then import back into the radio. Cheers, Davidt, VK3UR

3 5

Re: [chirp_users] CHIRP 0.1.8b3
by David Tilson 24 Nov '08

24 Nov '08

G'day Dan, > What features and behaviors does the chirp editor need to > have to make it equally or more useful than taking it out > into excel and back? As I think you know, I currently produce a bunch of configuration files for just about all of the Australian D-STAR 2m and 70cm repeaters. By exporting the memory information from my primary configuration file to csv format I can then perform a block / replace on large chunks of memories in the Freq, Offset, Tstep and RPT1 and RPT2 fields, which can then be imported back into the radio. CHIRP in its current format, using Export / Modify / Import, makes that a relatively simple process compared to editing one line at a time through the GUI. > Excel is pretty complex and powerful, so making chirp able to > rival the functionality may not be feasible, but it's a > worthwhile discussion, I think. Agreed. I have no perspective as to whether there are many others trying to do similar things to me, so I wouldn't suggest putting in a whole heap of effort if I'm the only one with this need. However... If you were to go down this path... One solution might be to be able to "tag" each of the memories to be changed, choose which field to have its data modified and have a field that can then have the new value entered into it. It still might be a bit kludgy if this has to be done each time, so it would be better still if the tagged entries could be remembered to simplify future editing. I think this would be great if not too difficult... Cheers, Davidt, VK3UR

2 1