- Developers - lists.chirpmyradio.com

[chirp_devel] VX5 scan edge special channels # 5187
by Richard Birch 01 Oct '17

01 Oct '17

Here is a patch at add scan edge special channels to the VX5

2 1

[chirp_devel] revert #4687
by SASANO Takayoshi 01 Oct '17

01 Oct '17

# HG changeset patch # User SASANO Takayoshi <uaa(a)mx5.nisiq.net> # Date 1504671405 -32400 # Wed Sep 06 13:16:45 2017 +0900 # Node ID 046007af2cb248ae8933f78d5f14dd55b8ae9ee8 # Parent c56244c58fe85688ef0da20a3f7bfebc0f447e6c revert #4687 Different from OpenBSD-6.0, OpenBSD-6.1 is no longer required this modification. And, this cause #5007 bug. Revert to 2715:d1bc2c917785. diff -r c56244c58fe8 -r 046007af2cb2 chirp/drivers/icf.py --- a/chirp/drivers/icf.py Mon Jul 10 17:45:50 2017 -0400 +++ b/chirp/drivers/icf.py Wed Sep 06 13:16:45 2017 +0900 @@ -198,8 +198,6 @@ pass pipe.write(frame) - pipe.flush() - pipe.read(len(frame)) # discard echoback return frame @@ -263,7 +261,6 @@ LOG.debug("Starting HiSpeed Clone:\n%s" % util.hexprint(buf)) radio.pipe.write(buf) radio.pipe.flush() - radio.pipe.read(len(buf)) # discard echoback def _clone_from_radio(radio):

2 1

[chirp_devel] [PATCH] Minor update to support RTX Radioddity QB25 (a QYT KT7900D clone) - fix for Issue Number #5135
by Attilio Pier Paolo Pannella 30 Sep '17

30 Sep '17

Dear all, as I could not have Chirp recognizing my Radioddity QB25 (a clone of QYT KT7900D), I found out that the problem was in the identification string. I therefore release a patch to have this problem fix. The Radioddity QB25 is now supported through the QYT KT7900, but it also have a proper entry into the Vednor/Model list (Radioddity/QB25). I hope this is helpful! 73 de DL1UNX - Attilio

1 0

[chirp_devel] Fixed Frequency Radio
by Jim Unroe 19 Sep '17

19 Sep '17

All, I have a radio coming to me in the near future that will have something like 15 fixed simplex frequencies. In other words, the RX/TX frequencies cannot be changed. CHIRP will only be required to program the other per channel settings like CTCS, DTCS, Power, Skip and the like. Does anyone know if there is a provision in CHIRP that will show the frequencies of the memory rows (or range of memory rows) but displays them as un-editible fields? Thanks, Jim KC9HI

2 11

[chirp_devel] Questions about "Special Channels" especially WRT Yaesu FT1D/FT2D
by NNN Wx 17 Sep '17

17 Sep '17

When I look at a chirp “Memories” window, there’s a button called “Special Channels” which AFAICT does exactly nothing for my FT2D. I can find no description in the Wiki of the “Special Channels”. I AM ONLY IMAGINING WHAT THESE COULD BE, but I have some thoughts. - The FT2D has several sets of preset channels: international VHF Marine, worldwide broadcasts, NOAA weather channels. That’d be perfect for “Special Channels”, although they are supposed to be read-only [but they have locations in the FT2D memory image, so it’s not unlikely that chirp can read AND write these locations.] Of course, it’d be illegal and impolite to try to TRANSMIT to those frequencies, so I may want to find a “do not transmit” flag to go with them. - The FT2D has a subset of the memory locations that can only hold “skip” frequencies: whenever a scan is enabled, if the frequency matches a skip frequency that frequency is not used. These locations ARE programmable and contiguous with regular memory; at present, I’ve implemented them as memory locations that are forced to have a “Skip” flag. So, please, dear developer experts: Where are the “Special Channels” documented? How does chirp access and define the “Special Channels”? What data structures and methods are needed to implement them? Would either (or both?) of the two above sets of locations be appropriate for inclusion as “Special Channels”? Did I miss “Special Channels" in the underlying FT1D driver that I’m using to implement FT2D? These questions are prompted by a preliminary bug report; one user seems to have used the FT2D to enter a preset channel into a memory bank, after which chirp refuses to edit the whole bank! I’ll be submitting a bug report Real Soon Now since it’s clearly a feature that the radio can handle. I’d hope to have a fix researched and suggested shortly thereafter. Declan WD5EQY

1 0

[chirp_devel] Wouxum Radios
by dropkick23＠gmail.com 25 Aug '17

25 Aug '17

see attached file.

2 1

[chirp_devel] Wouxun KG-UV8E
by D.J.J. Ring, Jr. 23 Aug '17

23 Aug '17

