Glow with *OUR* Show and MSP430G2553 discussion

@ac2ev

Thanks for the encouraging words. It helps to be semi-retired and have a wife who's a rabid runDisney fan.

I'm going back through my notes, checking things once more and dumping the findings into a spreadsheet format to make it easier to wade through the effects. Hope to get that done and posted within the next couple days.
 
I collected my notes on the 0x48 ?? series of codes and arranged them in a spreadsheet format that may make them a bit easier to sort through. I'll try to attach that pdf to this post.

I hope these provide useful starting points for any who are still interested in digging a bit deeper into this protocol. With this additional data, I estimate that 24461 of the 70411 codes in the collection I'm working with, 34.7%, are now described.

The two next most prevalent codes are 0xD0 and 0x58. The 0xD? series consists of just 3 codes: 0xD0, 0xD1 and 0xD2. Based upon impressions gained while working through the 0x48 series data and the post by @jstorms, it's possible that the 0xD0 series takes arguments of two bytes, the 0xD1 takes 3 bytes and 0xD2 takes 4. Similarly, the 0x5? series may involve 0x58 with a one byte argument, 0x59 with two, 0x5A takes three and 0x5B consumes 4. Both families of codes seem to modify various members of the 0x48 ?? series, but it's not clear to me why one is chosen over the other and what all the arguments code for. I have a hunch that I'd have more luck if I knew a bit more about how the MSP430G2553 works.

If my hunch is correct about the 0x58 involving one argument and 0xD0 involving 2, describing what they do would bring the percentage of the described code to over 60%, a substantial increase.

Let me know what I got wrong and I'll make corrections. If you have contributions, I'll be delighted to add it to the document and post an update once the dust settles.
 

Attachments

  • 48 series overview.pdf
    29.9 KB · Views: 64
Oooops!

Going back through the older posts in this thread, I once again stumbled upon Jon Fether's s #121 post. Therein, he pretty much described most of what I've been looking into up until now.

My apologies for bringing up old news and stepping on that post. I must have been there in the past as that post contains the link to the mouseeartransmissiontest.ino script that I use on practically a daily basis. Just didn't remember seeing any of that before. Perhaps the best punishment for such a transgression is to have to slog through all that research, yet again. Which I now have. For good measure, I'll make sure to reread the entire thread again. I promise.

At the very least, maybe I did fill in some of the blanks he left for us to explore on our own.

In that same post, he mentions the code: 55 AA 08 C4 13 FF 01 ED AF FF 7A as a shutdown code. That seems to work on the ears but not the wand nor bow devices. I can verify that the ears can't be revived with a simple 90 24 command. They're down for the count.

He also described the second column F?, 20 codes, as well as the 58 ?? duration modifiers. Those contribute a substantial amount to the described subset code base. With those contributions, I estimate the percentage of the valid 9? phrases subset to be close to 48% described.

And I'm still working on how to do the accounting for the info contributed by @jstorms. All those codes are D1 ?? ?? ?? D0 ?? ?? constructs. While a D0 clause usually comes after a D1 clause, sometimes it comes before it, sometimes it's replaced with a D2 clause and sometimes there aren't any additional D? arguments within the same phrase. Kind of confusing.

About as confusing as the 8C ?? 83 ?? sequences that extend from the second column. Those commands seem to be used to direct commands to a subset of the listening devices. For any 8C ?? 83 ?? code, some devices will respond, others won't. A clear pattern has yet to come into focus. The number of show phrases using the 8C set is very small, only about 3.5% of the valid 0x9? phrases recorded. Unless one is interested in this aspect, it can probably be ignored without compromising the overall understanding.
 
I've been playing around with the fading and some other commands and here is what i've found it. Most, if not all of this information has already been discussed but I thought I'd consolidate my notes into one post.

9X commands are the main control commands.
90 – 1 BYTE + CHECKSUM
91 – 2 BYTES + CHECKSUM
92 – 3 BYTES + CHECKSUM
93– 4 BYTES + CHECKSUM
94 – 5 BYTES + CHECKSUM
95 – 6 BYTES + CHECKSUM
96 – 7 BYTES + CHECKSUM
97 – 8 BYTES + CHECKSUM
98 – 9 BYTES + CHECKSUM
99 – 10 BYTES + CHECKSUM
9A– 11 BYTES + CHECKSUM
9B – 12 BYTES + CHECKSUM
9C– 13 BYTES + CHECKSUM
9D – 14 BYTES + CHECKSUM
9E – 15 BYTES + CHECKSUM
9F – 16 BYTES + CHECKSUM

