I’ve been toying with the idea of building a walkie talkie based on the svxLink software and Raspberry Pi Zero W platform. I found a really nice audio board that has two microphones, a headphone jack and speaker output that implements the I²S (Inter-IC Sound) digital audio interface standard. FWIW, it’s pronounced “eye squared S”.

I put together a Raspberry Pi Zero W that I soldered headers onto to mate with the KeyeStudio ReSpeaker Pi Hat board. The board provides two GPIO output that you can connect to using Grove connectors which is handy. I wired up a pushbutton to GPIO12 and a slide switch to GPIO13 via the Grove connector provided. The pushbutton provides a “COR” signal which tells svxLink that there is a signal on the “receiver” which in this case is the two microphones. It functions like a PTT switch.

The svxLink software is compiled from source code, and standard configuration settings are updated in svxlink.conf using a BASH script. The main things you will want to configure are the audio interface you’re using, e.g.”plughw:1″, type of the squelch detection (COR), either by GPIO pin or through the CM-119 “HiDraw” interface and what GPIO pin or HiDraw signal is used for PTT. When building a node that is not connected to a radio, the PTT signal can be used to drive an LED that indicates when someone is talking through the node.

Using a BASH script that’s run in the background to watch the status of GPIO13, a command is sent to svxLink that changes the talk group that is selected on the svxreflector via the svxLinks DTMF_CTRL_PTY facility.

svxreflector is described in another post. To recap, svxreflector allows multiple svxLink nodes to chat just like you might on a amateur repeater system. It supports vast numbers of different talk groups so multiple groups of users can have separate conversations. I have svxreflector running on another Raspberry Pi 3B+ computer. One of the nodes is connected to our Laguna Beach repeater. Any node that talks on the same talk group as the repeater, will go out over the air via the repeater. svxreflector authenticates each user by user ID and password.

Once everything was working, I designed and printed several different enclosures. The purple one is a small hand held “svxTalkie” that has a rechargeable LiPo battery and charge controller.

The larger Orange and Red unit is based on the Raspberry Pi 3B+ and features a much larger speaker but the same digital audio board is inside.

Another easy way to get started with svxLink is to use an external USB audio device such as the mVox MV100 that I’ve got set up on a Raspberry Pi 3B+ in one of the photos below. Then all you need to do is wire a PTT button and you’re all set.

One of my first versions of the svxTalkie was based on the Google Voice Kit version 1. It consists of a Raspberry Pi 3B board with a Google Digital Voice hat. The kit includes a fancy cardboard box that you mount the speaker, microphone, and button with LED in. I configured svxLink to use the digital voice board for RX and TX audio and used the button for PTT (actually COR) and the light that indicates when the remote side is talking (actually the PTT signal). It works great but I’ve yet to figure out how to get a volume control implemented in software and am reluctant to mess up the fancy cardboard box with a potentiometer.

SVXLink Interfaces

I’ve been running the svxLink application written by Tobias, SM0SVX for some time now. I installed it on our local VHF repeater back in 2018 using a Raspberry Pi 3B+, and an audio/PTT isolation board. I’ve been looking for new, improved or simplified interfaces to interconnect svxLink with repeater controllers and simplex node radios. Some time ago, I purchased an RA-35 board from Masters Communications and recently put it to the test.

I purchased the kit version of the board. Surface mount components are already soldered onto the board and the rest is through-hole parts. It was a fun project to build.

Previously I’ve built all-in-one systems using Raspberry pi computers and interfaces in a custom designed 3D printed case. That makes for a fairly clean installation.

Another solution I have used is a Linux computer with an external interface such as the ELink Echolink Controller:

This solution uses either the internal sound card in the computer, or an external USB sound dongle for the RX and TX audio. As you can see, there are a lot of cables to connect between the computer and interface.

The RA-35 board is essentially a USB sound dongle (Cmedia CM-119A) with audio amplifiers (LM-386) for TX Audio. The board uses the CM-119A’s Mic input and provides a pot to adjust the RX audio input level. The CM-119A’s GPIO (general purpose input/output) signals are used to control PTT, COS, CTCSS, etc. The board also provides landings for connecting directly to other GPIO pins. Software on Linux interfaces to these signals through the hidraw facility. svxLink is able to interface to these GPIO ports directly through configuration options.

The RA-35 board also features a clever monostable (LM555) circuit that disables PTT/TX if the system or board fails and heartbeat goes away.

This makes for a very clean interface between any linux computer and a repeater controller or FM transceiver.

I initially tested this solution using an Alinco DR-135 VHF transceiver and I am very pleased with the results.

svxLink can be used to interconnect repeaters, links, and users over the Internet or it can be used to establish point to point links using its own protocols.

A reflector application written for use with svxLink nodes called “SVXReflector” can be used to provide functionality similar to Echolink reflectors.

Ham Clock

Some time ago, I bought all of the parts to build a HamClock. Ed, WA6ED mentioned this project on the 40 meter net a while back. I finally got around to building mine (September, 2020).

HamClock runs on Linux (Raspberry Pi, single board computers), or Arduino platforms. The Arduino version was written for an ESPressif ESP8266 Arduino board from Adafruit called “Huzzah Feather” that has a built-in Wifi module.

