Why Can’t Digital Signage Hardware Protocols Make Sense?
February 12, 2019 by guest author, Mitch Leathers
Guest Post: Luis Villafane, Maler
It’s been a while since Ive written anything for 16:9. I guess the muse did not come to me until just now.
I’ve been keeping a low profile because I’ve just been very busy. I did not go to ISE this year. I wanted to go, I really did, but I just could not make it. Too much work, too many children. But from what I read from Dave’s impressions, same software CMS houses, newer LEDs … and also a new office building for Riegel … without a roof-pool 🙁
Anyhow, the topic of my article (& hidden free advertising) is hardware protocols.
Against all my best judgement, we have taken a small step away from digital signage operations and management to develop a single piece of software that is able to monitor hardware. We got soooo tired of trying manufacturer software that more than once could not find its own machines on the local LAN. So … we gave up, and wrote our own.
That means all protocols for NovaStar controllers, LG, Samsung, NEC, Philips … all of them (all of the cool ones, at least) go into one single piece of software, completely embedded into a true monitoring system (you all know how much we like live monitoring).
We’ve developed commands that are really worth having and my engineers have become so “native” with the damn protocols that we even renamed some of those commands with the bugs or issues associated with them.
For example:
The “power off” command – We now call it the “goodbye” command, because you wont be able to power it back on …(well thought out, guys).
The “Check COM Port status” command – We call it the “GuessWho?” command, because you never know which crappy software is not releasing it.
There is also another set of commands that follows the double negative train of thought of Asian languages: For example – ScreenOFF.
Now, read slowly:
This command can be set to either ON or OFF.
Thus, “ScreenOFF ON” means that the panel is off.
However, “ScreenOFF OFF” means that the panel is ON.
Clear enough?
I know …
When working with someone else’s hardware, you are obviously limited to what the hardware does, thus, you cannot ask a controller “their name” if the hardware doesn’t know it. So, this next one is even better:
I have an LED controller, the controller has 4 network cards. Network card numbering and coding is different. So, “Net 0” is actually 1, 1 is 2, 2 is 3 and 4 is 5. Or is it the other way around? Aaaargh!!!
On this controller, I have 50 LED cabinets per network card, and I am actually forced to have to ask each one of those cabinets for their status, because the controller doesn’t store that info.
So, 0.75s for sending the command and receiving it, multiplied by 50 cabinets = 37.5 seconds.
Times 4 network cards = 150 seconds (if none fails).
That means 2.3 minutes for knowing if a panel is OK or not.
Uff … come on guys, really? You have to do better.
This is really why it has taken so long to develop it. Translating a “Programmer/Lab Engineer Logic” is hard, really hard. There was a point where we didnt really know if we were setting something on or off or asking zeros at 1… BUT, all sorted now & looking beautiful.
So, all of you get in line, I have licensing for everyone. Hurry, because Ive got a few clients that want it for themselves. But as of now, I own it, and it is mine, all mine … MUHAHAHAHA!
Editor’s note: This guest post treads a line between editorial and advertorial, but I thought about it and concluded Luis is making too many good points here about painful hardware design decisions, and doesn’t expressly mention his product anywhere. My benchmark is guest posts need to advance understanding of something, and this does.
Plus he’s cheeky, as always.
How do we find out more?
Excellent post on the “real world” of programming nightmares! A great morning read!
you may ask Dave for my contact email address.
Good stuff, as always, Luis! One of my longest standing pet peeves is the lack of any standards with respect to RS232 protocols. It is common practice for different models *within the same brand family* to have different instruction sets for SIMPLE ACTIONS such as ON/OFF and volume control. It is irritating beyond belief. And as you point out, their own documentation is often borderline useless. The irony here is that these are the same geniuses who are telling you that they should be trusted with operating systems and CMS software. After all these years they can’t even sit around a table with neutral AV professionals anxious to help and develop standards. Is volume control a trade secret?
Stay cranky, my friend, stay cranky.