- Users - lists.chirpmyradio.com

[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

[chirp_users] [CHIRP] #71: CSV Format Mismatch with DV code
by CHIRP Tracker 31 Jan '11

31 Jan '11

#71: CSV Format Mismatch with DV code ---------------------------+------------------------------------------------ Reporter: kk7ds | Owner: Type: Bug | Status: new Priority: Stability | Milestone: Component: Import/Export | Version: Keywords: | Platform: Linux ---------------------------+------------------------------------------------ The CSV header does not include the "code squelch" header for DV mode, and chokes if the (appropriate) trailing comma is included -- Ticket URL: <http://trac.chirp.danplanet.com/trac/ticket/71> CHIRP <http://trac.chirp.danplanet.com/trac> CHIRP Development

1 3

[chirp_users] [CHIRP] #76: Populate blank fields during CSV import
by CHIRP Tracker 31 Jan '11

31 Jan '11

#76: Populate blank fields during CSV import ---------------------+------------------------------------------------------ Reporter: N7SS | Type: Feature Status: new | Priority: Stability Milestone: | Component: Import/Export Version: | Keywords: Platform: Windows | ---------------------+------------------------------------------------------ I have a master spreadsheet I use as a template. I prefer to leave unused fields blank because it's easier to spot errors. This complicates bringing CSV data into Chirp because it allows only some fields to be blank (name, tone mode, duplex, skip, bank, urcall, rtptcall, rpt2call, digital code). Other fields like Tone, ToneSQL, DTCS Code, DTCS Pol, Offset, Tune Step and Bank Index are not always used and could be defaulted to some value if not specified. That would make imports a bit easier. Thanks! -- Ticket URL: <http://trac.chirp.danplanet.com/trac/ticket/76> CHIRP <http://trac.chirp.danplanet.com/trac> CHIRP Development

1 2

[chirp_users] [CHIRP] #74: TSQL and Duplex save setting
by CHIRP Tracker 24 Jan '11

24 Jan '11

#74: TSQL and Duplex save setting ----------------------------------+----------------------------------------- Reporter: TheSndGy@… | Type: Bug Status: new | Priority: Functionality Milestone: | Component: Memory Editor Version: | Keywords: Platform: Windows | ----------------------------------+----------------------------------------- When setting a tone mode of TSQL but leaving Duplex as "None", the file will not save properly; upon opening, the value is set to "-". IC-2820 -- Ticket URL: <http://trac.chirp.danplanet.com/trac/ticket/74> CHIRP <http://trac.chirp.danplanet.com/trac> CHIRP Development

1 3

Re: [chirp_users] Kenwood TH-D72 and Linux
by Vernon Mauery 03 Jan '11

03 Jan '11

On Thu, Dec 16, 2010 at 8:53 AM, Dan Smith <dsmith(a)danplanet.com> wrote: > Hey Vernon, > > Wow, super-awesome. Thanks a bunch :) > >> In the process of trying to understand the radio, I found that I can >> do partial reads and writes. This opens up a lot in the way of faster >> syncing with the radio. I am hoping to find a way to mark blocks of >> the mmap as 'dirty' and only flush those dirty blocks out to the >> radio. > > Hmm, okay, well, that would be pretty different than how most of the > other stuff works. Perhaps you need to model it more as a LiveRadio > than a mmap-ed one. The UI changes behavior in some areas depending on > whether it thinks the radio is live or not (like warning the user about > long-running operations). Well, for now I am just going to leave it as a clone radio. >> In addition, the windows MCP-4A program offers a lot more than just >> editing the memories. I would like to be able to modify some of the >> other behaviors on the radio from the GUI as well. But I am not sure >> UI-wise the best way to go at this. A new tab or a new popup window >> or something. This is still a ways out since I am still trying to >> figure out memory offsets and data formats for all the settings. > > Yeah, so, the thing is: all radios have memories, and they're all fairly > similar. The problem comes when you have a ton of other little > radio-specific things to change that it becomes harder to make the tool > universal. > > I'm definitely not opposed to this, but I think we need to do some > thinking on how best to model it internally. The UI already has > multiple tabs on some of the radios (like the D-STAR radios, for setting > callsigns and stuff). It shouldn't be too hard to do the same for > specific radio features. I agree that some discussion needs to take place. That is one reason I didn't just jump right in. The other is that I don't have much in the way of pygtk know-how. > Maybe we should come up with a subset of non-memory things we want to > support for all radios first? Things like display color, power-off > time, etc? I'm not sure how far down the rabbit hole you want to go :) 1) Compile a list of all the options all the supported radios have 2) Find the subset of common options 3) Come up with a nice UI for that. I think that steps one and two are the ones that will take the most work. >> +CROSS_CODES = [ >> + "DCS->Off", >> + "Tone->DCS", >> + "DCS->CTCSS", >> + "Tone->CTCSS", >> +] > > Hmm, would you consider splitting (or letting me split) the patch into > one for the D72 and one for the "cross code" thing? This version has that split out. > Am I correct in saying that this lets you transmit DCS but receive Tone, > or something like that? Does the MCP call it "cross code"? The MCP interface has a choice of which method to use (Tone/CTCSS/DCS/Cross) and then if Cross is selected, the "Tx Cross Tone" and "Rx Cross Tone" fields are enabled. The manual calls it Cross Mode, so that is what I have altered it to be. >> +# memory channel >> +# 0 1 2 3 4 5 6 7 8 9 a b c d e f >> +# [freq ] ? mode tmode rtone ctone dtcs cmode [offset] ? >> +POS_MODE = 5 >> +POS_DUP = 6 >> +POS_TMODE = 6 >> +POS_RTONE = 7 >> +POS_CTONE = 8 >> +POS_DTCS = 9 >> +POS_CMODE = 10 >> +POS_OFFSET = 11 >> + >> +MEM_LOC_BASE = 0x1500 >> +MEM_LOC_SIZE = 16 >> +MEM_TAG_BASE = 0x5e00 >> +MEM_FLG_BASE = 0x0C00 > > So, you may hate me for this, but I think you might want to take a look > at some of the other radios that I've been porting to a new way of doing > things. > > Look, for example, at the vx8.py driver. I've defined a little > mini-language that lets you define things like you did in the comment > block above, but in a way that lets the code automate a bunch for you. > I haven't converted the V71 driver because I don't own one and don't > want to port it to the new model until I have one handy to test with. > > Anyway, I definitely think it's the "way forward" with this stuff, and > makes the code much smaller and simpler. Not that I wouldn't take the > patch as it is, but at least take a look first and let me know what you > think. I took a look at the vx8 driver and modified the thd72 driver to work with the bitwise parser. It took some time, but since this was the first day of my end-of-the-year holiday, I didn't have anything else to do. It worked out nicely. I used hg record to break apart my changes and then used hg export to create the patch. Is this the preferred method of submission or should I do something else next time? I have never used hg before, so I am breaking new ground all over the place with this project. --Vernon > Otherwise, thanks a ton for doing this work! > > -- > Dan Smith > www.danplanet.com > KK7DS >

2 2

[chirp_users] chirp RPMs for Fedora FC13 and FC14 Available
by Mike Heitmann 03 Dec '10

03 Dec '10

All, If you are running chirp on Fedora Linux, rpm packages are now available in the the d-rats yum repository. (Also known now as the KK7DS-Ham-Apps Software Repository). To set it up, please look at the instructions: http://www.d-rats.com/component/content/article/30-d-rats-yum-repository/ or just install the repository definition rpm by running: rpm --install http://d-rats.com/yum/f11/d-rats-repo-0.1.3-1.fc12.noarch.rpm as root. There are two repositories: KK7DS Ham Apps Software KK7DS Ham Apps Beta Software The chirp beta versions are in the "Beta Software" repository, which is disabled by default. To enable it, go to: System->Administration->Software Sources and check the box next to it. Please note: there are two rpms for each version: one for FC13 (which used python version 2.6) and one for FC14 (the latest Fedora version, which used python 2.7). Please pick the one that matches your system. 73, and enjoy! Mike, N0SO

1 0

[chirp_users] Testing Guidelines
by Dan Smith 30 Nov '10

30 Nov '10

Hi all, Thanks to those who have volunteered to be testers. There are still a bunch of unfilled spots on the list, so please let me know if you're interested in "owning" the testing of one of the drivers: http://chirp.danplanet.com/content/chirp-qa In order to help make the process more consistent, I have put together a page of guidelines and procedures. Included on this page is some general overview information about how CHIRP works and some bug-like behavior to look for specifically. It also has some suggestions for things to try to verify that CHIRP is operating properly for the radio model you're testing. If you are signed up to test a specific model, or are thinking about doing so, please take a look at the following page: http://chirp.danplanet.com/content/testing-guidelines It would be great if the people assigned to specific drivers could go through that document and give me a "thumbs up" or "thumbs down" report on the currently-available beta version. This will get us rolling a bit, and I'm sure will uncover some issues. Thanks! -- Dan Smith www.danplanet.com KK7DS

1 0

[chirp_users] Looking for help testing specific radios...
by Dan Smith 28 Nov '10

28 Nov '10

Hi all, I would like to propose the idea of a formal list of radio testers, to help ensure that future releases of CHIRP go out without significant model-specific regressions. What I would like is one or two volunteers per radio to test beta versions in a timely manner. This would mean that when I post a beta version (or especially right before a regular release), you would test the latest with your assigned radio to make sure that it functions as expected. We could get a "tester's plan" developed with specific things to test each time to make it consistent and meaningful. I would expect a "thumbs up or down" response within, say, a week of posting a new beta version. In return, you would have my (and others') gratitude, a mention on the website as being responsible for "QA" of your model, and hopefully a better tool in the long run as a result. I can't personally purchase and own every model that CHIRP supports. As the list grows, it becomes harder and harder to make changes without knowing if obscure models are being negatively affected. So, any volunteers? Please reply and let me know which radio you'd be willing to help test and I'll get a list started on the website. Thanks! -- Dan Smith www.danplanet.com KK7DS

3 5

[chirp_users] CHIRP 0.1.11b3 (with lots of changes)
by Dan Smith 16 Nov '10

16 Nov '10

Hi all, I just posted 0.1.11b3 with a fairly extensive set of changes. In addition to support for a few new radios, this beta release has a lot of usability and stability fixes. If you haven't tried CHIRP in a while, take a look. If you're good at breaking things, help me out by pointing to what you find. Support for new models: - Add ICOM IC-Q7A support - Add ICOM CI-V radio support and preliminary IC-7200 driver - Hopefully at least IC-7000, IC-706 support coming soon - Add Yaesu FT-7900 support Usability enhancements: - Performance improvements in the memory editor - Import dialog improvements: - Color collisions in yellow - Color invalid locations in red - Grey-out memories that can't be imported into the current model - Better error handling and reporting - Allow multi-select in the memory editor (and thus multi-delete) - Add Edit menu with Cut/Copy/Paste and overwrite notification - Hide more columns when not supported by a given model - Offer radio's supported modes and tone modes in UI - Improve per-radio validation of input Stability/Fixes: - Fix memory editor not actually saving single changes to a memory in some cases - Fix exposing some internal-use column names in View->Columns - Fix open/import of CSV files - Port IC-2200 module to new driver model - Port VX-7 module to new driver model - Port FT-7800 module to new driver model - Fix a 2820 bug after download - Fix VX-8 checksum calculation There are a lot of new features being added here and I want to get them out to "regular users" in a formal release soon. I'd really appreciate some testing of this stuff, even if you report back with what you've done and that "it worked". Thanks! -- Dan Smith www.danplanet.com KK7DS

1 0