More information about the project can be found here:

I mounted the Huzzah Feather board, display driver, and battery to the back of the display and designed a 3D printed case for it.

TM-731A Battery Replacement & Backlight LED Modification

I recently repaired a Kenwood TM-731A 2m/70cm mobile radio. It appeared that the backup battery was dead since it would no longer retain any memories after power was removed.

Checking the battery, it was indeed dead. I replaced that but noticed the board was coated with what could have been electrolyte leaking from the dead CR2032 battery. I removed as much of the leaked liquid as I could from the circuit board using flux remover.

To replace the four bulbs used to illuminate the LED display, I had to remove the front panel. That can be tricky on these old Kenwood radios since the foam that secures the buttons in place turns to sticky goo after so many years of use.

Like most radios I’ve come across, the backlight consists of multiple, in this case 2, pairs of 6 volt bulbs in series with a resistor.

After carefully bending the metal ears straight and releasing the LED display away from the control board, I desoldered each bulb and replaced it with a super bright white LED, keeping track of the polarity of the LEDs. I replaced the 10 ohm series resistors with 680 ohm SMD resistors for the new 20mA LEDs

Remote control for the Repeater Site

Howard, KG6GI and I installed the first D-STAR repeater system for the SOARA club in early 2007. During the process, we realized that we needed a way to remotely disable this new repeater system should anything go wrong, and to meet our FCC obligations.

Howard had already obtained a network connected relay and opto-isolated input control board designed by VA3TO called the “AVR Ethernet I/O”. Howard fabricated a 19″ rack panel with standoffs for the board, high current DC relay, bypass switch and indicators.

With 4 relays and 4 opto-isolated inputs, we also wired the remote control board to our D-STAR gateway computer and Echolink Node/Console server systems so that we could remotely reset them too. We used the opto-isolated inputs to determine if we had lost A/C power and test the door contact sensor, to know if the door was open.

I wrote a Perl application to query the board status remotely and developed some alerting code that would let us know if the A/C power failed, or if the door was open.

This worked great for many years until recently, when the board stopped communicating over the network. I was unable to repair the board, and our spare board exhibited the exact same failure mode.

So, I set out to build a replacement.

I had a “Nanode” (Arduino compatible) board that my friend Steve, KV6O had given me some time ago.

It had been a long time since the kit was produced, but I was able to find the assembly manual and figure out how to get the network working as well. I wrote a sketch that listens for commands and turns relays on or off accordingly.

I bought a 4port relay board from Amazon to use with the I/O pins on the Arduino board.

To make swapping the new setup in easier, I designed and printed a 3D platform that matched the EIO boards mounting screw locations exactly.

In the future, I will add the ability to probe isolated inputs to accomplish the same level of monitoring we had with the AVR EIO board.

Repairing Maggiore R1 Repeater

The SOARA 224.100 Repeater became intermittent and stopped transmitting a few months ago. I finally made an appointment with the Laguna Beach water district to visit the site on May 28th.

Once on site, I quickly determined that the repeater had no power output. Keying the repeater did engage the transmitter, but nothing was heard even at close proximity to the repeater. I disconnected and removed the repeater radio from the shelf and took it home to troubleshoot the problem.

Once on the bench, I took the cover off, a time consuming task given it has so many screws that hold the top cover on!

The receiver and transmitter are in separate shielded sections with the center section of the cabinet available for a repeater controller, PL encoder/decoders and cabling. The transmit side consists of a Maggiore Hi Pro EV1 Rev F. transmitter/exciter and Hi Pro PAV-1 Power Amplifier.

My first thought was that the PA output transistor might have failed since it’s a part that is put through a lot of stress from heat and high current. I disconnected the exciter from the PA and wired a test transmitter to the input of the PA. It worked fine. I followed the alignment procedure and was able to obtain a clean 20 watts of output power into my service monitor.

The output of the exciter was only a few milliwatts when it should be about 3.3 watts. Measuring voltages through the filter stages, I found the voltage on the base of a transistor in the first buffer stage was very low. I removed the exciter board to make it easier to perform further testing and repair.

When removed from the chassis, I had to apply 13.8 volts to both the oscillator and subsequent buffer/multiplier/amplifier (PTT keying) stages. Once I did this, I noticed a large increase in power into the service monitor.

Once I went through the alignment procedure described in the service manual, I was able to obtain about 4 watts output from the EV1 transmitter.

Now that I had a working exciter/transmitter and PA, I reassembled everything back into the chassis.

Measuring the power output, it was back down to a few milliwatts output. Measuring the two 13.8 volt supply lines to the transmitter while grounding the PTT line, I found that the oscillator voltage was fine, but the PTT keying line was only 3volts! The obvious problem was the PTT relay. For some reason, Maggiore had used a 28VDC relay instead of a 12 volt relay.

I fabricated a small PCB with a relay and flyback diode. Luckily I had just purchased some automotive quality relays to fix a problem with the central locking system in my Toyota and I had a spare Fujitsu 52ND12-W relay.

