All Digital

As of Wednesday Oct. 12, WSBF's web stream is digital, all the way through the chain.  WSBF's studio A control board is a PR&E Airwave Digital; when I started this project, the auxiliary analog output for our control board's Program 1 was used for web streaming and the digital output was used for our over the air broadcast.  I originally implemented a way to use the digital output from Program 2 for our web stream, but we soon realized that, because our phone module can only output to one Program channel at a time, we wouldn't be able to hear callers over the air and on the web stream at the same time.  I tried to fix this by swapping some Studio Hub cables around to let Program 1 go to both places.  Unfortunately, we figured out that the same Studio Hub cable that brings the digital Program 2 audio into the production studio also brings the production computer audio back into studio A, so my first efforts to implement this solution left a live session silent for a few minutes.  Eventually I came up with a combination of connections that would let Program 1 go to both places and still allow the production studio to work.  At this point, for the first time, WSBF's web stream was post dump and post EAS, but the chain was still not entirely digital.  The digital Program 1 audio was going into the processor that we used for web streaming, but it was going out of the processor to the transcoding computer as analog.  To fix this I found an old audio card, an RME Digi96/8 PST, that supports AES/EBU audio; I looked up some info on Linux support for the card and luckily it works with OSS, which is what our system already used.  I installed the card in the computer and was not the least bit surprised when it didn't work.  After a few hours of reinstalling OSS and tinkering with settings, I go the card to show up as being installed, but I couldn't change any settings for it.  On a hunch, David Cohen installed pulseaudio on the computer and that allowed us to change the settings of the sound card to use the correct input and format.  At that point though, the sound card still wouldn't work, so it was back to a couple more hours of tinkering with OSS settings.  After a lot of research and a few restarts, I launched Darkice, refreshed the listen now page, clicked play, and something wonderful happened; the all digital audio poured out of my speakers.  You can hear for yourself at wsbf.net/listen.

A New Year

It's a new year for WSBF and the engineering department has been hard at work.  Over the summer, Computer Engineer David Cohen and I decided to completely redo the website, get rid of Drupal, and replace our haphazard database.  We also want to change our server from a Windows server to a Linux server, and after evaluating moving our Drupal site over, we decided to start fresh.  Our old database had become completely disorganized after years of adding on to it and various hacks and fixes to try to make it work with new systems.  With help from Clemson Ph.D. student in computer science, Yates Montieth, we managed to design an all new MySQL database in third normal form for the website and port over all the useful information from the old database.  After that we've been working on porting over and rewriting various systems we need for the station.  So far I've completely rewritten our CD review system; Music Director tools for moving rotation, editing reviews, and printing CD labels; and I've ported over all the music importing tools.  There's still a long list of things that need to be done, but for the station to function, these tools had to be completed first.  Through the process I've learned a lot about database design and normalization.  I've learned a great deal about MySQL, PHP, and JavaScript, which I'll continue to use to help David complete the website; however, my biggest responsibility in the process of rebuilding the website is done, which should leave me more time to complete the various hardware projects I've been working on.  There is no rest for an engineer.

On Air Lights

Another project I'm undertaking is the installation of On Air and Recording lights at WSBF.  I'm not sure why this was never seen as important before now.  Any DJ who has had someone walk in the room while doing a mic segment knows that it can be pretty annoying.  On top of that, it sounds extremely unprofessional when you hear a door open and close or people having a background conversation over the radio.  On Air lights would prevent this from happening and would prevent, for example, unwanted cursing from someone who walk in the room during a mic segment from going out over the air.  The control board has a set of pins that output a voltage when the mic channels are turned on.  This voltage can be used to control a relay that will turn on On Air lights above both entrances to Studio A.  The recording studio also needs a set of lights to notify people when a band is recording.  The light here is even more important because the are no windows on the door to the recording studio.  This means anyone could just walk in on a band and potentially ruin a take or even mess then up on the air during a Live Session.  To prevent this I will install recording lights above both doors to the recording studio.  Since there isn't any kind of interface available for me to use to make the lights turn on automatically when recording begins, I will wire up a switch to a relay that will turn the lights on and off.  Once these lights are installed I think it will increase our professionalism and improve our broadcast quality, which is the ultimate goal for any radio station.

Backup Automation/Silence Detection

Broadcast Tools Smart Silence Monitor

Last semester I implemented silence detection at WSBF, which is much needed because our commercial automation software crashes anytime it runs for about fifteen minutes.  I used a Broadcast Tools SSM silence monitor that I found in a cabinet at the station.  I assume the device wasn't being used because it is for analog audio and we use a digital signal.  I devised a way to make it work by having the SSM monitor the analog output of the STL, then passing the digital output of the STL through the normally closed relays and connecting the digital output of a computer to the normally open relays.  This works because the SSM doesn't interact with the signal connected to the relays at all, it just switches between them.  By having the SSM monitor the STL, it keeps the silence detection from being falsely reset when Backup Automation kicks in, which is what would happen if the SSM monitored the over the air broadcast or the output of the processor.  When two minutes of silence is detected, the SSM sends a pulse to our VRC2500 Remote Transmitter Control.  When this happens it tells the Lynx software to launch the Backup Automation software.  The program prevents multiple instances of itself from running, otherwise, every two minutes the SSM would send another pulse and Lynx would launch another instance of Backup Automation.  This program is a piece of software that I wrote in trusty Visual Basic 6, which I call Quick and Dirty Backup Automation.  The program and its source code can be found on the Solutions page of this blog.  It is pretty simple software; when launched it plays songs from a folder, and every four songs it plays a PSA from another folder and a station ID from another folder.  This week I went back to the code and added support for playing the station ID at the top of every hour to ensure we stay FCC compliant when the program is in use.  This software doesn't have a lot of features, but it does exactly what we need it to do, and it does it well.  The simplicity of the program is responsible for its key feature: reliability.  We've left the program running on a computer at the transmitter site for close to five months with no issues whatsoever.  Silence Detection and Backup Automation have already saved us from countless hours of dead air, and, at least until Zach Musgrave finishes his Automation software, it is definitely a necessity for WSBF.

