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.
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.
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.