Fujitsu 52ND12-W automotive relay used for PTT keying

Grounding the supply side of the relay energizes the relay and passes 13.8volts onto the keying line of the transmitter.

The output power was now 20 watts. I hooked the R1 up to a repeater controller and adjusted the audio levels. Lastly, I grounded the transmit PL enable line and adjusted the deviation of the PL encoder.

A few days later, I re-installed the repeater at Temple Hill. I added an RCA “Y” cable to connect the PL decoder logic output to the PL encoder enable input. This causes the transmit PL encoder to be activated any time a user’s input PL is received and decoded. The purpose is to allow listeners with CTCSS / PL Decode enabled to only hear users and not courtesy tones or repeater IDs.

TM-742AD no TX audio

I noticed an old TM-742AD in a friends garage recently. It had been disassembled and had a label on it that read “Defective Unit” – that piqued my interest!

I brought the radio home and put it on the bench. The radio powered up but all of the memories were reset to default frequencies so I suspected the backup battery was dead. I programmed a simplex frequency and transmitted into my service monitor. The PTT switch on the microphone was stuck. I fixed that by replacing the heavy foam bumper inside the microphone. Transmitting again, I noticed there was no TX audio. Since this radio uses an electret microphone, my first question was – is there power to the microphone? I measured 0 volts on the “8C” line to the microphone. Tracing through the schematic, I found a bad fuse. Replacing the fuse restored mic audio.

I disassembled the radio’s controller section which consists of two circuit boards fixed to a metal frame and connected together via a SIP connector and a ribbon cable. I measured the backup battery and found that it was flat. I have replaced many of these batteries in the TM-742 model radios and had brand new ones in stock. I bought direct replacement backup batteries from Mouser. Replacing the battery solved the memory issue.

When turning off the radio, I noticed the sound of a DTMF digit over the speaker and that the speaker was still making a rushing noise when it should be silent.

Power to the audio amplifier is controlled by two transistors, one a high power switching transistor that provides the source voltage for an 8 volt voltage regulator. With the power off, there was still 12.6 volts on the input side of the voltage regulator. I immediately suspected Q102, the larger switching transistor. Testing it confirmed that it was internally shorted which provided power to the audio circuits even when the logic circuits were shut down.

I replaced the 2SA1641(S) with a new one that I had in stock. I’ve seen this switching transistor fail in other units I’ve worked on.

The radio had been worked on before and the trace from the base of the transistor to the collector of the previous stage switching transistor through a current limiting resistor had been replaced with a short length of bare wire.

After I replaced the transistor, I cleaned up the wire that replaced the burned out PCB trace.

Upon further testing, I found that the output audio was intermittent! I installed a plug in the mixed audio output jack to plug into my test amplifier and while inserting the plug, I noticed the audio was restored. So, I reflowed the solder on the 3.5mm stereo mixed audio jack, sprayed contact cleaner into it, and the output audio is back to normal.

This is a really great radio and is still serviceable after 28+ years! Parts are becoming a little more scarce but you can still find these radios and optional modules and accessories on ebay for reasonable prices.

The last problem that I tackled with this TM-742AD was the lack of CTCSS decode, when there was clearly a TSU-7 decoder module installed. There was no CTCSS indication on the screen when pressing the TONE button.

My suspicion that the connector had separated from the board was correct. I reflowed the surface mount connector back onto the TSU-7 board and that was all that was needed to restore CTCSS (PL) decode. This is unfortunately a common problem with these older radios.

FT-911 low-audio repair

My Brother recently took his old FT-911 23cm handie talkie out of storage and powered it up. The radio worked, but the output audio was very low.

Tracing the audio path, I found sufficient audio at the output of the LM386 audio amplifier and the only component between the speaker and that was an electrolytic capacitor.

Naturally, that capacitor was buried deep in the circuit boards under lots of RF shielding. After some work, I was able to liberate the circuit board assembly from the transmit side. I couldn’t find a 100uF/10v capacitor – I only had a much larger 100uF/25V cap. It fit rather snugly but should do the job.

Once replaced, the radio now has sufficient audio. The output audio is not perfect in that there are some strange audio artifacts that can be heard from time time, but the radio works now.

Alpha Delta Coax Switches

I have one primary HF antenna, a Hustler 6BTV (6 band trap vertical). I was using an Alpha Delta 4-port coax switch to switch the antenna between my K3, K2, and coax that I use on the workbench. This morning when I listened for the SOARA 40 meter net, signals were very weak. SWR was very high when I tried to transmit. I removed the switch and replaced the K3 position with a SO239 barrel connector and that resolved the problem.

I used a digital VOM to test the ports on the switch and found ports 3 and 4 (K3 and K2) to be shorted out while activated! After opening up the switch, I found out why.

The busbar that provides grounding for ports that are not activated was higher on the port 3&4 side than the port 1&2 side. This was caused by the screw and washer that were supposed to hold the bar down being located too far away to engage the bar. A manufacturing defect.

I attempted to email the company but both of the email addresses they list on their web site are no longer valid.

Buyer beware! If you have a Delta4, you might want to take a look inside to see how it is constructed and make sure it doesn’t have this defect.