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.

Older Baofeng radio models often included internal pictures which were available to view in the public FCC filing. However, for recent radio models Baofeng has requested long-term confidentiality for the internal photos (the schematic, block diagram, set-up procedure and operation description were already under long-term confidentiality on previous models).

Of course, since the radio isn’t welded shut, this doesn’t stop anyone from making a detailed investigation of what is in the radio, and that’s what I set out to do.

Without further ado, let’s dive right in. This is the side of the radio board that you will see upon initial disassembly (after removal of the LCD display screen):

1. LCD display connector – the large solder pad to the left is where the antenna connector is soldered to the PCB
2. Front panel (keypad / microphone / speaker / LEDs) connector
3. Unidentified integrated circuit from 3PEAK labeled DM2S04B
4. GPS antenna connector (UFL) – to the left of the GPS connector are the 2 LEDs that light up the activity indicator at the top of the case.

The back side of the board is where things really get interesting (note that you will need to de-solder the antenna connector to get the board out of the chassis):

1. TDA2822A – STMicroelectronics dual audio amplifier
2. 5807M – RDA Microelectronics FM tuner
3. XM25QH16CHIG – XMC 16Mbit serial flash (2MB)
4. Microcontroller – Unknown brand/model as the top has been ground off, tentatively identified as an ARM Cortex-A4 family part
5. M21529010 – Unknown IC, possibly flash memory
6. FD6818 – RF transceiver
7. H0606E – RF power transistors
8. ATGM336H-5N – Zhongke Microelectronics GPS / Baidu receiver

This is the underside of the front panel (keypad / microphone / speaker / LEDs). I did not do further disassembly in this area. But the LEDs and their driver transistor are visible at the left of this image. The PCB artwork is dated 2314, so is apparently quite recent.

This is the baseplate, which doubles as a heat sink for the 2 RF output transistors (the blue pads). The coarse scrawl of “UV-17 1” is quite different than the care shown in the rest of the radio internals:

This closeup shows the identification markings on the main PCB – “BF_UV17_PCB1.6 / 2023-03-01” with PCB artwork dated 2317. The row of 5 fingers at the center right is connected to the CPU, possibly used for programming the firmware:

In contrast to pictures posted of older model radio internals, the wave soldering seems to be quite well-done on this board:

In this picture you can see the hand-soldering of items like the volume control and the K1 external microphone / speaker connector:

I’ll wrap up this post with a picture of the GPS patch antenna. It is a “dumb” antenna – all of the magic happens in the ATGM336H-5N chip:

If you buy used Dell servers, you may end up with a system assembled from various parts. One of the more common things is ending up with a server that has no disk trays, or where the drives in the trays don’t match the labels on the trays due to the seller swapping or adding drives.

While the labels on the trays don’t provide enough detail to tell you the exact model of drive in the tray, it at least gives you a clue what you’re looking at, like “SAS 146GB 15k”. I recently assembled a server which came with no drives, by adding 8 Toshiba PX04SMB040 SSDs (Dell part number GM5R3) which came in unlabeled trays.

A number of different solutions have been proposed – everything from writing on the tray with a silver Sharpie pen to web-based label generators. Even if you could generate a perfect printout of tray labels, there is still the issue of finding a printer that can print silver, as well as the issue of either aligning the labels or manually cutting each label to size. Dell prints enough labels (or contracts them out) in large enough quantities that it works for them. I decided I could create a simpler solution at a much lower cost.

Since I already had all of the things needed to create tray labels, I decided to document the procedure here in case anyone else is interested.

First, you will need a Brother P-Touch printer that takes “TZe” type labels and supports printing from a host computer. I have the PT-P710BT “P-Touch CUBE Plus” model.

At the time I started this project, I could not find a Brother part number for a TZe 9mm black print on silver tape. Fortunately there is a huge aftermarket supply of TZe tapes, so this was not a problem. On eBay I found one in sealed packaging for $1.99. While I was writing this article I discovered that Brother does indeed make this size and color of tape – the TZe-M921. But Brother really does go out of their way to make it difficult to find part numbers for their tapes. I think that if they had a simple PDF, updated regularly, with columns showing tape width and rows showing the color, and either a part number or “N/A” at each intersection, they’d sell a lot more tapes.

Here is the “MATTSILVER” (sic) tape I purchased on eBay:

Installed in the P-Touch CUBE Plus:

Next, I created an image of the desired label in Adobe Photoshop. You can download the Photoshop file here and modify it to suit your requirements. I then saved the completed image as a .png file and imported it into the P-Touch Editor, duplicating it multiple times to create a strip of identical labels. The P-Touch file for the strip of labels I created is also available here (right-click and “Save Link As…”), although it won’t be very useful unless you also have 400GB SAS SSDs. But you can load it into the P-Touch Editor to see how easy it is to use.

The varying gaps between labels are not important – these will be trimmed away later. What is important is the vertical alignment – the black strips should align across each of the duplicates:

I then printed out the completed label strip. Note that the silver is more shiny and less matte than represented by the seller, but for $1.99 I can’t complain:

The next thing I did was tape the completed labels down to an 8.5 x 11 sheet of plain paper using 3/4″ Scotch “Magic Tape”. It is important to have the black stripe side of the labels closest to the edge of the paper and to center the tape on top of the label strip so that there is excess tape on all sides.

I then trimmed the sides of the paper so that the ends of the black stripe lined up with the cuts:

The previous step is necessary so the black stripe can be lined up exactly with the cutting path of the rotary trimmer:

While holding the paper firmly in the correct position, I used the rotary trimmer to cut the label strip and remove the excess silver part from the long edge of the labels. This trimming is needed because the indent on the Dell drive tray is narrower than 9mm and the P-Touch printer cannot print all the way to the edge of the label. Trimming the labels solves both problems in one step:

I then used the rotary trimmer to trim the sides of the labels to the correct width. This is something that requires practice – trim a label and hold it up to the drive tray and see if it is too narrow, too wide, or just right.

Next, I used scissors to cut off the excess paper ‘tails’ of each label:

Here is the drive tray I’m going to apply a label to:

Peel back the paper and fold it over, leaving a short strip of tape exposed between the label and the paper:

Remove the wax paper backing from the adhesive side of the label. You may find a single-edge razor blade helpful:

Carefully align the top, bottom and right sides of the label with the indent and apply the label, using the paper “tail” to hold and position the label:

Again using the paper “tail”, begin peeling the tape off the top of the label, starting at the top right. The adhesion of the label to the tray should be greater than that of the tape to the label, so the label should remain attached to the tray while peeling:

Continue removing the paper and tape until it is completely removed:

The left edge of the label needs to be pressed down into the tray indent. Then use a razor blade to cut the small diagonal notch on the bottom left of the label, taking care to not cut too deeply – you just want to cut the label, not the tray:

Repeat as needed until you have a system full of labeled trays:

You can use a similar method for 3.5″ drive tray labels or older generations of trays.

There are a huge variety of radios sold under the “Baofeng” (officially, Fujian [Nan’an] Baofeng Electronics Co.) name. Some are probably official private label models, some are outright fakes, and some fall somewhere in between. To confuse things further, Baofeng originally didn’t bother to register their brand trademark in the US. Someone else did some “trademark squatting” by registering it. While this was playing out at the US Patent and Trademark Office (USPTO), Baofeng branded their radios as “Pofung“. Between the Baofeng / Pofung confusion, official private label models and the fakes, it is hard to tell if a particular “Baofeng” radio is legit or not.

To complicate things even further, at least two companies claim to be “the” official United States distributor of Baofeng radios:

https://baofengtech.com (who also refer to themselves as BTECH) state that “We have personally dealt with hundreds of counterfeit listings and have had them removed from marketplaces. Unfortunately, most sites will not prohibit the counterfeiter from creating another listing. The most effective means to stopping counterfeits is to buy direct from a BTECH authorized distributor.”

https://baofengradio.us claims “Baofeng Radio US is the Authorized Distributor of Baofeng products in the United States. All products ship from within the United States.”

In addition to those two, there are a large number of other sellers on Amazon, eBay, etc. who are also selling “Baofeng” radios.

The manufacturer isn’t helping the situation. Their Baofeng Official Website Announcement says “While Baofeng has worldwide distributors and resellers, products are all produced by Baofeng. The concept that radio not sold by one of the distributors is counterfeit is factually inaccurate.” Aside from that statement appearing to claim that anything marked with a “Baofeng” label is genuine, it does not provide a list of “worldwide distributors and resellers” so anyone could represent that they’re a factory-authorized distributor or reseller and the purchaser has no way of telling if that is true or not. To confuse matters further, there are many “Certificate of Authorization” letters allegedly issued by the manufacturer listing dozens (if not hundreds) of entities that are “authorized”. These letters seem to come in a a surprising variety of styles, and every one I’ve examined is expired. You can do a Google image search for yourself by clicking here.

My first experience with this situation was ordering a package of two “Baofeng UV-82HP” radios from Amazon in November 2019. This was a “too good to be true” deal with 2 radios, 4 batteries, 2 coiled combo speaker/microphones, 2 earpieces and two whip antennas. When I received them, there was no FCC ID number on/in the radio (required for them to be legally sold in the US) and after contacting the seller I was given the alleged FCC ID for these radios, which turned out to be for a different model entirely. I returned then to Amazon for a refund, stating that they were counterfeit. I also left a review saying the radios were counterfeit. Amazon approved and published my review and it showed up among several other reviews also stating that the radios were counterfeit. Apparently the seller complained because my reviews and the other reviews mentioning “counterfeit”, “fake”, etc. were removed without explanation. That product listing is still active on Amazon, three and a half years later.

I eventually ordered replacement radios on Amazon from seller “BaoFeng Tech”. This is the same seller as https://baofengtech.com, also known as BTECH. In fact, their Amazon pages show both “Sold by BaoFeng Tech” and “Visit the BTECH Store”. They came with the expected FCC IDs inside and performed as expected. Since then I’ve been making sure to only order products that are sold by BTECH.

You can probably get the same radio from other sellers, particularly if you’re outside the US. But I decided to stop “rolling the dice” and always order from BaoFeng Tech / BTECH.

BTECH themselves are not helping the situation with their multiple brandings. Also, while their radios have customized battery compartment labels with their website listed and they have custom packaging distinct from any other seller I’ve seen, all of their BL-8 batteries had been mis-labeled (along with everyone else’s) as 2800mAh capacity instead of the actual 1700mAh capacity. This continued for many years until they introduced a new version of the BL-8 pack which includes a built-in USB-C charging port in the pack. That pack is correctly labeled as 18mAh. Unfortunately they didn’t change the part number, so a “BL-8” battery might or not might have USB charging depending on when it was made and who sold it. It makes me want to jump up and down and yell “You’re not helping!” regarding confusing naming.

Having said all that, BTECH does seem to be the most reliable supplier in terms of the product being exactly what it is represented to be.

This is something I worked on quite a few years ago, and I’m finally getting around to posting it.

A long time ago I ran across a fan fiction story titled The Black Company in Middle Earth by a user named McJunker. You almost certainly know Middle Earth as the setting for J. R. R. Tolkien’s The Lord of the Rings, but you may not have heard of Glen Cook’s The Black Company novels. That is something you’ll probably want to rectify, as McJunker explains. The Black Company in Middle Earth is a full novel in its own right – if it were to be published as a paperback, it would be close to 200 pages long.

Anyway, I contacted the author because I loved the story. I was working on my copy editing and document formatting skills at the time because I was getting ready to have a paper published in a professional journal. I asked if I could “publish” his story in a somewhat more polished form, as a PDF. He loved the idea, and off and on over the next year or so I worked on this project. In the meantime the author entered military service, served in Afghanistan and came back home. How time flies…

Anyway, once McJunker returned I showed him the result and he loved it. But I never got around to posting it for some reason. So here it is: The Black Company in Middle Earth (PDF edition). I hope you find it as enjoyable to read as I did. If for some reason you’re prefer reading it online, you can read it here: The Black Company in Middle Earth (HTML edition). I’m partial to the version with my copy edits, but if you want to read the original, feel free to check it out via the link at the top of this post.