In-car testing at KHTK.
The author is vice president, business development, for Orban Labs.
A long time ago, on a planet far away in a different galaxy and another lifetime, there were Arbitron (now Nielsen) paper diaries.
These were manually filled out by “listeners” to indicate which radio station(s) they listened to and for how long.
Technology marched on, and in the age of PCs and smartphones, the thought of filling out diaries manually felt like using stone tablets and chisels. So Arbitron designed a system to encode a radio station’s audio with a series of low-level tones that a device called a Personal People Meter would hear and log.
All that Arbitron “listeners” would have to do was carry the PPM device and, at the end of the day, put it into its charger, which would transmit the listening data back to Arbitron for processing. Brilliant!
Arbitron built the encoders, which resided in the station’s audio chain. The encoder looked at the audio and, if there was sufficient audio, generated the tones that the PPM device heard.
Processing manufacturers took a look at how they might be able to work with the encoder, and many provided an “encoder loop” that let the station put the encoder in between portions of the processor processing chain.
In many processors the “encoder loop” was placed after the input AGC and before the multi-band processing. This fed the encoder with more uniform audio levels and could potentially improve the encoder’s ability to encode the audio.
Take It On-Board
A decade later, in the era of AI and really smart phones, Nielsen, along with the NAB, approached processing manufacturers to see if they were interested in having the PPM encoding done in the audio processor.
This would eliminate the external encoding hardware plus the processor encoding loop and make life easier for stations. Also, there might be the ability to place the encoder in places that weren’t practical with an external encoder.
Nielsen assembled a team that developed a PPM encoding Software Development Kit (SDK) for both X86 and ARM solutions, and worked extensively with processor manufacturers on implementation.
Timing worked out well for us at Orban as we had engineering resources that had become available right at the time the SDK was ready, and our new XPN-AM platform was an ideal candidate for the X86 implementation.
Bob Orban and the engineering team looked at where the best location in the processing chain should be for the encoder, taking into account the need to support both analog AM and HD Radio, and potentially all-digital AM, along with streaming or an FM translator.
This resulted in using two encoder instances, one for analog and the other for all other digital services. Within 90 days we had a stable XPN-AM build with integrated PPM encoders.
Once the encoders were implemented in our XPN-AM software, a stringent testing process was done with hundreds of audio test files being processed and checked by Nielsen.
After the test files hit 100% approval, the next phase was beta on-air testing. These test sites had to have sufficient audience to generate enough testing granularity to assure valid results. Also, station management had to buy into the tests, the testing had to be coordinated with a Nielsen rating “book” period.
The Beta Process
I hit the road and installed all of the XPN-AM PPM beta test units at KHTK in Sacramento, KSL in Salt Lake City, KKYX in San Antonio and WSB in Atlanta.
Setup included adjusting proper modulation levels, checking HD Radio blend and diversity delay settings for KHTK and KSL along with doing drive listening in everything from vehicles ranging from a Mercedes Benz (borrowed from the morning drive host) to Jeeps, pickups and everything in between.
“Golden Ear” listeners, GMs and PDs were all polled and processor settings such as EQ and density were tweaked as desired by each of the stations.
Jason Ornellas, Bonneville’s regional director of engineering for the West Region, is shown at KHTK(AM) Sacramento with the XPN-AM processor.
We also did some experimenting with MDCL (since we could). At KSL we increased the amount of MDCL from 3 dB to 5 dB AMC without impacting fringe coverage because of the higher modulation density. It was interesting to see the forward power running about 17 kW with a 50 kW setpoint. The DOE said that would pay for the processor in power savings alone.
The critical part of the testing — the PPM encoding — was thoroughly tested. We were able to confirm with Nielsen that the correct IDs were being encoded. This included separate testing for stations that were running AM HD Radio.
Beta testing went live on Oct. 8 without any issues, and the feedback from both the stations and Nielsen has been highly positive, so much so that we have decided to provide PPM encoding at no extra charge in our XPN-AM starting immediately.
Orban’s engineers always enjoy a good challenge — in this case, producing viable internal PPM encoding in record time — and as usual they delivered, thanks to Bob and his team.
Comment on this or any story. Email radioworld@futurenet.com with “Letter to the Editor” in the subject field.
The post Making PPM Encoding Easier appeared first on Radio World.
