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.

I’ve owned a number of Baofeng UV-17 Pro GPS radios for some time and I’ve previously posted a teardown here on this blog. John Miklor has posted a detailed review on his site.

I had been hoping CHIRP would add support for this radio as I’ve had an issue open to add support for it for some time. Unfortunately, there are a huge number of requests competing for the CHIRP team’s time and this is not a simple thing to add – this radio uses a completely different programming interface and properly supporting it would require re-architecting parts of CHIRP’s basic structure – as an example, this radio model has 10 zones of 100 channels each. This would either mean a 1000-row list in CHIRP or adding a new way to select zones.

The factory CPS (Customer Programming Software, presumably) is very basic. In addition to an overall lack of features there are a number of annoyances ranging from the minor (some error messages only display in Chinese) to the major (the software won’t let you enter frequencies in the 108-136MHz aircraft band, even though the radio can receive them).

I initially thought “How hard could this be to fix?” and released a patched version of the factory software which I called 1.2.4a to distinguish it from the factory software. This got an excellent reception from the user community and soon requests for additional features started coming in, as well as a report that a certain series of steps would disable entry of aircraft band frequencies again. The sequence was odd enough (program frequencies in CPS, write to radio, read from radio and try to edit) that only one user ran into it. I released my 1.2.4b and 1.2.4c versions in rapid succession, but was unable to entirely eliminate the reported error. It also became clear that a number of feature requests from users could not be accomplished by simply patching the factory CPS with a hex editor.

Fortunately, the factory CPS was built with Visual Studio and Microsoft .NET and the program included a full “symbol table” which meant that it was possible to “decompile” the program into source code that had meaningful labels – typically decompilation produces code with names like “L1874” instead of “ChannelNumber”. At first I looked at this source code solely as an aid to discovering where I needed to patch things, but then I decided to attempt “recompiling” it from scratch. Much to my surprise, Visual Studio produced a program that seemed to work just like the factory CPS (after I made a number of corrections to the decompiled code). I worked on a number of “1.2.4d Experimental” releases which fixed many more bugs (including finally fixing the “aircraft band disabled after reading from radio”) and added new features. This version was extensively tested by John Miklor and a few selected users. I refer to 1.2.4d and later as “modified” software instead of “patched” software as things have moved far beyond simple patching at this point.

Confident that I was heading in the right direction, I continued with development of 1.2.4e. In addition to changes I was making to the program, I also built an installer package so that all users needed to do was run a “setup.exe” program. John Miklor contributed a new icon (orange UV-17 radio) which is now the default icon. The original generic radio icon is still available for those that prefer it. John did additional extensive testing to make sure I didn’t break anything and verify that all of the newly-added features and bug fixes worked as expected.

1.2.4e was released on the Miklor.com web site today and I wrote this blog entry to provide a little history on how and why it came about.

This is the list of changes and what version they first appeared in:

Revision history:

Changes in 1.2.4a:
1) "Freqence is invalid" -> "Invalid Frequency!" error message
2) "ZONEE 5" -> "ZONE 5" in default settings
3) "v1.2.4" -> "1.2.4a" in About
4) "?????" (Chinese text 'Read Failed!') -> "ERR1!" when opening a file
5)  Changed lower VHF frequency limit from 136MHz to 108MHz

Changes in 1.2.4b:
6)  "1.2.4a" -> "1.2.4b" in About
7)  Fixed additional locations where the aircraft frequency is checked
8)  Added additional information to this file

Changes in 1.2.4c:
9)  "1.2.4b" -> "1.2.4c" in About
10) Changed header to show 108-174 instead of 136-174
11) Documented restriction after reading from radio

Changes in 1.2.4d Experimental-1:
12) Switch to full recompilation in Visual Studio instead of patching binary
13) Changed Properties / Details to provide information about executable
14) Changed various Chinese-only error messages to English
15) Fixed "ZONE 5" to not have trailing NUL
16) Changed "ERR1!" from item #4 to "File open/read error!"
17) Corrected various spelling / grammar issues in English messages
18) Increased normal window size to not need scroll bars
19) Changed main window title to "UV-17/18/19/20/21/22 Pro CPS - Unofficial Experimental by 
    Terri Kennedy"
20) REALLY fixed air band in channel list
21) Removed documented restriction from #11 as it no longer applies
22) Changed Help / About... to "Version 1.2.4d\nExperimental-1\nby Terri Kennedy"
23) Changed the default radio model to UV17PRO

Changes in 1.2.4d Experimental-2:
24) Changed VFO lower limit to 108
25) App icon is missing from source-built executable - reinstate
26) Change “Bank” labels to “Zone” to be consistent with radio’s usage

Changes in 1.2.4e Experimental-3:
27) "1.2.4d" -> "1.2.4e" in About 
28) Temporarily disable “Import Picture to Radio” in Tools menu as it is not working
29) Make sure all instances of minVHF refer to 108 (hard-code in assignments)
30) Change default icon to orange (from John Miklor), retain original as alternate icon
31) Change internal app icons to orange and add where missing
32) Auto-close the COM port dialog after port is selected
33) Start app in window mode instead of fullscreen
34) Fix .cs files not loading properly in Visual Studio 2019 Designer
35) Change ordering of Zone selection buttons on channel window, rename “Last” to “Previous” 
    to correctly reflect function.
36) Fix SK2 setting reverting to FM when downloading from radio
37) Use orange icon in Control Panel / Programs and features

Changes in 1.2.4e Unofficial Build:
38) Change “Experimental-x" to “Unofficial Build” in #19
39) Change “Experimental-x” to “Unofficial Build” in #22
40) Change “Experimental-x” to “Unofficial Build” in #13

I have a number of things planned for a future 1.2.4f release, but you’ll need to wait for that release. I think you’ll be amazed at what I’ve come up with! In the meanwhile, 1.2.4e is so much better than the factory CPS that you should definitely try if you have one of these radios.

Hopefully these improvements will encourage Baofeng to “up their game” in their own CPS software releases. Simply releasing a bare-minimum CPS is no longer sufficient if they want to be taken more seriously as a radio supplier. Since there is currently no CHIRP support for their newer radios, Baofeng can’t simply say “use CHIRP if you want something better”.

A few closing thoughts:

1) If Baofeng is interested in obtaining the improved CPS, they should definitely reach out to me.
2) It would probably be possible to make similar improvements to the CPS for other radio models. My interest is exclusively the UV-17 Pro GPS as those are the radios I have. I’d be glad to discuss technical details with anyone who wants to try the same sort of thing on a different CPS. I’d also consider doing the work myself on a “time and materials” basis. I’d need at least one radio of the desired model to verify proper operation, as well as funding for the project.