1 byte colors are 0x61-0x67 for both ears and 0x69-0x6F for left ear only. 0x60 is both ears off and 0x68 is left ear off only.
Examples (not including checksum):
90 60 - both ears off
90 61 - both ears blue
91 61 6C - right ear blue and left ear red

Palette colors are two byte commands using 0E XX where XX is the color. 0x00-0x1C is for both ears and 0x80-0x9C are for left ear only. 0x1D is both ears off and 0x9D is left ear off only.
Examples (not including checksum):
91 0E 00 - both ears white
93 0E 00 0E 84 - right ear white and left ear blue
93 0E 1D 0E 95 - right ear off and left ear red
93 0E 15 0E 9D - right ear red and left ear off

0x24 appears to be an off or override command depending on how its used. If the 0x24 command is used without any other display command it shuts the ears off. If the 0x24 command is included with any other command the ears will switch to that command. There are some built in functions that can be activated with 0x48 XX that once activated cannot be switched to another built in function unless 0x24 is included.
Examples (not including checksum):
90 24 - both ears off
91 48 08 - quick rotation through four colors
91 48 10 - quick flashing on one ear. If it doesn't active, try 92 24 48 10 and it will activate.

0x20 appears to be used to start something immediately.

0x25 appears to be used to stop motion of any running effects.

0xF1-0xFF appears to be a delay with F1 being more delayed and FF being almost instantly.
Example (not including checksum):
90 62 - both ears green
91 F1 63 - both ears light blue after a few seconds delay

0x58 is speed control. It requires a one byte argument from 0x00-0xFF. With 0x00 being instantly and 0xFF being very very slow.

0x48 0x85 - is fade down. This can only be used it an ear is on.
0x48 0x86 is fade up. This can be used any time. If an ear is on, it will fade up again.
Examples (not including checksum):
93 0E 07 48 86 - fade up both ears purple
95 0E 07 48 86 58 00 - fade up both ears purple instantly. Essentially instant on
95 0E 07 48 86 58 10- fade up both ears purple slower
95 0E 07 48 85 58 10- fade down both ears purple same speed as up

Basic RGB Fade up/down sequences (including checksum):
98 24 0E 1D 0E 95 48 86 58 10 28 – LEFT EAR FADE UP RED
98 24 0E 1D 0E 95 48 85 58 10 CC – LEFT EAR FADE DOWN RED
98 24 0E 1D 0E 99 48 86 58 10 09– LEFT EAR FADE UP GREEN
98 24 0E 1D 0E 99 48 85 58 10 ED – LEFT EAR FADE DOWN GREEN
98 24 0E 1D 0E 84 48 86 58 10 99– LEFT EAR FADE UP BLUE
98 24 0E 1D 0E 84 48 85 58 10 7D– LEFT EAR FADE DOWN BLUE
98 24 0E 15 0E 9D 48 86 58 10 E7 – RIGHT EAR FADE UP RED
98 24 0E 15 0E 9D 48 85 58 10 03– RIGHT EAR FADE DOWN RED
98 24 0E 19 0E 9D 48 86 58 10 E2– RIGHT EAR FADE UP GREEN
98 24 0E 19 0E 9D 48 85 58 10 06– RIGHT EAR FADE DOWN GREEN
98 24 0E 04 0E 9D 48 86 58 10 21– RIGHT EAR FADE UP BLUE
98 24 0E 04 0E 9D 48 85 58 10 C5– RIGHT EAR FADE DOWN BLUE
 
Nice summary, @djred2000.

But you might want to recheck your data on the 0xF? delays. The 0xF?/0x58 commands were first described by Jon Fether in post #121. He noted that the lower nibble of the 0xF? causes a ? * 100 msec delay before the subsequent codes are implemented, providing for variable delays of 100-1500 msec. That's what I'm seeing, too. The same seems to be true for most of the second byte arguments of the 0x58 series. Using a phone stopwatch (only good for an approximation), I get that it takes approximately 4.9 sec for 48 85 58 32 to fade out: 4.9sec/50counts = 98 msec - roughly the same as for the 0xF? series. This relationship holds through 0x64. Beyond that, there are two additional 0x58 arguments, 0xEE and 0xF0 which appear to have other functions. 58 F0 is used exclusively by 48 03 and 48 04. It gives a slow, even pulsing effect. 0xF0 is used sparingly in the subset I'm looking at. It's only found in the following combinations: D0 33 F0, D0 32 F0, D0 34 F0, D2 35 04 F0 10, 5B AC F0 E6 33, 5B AB F0 E6 33, 5B AA F0 F2 33, 5B A9 F0 E6 33, and 5B AA F0 E6 33 and doesn't seem to be used like the 0xF1-0xFF codes. There's something unique about the 0xF0 code.

