- Users - lists.chirpmyradio.com

[chirp_users] New Daily Build
by Build System 20 Nov '22

20 Nov '22

Greetings, A new daily build of CHIRP is available. This includes changes made directly to the tree yesterday, and may include additional features, bug fixes, and/or bugs. If you are interested in trying it, grab it from the following location: http://trac.chirp.danplanet.com/chirp_daily/daily-20221120 A list of the changes included in this build (since the last daily) follows: Changes for Build #712 [Dan Smith <dsmith(a)danplanet.com>] Make ICF log the full model query result [Dan Smith <dsmith(a)danplanet.com>] Long-overdue ICF cleanup The ICF driver has been accumulating a lot of cruft, from before the days where even hispeed cloning was supported. This doesn't clean up everything, but does improve consistency in frame parsing, generation, and makes the hispeed kicker use proper framing. It also (finally) actually digests the radio's CLONE_OK message for proper reporting. Some additional safety things are added, reporting of things to help debug, and unifies things such that merging with the py3 branch will be simpler. [Dan Smith <dsmith(a)danplanet.com>] Make ICF driver log the clone result frame [Dan Smith <dsmith(a)danplanet.com>] Make hexprint show proper data length Historically hexprint zero-pads the data it is printing, which makes it hard to see how much data is actually there. Fix that.

3 2

[chirp_users] New Daily Build
by Build System 19 Nov '22

19 Nov '22

Greetings, A new daily build of CHIRP is available. This includes changes made directly to the tree yesterday, and may include additional features, bug fixes, and/or bugs. If you are interested in trying it, grab it from the following location: http://trac.chirp.danplanet.com/chirp_daily/daily-20221119 A list of the changes included in this build (since the last daily) follows: Changes for Build #711 [Dan Smith <dsmith(a)danplanet.com>] A better fix to the ICF clone speed issue In commit 89467012 I "fixed" the issue with cloning to older Icom radios going too fast and causing them to choke on the data stream. A bug in that caused us to always hit the timeout reading echo frames (even if we got one) and thus slowed the clone process way down. This fixes that bug, and also tracks whether or not our cable is the echoing type to avoid us even needing to munch echoes once we have determined that we're on a non-echoing type. Tested with IC-2200, IC-2820, ID-800v2, ID-31A. [Dan Smith <dsmith(a)danplanet.com>] Improve native support for ICF files This makes CHIRP able to handle ICF files more natively, extending the save support recently added. We no longer warn the user about ICF files being readonly, and we can load/save them like .img files. Legacy models seem to have none of the metadata that the newer ones do, which makes this easier for them. Newer models have more things (like MapRev, EtcData), and this makes us persist those for a loaded file so that we can save them back out.

1 0

[chirp_users] New Daily Build
by Build System 18 Nov '22

18 Nov '22

Greetings, A new daily build of CHIRP is available. This includes changes made directly to the tree yesterday, and may include additional features, bug fixes, and/or bugs. If you are interested in trying it, grab it from the following location: http://trac.chirp.danplanet.com/chirp_daily/daily-20221118 A list of the changes included in this build (since the last daily) follows: Changes for Build #710 [Jim Unroe <rock.unroe(a)gmail.com>] [UV-50X2_G2] Add Baofeng Tech UV-50X2_G2 Baofeng Tech is releasing a second generation version of the BTech UV-50X2. This patch adds support for the BTech UV-50X2_G2. fixes #10126 [Dan Smith <dsmith(a)danplanet.com>] Make tests not require DV call lists If the radio driver does not require DV call lists, the tests should not require them either. Related to #1647 [Dan Smith <dsmith(a)danplanet.com>] Make the UI offer to save ICF files, if supported For drivers that expose the ICF details, allow File->Save to ICF file format. Related to #1647 [Dan Smith <dsmith(a)danplanet.com>] Add ICF write support for ID-31A Related to #1647 [Dan Smith <dsmith(a)danplanet.com>] Make ICF module able to write files We have long supported reading ICF files, but not writing them. The format is *mostly* well-understood, with the exception of some metadata. This is not as useful for all radios, but for the ones that support SD cards, being able to write ICF files means those can be programmed without a cable and/or before we have figured out the cloning details. This adds the basic capability to icf.py, but requires drivers to declare the metadata details for it to be useful. Note this also includes some py3 fixes so this will more directly apply to the py3 branch. Related to #1647 [Dan Smith <dsmith(a)danplanet.com>] Run py2 tests on Focal Github just switched ubuntu-latest to jammy, so make sure these run on focal. [Dan Smith <dsmith(a)danplanet.com>] Don't fail to create PR if merge commit fails If we fail to run makesupported, we will not touch anything, but return nonzero, which will try to git commit, which will fail because nothing is changed. Just ignore that and push the PR anyway so we have something to work from.

