Loss of Connection Errors?

August 17, 2022 Comments off

Why do we always start of with “it’s been a busy week”? I would hope we are busy or else someone out there will find our presence superfluous. Always wanted to use that word in a blog. I will say an average week with an interesting find, and we are only half way through the week!  As we all do more and more IP based infrastructure, we get to troubleshoot more and more IP based issues. We send audio all over the place via IP these days, so when a codec reports an unusual amount of errors, even though it is not a main, you look into it. As we progressed to a MPX over IP solution, my audio codecs are still online as backups, and I do check these on my remote control for any anomalies. I saw one which was troubling, an excessive amount of Loss of Connection(LOC) errors.

As I saw these errors on both codecs, I began my investigation at the studio end in the comfort of my not so comfortable chair. Software reboot of both codecs was first. Hardware restart of the studio end codec. As it was due for a firmware update, I even verified this was up to date which it was. One of the last things I did before exiting for the day was to connect this codec to the backup codec at the site and see if I was chasing the wrong end.

Good morning, and time to check what the double hockey stick is going on with that codec. Interesting find: LOC errors were gone and the usually expected dropped packets, especially on the Internet side. Looks like a visit to the site.

At the site I did the same routine as I did at the studio. Another software reboot, then a hardware reset, and just a good head scratch as the errors continued to climb. I did a quick check of the switch and verified all other equipment had no issues, and I did not find any. So, I decided to do the tried and true of troubleshooting, and I reworked, exercised, and cleaned the ethernet connections both into the switch and into the codec. I checked for proper operation and began to monitor the situation. No immediate count increase, so looking good. As it is a transmitter site visit I did some routine cleanup. After that time where I saw upwards of 50 or more LOC errors before, none were recorded! Connector cleaning it was.

I checked when I got back and all good. As of writing, a few hours later, still no LOC errors. I will do my periodic checks, but it all looks like life is once again in balance. When tracking down and troubleshooting don’t forget to include connectors and connections in general especially at transmitter sites. Think about how many years its been since you have touched a connection at a site. Usually if nothing is wrong you don’t touch it, but if you have an issue, clean things up and get back to a clean base.

Categories: Equipment Tags: , ,

Dante Certification

August 16, 2022 Comments off

So, Audinate changed their training program with new videos and content. Covers all their new stuff. In addition, though not as in depth as some of the training can be, and may be covered under Level 3, it is a good improvement. So I spent some free time over the last week to peruse the training videos, and today I took the test(s). I am now Dante Certified Level 2 2nd Edition!

Test(s) you ask? Yes, three of them. No, not long, but broken out into 2 mini tests and a simulation portion. The first two are multiple choice and the simulation you are given instructions to follow, and you do it. I see a future test which will be less step by step and more here is what you have, this is your goal type format.

Level 3 is geared toward enterprise and large systems, so it will be a bit more challenging, I think. I will do some homework and start the Level 3 process. In the meantime, if you need any Dante help, I am, well, Level 2 certified.


PS: When I receive my “label” I will post it.

Categories: Equipment Tags:

Covid Round-3? Tieline Via Ready

January 7, 2022 Comments off

Looks like Covid has hit with round 3, 4? Open, closed? Stay home, go to work? Politics aside, this has been such a rollercoaster ride, and has been quite frustrating. Well, take that frustration out and go ahead and try something new. As we have gone through this before, I spent the week preparing for the potential, looming situation of air talent working from home, again. This time I have the opportunity to do what we have read about from Tieline, multiple connections to assist in a network delayed world.

What, you ask? Multi-talent show, two people for this one, located at different homes/locations. What happens when these two connect only to the station? Talent 1 speaks, audio goes to the station. Then the mix-minus feed to talent 2 is sent from the station to talent 2. Network delay gets a bit longer between the two talent due to this double hop. The solution is to create a feed, or stream, between the two talent. Enter the Tieline Via where I chose to implement many “factors” or better yet, resources provided by Tieline. Some are free, the Tielink server for example, while others are licensed. It is all based on needs or desires. With that said, I use the Tielink server, Cloud Codec Controller, and capabilities of the Via.

