Measuring and logging HD Radio interchannel delay

The analog FM program audio and the main digital audio are supposed to be synchronized very closely to produce a clean blend between analog and digital when necessary at the receiver. With some work, you can synchronize these down to within a few samples. The problem now, depending on your installation, is keeping it synchronized. A lot of stations are finding that their digital signal drifts in time against the analog. The drift problem is being worked on, but for now, my concern is "How do I keep aware of how well I am synchronised?"

A ham operator and FM enthusiast, Brian Beezley (K6STI), wrote a command line program to cross-correlate the delay error between the two channels of a wave file and output the results to a text file. It seems logical to me that one could automate the recording of audio from a receiver in split mode to create many samples of audio for analysis. Then, another automated script could analyze the sample audio files and output the results in a statistical format. Since it doesn't have to be done in real time, all these data points (timestamped delay error values) could be saved and graphed, showing a nice graphical view of the drift. If you use a package like OpenNMS to collect and log the data, you could even get notification when it drifted outside certain limits. That is one way to keep on top of the drift and know how much it changes.

More details on half-duplex networking with Moseley Starlink with LAN option

I wrote this in an email to a colleague who asked how I tested our network connection over our Starlink STL. I wanted to save it for future reference.
----------------------------------------------------------

Ah, I have not tried using NetCat on Win98. Thanks for the tip. I just pinged myself over UDP on my XP box. On one command prompt, I ran the program like this:

nc.exe -u -L -p 5002

On a second command prompt window, I ran the program like this:
echo "Hello World" ¦ nc.exe -u 127.0.0.1 5002

This printed out the text "Hello World" on my first command window. This should work the same between two computers on a LAN.

Now, there is one small snag that I hit with the Moseley Starlink LAN port. Forgive me if I am repeating something you are already familiar with. On a normal network (full duplex), when a host wants to open a connection to a destination IP address, it first has to turn that IP address into an Ethernet MAC address (192.168.0.1 ==> 00:01:de:74:2a:07 for instance). To do this, it uses a protocol called ARP. It sends a broadcast message out that says "Who has [dest ip]? Tell [host address]." Then, when the dest computer hears its address asked for, it sends a reply to the requesting computer. The original host who made the request then caches the address and finishes its connection. The problem for the Starlink is that a destination computer on the receive side can never send an ARP reply back to the computer that asked for it, so no hosts on the transmit side can ever figure out on their own what the MAC addresses are on the receive side, hence they can never generate any packets to send. So, the network administrator has to set up his switch or the computer that wants to send packets over the Starlink manually with the MAC information for the computers on the receive side. In Windows, for example, if you know the IP address and MAC address of a computer on the receive side of the Starlink, you can put this information into a computer on the transmit side of the Starlink with this command:

arp -s ip_address mac_address

This will add a static entry into this computer's ARP table so that it never has to ask for the address. It just knows what it is and makes the packet and away it goes. There are also commands for Cisco switches to help this situation too, but I would have to look them up.

To answer your second question, I have tested our Starlink connection. I actually used a program called VLC to encode an audio file as a stream and it sent the data using UDP to a computer on the other end running VLC as a client. I posted a link to VLC on my blog but I didn't have time then to go into detail. You might read a little about VLC and see if it something you want to try.

Tags: radio networking HD Radio

Online debate about the future of HD Radio

Start here and work backwards.

A lot of really good points are made. What I benefitted from is a reminder that the real thing thing that listeners are interested in is content. The project really has just begun when the digital transmitter is installed. The biggest investment of effort will inevitably be in developing more content or perhaps new features that will make consumption easier. Also, any efforts toward generating new or existing content should take advantage of Internet distribution as well.

Tags: radio media digital HD Radio

Satellite radio faces economic difficulties

I read this article in the Wall Street Journal (mentioned here) about a potential financial crisis facing satellite radio companies. It seemed to highlight to me that terrestrial broadcasting's strength continues to be that it is free and hopefully stations will use their HD Radio multicast capability to offer interesting new content instead of more of what is already available in their markets.
Technorati tags: radio satellite digital HD Radio