We spent the week working with Harris on the HTHD+. More precisely we have been working with them on the FlexStar exciter. Apparently we have some sort of PLL anomaly, or at least that is what we are investigating now.

We have limited connectivity to our transmitter site, so we use a single T1 circuit that carries our main audio and our HD data. This bottleneck seems to cause a clocking issue and when it gets too far out of whack (for lack of a better descriptor) the PLL goes nuts and mutes RF on the exciter. With more information from our frequency monitoring service we discovered that the transmitter was drifting in frequency, too.

We shipped our exciter back for evaluation and have installed a loaner. We went to air on it Friday, and so far we have been on the air since. I will be checking the PLL logs we are collecting to see how this exciter deals with our bottleneck of a data network.

I cannot blame any manufacturer here. I do feel that iBiquity could have/should have done a bit more testing of their algorithms and encoding so such issues could be avoided. There are many stations with limited bandwidth to their transmitter sites. If we were not forced to jump on this HD bandwagon so soon, maybe this situation would never have happened.

Talking with a colleague there appears to be some confusion on what a LUT is.  This is referenced in the new procedures when upgrading to version 2.7 of the software.  To be honest, with our NV20’s we do not even have saved LUTs.  If your transmitter is running IBOC with either FM+HD or HD only it is recommended that a LUT is saved.

The instructions provided with your 2.7 update will take you through the recalibration process.  We performed ours BEFORE the revised procedures came out.  Overall ours went well except that one transmitter lost its Transmitter High RF Drive Power threshold.  Huh?  Yes, we had to manually set the threshold level again so we could make full TPO.  A minor annoyance considering how complicated this box is.

I’ve read the new procedures which includes the reset of the LUT.  Again, the LUT is a look-up table.  If you have one configured, located under Hardware Settings, it contains information on the mode (FM+HD or HD only), TPO, and frequency.  The location number is what is referenced in the Preset under Other Audio.  The LUT height is figured out to compensate for any overshoot (power) when the transmitter is turned on.  In addition the ramp up time or the time it takes the transmitter to achieve full power is indexed and is the LUT gain.  Once the height is set, you work the gain to achieve a nice smooth ramp up to full power.

The bottom line is the LUT is used as a reference and target for a preset running an HD mode.  If you are running FM Only, the LUT is not required or important.  The transmitter references the LUT and then powers up smoothly and stops at the desired TPO.  If you run two presets with differing power levels it is recommended you create a LUT for each one.  The information is then stored in the exciter.

That is my understanding of the LUT.  Hopefully this clears up some confusion on the purpose.  As I learn more I will modify this post.

Cheers!

As promised, I will give you an account of our Nautel NV20 maintenance.  All is routine and a pretty boring read, but you always have to be prepared for the unexpected.  Having the first ones does make for some interesting servicing and surprises.  All in all, the maintenance was complete within two hours.

The first part of the process was to upload the new 2.7 software to the “20kW Linux computers.”  No surprises here, so there isn’t much to report there.
The second part of our maintenance before apply the software was to remove a power module and place a ferrite on a fan lead which was reporting the wrong speed.  The tachometer was reporting varying speeds due to RF getting into the circuit.  Of course this only shows up while in hybrid, FM+HD, mode.  In FM only the problem went away, so we knew something was up.  Removal of the module was a breeze.  After taking the cover off, it was easy to clip the ferrite around the lead.  We also took note of how the power amps were installed and then we turned the unit over and removed the back panel.  All heat sink.  I must say the power modules are built very simple and neat.  If you wonder why they are so big it is all heat dissipation from what I can tell.  The components themselves are compact and cleanly installed.  Once the ferrite was in we put it all back together and tested to make sure this took care of our reporting error.  It sure did.  We have extra ferrites if we see this problem crop up in any other modules.
Third we proceeded with the software updates.  The first NV was flawless.  At the end of the update we performed the recalibration procedure with no issue.  The second update took with no issues. After recalibration the thing would not go over 5kW!  Whoa, boy.  What the…?  Identical boxes and one was not happy?  After some checks and comparisons with the first box we checked the threshold settings.  Sure enough the update reset the default thresholds.  After adjusting to what they should be we were back in business.
Fourth, we had some housekeeping to do.  As these are the first ones out there was some test files and configurations that did not get removed causing a bit of network traffice, though not much, was not necessary.  So we eliminated the file and cleared that up.

We are now working smoothly.  All this “work” took less than two hours.  Now if we can get AT&T to maintain the T1’s we will be golden.  We keep pushing them to install fiber.  We continue to wait and call in trouble as we get it.

AT&T.  T-1 line issues.
1.  Tests good.
2.  Data slips lead to audio outage and AT&T documents they see an issue.
3.  Dispatch.  Tech tests OK, but states he did not like what he saw.  Claims he will head back to the CO (central office) to test again and may refer it to “engineering design.”
4.  One day later, no phone calls with results or plan of attack.
5.  I call to check.  Trouble ticket is closed.  Open and new ticket called an “informational ticket.”
6.  Return call4 hours later.  Ticket was closed as the line tested good.  No referral to engineering.  No reason for not calling with status.  We are back on the circuit.  So far, so good.

I ask why we were never informed of the status of the circuit.  If it was cleared, why did I have to make the extra effort to find out what happened?  Why would a tech tell me it would most likely be referred to engineering design?  I fell for this as the copper cable to this site is old.  It is worn.  It is susceptible to moisture and temperature changes.  What else should I suspect?

I figure AT&T has a very high volume of calls, so it could let a menial thing as a status update to fall through the cracks.  I also figure that any company which wishes to maintain customer loyalty and professionalism would have procedures to prevent this info loss.

I see this as a growing trend among companies, even within our own.  No follow-through.  No professional courtesy.  The drive to be the best is missing.  Oh, the commercials on T.V. and radio say otherwise, but actions speak loudly.  I am going to personally act and be the best I can be.  How about you?

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.

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.

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

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.

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.

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.