Being a power user I decided to setup my two units by connecting them to independent LANs as I know this is basically how the final use will be, and use the Cloud Codec Controller to connect and configure. Doing so, I open up each respective unit and created a new profile or program for each utilizing the dual mono program. On each the first stream is configured to connect to the station. I have three Merlin Plus units, so must designate which one and which port. The second stream is a bidirectional stream between the two Via units. Being that they are not a dedicated IP address behind a home router, I implement the Tielink server. Either unit can connect to the other.

The test setup looks like this:

Two Via Units Chatting Away

I setup the units to use either the wired LAN and/or the built in WiFi. This way I can cover the fact that some homes do not have a wired connection these days. We all know that audio over WiFi is our last resort, so when the talent picked up their respective units I provided a network cable and asked that if they could, plug ‘er in.

The audio matrix editor makes this a breeze in audio routing. It looks like this:

Matrix Editor

The fact that I am using the Cloud Codec Controller makes for quick remote changes as needed. I hope I do not need it, but if one cannot connect to the studio, I could route it through the other’s Via keeping both air talent on the air. The current setup is they converse through the direct connection cutting the delay. The producer at the station can just take them out of cue if the discussion gets heated! 😉

I did run into some interesting “gotcha” moments when doing my setup and testing. First there is the company network routine. If I used the wired network on both, as expected, no issue. If I put one on a different, or outside network, the firewall would not allow the connection. And, if you think you are smart and put both on the same WiFi network, you are not. The units would not see each other. This occurred with a standard “house type” WiFi and a WiFi setup with a hotspot. Though you think you are on the same subnet, the WiFi router must have a setting to allow for the two to talk. Once I put them on independent networks, outside of business, everything worked as expected.

The only Tieline side gotcha was the default Dual Mono mix matrix was not populated with any default audio routes when I started. The recommended cross points were indicated, but not selected. It was just extra work to click each cross point needed to do what I wanted. This included headphone feeds and what encoder to send the audio. I was baffled by this at first, but nothing preventing me from finishing the task. I did have to make a call to reacquaint myself with the Tielink server. Turns out to be quite easy.

I am now ready. I hope we do not have go to this, but the Via units are deployed and have been tested from their temporary homes. Let’s continue to do our best to get through this Covid stuff.


Categories: Equipment Tags:

New Year: 2022

December 31, 2021 Comments off

Well, we made it to another year. 2021 seemed to fly by. I hope most faired well, and I feel for those who lost loved ones. With Covid the way we do things has changed dramatically. We learned real quick our dependence on a strong infrastructure as seen in remote work. We learned how to cope with the change. I hope everyone stays safe and healthy as we head into the new year.

Happy New Year!

Categories: Management Tags:

Aphex Channel – Keep It!

August 3, 2021 Comments off

If you have an Aphex Channel Voice Processor, KEEP IT!

Of all the mic or voice processors out there I find the Aphex Channel one of the best for studio use. There are many good ones, but this one works the best. My major beef with this unit, and the company, is the lack of support for the hardware. So, let’s get into it and I will end with why I like it and how I set it up.

You will find that your unit will die. Yes, power cycle that puppy and it will not come back to life. Make the mistake of pulling a phantom powered mic, or plugging one in, and it will kill the unit. Why? Crappy power supplies. The power supply is easy to replace. Stay tuned for a tech note on how to do so as I start to make notes and lists of things to add here. You paid for this unit, for about $75 you can make it good again. You can purchase the power supplies through distributors like Broadcasters General Store (BGS). How bad is this issue? I replaced 15 of them in the last couple months. A new processor will last about 3 to 4 years before the power supply decides it doesn’t want to work again. BTW, the tube should last a good 10 years as one of my now retired 230s has proven.

