audio – Engineering Radio

Audio Processing

Any radio station’s on air signal is its biggest marketing tool.

What sounds bad:

Over use of compression (gain reduction)
Over use of high frequency EQ
Over “equalization” on all frequencies
Over modulation
Overly aggressive composite clipping
Improper use of FM pre-emphasis
Poorly tuned transmitters (tube type)
Poorly matched antenna systems (all types)
Poor quality audio input
Over use of bit reduction on the STL
Analog STL’s that are off frequency
Playback of bad audio recordings

What sounds good:

Moderate use of compression to bring up audio levels for in car listening
Using equalization that suites format (e.g. more mid-range for all talk, more bass for urban, etc.)
Properly adjusted processor output levels for the correct modulation levels
Setting the pre-emphasis correctly
Tuning tube type transmitters for minimum distortion
Tuning antennas for adequate impedance and bandwidth
Making sure that audio input levels are correct, the audio is properly distributed and terminated with the correct impedance
Using STLs that have enough throughput that either no bit reduction or minimum bit reduction is used
Regularly check analog STL frequencies and re-adjust as necessary
Get rid of all bad audio recordings in the automation/playback system. Make sure that new files are from good sources and/or are re-recorded correctly

I took a little road trip between Christmas and New Years (Happy New Year!). I cannot help myself, I ended up tuning around the radio to see what was on. Suffice to say, I found the usual formats and a few locally focused stations. What struck me was the sound of some of the stations. While most sounded acceptable, if not somewhat generic, there were a few that had ear splitting, headache inducing audio. These stations were often over modulating and way over processed. It would have been better if there were no processing at all.

That got me thinking, what is or rather what should be the point of audio processing? Way back in the day, there were loudness wars. These were often program director ego induced efforts to sound louder than the competition because if you were louder, it meant you had more power. As listeners tuned their analog car radios from station to station, the signal that “jumped out” was mostly likely to attract more listeners. At least that was the way it was explained to me in the by a program director in the late 1980s.

We are no longer living in a listening environment where loudness is of huge importance. The number of audio sources has increased greatly; iTunes, Amazon Alexa, Spotify, Tune in, Pandora, YouTube Music, Sirius XM, iHeart, and AM/FM radio. Audio levels can be anywhere and listeners have gotten into the habit of raising or lower the volume as needed. Outside of program directors, (or whatever they are called these days) offices, loudness means next to nothing. If you asked an average audio consumer how loud their program sounded, they would not likely know how to answer you.

I believe what most people are looking for is an enjoyable listening experience. The most important quality of any type of audio processing is that the product sounds good. The problem is “sounds good” is very subjective. Perhaps a better term would be technically sounds good. The audio should be free from distortion and artifacts of CODEC bit reduction. Overdone AAC or HE-AAC has this strange background swoshy platform behind everything which is headache inducing. Instruments should sound as they do when heard live. In other words, Susan Vega’s voice in the original Tom’s Diner should sound like Susan Vega.

Next would be compensating for difference levels in program material. A bit of gain reduction so that those in mobile listening environments can hear all of the program material. Finally, some format specific equalization can be useful. That is it. Moderate use of various audio processing tools can certainly accomplish those things. Like everything else, too much of a good thing is bad.

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.