[EAS] RWT trigger detection...more info

[Mike McCarthy]

I'm leaving the whole post intact for reference.  Please do not edit.

It seems to me that folks are fascinated by trying to incorporate the 
remote control or bring a convoluted third path and hardware into the 
process.  Guys and gals, I'm trying to simplify this effort to the point 
a simple traffic'd automation audio cut can do all the work for one or 
many downstream EAS boxes.  BROAD.....CAST       SIM....PLE

Let me distill the scenario more.

I have a station who's EAS box is at the transmitter and the local 
operating area LP monitoring is on-site.  Remote control is dial-up and 
the audio path is one way STL. Sure it has IP access for CAP and logging 
via a third party.

Remember, it costs money both in materials, software, integration work, 
and labor to test and install any sort of workaround.  So much that I 
can't justify doing it for a once a week activity 40 times a year. 
(RMT's cover the other 12.)  Manual intervention through the remote 
control might be OK for a single station if you trust it will get done 
religiously.  But that's out if there is more than  one station and they 
run common content or there is no operations staff...period.

Now...Multiply by some number starting with 1  (More than one for a 
network.)   You will quickly see how any type of manual intervention is 
going to be a logistical challenge.  Especially for simulcast and 
networked stations fed directly by satellite....one way.

Now...on to activating the RWT function going forward.   By process of 
elimination and simplification, the concluded only way to activate is by 
some form of on-channel signalling.  Many networks realized this years 
ago to eliminate the human element.  Hmmm...Wheel...already invented.  
Why beat my head any more?

DTMF comes to mind.  Attributes are already well established, there is 
plenty of prior use in this capacity, gear is relatively low cost, and 
using a letter for one of the tones makes the system more secure.  25/35 
hz are out as they're used for other purposes.  I could adapt a cart 
machine decoder and detect 150Hz. and 8K.  Why bother other than for a 
science project?

So...We'll add a two toned signal at the end of the EAS intro to trigger 
some downstream decoder.

Security?  What security is needed.  The path to the TX is secure.  And 
even if the STL is hijacked, they will get one RWT a day.  Nothing 
more.  On satellites and other secure paths, security is more related to 
preventing content induced false triggers.  OK...so four tones.

OK....For less than $200 and an hour, I can do this with DTMF and 
nothing at the station end other than a modified audio cut.

That's settled.

The question I have specifically postulated is whether the EAS boxes can 
incorporate DTMF (or other standard audio tone detection) detection into 
the firmware with the intent the station would self-feed their pre-EAS 
program content to one of the monitored inputs, say #6 (or the last one 
if less).

I'm thinking two commands:  1) Trigger RWT.  2) Trigger message in 
waiting to forward.  The latter could be used for RMT's.... or anything 
in waiting really.

So...there it is.....I can't spell it out any more plainly.

As an aside, this method would also work on any automation system (such 
as OPLOG) which can't generate closures from audio cuts without some 
form of external hardware.  It makes it possible for ANY automation 
system to trigger RWT's (and forward messages waiting).  All by using a 
couple pairs of 500ms long tones. What a concept.....  No extra key 
strokes or programs to install.  Ideally only one extra wire too.

Comments...?  Other ideas which meet the same strict threshold of no 
additional hardware, software, paths, or workarounds and automation 
friendly?  It must be simple and able to be carried by the main channel 
for less than a couple hundred dollars.  Something I'm willing to pay if 
it keeps the station legal...reliably.

Harold, Darryl, Ed, what hath you say???

I'm now listening......

MM

On 7/6/2012 12:00 PM, Dale Lamm wrote:
> [snip]
>
> How would you introduce the closure to the remote control?  Therein lies
> the rub...short of a multiple box system costing a few $K, you can't.
>
> [end]
>
> Now your requirements become more clear. If the remote EAS unit is on
> the internet, and if the remote EAS unit contains a web server for
> manual control, a human could connect via a browser and click on the
> "Send RWT" icon. No need for anything else, assuming manual control is
> acceptable.
>
> Your requirements seem to indicate that an automation system should be
> able to initiate the RWT, which rules out using the site's remote
> control to issue a "raise" command on some channel to close a relay at
> the site.
>
> Many automation systems can close a local relay. Broadcast Tools make
> products "Status Sentinel" and "Relay Sentinel" which can be thought of
> as a very long multi-conductor cable, transferring a local closure via
> the internet to a remote relay.
>
> If spending money on such a solution is not possible, you might be back
> to the homebrew DTMF decoder at the site, along with injecting
> "announcements" containing a DTMF burst into the traffic log for
> playout. You'll have to deal with DTMF decoders that are not 100%
> perfect. What happens if something somewhere fades or drops and white
> noise hits the DTMF decoder?
>
> Here's another possibility, with the caveat that I don't know everything
> about your specific requirements. Go back to the first suggestion,
> bringing up the EAS on a web browser and clicking the "Send RWT" icon by
> hand. There are tools available for free that allow you to create
> mouse-keyboard macros that will execute a specific sequence of moves,
> keystrokes and clicks in a script file. You could start such a macro
> from Windows "scheduled tasks" utility. Of course, if the RWT is to be
> scheduled that way, then just tell the EAS unit to run the RWT on an
> internal schedule. I know our unit can do this on it's own.
>
> Let's work with this idea some more. Say you have the mouse-keyboard
> macro generator working just as you like. Now you need a way to launch
> the macro generator under command of the automation. The automation we
> use cannot directly launch a BAT or EXE file from an AUX event in the
> traffic log, so we have to get sneaky. You could construct a continually
> running script that watches the automation's "as-aired" log for the
> occurrence of a special event. For example, a song of zero length whose
> title is "SEND RWT". Traffic places this "song" into the log. When your
> script notices that this song has appeared in the tail end of the
> as-aired log, it would launch the BAT file that runs the macro generator
> and your RWT would go out.
>
> There you go, a truly Rube Goldberg solution that costs nothing but your
> time. Money back if not satisfied!
>