Archive
Our New Remote Broadcast Case
Having worked many live broadcasts for radio I have seen many setups. Our setups have ranged from the complex to the most simple. A wide range for sure. We have broadcasts which require four or more mics down to simple “call-in” type hits using the Tieline Report-IT application. Now we put together something for the simple end such that any air talent can set it up.
What does this remote broadcast case contain? Here’s the list:
Apple iPad running Tieline Report-IT Enterprise equipped with Verizon 4G LTE wireless
Alesis I/O Dock
Fostex amplified speaker
Presonus headphone amplifier
2 Shure SM58 mics
2 headphones
associated cables and 25′ extension cord.
The speaker and headphone amp are items we had in house that were either spare or used in other applications that are no longer necessary. Mr. Bill was along to assist in the setup and make sure everything ran smoothly. The headphone amp is used just in case of a two person setup, and noted later as an interface to mono the audio feed. We have found in many cases if the environment is not too noisy a guest does not use, or need, headphones. It adds additional gain for the deaf air talent, too. If the air talent does not need the amp, just plug into the headphone output of the I/O Dock.
We did find in another broadcast test that the iPad will smoothly transition between 4G LTE wireless and WiFi connections. This was discovered when checking out a new site. A little added bonus.
After doing an initial broadcast and testing, we discovered that the Alesis I/O Dock is designed around two independent channels. Input 1 is the left channel and Input 2 is the right channel. These channels are independent throughout the system with no mixing or mono-button capability. The Tieline Report-IT application, being a mono or one channel application, only “saw” Channel 1, so a mic plugged into Channel 2 did not feed audio to it. I voided the warranty. Since the device only cost us $177, I decided to open it up and modified the I/O Dock. This first modification, and I have others planned, was to make sure two mics fed the application. No schematic was available, but I was able to research the chip-sets used and found the AD-DA (Analog to Digital/Digital to Analog) converter chip. Armed with the pin-outs I used my oscilloscope to trace the signal at that point with the goal of making sure the summing occurred after the pre-amplifiers for the inputs. I located a convenient locations, soldered in a jumper, and all was good. An instant mono, or summed, source for the iPad. This modification does not affect the headphone or main out feed of the I/O Dock, just the feed to the iPad, so each channel is in separate ears of the headphones if plugged directly into the headphone outputs. The Presonus headphone amp has a mono button on it, so the device acts as a nice interface for the picky talent. Return audio from the Report-IT application is not affected and feeds both output channels. I do plan on modifying the modification to included a switch so at a push of a button a mono signal is produced and feeds all outputs. Where and how to implement this switch is the tricky part as there is not a lot of space to add it to the I/O Dock, but I will find a way.
Another added benefit of this setup is to allow recording on the iPad using either a third party application like WavePad or even the Tieline application for feeds later. Using WavePad the talent can record and do basic editing, and once complete, email the audio clip back to the studio. If using Report-IT the talent can record a report and either feed it down the connection or, if FTP is setup, upload to the studio. We are currently researching ways to incorporate the FTP feature in Report-IT such that we can upload clips with specific file/cart numbers and have them automatically import them into a RCS NexGen log.
Why not just use a mic adapter and Report-IT on a phone or iPad directly? We do that, too. In this setup the ease of incorporating two microphones was ideal. In addition the comfort level of the air talent increases as they have that physical something in front of them. Some of our staff has embraced this new technology, but others seem to be less forgiving. As we easy them into it, we make it simple and functional for them. Soon they will be able to run out with a setup on their own and not think twice of it. Getting things done. That ‘s what it is all about.
Alesis makes a product called the I/O Mix which is a 4 channel mixer. We are looking into that, but this is taking things backwards. There may be a use for such a setup in the near future. For a more complex setup, Mackie makes the the DL608 and the DL1608, 8 and 16 channel, mixers for iPad. These are sweet as they incorporate the features of the Mackie VLZ series of mixers. I know of a station that uses this setup for their NFL broadcasts.
As the technology and connectivity continues to improve, applications like Tieline’s Report-IT simplifies the ability to provide for quick, live broadcasts, and news gathering. We are always looking to simplify and utilize emerging tech to our advantage. The package seen here does not cost that much and the flexibility makes it more desirable. The elimination of bulky and confusing mixers appeals to air talent and promotions alike. Improved audio quality for “call-ins” over a standard cell phone call makes us stand out over the competition.
NAB Show 2014 Recap
Coming up on a month out and I have not even done a recap of the NAB Show! Well, that’s because most of the wanderings I did had to do with actual business this year. Odd, but true. I really could have used a third day this year as I did not even make it to the South Hall!!! Nor did I visit my friends at GoPro or DJi. Now that is what I call busy.
What I did see was the cool stuff that you probably already know about through trades or hearsay. I like the new Nautel GV series transmitters. Harris is also looking good and stepping up a bit. This time I was actually talking STL equipment with them. The Alliance had their share of stuff, and all they need to do now is make transmitters since they seem to do everything else. As you can tell if you have read this far, nothing really jumped out at me at this point. I did have a nice demonstration of the Tieline offering: the Codec Lounge. A very good concept and we discussed possible ways of making it even better. Maybe I’ll get a demo/beta version to try out. I also heard about the SAS Virtual Console of which I will get to see shortly. I have some ideas for this.
Of course on the Radio side of life is talk of HD Radio. HD this, HD that. As we progress with this technology I see more and more use of it as a data transport more so than audio. Traffic, weather, album art, artist and title. Wonder what else we can squeeze into 96kb, or 128kB? Did I get to see any demos? No. I saw a couple of cars out front, though. The one thing that stood out to me is that different manufacturers are offering different radios that do different things. My new Mazda6 has HD, but it does not do album art; it does everything else. A hand full of aftermarket have displays for everything, but there are many that do not. Will there ever be a “standard?”
Along the lines of STL’s (that’s Studio to Transmitter Links for the acronym challenged) I’m seeing more in the IP transport arena. We are actually researching upgrading our aural STLs to an IP based system for two reasons, flexibility and flexibility. Audio over IP on a private network is just fine these days and for a backup to anything else it is great. With all the data we push around with IP based remote controls and addressable transmitter equipment, the added flexibility of IP makes life much more simple. For audio I was looking a the Tieline and Worldcast gear. As for a system we are looking into the licensed 8, 11, etc. Gig radios and broadband data. Let’s see how that pans out over the year.
As we move forward what did you see that excited you at the show? Overall, not too much jumped out at me. Yet, on the face-to-face time, it was a very good show. Maybe next year I can get an extra day to see the other world of cool stuff in the South Hall.
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!
Thoughts While NexGen Updates
How’s that for a generic title? And, WOW, it’s February already!
Anyhow, I’m still working on my Future of Radio series, but it has been tough concentrating on that while doing the daily grind, and I must admit keeping the motivation up. Now that we are in the midst of a NexGen update, going to version 2.13, I am relaying general items that have popped up in the last couple of weeks.
My first interesting conversation was from Burk. I placed a “feature request” in. Not really a feature, but I figured I would ask since I’m dabbling in Linux. The answer is no, they are not working on a Linus version of AutoPilot. Would you believe of all you engineers out there, they claim to have received NO requests for this? My reasoning: Running a monitoring critical operations with a Windows-based system seems a bit disturbing. One would think that having a strong, stable platform running software would be high on the list of requirements. So, I hope I get a call to test out a new package, but something tells me until more of you make the request, no move will happen in the short term.
As I type this, I’m working on my Linux VM. I had to fight, actually learn how to install a plug-in that was not automatic as I am used to. I have a lot to learn on this stuff. Once I get a handle on it, watch out Nautel, I know you guys use Linux for the AUI!
How many of you have MPLS “private” networks across your city, region, or at all? We are in a valley, so our primary STL is T1. AT&T is just the worst now at maintenance and reliability. Seems to me they are taking the same route with point to point T1 circuits as they are with ISDN; slowly letting them die. I figure we would research MPLS and the response from manufacturers like WorldCast is that is the best way to get quality IP connections for audio. Of course this is true if the provider can guarantee bandwidth. This bothers me as many of they companies must lease line segments from the such as AT&T. If I can’t get reliable service from them direct, how can a third party provider? So, if you have something like this, please feel free to chime in with your thoughts.
A couple of years ago I started research for a licensed, high bandwidth data microwave using a combination of 11Gb, 18Gb, and possible 22Gb links. That fell flat when money was shut off. Now I wonder if I can even get a licensed link. I guess it may be time to start that research again. Hopefully the economy improves a bit to make things happen.
Well, better go back and check on that update, and after that check on an air duct to see if it has any dampers or diversions in it. Ah, the life of a radio engineer.
Nautel NVLT and Burk Technology Config
One thing I do like to do is help fellow engineers get to a solution to a problem. It does not matter how small or large. Even if I can help in the smallest way it feels good. I’m also feel honored that engineers, companies, and tech support folks actually recommend me to others for help. In this case, I was able to at least steer a fellow engineer in the right direction. What we learned, and it may sound surprising, is the Nautel NVLT is DIFFERENT than the NV so much so that Burk has a different PlusConnect-NV for that box.
The rub is the PlusConnect is so new that one of Burk’s own tech support was not aware of it, or made an assumption that was incorrect. I was not aware of how different the NVLT was until this contact. After a few email exchanges that stated the Link was there and the ARCPlus was talking with the PlusConnect, there were no readings and the configuration did not take. I slept on it after giving some Burk pointers. I began to feel that something was different and directed the engineer to contact Burk and ask for more details. A couple days later I received a call from him and did I get an eye opener: Yes, Burk has a different PlusConnect for the NVLT, yes the MIBs are different, yes the firmware is different, and yes the AutoLoad definitions are different. Well, that explains it all. Burk shipped the wrong PlusConnect. Mistakes do happen, but….
I find it interesting that my engineer friend did not learn this from the first tech support person. Whether he was too new or did not know, a simple “I do not know, let me get back to you” would have sufficed. It took multiple calls. There are most likely many reasons for this, so I give them the benefit of the doubt, but still a courtesy call to make sure the proper information was conveyed goes a long way. After the calls the Burk website (here) has been updated with NVLT firmware and AutoLoad definitions.
Now back to business.
Cheers!
Forward: Part I
Are we losing our vision? Are we not looking forward? Forward: Part I.
All we hear is “do not spend money.” All we hear is “can we doing it cheaper?” We make due to keep our stations on the air. That is all we do. A live broadcast here, a broken button there, and the spilled coffee. All parts of our daily lives, but how many of us take the opportunity to move forward? Even though we do not have the money, do we take the time to look on how to improve our systems we currently have and when the time does come, are we prepared? It seems I run out of time to make my lists to submit for another budget. I must improve on this so I can move forward. How do you move forward?
I discovered recently that our Lanlink (Moseley) is “outdated”. Purchased by my predecessor only 3 years ago, it was never implemented to its fullest due to bandwidth limitations. It was never used for telemetry. It sat there, stagnant. A simple call and a question and I find out the bandwidth can be doubled by purchasing an upgraded radio. If I knew this, it would be in the budget, but it is not. Will I drop it? No. I can use it. Is it the best system for what we do today? No. Until we can make the case we need to use what we have, so in this case a backup segment. Slow, but useful. There is always room to improve.
Audio over IP is everywhere today. Some systems use it as their main backbone and others use it as an extension of their existing, proven systems. Bandwidth is the limitation. How much can we squeeze through this pipe? How much are we willing to give up in quality to make it happen today because we are the first? There are webcasts on audio over IP (AoIP). Hit This Week in Radio Tech as Kirk Harnack talks with engineers who live this stuff every day, and learn what we do. Almost all of these fall during times I cannot “attend” and what do we do, AoIP! We do it successfully, everyday. (Good thing they all have sites for replaying and reviewing.) I am now testing and evaluating a new AoIP box. Will this be the next STL? Can it be used in conjunction with existing STLs?
Do you keep looking for room to improve? Do you give suggestions to manufacturers on what you would like to see or use? Do you look or do you wait? How does the NAB convention help or hinder your decisions? Where do you think this industry is going. My thoughts are coming….
Cheers!
Coming soon:
Forward: Part II
A different line on a similar topic.
Linux, Initial Observations
A couple of months ago I posted on Goggle+ for suggestions on how to enter the world of Linux. I was enlightened on the responses and jumped in. I installed VirtualBox virtual machine software on my Windows 7 desktop and had at it.
First I downloaded Ubuntu. The 64-bit stable release 12 did not take too well, so I went with version 13. Install went well. My impression after starting to use it was a feel between Mac OS and Windows. A mash up, if you will. The package came with LibreOffice, so I briefly poked through that. I found the standard games. I used the standard browser. All worked. I when decided to download the Chrome browser as a test. No problem there. I still have much to explore as Ubuntu provides a lot of stuff in their package.
One thing stood out that annoyed me. The scroll wheel on the most does not work. At this point I did not know if it was a VM issue or Ubuntu. I guess I’m used to that particular mouse feature, so it stood out.
After this quick study I looked for the other suggested Linux build, Debian. There were two routes to take on this, and being a noob (yes I just used that word), I downloaded some full ISO image. Thinking I did not need this running on a virtual machine I looked at the options again and found a network build/install. I downloaded that and installed it. While Ubuntu has links to apps like a Windows desktop, Debian gave me a blank desktop with a drop down menu. I poked around and was getting comfortable very quickly, though I still have tons to learn.
Thinking I know enough to cause trouble I began to surf the web using the default browsers. Ubuntu’s seemed a bit clunky and I decided to jump to Chrome. The Google browser installed automatically and ran well. In Debian the default browser was just like Firefox but with a different name. (I’m now sitting at my machine, the browser is Iceweasle.) It was quick and easy to use. To be fair on the comparisons I downloaded Chrome. Debian did not install automatically. It downloaded an install package which made me learn how to install the package, which I did figure out after one false start. That was not all, I had to find where it was installed and it did not add a shortcut or link in the menu. I poked around the file system and quickly found the file to run. I learned how to add it to the menu list which was satisfying. Performance was similar to the default browser, so the jury is still out on which one I like best.
I plan on looking for the best or proper antivirus software to run next. I don’t want to assume all is safe like Apple does. More research needs to be done as I continue on. Both versions of Linux came with Libre Office, so I get to play with that. I want to search for more applications that may be useful, too. Any suggestions are welcome. I will follow up on this post add I continue my journey into the Linux world.
Cheers!
Burk: ARCPlus, PlusConnect-NV, and AutoLoad Plus
There is something very satisfying when helping a fellow engineer solve an issue. It is also nice to think that a manufacturer would recommend making the contact due to past experience with their equipment and associated equipment. In this case Nautel directed said engineer to make contact since I am familiar with the NV line of transmitters and the Burk ARCPlus line of products. In fact, the Nautel tech sent me the initial email, then everything flowed from there. Apparently, and I knew this, there is a multiplier issue with Burk and meter readings of the Nautel NV series transmitters via the PlusConnect device.
A while back I noticed after a firmware update that I was no longer getting the proper Reflected Power reading from my transmitters. I have 2 NV20s. No changes of decimal places seemed to make a difference. Working with Burk technicians we determined there was a multiplier issue withing the system. As a work-around we used an unused channel to take the reading, and then used a Virtual source on the channel on which all my units displayed the readings (ARCPlus, AutoPilot Plus, etc). This solution worked and all was good. I assumed that any future update would correct this issue.
Then came this contact. I immediately recognized the situation as being similar. Reflected Power reading and this time Reject Power. I suggested to do the work-around and see if it made a difference. I was glad to hear from him this morning that it did, but he had another channel that was doing something odd, the PA Temp reading was a 4 digit number and changing the decimal places in AutoLoad made the reading go out of range; the dreaded 99.99 reading. As this was not a channel I normally monitor, I gave it a shot to see what I would get. Sure enough the raw reading was coming back as 3613 and 3684 on my respective transmitters. I thought that this was a good number, but the decimal place was off, so I changed the decimal setting in AutoLoad. Sure enough the ARCPlus was now reading 99.99! I tried a decimal setting of 000.0 from 00.00 and then I got a -999.9! Sure enough there is an issue with a multiplier. In this case it was TOO BIG, so I decided to take the raw reading on a spare channel. I then changed the metering channel I wanted to read to a Virtual source and divided the raw reading by 100 which displayed the result of 36.13 for the first transmitter. As it is a temperature in unites of Celsius, this reading on a reject is good.
Phew. Of course I called Burk and filled them in. Off to the programmers to see what is up. In any case, if you have a setup like this and your reading is too low and you know what it should look like, the solution is to create a channel that is a virtual source. In my case the expression entered: M256*1000. Translated to take meter reading on Channel 256 and multiply by 1000. On the PA temp the expression entered for the virtual source: M255/100. Translates to take the meter reading on Channel 255 and divide it by 100.
If you have this issue, fix it by doing this manual multiplier/divider thinking. All you are doing is what the program should be doing when changing the decimal places setting. Burk is aware of this issue. As I copied my Nautel contact, they are aware of this issue, too. Happy troubleshooting!
Cheers!
The Future
I just wanted to solicit any thoughts on the the future of Radio. Television is OK, too, but I work radio. I want to know what you think about hardware, programming, and how they will interact in the future. Send email or reply to this blog.
Email: bill at eisenhamerengineering dot com.
Over the last few months I’ve been thinking about this subject. Seeing some of the recent moves by companies like Cumulus makes me more sure of what I see.
Clear your mind. Think outside the world as you know it. If you want to discuss and/or collaborate, contact me. This should be quite the exercise. Traditionalist need not apply.
ESE ES-102 Surprise
So, we’ve had this ESE master clock for some time now. It’s an ES-102 GPS Master Clock with time code output for our console clocks and PPM equipment. The clock was purchased years ago under the watch of another engineer. I received email on Sunday that the clocks were doing some weird things. Weird? One called out for “Help 4” and another email stated it was jumping between 2:01 and garbage. Then I received an email that all was good again. Then…. You get the picture. I responded thanking for the info and I’ll check it on Monday. Not a pressing item, but then more emails about the behavior. I decided to call and get more details. Same report, but it was working at that time.
Come Monday I enter the shop and take a look a the clock: 2:01. Nice. GPS LED lock is green, so it was receiving signal. I do a power reset as that is one of the first things I do. It goes through the cycle and the correct time appears. GPS locks. All is good for about 10 minutes, then 2:01. Head scratching. I pull the box from the rack and open it up. I like opening up boxes. What do I find inside? A battery. I never knew it had a battery. Being the good engineer that I think I am, I remove the battery and test it; 2.02V, not 6V as stated on the battery. OK, battery is bad, but is this the problem? I install the unit sans battery and plug it in. Now the time is correct and GPS lock. I wait. And I wait some more. I go out and get my morning coffee. I come back and it is still right on time. Conclusion: Dead battery causes some weird stuff.
I head out and purchase a replacement battery. The store only had 2 left. It is a rectangular looking thing with F2 spade connectors, and rechargeable. Call it a baby UPS battery. I swapped it out, put the unit back in service and all is good. I now have a note for the ES-102 to check the battery again in 4 years; I may do it sooner, but the specs in the manual says 4.
When your equipment is having a bit of a spasm, check for the obvious stuff first. I know this is basic how-to information, but it is always worth refreshing. I know some who would dig in and start replacing caps, IC’s, or just freak out and throw the thing away. Using good technical troubleshooting skills will save time and money. Refine and refresh your skills. In my case a good process of elimination procedure pin-pointed and solved the trouble quickly and resulted in an easy repair.
Happy troubleshooting!
Cheers.
