- Developers - lists.chirpmyradio.com

[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 14 Apr '11

14 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

Re: [chirp_devel] [PATCH 0 of 3] [RFC] Radio Mods Interface
by Dan Smith 07 Apr '11

07 Apr '11

(pulling the list back into this thread) On 04/06/2011 12:25 PM, Robert Terzi wrote: > Reading between the lines for some of the stuff I've read about > the VX-8R, there was a firmware setting that could be reached > through a service menu/backdoor, which would change the frequency > ranges it would tx on. I believe the purpose was changing > the region. Doing this changed the model number that was > reported by the radio for the clone interface and would cause > all of the settings to be reset (so the radio lost all programming). Are you sure you're not thinking of the VX7? What you describe is exactly how it works for that radio, but the VX8 makes a departure from the three-block protocol that the 7 (and others of that vintage) use. The block missing is the one with the mods in it. Rick did some work on the VX3 trying to figure out the soft mod but I'm not aware that anything ever came of it. Personally, I think its likely that Yaesu didn't carry that "feature" forward past the VX5/7 days. > For what is worth looking at vx6tool.c, the vx6 could be > freebanded by changing two bytes looks like offset 8 & 9. Yep, the 2,5,6, and 7 all have that one block in between the header and the memory data, but the 3 and 8 do not (which is the source of my skepticism) > On whether mods in terms of freebanding should be part of a > general settings interface -- my inclination is to say no, > especially from the user interface point of view. > > Aside from the obvious liability issues, if changing the frequency ranges > causes radios like the vx-8 do a full reset, it would be > problematic for the user, they'd probably have to download > to the radio multiple times, there is currently no backup > or manipulation of the regular settings through chirp. I'd > rather see the frequency range settings done through a separate > UI even though it probably shares most of the code/models of > the radio underneath. Hmm, well, I'm not too worried about the liability issues. I certainly plan to throw up a huge blinking buzzing warning about doing something to your radio that you might regret. I think that it will be fairly easy to re-use the same key/value mechanism underneath the covers without making the UI (for settings and mods) a big mess of knobs. That's what I meant about using this system for generic settings and mods. It will definitely need a little augmentation to allow it to be organized. Thanks for the feedback! -- Dan Smith www.danplanet.com KK7DS

4 8

[chirp_devel] Wouxun OSS software with mods detail
by Robert Terzi 07 Apr '11

07 Apr '11

On 4/6/2011 12:19 PM, Dan Smith wrote: > ... for the VX7 radio (which is, I think, the only one for >which we know about any mods). Don't know if this is a help, if you want another radio to model for mods, there is another piece of open source software, owx, that is available for the Wouxun KG-UV2D & KG-UVD1P which looks like it has some details for frequency range modifications. http://owx.chmurka.net/?p=docs --Rob 6.2. Frequency ranges There are eight values below the channel table. They correspond to the RX and TX ranges on both bands. By editing them, you can unlock your radio (change it's transmit and receive range), but it's easy to kill your radio by setting invalid values. If the ranges are invalid, the rig will refuse to turn on, probably due to busy-waiting for the PLL loop to lock. YOU WILL NOT BE ABLE TO REPROGRAM MEMORY USING ORDINARY CABLE. We've killed one radio this way and in order to bring it back to life I had to open it, disable the MCU (I just disabled it's clock), connect to the memory I2C bus and manually reprogram it. If you lack appropriate equipment or skills you definitely don't want to do this. OWX performs some basic checks on the ranges when importing and warns you if any value seems to be bogus, but it doesn't check the ranges (if you mess with their order). Also, bugs in the importing routine are possible. If you see any warning during importing, consider contacting me before putting the resulting file to the radio, as it is easy to brick the radio and not so easy to bring it back to life. If instead of frequencies you see some hexadecimal values (0xABCD or so) then the decoder (used when exporting) found unexpected pattern and refused to decode the value. Please contact me and provide these raw values. It should be safe to program them back to the radio, but don't change them (they're encoded).

1 1

[chirp_devel] [PATCH 0 of 3] [RFC] Radio Mods Interface
by Dan Smith 06 Apr '11

06 Apr '11

Hi all, This is the (fixed up) RFC mod patch set that I initially started to show Rick. It includes some basic plumbing, UI, and stubs for the VX7 radio (which is, I think, the only one for which we know about any mods). After doing this, I realized that maybe it would be better to not call this a "mod" interface, but more of a general "radio settings" interface, allowing a way to provide radio-specific feature support. For anything that is common across models, I'd still like something formalized like everything else, but this could be a way to support one-offs. Thoughts? --Dan KK7DS

1 3