Skip to main content

Hello, Timing Guys.

I work with Electro-Mech Scoreboard Company. We're a U.S. manufacturer of electronic scoreboard displays with a 50-year history and tens of thousands of scoreboards in use around the country. We are working on some product changes that we hope will make it easier for other folks' hardware/software to grab data generated by our scoreboard controllers. We've had numerous requests from customers who want to generate scorebugs for their video productions, provide live scoring updates on their web sites, collect stats, etc.

I'm hoping that the folks on this forum can provide guidance as Electro-Mech develops the hardware and software that will offer a better interface to computers, character generators, and other devices that can consume scoring and timing data. Maybe this project will make your lives easier, if you end up working on events at facilities with Electro-Mech scoreboards.

I've seen a variety of video tools (from NewTek, Ross Video, and Graphics Outfitters, for example) that claim to provide an interface for use with Daktronics, Fair-Play, OES, and White Way scoreboards. It looks like the hardware connection is made through an RS-232 port on the scoreboard control consoles. So far, I haven't found any specifications about the particular protocol being used or the format of the data. Does anyone here have knowledge about these details? Do you have an opinion as to whether RS-232 provides the best/easiest/most reliable way to communicate this sort of data? If the methods used by Daktronics and the other guys are not optimal, what would you recommend instead?

Thanks in advance for any advice you can provide!

Regards,
Chap McMichael
Electro-Mech Scoreboard Co.
Original Post
Hi, my company (Broder's Skunkware - see WWW.SKUNKWARE.TV and WWW.SKUNKWARE.US) has done extensive interfacing to Daktronics boards at stadiums in about 20 countries for showjumping, dressage, 3-Day Eventing, soccer, NASCAR, tennis (Australian Open & US Open both have permanent Daktronics boards), cycling, rodeo, chuck wagon racing, and alpine ski racing. Most of our commercial timing & scoring products support Daktronics, and Daktronics themselves licenses several flavors of our application software for various sports.

Daktronics has two very flexible & robust protocols, RTD (Real-Time Data) and ERTD (Enhanced RTD). Both are supported on most Daktronics scoreboard controllers via RS-232, UDP, Named Pipes, and TCP/IP (both client and server). If you want more detailed info than that, you'll have to contact Daktronics and sign an NDA.

My opinions in reply to your question: RS-232 has been dead as a transmission protocol for almost a decade. Go onto the internet and try to buy a laptop with an RS-232 port. See what I mean? In my opinion, USB is also dead. Some manufacturers (such as ALGE) have timing / scoring devices on the market utilizing USB, but the whole spec has fatal flaws for mission-critical data exchange. For example, something as simple as dirty power or a bad ground can trigger the USB device ID / enumeration process, which renders all the devices on the USB bus inop.

Clearly, sockets programming is where it's at. JSON, XML, or even fixed-length data exchanged via UDP or TCP/IP (preferably support both) is something any competent programmer will understand immediately, regardless of whether his lingua franca is C++, C#, VB, Java, Delphi, whatever.

You might also take a look at Lynx (www.FinishLynx.com), which has done a fantastic job with interfacing their devices. Lynx photofinish cameras come with a scriptable output channel. Hundreds of devices are supported via factory-written Lynx LSS script files, and data can be sent via serial, UDP, or TCP/IP (both server and client). Custom LSS files can be composed so that end-users can "roll their own".

I'd suggest you also take a look at Vizrt character generators (www.vizrt.com), which have a killer user-programmable data-exchange interface called Datapool. Viz also offers dozens if not hundreds of "Plug-Ins" supporting various data exchange formats and data-driven triggers.

Whatever you decide to do, remember to support multiple encodings so that your devices can deal with Kanji, Arabic, Hebrew, etc. All of the above support Unicode at a minimum, and multiple encodings at maximum.

Add Reply

Post
×
×
×
×
Link copied to your clipboard.
×