I changed my [prefs] stock_configs = E:@online docs\Amateur Radio\CHIRP stock_configs as a test.

?? Something I did yesterday during my testing and installing the latest standalone version emptied out my custom stock_configs dir (or I did it by mistake) and cleared the [prefs] section so that when I started up this morning, I got the default loc.

In the olden times, CHIRP would copy all of the distributed stock configs into the user's personal directory. That was a big problem because it was then hard for us to update those files when they change (and they do, such as the new GMRS rules a few years ago). It's also a minor problem in that it's harder to distinguish your files from the distributed ones in the same directory and deleting them would cause CHIRP to just copy them in again.

In next, the distributed ones are separate from the user's own stock configs, we read them out of each location, and that's also why they're separated in the menu so you can tell the difference. In order to avoid duplication for people who have stock configs that were copied into their personal directory by legacy, next will purge the stock configs from the personal location they exist there (and only if they are unchanged from the source file).

So, assuming you've copied some of the distributed files directly into your personal/overridden stock_configs directory, you'll see that purging activity happen because chirp assumes it was legacy that copied those files there. If you don't want that to happen, just make any change to those files (like put a comment somewhere in the file after the first header line, prefixed with a '#'). That should cause it to look modified and chirp will leave it alone.

https://chirp.danplanet.com/projects/chirp/wiki/AdvancedConfig "Group" =? "section" ?

A library I use for reading these files calls them groups, but yes, you got it.

Maybe [whatever] isn't really needed? CHIRP simply scans for keys? At any rate, I decided that "group" means "section", and it worked fine.

No, the section/group *does* matter. You can't just put keys wherever you want, they have to be in the right place in order to be honored.

BOM - yep. I tripped myself here. I have my editor set to change unknown file types that are UTF-8 to use a BOM. Then when I saved the config file, CHIRP threw a mysterious (at the time) error, saying that the first line had an error. Of course, it didn't appear in the editor, so I was puzzled at first.

I should be able to fix this if you open a bug for the issue to "charge" it against. I think may be the only person that will notice, but it's an easy change in the encoding we use to read the file :)

--Dan

How specifically does chirp decide? For example, if I changed any of the files...and I don't really see that happening...the timestamp would change.

It calculates a cryptographic hash of the file contents to decide if they match the hash of the source. It should be basically infallible for these files.

So I am getting ready to submit the report. First I tested it, and got the debug log to attach.

Great, a source file for me to test against would be helpful as well.

Now I find that my user is 'unknown' on chirp...

I see "Once you are logged in, click the http://chirp.danplanet.com/projects/chirp/issues/newNew issue link on the menu bar above to get started. " but don't actually see the New issue link on any menu bar...so I clicked the link, and that worked.

Now if I can remember that bug report you asked me to submit quite a while ago...I'll look thru my emails...

Contact me off-list if you can't figure it out and I'll help you find your account and get logged in.

Thanks!

--Dan

On Wed, Nov 29, 2023 at 4:10 PM ritchkp@gmail.com wrote:

Trying to program a Wouxun, and I cannot recognize the Com ports on a Dell running Windows 11.

The Prolific PL2303HXA and PL2303TA chips which are often found in cheap programming cables, programming cables included with a radio and older Baofeng labeled programming cables are considered EOL (end-of-life). The Prolific company, which supplies the driver that Windows automatically installs when a Prolific PL2303 chip is detected, removes support for EOL chips from their driver. So when an EOL chip is detected by Windows, the driver will not assign a COM port. The only Prolific chip that is currently recognized by the latest Prolific driver in Windows 11 is PL2303GA (which is rare to see in a programming cable, but I happen to have one in my collection of over 40 programming cables).

You have a few workarounds available to you...

1. Switch to a programming cable that has been made using a USB-to-Serial chip from a different chip vendor (FTDI, Silicon Labs, WCH, etc). The FTDI chip is popular for this because the vendor/dealer listing will almost always mention FTDI (so you know which chip you are getting, if the listing doesn't say, then the chances of getting another Prolific chip based programming cable is very high). 2. Use a Linux operating system to run CHIRP. The drivers in Linux are open source (not made by Prolific) and continue to support chips that are considered EOL by Prolific. 3. Download, install and manually select the older (more than 10 years) Prolific v3.2.0.0 driver that works fine with any Prolific type chip (HXA, TA, GA, etc) and any Windows from 7 through 11 (Windows XP requires v2.0.2.1). A link to the driver and instructions for how to manually install it are available on the miklor.com website. I have been successfully using this method since 2012.

https://www.miklor.com/COM/UV_Drivers.php

Jim KC9HI