The 0xF? and 0x58 commands have slightly different functions. The 0xF? allows a timed continuation of the previous effect before moving on whereas the 0x58 command appears to time a cycle of a 0x48 effect. I've only found 0x58 commands in phrases also containing 0x48 commands, but they don't seem to work with all of the 0x48 effects. Primary targets are 48 84, 48 85, 48 86 and 48 03, 48 04. Sometimes it's difficult to determine the actual target as multiple 0x48 commands often occur in the same phrase. The attached file illustrates some of the co-occurrences observed. Note that these are simply co-occurrences and NOT established relationships.

48 0F may utilize 0x59 ?? ?? commands for timing. For the 59 ?? ?? series, they seem to time in 200 msec intervals, instead of the 100 msec intervals of the 58 and F? commands. The first argument alters the effect, itself and the second argument is the timing increment.

The 0x5A commands seem to take a three byte argument and are only found in conjunction with 48 8B. Only three variants detected: 5A 01 08 55, 5A 02 08 55 and 5A 05 08 55. When the third argument is 55, the first argument acts as a multiplier of 400 msec and the second argument as a divisor. Combined, they make it possible to define a fractional time of the default 400 msec. Example: 5A 01 08 55 -> 400 msec/8 = 50 msec/cycle, 5A 05 08 55 -> 5*400msec/8 = 250 msec, 5A 0A 02 55 -> 10*400msec/2 = 2 sec. The last one is observable using a stopwatch. Changing the third argument seems to interfere with the ability to modify the timing. As the value decreases towards 0x40h, there is a noticible pause with the rt ear off and lft ear on. Below 0x40, the left ear stays on and the right ear off. As the value increases towards 0xBF, the opposite happens, the pause favors the rt ear on and the left ear off. Above 0xBF, the right ear stays on and the left off.

In post 373, @jstorms nicely demonstrates that a 0x48 code isn't necessary for some effects. The timer in the sequences described is attributed to 0xD1 42 .... Checking out 99 26 62 6A D1 42 14 20 D0 32 F0 43, I estimate it is timing increments at 200 msec @. There's also a 0xD0 42 ?? series that is used by some of the 48 codes. Example: 9B 24 0E 0E 0E 8E 58 F0 48 04 D0 42 14 89 also takes approximately 4 sec/cycle -> 200 msec per increment of D0 42 ??. Both match the observed increments for the 0x59 ?? ?? codes. In the last example just given, the 48 04 code requires both the 58 F0 argument for the effect and the D0 42 14 actually appears to modify the duration of the 58 F0 effect/timer. When 0xD0 42 ?? modifies 48 82 or 48 83, 58 F0 isn't present. My impression is that most 48 series codes respond to either the 0x5? codes or the 0xD? codes. 48 04 may be the exception. It often uses 58 F0 and then 0xD0 42 ?? to modify the cycle rate.

Outside of the 0x9? .... checksum phrases, Jon Fether noted there is timing info contained in the 0x55 AA ... codes. See post 107 for more info.

It's probable there remain even more 'timers' to be detected and described. This is as far as I've gotten. It's become slow going. The complexity increases when there are multiple 48 codes, 58 codes and D0 codes in the same phrases. The attachment illustrates that nicely.

One thing strikes me about the data discovered so far - the timings seem to be more or less fixed. Hexadecimal seems well suited for representing music 16ths - the 0xF? series could be an example. A 100msec delay would be perfect for a 1/16th note at 150 bpm and 4/4 time, but might not work that well for other tempos. I've spent a bit of time looking for something that alters the delay value to suit other tempos but, outside of the 0x5A examples, I haven't had much luck yet. And the 0x5A codes are rarely used and are associated with a single 48 code. If anyone has found such a thing, I'd sure like to know!
 
Last edited:
Of the top 4 most abundant single byte show codes in the subset I've been studying, 3 have already been covered: 48, 24, 58. The remaining code is 0xD0. @jstorms brought up D0 3(2|3) F0 (post #373). I talked about D0 42 ?? in my last post (#385). I think that was all that needs saying about the D0 42 ?? series. Other than that, I don't think this series has received much discussion.

By itself, 0xD0 comprises 6% of the subset codes. It appears to take 2 bytes as arguments. That suggests the the 0xD0 series, alone, accounts for 18% of the subset codes. That's on par with the 17% of the 0x48 series. A lot of useful information should come out of working through this series!

