Recreating Stranger Things

[JonnyMac]

At Transworld 2017 we had a neat little technology demo: a poster-sized "Stranger Things" wall that could be controlled from an Android app running on a phone or tablet. A lot of people have expressed interest in duplicating our display, or using the tech to create other props.

Here's what we had in our booth.



We use an HC-8+ (Rev F) PCB with an HC-06 Bluetooth module for communicating with the phone app. The Christmas lights are smart bulbs from a company called HolidayCoro. These bulbs run from 12V and are controlled by a special messaging protocol (WS28xx). This protocol is quite complex, but easily handled by a Propeller-based controller like the HC-8+ and my driver code (which is used my many lighting professionals).

Our demo accepted words from a phone app via Bluetooth. We're Android users and there is an easy-to-use tool called MIT Android Inventor II that we used on the project. We're happy to share that with anyone who wants to use it as a framework.

You do not have to use the radio and phone app. There is a program constant called CMD_MODE that allows us to switch between radio and the programming port. This is what I used when developing the program: I would download and update, open a terminal window, and type in commands to test.

I've attached the connection diagram for the HC-8+, the lights, and the [optional] radio. I will post a radio set-up document separately. The HC-06 radio is cheap and easy to come by, but a little fussy to setup. I ended up writing a program just for configuring the radio which eliminates most of the headaches. Again, we'll deal with radio setup in a separate post since many have told me they want to run a direct connection.

Parts used:
-- EFX-TEK HC-8+ Controller (http://www.efx-tek.com/topics/hc-8.html)
-- HC-06 Bluetooth radio [optional] (https://www.amazon.com/KEDSUM-Arduino-Bluetooth-Wireless-Transceiver/dp/B0093XAV4U)
-- F-F Connector wires [as required] (https://www.pololu.com/product/1700)
-- Smart RGB Christmas lights (http://www.holidaycoro.com/Brilliant-Bulb-p/709.htm)

For our small display, we used lights with 4" spacing. If you're going to do a full-size display (as our friend Matt did last Halloween), the 12" spacing may be best.

In the program there is a constant called STRIP_LEN that we have set to 38; this is the number of bulbs on the display. You will probably have to change this for your display, as well as the map called Alphas which tells us which channel represents each letter. The program as it stands does not use numbers, but that could be added in.

If you need a specific change to the code, please post that request here. I will create a new version with your changes. Hopefully, there won't be too many changes required to fill a lot of prop needs.

EDIT: I've modified the program (dated 2017-07-26) so that it should run on any HC-8+; you simply need to modify the PCB_REV constant at the top of the program. While working with this, I added some debugging output when the program is used in terminal mode. This lead to the discovery of a bug in my text object (wasn't handling backspace correctly); that is now fixed.

[Jeff Haas]

Seeing this updated version reminds me - I forgot to tell you how cool this is!

I've been away from coding in Spin for awhile, and my HC-8 is Rev. C.  What modifications need to be made, other than removing support for the XPort?

[JonnyMac]

Jeff,

Jump back into Spin -- it's fun.

The key difference in the Rev F is the 5V outputs; we upgraded from a standard buffer chip to the TC4427 (4 of them with 2 circuits each). This chip has become one of our favorites; you'll see it on the AP-8+ coming soon. We like the TC4427 as a level translator (3.3 to 5v) because it has very stiff outputs; the device uses totem-pole MOSFETs that can switch the desired Vdd or ground and do so with a fair bit of current (up to 1.5A, though the HC-8+ won't like that if you try it). Importantly, the TC4427 can switch very fast; between the switching speed and the stiff outputs, we can send the complex WS28xx signal down the line to the HolidayCoro bulbs (or any other WS28xx or SK68xx string).

You could do a test of the Rev C output with any WS28xx device -- though you may need to change the start() method call to match the protocol used. I would also suggest keeping the first pixel very close to the HC-8+. I have a friend in the special FX world who uses a single pixel as his 3.3v to 5v translator for the WS28xx signal. His Propeller board doesn't have any 5V outputs so this is his strategy. It does the trick and his work (using my driver code) has been featured in a bunch of TV commercials and movies.

Rick's handiwork is on display in this popular Super Bowl commercial: https://youtu.be/kwDUqFBeOrI

If the 5V output on the Rev C doesn't work with WS28xx devices, you can try one of the 3.3V pins on the option port. You will need to move the related option switch to OFF (ON connects the pin to ground which would be bad for the pin). The first lamp would need to be pretty close to the board. The nice thing about the WS28xx/SK68xx pixels is that the input signal is reconditioned before getting to the output, so the first pixel can act as a level translator.

[Jeff Haas]

Hmm...having a bit of trouble.

The Rev. C board works beautifully with a string of WS2812 pixels, using your hc-8+_neopixel_demo.spin.  To power 32 pixels I give them their own 5V power supply (with the usual shared ground).  I changed  NEOS  =  OUT7  to match the Stranger Things code.  Hit F10, get the rainbow.

Going to the Stranger Things code, I left the LEDs connected, removed the sections for the XPort (both in CON {io pins} and the two objects), and changed CMD_MODE = M_USB.  No response from the LEDs.  I've edited Setup to try start_2811, start_2812, and start_2812b, no results.

Flipping back to the neopixel_demo and hitting F10 gets immediate results.  Seems like some part of jm_rgbx_pixel isn't communicating with this type of LEDs the same way.

To test the option header alone, I grabbed a strip of 8 pixels and connected them via servo cable to OUT7.  Same results - neopixel_demo works fine, Stranger Things doesn't.

I hope I didn't miss something obvious doing this before bed!

[JonnyMac]

There are several changes to the new driver to accommodate variable buffer size, multiple buffers, and multiple pins using the same driver.  That said, I've used the new driver with every pixel type. The HolidayCoro lights are WS2811s.

I've attached an updated pixel demo program that demonstrates how to use the new driver (it just uses one pin). Change the LEDS pin number for your HC-8+ and give it a try.

[JonnyMac]

I think I figured it out, Jeff. Before Rev F, you had to pull a line called OUT_EN low to activate the 5V outputs -- that is missing from the Rev F program. Add this line of code to the setup() method after io.start():

  if (PCB_REV =< "E")                                 
    io.low(OUT_EN)                                              ' enable output driver

You probably have this definition in an HC-8+ program that is working with your pixels (in the IO definitions section).

  OUT_EN  = 27  { O }

[JonnyMac]

I have updated the program to make it universal for any HC-8+. Code is attached to my original post.

[Jeff Haas]

And it's working!

I found something odd...the R/G LED seems to have its commands different for my board.  It shows red once the string is colored in.

In colorize_string and random_refill, setting GRN makes it show red, setting RED makes it show green.  YEL makes it show red.  Possibly another variation for the earlier boards.

And, to be super-nitpicky, the terminal display could use an additional line after "Ready" like this:

Code Select Expand

pub show_ready

  if (CMD_MODE == M_USB)         
    term.str(string(13, "Ready"))
    term.str(string(13, "> "))   


[JonnyMac]

You're right: we're using a new R/G LED now and the colors are reversed. Unfortunately, there is no conditional compilation for pin #s; you'll have to fix that manually. The RG LED gets used in the background process; adding conditional code there would slow it down. I am hoping that a future Spin compiler will support conditional compilation of pins, and the conditional inclusion of libraries.

I don't add the caret (">") like you suggest because PST doesn't accept text in the body. This is why I use the "<-- " to indicate input to the program, and "--> " to indicate output to the lamp spelling code.

I'm glad it's working and I hope you'll have fun with it.

[Jeff Haas]

Not a problem, that's an easy fix.  Thanks for the info!