Archive
GatesAir FMXi 4g Importer/Exporter
Corporate mandate: Install this on your station. Reason: Old Importer runs Windows XP, security reasons.
I accept the reason, but I do not understand the mandate for a specific manufacturer’s equipment, especially when my transmitter is a different manufacturer. Making a GatesAir FMXi 4g work with a Nautel NV20. Well, I do, but money should not always be the answer to everything.
This can be done. What I did discover is quite interesting, and is not a very good way to determine proper operation. To make this whole picture come together imagine your choices of installation location for a combination Importer/Exporter. If you put it at the transmitter site, the Exporter sits on its own subnet with the Exgine. Now you need to get your audio for your HD2s and 3s to the site, in addition to metadata. If you install the combination at the studios, then you have your Exporter and Exgine on different subnets, or you are forced into VLAN fun. I have been running Exporters from the studio site successfully for years, so it can be done, but the FMXi gave me quite a start.
Per the manual, I configured the management NIC and the E2X NIC on the FMXi. I saved the PSD/IMP NIC as the last thing to worry about. When configuring the device GatesAir wants you to configure a routing table so traffic knows where to go. E2X is a simple UDP stream, so this should be simple enough. No HD. Head scratch. Example: E2X NIC given the 192.168.10.10 address. Exgine is on 192.168.20.X network, so the routing table is configured to send data to the 20.x network, use 192.168.10.1 gateway. Simple enough. No work. Discussion time #1.
Take the unit to the transmitter site. Basic troubleshooting principles. Drop it on the same subnet. After a quick configuration still nothing. Poked at the Exgine and verify ports are correct. Sheesh, haven’t changed those in so long, but verification away. After about 10 minutes of this, I noticed the FMXi was now happy, Exgine was detected. So, it can talk with the Nautel Exciter and Exgine. Cool. Back to the studios to contemplate why. Discussion #2.
Discussion #2 with Gates revealed a very important, yet minor detail about the Exgine being “detected”. I was curious about how a UDP connection got confirmation that “presence”, as Gates calls it, is determined. The surprising answer was the ARP table. The FMXi creates an ARP table just like any computer or switch. If the Exgine IP address is in the ARP table, then the Exgine is considered present. Guess what? If you are on a different subnet, you will NEVER get that “presence” indication, and your FMXi will report visually that the Exgine is not present.
As I had the FMXi working, as in creating an E2X stream at the site on the local subnet, I knew I could get this to work from the studios, so back to configuration and poking. Again, I made sure the routing table had the route required to get the E2X stream to the site. This time, I kept refreshing the ARP table until I saw with my own two eyes that the gateway configured showed up. Bam, HD was on. Here’s the kicker. The FMXi still reported that the Exgine was not present. So, now I have a box that is working, but reports that it is not. Here’s the proof:
Apparently GatesAir will have to come up with a “better” way to inform the end user that the E2X stream is being sent to where it is designated to go. In all this, I also discovered that the FMXi has no built in diagnostics such as ping or trace route. If I was able to ping from this device I would have confirmation that my route was correct and that the ARP table had correct entries without having to go through these extra hoops hoping to see the HD carriers and hear audio.
There you have it. Intermingled manufacturer devices working together. The Nautel HD Multicast+ was not this difficult to setup. I will address metadata in my next post, as another interesting discovery was made regarding PSD data. Until then!
Cheers!
HD Radio = Headache
What is up with HD Radio? Why is it so complex when normal networking protocols have been in place for years? Ever asked yourself these questions? The end user does care how it is received, but if you have to install and configure such a beast you could go bald pulling your hair out. (Assuming you started with hair.)
Since the inception, we have managed to run the E2X, Exporter to Exgine, stream over our MPLS network. We have all the equipment at the studio end for simplicity. More on this in a bit. My 3 stations were humming along without issue until it was time to replace old, aging, or even failed equipment. Now all of a sudden where this stuff is located becomes an issue.
Manufacturers tend to do things differently. This is to be expected. Each radio facility is expected to do things differently. Again, expected. My issue is that those who design and provide this stuff think that radio facilities do everything the same. Guess what, folks. Each facility is build with some basics “standard”, but customized to fit the need of the format, personality, and mentality of those that build it. For my installation I look toward simplicity. I like to keep things simple, so why cannot I install my Exporter or now combo box at my studio location? I’ve done so in the past, but now your new box won’t work this way? Does it not make more sense to install this at the studio especially if it is a combination Importer & Exporter?
Let’s evaluate this. If a combination unit is installed at the studio, then I can have my metadata, my other HD channel audio, and my control locally with a SINGLE data stream to the transmitter site. If this unit is installed at the transmitter site, then I must send a data stream with metadata AND multiple audio streams to the transmitter site. Bandwidth becomes a real issue, especially since we, here, are a full IP based STL distribution system. It is just more convenient and efficient if this is located locally at the studio end. All I need to send to the transmitter is a single data stream for HD and my main audio.
Right now Nautel makes this happen just fine even with their new HDMC+. As I write I have discovered that Gates requires the E2X to be on its own subnet. Nautel I just drop the data on the network at it goes. To make the Gates work on one station an extra box is required, called the IPLink. This encapsulates the E2X on the pipe that connects to the site. Why do I need another box? Save money they say. How? You have to buy another box or redesign your whole audio chain. Seems crazy.
Whatever happened to standard networking protocols? Why does HD data have to be so special? How different does it have to really be? We can squeeze Zoom meetings with video and audio on fairly conservative network, but we cannot send a simple, supposedly, UDP data stream from point A to point B on a different subnet? A private one at that?
If we did everything the same, then we may as well have automatons do our work. Thanks radio for spending so much time eliminating the people that make the medium unique.
Cheers!
Forward: What’s Next for Radio?
I read the trades and hear the talk of the future of radio. The competition between Internet radio and broadcast radio. Many years now we have had this radio stigma that we are the best. Best at what? All of it to me is a moot point. Looks like we in radio are better at content providing than leading the charge to innovate and improve technology. The future will soon see a paradigm change that will split radio as a whole into Content Providers and Content Delivery (technology).
I have talked with some colleagues and manufacturer reps about the future of radio. I get asked the question all the time. Many focus on the immediate future, but I think about the real future as I see it. We are at the beginning with HD radio and I watch closely as other countries move to digital. I watch the trends of our own digital development. I see we keep putting a band aid on old technology like the new RDS2, granted is really cool, and we keep adding to the HD sidebands. This is not enough. I see the trends of where and how content is consumed. I see a change. As we move to all digital, we are looking at the analog carrier going away and becoming one large digital carrier. We can split digital sidebands into multiple channels. Look what we can do with a single digital carrier.
We take a digital carrier and we can split it into a number of channels. For the sake of argument, we choose 100 channels. Yes, that may be too many for a single carrier and it may take a wider bandwidth, consuming the adjacent radio channels as we saw in the Nautel presentation at the NAB show earlier this year. Open you mind and let this sink it. 100 channels. What does that mean? 100 streams of content. Place 10 FM stations on the air with 100 channels each. 1000 streams of content. We see a change. One facility as we know it no longer can handle 100 channels. Content providers must split from the content delivery mechanism, or hardware provider. A large radio group becomes a large content provider group. Look at iHeartMedia. They have an app for that. Content being pushed across all mediums. They are unloading transmitter sites no longer wanting to be the landlord. What next? The transmission systems themselves?
Yes. The transmission systems. The delivery systems. A new business model emerges. Content providers will lease from the “delivery” providers, or Content Delivery companies. The delivery folks will offer bandwidth for a price. No more maintaining a technical department, the providers now can concentrate on content, advertising, business. The deliverers, or whomever you want to call them, maintain the delivery systems. This splits open a whole new world for the providers. They can concentrate on what they do best. The content delivery companies do what they do best. They provide a means to get that content to the masses. They do it now. They just do not have the mass delivery capabilities, but they will.
Who are these delivery companies? Look at your mobile device, and you have found the new content delivery company. AT&T, Verizon, T-Mobile, even Sirious/XM You name it, the game is, or will be, in their hands. The paradigm shift; these companies will hold the licenses to the “big sticks”. This will give them the means to get the mass, one direction, streams off their standard network, and put it out there on their “broadcast” network. It will be the same data we see today, but it is now totally wireless. New “radios” will be capable of picking up and “tuning” into any stream a user/consumer wants, seamlessly between the off-air network and the Internet network, as they will become one and the same. These same companies own their wireless cell networks. They have 4G LTE, 5G, or whatever. These cell sites fill in the gaps and supplement the broadcast signal. The radio hardware will be capable of switching between the two or three delivery paths. The hardware will allow the consumer to provide feedback, or interact, with the content because there will be a return path, the cellular network. The two, broadcast and cellular, will work side-by-side, hand in hand, seamlessly. Look at the connected vehicle. A single point to receive content. A single point to respond and have an input. The mobile phone, or smart phone is the other. The device becomes the center of interaction, and the content provider will now have a direct connection to their “audience”.
This may be difficult to digest for some. This is a paradigm change. Many little changes will take place. The obvious is the physical hardware of the transmission facilities. All digital transmitters will most likely mean lower transmitter power output (TPO), so a currently licensed 50kW ERP facility may be now become 20kW ERP or less. The licenses will transfer from traditional owners to the new content delivery companies. Imagine an AT&T or Verizon owning a broadcast license. Difficult to imagine, but it will happen in this shift. The very heart of regulation will change, too. The Federal Communications Commission media bureau will have to change. The rules will have to change. The way emergency information is spread will change. Go back to our original 100 channel block. A low bandwidth channel may be set aside for emergency information only. The “receiver” will automatically change to that channel if an alert is issued. Alerts can be issued to specific geographical areas. It can be done. The old ways will change, and that will leave a bad taste for many, but it will have to happen if radio will survive, and it is human nature to detest change. Change is painful, but constant.
This change will not happen tomorrow, or even 5 years from now. It will be slow, but it will happen. It is very exciting to think about this paradigm shift. Consumers will be happy getting, and interacting, with what they consume. No more ambiguity for advertisers on how and where their audience is. Content providers will get the metrics they need directly from the devices in cars, in pockets, on belts. It is all data. The delivery companies are already in place doing what they do, delivering content to their network subscribers. A win all around. These are some of the thoughts I have. Maybe I have too much time to think, and maybe now that my thoughts and concepts are out there I can get credit for this paradigm changing concept of the future. (That’s my ego talking.)
Stay connected and I will pursue posting more thoughts on this as it develops.
Cheers!
Carrier Drift & Diversity Delay
Earlier this week, Tuesday to be exact, I noticed something not quite right with my diversity delay. HD radio has added a little more complexity to our systems which requires delaying analog audio to match digital audio so when a radio switches between analog and HD audio there is no skipping or jumping. This makes the transitions smoother in high multipath areas and only sounds like a quality change if the delay is set properly. Knowing I had an issue I began to look into it when I received a call from our third-party frequency observer. Our carrier frequency was off by -780 Hz. Though within the legal limits, this was a large difference than the month prior. What changed?
The technology for running IBOC, In Band On Channel, digital radio brought along some new challenges and some more things to monitor and look at. In this case we have two things occurring: Diversity delay drifting and a carrier off frequency. With the new technology a source clock is required to maintain sync among all facets of transmission, and this is a 10 MHz reference. All normal installations have a GPS signal fed to the Exporter which has a built-in receiver. This produces the reference 10 MHz clock. All normal installation uses this clock through the Exporter to sync their exciters, so the exciter is now synced to the same 10 MHz reference. Most of the time this works. In our case, on one station, it does not. All four stations have Exporters located at the studios, and three of the four have no issues with the exciters syncing. The third seemed to have some issues with this, so a 10 MHz GPS reference was installed at the transmitter site to clock the exciter directly. This was my starting point.
It was safe to conclude that there was an issue, somewhere, with regard to the reference clocking since both diversity delay and carrier frequency were affected. It was time to check things out at the site. The ESE-110 GPS reference front panel display showed 2 green LEDs. GPS lock and power. Good sign. The Flexstar exciter showed no errors. Green LEDs and diagnostic screens showed good things. I placed a spectrum analyzer on the 10 MHz output of the ESE. I measured 10 MHz. Actually it was slightly lower, like 10 Hz, but then again it is an older spectrum analyzer and probably needs calibration. I used a TFT 844 to measure the frequency shift in conjunction with the spectrum analyzer. Yup, it was there. Since I wanted a third party measurement to confirm, I called him up. I switched to the internal clock of the Flexstar. Frequency changed and swung to +110 Hz. Better. The diversity delay settled down, too. What was up with the 10 MHz input?
If the ESE output was within spec, and a call to ESE verified this along with the only indicators, the green LEDs, then what is up with the exciter? Again, the exciter seemed to be good with the external reference according to the indicators on it along with the diagnostic screens. I did not find the schematic at the site, another long story, so all I had was the operations manual and block diagrams. I remeasured the 10 MHz signal. I stretched out the bandwidth to look at the “hump.” All the manual says is a max of 10 dBm, 0 dBm nominal, and it is used for carrier sync purposes. They better modify that to say it is for ALL frequency references! Mental note on that. I’ve been running this configuration for a year without issue, so what changed? I stood there staring at the simplified block diagram of the Modulation Chain. That PLL feeds the FPGA and D/A module. Two different mixers. Both having issues. I read the short paragraph on the PLL. The 10 MHz reference input is first amplified and put through an AGC loop for level stability. I lacked stability.
My what if moment came at this point. I have had zero, none, nada, problems for a year with my current configuration and a fairly sudden change occurred. If they are amplifying the reference input, what if the amplifier has gone bad in some way. I dug through the spectrum analyzer bag knowing I had a couple of in-line BNC pads. I took out the -20 dBm pad, slapped it on the output of the ESE box, and reconnected it to the Flexstar exciter. I gave it about 10 minutes, though I didn’t have to, and took a diversity delay measurement. Yup, had to change it, so it was time to dial it in and see if it stays. I got the delay down to a very respectable -0.0008 s. At that value I should surely see a change if my solution did not work. I gave it about 2 minutes and rechecked. -0.0004 s. I gave it 10 minutes more; -0.0005 s. Before it was changing rapidly, now it seems to be locked in. I gave a call to Harris. While talking with support, I checked again, -0.0003 s. OMG, this may be working. I emailed my third party to take a measurement while I was busy talking with Harris. No immediate response, but I was not too concerned. The Harris tech was actually surprised at this solution, and after our talk concluded that a new PLL on site would be prudent as all indications now pointed to that as the culprit.
I packed up and blessed the site. I returned to the station and took another reading. The first in about an hour. If it was drifting now, it would show it. -0.0005 s. I was beside myself at this point. What did I stumble upon? It has never been this stable. Before leaving for the day and my tax appointment, I took another reading: -0.0009 s. So far so good. After my appointment, we were out eating dinner (yes, we owe the government a couple of bucks) I received an email from my contact. He listed the times of measurements and the error, the last entry was “6:47 PM. 0 Hz error ** Wow! What did you do?” My solution was holding! I came into work this morning, and I checked my delay again: -0.0004 s.
I now have a PLL module on order with Harris as we have no idea how long this one will last. From what I can figure the amplifier section of the PLL has an issue. The 10 MHz reference was getting distorted and creating a new frequency that offset the carrier frequency. In addition, the distorted signal was “outside” the specification for the unit to lock the diversity delay which was free-running allowing it to drift over a half second. Talking with a colleague we both concluded they may want to install a test point or provide a software controlled pad on the external 10 MHz input. For now, the problem is solved. I am tempted to see how long this lasts or if there will be further deterioration causing drift once again. Happy troubleshoot!
Cheers!
An Importer Upgrade: Lesson’s Learned
A couple of weeks ago I decided to pursue an upgrade to our Nautel Export+ and Importers. For those not in the U.S., this is the equipment that makes our HD Radio channels work, or digital radio. The old Exporter and the Exporter+ units upgraded just fine. It really isn’t that difficult. The Importers were a bit different.
My upgrade worked out well. First I had to update from Windows XP SP2 to SP3. Well, the boxes are so old I had to find an executable upgrade package on the TechNet site. I found it and it worked. Why did Windows Update not work? As mentioned the boxes were so old and all automatic updates are disabled due to the fact that the software used for HD Radio does not get the continuing testing required to keep up with OS changes. The Nautel version 4.4.7 update specifies Win XP SP3. The most time consuming part was using Windows Update to get all the current, laugh here, patches. Done.
Importer update: This was straight forward too. I skipped a version, 4.2.1, past 4.3.1, to 4.4.7. All installed well and even my BTC (Broadcast Traffic Consortium) station came up just fine. As we were pursuing an HD2 channel, I looked closely at the Capture Client for the secondary service and discovered that the second audio card was not there! My brain started to wonder what happened. The OS saw it and the Orban PC Remote software saw the two audio cards. Now what?
After a reinstall of the 4.4.7 software, the reinstall of the Orban audio card drivers, and more checks to see what I may have missed, I did not get anywhere. I contacted Nautel and this stumped them. I decided to contact iBiquity. They heard of some issue with the Orban PC1100 cards, but did not have an answer. I contacted Orban and they did not have an immediate answer. More suggestions of removing and reinstalling drivers and software. I decided to dig a bit more.
At no time did anyone mention the PC1100 version. I visited the Orban website and checked the download section. I discovered at some point the software and drivers for the PC1100 audio cards was updated. I usually keep up on updates, but, again, with HD stuff you do not touch it unless instructed to or forced to. I figured I had nothing to lose, so I downloaded the software and installed in on a machine where the Importer services have not been required. It worked! I notified all parties involved. Everyone assumed that this update was applied. Well, again, I do not apply any updates unless there is a confirmed reason when it comes to the iBiquity equipment. It is mentioned in all their documentation that automated updates and any other updates be cleared first. Well, a bulletin or something could have been issued with the latest requirements and no one would have had to worry about this update.
I updated the other two Importers and all audio cards are seen and work. Lesson learned. Update that audio card and drivers if you have not done so. This applies to anyone with a box that is at least 3 years old or older. I see that Orban now has the PC1101 audio card out. This is 2 audio cards in one. Anyone have experience with this one?
Lessons are learned, and we keep learning everyday. Keep your stuff updated within reason! Hopefully my little exercise will help others not fall into this little trap. Have a great weekend!
Cheers!
Playing with HD 2
Well, I will start by saying I am not a huge fan of the HD technology for digital radio here in the U.S. I see all this progress on all digital DRM and DRM+, but I do not, and have not follow it that much. I do believe the future is an all digital solution, but what type and when is not clear. In any case, as an engineer we are at the whim of either programming or some corporate mandate. This week it is at the whim of programming wanting to utilize an HD2 channel.
First, as I know some other mandates are coming down the pike, I decided to update all my Exporters and Importers to the latest software/firmware. Believe it or not it was not that difficult. Over the years it seems to have gotten a bit more stream-lined. The thing that makes me laugh is that, just now, the Importer software supports Windows XP SP3, so I had to update the machines from SP2 to SP3. Since SP2 is no longer really supported, I had to download from Microsoft a update executable to SP3. Once installed all the Windows Update stuff started working again. My question is will any of this stuff work on Windows 7 or 8, or will it go to a Linux based OS like the Exporters? I guess I will know and learn about that some day!
To add to the complexity, the HD 2 will be run on our simulcast stations, so I first attacked the main and got that running. I then performed the configurations for the simulcast station. All works pretty well I might add, but I did discover an oddity. When configuring the Capture client for the second station, I noticed that I had one, and only one choice of sound card. This made me wondered how I would know if I have my audio feeding the “right” one. I did a bit of digging and everyone says that if there are two sound cards, they should show up in the list to be selected. That is definitely not the case on ANY of the Importers I have with that software and version. All have 2 sound cards. No where can I find in any configuration where the capture client gets its information on sound cards. The Windows OS shows both, the Orban software shows both, but not the iBiquity stuff. When I receive a definitive answer I will follow up with a note.
So, I had to determine which is the “right” sound card. Yes, the station is “out of range” to monitor HD at the studios, so the only test would be to feed audio to both cards, get to a receive location, and then disconnect one to determine which is correct. Logic prevailed as I chose the proper one initially. Now if this programmer goes nuts and wants an HD3, well, then we have a new issue: How to get the second sound card to feed that stream. I guess I will cross that bridge when we get there. For now, things are ready to roll when the programmer decides to pull the trigger.
My conclusion is nothing is easy or intuitive with HD and the iBiquity hoops we jump through to make this work. Some day I will gather my thoughts and post what my future of radio will look like in the fully digital world.
Cheers!
HD Equipment Placement
Feel free to respond to this one. I should make a poll and get info that way, but I’m lazy, or not.
Where do you prefer to place your Exporter and HD equipment in general? Mine is at the studio. I have many issues with Harris, but none with Nautel. I have been asked, and I hate to admit it considering, to place the Exporter at the transmitter site. Of course they I will have to do another GPS installation, but that’s life.
Do you have any compelling feelings either way? If you would like I will post results after NAB.
Cheers!
Transmitters and their Quirks
We spent the week working with Harris on the HTHD+. More precisely we have been working with them on the FlexStar exciter. Apparently we have some sort of PLL anomaly, or at least that is what we are investigating now.
We have limited connectivity to our transmitter site, so we use a single T1 circuit that carries our main audio and our HD data. This bottleneck seems to cause a clocking issue and when it gets too far out of whack (for lack of a better descriptor) the PLL goes nuts and mutes RF on the exciter. With more information from our frequency monitoring service we discovered that the transmitter was drifting in frequency, too.
We shipped our exciter back for evaluation and have installed a loaner. We went to air on it Friday, and so far we have been on the air since. I will be checking the PLL logs we are collecting to see how this exciter deals with our bottleneck of a data network.
I cannot blame any manufacturer here. I do feel that iBiquity could have/should have done a bit more testing of their algorithms and encoding so such issues could be avoided. There are many stations with limited bandwidth to their transmitter sites. If we were not forced to jump on this HD bandwagon so soon, maybe this situation would never have happened.
92kHz subcarriers and HD
Has anyone run into issues with 92kHz subcarriers and HD? Seems that when I turn on our HD carrier our 92kHz subcarrier client complains of noise or static. It is a crackly type sound from what I hear over the phone. It goes away when the HD carriers are off.
My initial feeling is the radios used to receive the subcarrier are sub-par and do not do well with the additional carriers turned on. We do not have that issue on another station with a 67kHz client.
As always I am interested in your thoughts and opinions. I will post any of my findings.
Tech Notes from the Field 