Some people added a bounty to getting the Wouxun KG-UV8E working under CHIRP. It's a very good radio, WOUXUN customer service is horrible, I've had two former radio officer friends of mine from Hong Kong email Wouxun in an attempt to get them to cooperate with CHIRP developers. No answer. Stupid idiots. I have a unit, my neighbor has one, and several people have offered some cash. One is Dan Lott. You have to find the Wouxun Software for this with version above 1.0 as that's Chinese language only. A USA site has it and I'm pasting the links here. The Zipped file is RAR'd and not zipped. *Wouxun KG-UV8E* Tri Band Software Zipped <http://www.mtcradio.com/content/softwaredownloads/KG-UV8E%20zip.rar> Direct Download <http://www.mtcradio.com/content/softwaredownloads/KG-UV8E%20----%20setup.exe> *Wouxun KG-UV8E* Tri Band Freq Expansion Zipped <http://www.mtcradio.com/content/softwaredownloads/KG-UV8E%20Frq%20Limit%20s…> Direct Download <http://www.mtcradio.com/content/softwaredownloads/KG-UV8E%20Frq%20Limit%20s…> It's a really good radio and has a very good triband antenna. I'm just posting once to see if I can get anyone interested. Thanks for all your efforts with CHIRP, I love your program and recommend it to all. 73 David J. Ring, Jr., N1EA

1 0

[chirp_devel] latest build
by dropkick23＠gmail.com 21 Aug '17

21 Aug '17

The latest build was over one month ago.

2 1

[chirp_devel] Patch that updates desktop entry file (Linux)
by Patrik Nilsson 19 Aug '17

19 Aug '17

# HG changeset patch # User Patrik Nilsson <asavartzeth(a)gmail.com> # Date 1502892912 -7200 # Wed Aug 16 16:15:12 2017 +0200 # Node ID 49c7636445b4ec7a9ad101ca99b294f3e4ff8bde # Parent c56244c58fe85688ef0da20a3f7bfebc0f447e6c Fix Linux/Unix desktop entry file Fixes #5075 #3491 - Update "Version" to 1.0 - Fix "GenericName" not being generic - Fix "Comment" being redundant with "GenericName" and wrong format - Fix hard-coded icon extension - Fix "Categories" using incorrect non-existing main category "Application", using "Utility" instead. - Add ability to open files with chirpw (based on Debian patch) - Add several "Keywords" for discoverability Fixing the hard-coded icon enables theming and is a pre-requsite for adding a scalable icon and/or icons of different sizes. It should also resolve bug #3491. The latest version of the Freedesktop specification can be found at: https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-lat… A table of acceptable main categories can be found at: https://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#category-reg… diff -r c56244c58fe8 -r 49c7636445b4 share/chirp.desktop --- a/share/chirp.desktop Mon Jul 10 17:45:50 2017 -0400 +++ b/share/chirp.desktop Wed Aug 16 16:15:12 2017 +0200 @@ -1,13 +1,13 @@ [Desktop Entry] -Version=0.1 -Encoding=UTF-8 Type=Application -Exec=chirpw -Icon=chirp.png +Version=1.0 +Name=CHIRP +GenericName=Radio Programming Tool +Comment=Program amateur radios +Icon=chirp +Exec=chirpw %F +Terminal=false +MimeType=inode/directory +Categories=Utility;HamRadio +Keywords=Hamradio;Programming;Handheld;Radio;Amateur;Programmer StartupNotify=true -Terminal=false -Categories=Application;HamRadio -MimeType=inode/directory -Name=CHIRP -Comment=CHIRP Radio Programming Tool -GenericName=CHIRP Radio Programming Tool

2 2

Re: [chirp_devel] [chirp_users] Yaesu ft-2900
by Tom Hayward 25 Jul '17

25 Jul '17

On Sun, Jul 23, 2017 at 4:15 AM, Jim Unroe <rock.unroe(a)gmail.com> wrote: > CHIRP supports the USA version of the FT-2900 (FT-2900R). It does not > currently support the FT-2900E (European version) or an FT-2900 that > has the MARS modification. This seems wrong to me. Is there anything different about the versions other than the region code? Looking at the driver, I think not... http://chirp.danplanet.com/projects/chirp/repository/entry/chirp/drivers/ft… Both IDBLOCKs start with \x56\x43\x32\x33\x00\x02. This appears to be the model code. Then the region code follows. Also, Chirp's generic Yaesu driver puts this model code at the start of the img, but the FT-2900 driver opts to leave it out. This means the driver has to send that pre-defined IDBLOCK at the beginning of every upload, instead of just sending what was in the radio before. This is probably why the MARS modification isn't supported. If someone with an FT-2900 wants to refactor this, I think a lot of code could be removed by switching to the yaesu_clone.py routines and support more regions/mods in the process. Tom KD7LXL

1 0