Over 9 years ago, I posted Part 1 of this post, lamenting how removing older encryption algorithms and other features from SSL was a disservice to end users. After all, I’m not going to replace all of my light bulbs just because they’re no longer supported by the most recent web browsers. And it isn’t the browser maker’s fault – there’s a mysterious (to the vast majority of Internet users who want things to Just Work) cabal that sets these rules, and holds the threat of banishment over any company / organization that does not comply with their arbitrary and capricious rules, which they seem to be making up whenever they feel like it.

The cabal’s latest idiocy is that the lifetime of SSL certificates (which used to be three years and was cut back to one year some time ago) needs to be shortened further, with the eventual goal being to reduce the maximum certificate lifetime to 47 days in 2029.

Per digicert, the timetable is:

• From today until March 15, 2026, the maximum lifetime for a TLS certificate is 398 days.
• As of March 15, 2026, the maximum lifetime for a TLS certificate will be 200 days.
• As of March 15, 2027, the maximum lifetime for a TLS certificate will be 100 days.
• As of March 15, 2029, the maximum lifetime for a TLS certificate will be 47 days.

The justification for this is apparently that a purloined or mis-issued certificate will have a shorter lifetime, limiting the amount of damage that could be caused.

I feel there are 2 pieces to this (which I touched on in my previous post):

1. I care about Bad Guys impersonating my bank.
2. I don’t care about Bad Guys turning my light bulbs on and off, particularly since they’re on a private network not accessible from outside my house.

And I REALLY don’t want to have to write scripts to automate the uploading of new certificates to my light bulbs, water heater, air conditioners, etc. – once a year was about the maximum annoyance level I could tolerate for doing this manually.

And in some respects, 47 days is too long – if BiggyBank.com gets their certificate stolen or a bogus certificate for BiggyBank.com issued to someone else, a lot of money is going to get vacuumed out of the bank in those 47 days. It seems that some new method of authenticating the site to users and users to sites like BiggyBank is needed. Preferably one that that doesn’t involve multi-factor biometric-based authentication or some other show of security that doesn’t actually provide any security*.

If I was a company in the business of selling SSL certificates for non-critical uses (like my light bulbs) I’d be up in arms about this – after all, if a user can get a free Let’s Encrypt SSL certificate that lasts just as long as the commercial certificate I’m selling, what incentive do most customers (other than places like BiggyBank.com) have to pay me for a certificate they can get for free, particularly when a robust ecosystem of installing Let’s Encrypt certificates on just about every type of device has already evolved?

* Such as when I am signing up for some service on my phone, and they ask me for my phone number so they can text me a code (to the phone number I just gave them) to “prove” that I’m me.

I’ve been quiet on the radio front as I’ve been working behind the scenes with BTECH for over six months on a new radio. It was announced today as the BF-F8HP Pro.

Here’s what I posted to the various Facebook radio groups I participate in:

This is where I (and my modified CPS) disappeared to.

I’ve been working extensively with BTECH to make this the best possible Baofeng, both firmware-wise and CPS. My modified CPS will reappear as 1.25m in December or January, with all of the improvements that aren’t unique to the BTECH 1.2.5l (so no firmware upgrade tool, etc.). In 1.25m you will be able to just open a .dat file from any of the radios supported by the modified CPS and write it to the BF-F8HP Pro, and vice versa. This is for user convenience – it won’t give you the features that are in the BTECH radio, but there’s none of the CHIRP “export to CVS” workaround needed to move configs between different radio models.

You may remember me saying that “I want to do a radio that fixes everything that’s wrong with the UV-17 Pro GPS, as well as a whole lot more”. This is that radio.

I’d suggest you download the CPS (it will happily coexist with any other CPS you have installed) and the radio manual and look at the radio and CPS features.

There are too many improvements to list here, but some highlights are:

