• Get involved.
    We want your input!
    Apply for Membership and join the conversations about everything related to broadcasting.

    After we receive your registration, a moderator will review it. After your registration is approved, you will be permitted to post.
    If you use a disposable or false email address, your registration will be rejected.

    After your membership is approved, please take a minute to tell us a little bit about yourself.
    https://www.radiodiscussions.com/forums/introduce-yourself.1088/

    Thanks in advance and have fun!
    RadioDiscussions Administrators

XDS relays "delayed" w/ Nexgen?

ssndradio

New Participating Member
Hey All;

I have a problem that is driving me insane -- during NFL broadcasts (since the start of pre-season), there is about a 3 count from when the relay is thrown to when the automation system (Nexgen) actually fires the break. I've triple-checked the wiring, the netcues, Nexgen can see it when the pins are shorted, and yet when they call for a break it's silent and then about "one thousand one, one thousand two, one thousand 3... spot block fires'. I called RCS who sat on the phone with me during one of the games only to tell me it must be the receiver... I did get a new XDS from WW1 because last week I was only getting half the breaks firing; funny thing is that the ones that were firing intermittently were firing immediately with no delay...

I know it's not the network -- other automated stations fire breaks immediately. I did call around and found one other station who is having the same issue -- they use DJB automation -- but their solution was to make the breaks 2-3 seconds shorter and just live with it. I won't live with that lol

We dropped most all talk programming, but I do have some USA Radio programming on the same receiver that I've tested with -- the breaks there fire just fine. So to me that rules out the automation (although that is wired into the other audio output and is in another studio).

Anyone have any other ideas or tips? Ever had something like this happen?
 
Your trouble sounds like it might be the relay mapping in the receiver. The relay output which you are using may be set as a NC output rather than a NO output.
 
You're carrying NFL from which network? XDS has SUSA as well as individual team broadcasts. We take the Jaguars on one of our stations with no problems. I've also had no issues with SUSA on another station. The rest of the NFL we carry is from WWO and those use the Wegener iPump 6240 receiver. On those games, there is a delay between the announcer cue and the local break start, but it seems to be on the network end, because we never come back to the broadcast late.
 
A couple things come to mind: We have the newer version, Zetta, and have found GPI delays from firing cause by two potential things:

1. The system is doing it's daily reconciling of the database around the time of the delayed trigger. Moving the scheduled database maintenance time seemed to reduce the problem to hours where it didn't matter. The delay is caused because the system is busy doing database maintenance.

2. I believe NexGen has what amounts to a d-bounce feature, which holds to react for however many milliseconds if it received multiple contact closures from the receiver or source. Are you using a Broadcast Tools SS8.2, or some other device that takes the closure and converts it to serial to feed the automation?
 
I believe NexGen has what amounts to a d-bounce feature, which holds to react for however many milliseconds if it received multiple contact closures from the receiver or source. Are you using a Broadcast Tools SS8.2, or some other device that takes the closure and converts it to serial to feed the automation?

That's actually a very good point, though I'm surprised that a de-bounce feature would be part of the automation. If so however, you'd think the trigger would be on the leading edge of the input, with the de-bounce timeout preventing subsequent firings.

In any case, as I think Kelly may be leading to... a Broadcast Tools switcher has the same feature. By default, it's pretty fast, but it does hold whatever programming was entered into it, so if someone might have once set a long delay into the memory, it might still be holding that.

In any case though, 3 seconds is an awfully long time for any de-bounce function.

As for working through this with the network; making the point would be easy if you took the time to put a pushbutton over the relay contacts and simulated a break. If you get the same delayed result you're seeing now, you've proven it's the automation, whatever translates the relay closures to the input the computer uses... or maybe even something in the computer itself. On the other hand, if the break fires off immediately, you've got a receiver issue, and that makes it a little harder for either side to point fingers at the other.
 
Last edited:
Status
This thread has been closed due to inactivity. You can create a new thread to discuss this topic.
Back
Top Bottom