Archive
GatesAir FMXi 4g Metadata
Metadata. Title, Artist, Album information. Artist Experience. PSD. Data. All data. Different names for data. What can be so difficult about that? Everything. Format, type, destination, were it comes from. The FMXi says you don’t have to do much to get it working. Well, I beg to differ.
I will start with the easiest form of data used in HD, program data. This is known to some, all, few, as PSD, Program Service Data. Basically it is Title, Artist, and Album information. Nothing special, though different devices accept different formats. Today, the formatting is pretty much standard. According to GatesAir one can send PSD data to any of the three NICs on the FMXi. The network interfaces are labeled as Management, E2X, and PSD/IMP. Each is separate and the device is its own switch and router. Easy enough. To keep things simple and create a standard I chose to send the data to the PSD/IMP interface. Gosh, PSD is in its name, so why not use it.
First be aware that none of the three network interfaces can live on the same subnet. I tried to configure the PSD/IMP NIC to reside on the same subnet as the E2X. Before this device I had my Importer and Exporter living on the same network. Flat network. Simple. To make this installation a bit easier, our IT made a subnet which is basically the metadata subnet. Arctic Palm and JumpGate reside on this network and worked prior to the advent of the FMXi, so logic dictates to send this data to an interface on this same subnet. Guess what. Did not work. Some digging to do and from the Arctic Palm computer I can ping this new port. Yeah. Double checked port assignments. HD1 PSD data default is 11000. Easy enough, we are using the defaults. Nothing. Hold up. What?
Shoot, let’s try to send it the data to the Management NIC. By the way, this is also known as the WAN interface within the FMXi, so it creates a bit of confusion. I call it the house network, or management port. I know the interface works for the Web GUI or how else would I be able to configure the device? Send data there, I say. Nope. Not. Or as I like to say, Nicht, Nein. OK, remember my last post about routing tables and ARP? Let’s check them out! And, of course, all checks out. Arctic Palm and the JumpGate IP addresses show up in the table and references the proper subnet. Routing? Should not be an issue. Devices and interfaces configured to be on same subnet. Devices show in ARP table.
Let’s try the E2X interface. OK. A simple change again to the devices delivering the data. PSD shows! As my daughter likes to say, and I guess many teens these day do, wait, what? The routing table doesn’t show any “new” gateway. IP resides on same network. It works. Hold on a moment. The PSD/IMP interface is configured to be on same subnet as the devices delivering the data. Said devices show in ARP table. Not data. E2X interface works? Same with the management interface. I now conclude the claim that PSD can be sent to any of the three ports is false. Unless there is some firewall thing talking place on our network, there should not be an issue here. Side note, our network is so complex that only 1 person in our building knows at least part of it, but will not share with the rest of us. I prefer to keep things simple.
Time to move onto Artist Experience. Believe it or not, we got this one working before the PSD! At the start we did not get the data to flow properly, but after a little poking around we tried something that is not suggested at in the FMXi manual. Though the JumpGate which aggregates this information is on the “metadata” subnet and has access to the outside world to retrieve the artwork, etc, as we found out with PSD it did not get to the FMXi. This one was a bit different, and since we knew it had something to do with the outside world, it was back to the routing table. The decision was made to add a “catch all” default route. In the table it was time to add a destination address of 0.0.0.0, a netmask of 0.0.0.0, the gateway to the outside world which happens to be on the management interface and subnet. Once this was done, Artist Experience was on the radio. Simple fix, but not the most intuitive.
BTW, based on the FMXi interface configuration, the unit will define a “system” route based on IP configured. If you have the management interface configured for 10.10.10.10, the netmask will be 255.255.0.0. Or if you configured it static and chose a mask of 255.255.255.0 to keep it manageable, then that would show. The gateway for all these would be 0.0.0.0. By doing our “fix” we created a default type route which seemed to make the unit happy with Artist Experience. Maybe if more digging is done the route table could be manipulated such that PSD could be used on any interface. The issue is the manual does not say that. It does not suggest that. We make the notes so we know how to put the next one in.
I suggest if/when you install the FMXi 4g you brush up on the networking skills. If you have a simple network, the better. Unfortunately you cannot configure the three interfaces to live on the same subnet, so if you do keep a simple network, you will not have to configure all three, but you will want to configure the management interface as that is your Web GUI, and you will need your E2X interface configured to ship that stream to your Exgine. I do like the built in diversity delay and it seems to be holding, so that is nice. Good luck. I hope this information helps you install and troubleshoot the FMXi. Maybe in some firmware update GatesAir will include simple diagnostics, like Ping, to help verify network settings and routes.
Cheers!
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!
When Old and New Don’t Mix
A few months back the decision was made to “rush” a MaxxCasting system. The company teamed up with GEO Broadcasting and GatesAir to have this system installed. Currently in analog mode it works fairly well. When the baseball season finally ends, we become the test for doing HD as well. Check it out, it is interesting. The part I have issues is making the old, a 2006 Harris (GatesAir) HTHD+, and the new, a Flexiva FAX50 exciter, play nice.
I knew I would have issues from day one with this installation. Having no involvement other than being told what needs to be done, providing input was limited. At the onset I informed everyone on this project by interjecting a simple question: Will there be any issues utilizing our old HTHD+ transmitter for this? An early 2006 edition of the HTHD+ transmitter as we were “forced” into the early adoption of HD radio, this transmitter installation was a rush job from the get go. As an amplifier I have never had any issues with the transmitter, but I have had issues with exciters. We had 3 different Flexstar exciters in this thing, yet I have only replaced the tube 4 times. Anyways, the answer to the question was basically, yes, don’t worry about it.
Without being involved other than do as you are told routine, the day came to install the FAX50 as an exciter. Without a full rundown of the Geo-synchronization of the whole system, let it be known the Flexstar was not capable, thus the swap. I has the exciter out. I had the filler plate. I had cable adapter kit. Whoa, hold on. The kit labeled for a Z series transmitter? I told everyone this was an HTHD+. Hmmmm? Let’s proceed with getting the new exciter installed in the transmitter. After the first indicator of an issue (the cable), the second indicator of more fun to come was the fact that the exciter did NOT go into the transmitter! I was told otherwise, and I was provided with no instructions. Phone call time. Sure enough, the interface kit was wrong, and no, the FAX does not fit inside the transmitter, but must be externally mounted. New interface cable kit and instructions were on their way.
The new cable kit arrived with the new instructions. Now things began to make sense. I cleared out rack space and place the exciter in a location that was just accessible to comfortably been seen, i.e. not at the top of the rack, but at least a quarter way down. That was the maximum length of the new cables. Installation complete. Testing into the station load I got to learn how to setup the exciter as it did not come setup for our station. It was setup on the wrong frequency and as a transmitter, full 50 watts, not as an exciter of which we run about 4 watts. Details of this for another time. Rest assured it was not too bad and I had the transmitter back on the air soon enough.
Mixing the old and new. As we all know, the HD E2X, or Exporter to Exgine, stream will have packet drops on occasion or some other ISP induced oddity. In the case of anything somewhat prolonged or unusual, the exciters are designed to shut the HD off, suppress the carriers, and the station goes analog only for that brief time. When the E2X stream returns, the exciter detects it and HD carriers return. All good. Well, the FAX series exciters are some fancy boxes and are designed as stand alone transmitter. These range in power from the 50 watts to high power. As such when the E2X is gone, FAX is designed to drop power level and normalize to analog operation. When the E2X stream returns, the FAX adjusts, the power level changes to accommodate the HD carriers. All good when in an all inclusive box, when driving an external transmitter it causes some serous output power swings, and at times even a brief no power out. Our transmitter is licensed for 18kW TPO. I have witnessed this drop to zero and shoot to about 20kW all within a few seconds. I had four occurrences just this morning of lower power alarms followed by high power alarms. The APC and drive level required drops suddenly during this incidences that the transmitter PA cannot handle it. I wonder what stress this will place on my recently replaced tube?
GatesAir is aware of this and is considering options. I have suggested to the company they may wish to just upgrade the transmitter. We will see. I think the lesson that reinforces my philosophy is not to attempt a new project which mixes technology without considering all the pieces, and be prepared to invest in replacing the old even if it is going to cost you. Consistency is key to a smoothly running plant.
Cheers!
Fixin’ Things: Week’s Update
Figured I would try and and get back into the swing of things and update a bit more often. Mostly boring stuff, but, hey, someone has to do it! This week I have a bit of F.O.R.D. action to mention along with plans to repair a Nautel NV20. Also a little fun with NexGen and Sage communications. A little bit of everything.
F.O.R.D. = Fix Or Repair Daily. Harris Z10. This box just sits there and is used on occasion when I do a Nautel update. As it sits, it fails. No, it doesn’t need to be turned on, it just fails. I should clarify, it shows Faults. Currently 4 when I look at the logs, used to be 5. Let me remind you, it gets these just sitting idle. Apparently 2 of the 4, was 3 of 5, are PA modules showing the PS#_OT, or over temperature fault. Again, it isn’t running. A little research and some interaction with tech support a couple months ago, I finally ordered the parts through Mouser and did a test repair. This repair entails the replacement of a capacitor and thermistor. Easy enough except they are surface mount, so I finally got a chance to experience this type of repair first hand. All I can say is it takes patience. Needless to say, the test PA module installed and fault is cleared. I have 2 more to do. The other faults I will act on when I get these obvious ones out of the way. Unfortunately it looks like one of these pending faults corresponds to a dead PA.
But, wait, did I say a Nautel repair is imminent? Yeah, I guess I pushed the old beast a bit too hard as I prepare for an HD carrier increase. I began to adjust the HD PA voltage to accommodate the new power increase and two PA modules said they did not like that, and Poof! I just finished doing some research and I have all the parts to replace them. I even have the tools! What did I find out today? I have version A of the modules and all the latest documents show they are up to C, and they look more modular! The old ones require de-soldering and then replacement. At least it doesn’t look to bad. I also get to perform the modifications that the modules required a few years back to improve efficiency. All in all, I call this fun.
We us IP to control most everything these days, and this includes how the RCS NexGen communicates with the Sage Endec. Sure enough, this week I noticed that the RWT did not fire properly. This is normally caused by the old architecture of NexGen where it just decides to not talk. After a couple of tests I had to do the old CTRL+Alt+Shift+F4 on the A-server so it would load a fresh database. Why it decided to start doing this is beyond me. The other two stations do not have this issue. I know we will be moving off this system some day, so whatever we use better be IP savvy in running all tests and alerts.
Interspersed among all this fun is Microsoft and Windows 10. Thanks. Apparently there is an issue with Win 10 and USB 3.0. At least with some of our stuff, more specifically Digigram and the UAX-220v2. Thought he device uses generic Windows drivers, the system will throw a fault and reboot spontaneously. When trying to track it down, the Event Logs show nothing except the “previous shutdown was unexpected” error. I finally caught a memory dump and analysed it. A reference to a USB device was there. As a test I removed the UAX and that machine has settled down. I think I will need to experiment with a couple of other USB sound devices and see if it is isolated to Digigram or it is more universal issue. Sad if it is the UAX as the beauty of it was plug and play with no special drivers.
If you get a long weekend, enjoy! If not, take advantage of the time you have!
Cheers.
Step Forward, Then Back
Another week has gone by and wouldn’t you know it, that exciter of last week made me take a step back. That Superciter was working just dandy on the bench when I shut down on Friday of last. I had it up to 30 watts running happy as a clam (wherever that phrase came from) into a load. All afternoon it ran until I pulled the plug for the weekend. Come Monday of this week, Mr. Murphy struck.
As usual with these things, I felt I should run another bench test before calling this exciter good. Plugged it in and let it run. It started out just fine at 30 watts. I’m happy that nothing changed while it sat doing nothing for a weekend. We all need time off. I wander through the shop while doing other things. I walk right by the bench late morning and stop. Take a couple steps back and look at the forward power. 16 watts! Huh? Fan is working and I pop the top open. Not heat. Shoot, it’s even sitting under an air conditioning vent. Time to pull it apart and take the test point readings. I start to see a couple of anomalies, though for the most part all readings were good.
I sit down with the schematic and refresh my brains on the previous week pointers on what drives what and who and where. Take a couple more readings as I watch the power drop down below 10 watts. Something is failing and failing slowly. No faults, just no power. OK, if those don’t get enough drive what happens? I’m starting to get the feeling there is a drive issue. Why it didn’t show last week is interesting. I have a brief email exchange with GatesAir. I describe the situation and how it changed from last week. The same conclusion that something is not giving enough drive. We are going t concentrate on the RF drive produced by the FM Synthesizer board. I have a couple of parts ordered, so we wait until they arrive. Let’s see if this takes care of it.
In the meantime, we had our annual fire inspection. Meetings. A last minute invite to Al Salci’s (of SAS fame) presentation of AVB (Audio Video Bridging) was a highlight. Great presentation if you get a chance to witness it. At least I had time off from wrestling with that exciter! Every week is a learning experience, so take advantage when you can. Next week more meets and greets. Let’s see what I learn and maybe even get an exciter repaired.
Cheers!
Engineering Week Successes
Motivation has been lacking. Been waiting a while for the sale to go through, so now we are a new company. Very cool and it looks to be quite fruitful with the resources that appear to be had. Many little/minor repairs have been done since my last post. If you read the trades much in terms of streaming and connected media. While all that goes on there is still radio and still needs to be met. As a broadcast engineer the main deed is to keep our stations on the air!
Granted I had no off air time this week, I did have to deal with a couple of issues. One is an auxiliary exciter that decided not to produce power. This bad boy is an old Harris Superciter. I believe it to be a post-Digit exciter and dates back to 2006. As I had a spare Digit I was able to bring the Superciter to the shop for work. Acquiring the schematics and manual was fun, and I dug up a schematic set, but no manual. GatesAir was able to forward me a manual and another set of schematics. After poking around I got frustrated as I did not know what readings I needed to see as certain points to determine what direction to go. A few more emails and a better understanding led me to testing each stage. Eventually I got really curious, so when I got to the Power Amp (PA), I began static testing the transistors which began to look good. As this exciter is an Aux and just sits there with a quarterly turn on and run I figure it was time to really look for dirty contacts everywhere. Anything I saw I cleaned. I reconnected everything and had forward power! Crossing my fingers, I put the box back together thinking it won’t turn on when I do. Luck on my side, it came on again. Ran it for over an hour into a load without issue. I’ll fire it up again Monday to verify and plan on taking it back to the site.
As if this exciter thing was a pain, one of my main transmitters started doing something odd: It began having power fluctuations. This is an “old” Nautel NV20. Yeah, remember, I have the oldest ones out there at 6 1/2 years old now, so I get to experience the aging process. No faults were showing except for PA module foldbacks and, sitting down, “Module # not responding.” If a PA module is not responding there must be some fault somewhere. I looked at everything. I ran it into the load and watched it. It didn’t matter which module it just randomly picked on as not responding, or two, three…. What else can I do?
I did what anyone would do. Shut it down. Remove each PA module and reset it. While I did that I also checked the fans on each, though not showing failures, I’ve had a couple fail from old age already. Found 2 that showed signs of failing and replaced them. I check the connections to the exciter. All good and tight. Flipped the disconnect back on and let the AUI boot up. I took it slow and selected a low power preset. I stepped to to a low power with HD preset. I went for the gold to full TPO of 10 kW. I watched it with eagle eyes. I dared it to do something. Rock solid. Heated that room up good running it into the load for 20+ minutes. Time to put it back on the air, and it came right up. Again I eyed it. Both via front monitor AUI and via remote web browser, one on the main screen and the other on the status screen just waiting for it to mess up. Rock solid. Absolutely no power wavering. I watched that thing for an hour, and then called it good. The conclusion: Even 20 kW Linux computers need to be rebooted, from a cold boot, on occasion.
Hope all your repairs turn out to be as simple and successful as mine have. Look for the signposts while troubleshooting and take the proper path. The repair becomes easy. (Oooh, a Zen moment there.)
Cheers!
A Little Harris (GatesAir) HTHD+ Repair
Not to focus on anything like this, but, damn, I have not posted in a while. Let’s start flooding you with some real boring stuff! A few weeks back I had the un-welcomed 12:30am phone call from the remote control. How we love those calls. The basics were there: No forward power, off air alarm, etc. I do the normal, let’s try and turn it back on. Nothing. I tried to switch to the Auxiliary transmitter, but that did not happen. My first thought was “great there goes a UPS” which would explain lack of control, but my remote control was working. Up on the Aux site I went. Mind you all this took place quick enough the person in building was never aware of the condition.
Off to the site I go ready to find some melted metal. First lesson of the evening: Make sure all connections are tight and good even on the remote control! A wire backed out of the Phoenix connector on my command for the coax switch. Doh, no wonder it didn’t switch. Fixed that and put the Aux transmitter on the air and turned off the Aux site. (Nice to have an actual auxiliary site.) Crazy how that switch ALWAYS remotely switched until this night. Now on to the main transmitter.
The HTHD+, as all HT series transmitters, has the mimic panel. I see red LEDs for the Plate and a Fault indicators. Well, isn’t that nice. I did just replace the tube a month prior. Let’s see what happens if I shut everything down and start it up again. This usually clears a strange fault or situation especially with a power fluctuation. Wham and Bam. Nope. Immediate slam, in your face, time to troubleshoot sound. I checked the obvious PA cavity and tube. Always check that plate blocker. No obvious signs and no arcing. Jeez, it was clean. Give the tube a shake. Not rattle. Good. Let’s give it another chance, so I turn on the filament, then plate. Same result. Nothing. At this time I take a step back and glance at the big picture. Plate and Fault indicators on the mimic panel. I glance at the High Voltage Power Supply (HVPS) cabinet and there I see it, a MAG OVLD indicator.
How I didn’t notice it when I first walked in I cannot say. Tired or just fixated on the mimic panel. Time to focus on the HVPS. First step is I verified the fault through the multimeter overload faults. Code 21. A cross check corresponded with the MAG OVLD which indicates either relays being open or control voltage was not there. I did all the basic checks: Input line volage, cabinet connections, and interlocks. All good. So, I either had a bad relay or, worst case, a shorted transformer, though I did not smell any magic smoke. I messaged GatesAir via the customer portal, and then studied the schematic. As all line voltages were good I was beginning to suspect a set of relays, and after a nice chat with GatesAir, we determined to focus on magnetic relays 3K1 & 3K2. I set out to do just that. There happens to be contacts on those relays that are exposed. I gave them a little burnshing. I did a quick test into the load. Everything came up flawless. As I had the aux transmitter on the air, I decided to proceed with a cleaning of the HVPS cabinet.
After cleaning up I placed the HTHD+ back on the air. I still find it odd that this failure occurred in the middle of the night. I also find it all that something got in between the contacts on either or both relay contacts while they are normally closed. I did go through a cleaning while I did the tube replacement earlier, but it never occurred to me to burnish these contacts. In addition all was running fine up to that point. As power at the site can be somewhat inconsistent, I wonder if a phase dropped briefly and upon an automatic restart an arc or some dust affected the relay contacts. I have an HT-25, I’ve installed and maintained an HT-30 in the past. I have never had this situation, and they were in environments worse that this.
I love this job as there is always something to learn even if it is a minor, and somewhat obvious item. We do not “know it all” and I love to learn. Pack it in your data bank of a brain so next time the repair is a no-brainer.
Cheers!
Tech Notes from the Field 