audio – Engineering Radio

Unbalanced to Balanced Audio

I pulled this out of the published posts and updated it.

I have been working on updating some wiring at one of our client’s transmitter sites. I noticed that an off air monitor feed was going back to the studio on a Barix box, which is fine. It was being fed from a balanced output of a DA to the unbalanced input on the Barix box. This being at the transmitter site, was susceptible to RF noise. I decided to make a passive audio BALUN.

Balanced to unbalanced audio converter using 10K to 600 ohm transformer

In any case, there are several ways to go from balanced to unbalanced without too much difficulty. The first way is to wire the shield and Lo together on the unbalanced connector. This works well with older, transformer input/output gear, so long as the unbalanced cables are kept relatively short.

simple balanced to unbalanced audio connection

Most modern professional audio equipment has active balanced input/output interfaces, in which case the above circuit will unbalance the audio and decrease the CMRR (Common Mode Rejection Ratio), increasing the chance of noise, buzz, and so on getting into the audio. In this case, the CMRR is about 30 dB at 60 Hz. Also, newer equipment with active balanced input/output, particularly some brands of sound cards will not like to have the Lo side grounded. In a few instances, this can actually damage the equipment.

A Henry Match Box or something similar can be used. I have found, however, the active components in such devices can sometimes fail, creating hum, distortion, buzz, or no audio at all. Well-designed and manufactured passive components (transformers and resistors) will provide excellent performance with little chance of failure. There are several methods of using transformers to go from balanced to unbalanced or vice versa.

Balanced to unbalanced audio using 1:1 transformer

Using a 600:600 ohm transformer is the most common. Unbalanced audio impedance of consumer-grade electronics can vary anywhere from 270 to 470 ohms or more. The 10,000-ohm resistor provides constant loading regardless of what the unbalanced impedance. In this configuration, CMMR (Common-Mode Rejection Ratio) will be 55 dB at 60 Hz, but gradually decreases to about 30 dB for frequencies above 1 KHz.

Balanced to unbalanced audio using a 4:1 transformer

A 600:10,000 ohm transformer will give better performance, as the CMMR will be 120 dB at 60 Hz and 80 dB at 3 KHz, remaining high across the entire audio bandwidth. The line balancing will be far better for the high-impedance load. This circuit will have about 12dB attenuation, so plan accordingly.

For best results, use high-quality transformers like Jensen, UTC, or even WE 111C (although they are huge) can be used. I have found several places where these transformers can be scrounged, DATS cards on the old 7300 series Scientific Atlanta satellite receivers, old modules from PRE consoles, etc. A simple audio BALUN can be constructed for little cost or effort and sound a whole lot better than doing it the wrong way.

A brief list, there are other types/manufacturers that will work also:

Ratio	Jensen	Hammond	UTC	Edcor
1:1 (600:600)	JT11E series	804, 560G	A20, A21, A43	PC600/600
4:1 (10K:600)	JT10K series	560N	A35	PC10K/600

Keep all unbalanced cable runs as short as possible. In stereo circuits, phasing is critically important, so pay attention to how the balanced transformer windings are connected.

As for cost; I purchased the Edcor PC10K/600 transformer on eBay for $20.00 and the Hammond 1590B Enclosure was about $9.00. The audio jacks and resistor were in the parts drawer. It took about 20 minutes to layout the holes, drill, mount the audio jacks, and solder the jumper wires. I used a tie-base, wire tie, and some Gorilla glue to hold the transformer down. I used a 1/4 inch TRS jack because the enclosure was a little bit too small for an XLR jack. If a stereo pair needed be converted, it would require two of everything.

Overall, I fun project. The old Simpson 260 is still accurate!

Checking the accuracy of a Simpson 260 on audio frequencies.

GPS controlled clock based on Raspberry Pi

This is an adjunct to my previous post on creating a Stratum 1 NTP time server with a Raspberry Pi. I finished this project about a year ago, and I have to say it has been running flawlessly since then. I thought that perhaps the inexpensive GPS module designed to work with drones might not hold up. But it has.

Wouldn’t it be nice to use this time source, not just to set hardware clocks but also display the time in varous places? Yes, yes it would.

Since most of my ideas are not original, I figured a quick internet search may shed some light on how to proceed. Keith, G6NHU did exactly this a year ago or so. His project can be viewed here: https://qso365.co.uk/2023/05/how-to-build-a-shack-clock-using-a-raspberry-pi-and-a-7-touch-display/

As I suspected, with a few more configuration steps, this NTP server can display the time on the native HDMI port as well as create a simple web page available on the LAN for any computer to access with a web browser. The web server is Lighttpd, which is a low CPU load, low memory demon, perfect for an older Raspberry Pi 3.

