Archive
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!
When The UPS Fails
When Murphy’s Law kicks in, there is no holding him back. I had an UPS (Uninterruptible Power Supply) die on me at 11:45pm, 12/31/2012. That’s right. 15 minutes before the New Year. I may as well was having a baby! To add insult to injury the UPS was only 2 months out of warranty!
In any case, apparently we took a brief outage at the transmitter site and the return surge was enough to damage something in the UPS. The UPS in the other rack had no issues. How did it fail, you might ask? At the time of the utility interruption, the unit switched to battery power as normal, but when utility power came back, it did not switch back and the batteries ran out of juice.
When I tested and discovered this I noticed that I can force it back to utility power by turning it on and off. Eventually the relay that switched to utility will close. Yes, the UPS starts on battery and tests utility before switching on. Of course no love from the manufacturer except for the “we have service, please call….” I already ordered a new one. I may find a replacement relay and make the repair myself, but something in the back of my mind is telling me that some logic issue is involved and it is not just the relay.
How often do you relay on instinct when making repairs? I do quite often with great results. I’ll follow up if I do this repair do to boredom. 😉
Cheers
Break-Through, Breaking, Broke, Fixed
That sums up this week. Break a few things, get good news on an old issue, and fixing stuff. That’s my life.
Cleaning up is my number one To-Do this week and I can walk into my office now. Hall cleared, office cleaned up, and Station Logs files for 2013 are made. (year, really.) As we progress I got to cleaning up my remote control situation even more and creating automated tasks with macros. This turned into a 2 day exercise as I had a chat with my pals at Burk Technology with some questions when I find out they posted updates for the ARC Plus firmware, now at 3.0.0.37, and AutoPilot 2010, officially 2.8.4. Not resisting something “new” I had to update. All went well except for 2 ARC Plus units. The configurations I saved prior to the update messed them up when loaded back in! Doh! To quote Homer. I figured that out and loaded configurations I had saved last week when I made a couple of macro changes. Lesson learned: Save that configuration as soon as you make a change! Now I can proceed with some more macro building and some JET flowchart learning. Yeah, I’m lagging on that.
The break-through is from RCS and our on-going NexGen v. Sage Endec IP control issue. WE CAPTURED AN EVENT! I received and email and RCS is working on code to install within NexGen to more closely evaluate why NexGen did not respond to the incoming alert. We await this little update to the A-serves. I ask again, anyone else out there doing IP control between NexGen and Sage? I wish I knew a bit more of the inner workings of this system. On the other hand I would not want to see that internal road map as the software in its basic form has been around for years!
Broke: AT&T. Nuff said? We’ve had a series of T1 failures. Some responded to quickly, others just lie in wait to annoy us. I would suspect our Moseley equipment, but history proofs otherwise. I do wish Moseley had a better self monitoring system, but the equipment is older and we are looking at upgrading to newer systems. Bottom line is it sucks to not have line-of-site to transmitter sites so I can use a reliable microwave STL, I want a new 11GHz system so bad with a large bandwidth! I can dream, can’t I?
As things settle down, other than AT&T, I am now going to sweep the studios and clean up some dust bunnies. I think I have a battery replacement on an UPS due, too. Love the holidays!
Cheers!
PS: Glossary for those new to this stuff:
STL = Studio Transmitter Link. Conversely TSL = Transmitter Studio Link, the opposite path. In radio we are mostly concerned with getting audio to the transmitter site. In this modern world with data, along with monitoring/metering, the return path is for this information.
11GHz = 11 Giga Hertz microwave systems, is the band that carries audio, data. “Classic” STLs are in the 950MHz band with limited bandwidth. For comparison, 802.11 WiFi routers run in the 2.4GHz band with wireless N also in the 5GHz band. Wireless mice and keyboards are also in the 2.4GHz band.
NexGen and Sage Endec Control
We installed the RCS NexGen a year ago. As of today we still have issues with the NexGen – Sage Endec communications.
Our NexGen system is installed with no GPIO, or opto-relay, equipment. We are 100% IP control with the system at this time. We run EAS Required Weekly Tests, generated from the NexGen, without any issues. It is pretty simple once set up. NexGen is configured to look at the IP address and Port of the Sage Endec, monitoring for any Sage originated activity. If an alert or Required Monthly Test (RMT) comes in, NexGen is supposed to “see” it and act accordingly. It works sporadically at best. Today we had 2 of 3 stations run properly.
What could be the problem? No one seems to know or ask the proper questions. We have tested time and again the Sage Endec for the information it sends out. It exists. It’s there. It just needs to be acted upon. The NexGen will not “see” the information. It does not acknowledge that an alert or test has come in. If it does, it works just fine. If it doesn’t, then manual intervention is required or the Sage takes over and runs the alert or test on the air, interrupting programming.
I ask the question: Why does the NexGen machines not see the information consistently? It is there to be acted upon, so why does it not see it? NexGen is installed on Windows 7 server class computers. NexGen runs on layers of older code. I conclude one of two things: 1) the older IP stack on which NexGen is build stops responding, or 2) the Windows 7 computer “shuts down” something such that the information is ignored. Anyone have experience with Windows 7 boxes acting odd like this? Could there be a miscue between the application and the physical NIC?
We continue to send logs to RCS for evaluation. No one seems to have answer. One year later. Any Windows 7 insight is greatly appreciated, and if you have an RCS NexGen running IP control, let me know what experiences you have.
Cheers!
More on Tin Whiskers
A few weeks back I posted on Tin Whiskers. Well, look what I found on Phys.org today: Phys.org: Tin Whiskers.
Coincidental I say. I had a nice chat with Kirk Harnack on TWiRT on these suckers and how they can cause failures and you would never know they were the culprit. Pretty cool.
Anyone out there have a story or experienced a “tin whisker failure?”
Cheers!
End of Year Routine?
So, we are wrapping up the year. Can’t spend any more money. Folks are heading out on vacation. What do you do?
Once again let’s keep things organized! I tend to clean up the shop. I make sure my documentation is straight. I have a couple of shots of whiskey. Oh, wait, well, you know….. Much of this is tedious work, but should be done. Shoot, drop “should” and make that a “MUST” be done. I find having my documentation up to date make troubleshooting easier when it is necessary. I know you hear this time and time again, but DO IT!
The most frustrating thing I find is since more than one of use does something, it does not get documented. This is because I am anal about it, to a point, while those around me are not. Of course when it comes to troubleshooting, I pick up the binder and use it while the others do not. Annoying. Plus keep the documents up to date helps refresh your memory of what was done. It is a habit which must be learned, but it sure pays off when you get a good one and a quick repair or work-around is needed.
Start you end-of-year clean up and be ready for next year!
Cheers!
Tin Whiskers
I was poking around the web during lunch and came across one of my favorite sites, EE Web. While browsing down the page I saw this blog/article post on Tin Whiskers. (For those looking for humor: I almost wrote Whiskey!)
Anyone ever run into an issue with tin whiskers? I know some manufacturers that have. The issue one had was between a PCB and a shield assembly. Over time with the help of dust the whiskers grew until they shorted with the shield. The solution was to make the gap between PCB and shield wider. Knowing that this can happen and if you start seeing intermittent oddities with a piece of equipment, check for tin whiskers. Blasting air will clean out the dust and any other catalyst, but it will not prevent regrowth.
EE Web is a great resource for electrical engineering articles and tools. Very easy to navigate. Do you have a favorite site? Pass it along and I will publish it.
Cheers!
Wow, A Marconi!
It hit me today that I am the Chief Engineer of the Large Market Station of the Year. How cool is that? The whole group of people pulled together to make this station shine over the last months. What a good bunch.
Let’s hope and work for another successful year. I feel a sister station may be in contention. That would be very cool.
Cheers!
Networking, IT, IP, and RF
Been spending a lot of time in the modern world of broadcast engineering. As we keep moving forward we keep doing more of what people call IT. What do we do as broadcasters, we pass information. Why not group us into IT?
First I have been spending time with Burk and Nautel on a Burk PlusConnect-NV disconnect issue. Seems the PlusConnect is working fine. Nautel does say there is a little issue with the SNMP agent as it is slow to respond at times. I understand a few customers have this issue. Rest assured both parties are aware of this and both parties are working together to resolve this issue. I’m glad I get to work with both. Right now I have been informed there is a new version of the Nautel AUI in the works. This version will address many concerns including the SNMP agent. As they are being so diligent on making sure all the “bugs” are worked out, we all must be patient on the release date as there is none at the moment. I say great, make sure it works before getting it out there. Anyone beta testing? I’m not.
As for the Burk system, it is working pretty well. I did have them re-write the version 3 of the ARC Plus, so ask about the latest version that is not posted on their website. 😉 I see 3.0.0.25 still there. I am still waiting on a new build of the AutoLoad Plus to address another minor issue.
As for the overall problem I am going to seriously look into the RF situation and network cabling. Though I use shielded cable, I suspect a bit of RF causing some headaches. Not sure exactly how I will attack this, but as we move more into the networked systems realm, I want to make sure future installs do not exhibit RF issues. What is very interesting is the shielded cable is actually giving me more problems than unshielded. This makes me wonder about the integrity of the connectors on the former cable.
More RF fun is my old Moseley Starlink. Seems I have a “special” unit. For one it shows a received signal in the mid- -50’s. WTF? When a different receiver is installed it shows a more realistic -75 dBm. The spectrum analyzer shows a -80 dBm. I think the dish that the landlord relocated needs to be re-sighted. The fun never stops. I’m working with Moseley regarding this odd reading and I suspect they will take the unit back and have it calibrated.
Next week we dive deeper into our network as we install a new Layer 3 switch. This is going to be great!
Cheers!
Travels, Work, and More Work
Wow, it seems to be forever since I posted. Forgive that. I bet you expect juicy details on super secret stuff. Well, not exactly. Recently I did travel, and since being back I have been busy. Shoot, I was busy before the travel. Does work get in the way of vacation or does vacation get in the way of work? Will we ever know?
Vacation was great. Part of that was to visit the Elenos factory in Italy. I enjoyed meeting the crew out there and talking shop. What I saw was quite impressive and the dedication and passion behind the product is amazing. With that we may see Elenos become a player in the transmitter market, so stay tuned. From what I understand I may be receiving one to test. Did I mention they did win a Cool Stuff award at NAB this year?
Of course I get back from vacation, IT Dude goes on vacation. This always equals some trouble. In this case it is Marketron vs. Windows 7 and a Ricoh printer. After a whole week, we still cannot print from the new machines. They print locally, but not through Marketron. I think I am overlooking something that IT Dude will notice right off. That is the true difference of dealing with something day-to-day versus only on occasion.
Do I dare mention the Harris Flexstar? I should write a whole post on just this. Yes, I continue to have Exciter muting issues, though not as bad as before. To make a long story short, we know for a fact that the Flexstar cannot handle too much data. It bogs down and eventually chokes. The only way to recover from the mute is to reboot. I wired up my remote control to the Flexstar restart input. This is pin 13 on the Remote User Interface of the Flexstar itself. A contact to ground and the Flexstar will perform and cold boot.
I have been fine tuning my Burk ARC Plus installation and utilizing the AutoPilot program a bit more. Now if we can only get Burk to support SNMP within the ARC Plus removing the need for AutoPilot they may be on to something. In the meantime I have created a fine custom view that shows the basics of all my transmitter sites. Attached to the touch screen monitor, all it takes is a touch of the screen to execute a function like STL switching or rebooting the Flexstar exciter. In addition I am utilizing SNMP with my Eaton-Powerware UPS’s by adding a network management card to the UPS. Currently four are up and running and I monitor on AutoPilot input and output voltage, UPS load, time remaining, and battery charge level. As I learn more about SNMP I may have status notifications if a self test fails or whatever else I can find!
Maybe my next post will get into some dirty details. If there is a subject you wish to see covered, drop me a line.
Cheers!
Tech Notes from the Field 