• User-provided names for the zone displays on the radio, not just “ZONExx”.
• The top and bottom parts of the display can be in different zones.
• Zones can be added, edited, or deleted in the field – no need for the CPS.
• Single-key functions to toggle between name / frequency / channel number on the display; change Tx power; display battery voltage (in addition to the usual scan, lock and weather single-key functions).
• “Single watch” display mode where the whole screen displays all the info for a channel – name, frequency, channel number.
• User-customizable startup screen delay.
• In addition to the usual picture / battery voltage startup display, you can set a string with your call sign or name.
• 1.25m band works on this radio.
• You will get the advertised power (maybe a little more) across all bands. This isn’t some paper spec, it is really there.
• The radio comes with 2 antennas, one tuned for VHF/UHF and another tuned for VHF + 1.25m.
• The GPS interoperates with the NRF-based UV-17 Pro GPS (firmware 1.03, 1.07 and 1.11) as well as some other NRF-based Baofeng models that have GPS capability.
• The radios are individually calibrated at Baofeng, on a separate production line overseen by someone who reports to BTECH, not Baofeng.
• There are actually people (the BTECH folks) here in the US, who know the radio inside and out and will provide support as well as make note of feature requests / bug reports and get them addressed. None of this “We can’t get that from the factory” or “we don’t know” stuff you get from overseas vendors.
• You WILL get firmware updates. The tool to apply them is part of the CPS. IMPORTANT: Firmware files and the tool are for this radio model only. There is no “generic” version of this radio – the hardware is unique to BTECH. Flashing this firmware to other radios will brick them.

I did my work without knowing what the final market price would be. The selling price is $10 less than the low end of my ballpark guess.

I’ve been involved with this since late March. Baofeng creates new models on what seems like a weekly basis. BTECH are going to sell and support this radio long after other models have come and gone.

BTW, if you want to, you can use this affiliate link at BTECH, which will help me out a little on everything you order through the link and help support further development of my modified CPS for other the UV-17 Pro GPS and related radio models.

On August 14th, I received an email from Google saying that my Google Pay balance of 38 cents was to be forfeited in 9 days unless I took some specific action:

Merriam-Webster defines escheat as “the reversion of property to the crown in England or to the state in the U.S. when there are no legal heirs”

In general, in order to be escheated, property needs to be both unclaimed and the lawful owner is unknown. Neither of these is the case here, as obviously Google knows these are my funds and how to contact me (as well as lots of other data they’ve collected on me and anyone else who has ever used any of their services).

So I clicked on the “contact us” link, which was as unhelpful as ever* – if you or your company aren’t paying Google, you’re a product to be sold, not a customer to be assisted. Inventory doesn’t get to complain.

If I had been able to contact anyone/anything at Google that had even an ounce of common sense, I would have asked for this to be transferred to my Google Play Store account, which gets used several times a month. Instead, Google is presumably going to add my info to a giant spreadsheet, along with everyone else they’re escheating that lives in my state, and send the spreadsheet and a single check to my state.

Just out of sheer orneriness, I’m going to wait for my 38 cents to be processed by my state and then I’m going to request a check be sent to me for the 38 cents. It would be fantastic if enough people did this that someone in one or more states goes “WTF?” and complains to Google that Google is making the state pay to return funds to Google’s customers because Google is too lazy to do so itself. I’d love to see a class action** over this, but that’s being way too optimistic.

At best, someone searching for “google escheat” may come across this page in search results.

* When I ordered a Pixel 3XL phone direct from Google and they reduced the price by $200 before I’d even received my order, their canned response was that I could return it, pay the restocking fee, and re-order it at the new lower price. When pressed, their “official” position was that I should join Reddit, send a direct message explaining the situation to someone named “Ziggy”. Bizarrely, that eventually worked. Ziggy’s email signature read “Ziggy / Platinum Google Product Expert & Mentor / Docs, Fi, and Pixel”. One heck of a way to run a company.

** I’m hopeful that many of the class action suits which don’t return any meaningful funds to the class members still serve as an incentive for the company being sued to stop doing whatever they did that led to the class action suit in the first place. Google seems to hold the opinion that they can pay their way out of their various legal issues with trivial amounts of money (for example, an hour’s worth of profits) and keep on doing what they’ve been doing. Even if the US doesn’t have any taste for a battle with Google, the European Union certainly seems to be spoiling for a fight.