1 0

[chirp_users] New Daily Build
by Build System 09 Nov '22

09 Nov '22

Greetings, A new daily build of CHIRP is available. This includes changes made directly to the tree yesterday, and may include additional features, bug fixes, and/or bugs. If you are interested in trying it, grab it from the following location: http://trac.chirp.danplanet.com/chirp_daily/daily-20221109 A list of the changes included in this build (since the last daily) follows: Changes for Build #709 [Masen Furer <m_github(a)0x26.net>] hg_uv98: skip register if `future` is not available this driver currently depends on builtins.bytes ass try/except ImportError when doing from builtins import bytes since some platforms dont have the `future` package and the driver shouldn't crash the whole program in those cases. fixes #10110

1 0

[chirp_users] New Daily Build
by Build System 08 Nov '22

08 Nov '22

Greetings, A new daily build of CHIRP is available. This includes changes made directly to the tree yesterday, and may include additional features, bug fixes, and/or bugs. If you are interested in trying it, grab it from the following location: http://trac.chirp.danplanet.com/chirp_daily/daily-20221108 A list of the changes included in this build (since the last daily) follows: Changes for Build #708 [Dan Smith <dsmith(a)danplanet.com>] Fix ICF-based radios for clone out At some point we apparently started slamming data down the serial line at too high a rate for older radios. When using an ID-800, the clone dialog finishes in a few seconds, and the radio times out because it missed a huge chunk of the image because it overran its buffer. This seemed to work okay for radios that use the direct serial connection to the 2.5mm data jack, but not via the OPC-478 type interface. This change makes us read our own echo frames before sending the next one, which slows us down a lot. It feels a lot slower, but it means we're at least pacing the physical echo. Tested with an ID-800, ID-880 and IC-2820 and this fixes things. [Masen Furer <m_github(a)0x26.net>] add Lanchonlh HG-UV98 driver (#100) * hg_uv98: add Lanchonlh HG-UV98 driver fixes #7999 [Dan Smith <dsmith(a)danplanet.com>] py3-pr needs to push *after* matrix commit [Dan Smith <dsmith(a)danplanet.com>] py3-pr Needs file to commit [Dan Smith <dsmith(a)danplanet.com>] Update py3-pr to have tox for makesupported

3 2

[chirp_users] No mail getting to chirp-devel ML?
by Barry Jackson 05 Nov '22

05 Nov '22

I have sent 3 messages to the -devel ML recently and see none in the list. Also there are no archives since 24th October.

1 0

[chirp_users] Port names: (Was Re: Linux and chirp)
by Dave B 05 Nov '22

05 Nov '22

