Screenkeys Library

Status
Not open for further replies.
sumotoy

sumotoy

Well-known member
LCD_Key1.jpg
I got several Screenkeys LC16 buttons from an auction in ebay for very cheap. These buttons have an LCD inside with multicolor background so I buildup a library for use several of this buttons without sacrifice pins from Teensy.
These buttons are really expensive but actually it's not rare find on ebay used video modules that uses a lot of them, probably because several studios have changed the serial standard.
Using this buttons it's not so easy, they need a constant clock (or they will destroy quickly) and protocol has some weird needs but they are cool so I find a way to reuse them by adding some hardware around to save MCU resources as much I can.
I was not able to find any working code for these buttons so I decided to wrote one for Teensy3 that it's the perfect MCU for these buttons, I was able to connect 64 without using too much resources and just 4 pin dedicated (not included MOSI,MISO and SCK that can be shared with other periferal).
I'm still developing this, prototype worked but was build up in a sketch to I used a library for easy integrate library with other projects and can be extended easily to other type of Screenkeys (like LC24 or full color ones), atually it works but not optimized.
I also created the Eagle component for these buttons and preparing some PCB for build up some projects.
On GitHub https://github.com/sumotoy/screenkeys
Thanks all and have fun!

Addendum:
Normally these buttons are mounted in serial video switcher that use a protocol based on RS485 but I cannot find any info, if someone here have some knoledge about these video serial protocols will be interesting for me know more about...
 
Last edited:
I don't know, they are normally used in stuff for Video Studios or Avionics, never see in a shop. Some time ago SparkFun has in catalog but they retired.
There's a distributor in USA http://www.trgcomponents.com/TrgUS/Internet/ProductShow.aspx?ItemID=5732 but as I said I find occasionally on Ebay in item like this one http://www.ebay.com/itm/390716022985?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649 , around 1 US each!
These units are from BFE but there's from Philips, Abekas, etc. Last year I loose an entire large remote control that uses around 300 of this buttons and gone for 120 US. All these units use a kinda of RS485 protocol very popular in video but I wasn't able to find any info about, so I decided to dismantle one unit. Inside the classic FPGA and a lot of gpio from ntx, very interesting to study for an un'usual way to use I2C by using RS485 transceiver inside (to avoid noises problems).
It's fun dismantle old stuff and give new life, expecially when it's well maded and not chinese!
 
Last edited:
RS-485 is just half-duplex serial with differential signal levels. There are 8 pin RS-485 chip that convert the serial pins on Teensy to that type of signal. Usually 3 pins are needed, RX, TX and a pin to control whether to transmit or receive. The chip converts that to the 2 signals (often called "A" & "B" or "+" and "-") that are RS-485.

Of course, to actually communicate, you'll need to know the baud rate, format (8N1, 7E1, etc) and what the bytes mean. RS-485 protocols usually have a command-response design, and some scheme to assign unique addresses to each slave device. A slave device typically listens for command to its address and turns on its transmitter to send a reply when it hears a valid command. All the other slave devices will ignore the command because its not to their address, and they will ignore the response because it's distinctly different than any command.

The master sending commands needs to be designed to turn its transmitter off quickly after sending a command. Often RS-485 protocols have a minimum and maximum "turn around time" spec, where the slave device will not begin transmitting a response for some minimum time after it hears a command (to allow the transmitter to turn off its transmitter), and a maximum response time too, since the master needs to be able to know when to stop listening for a reply that never arrives, before it can turn its transmitter back on to talk to something else.

It's possible to build more complex peer-to-peer schemes, usually based on token passing, to determine which device is able to transmit when. I've seen that done on RS-485 once, and it's quite complicated. Usually most RS-485 ptotocols define the bytes, messages and timing for the relatively simple strategy of a single master sending commands to uniquely addressed slave devices, which must reply within specific timing windows.

So even though RS-485 is "only" serial, which Teensy can easily do, to have any hope of using these buttons you'll need to find some info about the protocol they use.
 
Last edited:
The protocol it's the tricky part! I emailed BFE and they was really gentle but they not provide any info about protocol since it looks like a company secret. It's based around a video industry RS485 protocol (can't remember name now but was developed to drive video tape recorders by serial) but in the years every company modified it and now they switched to another custom protocol on ethernet so why there's many of these modules on the net. This is the reason I dismantled one and hacked buttons to work with Teensy!
I also emailed Screenkeys and they confirmed all buttons are still in production but as I said not easy to find.
But thanks about RS485 infos, I find an hardware address on the back of these units and get a USB to RS485 transceiver for my laptop so I can loose some time to inject some command and findout how these modules respond.
 
Do you have any equipment or software that makes these buttons actually work?

That's the easiest way to reverse engineer RS-485 protocols, by watching the line while 2 or more talk to each other.

Another simple reverse engineering trick involves changing the power supply voltage at the RS-485 chip of one device, and making sure the line is not terminated but has short wires. Then when you view on a scope, it's easy to see which bytes are from that device, because it doesn't drive the line with as much voltage as the other side. Many RS-485 protocols are very simple, so just knowing which bytes are from each side is often enough to make a lot of it pretty evident.

But without being able to observe working devices talking to each other, you'll be facing a pretty tough task. Well, unless you can find any info about the protocol to get you started.
 
Status
Not open for further replies.
Back
Top