I know I worked with Marvin with the 230 and Channel before Aphex sold the company. Rode, the maker of the now famous RodeCaster, purchased Aphex. It is very obvious that they do not care about the hardware and purchased Aphex for the technology as it is incorporated into the RodeCaster for mic processing. I say they are missing out on a lot of money by ignoring the hardware side of life. The design is the same as the original and that definitely includes the power supply. My suggestion to them is to make some minor tweaks and continue to supply and support us in the field. One tweak is cooling. Maybe include vent holes near the power supply as the single set of vents next to the tube is not conducive to air flow through the unit. I also suggest a little better support system. I’ve tried email via the web page, and direct contact. The latter is tough as they make it very difficult to speak to a human. As two new units were sent through “under warranty” and came back not working, I felt it was easier to just take care of it myself, and it has always been a power supply.

What I like and I cannot seem to find in other voice processors is a gate. Many do not even have a gate. Why? Studio and even live performances do use gates. Maybe in today’s world of production all this is done on the computers, but live stuff is live and needs such features. I have tried a replacement Presonus voice processor. It is a good unit, but the first and only complaint I received is no gate. Maybe these “talent” are spoiled, but I found it interesting that is what they noticed. If there is a main reason to keep the Channel is the gate.

For studio use, set that unit up with moderate level and put that release around the 9pm position, or slow. Set that gate threshold and the depth you wish so it doesn’t chop in and out. Set the Big Bottom and Aural Exciter for about 12 o’clock and adjust from there. Use the parametric EQ to get rid of that annoying air conditioner or some other background mess. Set the output drive to your best level on the console and you are done. You will find the Channel is smooth at controlling the peaks and the slow release helps keep a constant level for the talent.

Keep that Aphex Channel. Spend a couple bucks to replace that power supply. Enjoy. Until I find something that I like better, I am keeping with the Aphex even with the lack of support. Why mess with a good unit. Maybe someday Rode will find it in their best interest to improve on this piece of hardware.


False Issues

May 26, 2021 1 comment

So, all I’ve been hearing this week is how a programmer thinks a station doesn’t sound as loud as its sister station. Our tech director keeps claiming it has an issue. I sit back an observe the stupidity going around regarding this situation.

First, the measurements of said station says its modulation level is just fine. Compared to all the stations I’ve listen too in the area, it is right with them in level.

The station that is louder is over modulated. I have no prove or measurements as it is “taken care of by our other engineer”. It is overly loud. I know this from experience. It is also very fatiguing. Yet, the programmer wants this station to sound like this awful sounding station.

Add the fact that the station which is “not up to par” is the #1 station in the market makes the decision to mess it up even harder to swallow. This station has been #1 for some time. I don’t count holiday music time.

So, the other day I observe the replacement of the processor. The station has no level what so ever. Notice I did not write “whatsoever”. Turns out said processor does not really process the AES output audio, and if it does, it has absolutely no peak control. I refrain from mentioning manufacturers on this for now. And, yes, on two stations we have processing at the studio, so audio is sent to the site versus a composite feed. Yet, they claim the station is not as loud as the other AES audio fed station. Both have identical air chains from start to finish. Audio levels measured on my Inovonics tuners show identical levels. Go figure. In my opinion the station is just fine.

What are your feelings on this? Educate a programmer or just continue to chase the tail? Right now I am just sitting back and watching the fun. The tech boss is adamant the processor has an issue. The other engineer just plays because it is something cool to do plus he wants to the be hero if something works. This is what our business has come down to. The experienced people have moved on and we are left with those who just don’t get it. Or am I too stubborn?


Categories: Management

Troubleshooting Annoying Problems

April 11, 2021 Comments off

You would think that when purchasing pre-made, or manufactured, cable they are built properly. Millions of XLR mic cables are made and you would think the process would be flawless. When it comes to troubleshooting annoying issues, trust your skills and your instinct. You may be surprised what you find.

My annoying problem was a noise complaint within our road system for play-by-play. This system was built 5 years ago, but only this Spring did it become a problem, but only locally in the booth. The talent and producer complained about a noise that came and went, got louder, then soft, and did not seem to go away when equipment was connected, moved, or changed out. Granted, there was always a low level background noise, but never one that created any nuisance. After Spring Training was done, I had the gear dropped off for further evaluation and troubleshooting.