Those of you who are using Linux in one form or another, and need some "stability" as to how USB/Serial adapters are named/numbered each time you connect them to you computer, could do no worse than consult this site... http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/ Very good and genuinely useful info regarding "udev rules". These are text files that you can create, so that the OS can assign a consistent device ID for your use, regardless of how the OS actually discovered them... Two things though... a) The place to put the needed udev configuration file, can vary between Linux distro's, worse, more than one place can be used. One for "system" and one for "users". (On this now older Mint 19.3 system, my "Shack" udev file (99-shack.rules) is located at:- /lib/udev/rules.d) You also need to kick the OS into re-scanning the udev rules after you added new rule or made a change. $ sudo udevadm control --reload-rules && udevadm trigger (Your login password will be asked for.)| |b) Sadly, most USB<>Serial adapters, do NOT have any unique identifying feature in the information they present to the OS when connected, or as found during the boot process. But, you can use the "path" to them (the convoluted route via all the USB hubs etc, between OS and device) if needed. Just that you then *MUST* connect things up exactly the same each time. But.. FTDI bless them, DO HAVE a unique serial number for each and every one of their devices. ("Genuine" devices that is, there are fake FTDI chips about as well!) It is trivial then, to use that serial number to create (for example) a rule that results in a "device" name for example of:- /dev/ttyTMV71 Whenever that programming lead is connected. The corresponding rule itself is:- #TM-V71 (using the FTDI based lead) SUBSYSTEM=="tty", ATTRS{serial}=="AK06ML2R", SYMLINK+="ttyTMV71" In this case, the FTDI unique "serial number" is AK06ML2R You can discover that in several ways. One of the easiest is to perform a $ dmesg -wH command in a seperate terminal window. You will see instantly what happens when you connect or disconnect things. The -w means wait, and the H means human readable output. So, it just sits there reporting stuff as it happens. Untill you use a Control+C character to quit dmesg, then allowing you to close the terminal session as you need. The output of that contains (for example)... [ +0.114801] usb 1-1.4.2: New USB device found, idVendor=0403, idProduct=6001 [ +0.000003] usb 1-1.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ +0.000002] usb 1-1.4.2: Product: FT232R USB UART [ +0.000002] usb 1-1.4.2: Manufacturer: FTDI [ +0.000002] usb 1-1.4.2: SerialNumber: *AK06ML2R* [ +0.002668] ftdi_sio 1-1.4.2:1.0: FTDI USB Serial Device converter detected [ +0.000047] usb 1-1.4.2: Detected FT232RL [ +0.000534] usb 1-1.4.2: FTDI USB Serial Device converter now attached to ttyUSB5 [ +12.717166] usb 1-1.4.2: USB disconnect, device number 17 [ +0.000237] ftdi_sio ttyUSB5: FTDI USB Serial Device converter now disconnected from ttyUSB5 Note the "usb 1-1.4.2:" common parts of each line. the "1.4.2" after the initial "1-" changes if the same device is plugged into a different port, as below... [ +0.000002] usb 1-1.4.5.5: Manufacturer: FTDI [ +0.000001] usb 1-1.4.5.5: SerialNumber: *AK06ML2R* [ +0.002685] ftdi_sio 1-1.4.5.5:1.0: FTDI USB Serial Device converter detected [ +0.000047] usb 1-1.4.5.5: Detected FT232RL [ +0.000408] usb 1-1.4.5.5: FTDI USB Serial Device converter now attached to ttyUSB5 It now has a path of 1.4.5 You can use that information in a udev rule thus, below. #TS-870s SUBSYSTEM=="tty", ATTRS{devpath}=="1.3.3", SYMLINK+="ttyTS870" (In this case, for my Kenwood TS-870s, that is connected to one "leg" of a 4 port Prolific based device. The line beginning with a # Is a comment, you can for example include human readable text as a reminder...) Example readlink outputs: $ readlink /dev/ttyTMV71 ttyUSB5 or... $ readlink /dev/ttyTS870 ttyUSB2 Note! Your "custom" name "ttyTMV71" for example is valid, but what it points to, the "default" device name "ttyUSB5" is also still valid. The only difference is that "ttyTM-V71" will not change, regardless of the "ttyUSBn" device it actually relates to. So, in this instance, you would ordinarily use "/dev/ttyUSB5" in Chirp to work with the connected Kenwood TM-V71 radio. However, you CAN manually edit the port name in Chirp, to show "/dev/ttyTMV71", and it remembers it between sessions, so regardless of what ttyUSB device number is actually uses, it will work. (Or specify "/dev/ttyTS870" in Flrig or Fldigi. You of course can use readlink in a script to set an environment variable prior to launching some software that needs a port specified in it's command line invocation. It's not difficult, and there is ton's of good instructional pages out there that will help you automate things for a stable life...) You can also use udev rules to give consistent names to other devices, if you have multiple of the same type. Some USB sound cards for example also have a unique ID of some sort you can use. Hope something above helps. It seems like a lot of trouble and faffing about at first, but explore it, and you'll never look back. It is also one of the more compelling reasons to buy only genuine FTDI USB/Serial products too! It just makes life easier! Lastly. If you go this route.. DO make backups of your rules files! You will likely need them if/when you upgrade/replace your OS. Or just to remind your faded grey cell, what you did to make it work in the past. Have Fun! 73. Dave G8KBV (just another Linux user, "NOT" an expert by any means.) On 03/11/2022 19:00, chirp_users-request(a)intrepid.danplanet.com wrote: > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 3 Nov 2022 02:26:57 -0500 > From: W Paul Mills<ac0hy(a)wpmills.com> > Subject: Re: [chirp_users] Linux and chirp > To:chirp_users@intrepid.danplanet.com > Message-ID:<cf28ae50-a629-50ea-542b-4d0db3ee525c(a)wpmills.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > But if you plug in both, one will be ttyUSB0 and one will be ttyUSB1, etc. > > On 10/29/22 01:05, Cinaed Simson wrote: -- Created on and sent from a Unix like PC running and using free and open source software:

1 0

[chirp_users] Linux and chirp
by Julian Macassey 03 Nov '22

03 Nov '22

