April 2011 - Developers - lists.chirpmyradio.com

[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

[chirp_devel] Testing & Development
by Mathew Mrosko 05 Apr '11

05 Apr '11

Dan, I'm a software engineer and amateur radio operator. I found your software when searching for an alternative to the monstrosity that is MCP-2A to program my TM-V71A after using the great VX-7 Commander software for my HT. I was so disappointed with the MCP-2A that I was pleased to an alternative and even more pleased that it works with my VX-7R as well. I'd like to contribute in my free time, which is admittedly sparse. I was wondering if you're welcoming contributors and if you had any accessible revision control so I can work from the latest and greatest when submitting patches. Even if it's read-only, I'd prefer to work with the latest code. I will be using linux, but will probably try to test any changes on windows before submitting any patches for you to review. For now, the things I think I'll work on will be: * Inserting CB/FRS/GMRS frequencies (like vx-7 commander) - This is handy, and while I have it set up for my radios already, it is incomplete. I'd like to add optional lists for the "Privacy Settings" of different manufacturers and have the PL in the list * "Move up"/"Move down" buttons (like vx-7 commander) - This is good for moving frequencies without having to "copy", "delete (and move up)", "insert", "paste". * "1-step convert" (read from radio type A, "convert", write to radio type B) - I have two manufacturers of radio, and while chirp handles both, it only handles both somewhat separately. I'd like to be able to maintain 1 file, and just write to both radios. * Toggle for Kenwood's "live" mode - If I want to "work later", I have to read, export to chirp native, work on that file, re-read, then import. I'd much rather simply read, save to an img, work on that, write. Or, my with the "1-step convert" option, have 1 file that I maintain with my frequencies that I can then easily write to multiple differing radios. * Special settings for radios - Have a "settings" screen for things specific to each radio that is supported. Things like what are available in VX-7 Commander for software free-banding the radio, setting the current mode, aro, vox, etc. I have never done any GUI programming but wrote a lot of python 6+ years ago. I'm looking at this to be a learning experience too and will probably be slow to actually get anything done (lack of free time, and unfamiliar code/tasks). Do you have any feedback, advice, opinions on any of the items in my list? Something you would like to see first? Things already done? Things not possible due to some technical reason? I also imported the last few versions you've released into a git repository and posted it on github.com which I will use as my starting point unless you have some place else I can easily get the source. It can be found at https://github.com/Materdaddy/CHIRP Thanks/73s Mat WD4DDY

3 2