What?! Nothing Happening?
Wow, I cannot believe I have not posted in over two weeks! Well, yes I can. Nothing is going on. As my tweets have mentioned I have updated our NV20’s to Version 2.6. Guess what, 2.7 is available. From what I can tell I may not need 2.7 at this time as i am not experiencing the issues of which it contains. I do not update just for the sake of updating, so on this one I will wait it out just a bit and research more on what it is supposed to do. I am quite happy with 2.6. No issues. Uh, Oh, now there will be something.
Harris? This buffer overflow thing seemed to be the issue. I still am surprised that an HD data overflow would mute the exciter. How can you put something on the air that is NOT critical but can cause a critical outage? Flabbergasted is a word for that. Hey, at least we’ve been on the air since I changed the Exgine delay setting.
DaySequerra M2.2R? Not back yet. Still waiting. This better work when I get it back!
Time change. Hopefully everyone who needs to made their changes. When you get down to it I find it amazing how many things have clocks in them. I also find it amazing why. I know my processors have dayparting, but we do not use it. Need a clock? Not really, but we check them anyways. Anything that logs need updating. Now my Nautel transmitter clocks need to be checked so I can get accurate logs on any issues. Nice feature, eh?
The super secret item mentioned in a tweet? It is a Tieline product. I am beta testing for a week coming up here. I don’t think I am supposed to talk about it yet, though it is a product they demonstrated at NAB. I am honored to be able to test something for a company. They trust I will either like it or can find issues with it. I can’t wait to get my hands on it.
That’s all folks. I’ll keep you posted and may even write an opinion on something like HD power increase.
Harris Fix?
Apparently we me be on the road to the answer of why our HTHD+ transmitter randomly drops off air. If you have followed my posts these random events are annoying to say the least. Recently we discovered the transmitter recovers on its own within 2 minutes, a long time in radio land. What is this potential solution?
Set the Exgine Buffer such that the Buf Used and Buf Max is in the 20-30% range. We moved ours from Default to 0.836 and the system seemed to stabilize. We still experience Exporter Sync Unlocks, but are not as often. Also when using thos setting the Lock Indicator does not swing as much. This will count down to zero, go negative, reverse, and “swing” between random limits. Apparently if the swing is within some tolerance the sync indicates a lock and the buffer is running optimal.
If the buffer is over utilized there seems to be a DSP barf which mutes the exciter. Seems odd that this could happen, but since changing our settings we surpassed our 2 week wall and shut offs. After checking this morning the sync was unlocked and we noticed our T-1 circuit took a hit. Makes sense that some corrupt packets came in and caused loss of sync. We await a re-sync. Too bad there is no good way to remotely monitor this.
I will keep on top of this, so look for tweets and future blog updates.
Test Post from Zoundry Raven
Looking for more fun stuff to play with. Found Zoundry Raven, a desktop client for blog posting.
Figure I give it a test run.
Powered by Zoundry Raven
Daylight Time Ends On Nov. 1
For all those who lose track of time, Daylight time ends November 1st. Back to Standard Time. I wish we could just stay on DT, works out better for me. 😉
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?
Tech Notes from the Field 