I am running kubuntu 22.04.1 on a Framework laptop. I have loaded the daily build from flatpak and Chirp comes up when opened. My radio is a Baofeng UV-5RV2+ I followed the instructions in: https://chirp.danplanet.com/projects/chirp/wiki/CSV_HowTo + A Clean Start + + If you want to get an empty CHIRP-compatible CSV file, the + easiest way is to let CHIRP create one for you. Here are the + approximate steps for creating an empty file, editing it in an + external editor and opening it back up in CHIRP: + + Start CHIRP + Go to File > New to create an empty CSV file + + Add a memory to the first row, by entering a frequency + such as 146.52 + + + Go to File > Export to save the template file to something + ending with a .csv extension + + Open the file in your spreadsheet or external application of + choice, make edits and save + Re-open the file in CHIRP to validate that the format is + still correct, by going to File > Open and choosing your file + + Optionally use File > Import to import the contents of your + CSV file into another radio image + ... + If you have a clone-mode radio, upload the changes back to your + device using Radio > Upload To Radio. If you are using a + live-mode radio, wait until all of the changes finish + synchronizing back to the device by watching the status bar in + the lower right corner of the main window. So, when I plug in my radio, I see the following in /var/logsyslog: ------ Oct 28 18:07:10 localhost kernel: [218263.636611] usb 3-4: new full-speed USB device number 15 using xhci_hcd Oct 28 18:07:11 localhost kernel: [218264.061760] usb 3-4: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 3.00 Oct 28 18:07:11 localhost kernel: [218264.061769] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Oct 28 18:07:11 localhost kernel: [218264.061772] usb 3-4: Product: USB-Serial Controller Oct 28 18:07:11 localhost kernel: [218264.061775] usb 3-4: Manufacturer: Prolific Technology Inc. Oct 28 18:07:11 localhost kernel: [218264.064089] pl2303 3-4:1.0: pl2303 converter detected Oct 28 18:07:11 localhost kernel: [218264.066251] usb 3-4: pl2303 converter now attached to ttyUSB0 Oct 28 18:07:11 localhost mtp-probe: checking bus 3, device 15: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-4" Oct 28 18:07:11 localhost mtp-probe: bus: 3, device: 15 was not an MTP device Oct 28 18:07:11 localhost snapd[13154]: hotplug.go:200: hotplug device add event ignored, enable experimental.hotplug Oct 28 18:07:11 localhost mtp-probe: checking bus 3, device 15: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-4" Oct 28 18:07:11 localhost mtp-probe: bus: 3, device: 15 was not an MTP device Oct 28 18:07:13 localhost ModemManager[824]: <info> [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:14.0/usb3/3-4': not supported by any plugin --- In Chirp I select Radio and slide down to select "Upload to Radio". I get a dialogue box saying:Port /dev/ttyS0, Bofeng, UV5R, I select OK. I get "An error has occurred Could configure port: (5, 'Input/output error') So just in case, I fiddles with the /dev/ttyS0 permissions: crw-rw-rw- 1 root dialout 4, 64 Oct 25 11:15 ttyS0 So what have I not done? What should I do? Yours GM5LUK -- "We can’t be successful unless we lie to customers.” Larry Ellison to Bruce Scott.

8 14

[chirp_users] Installation errors
by Tom 30 Oct '22

30 Oct '22

Hi, I have encountered a bunch of "C\ProFiles(x86)\CHIRP\XXX errors when installing the current CHIRP program. I stopped counting at 32. Here is a list of some of the errors: C\ProFiles(x86)\CHIRP\_ctypes.pyd \hashlib.pyd \socket.pyd \ssl.pyd \atik.pyd \cairo._cairo.pyd \chirpw.exe \freetype6.dll And many more. What went wrong? Thanks & 73, Tom KX7TRW

3 2

[chirp_users] New Daily Build
by Build System 25 Oct '22

25 Oct '22

Greetings, A new daily build of CHIRP is available. This includes changes made directly to the tree yesterday, and may include additional features, bug fixes, and/or bugs. If you are interested in trying it, grab it from the following location: http://trac.chirp.danplanet.com/chirp_daily/daily-20221025 A list of the changes included in this build (since the last daily) follows: Changes for Build #707 [Dan Smith <dsmith(a)danplanet.com>] Make the auto-sync PR update support matrix [Dan Smith <dsmith(a)danplanet.com>] Fix TK-8180 creating new zones with invalid data This fixes an issue when expanding the zone list. Related to #10093 [Dan Smith <dsmith(a)danplanet.com>] Add TK-8180E and TK-7180E model support Fixes #10093 [Dan Smith <dsmith(a)danplanet.com>] Add IC-7610 and fix IC-7300 Somehow the initial apply of the 7300 support duplicated some lines in the memory structure that prevented proper parsing of memory channels. This worked for reading memories, but would break when we went to send memories to the radio as we were writing past the end of our buffer. I'm not sure how this went unnoticed for the last two years, but this patch fixes it.

1 0