Here are some resources on syncing computers to Content Depot with NTP.
Microsoft pages showing how to configure Windows Time service to use the Content Depot receiver as an NTP source.
I posted previously about using the Meinberg NTP software to monitor the Content Depot devices NTP servers to indicate if they were working or not. Meinberg NTP can also be used to sync to them.
I am trying the Beagle Software ClockCard with ClockWatch Server to sync our NexGen audio server to Content Depot. So far it looks very accurate and should not drift if there are large amounts of time that we cannot synchronize. I also have some indications that NexGen provides native support for the card. I am looking into it.
Some are also using the Dimension 4 NTP client. I have not tried it, but others really like it.
Lastly, some have mentioned a program called About Time. Again, I have not tried that one, plus, it looks like older software, not updated in a while.
Tags: radio networking ntp content depot
Tuesday, December 12, 2006
Here are some resources on syncing computers to Content Depot with NTP.
Wednesday, August 23, 2006
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
Friday, August 18, 2006
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
Wednesday, August 16, 2006
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
Tuesday, August 08, 2006
I had a very interesting meeting today about how we would plan to use the new technologies that are emerging to offer new services. I have been thinking a lot lately about what radio can do well in this new world we live in. Google and other search engines have dramatically changed how we are informed. In the old days, if you wanted to know about something, you would tune in and find out. Or if you wanted to hear a piece of music, you would tune in and listen, maybe even make a request. Now, search has made it possible to find almost anything you are looking for and you can usually download it and listen or watch it on your own time. This is natural and much more efficient. I could imagine fewer and fewer people listening to radio for this purpose. However, as the saying goes, "You know what you know, and you know what you don't know, but you don't know what you don't know." This is something I try hard to remember because no amount of searching for something will educate you on how much you don't know. We need other people to tell us things about things we don't already know, things that are interesting or entertaining. They can help us discover new styles of music or information that we didn't know we didn't know. I can't think of a better way to do that than broadcasting. I hope that broadcasting of the future will involve more of a two way interchange between broadcasters and the communities they serve.
Tags: radio media search hdradio
Posted by John McMellen at 3:48 PM
Wednesday, July 05, 2006
A fellow engineer asked today about how to ping from one side of a one-way network connection to the other to make sure it worked. I thought I would post some ideas that I had found when I was trying to do the same thing.
The ping command would work, but only if you had some network monitoring software on the device on the other end that you were pinging because the ICMP echo replies can't get back to the pinging host. An Ibiquity document describes how to overcome this using some utilities supplied with their HD Radio equipment on pages 64 and 65 of this document.
In addition, one could also run NetCat on two computers, one sending data on intervals on one side and the other listening for data on the other side. There are Windows versions of Netcat available with a quick google search.
My personal favorite method was to set up VLC on one computer streaming some audio or video to the other side on a computer running VLC as the client.
Tags: radio engineering network hdradio
Posted by John McMellen at 12:54 PM
Wednesday, June 21, 2006
I have posted before about using ticket creation software to track repairs, changes and other tasks done by engineering. A couple of months ago an engineer on Pubtech posted a link to the RequestTracker homepage in reference to how his shop keeps records and organizes these support tasks using a ticket based process. Once I got a chance to install and configure this package I was amazed at how useful it was just to improve my own record keeping and organization. It was not too hard to install, was free, and is fairly simple to use. Rich, you deserve a great big thank you for pointing this software out.
The most exciting possibility I have envisioned for us is the possibility of handling some problems in a more automated way. For instance, RT can be set up with an email gateway so that you can send an email and it will automatically record it and then act upon it however you choose. So I was thinking, wouldn't it be cool if I could have my equipment send an email to the RT software to report a problem and then the server would in turn open a ticket and forward the problem on to me by the most logical method. If it was a severe problem, it could be programmed to forward to my cell phone by text message. If it was less severe, it could just forward to my normal email inbox or possibly wait in the queue on the server for someone to act on it. This handles the problem of how do you process and forward all the alarm information from all the new devices that are capable of sending electronic alerts (remote controls, Content Depot, automation systems, etc.) in an intelligent fashion while preserving and documenting the history of these problems. I need to learn more about the scripting features in order to accomplish this, though, and try to find time between satellite equipment upgrades, HD Radio upgrades and everything else to try it out. I think it would be really cool.
Tags: radio engineering ticket
Posted by John McMellen at 2:03 PM
Friday, April 21, 2006
I found this utility while researching the NTP service that will be available on our new PRSS Content Depot receivers. It can monitor a local NTP service or external ones, and can email you if they are not functioning. This might be useful for knowing if our Content Depot devices develop any problems and warning us.
Posted by John McMellen at 3:47 PM
Thursday, March 16, 2006
Actually, it is a security feature. I am talking about the extensions of files downloaded from the Internet. The reason it is a good thing is that if the MIME type is an audio file and the extension is exe, then guess what happens when your browser gets the file? It may likely just go ahead an run an executable program that you thought was an audio file. However, Windows does make some stupid assumptions about what extensions a file type may have. Our radio station has been downloading audio segments from the Public Radio Satellite System's Content Depot. The files are MPEG 1 Layer 2 (extension .mp2) files. The server sends them as MIME type audio/mpeg which Windows assumes is an MP3 file, so it automatically changes the extension to MP3. Frustrating. I found this workaround by digging in the registry. Under this key, "HKEY_CLASSES_ROOT\MIME\Database\Content Type\audio/mpeg", delete the value "Extension". After restarting IE and Firefox, both browsers left the extension mp2.
Posted by John McMellen at 1:07 PM
Tuesday, February 07, 2006
Tuesday, January 24, 2006
Our Grad Assistant has been working on our content management system. This homegrown application has become more and more important in our operation. It is a new idea for radio. What we used to think of as a content management system was our automation system and all it did was put audio on the air. But now, you have web streaming, podcasting, online archives, RSS, and more in the works. The next big area to simplify our operation will be to create the capability to create content once and have the servers distribute it in whatever media you want. I wonder if the automation system vendors are working on this too?
Posted by John McMellen at 10:47 AM
Broadcasters are beginning to see the value of building Ethernet networks into their physical plant. In the past these networks were used for file based audio playout and automation, but now more streaming audio is being delivered over the network. Appliances such as the Axia Livewire system and Audioscience Cobranet do this in hardware. I have found that for quick setup of audio streaming across a local network, VLC is a useful, free program that fits a variety of situations. The executable acts as both a server and a client. It allows you to do traditional http streaming, but also offers more advanced options using Real Time Streaming Protocol (RTSP) or UDP streaming. It even offers multicast streaming. I believe it could even capture audio streams off of NPR's Content Depot network. I hope to get to try it soon that way. UDP streaming is also very useful for one-way Ethernet connections from Studio to Transmitter.
Posted by John McMellen at 10:37 AM