Archive
Enco Padapult & Audemat FMB80
So here’s the deal with Padapult. After talking with Audemat regarding sending RDS updates via Ethernet it was decided to go with a TCP connection using Port 23, Telnet. We are on a closed, so no problem. Send the PS_Text= to the IP address of the FMB80 using port 23 and all is good. It works. All is better. BUT WAIT! Nothing after a day, or half day, or random time. Shoot a whole weekend without issue and then nothing? What up?
We run a packet capture on the monitor port for the Padapult computer. We document that the RDS is being sent properly. As it works we see the data is spit out. Shoot, it’s only ASCII text. Then we notice that it stops. The Padapult software says it sends the data. The packet capture shows nothing from the source IP, Padapult computer. So the application shows it sends the data, but the computer is not sending the data. Now what? We restart the application and all is good to go again. Something is up with Padapult, that is certain. Enco does it again!
We run 3 instances of Padapult on one computer. We send PSD (formerly PAD) data to the HD Exporters, we send RDS data to the FMB80’s, and we send twitter updates. The PSD and twitter updates work continuously, but that RDS data is flakey. If we check the initialize connection on each send the RDS data does not fly at all, so that option is a wash.
We will continue to bash it until we find something tangible. It is annoying and we may go back to a serial transport which seemed to work just fine.
NV Update is Out
I have the new update for our NV’s and will be installing it this week. I have also discovered it will fix an issue we just experienced on one box. We had a mysterious exciter PA over temperature. No reason for it as the readings are will within parameters. Press the Reset and away you go. I inquired if this update will “fix” this and I received a “yes” response.
Now that is support.
DAD Padapult & RDS via Ethernet
Working yesterday to use an alternate path for RDS data while our Moseley STL transmitter is being repaired, I decided to take advantage of our HD Ethernet connections to our various transmitter sites. The big question was how to make the Audemat FMB-80 boxes accept the data and what to tell the Padapult what to send.
Surprise, surprise, we researched the FMB-80 manual and found that it wants to see commands using UDP port this or that. OK, we tried. We tried to make the Padapult send those “commands”. We researched the Enco forums for information. Everything was not quite right. What are you people thinking, it must be easier than that!
A quick call to Audemat and I ask Tony, “what’s the easiest, simple way to do the Ethernet data feed?” Lo and behold I get the simple answer. Do not use UDP port this and that and all the fun complex stuff! Set the Padapult up to send to the IP address of the RDS box using port 23! Genius! We telnet in to service/check the FMB-80, why not use the same port to send these commands. We are also on a closed network, so security is not and issue. Set up the Padapult to send the following command: PS_Text= and fill in the stuff like [Title] by [Artist] on KZZZ and add the carriage return [013]. The carriage return is a must for the FMB-80 to interpret the “end” of the line. I add a line feed, too.
No we have the RDS information there like before. Sure we lose some of the cool things that the FMB-80 can do when it gets commands like stop scrolling the song information when the duration is complete, but we do not need that, now. You can even add the Radio_Text command this way. Simple and easy, just the way I like it.
Nautel NV Software
After killing an Exgine card due to my own curiosity, I have learned that a new software revision will be coming out soon. Wait for it. The latest has some cosmetic bugs, like the date, and it would be best to wait. Overall the latest works just fine.
We are running the latest embedded exporter software and the iBiquity Left/Right channel swap is fixed. It was a straight forward update.
Carry on!
Week of Fun
So you all saw the updates of the week via Tweets. Some also have seen the latest post regarding the STL. Here is a summary of stuff that will help those troubleshooting (STL) and planning (software updates) in the coming weeks.
1. The STL. The symptoms were quite surprising on the Moseley aural STL. We noticed the failure via audio drop outs. It was somewhat periodic, too, which was quite interesting. As we had planned to drop the system to 32 quam from 64 quam to make it more robust in the first place, we began to do that from the far end (receivers at transmitter sites) back to the near end (studios). No bit errors were being received at the transmitter site, so there was no real need to worry, yet the problem was there. When we got to the transmitter at the studio, and after visiting the mid-point, we noticed the issue after making our Quam adjustment.
As we are running 32 Quam now, an issue like this will not show itself unless you are diligent on routine maintenance. Now we are going to schedule monthly tests of the backup STL system by placing it on air for at least 1 hour. We will also make sure we check the units themselves for any parameters out of range.
2. Harris HTHD+: Amazingly this thing will drop when you least expect it. After spending a better part of the day Friday with tech support we are experimenting with the Exgine buffer. The premise is the buffer is overflowing or having some issue causing a system restart. During the restart RF is muted. I will know more tomorrow when I hit the site and see how are buffer is doing after doing recommended adjustments to buffer timing. If we remain unlocked, then we are looking at some issue. If it is a data stream issue, then we may have something up with our Intraplex STL. It would be odd if this was our issue and I would conclude that the Flexstar processing system and Exgine would need some sort of overhaul. On a side note it also shows how critical a good network path to the transmitter site is for iBiquity HD radio. Nuts considering many transmitter sites have little or no network access.
3. UPSs (Uninterruptible Power Supplies): Never purchase a consumer grade UPS even if it is a “true” UPS. If possible purchase an online UPS large enough to handle the plant or a section thereof. I have 15 more batteries to replace in the next day or two. They are running my budget up and it is killing me. It is worth the money to protect your systems, but a maintenance nightmare. Try to keep it simple.
4. Remote Controls: More monitoring is a definite requirement for major markets. Reliable, too. I need something reliable, versatile, and flexible. Will it be Davicom, Audemat, Burk, or Statmon? I am tending towards Statmon, but the cost may be too steep. I’ll keep you posted on my progress on this one.
Enough rambling, back to more fun!
STL Issues!
Wow, it’s been a while since I’ve posted. Mostly because it has been quite slow and doing a bunch of budget prep. Maybe I’ll post a separate article on budget prep. In the meantime what are the chances that both your main STL and your auxiliary STL have issues simultaneously? Yesterday our T-1 went down hard. We switched to our aux STL. It worked, but we were taking audio drops. The aux STL is a Moseley Starlink, 4-channel version. This system goes back at least 8 years and I was not too involved with the install, just the basics. Configuration was done be someone else and the factory. The bottom line is I felt that the 64Q settings were not robust enough for reliable transport of our audio and data. I was right.
I proceeded to configure all our sites to 32Q. We have a studio, a midpoint relay, and two receive sites. I discovered as I worked my way back that our studio transmitter on one system was running low power! Clue one for audio drops. I have an order in for a loaner and will be getting it repaired ASAP. After all the configurations were changed, the audio drops, even with a low power transmitter, have gone away. Of course by the time I had the system configured, AT&T had fixed our T-1.
If you have an auxiliary STL system that does not get used much I suggest you take a close look at all the operating parameters. Apparently on the Moseley you cannot monitor them remotely or you need to do some upgrading. As we clean up around here after years of neglect, we are scheduling routine maintenance of all systems. Have you checked yours recently?
Damned Digital Magazines
Have you noticed how difficult it is to read the digital version of Radio World? How about Radio Magazine? How about any of them! Is it my eyes and old age setting in? I am finally getting to the Aug. 19th edition of Radio World and I click to zoom in to read the first page. It comes up fuzzy and small. I lean into the monitor. Uhg. Not comfortable.
What am I reading it on? A laptop with a 17″ monitor! The browser is maximized. I still have issues reading it. I cannot even use the CTRL+Scroll to enlarge it with Firefox. Nuts.
Here is a thought, make it possible to zoom in more! I’ll use the damned mouse to move around. Just make it legible. I can do this with PDF versions of emags (Redman is an example) where I zoom in as much as I like.
Old age sucks and I’m not even that old yet!
OK, rant mode off. I feel better.
Powered by ScribeFire.
Preparing for an SDG&E Planned Outage
San Diego Gas & Electric threw a curve ball at us last week. They are replacing a power pole on a circuit that feeds our little class A simulcast site. Being a small site and no room for any on-site generator we started to prepare for this outage which is to last “up to 10 hours.”
We picked up the promotions generator and tested it out. Got some extra fuel. Now some more fun and a great electrician: We had to make sure we had the proper connections for the devices that will be used or even potentially be used. Our main transmitter has a “china man” type connection and our aux has a twist lock type connection. The generator has a 4-prong 240V plug. Our electrician whipped up a cable with the 4-prong on one end, a j-box with a couple of 120V outlets, and a tail with the “china man” plug. In addition he has a “china man” to twist lock 3-prong if we need to run the aux.
We will do a dry run on Monday to make sure we are not missing anything. Along with this a couple of extension cords to run peripherals and we should be good.
Nothing like being prepared and having a good team to jump on it early,l especially when I was busy with other projects. At this stage I think we are ready to keep the site up and running.
Now is AT&T going to keep the T-1 active or are we flying on the backup/emergency feed to the site?
So What Have We Done with the M2.2R?
Some of you are interested in what resolve has occurred with our DaySequerra M2.2R. The bottom line is there has been no resolve.
The latest is we sent a bunch of data to them with the box we still have here. We sent a spectrum plot of what a whip antenna receives at the site. We’ve sent spectrum plots of what the samples see. We sent screen shots of their own web application showing signal strength and the like. They are still combing through it.
The last thing I did was take some measurements attenuating the signal from the sample and feeding the low level or antenna input. When the air conditioning folks move to the next unit, I will do more measurements. So far I’ve attenuated about 55dB. I have another 20dB attenuator I found. In any case, so far nothing seems to work. Inconsistent readings, or just not trustworthy readings, continue.
Stay tuned!
So, What Do You Think? HD Radio Dead Out of Box?
Insignia’s portable player unlikely to boost HD Radio’s popularity – Los Angeles Times
Seems to me we are reading the same complaints/issues that even some engineers in the field talk about. I know we are working on the IBOC power increase, but will it be enough to receive INDOORS? Will an external antenna be required on all devices. By the way, the article is a review of the new Insignia radio that the industry is talking about. The next item that I find interesting is right at the beginning: The ear buds are inferior. Figured that was coming. Also note the quote used from the iBiquity website. I need to check on that one!
From the broadcasters standpoint and the inception of PPM, how will a monitor pickup what the listener is hearing if they are wearing headphones or ear buds? This same question arises for those iPods and iPhones. Hype the apps all you want, people are using headphones and you will not get ratings. A minus for the PPM technology?
What do you think?
Powered by ScribeFire.
Tech Notes from the Field 