- Developers - lists.chirpmyradio.com

[chirp_devel] CSV Power Levels
by Dan Smith 10 May '11

10 May '11

Hi all, I thought I'd post an RFC patch for supporting power levels in the CSV driver for some discussion. The lack of this feature is an oft-mentioned item with folks. I think the commit message covers the details, but let me know if you have any questions. I'm hoping to get some ACK/NAK or discussion about this before I put it into the tree. Thanks! -- Dan Smith www.danplanet.com KK7DS

1 0

[chirp_devel] Couple small patches for Wouxun
by Louie Ilievski 03 May '11

03 May '11

All, I've attached a couple changes for Wouxun. The first change defines the busy channel lockout bit in the memory map and defaults it to being off (I was annoyed on a road trip this weekend when I discovered some of the channels I had recently programmed had it enabled which can make talking on repeaters a pain). There is no column yet for this and I didn't find any other supported radio at a glance that had a similar feature so I figured for now it was best to just give it a default and if we want to support it in the UI at some point then it can be updated. The other change just fixes the character set to include the few supported special characters at the end instead of all question marks. Memory channel names that I had programmed directly into the radio with spaces were being imported into CHIRP with question marks in place of the spaces. Thanks, ~Lou

2 1

[chirp_devel] FYI: KC8UNJ commander software now supports Wouxun. KG-UV[123]
by Robert Terzi 02 May '11

02 May '11

It was announced on the Wouxun yahoo group list that the KC8UNJ Commander software now has a version for wouxun KG-UV[123] This is free software, but not open source, and is windows only. Someone mentioned it's implemented in Visual basic, which I don't know if that's correct or not. I mention it here as a somewhat mild FYI. KC8UNJ's commander software is available for radios from Yaesu, ICom, and now Wouxun. However, there are separate packages for each radio, and per radio specific formats. At least according to the read-me even the csv is considered radio specific. It does support importing/exporting the .tw files that the wouxun supplied software uses. I don't know if there is anything useful to learn from the software. I was hoping it might have something to learn from in terms of cross radio file format, but that doesn't appear to be the case. As far as I've seen Chirp seems to be leading the way. --Rob

1 0

[chirp_devel] Two patches for Kenwood TM-D710
by Tom Hayward 02 May '11

02 May '11

After programming my D710 with Chirp I noticed neither memory lockout ("skip") or odd-splits were working. Turns out these two features were just never implemented--until now! Attached are two patches (apply in order, please). The first adds Skip support, the second adds odd-split support. I'm not 100% happy with my implementation of odd-split support. Because the TM-D710 is implemented as a KenwoodLiveRadio, the memory is written to the radio each time a field is changed. If duplex is changed to "split", it tries to save 0.600 (the default offset) as the TX frequency, before the user has entered the actual TX frequency. To workaround this behavior, my code sets the TX freq to 0 if the offset is < 136 MHz (this seems to be the lowest TX freq the D710 will accept. The opposite is true when changing and odd-split back to None, + or, - (I send an offset of 0 to the radio when the offset is >= 136). It seems like a bad idea to write zeros to the radio, but I couldn't find a way to keep Chirp UI from saving to the radio on every field change. Tom KD7LXL

2 3

[chirp_devel] Automated Tests
by Dan Smith 01 May '11

01 May '11

Hi all, After some prodding by Robert, I have finally started on some automated tests for CHIRP. These are aimed at testing the clone-mode radio drivers, but could be selectively enabled to work against the live mode ones as well (hardware-permitting). The current set of tests only exercise the drivers themselves (not the UI). I would have sent this to the list as a patch for review, but I needed to include a bunch of binary radio images, so I just committed it to the tree. Comments are welcome. If you were looking for some work to do on CHIRP but hadn't found a spot to start yet, this is your opportunity. Since the images are in the tree, you could potentially fix bugs reported by the tests for models you don't even have. The flurry of commits this morning have been for things that I found along the way. There are still a bunch of them to be fixed, and most look fairly simple (typos, off-by-one errors, etc). To run them, grab an updated version of the mercurial tree (these won't be in the tarballs) from here: http://d-rats.com/hg/chirp.hg Then go into the tests/ directory and run the script: $ ./run_tests You should see a bunch of reports start to fly by. Logs for crashes and certain types of failures are left in the logs/ directory. You can run tests against a single driver by putting its id (from the directory) on the command line: $ ./run_tests vx7 The current report of bugs is below. If you have questions or comments, let me know. Thanks! -- Dan Smith www.danplanet.com KK7DS > Icom ID-800H v2 CopyAll PASSED: All tests > Icom ID-800H v2 BruteForce PASSED: All tests > Icom ID-880H CopyAll PASSED: All tests > Icom ID-880H BruteForce PASSED: All tests > Icom IC-2820H CopyAll PASSED: All tests > Icom IC-2820H BruteForce PASSED: All tests > Icom IC-2200H CopyAll FAILED: <125>: Field `offset' is `0.48', expected `0.6' > Icom IC-2200H CopyAll FAILED: <127>: Field `offset' is `0.48', expected `0.6' > Icom IC-2200H BruteForce PASSED: All tests > Icom IC-V82/U82 CopyAll PASSED: All tests > Icom IC-V82/U82 BruteForce PASSED: All tests > Icom IC-2100H CopyAll PASSED: All tests > Icom IC-2100H BruteForce PASSED: All tests > Icom IC-2720H CopyAll PASSED: All tests > Icom IC-2720H BruteForce PASSED: All tests > Icom IC-Q7A CopyAll FAILED: <100>: Field `freq' is `851.012', expected `851.0125' > Icom IC-Q7A CopyAll FAILED: <101>: Field `freq' is `851.512', expected `851.5125' > Icom IC-Q7A CopyAll FAILED: <102>: Field `freq' is `852.012', expected `852.0125' > Icom IC-Q7A CopyAll FAILED: <103>: Field `freq' is `852.512', expected `852.5125' > Icom IC-Q7A CopyAll FAILED: <104>: Field `freq' is `853.012', expected `853.0125' > Icom IC-Q7A CopyAll FAILED: <106>: Field `freq' is `851.387', expected `851.3875' > Icom IC-Q7A CopyAll FAILED: <110>: Field `freq' is `852.537', expected `852.5375' > Icom IC-Q7A CopyAll FAILED: <111>: Field `freq' is `852.562', expected `852.5625' > Icom IC-Q7A CopyAll FAILED: <112>: Field `freq' is `852.587', expected `852.5875' > Icom IC-Q7A CopyAll FAILED: <113>: Field `freq' is `852.612', expected `852.6125' > Icom IC-Q7A CopyAll FAILED: <114>: Field `freq' is `852.637', expected `852.6375' > Icom IC-Q7A CopyAll FAILED: <115>: Field `freq' is `453.212', expected `453.2125' > Icom IC-Q7A CopyAll FAILED: <116>: Field `freq' is `453.462', expected `453.4625' > Icom IC-Q7A CopyAll FAILED: <117>: Field `freq' is `453.712', expected `453.7125' > Icom IC-Q7A CopyAll FAILED: <118>: Field `freq' is `453.862', expected `453.8625' > Icom IC-Q7A CopyAll FAILED: <125>: Field `freq' is `151.137', expected `151.1375' > Icom IC-Q7A CopyAll FAILED: <127>: Field `freq' is `158.737', expected `158.7375' > Icom IC-Q7A CopyAll FAILED: <129>: Field `freq' is `860.737', expected `860.7375' > Icom IC-Q7A CopyAll FAILED: <130>: Field `freq' is `860.237', expected `860.2375' > Icom IC-Q7A CopyAll FAILED: <131>: Field `freq' is `859.737', expected `859.7375' > Icom IC-Q7A CopyAll FAILED: <132>: Field `freq' is `859.737', expected `859.7375' > Icom IC-Q7A CopyAll FAILED: <133>: Field `freq' is `858.237', expected `858.2375' > Icom IC-Q7A CopyAll FAILED: <134>: Field `freq' is `857.237', expected `857.2375' > Icom IC-Q7A CopyAll FAILED: <135>: Field `freq' is `856.237', expected `856.2375' > Icom IC-Q7A CopyAll FAILED: <136>: Field `freq' is `855.962', expected `855.9625' > Icom IC-Q7A CopyAll FAILED: <137>: Field `freq' is `855.237', expected `855.2375' > Icom IC-Q7A CopyAll FAILED: <138>: Field `freq' is `854.987', expected `854.9875' > Icom IC-Q7A BruteForce PASSED: All tests > Icom IC-W32A VHF CopyAll FAILED: <88>: Field `mode' is `FM', expected `AM' > Icom IC-W32A VHF CopyAll FAILED: <89>: Field `mode' is `FM', expected `AM' > Icom IC-W32A VHF CopyAll FAILED: <90>: Field `mode' is `FM', expected `AM' > Icom IC-W32A VHF CopyAll FAILED: <91>: Field `mode' is `FM', expected `AM' > Icom IC-W32A VHF CopyAll FAILED: <92>: Field `mode' is `FM', expected `AM' > Icom IC-W32A VHF CopyAll FAILED: <93>: Field `mode' is `FM', expected `AM' > Icom IC-W32A VHF CopyAll FAILED: <125>: Field `tuning_step' is `5.0', expected `12.5' > Icom IC-W32A VHF CopyAll FAILED: <127>: Field `tuning_step' is `5.0', expected `12.5' > Icom IC-W32A VHF BruteForce FAILED: Field `mode' is `FM', expected `AM' > Icom IC-W32A UHF CopyAll FAILED: <115>: Field `tuning_step' is `5.0', expected `12.5' > Icom IC-W32A UHF CopyAll FAILED: <116>: Field `tuning_step' is `5.0', expected `12.5' > Icom IC-W32A UHF CopyAll FAILED: <117>: Field `tuning_step' is `5.0', expected `12.5' > Icom IC-W32A UHF CopyAll FAILED: <118>: Field `tuning_step' is `5.0', expected `12.5' > Icom IC-W32A UHF BruteForce FAILED: Field `mode' is `FM', expected `AM' > Icom IC-T70 CopyAll FAILED: <115>: Field `freq' is `453.21', expected `453.2125' > Icom IC-T70 CopyAll FAILED: <116>: Field `freq' is `453.46', expected `453.4625' > Icom IC-T70 CopyAll FAILED: <117>: Field `freq' is `453.71', expected `453.7125' > Icom IC-T70 CopyAll FAILED: <118>: Field `freq' is `453.86', expected `453.8625' > Icom IC-T70 CopyAll FAILED: <125>: Field `freq' is `151.135', expected `151.1375' > Icom IC-T70 CopyAll FAILED: <127>: Field `freq' is `158.735', expected `158.7375' > Icom IC-T70 BruteForce PASSED: All tests > Yaesu VX-3 CopyAll PASSED: All tests > Yaesu VX-3 BruteForce FAILED: Field `name' is ` ', expected `' > Yaesu VX-5 CopyAll PASSED: All tests > Yaesu VX-5 BruteForce FAILED: Field `ctone' is `67.0', expected `88.5' > Yaesu VX-6 CopyAll PASSED: All tests > Yaesu VX-6 BruteForce FAILED: Field `rtone' is `88.5', expected `67.0' > Yaesu VX-7 CopyAll PASSED: All tests > Yaesu VX-7 BruteForce FAILED: Field `ctone' is `67.0', expected `88.5' > Yaesu VX-8 CopyAll PASSED: All tests > Yaesu VX-8 BruteForce FAILED: Field `ctone' is `67.0', expected `88.5' > Yaesu FT-7800 CopyAll PASSED: All tests > Yaesu FT-7800 BruteForce FAILED: Field `freq' is `108.0925', expected `108.1' > Yaesu FT-8800 Left CopyAll PASSED: All tests > Yaesu FT-8800 Left BruteForce FAILED: Field `name' is ` ', expected `' > Yaesu FT-8800 Right CopyAll PASSED: All tests > Yaesu FT-8800 Right BruteForce FAILED: Field `name' is ` ', expected `' > Yaesu FT-8900 CopyAll PASSED: All tests > Yaesu FT-8900 BruteForce FAILED: Field `name' is ` ', expected `' > Alinco DR235T CopyAll PASSED: All tests > Alinco DR235T BruteForce PASSED: All tests > Jetstream JT220M CopyAll PASSED: All tests > Jetstream JT220M BruteForce PASSED: All tests > Wouxun KG-UVD1P CopyAll PASSED: All tests > Wouxun KG-UVD1P BruteForce FAILED: Field `offset' is `0.0', expected `0.6'

1 0

[chirp_devel] duplex split
by Tom Hayward 01 May '11

01 May '11

In the memory editor, when choosing "split" for the duplex mode, how do I enter the TX frequency? I'm looking at the Memory class and it's not apparent how odd splits are stored. I'm trying to fix odd splits for the Kenwood D710. Currently the TX frequency is hard-coded to 0 (meaning that odd splits are not supported, I guess). It should be simple to update the D710 mem spec to support odd splits, I just don't know where to read the TX freq from. Tom KD7LXL

2 1

Re: [chirp_devel] [chirp_users] New Daily Build
by Tom Hayward 01 May '11

01 May '11

> changeset: 921:35826dd1552d > user: Dan Smith <dsmith(a)danplanet.com> > date: Sat Apr 30 11:49:06 2011 -0700 > files: chirpui/mainapp.py > description: > Move import and export to the File menu Oops, I found a dialog that still refers to Export under the Radio menu. Patch attached. Tom KD7LXL P.S. Hope these one-word patches don't annoy you :)

2 1

[chirp_devel] [PATCH] Detect all OS X serial ports, not just FTDI serial ports.
by Tom Hayward 01 May '11

01 May '11

This bug was mentioned last week in http://intrepid.danplanet.com/pipermail/chirp_users/2011-April/000744.html. I noticed that it had not been fixed as of last night's daily build, so here's a patch. The problem is that chirp was only looking for /dev/cu.usbser*. The OS X FTDI driver puts devices at /dev/cu.usbserial*, but other drivers use different names, such as /dev/cu.pl2303*, /dev/cu.SLAB_USBtoUART, etc. I have not fixed the other bug mentioned in that archive message (chirp not detecting returned ID properly when returned by TH-D72 in OS X). Tom KD7LXL

2 1

[chirp_devel] Icom IC-80AD - diffs and additional file
by Andrew Hart 26 Apr '11

26 Apr '11

I have modified the code to allow Chirp to read and programme the IC-80AD radio. Below are three unix style diffs for the files mainapp.py, directory.py and convert_ICF.py The first line in each case is the new code, and the second line the old code ( I had my diff programme working backwards it appears!) mainapp.py =========== 37c37 < from chirp import icf, ic9x_icf, ic80ad --- > from chirp import icf, ic9x_icf ============== directory.py ============== 19c19 < from chirp import id800, id880, ic2820, ic2200, ic9x, icx8x, ic2100, ic2720, ic80ad --- > from chirp import id800, id880, ic2820, ic2200, ic9x, icx8x, ic2100, ic2720 45d44 < "ic80ad" : ic80ad.IC80ADRadio, ============= convert_ICF.py ============= 2c2 < from chirp import id800, ic2820, ic2200, icx8x, id880, id80ad --- > from chirp import id800, ic2820, ic2200, icx8x, id880 13d12 < ic80ad.IC80ADRadio ============= It can be seen that the additions were trivial in these files, just adding the ic80ad. Then a new file ic80ad.py is required (based on the essentially identical ID880) The diffs between the new ic80ad.py and the ID880.py are ic80ad.py ============ 132c132 < class IC80ADRadio(icf.IcomCloneModeRadio, chirp_common.IcomDstarSupport): --- > class ID880Radio(icf.IcomCloneModeRadio, chirp_common.IcomDstarSupport): 134c134 < MODEL = "IC-80AD" --- > MODEL = "ID-880H" 136c136 < _model = "\x31\x55\x00\x01" --- > _model = "\x31\x67\x00\x01" 370,371c370,371 < class IC80ADRadio(IC80ADRadio): < MODEL = "IC80AD" --- > class ID80Radio(ID880Radio): > MODEL = "ID-880H" ============= again quite trivial changes, the main one being the radio ID. The memory format fortunately being identical between these two radios. I have not yet thoroughly tested this, but I have downloaded into Chirp the memory data from the radio, edited it, sent it back to the radio, and then reviewed with the Icom CS80 programme, and all seemed fine. Additional testing is of course required. What I have noted is that the IC-80AD radio must be set for 9800 baud in the SET>func>speed menu item. If it is at 4800, as a GPS connected to the same port would use, Chirp does not yet recognise the radio and errors. It should be relatively easy to try both speeds in a future version. Further, when downloading or uploading back into the radio the data rate remains at 9600 and does not speed up as it appears it should, and as does happen with the Icom programme. This means that the data transfer takes several minutes with Chirp. Perhaps I missed something in the code, as I did not take a great deal of time looking. The code for the European version of the radio should be almost identical, or will be identical depending on whether the radio ID is different between the EU and NA radios. The ID as can be seen in the diff above for the NA version, the IC-80Ad is 31 55 00 01 I found it useful to use the trial version of "device monitoring studio" from HHDsoftware (it only runs for 15 days in the trial mode), to examine all of the USB transaction data, as I was using a USB-serial interface cable. All was tested on a Windows 7 64 bit computer, with the native python .py code and not compiled to byte code, as python will work like this, and makes for easier testing. Feedback welcome cheers Andrew Hart C.Eng. MRINA amateur radio calls G8VTV / VE3NVK locator FN25bh The content of this message is *NOT* intended for the public, and is a private communication.

2 3

[chirp_devel] Patch for Wouxun Power Level Support
by Louie Ilievski 15 Apr '11

15 Apr '11

Hi all, I don't know what the preferred method of submitting patches is but I just created an hg diff in this instance. Let me know if a different way is preferred. This patch adds power level support to the Wouxun radios. I tested it on my KG-UV3D. I will be adding more features over time but this one was higher on my list. Thanks, ~Lou

2 1