The display I chose is a 7-inch 16×9 non-touch purchased from Amazon for $33.99: https://www.amazon.com/gp/product/B0BGXB2Y67/ (not an affiliate link)

When I created the NTP server last year, I named it ntpserver. The unit runs headless (no keyboard or monitor) so I use ssh to get into the command line. Thus, the first command is:

ssh ntpserver@192.168.1.200

Once in, always do an update:

sudo apt-get update
sudo apt-get upgrade -y

The following programs need to be added to the Pi:

sudo apt install xorg openbox xserver-xorg xinit unclutter lighttpd -y

If the OS is off the shelf Raspian, then Chromium should already be installed, but if not, then add it:

sudo apt install chromium-browser -y

Once that is done, some things need to be configured. Using whatever text editor you like the xserver so that anyone can access it. Open the Xwrapper file:

sudo nano /etc/X11/Xwrapper.config

Then add line:

allowed_users=anybody

Exit and save. Next open the xserverrc file:

sudo nano /home/ntpserver/.xserverrc

Add the following:

#!/bin/sh
#Start the X server session with no power management so the display never sleeps
exec /usr/bin/X -s 0 -dpms -nolisten tcp "$@"

Exit and save. Next open the xsession file:

sudo nano /home/ntpserver/.xsession

Add the following:

#!/bin/sh
#Start Chromium at startup
chromium-browser --start-fullscreen --window-size=800,480 --disable-infobars --noerrdialogs --incognito --kiosk http://localhost

Exit and save. Note the display size can be configured to any screen resolution. This affects the HDMI port, not the web page. The 7-inch Raspberry Pi monitor that I purchased from Amazon has an 800 x 480 screen resolution. If you are using a different screen resolution, change as needed. Next open the clock.service file (it will be created when you save the file):

sudo nano /etc/systemd/system/clock.service

Add the following:

[Unit]
Description=Clock
After=network-online.target
DefaultDependencies=no

[Service]
User=clock
ExecStart=/usr/bin/startx
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Exit and save.

The web page that will be displayed on the HDMI port as well as served to local hosts on the LAN is a java script page. It was originally developed by Nayuki: https://www.nayuki.io/page/full-screen-clock-javascript You can download whatever format you like from that site (I copied the page source) or you can download a 24-hour format from Keith’s site:

cd /var/www/html
sudo wget https://qsl.net/g6nhu/clock/index.html

The colors can be edited:

sudo nano /var/www/html/index.html

The background, foreground, and font type can be changed as desired.

Next start the clock service and reboot:

sudo systemctl enable clock
sudo systemctl start clock
sudo reboot now

Here is a quick video of the web page on my desktop computer. I have the GPS monitor from the ntpserver up and running in the left upper corner. That shows the GPS data going into the Raspberry Pi from the serial port along with some scratchy WWV audio. The actual clock sync is from the 1PPS output of the GPS module.

I could see this being used as an inexpensive master clock system somewhere. With an HDMI splitter (or a better name would be Distribution Amp), this could be sent to many locations.

Now all I need to do is figure out how to get a GPS synced 10 MHz output capable of driving multiple devices.

What time is it?

This is an important question these days. We are running into more situations where timing is important, especially when audio and video codecs are concerned. If there is too much time differential, the codec will unlock. More often, digital transmission methods require precise timing to prevent jitter and dropouts. Some equipment has 10 MHz or 1PPS inputs. Some equipment does not and relies on NTP to keep things in sync.

While searching online for GPS time sever, I came across this post where Austin built a Stratum 1 level time sever with a Raspberry pi and an inexpensive GPS receiver. I thought to myself; damn that sounds interesting. While a Raspberry pi is a hobbyist toy, the same setup can be done with a more serious computer to create a solid NTP server for a facility or LAN.

A little about NTP time servers; Stratum 0 server is directly connected to an atomic clock. Since GPS satellites have atomic clocks, that makes them a Stratum 0 server. Stratum 1 servers are connected to Stratum 0 servers. Stratum 2 servers are connected to Stratum 1 servers and so on. The time accuracy for a Stratum 1 server is 10 microseconds.

First, I wiped my SD card and loaded a fresh install of Raspberry pi OS. Then followed along with the instructions. For this install, I opted for the cheaper GPS receiver, the GT-U7 (not an affiliate link) from Amazon for $10.99. It comes with a cheap little antenna, which actually worked sitting inside on my desktop while I was configuring the software.

This little module is designed for a drone but works well in this application. The 1PPS output looks clean on the scope. Here is the pinout between the GT-U7 and the Raspberry pi:

GT-U7 pin	pi pin	Use	Color
vcc	1	+3.3 vdc	Green
gnd	6	ground	Brown
txd	8	rxd	Orange
rxd	10	txd	Red
pps	12	GPIO 18	Yellow