The Transmitter Shack

Last week my trusty Equipment Engineer, Marc William Fisher III, and I went out to the transmitter shack to clean it up.  It took about four hours of sweeping, vacuuming, and organizing to make the tiny room look somewhat clean.  The transmitter shack houses the most important and expensive piece of equipment WSBF owns, the transmitter.  Keeping the transmitter in a clean, well controlled environment is essential to successfully keep it running.  However, to say that the transmitter shack is run down would be an understatement.  Currently there are no lights in the shack, which makes it very difficult to work.  Repairing a transmitter in the dark is not something I would suggest to anyone.  We keep a flood lamp that we can plug in inside the shack for those times when light is necessary.  I suspect all of the light bulbs in building might be burned out, but there is a chance that the ballasts may be damaged as well.  In addition to not having any lights, the transmitter is open to the elements.  The attic crawl space isn't properly boarded up to the outside, which allows water, snow, animals, etc. into the attic.  There is also no cover closing the attic crawl space off from the inside of the building, which means all of these things can easily get inside to where the transmitter is and cause damage to it.  This also creates a concern with keeping the transmitter shack cool, as a lot of cold air can escape this way.  Overheating can also cause serious damage to the transmitter.  There's also an issue of water coming in under the front door.  Based on the mud on the floor, it is apparent that during heavy rain, water and mud seeps in under the door.  If this reaches the transmitter it could cause big electrical problems, or even a fire.  We have a device designed to suck moisture out of the building, but as far as I can tell it doesn't appear to be functioning, and may need to be repaired or replaced.  There are also a few regulatory things that need to be taken care of to stay FCC compliant.  We need to have signs on the gate and tower with our contact info and tower number, respectively.  We're also required to have modulation monitors.  While we do have these monitors, they seem to malfunction anytime they are touched.  They seem to recover after an unknown period of time, as they are always working when I go out there, but if any of the buttons are pressed, they stop working.  I need to look into repairing, or possibly replacing these as well.  Fixing all of these issues is essential to keeping the radio station in working order and are a priority.

Spring Break... In more ways than one.

This week hasn't been terribly productive in terms of projects.  The engineering staff of WSBF, after returning from spring break, found that a lot of things had broken while we were gone and we spent a good bit of this week repairing them.  Sometime over spring break the university shut the power off and I assume that was the cause of most of our problems.  First, the computer monitor in studio A died on us.  We found the capacitors inside had blown, which wasn't a surprise because it's pretty common in this brand of monitor and, in fact, the other monitor we have had the same problem about a year ago.  We ordered some more capacitors and the monitor will be fixed as soon as they get here.  Next up, the computer that transcodes the audio for the web stream died on us.  In a hurry to get it back up, we just put the hard drive and audio card in another computer and it worked immediately.  The website spent a good bit of time down after the the power outage and once the server came back up archiving wasn't working.  Zach Musgrave and David Cohen fixed those issues, so they can blog about that if they want.  I am pleased that when automation crashed over the break (as it always does) that silence detection and my backup automation software (which has been running on a computer at the transmitter since November) kicked in and picked up the slack.  I'll post more about that whole system one day in the future.

More Updates.

I think the RDS Sender is completely finished.  Since the radio station doesn't actually have a radio that can receive RDS, the only way for us to know if it worked is to go out to the transmitter and look at the RDS encoder, or have David Cohen sit in his car and watch.  This makes it pretty hard to get a good opportunity to test the program.  Wednesday night David and I had a chance to try it out, but to our chagrin we couldn't get it to work.  Some exploring on Thursday revealed that the program was generating a fatal error because when the PHP serial class attempted to execute "mode" to set the baud rate and other settings, it would claim that it was not a valid command.  Despite being able to run the mode command from the terminal it still claimed it didn't exist.  I tried changing it to the absolute path, but it still didn't work.  As far as I can tell, PHP just doesn't have permission to execute the mode command, but then I would have expected to get a permission denied error.  Either way, because we only use our serial port for one thing, we don't ever need to change any of the default settings, which means we never really need to try to run the mode command from PHP anyway.  I commented out the section of code that tried to set the baud rate and such, and now I can run the script without getting an error.  I assume this to mean that it works, but I can't really know until David Cohen is in his car.  As soon as I've confirmed it working, I'll post the source and instructions for use.  I'll leave in the commented out section of setting the baud rate in case anyone who uses it ever needs to change the settings and they give PHP permission to execute such commands.


As for the Remote Dump Panel, I've researched all the parts I think I'll need and the total comes to about $75.  Once we get those ordered and they come in I'll keep the blog up to date with progress on the build.