Archive
Studio M Goes Live!
This morning we went live from Studio M at 6:00am PDT. The transition went smooth. The combination of automation conditions, cross-point control, and humans came together and we did it!
As you may have guessed or if you read the blog, we are an SAS house. This studio consists of a Rubicon SL-24 & a Rubicon SL-8 in a split console configuration. We currently use the Enco DAD system on which we run an older version (long story). We have 3 touch monitors on this computer, one extended to the producer. We have the Audio VoxPro with 2 controllers, 2 monitors. Call screener appears on 3 monitors.
It flies. We like it. Now I get to do my job. More later. Gotta run!
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.
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.
Tech Notes from the Field 