I found this really nice aluminum case in a pile of disused junk at a transmitter site. It used to be for a digital TELCO STL circuit. I figured it would be nice to put the Raspberry pi and GPS receiver in a suitable home.

Raspberry pi 3 is mounted on a piece of scrap sheet steel designed to slide into the aluminum case.

We have several of these nice Panasonic GPS antennas left over from various installs. I pressed one into service on the roof of my house.

Panasonic CCAH32ST01 GPS antenna

I think a high-quality antenna is pretty important to get consistent good performance from this setup. There are three slight problems, however. Unfortunately, this antenna has been discontinued by the manufacturer. Also unfortunate, the GT-7U boards have one of those little IPX RF connectors. Fortunately, I found a short jumper with an F SMA connector. Finally, it requires +5 VDC and the GT-7U runs on 3.3 VDC. The pi does have a 5-volt rail, so I used this 2-way power divider to feed 5 volts to the antenna from one port and the received RF from the antenna goes to the GT-U7 from the other port.

If you are interested, here are the commands to get this thing running:

sudo apt get update
sudo apt get upgrade -y
sudo apt install pps-tools gpsd gpsd-clients chrony

The next step is to make sure the serial port is turned on and enable the ssh login shell since this is going to live in the basement and I don’t want to run down there to fool around with it.

sudo raspi-config

Then go to interface options, serial interface, and enable. The login over the serial interface can be left off. If ssh access is needed, enable ssh, then exit.

Once those packages have been downloaded and installed, some config file editing is needed. You may use whichever method you like, I tend to use nano. First, the /etc/config.txt and add the following to the file:

‘dtoverlay=pps-gpio,gpiopin=18’
'enable_uart=1'
'init_uart_baud=9600'

The uart needs to be enabled if you want to receive NMEA data (NMEA stands for National Marine Electronics Association) It is helpful to see if or how the GPS is working.

Next, the /etc/modules and add:

'pps-gpio'

Reboot, then see if the pps module is working:

lsmod | grep pps

The output should look like this:

Next, there are a few more configuration files that need to be edited.

/ect/default/gpsd – there is a default file that comes with the package, it needs to be modified to start the daemon automatically and look for the pps signal on ttyS0.

START_DAEMON="true"
USBAUTO="true"
DEVICES="/dev/ttyS0 /dev/pps0"
GPSD_OPTIONS="-n"

Reboot

Now check and see if the GPS module is working by typing cgps or gpsmon. The output should look something like this:

It did not take the module too long to find and lock onto GPS. If you don’t see something like this in five minutes or so, go back and check your wiring, and make sure that the data connections are made right. The GT-U7 has a little red LED that is lit when the PPS pulse is not being sent. If this light is not on at all, check your power connection. If it is on steady, check your antenna. If it is flashing, but you are not seeing any output in cgps or gpsmon, check your data connections.

Next and last configuration file is the /etc/chrony/chrony.conf file. At the top of the file, I added the following lines:

#custom lines for PPS
server time-a-g.nist.gov iburst
server time-d-g.nist.gov
server 3.us.pool.ntp.org
server time.windows.com
server time.apple.com
# add refclock pps
refclock SMH 0 delay .1 refid NEMA
refclock PPS /dev/pps0 refid PPS
#my home network
allow 192.168.1.0/24

Leave the rest of the file alone. Basically, the time servers are added to compare the GPS time and act as a backup. The hosts on my home network are allowed to query this host and use it as an NTP server.

Restart Chrony:

sudo systemctl restart chrony

Wait a couple of minutes and check the chrony console to see what is happening: chronyc sources. Should look something like this:

This was after the server had been running for a day. Chrony is great because it measures the hardware performance and creates a delay file. This is used to anticipate any hardware-added delays that the system might have. The last sample column is of interest, the number indicates the offset between the local clock and the source at the last measurement. The far column is the margin of error or greatest variation +/- of the expected values. A value of 0.0000000042 seconds or 0.042 microseconds is pretty good for an $11.00 piece of hardware. Now every host in my house is syncd to satellite within 0.042 microseconds, in lockstep through the time-space continuum.

If I were to do this professionally, I would use better hardware. I think the pi 4 has better serial and ethernet interfaces, more RAM, and a quad-core processor. Last I looked they were $75.00 at Newark.

The GPS module was the cheapest I could find on Amazon. I am slightly concerned about the longevity of this device. Perhaps it will run for a long time, or perhaps not. A quick search brought up several “hats” (plug directly into the 20-pin header). These range in price from about $30.00 to $60.00. What is required of any GPS module is 1PPS output. The configuration would be about the same although some use GPIO 4 instead of 18.

