Glow with *OUR* Show and MSP430G2553 discussion

[timon]

The only minor problem with the 10K tone is decoding it which is why I was thinking about a good old modem chip, if you can still find one, and just send 2400 baud modem tones to the recorder. If I remember 2400 baud does not do any training so you only need to just send.

The same chip could then be used to send from the recorder back to the computer.

Just a thought.

[rjchu]

Sorry for the delay in replying, I've been out of town for work for most of the past week...

The recording idea sounds interesting but, perhaps this can save everyone some time and trouble. Attached is a capture from World of Color that I Jon sent me to play with. It's got a fair number of 55 codes in it as well.

I'm still getting back into the swing of things after being out of town for so long and hope to play with some of the code posted here, these codes from Jon and everything else that's been going on in this thread for the past week. Good stuff!

Happy hunting,

-joni-

[rjchu]

Now that I'm back in town I've also been catching up on a couple emails with Jon and he asked for the link to our discussion (must have missed it when I sent it to him a while back). In any case, I think he'll be joining in the fun here soon which should really help this effort get wings...err EARS....and take off!

Thanks,

-joni-

[RobG]

BTW, are you familiar with MagiQuest? It's sort of like GwtS ears, but in reverse. Participants with IR wands control the show or activate different things. It could be fun to allow people to control some aspects of your show. For example, you could have a wall with IR enabled pixels on which you could "paint" or trigger effects.

[budude]

BTW, are you familiar with MagiQuest? It's sort of like GwtS ears, but in reverse. Participants with IR wands control the show or activate different things. It could be fun to allow people to control some aspects of your show. For example, you could have a wall with IR enabled pixels on which you could "paint" or trigger effects.

Perhaps some hooks into the Microsoft Kinect gizmo instead? I haven't followed that much but I know there are lots of hacks for it to map things for you...

[timon]

Sorry for the delay in replying, I've been out of town for work for most of the past week...

The recording idea sounds interesting but, perhaps this can save everyone some time and trouble. Attached is a capture from World of Color that I Jon sent me to play with. It's got a fair number of 55 codes in it as well.

I'm still getting back into the swing of things after being out of town for so long and hope to play with some of the code posted here, these codes from Jon and everything else that's been going on in this thread for the past week. Good stuff!

Happy hunting,

-joni-

I've been going through the files and it's hit or miss on the CRC's. A lot of they pass and a lot of them fail. So far none of the 55 codes have passed. Anyone else get something different?

[Jon Fether]

I've been going through the files and it's hit or miss on the CRC's. A lot of they pass and a lot of them fail. So far none of the 55 codes have passed. Anyone else get something different?

I found that the 55 codes use a very simple checksum - it's literally an addition of all of the bytes in the message, add one, then take the low byte of the additive result...

55 AA 19 04 01 02 0E 01 00 00 35 64

0x55+0xAA+0x19+0x04+0x01+0x02+0x0E+0x01+0x00+0x00+ 0x35 = 0x0163
0x0163 +1 = 0x0164
0x0164 % 0x100 = 0x64 = Checksum

I'm new to this form but have heard a lot about it. I understand that someone brilliant here managed to discover the Maxim 1-Wire checksum for the 9X codes.

I do own a glow-with-the-show recording device that generated the files I sent to Mr. Chu. It's an Arduino with a custom program that captures data over the native serial interface and does only a small amount of error rejection. (UART serial is prone to a lot of 0xFF's getting stuffed into the datastream due to a single bit being easily confused for a start bit.) The data is stored on a MicroSD card on my Arduino Ethernet Shield. I created text files with timestamp offsets from program start followed by hexadecimal data. Not very efficient but an 8GB card goes a long way.

The hardware has a IR receiver module like this one

Attachment 18165

I just stick it to the ears and run it to the Arduino in my pocket which is powered with 6 AA batteries in series. I've so far recorded WoC, Fantasmic!, Believe in Holiday Magic, and a few of the various codes some of the rides and areas emit (Cars Land, Disneyland Railroad, etc). I mainly recorded them for reverse engineering purposes but it is fun to play them back to the ears. There's a timecode embedded in the datastream as the 55 AA messages when a show is going, such as the above example. Not all 55 AA's are timecodes, but timecodes are written like this:

55 AA 19 04 01 02 0E 01 00 00 35 64 - 00h00m53s
55 AA 19 04 01 02 0E 01 00 02 05 36 - 00h02m05s
55 AA 19 04 01 02 0E 01 00 02 06 37 - 00h02m06s
55 AA 19 04 01 02 0E 01 00 02 07 38 - 00h02m07s

I don't know the significance of the rest of the message.

I wrote respective playback and brute-forcing software as well for Arduino. This allowed me to make local codes and test the effects. My playback program also displays the timecode messages over the attached serial port. The timecodes for Believe! match exactly to the official soundtrack releases. The timecode for Fantasmic! matches a patched version of the soundtrack I made with the Disneyland official soundtrack prepended with the show announcement from the WDW official soundtrack. Working backwards from the timecode you can find the correct file offset for the start of the show.