It's easy to get misled when investigating these codes. I've been down a lot of dead ends. Consequently, I like to include the data that goes into my most recent guesses so others can take a look and see if they agree with the findings. As a result, the write ups tend to be long winded and probably only interests a handful of folks. So I'll write up my notes and submit as attachments to keep from taking up much forum space. For those of you still interested in this topic, I hope you find this new material interesting and helpful with whatever you're trying to do!

The attachment includes a summary of the 0xD0 series and then focuses on: the 0xD0 0x0E ?? series, the 0x7? series and the 0x29 series
 

Attachments

  • report4_D07X29.pdf
    30.7 KB · Views: 48
Codes discussed:

0x0D, 0x26, 0x0C, 0xD0 0x05 ??, and some info about the headband and wand devices.

This material will be of interest to folks who want to produce asynchronous device responses and/or want to gain control over the transition to demo mode.
 

Attachments

  • report5_D005_26_0D_0C_headband.pdf
    22.2 KB · Views: 47
I've been following this thread off and on ever since it was created. It is amazing how far everyone has come in understanding the protocol that's part of these products.

I remember at the very beginning everyone thought it was a simple protocol. My gosh, in hindsight that was just so wrong...

I think it will be so kewl to include some of the new products, especially the wand into Christmas displays. Imagine a G-force accelerometer that could detect the "flick" of the wand, change the wand color and have it change a tree or other set of display elements.

Again, congrats to all that are working this through!
 
Hi everyone. I've been an unregistered lurker for some time now. I wanted to say thank you to everyone that has posted codes and tests etc because this forum has really helped me out with my own projects.

I'm not really a diy Christmas guy on a large scale since I live in an apartment, but I do have an interest in the ears.

I did want to add one thing that might help some folks reduce a bit of coding for the basic 0x60 color codes, and likely others for which I haven't tested the application.

First let me lay down some binary, miss-formatted with intent:
0x60 = 0110:0:000
0x61 = 0110:0:001
0x62 = 0110:0:010
0x63 = 0110:0:011
0x64 = 0110:0:100
0x65 = 0110:0:101
0x66 = 0110:0:110
0x67 = 0110:0:111
0x68 = 0110:1:000
0x69 = 0110:1:001
0x6A = 0110:1:010
0x6B = 0110:1:011
0x6C = 0110:1:100
0x6D = 0110:1:101
0x6E = 0110:1:110
0x6F = 0110:1:111

BIN = Command:Ear:RGB

Here's a code snippet people can use:
rval=0;
gval=0;
bval=0;
if ((codeValue&0b00000100)==0b00000100){rval=255;}
if ((codeValue&0b00000010)==0b00000010){gval=255;}
if ((codeValue&0b00000001)==0b00000001){bval=255;}

This code is designed to convert a received code into a color, but you could reverse it by taking a function with an RGB value, and then setting the appropriate bits in your output code value by using an "or" (|) operator instead of an "and" (&) operator.

Unfortunately I'm down for a bit on the dev side since my ears won't take codes anymore which I know are good codes. Its highly probable that I broke them since I have a tendency to break stuff. I know the vishay part is good because I put it on another device and I'm able to receive on it. I've also brute forced every possible 2 byte code into it bypassing the infrared but can't get it to respond so i might have blown the input line on the micro controller. I guess we will see when I get my hands on another set of ears.

Anyway for now I hope this helps someone. And thank you again.
 
evilsoapbox said:
Hello everyone,

I use an Arduino to interact with my ears. In the event anyone is going to do the same, or use a C-based microcontroller, I have thrown all of the colors of which I know into a header file for easy use:

https://github.com/evilsoapbox/EvilArduinoBox/tree/master/GlowShow
Click to expand...

For all. Does anyone understand the formatting on this? I'm not seeing the connection between the int arrays and the Hex code that everything else is done in. I'd like to implement the 48 codes and so far this is the only version of the encoding that I've to work on an Adafruit Flora platform (using IRlib rather then IRRemote)