Distributed Mode Loudspeakers

My journey into home stereo speakers and high-quality audio continues…

This is not a broadcast-related post, but I find this type of thing interesting nonetheless. A few years ago, I began fiddling around with flat panel speakers or Distributed Mode Loudspeakers (DML). My first attempt was lackluster, although adequate and not very expensive.

I enjoy listening to all types of music. I notice that some music reproduces better than others. The piano is a particularly difficult instrument to record and faithfully reproduce because of the complexity of the instrument itself. It is a percussive string instrument. When one of the hammers strikes a sting, the string itself does not make a very loud noise. The string is connected to a soundboard through a bridge. The much larger soundboard vibrates and amplifies the initial sound. Thus, the wood itself imparts a noticeable quality to the sound. Several other instruments such as acoustic guitar, violin, etc also use tonewood to amplify sound. Thus, when listening to a piano being played back on a set of speakers, it lacks much of the original texture of the actual instrument. It sounds like a recording of a piano, not an actual piano.

This made me think of ways to improve that reproduction.

A DML uses a large flat surface to reproduce sound. The large surface area and the bi-directional nature of the panel means the sound will be defused and not directional as is the case with conventional speakers at higher frequencies.

The principal characteristics of the material used in a DML are stiffness and density. The less dense (lightweight) and the stiffer the better. All materials have internal resonances, some decay quickly and others, such as steel will ring for a long time. A ringing reverb sound would be undesirable in most cases. Tonewood has suitable stiffness and a relatively high sound radiation coefficient that varies in density according to species and generally dampens high-frequency harmonics. Pianos often use Sitka Spruce for soundboards.

I made two terminated transmission line speakers last summer. Those sound great, but using one driver to reproduce all sound from 20-20,000 Hz has a drawback; the high-end lacks detail and is very directional.

A bit of research shows that Poplar has good to very good tonewood qualities while being inexpensive and readily available at the local big box hardware store. Thus, I purchased several 1/4 x 6 x 48 inch (6 x 152 x 1220 mm) planks and a few pieces for bracing to make two 33 x 22 inch (838 x 559 mm) flat panels. The idea here is to gently cross over the transmission line speakers at 4,500 Hz with these flat panels.

The assembly process was pretty easy. It took perhaps two hours to cut all the pieces to the right size. I used a router to chamfer the edges of the back bracing, mostly to reduce the weight of the brace. Everything was glued up and allowed to dry for 24 hours.

The bracing is designed to keep the panel stiff and helps with structural integrity. I sanded the fronts and backs of the panels, then finished them with Tung Oil.

Each panel uses two Dayton DAEX32QMB-4 tactile exciters wired in series. There is also a Zobel network which is important for a tube amp. Most drivers’ impedance will rise as the frequency increases. This rising impedance is mostly reactance from the driver coil. For solid-state amps, this is not much of a problem. However, tube amps, because of the output transformer, need a fairly constant impedance across their output range. This is because the output transformer is a ratio device. The primary impedance is derived from the impedance on the secondary (e.g. what the secondary is terminated with). For example, a certain tube has a 5,000-ohm plate impedance. The output transformer is chosen to match this design specification. The output transformer is designed to drive an 8-ohm loudspeaker. However, the driver impedance rises to 16 ohms at 15 KHz and 24 Ohms at 20 KHz. Under those conditions, the tube would be seeing a 10,000-ohm impedance at 15 KHz and a 15,000 Ohm impedance at 20 KHz. This will lead to added distortion. The Zobel network keeps the impedance fairly uniform across the entire audio range.

Rather than build a cross-over into the transmission line speakers, I made an external unit. This allows the speaker system components to operate independently if needed. I can easily change the cross-over components for a different crossover point. I can also mix and match things in the future. In other words, it gives me a great deal of flexibility for future projects and experimentation.

I made these small boxes to match the speakers. These contain the crossover and HF attenuator. The attenuator is necessary because of the difference in efficiency between the transmission line driver and the tactile drivers on the DML.

The schematic looks like this:

I kept things as simple as possible. Yes, I could have made a 12 dB per octave crossover with a few additional components, however, I like the gentle blend of both drivers in the mid-ranges.

A basic sweep with Room EQ Wizard shows a fairly flat response. There is a room resonance of around 90 Hz which I intend to correct with some sound-deadening materials in the corners and possibly a bass trap.

This shows that the speaker system is relatively flat from about 200 Hz to 10 KHz. Those bumps and dips from 88 to 250 Hz are all room due to room resonance.

How does it sound? Pretty good! Here is some copyright-free music, recorded from youtube, then re-uploaded to youtube! It is not the best video, there is some background noise, etc. However, it gives a pretty good idea of how these sound.