The output is emulated 38kHz 8-N-1 2400 baud data over a GPIO pin. I initially thought it matched IRDA SIR, but it does not to the best of my knowledge. I did some hardware hacking on a STIR4200 based USB IRDA dongle but it was a complete bust.

I will make an effort to post the code to my programs as soon as possible (The code is too sloppy for release at the moment). The IR emulation is loosely based on the work from LadyAda's code formerly at http://www.ladyada.net/learn/sensors/ir.html.

I also have done some protocol analysis by brute-forcing single byte commands as well as playing back portions of captured files. I'll post more on that soon as well.

Happy (late) Holidays
-Jon

[timon]

So as far as you can tell its only the 9x messages that control the color of the ears. Why would the ears need time code so I'm thinking that the 55AA may not even be used by the ears but by other devices around the park. I think the fact that the 55 codes use a different check sum tends to supports this.

[Jon Fether]

So as far as you can tell its only the 9x messages that control the color of the ears. Why would the ears need time code so I'm thinking that the 55AA may not even be used by the ears but by other devices around the park. I think the fact that the 55 codes use a different check sum tends to supports this.

55 AAs are also used by some of the codes that shut off the ears during rides (and prevent turning them on for a while unless you pull the battery). There are some such commands that they do respond to. So I know these ears know about them.

I was doing a little more research into colors:

The mouse ears use 2 different types of color signals (unless there's a third one I've not been able to detect). 1-bit and palette colors. 1-bit I mentioned in a previously crossposted item (61=Blue, 62=Green, 64=Red, 66=Yellow/Red+Green etc..). But there is another series of colors. These palette colors as I call them are predefined and activate the ears approximately with the following values:

Code	Red	Green	Blue	RGB
00	67.43%	99.76%	99.75%	ACFEFE
01	12.06%	56.39%	99.78%	1F90FE
02	12.24%	30.01%	99.57%	1F4DFE
03	12.23%	0%	99.78%	1F00FE
04	0%	0%	99.78%	0000FE
05	99.96%	79.59%	99.78%	FFCBFE
06	67.53%	30.06%	99.70%	AC4DFE
07	38.09%	14.89%	99.85%	6126FF
08	46.70%	0.46%	67.21%	7701AB
09	99.87%	67.34%	99.71%	FFACFE
0A	99.98%	17.26%	99.81%	FF2CFF
0B	99.68%	5.05%	99.91%	FE0DFF
0C	99.98%	0%	79.39%	FF00CA
0D	99.90%	0%	37.97%	FF0061
0E	99.89%	0%	6.78%	FF0011
0F	100%	79.74%	8.60%	FFCB16
10	99.90%	33.77%	3.93%	FF560A
11	99.86%	46.76%	0.43%	FF7701
12	99.84%	100%	0%	FFFF00
13	99.88%	26.56%	0%	FF4400
14	99.88%	6.75%	0%	FF1100
15	99.88%	0%	0%	FF0000
16	0%	99.74%	100%	00FEFF
17	0%	99.78%	42.10%	00FE6B
18	0%	99.78%	17.44%	00FE2C
19	0%	99.78%	0%	00FE00
1A	0.45%	99.84%	0%	01FF00
1B	86.02%	99.93%	79.37%	DBFFCA
1C	99.79%	99.67%	99.77%	FEFEFE
1D	0%	0%	0%	000000

These can be accessed by sending the ears "0E XX" where "XX" is the code from the above list. For instance:

91 0E 14 A3

Will turn the ears Orange (About 100% red, about 7% green).

The color approximations you get from the HTML color codes shown above are only relative to each other, the effect of the LED illuminators on each ear isn't the same as the response of a computer monitor. But I'm certain in this group of Christmas house-lighters everyone is probably already familiar with that. I based the color measurements based on the PWM duty cycle I observed with a logic analyzer on the LEDs so it's rather dodgy. You'll be much better off to simply preview each color on your own mouse ears, some of the differences are very subtle to the human eye.

Selecting the color for both ears is easy. You combine one of the codes that affect both ears to the same color with a second code immediately following that only affects the right ear. A single bit is set to indicate "Set right ear only":

To make any of those colors only affect the right ear only (to select two colors), add 0x80 to any of them. Do not add it to the 0x0E.:
91 0E 00 5F - Turn both ears white
91 0E 94 2F - Turn right ear orange
Leaves left ear white and right ear orange. You can also combine this to:
94 0E 00 0E 94 11 - Same effect

To make the 1-bit colors (0x60-0x67) only affect the right ear, add 0x08 to any of them.
91 61 6A 06 - Turn left ear Blue and right ear Green (0x62 + 0x08)

More notes to come.

[oPossum]

I found that the 55 codes use a very simple checksum - it's literally an addition of all of the bytes in the message, add one, then take the low byte of the additive result...

Exclude 55 AA from the checksum calculation and then it is an exact match - no need to add 1.