My monthly modified CPS release, 1.2.5k was released on the Miklor.com web site the other day. 1.2.5k re-bases the code on the factory CPS Version 1.2.5, introduces a new column sort feature, and includes several bug fixes and enhancements.

Here is a complete list of new features and changes in 1.2.5k:

• The modified CPS is now based on the factory CPS Version 1.2.5, which has some minor internal changes compared to the factory CPS Version 1.2.4.
• The Help / About box now contains a link to the official distribution site for this modified CPS. A number of unofficial mirror sites have appeared, and they may not have the most recent version.
• The ability to sort channels based on Rx Freq, Tx Freq, and Name has been added. Refer to Section 4.2 for additional information.
• Support for the UV-G30 Pro (AKA BF-UV20) radio model has been added to the CPS and Upload Startup Picture tool. Note: The UV-G30 Pro radio model is not yet supported by the Voice Pack Editor tool.
• A warning message is now displayed if the user changes the radio model after the Radio Function window has been opened. Note: This is necessary because the various radio models support different functions.
• The user-selected Scan Add/Del setting is now used when the Default button is clicked in the channel list window.
• The currently loaded filename is now displayed to the right of the toolstrip icons.
• The radio model dropdown now adds “(w/ zones)” to the model names to clarify that this CPS only works on radios that have multiple memory zones. Baofeng’s model numbering scheme can be quite confusing.
• The FHSS column in the channel list has been renamed to Encryption to better reflect its usage on the radio.
• An attempt to paste when more than one destination channel is selected is now detected and reports an error rather than silently doing nothing.
• The modified CPS no longer auto-disables transmit on frequencies in the 200-260MHz band when entered into channels. It has been reported that newer UV-17 radio versions, as well as other models, produce the expected output power in this band.

My monthly modified CPS release, 1.2.4j was released on the Miklor.com web site today. 1.2.4j provides an updated manual, adds additional radio support, and a few other features and bug fixes.

Here is a complete list of new features and changes in 1.2.4j:

• An additional ready-to-use voice pack with the “Grace” Irish voice has been added.
• A bug which caused “Malformed frequency” error messages to appear for international locales that use a comma as a decimal point has been fixed.
• A Silence.mp3 voice prompt is installed, allowing users to selectively disable various voice prompts as desired.
• The BF-18H has been added as a supported radio model.
• Support for the “Dis ANI” setting (added in radio firmware 1.28) has been added to the Radio Function window.
• A section has been added to the manual describing how to move configurations between different radio models in the UV-17 Pro GPS family.

Continuing my monthly modified CPS releases, 1.2.41 was released on the Miklor.com web site today. It adds a voice pack editor that lets you replace the factory voice prompts as well as a number of bugfixes.

Here is a complete list of new features and changes in 1.2.4i:

• A Voice Pack Editor utility is now available in the Tools menu. This utility lets users create and upload customized voice prompts to the radio.
• Six ready-to-use voice packs are provided with the modified CPS.
• Handle cases where invalid frequencies in .dat files generated by a 3rd-party app could cause the CPS to exit with no error message.
• Handle cases where channel names in .dat files generated by a 3rd-party app are not limited to 12 characters.
• When reading an invalid channel frequency from the radio’s memory, the CPS no longer exits with no error message.
• The CPS toolbar that shows the supported frequencies no longer changes to show an incomplete list of frequencies after a read from the radio.
• Reset channel selection (for Cut/Copy) when switching between zones.

Continuing my series of modified CPS releases, 1.2.4h was released on the Miklor.com web site today. It adds a working picture upload tool and a major redesign of the channel list visual style as well as a number of bugfixes and tidying up of loose ends.

Here is a complete list of new features and changes in 1.2.4h:

• Restore “Upload startup picture to radio” in the Tools menu, as it has been fixed.
• Two different Baofeng logo startup pictures have been added – the original one shipped with the radio and an alternative version.
• The visual style of the channel list has been redesigned to make it easier to use. The specific design elements are:
• Channels are now highlighted in a 2-color format when selected, instead of all selected channels being highlighted in Moccasin. The new 2-color format will follow the currently selected Windows theme, such as the high contrast theme for the visually impaired.
• The contrast between alternating rows of channels has been increased.
• The column header text background is now Light Gray instead of Moccasin.
• Use the system Sans Serif font throughout the CPS. Previously, the radio bands, channel list, and about box used a variety of harder-to-read fonts.
• Use the system theme for the scroll bar instead of forcing the scroll bar to always be blue.
• The QT/DQT values are now centered in their columns.
• The QT/DQT dropdown menu background colors now correctly match the background color of the channel.
• An obsolete library is no longer used, saving over 5MB of disk space in the installed CPS.
• The settings in the Settings toolbar dropdown (COM port number, CPS language, and default Scan Add behavior) are now saved and will be restored whenever the CPS is started. Note: The saved COM port is not shared with the “Upload startup picture to radio” applet. You will need to select the correct COM port each time you upload a startup picture.
• Correctly preserve the GPS time zone setting when reading / writing the radio and when opening / saving .dat files. Note: .dat files written with CPS versions prior to 1.2.4h have the time zone set to -12.
• Add “GPS Time Zone” combo box in the Radio Function window to allow configuring the GPS time zone.
• The first option name in the Radio Function window item “Backlight” has been changed to “Always On”.
• Tabbing between fields in the Radio Function window now proceeds as expected instead of sometimes jumping between different areas of the window.
• Items in the Radio Function window are now spaced evenly instead of having variably sized gaps between them.
• Items in the Radio Function window have been rearranged into more logical groups.
• Some Radio Function window items have been renamed to more accurately reflect the radio’s menu naming.
• The ability to configure the radio for Chinese menus / voice has been restored. It was broken in 1.2.4f and 1.2.4g. Note: This refers to the setting in the Radio Function window. The CPS has its own language option, but most CPS messages are English-only. Translation assistance is welcome.
• A new setting, “Voice Prompts”, has been added to the Radio Function window. Previously, this setting could be changed on the radio but not in the CPS.
• The Radio Function window item “Send ID Delay” (“PTT-DLY” on the radio’s menu) has been corrected to support the full range of settings supported by the radio (100 ms to 3000 ms in 100 ms increments).
• The Radio Function window item “Beep” now only allows the “OFF” and “ON” settings provided on the UV-17 Pro GPS radio.
• The VFO Mode window items “VFO A Step” and “VFO B Step” have had the missing 100KHz setting added.
• Correct the handling of CSV data with unexpected uppercase / lowercase formatting.
• Add a “Cancel” button to Paste Error message boxes.
• Entering a frequency with more than one decimal point in a channel no longer generates multiple “Error in frequency format” error messages.
• Entering an invalid frequency in a channel no longer deletes the existing channel settings after displaying the error message.
• The CPS can now be used with Windows “Open with…” dialogs.
• The setup program offers to optionally associate .dat files with the CPS.
• Unique error codes are now reported when a communication failure is encountered while reading from or writing to the radio. This should assist in locating places in the communication process that are prone to errors.
• A bug that caused the program to exit with no message after a new / write sequence has been fixed.
• A radio communication handshake error no longer causes the program to exit with no message. Instead, a message box requesting the user to report the bug is displayed.
• An attempt to read from or write to a radio using an incorrect COM port or with a cable that is not completely inserted in the radio is now detected and generates a useful diagnostic message.
• An attempt to read from or write to a radio with a cable that is not completely inserted in the radio now generates a useful diagnostic message when using certain programming cables. Note: This condition can not be detected on all programming cables. Some cables will report the generic COM port / cable error message.
• The radio read / write progress bar now properly auto-closes after the user clicks “OK” on an error message.
• A bug that prevented pasting lines with channel names containing Unicode text has been fixed. Note: The radio only has font characters for English and Chinese. Other characters will be displayed as a blank space.
• Pasting channel data into apps such as Notepad in older Windows versions no longer pastes as one long line of text.
• Trailing CR/LF characters are now added to the last line of cut / copied text.
• The README (this document) is now available from within the CPS via the Help / README for Modified CPS toolbar dropdown.
• The default channel list (generated when clicking the (Default) button in the Channel Information window) now auto-fills the GMRS/FRS channels instead of factory test channels. Note: This data is provided as an example only – the radio is not type approved to transmit on these channels in the US, and these frequencies may be used for other purposes outside the US.
• The default value for the Channel Information column “Scan Add” can now be set via the Settings / Default Scan Add behavior dropdown.
• Various checks for corrupted data have been added when loading a .dat file.
• Various checks for corrupted data have been added when doing a cut or copy operation.
• Unused code has been removed from the CPS build.