My first approach to troubleshooting is to recreate the issue if I was not there to witness first hand what was going on. Maybe how I set something up a bit differently than the end user, and we all know when something goes out in the field, the users do not always do what they were instructed, and once out the door, controlled environment can and will change, causing the field person to make changes. In this case, I setup just as I would if I was “out there”. As I had a few discussion with the producer already, I was initially looking, and listening, for a ground loop type noise and issue. In addition I was looking for a bad ground connection in general as this noise grew louder at times. It also changed at different venues. I hear noise. I also knew it was in the monitoring side of life as this noise never made it to air.

After a few minutes of wiggling and checking if all connections were good, the background noise we grew accustomed to was there, but louder, so I understood their complaint. As I checked all cabling for the monitoring or local, return, and talkback audio, I was not able to isolate it. At this stage it was time to methodically check each and every connection for each talent. Starting with channel 1 on the mixer I stepped through and compared listening for any nuance between positions. I also expanded my search to outside the monitoring. I soon discovered that if I unplugged a mic cable the noise went away. Interesting to say the least as I mentioned this noise never made it to air. I moved the cable to another input, and discovered the noise continued. As I also know the equipment gets jostled around a bit while traveling I decided to check for any loose mixer components. My method: Treat it like it is used in the wild. So, I gave it a solid, but not destructive pound with my fist. With said mic cable plugged in, the noise got loud, then dropped again. I repeated without the mic cable in. Silent. Mixer good.

I have not isolated the issue to a mic cable. Remember, this noise was only in the talent and producer headphones and not on air, yet the mic cable was definitely an issue. I swapped with a known good cable, and no noise. Always use a known good at the point of localizing the potential culprit. In some cases use more than one known good to test and be sure. Out comes the cable tester to verify my findings.

Here you see an “X” pattern on the tester. Bad Boy This is definitely not normal, and this is a pre-made, or manufactured cable. This mic cable was made this way. Look closely at the pattern and notice that this cable was made unbalanced. This was not a “failed” cable as I stretched and twisted and kinked the cable throughout the length to induce an intermittent. It never wavered.

Now this is the cable test of the known good cable which I eventually used as a replacement. Good Boy As you can see here, there is a nice one-to-one pin match between the two ends.

After the mic cable was replaced, I tested the whole system again. This, my friends, is a very important step. Though at this time I found the issue, I want to make sure there are no others. In this case all was good, so I put everything back together. Once secured, I did one last check.

Why the noise from this cable? A good question. As the picture showed, this cable was made unbalanced, and since the low, pin 3 side, was connected to ground, pin 1, all would work just with reduced level. For a mic input on a mixer that is electronically balanced, with a transformer, the common mode rejection was thrown out the door. In addition, the cable itself was now susceptible to noise and could act as an antenna, allowing this noise into the system. As headphones are wired unbalanced this noise can carry through to the headphones. Since the output of the mixer is balanced and wired to the balanced input of the codec, the noise is rejected as it appears on both the high and low signal leads which are out of phase feeds, and no noise on the air.

All this was quickly fixed by just using common troubleshooting practices. Throw a little instinct in there, like the rap with the fist, and we move on to repair or replace. This setup is currently in use this weekend and no annoying noise. Talent and producer are happy. Hope this information helps, and don’t rule out pre-made cables, they could bite you later.


Categories: Equipment Tags: ,

GatesAir FMXi 4g Metadata

March 19, 2021 Comments off

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, a netmask of, 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, the netmask will be Or if you configured it static and chose a mask of to keep it manageable, then that would show. The gateway for all these would be 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.


Categories: Equipment Tags: ,

GatesAir FMXi 4g Importer/Exporter

March 15, 2021 Comments off

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 address. Exgine is on 192.168.20.X network, so the routing table is configured to send data to the 20.x network, use 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:

Exgine Fault but HD Carriers on Transmitter

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!


Categories: Equipment Tags: , ,

Happy Lunar New Year!

February 11, 2021 Comments off

Wishing those a happy and prosperous new year. This is the Year of the OX!!!

(Doh! I put goat by mistake in original post.)

Let’s hope the attack on Covid-19 continues to progress and we can get things back to semi-normal sooner than later.


Categories: Uncategorized
%d bloggers like this: