Stern Star Trek: Reverse Engring the RGB LEDs

Quick post tonight before I go to bed.

I'm attempting to reverse engineer the RGB protocol used on the Stern Star Trek LEDs.
With some help from a fellow Pinhead here in Austin; we observed that the RGBs are being enabled via a custom microcontroller which speaks RS485 with the main CPU board in the backbox. This RS485 buss is then used to enable the various LEDs with some kind of instruction set.

With this observation; I bought a USB RS485 adapter from Sparkfun and then made a custom RJ45 cable which plugs into an empty RJ45 connector on the LED boards.

I then hooked up an Oscope and measured the smallest pulse width on the buss and measured ~8-12uS. Running the reciprocal of that gives me a baud rate which approximates 115200.

With that data; I set my RS485 adapter's com port to 115200, 8bit, no parity, 1stop bit... and captured some traces.

I'll post these traces tomorrow if some people agree to "group project" this and share the data / findings. I don't want one person "cornering" this info and attempting to prevent the others from making similar products. I'm being open about this - for the "group mind".

My end goal is "simple". I want to decode the protocol so I can interface it to the ColorDMD and change colors to match the mods currently in play. IE: Nero = purple, Save the Enterprise = green, etc. IF I can figure out the protocol then "in theory" it'd be possible to enable a cheap microcontroller to snoop the RS485 buss and switch colors in time to the missions active.

#2 9 years ago

HLT

herg

Cool project. Without knowing how you limited the machine activity during the captured traces, here's my thoughts:

1. If you have a trace while in a test mode with a single LED blinking, it will be much easier to isolate the command that is controlling it.
2. Timing information would be stripped from any captured data using the method you describe, and that timing might be useful in figuring out what's going on.

Good luck.

#3 9 years ago

RPL

QuarterGrabber

Inactive member

Ottawa, ON

10y 73,900 6,723 9 34

I believe I saw a post on here where some did this to a Tron pro. The color on the DMD changed with the different modes of the game. I believe his mod was tied into the Eli's ramp light mod and not the led's though.

#4 9 years ago

HLT

herg

Quoted from QuarterGrabber:
I believe I saw a post on here where some did this to a Tron pro. The color on the DMD changed with the different modes of the game. I believe his mod was tied into the Eli's ramp light mod and not the led's though.

That was me. That approach obviously doesn't work for what Zitt's trying to do, though.

#5 9 years ago

ABB

Aurich

Mods and Opinions

Torrance, CA

11y 144K 23,395 3

Cool, was wondering if someone would try and tackle this. Since there's no dead simple single light to slave the display too I'm guessing you'll need some kind of logic to track the mode inserts?

#6 9 years ago

ZIT

Zitt

Quoted from herg:
1. If you have a trace while in a test mode with a single LED blinking, it will be much easier to isolate the command that is controlling it.

Already done. One of the traces cycles thru the LEDs in test mode - one LED at a time. The on the last LED in the chain... think it's Klingon Battle; it cycles White, R, G, B.

Quoted from Aurich:
Since there's no dead simple single light to slave the display too I'm guessing you'll need some kind of logic to track the mode inserts?

Yes; proably a MicroController to decode RS485.... and also determine logicially with mode is active.

#7 9 years ago

ABB

Aurich

Mods and Opinions

Torrance, CA

11y 144K 23,395 3

OP
Quoted from Zitt:
Yes; proably a MicroController to decode RS485.... and also determine logicially with mode is active.

Cool. Should be easy enough to make that determination once you've got the signals sorted out. In some ways this makes more sense than even the Tron color changing ColorDMD, I think it's a great idea.

#8 9 years ago

SKB

Eskaybee

Pinside member

12y 155K 12,964 40

Tag for later. I have the cables and components to dabble with this if I can find the time

#9 9 years ago

ZIT

Zitt

Cable built out using CAT5e cable.

CN1 (stern side)
Pin Signal Color

1 VNB White / Orange
2 GND Orange
3 D+ Green
4 VNB White / Blue
5 VNB Blue
6 D- White / Green
7 GND White / Brown
8 GND Brown

RS485 (Sparkfun) [ https://www.sparkfun.com/products/9822 & PRT-00643 ]
4 White / Brown (GND)
5 Brown (GND)
7 Green (D+)
8 White / Green (D-)
No Connects on RS485 side (pins 1,2,3,6)

Note: Only D+/- and the (2 of 3) grounds are connected to the rs485 side. VNBs remain no-connects to prevent ground loops or issues.

Disclaimer: Author takes ZERO responsibility for the misuse of this data. Author also not responsible for typos or mistakes. You fry your machine - don't expect me to foot the bill to repair it. You the reader take all responsibility for using this information.

#10 9 years ago

ZIT

Zitt

Traces can be downloaded from my Public Google Drive at:

http://goo.gl/YMOHny

stle_RGB_LED_traces.zip contains my initial trace captures. There are three files.
readme.txt contains a short description of the files contained in the archive.

attract1152008n1.log is a capture of the rs485 buss while the STLE was in attract mode. Started at a random time; ended at a random time.

singleLamp1152008n1.log is a capture of the buss while the STLE was in diagnostic single lamp mode. I started and stopped the traces at random times; however, I "commented to the log" each time I switched to a new lamp. As a result the data has some "Garbage" in the file which you'll have to be aware of. In every case; the lamps were set to display white (default) until I got the the Klingon Battle insert - at that point I cycled from white -> red -> green -> blue.

If you open the file single lamp file with a hex editor you'll see it's mostly FFs.
At about offset 0x326de; you'll see the string "capt". This was a comment to the log during the cap chair insert test. It blinks White; then off. All comments to the log are NOT real - Not in the data stream; so keep this in mind when you start your "cracking" of the data stream.

Other comments to the log include:

save 0x0d 0x0a = Save the Enterprise @ white
nero 0x0d 0x0a = Nero @ white
drill 0x0d 0x0a = Attack the Dril @ white
space 0x0d 0x0a = space jump @ white
prime 0x0d 0x0a = prime directive @ white
kling 0x0d 0x0a = klingon battle @ white
red 0x0d 0x0a = klingon battle @ red
grn 0x0d 0x0a = klingon battle @ green
blue 0x0d 0x0a = klingon battle @ blue

attract1152008n1.log does not have any comments in the log.

#11 9 years ago

ZIT

Zitt

Initial - quick scan of the data leads me to believe that the following byte values may be "start of stream" instructions:
0x3d 0xdf 0xfd

Unsure what 0x79, 0x78, 0x77 represent. Maybe board addresses?

I didn't see any indication in the stream as to a difference between "off" and "on". This could mean that I didn't successfully capture the right data or I'm missing something.

It's unclear if the "slave" microcontroller on the LED boards expects instructional data as in here; go turn on bit X in shift register Y... or if it just watches the serial stream and counts bytes to know which to turn on/off.

One other possibility is that I have the cable wrong ... and maybe all I'm seeing is the "acknowledge" back from the LED boards. I might need to "swap" the D+ / D- signals to see if there is any impact.

#12 9 years ago

ART

OLDPINGUY

Arts Arcade

12y 171K 12,507 7

Once Again John, I am in awe!

Great Group Project!

#13 9 years ago

SBM

steve1515

Pinside member

Hmm... Looking at your files is seems that it is just an ACK from the boards. I don't see anything standing out that would indicate a color change. It's just the same data over and over again.

In your log, when you say something like "red". Does that comment appear before or after you've switched to red?

Another thing I noticed... If you look at the schematics, they show the board addresses. They look to correspond to the board numbers: 5, 6, and 7 with one having dip switches for setting the address.

One thing that you might want to try is unplugging all but one of the boards in the 485 chain and see how your data changes. That would determine if it is in fact an ACK that you are receiving. (Also try it without any boards plugged in.)

I also don't know why, but I have a hunch that 0x3d 0xdf 0xfd might be an end of transmission signal. Reminds me of the good old 0xDEAD 0xBEEF 0xFEED

I wonder if you could just ask Stern for the protocol? Maybe they would give it out?

Anyway cool thread. I'll try to help out if I can.

#14 9 years ago

SBM

steve1515

Pinside member

Upon a little closer inspection...

It looks like "board 8" contains unused inputs. I'm going to guess that unplugging this board will help you get better data. Maybe the CPU is querying this board and getting back FF's for all of those inputs.

#15 9 years ago

ZIT

Zitt

http://www.nxp.com/documents/data_sheet/74HC_HCT595.pdf

Quoted from steve1515:
Hmm... Looking at your files is seems that it is just an ACK from the boards.
I also don't know why, but I have a hunch that 0x3d 0xdf 0xfd might be an end of transmission signal. Reminds me of the good old 0xDEAD 0xBEEF 0xFEED
I wonder if you could just ask Stern for the protocol? Maybe they would give it out?
Anyway cool thread. I'll try to help out if I can.

I haven't asked; but I doubt Stern will give us this info. If someone has an inside track... feel free. I just feel like Stern wants to try and keep this a trade secret.

IIRC - There are no dip switches on the LED boards; I think they are hardwired to specific addresses.

Comments to the log are done after the changes were made to the game via menu. IE "in the middle" of the stream.
There's no real way to do anything else until we get closer on the protocols.

Quoted from steve1515:
Upon a little closer inspection...

It looks like "board 8" contains unused inputs. I'm going to guess that unplugging this board will help you get better data. Maybe the CPU is querying this board and getting back FF's for all of those inputs.

I'm in the middle of prepping for QuakeCon where I hope to do a pin-event for charity.
When I get back and settled back in; I can try to swap the A/B lines.

#16 9 years ago

FLE

flecom

Pinside member

Miami, FL

12y 53,650 852 44 36

I haven't looked under my star trek in a while but aren't they just using a bunch of 74HC595 in series?

decent writeup here on using 74HC595 serial to parallel shift registers here

http://arduino.cc/en/tutorial/ShiftOut

and

http://bildr.org/?s=74hc595

great little chip

#17 9 years ago

JAM

Wolfmarsh

Pinside member

12y 134K 10,956

I would recommend using a piece of software to analyze the logs. There are a couple free RS-485 analyzers out there.

Also, if they are in fact using a shift register, you would see the data for each LED being pushed out for each refresh cycle, and not a single command that is like "LED 35, RED".

#18 9 years ago

HLT

herg

I don't own an LE machine myslef, but from what I understood, there is a microcontroller that takes a RS485 input and handles the low level stuff, offloading the main CPU. Zitt is looking at the input to the microcontroller... I think.

#19 9 years ago

SBM

steve1515

Pinside member

Looking at the manual, it's RS-232 out from the CPU that goes into a bridging microcontroller (AVR) out to RS-485. The RS-485 bus/network contains 4 ARM controllers that are addressable. These ARMs drive the 74HC595s. So, I'm guessing that there would be some kind of addressed command sent out along with a byte where each bit is an output state to the 74HC595s.

Sounds like it should be pretty simple to see, but the data shows other wise.

#20 9 years ago

TOM

kapsreiter

Pinside member

Linz

10y 59,400 1,838 10

great project

i hope a connector pcb is available soon
to get a colordmd running

1 week later

#21 9 years ago

TOM

kapsreiter

Pinside member

Linz

10y 59,400 1,838 10

is someone still working on it?

any news?

#22 9 years ago

ZIT

Zitt

The term is group project.
I've been busy with other projects

#23 9 years ago

TOM

kapsreiter

Pinside member

Linz

10y 59,400 1,838 10

i don't have the programming and hardware engineering skills for that

just basic technical skills

and full motivated

1 week later

#24 9 years ago

ZIT

Zitt

I tried again tonight to capture "Clean data".

I tried inverting RTS using FTPROG... and playing with the setting of CBUS2. No dice.
I even went so far as to tie the SP3485 !RE and DE lines to ground to force the transceiver into only receive mode.

Data looks the same with the new captures.

I tried making a new cable with D+/D- swapped at the RS485(USB) end... but it just caused the Inserts to freeze.

Not sure what else I can do to capture different data.
I didn't try inverting RXD/TXD using FTPROG... not sure it would yield interesting data.
Maybe I should move to the RS232 side?
Ideas?

#25 9 years ago

HLT

herg

Any chance you could post a scope trace so that we could double-check your findings on baud rate, protocol settings, etc?

#26 9 years ago

SBM

steve1515

Pinside member

Could you unplug all boards except for the CPU and see what's being sent out? That should eliminate any extra "noise" in the data.

#27 9 years ago

ZIT

Zitt

Not sure my portable oscope (temna) would do a good job of showing anything other baud rate.
Let me ponder on this for a bit.

I don't think the FFs are noise. Plus; unsure how the software will react to having a unconnected LED string. (IF the led board answer back to the LED node bridge)

In the meantime; I've "reset" my goals on this project. Given *MY* goal was to sync ColorDMD colors to the "active" missions on the center RGB cluster... I spent about 1.5hrs creating a RS232 snooper board to piggy back on the CPU board => LED node board's communication. Has two RJ11 6pin connectors for "pass thru" to the LED board and a DB9 for connecting to a USB RS232 adapter.
http://www.chipkin.com/rs232-serial-port-sniffing-snooping/

Board was 1.25x2inches... and is on order as of tonight from OSHPark. Probably will be at least 2-3wks before I get a board back to test with.

My reasoning is the DMD is inside the backbox along with the reference boards; so if the 232 communications are easier to reverse engineer; then it's probably a better design anyway.

YES, I could have hacked a simple cable up... but didn't want to risk my $8k LE with a funky cable issue.

2 years later

#28 6 years ago

JAB

jabdoa

Inactive member

7y 46,050 448

Hi,

we implemented most of the SPIKE bus protocol in the Mission Pinball Framework a while back. You can find our implementation here: https://github.com/missionpinball/mpf/blob/dev/mpf/platforms/spike/spike.py and https://github.com/missionpinball/mpf/blob/dev/mpf/platforms/spike/spike_defines.py. Most stuff is supported: coil enable/pulse/disable, coil rules (single and dual wound flippers, pop bumpers, slings), lights/LEDs/GIs with fading, backbox light, backbox andcabinet switches (DIP and operator switches are not connected via the node boards), reading current and status values from node board. We documented most methods but did not implement those where we did not have the hardware (e.g. LCD node boards). Message format looks like this:

8x ll cc dd dd dd kk rr (x = node, ll = length, cc = cmd, dd = variable data kk = checksum, rr = response len)
kk = (all bytes mod 256) - 256

Jan

#29 6 years ago

ZIT

Zitt

Thanks. Ill look at this when i get sone time.

#30 6 years ago

GTX

gtxjoe

Pinside member

Chicago, IL

10y 35,050 253

There is a flavor of vpinmame that has working Stern SAM aux board support including RGB inserts. Discussion is at vpuniverse

#31 6 years ago

JAB

jabdoa

Inactive member

7y 46,050 448

Quoted from gtxjoe:
There is a flavor of vpinmame that has working Stern SAM aux board support including RGB inserts. Discussion is at vpuniverse

This is about Stern SPIKE not SAM. I would be interested to add SAM support to MPF but that might require a bit more work and would be off topic here.

#32 6 years ago

ZIT

Zitt

https://github.com/djrobx/SAMbuild/blob/SAM/src/wpc/sam.c#L959

I looked at my captured log... and didn't seen anything matching this protocol.
It's possible the protocol is different; or I just didn't capture at the proper baud rate.

#33 6 years ago

JAB

jabdoa

Inactive member

7y 46,050 448

I captured the bus to verify that it is the same as on the CPU. I think they got an additional stop bits or something there. Definitely 460800 baud. There is another LED command which sets all LEDs. I guess it is used in service mode. I checked on WWE.

Jan

#34 6 years ago

JOE

lucky1

Pinside member

Karlsruhe

8y 61,050 1,091 16

Maybe this helps

#35 6 years ago

ZIT

Zitt