Code: 
	static unsigned int BOTH_BLUE[12] = {2085,417,834,834,417,417,1668,834,417,417,1668,2502};
	static unsigned int BOTH_INACTIVE[14] = {2085,417,834,834,2502,834,417,417,834,834,834,417,417,834};
	static unsigned int BOTH_GREEN[16] = {2085,417,834,834,834,417,1251,834,417,417,834,417,417,834,1251,417};
	static unsigned int BOTH_YELLOW[16] = {2085,417,834,834,834,834,834,834,417,417,417,834,417,1668,417,417};
	static unsigned int BOTH_CYAN[16] = {2085,417,834,834,417,834,1251,834,417,417,1251,417,1251,417,417,417};
	static unsigned int BOTH_MAGENTA[18] = {2085,417,834,834,417,417,417,417,834,834,417,417,417,417,834,834,834,834};
	static unsigned int BOTH_WHITE[18] = {2085,417,834,834,417,1251,834,834,417,417,417,417,417,417,834,417,834,417};
	static unsigned int BOTH_RED[14] = {2085,417,834,834,1251,417,834,834,417,417,417,1251,1251,1251};
 
Last edited:
Code: 
Both Blue           2085,417,834,834,417,417,1668,834,417,417,1668,2502

Divide by 417       5,1,2,2,1,1,4,2,1,1,4,6


alternate 0s and 1s
                    5,      1,  2,  2,  1,  1,  4,      2,  1,  1,  4,  6
                    00000   1   00  11  0   1   0000    11  0   1   0000    111111

            =       000001001101000011010000111111

            =       0000010011
                    0100001101
                    0000111111


reverse it          1100100000
                    1011000010
                    1111110000

formatting          1 1001 0000 0
                    1 0110 0001 0
                    1 1111 1000 0

delete start/stop bits
                    1001 0000 = 0x90
                    0110 0001 = 0x61
                    1111 1000 = 0xF8

ac2ev, here ya go.
 
davee said:
Code: 
Both Blue           2085,417,834,834,417,417,1668,834,417,417,1668,2502

Divide by 417       5,1,2,2,1,1,4,2,1,1,4,6


alternate 0s and 1s
                    5,      1,  2,  2,  1,  1,  4,      2,  1,  1,  4,  6
                    00000   1   00  11  0   1   0000    11  0   1   0000    111111

            =       000001001101000011010000111111

            =       0000010011
                    0100001101
                    0000111111


reverse it          1100100000
                    1011000010
                    1111110000

formatting          1 1001 0000 0
                    1 0110 0001 0
                    1 1111 1000 0

delete start/stop bits
                    1001 0000 = 0x90
                    0110 0001 = 0x61
                    1111 1000 = 0xF8

ac2ev, here ya go.
Click to expand...

Awesome. Thank you. But now I want to know why it's like that?
 
Makes perfect sense now. I've Never gotten this deep into serial protocol. Now to create a routine to test things out.
 
I was at the park the other day waiting for WoC and right before the Pier Games my Made With Magic Paintbrush played a "chiptune"ish version of the WoC song. I think it was sent to the wand over the infrared show signals. I'm going to try to capture it next time.
 
On a recent quick trip through Disneyland, I happened to see the new 60th Anniversary Ear hats and the Paintbrush. Both seem to be more popular than previous versions. Saw lots of happy users, of all ages, mischievously using their paintbrush devices to change other park-goers MWM devices. Hadn't seen that before with the wand devices.

The hats clearly have been redesigned. Quick inspection revealed that there are now two separate battery compartments, one directly underneath each 'ear'. Access is still from the inside of the hat. Each compartment holds a single AAA battery. The on/off switch is now on the exterior of the hat on the lower part of the right ear. You no longer need to remove the hat to turn it on or off. Near as I can tell, the redesign doesn't make it fit adult heads much better - at least it didn't feel better to me.

Also ran across an item I'd begun to think would never actually reach the shelves - the glove:

MadeWithMagicGlove_sm.jpg I didn't see one in use while I was there, but it was there and for sale. Looks like it, too, contains two LEDs. If I'm remembering correctly, both are in the palm area and sort of close together. It wasn't all that impressive. Maybe I'd change my mind if I had a chance to really examine one and see what it can do.

Another item is one I hadn't heard about - the MWM Fantasmic cup. I only saw this promoted at the walk-up counter behind the French Market quick serve. All I know about it is:

MadeWithMagicFantasmicCup_sm.jpg

If I get around to tearing the hat apart (likely since it's not comfortable to wear), I'll try to take some pictures and post what I find

I came away from the 60th gala with two impressions, 1) that the areas covered by infrared signal have been expanded, as I detected signal during the fireworks much further down main street than I remembered being possible before and, 2) that the IR codes are either being generated by the Electric Light parade floats, themselves, or they trigger local emitters as they approach because I was getting code reception between Fantasy Land and Small World when the floats came through and not much at all before or after. Didn't think I'd pick up anything at that location and almost didn't bother to turn on the recorder.

Anyone else notice either of these?
 
You must log in or register to reply here.
Back
Top