Sending equipment out for repair

Periodically, Robin sends various pieces of equipment out for repair. Each piece has its own particular procedure for getting sent out, but there's something that he does for every piece:

1. Puts a KCUR sticker in a prominent place on the chassis


2. Tapes his KCUR business card to the bottom


3. Attaches a form letter with model number, serial number, and problem description

This helps to make sure that we get the same equipment back that we sent, we get the problem we complained about fixed, and that the problem gets fixed in a fairly timely manner.

Internet at the TX

Robin is thinking about getting wireless 4G out at the TX for Internet access. Clear is offering "business-class" service for $75/month, which is fairly cheap, all things considered. This would allow us to have IP-based remote telemetry of the equipment that supports it (I don't think our main transmitter (BE FM30B) does, but I bet our HD equipment will). It will also allow us to stream RDS (the text that shows up on some radios with song information and the like) from the studio. On the down side, that's more equipment that needs to be examined and protected from a security standpoint. But I can help with that. :)

We would also need to get an external antenna hooked up and run outside the transmitter building, as that building eats microwaves. Perhaps all the RF equipment causes interference as well, but if that were the case, I would expect that interference to be just as great immediately outside the building. Then again, the GPS antenna is outside the building and it works just fine (when it hasn't been struck by lightning, that is).

So, Dear Readers, have any of you in the radio business (are there any of you in the radio business?) done this? If you have, what have your experiences been?

KCUR audio link down

Apologies for the lack of updates lately, Dear Readers. I'll make up for it with a bunch of posts all in a row. :)

Two weeks ago (18 July) our T-1 audio link between the transmitter and the studio went down. Robin got a call from the monitoring hardware at 0345, then switched over to our backup link. Robin called me the following Monday to say he'd had "an eventful weekend", and rather than meeting him at the transmitter, I ought to meet him at the station. When I got there, he was calmly updating the EAS logs. This may strike you, Dear Reader, as odd, so allow me to explain Robin's philosophy of "important" vs. "pressing".

When I first met Robin, he explained that a given engineering issue can be thought of in two dimensions, "important" and "pressing". An "important" issue directly affects the running of the station - in this case, the audio link between the station and the transmitter going down. A "pressing" issue is an issue that needs to be addressed immediately. The audio link falls into this category as well. However, once Robin had switched to the backup link, the issue continued to be important - after all, with the primary link down, the station was running "without a net", if you will - but the backup link would serve well enough through the weekend, so it was no longer pressing.

Anyway, after he was done with the EAS logs, Robin decided to call AT&T and register a trouble ticket as he was pretty sure it was a telco issue. He got an ETA for the AT&T technician of "soon" and we headed out to the TX to meet the tech. When we got there, the tech hadn't arrived yet, so I set about taking the readings as usual. Everything looked normal on the readings except (of course) the T-1, which was showing an alarm.

When the AT&T guy finally got there, he determined that the problem was a bad pair, and set about finding a good one. It's curious to me, Dear Reader, how much trouble two little copper wires can cause. Somebody can break them with a backhoe. Water can (conceivably) get in and corrode the wires and/or cause a short. Or, as the AT&T tech surmised in our case, lightning can strike and fry the wires and the card attached to those wires.

Once the AT&T guy had found a good pair and replaced the T-1 card, we were good to go again. If we'd had a microwave STL, this wouldn't have happened. However, microwave STL's have their own set of potential problems, I'm certain.

Going to the barnraising!

Thanks to a generous donation, I have managed to cover registration costs for the WGXC barnraising. I'm trying to arrange housing via Couchsurfing.org. I still need to cover travel expenses and food while I'm there, so I'm still looking for donations. Locals, I'm also willing to work in exchange for a donation to the cause - just let me know what you need done.

WGXC Barnraising!

http://prometheusradio.org/WGXC_barnraising

I heard about this on pubtech. They're putting up a full-power FM community radio station the last weekend in September. I totally want to go to this, but the registration alone is $100 at minimum (it's a sliding scale type of thing). Still, that's valuable experience, and I've got a couple of months to make arrangements...

Recently at and around KCUR

Sorry that I haven't updated. I've been busy with my Real Job™

Since Monday was a holiday, I went to the transmitter on Tuesday. I took the logs as I have been doing, then Robin and I changed the air filters on all the equipment. Our BE FM703i (HD transmitter) has washable air filters, which is cool. Our BE FM30B (analog FM transmitter) does not have washable air filters, but its air intake is half the size of the air filters Robin buys. When it's time to change the filter, he flips the filter that's in there upside down, allowing one filter to serve two duty cycles (a couple of months, IIRC).

Wednesday I met Robin over at the studio for some DAD hands-on training. Except it wasn't quite hands-on, more "look at the way we have DAD set up." And that's good, but to really get a feel for DAD I'm going to need to fiddle with it myself. Maybe Enco has an academic version or something, or maybe Robin will let me play with "MOM", our backup DAD installation.

Thursday I went to my first SBE (Society of Broadcast Engineers) meeting. At said meeting, it was moved that the dill pickle be adopted as the official pickle of our chapter (I think it was some kind of running gag). The motion carried with nearly unanimous support. We adjourned shortly after that to watch a presentation about the coolest things (at least according to Broadcast Engineering magazine) at this year's NAB show. Most notable were a couple of things that looked like their sole purpose was to allow a station to be run with fewer people. Automation, and the desire to reduce headcount, are everywhere.

I was also introduced to a couple of contract engineers. Robin wants me to try and go out on calls with them so that I can see more transmitters. I think that's a fine idea. I also want to visit WSMI, the radio station in my home town, and maybe some of the Spanish-language AM stations here in town. The more the better, after all.

Homework!

Friday at the transmitter, Robin gave me a homework assignment:

Assume a radio station that receives network programming over a satellite link. Assume that the receiver for this link uses a dry contact closure to signal an automation system to play local content. Set up this scenario in ENCO DAD (Digital Audio Delivery).

To begin with, I'll need to reference the DAD manual at http://enco.com/Help/mainindex.htm .

At first, I thought it might be under Switchers. It looks like this is only for equipment controlled via serial connection, though.

Next, I found DAD's General Purpose Interface. This looks promising: "The General Purpose Interface allows DAD to control external devices via relay outputs [GPO], and enables DAD to receive external command signals (inputs) [GPI] from devices such as a satellite controller, a master clock or a manual push button from a Console". I think we have a winner.

So, to begin with, I'll assume that there is a GPI card (or a USB GPI interface, but I'm just going to call it a "card") of some sort installed in the machine running DAD. I'll further assume that the GPI card has been installed in the DAD machine and set up according to the instructions. I'll assume that the length of the break in network programming is precisely known, rather than the satellite system signalling at the start of the break and at the end of the break. I'll assume that local content is live.

I'll use input #0 on my hypothetical GPI card for the satellite receiver. I'll use output #0 to control the switch from live to satellite. Assuming no other inputs connected to the card, my GPI file (I'll call it 'DAD.GPI') should look something like this:

"ENABLE GPO 0 FOR <x> SECONDS"
""
""
""
""
""
""
""

Note that "<x>" here is the length of the pause in satellite output, in seconds.

I'm not certain this is exactly what Robin had in mind. I'll give it to him and post his comments.

UPDATE: Robin's comments: "You are on the right track. You have the basics but it will take a little more to make it work."