I have a pair of Brady TLS2200 labelers which are still heavily used. This model was discontinued by Brady in early 2016 and supplies for it are becoming more difficult to find. There is still a good assortment of labels and ribbons available on eBay, but reasonably-priced, functional batteries are another issue entirely.

Brady will still sell you a battery for $119.99 (plus shipping) but as they haven’t sold this printer in over 7 years, it likely that even “new” batteries will not perform as expected.

A company named MTO Battery offers a battery rebuild service for $55. Unless that also includes a prepaid mailer and return shipping, you still have to pay for shipping.

Brady also offered a battery eliminator but it is also discontinued. They’re quite rare on the used market, presumably because most people still using these printers need them because their batteries are bad.

That left me with three alternatives, none particularly appealing. I found that a company named FMA Battery was selling assembled battery cells (only, no case) for the TLS2200 on AliExpress. Unless you’re buying quite a few of them, it will probably be easier to order them from the FMA Battery eBay store. Here is an example listing. In case the listing is gone by the time you read this post, here is a screenshot:

You will need the following tools and supplies:

• One or more TLS2200 battery packs
• A matching number of new batteries
• Soldering iron and solder
• Diagonal cutters
• Single-edge razor blade
• Blue painter’s tape or equivalent
• 1/2″ chisel
• Black silicone adhesive sealant
• Gel-type cyanoacrylate glue (superglue)
• (optional) Labels showing the date the battery pack was rebuilt
• (optional) Marker pen

Some of those are shown in the following picture:

You will need to use the chisel to carefully cut the pack at the seam between the upper and lower halves of the pack. The area to chisel is shown by a green line in the following picture. It continues around the other 3 sides of the battery as well. On the two long edges this is at the location shown in the picture, just below the protruding lip. On the two shorter edges there is a visible seam you can chisel.

You are not trying to split the pack open with a single (or several) chisel strokes, just to crack the halves of the battery. A single light tap repeated along all four edges should be sufficient. When you have finished, stand the battery up so that the shortest piece is on top and tap on one corner with the chisel. The halves should begin to separate and you can use the chisel as a lever to separate them further.

It is important to not apply too much force with the chisel. You can always chisel around the edges again, but recovering from a shattered battery is more difficult.

If you are rebuilding more than one battery pack at a time, it is important to label the two halves of each battery with a unique number using painter’s tape and marker so you know which top goes back on which bottom. The plastic will split unevenly and you won’t be able to properly reassemble the battery if you have mismatched pieces. Note: This picture was taken after the battery case was disassembled, to show the labels on each half. You should apply the labels to each piece before separating the halves.

Once you have the halves separated, you will see the circuit board and batteries:

Lift the battery pack out. The circuit board will come with it since it is not attached. If the batteries don’t come out easily, you may need to lift the circuit board out of the way and then gently use the chisel as a pry bar to lift the batteries up. Do NOT cut into or otherwise damage the batteries – you want the chisel between the bottom of the case and the battery pack. Once you have the circuit board and batteries out, they should look like this:

The bottom half of the case may have remnants of silicone caulk attached. If your battery has these, peel them off with your fingers. Particularly troublesome pieces can be scraped off with the chisel.

Use diagonal cutters to cut the red and black wires connecting the battery to the circuit board, one at a time. Do NOT cut both wires at the same time – this will short-circuit the battery if it has any remaining charge.

There are two types of circuit board. This is the older style:

This is the newer style:

If you are rebuilding more than one battery pack at a time, use the marker and tape to label each circuit board with the same number as the battery halves it was removed from.

The new battery pack will come with a nice shrink wrapper and label:

This needs to be carefully removed before installing the new battery in the pack. Use a single-edge razor blade to cut a slit in the wapper at a point where the wrapper is not contacting the battery. Be very careful to not nick the wrappers of the individual batteries, as their wrappers are a similar color. Peel the wrapper off in a spiral motion, as if you were peeling an orange:

Place a blob of black adhesive sealant on each end of the four bottom battery cells:

Place the cells in the bottom half of the battery case. Slide them so that the side without the wires is close to the edge of the case so you have room for the wires later on. Carefully tuck the wires into the area where the circuit board will eventually go, taking care to not get the ends under the battery pack:

Place the top half of the case on the bottom half. It should have a tight fit along all four sides. Once you have verified that the top is on all the way, use the painter’s tape to tape the battery shut. It is important that the tape be very tight, to make sure that the batteries are pushed as far into the sealant as possible:

Let the battery pack(s) sit for 24 hours to allow time for the sealant to cure, then unwrap the tape that was temporarily holding the battery halves together. If you were using tape to mark which battery half was which, be sure to not remove those labels by accident when removing the rest of the tape.

Using the soldering iron, remove the cut ends of the battery wires from the circuit board and ensure that the holes have been cleaned out:

Cut the battery wires to the appropriate length and solder them to the circuit board. Be sure to work with each wire individually to avoid shorting them together:

Examine the battery pack from the top to make sure that the battery wires are tucked inside the case and not protruding where they would interfere with installation of the upper part of the battery case:

Carefully flip the pack over to confirm that the spring-loaded battery terminals are protruding from the battery pack. You don’t want to have to chisel the pack open again to fix a stuck spring terminal!

After making sure that you have the correct top piece for this battery pack (if you’re rebuilding more than one pack at the same time), run a bead of gel-type cyanoacrylate glue along all four sides of the case. You want most of the glue to be on the area where the case joints cracked during disassembly and not so much along the outer edges:

Place the top piece on the battery pack and squeeze the two halves together, making sure that the halves are fully seated against each other. There will probably be some “squeeze-out” of glue. That’s OK – it means the glue is in contact with both halves of the battery pack. You should remove this excess glue, particularly along the long edges of the battery pack, as this is where the battery retention mechanism works. You can use the cardboard wrapper from the single-edge razor blade or anything else that is convenient to remove the excess glue:

Re-wrap the batttery pack with blue painter’s tape, just as you did while the silicone adhesive was drying. It is important to make this wrap as tight as possible. The glue is the only thing keeping the battery from falling apart during use, so you want as good a connection as possible.

After waiting several hours for the glue to harden, remove the blue painter’s tape. At this time you can also remove any number labels you put on the cases to keep pieces of multiple cases organized.

Install a label indicating when the battery was rebuilt. You can always use the TLS2200 to print this label if you don’t have another labelmaker:

If you have a TLS2200 Quick Charger, place the rebuilt battery pack in it and allow it to fully charge, then press the red refresh button on the charger to perform a drain / recharge cycle. If you don’t have the quick charger, use the standard TLS2200 charger to charge the rebuilt battery pack. It may take several charge / discharge cycles for the battery to reach its full capacity.

I examined the original cells from 5 different TLS2200 batteries. 2 batteries had cells from SAFT, 2 had cells from TETG, and 1 had cells from GP. Of these, only the TETG cells had visible date codes, which indicated they were from 2000 and 2001. The TETG batteries were the only ones that displayed any sort of leakage (the white powsery substance visible on the upper-left and lower-right orange cells). As these cells are over 20 years old at this point, that may just be normal aging:

Continuing my series of modified CPS releases, 1.2.4g was released on the Miklor.com web site today. It introduces the ability to specify transmit frequencies as offsets instead of absolute frequencies, adds a frequency calculator utility, and contains a number of other improvements as well as bug fixes.

Here is a complete list of new features and changes in 1.2.4g:

• Add the ability to specify an offset for Tx frequency.
• A frequency calculator utility has been added.
• Fix error when entering a frequency such as “146.”
• Fix to actually exit the program when doing File / Exit.
• Fix occasional exceptions when trying to save to a read-only or otherwise invalid file.
• Report successful completion after saving a data file.
• Include the program build date/time in Help / About.
• Accept additional line delimiters when pasting from CSV files.
• Make error messages and window titles uniform and add unique codes when an error message can be generated in multiple places.
• Fix a problem where cutting a channel and then entering an Rx frequency into the same channel does not auto-fill the remaining fields as expected.
• Only auto-fill the Tx frequency for bands the radio can transmit on.
• Fix a number of unhandled exceptions when entering frequencies or offsets in the VFO Mode window.
• Limit the range of valid offsets to -10Mhz to 10MHz in the VFO Mode window.
• Only auto-fill the Tx QT/DQT column from Rx QT/DQT if the current Tx QT/DQT is set to “OFF”. This solves a problem where changing the Rx QT/DQT on an already-populated channel inadvertently changes the Tx QT/DQT.
• Handle a case where .dat files generated by a 3rd-party app caused Cut / Copy operations to not populate all of the selected channels.
• Correct an issue where attempting to add a new channel with a data file loaded could cause the error message “InvalidArgument=Value of ‘-1’ is not valid for ‘index’.”
• Sort the list of COM ports in the Settings / Port dropdown.
• Correctly handle cases where software such as Microsoft Excel reformats numbers, for example by changing “462.57500” to “462.575” and that data is then pasted into the CPS.
• Correct a bug that caused reported “Invalid setting in channel X” errors to show an incorrect channel number (one lower than expected).
• Do additional validation of frequencies and QT/DQT tones when pasting data into the modified CPS.
• Allow empty Tx and/or Rx QT/DQT in CSV paste, treated as “OFF”.
• Add “OFF” and “0” as synonyms for an empty Tx Freq in CSV paste to improve compatibility with other programs.
• Add the ability to specify a Tx Freq as an offset in CSV paste. Values from -10 to +10 are accepted.
• It is no longer necessary to click in the Rx Freq column of pasted data in order to enable editing of the other columns in that channel.
• A bug was corrected where pasting one or more channels would reset the channel’s Tx Freq to the pasted Rx Freq and both Tx and Rx QT/DQT to “OFF” when the channels’s Rx Freq was clicked on.
• The “Attempt to paste beyond Channel 100” error message will only be displayed once per paste operation instead of once for each channel past 100.

Continuing my series of modified CPS releases, 1.2.4f was released on the Miklor.com web site today. It introduces a number of new features including full Cut / Copy / Paste functionality – within a zone, between zones, and to / from CSV.

Here is a complete list of new features and changes in 1.2.4f:

• Add full Cut / Copy / Paste functionality – within zones, between zones, and to/from CSV (Comma-Separated Value) files.
• Fix VFO window scan range limits to 108-136/136-174/200-260/350-390/400-520 to match the radio’s capability.
• Display an informational message when selecting a scan range between 108-136 or 350-390 to warn about a bug in the radio firmware that prevents their use.
• Fix VFO Channel A & B frequency box validation to accept all valid frequencies.
• Fix Channel window frequency input boxes to accept all valid frequencies.
• Change the window top menu strip to show the actual radio frequency bands of 108-136/136-174/200-260/350-390/400-520.
• Change the default language for the radio in empty configs to English.
• Add a pop-up if selecting a radio model other than UV-17 to request feedback, as I have not tested those models.
• Fix the write progress bar to auto-close after the user clicks “OK” in the completion pop-up.
• Restore the ability to install on Windows XP (broken since 1.2.4d).
• Restore correct 136.5 CTCSS tone (broken since 1.2.4d).
• Accept frequencies ending with a decimal point (like “146.”) instead of generating an “Error in frequency format” error message.
• Both the setup program and CPS are digitally signed to prove their authenticity and that they have not been modified or damaged.
• Provide a complete manual (this document) in PDF form instead of text README file.