I love this project. Keep up the good work, it's great inspiration.

Are you planning on using the Raspberry Pi to do the audio? I've been looking at OPP with the new STM32 and have been wondering what the best way to do audio with it would be...

edit: I read some more and of course the raspberry pi does audio! Silly me

On the Raspberry Pi and audio, I found that the base Raspberry Pi analog audio output was atrocious. That was back on one of the original Raspberry Pi's (Model A). Because of that, I ended up purchasing a cheap USB to audio adapter (maybe $1 or $2). With the original analog output, I could hear how hard the Pi was working with the high pitched squeal that it emitted over the speakers. With the USB audio adapter, there was no aliasing of the processor frequency through the speakers. I think I also needed to use an isolation filter going to the amplifier. That was another $1 or $2. (I'm not 100% certain but for 1 project I needed that, and for 1 project I didn't need the isolation filter. I think when I was running the Pi/hub off a battery pack, it was OK, but as soon as I tied the Pi, USB hub, etc into the same power supply, I heard a new noise. That caused me to need a the isolation filter to the amplifier). Hope that helps.

Great project - thanks. I came across it when pondering a OPP retheme and a thread like this is great as inspiration and part howto.

@cobra18t, you made the same kind of board I was just considering making! I thought, "How about I design a board that acts as a bunch of wings and is easier to physically mount than multiple boards hanging off of one another." I just discovered @openpinballproj's OPP and am itching to build my own machine. I've used STM32 micros a lot, and I was also thinking about putting one or more STM32 MCUs directly on the PCB instead of soldering the "blue pill" boards onto the larger board. Sadly I have more ideas than money at this point, so so far all I can do is dream and design.

That said, I'd be happy to help whip up boards in KiCad as time permits!

@cobra18t, good call on being able to swap in a new MCU board instead of desoldering and replacing a surface mount chip. And the price is right on the blue pill boards.

What FETs are you using for the solenoids? Any gate drivers?

Also do you have a link handy for those LEDs you're mounting to the playfield using the laser-cut holders? Those look convenient!

I never saw that type of LED's before. That makes much more sense than me cutting up strip LED's and soldering wires in between. (That's a major pain). I'd be interested in knowing how you are mounting them. Anything special?

By the bye, I have the Neopixel code working on STM32 so that should be coming out pretty soon for OPP. I've been oscillating between using the SPI or using the PWM to drive the Neopixels, and I think that I have finally settled on the SPI because it saves 1/2 of the RAM. I could have saved a little time running the PWM, but it really wasn't worth it in the end to get the refresh rate higher. (One thing to remember is that it is going to need a 3.3V to 5V converter to get the Neopixels as bright as possible.)

3.3V to 5V converter? Do you not have 5V power available already?

NeoPixels are the usual WS2812B addressable RGB LEDs, right?

Oh, for the data line? I just checked, and VIH is around 3.5V depending on the specific part. I guess I've gotten lucky driving mine at 3.3V logic levels.

It is much easier using the pre-wired LED string. I bought some individual WS2812 leds and wired them together for part of my project and it was tedious. Cobra18t made some nice little laser cut brackets to hold the leds in place. I did a similar thing on mine but made custom brackets for holding multiple LEDs in a line for each area of the playfield. I need to start a thread about my Joust build.

Just remember, when I have Neopixels supported on the OPP side, there is still a good amount of work that needs to be done to integrate it with MPF. Hopefully somebody (not mentioning his name in case he doesn't want to do the work) is willing to do that side because he is much better at it than I am. The commands to change the LEDs were based on his suggestions and how to make an efficient update to a string of LEDs from the MPF perspective. (It's all about the fade baby!)

Here are the laser cut holders I made for the Joust egg bonus light array. It was easier to get the pre-wired string and zip tie the excess wire than to solder individual lights together.

393B5508-791C-4C57-9E7E-C4EC5BC0E240 (resized).jpeg

77A043AE-4B52-47A7-9A54-9FF1299FE970 (resized).jpeg

FA970D43-E367-4FBC-A4D2-6C0DC5AB7962 (resized).jpeg

cobra18t I took finally some time to play your video on rules. damn, it brings this pinball to such another level !! Great job

RE: Logic Level Shifting and neopixels

I've had good luck using this little modulein the past, but am unsure whether it will work for something quite as time sensitive as driving neopixels...

Looking at the schematic, it looks like the magic is just an npn mosfet switch whose gate is driven by the 3.3v logic. It should be okay to incorporate one into a neopixel "wing".

For timing, I see mixed responses on sparkfun's comments. Some say it works with adressable LED's, some not, some say SPI is no-go... looking at the fet's datasheet, max turn-on delay + max rise-time = 23ns, okay...

according to adafruit's guide here, the data line frequency is fixed at 800kHz.. Math time...

I think it would be handy if you stopped using the brand name neopixel on your project openpinballproj as it seems to imply that ONLY adafruit's neopixels are supported, and kinda goes counter to the "open" part of your name in my mind. Now if that is the case (I hope not/don't know why it would be) then I retract my suggestion. Avoids questions like this.

From adafruit site:

“NeoPixel” is Adafruit’s brand for individually-addressable RGB color pixels and strips based on the WS2812, WS2811 and SK6812 LED/drivers, using a single-wire control protocol.

cobra18t cool project, I'm enjoying following along. Hope to get back on my project sometime, and really liking the new developments.

eh, I'm at the coffeeshop with awful wifi so I'm having trouble citing my sources, but I don't see any reason why using such a logic level shifter *shouldn't* work (or why it didn't work for other users...). I'll dig around tonight and see if I can find the parts to put together an experiment. I've been meaning to tinker more with my blue pills anyhow.

@borgdog I think calling them neopixels is no big deal. Adafruit's designs are mostly open-source anyway and if/when they rebrand something, they usually have great documentation and libraries to back it up. I'm happy to pay Adafruit for my first thing or two, use their documentation to learn how to use it, then go for the cheaper route once I have a little experience with it. I consider it a well-earned finder's fee. As a bonus, it's harder to accidentally order a ws2811 or a ws2801 by accident!

It's also just a manner of speaking. I'm sure you've used a Kleenex, or a Band-Aide, or a Crescent Wrench before...

I've been trying to avoid using the term Neoppixels too. For me it's a bit confusing, as I read Adafruit site when they say "Neopixel LED" they mean serially controlled with RGB+W in the package and "Neopixel" is just RGB with no W. Further I think WS2811 are grb and WS2812 are rgb so it all gets crazy.

I think MPF handles rgb and grb, not sure about rgbw.

Sorry for any confusion, but when I say Neopixels, I'm actually just talking about addressable LEDs. I have never bought a Neopixel myself, but most of the stuff that I search on the web is found throwing that in the search. I'm currently using WS2812B strips for my testing. While those are RGB, it doesn't actually matter to the firmware if it is RGB or RGBW, etc. The thought is that MPF will be configured with the color order, number of bytes per pixel, and suddenly the OPP firmware doesn't need to care about that stuff and it makes projects much more configurable.

I would characterize that as not supporting RGBW LEDs. My understanding of RGBW LEDs is that instead of 3 bytes of data, there is a 4th byte of data necessary for the white channel, and the white has its own separate LED. The SK6812RGBW seems to show the same timing as WS2812, so the SPI timing should work for either. My theory was that the configuration have the LED wing configured as 3 bytes or 4 bytes per pixel, and the number of pixels in the chain. That gives the firmware the number bytes needed to transmit the whole chain.

When updating the LEDs, a single fade command is supported. The fade command is as follows: board id (byte, normally 0x20 for STM32s), command (byte, 0x40), offset (2 bytes), num bytes to update (2 bytes), time of fade (number of ms, 2 bytes), data, crc8.

By setting the time of fade to 0 ms (0x0000), the changes will take affect immediately.

Assuming an rgb LED chain (3 bytes per pixel), updating the 3rd pixel to be black (all channels off) immediately would look like:
0x20 0x40 0x00 0x06 0x00 0x03 0x00 0x00 0x00 0x00 0x00 crc8

Assuming an rgb LED chain (3 bytes per pixel), updating the 4th pixel to all on immediately would look like:
0x20 0x40 0x00 0x09 0x00 0x03 0x00 0x00 0xff 0xff 0xff crc8

Assuming an rgb LED chain (3 bytes per pixel), updating the 5th pixel, green only channel to full on in 1 second would look like:
0x20 0x40 0x00 0x0d 0x00 0x01 0x03 0xe8 0xff crc8

Assuming an rgbw LED chain (4 bytes per pixel), updating 3rd pixel to black (all channels off) immediately would look like:
0x20 0x40 0x00 0x08 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 crc8

That's where the OPP firmware is going next. The goal is that this single command makes it very easy for MPF to update LEDs efficiently.

Good information. I was worried that MPF wouldn't understand the difference between 3 byte (RGB) and 4 byte (RGBW) strands. Maybe they just can't handle 32 bit values for RGBW leds? In the tutorial step 17, it mentions "6-digit hex color codes". http://docs.missionpinball.org/en/latest/tutorial/17_add_lights_leds.html

would be great to test. I think I'll get one too ^^

MPF will happily send 3, 4 or 10 bytes per LED. It only depends on how many channels you define for a light. A light channel is just a brightness. It then depends on the platform how those are applied to the hardware (i.e. serially for WS281X). Internally, a light still uses RGB for colors though (because that is how most applications work with color). However, we can calculate a white channel based on RGB. I implemented the simplest possible algorithm for that. There are better ones but nobody implemented them yet.

Love that. That's nearly what I plan for the next one where I only have the playfield.
Was wondering on the best way to handle the window... Will wait for your feedback on the gravity option, especially on the denoising effect of the window without rails.

Rgbw leds are not listed like that in mpf docs.
It's coded by three channels, then the white takes the next ones and creates a shift..
Can be a mess quite quickly, or did I miss something?
http://docs.missionpinball.org/en/latest/mechs/lights/leds.html#hardware

Thanks for these two replies.
Will see how OPP and MPF will take that in charge...
About the noise, I'll follow that issue

I'm limiting the OPP firmware to about 256 LEDs. That is either RGB or RGBW. The STM32 is memory limited which is why I'm doing that calculation. So the firmware needs to hold all of the bytes of data that it is currently displaying. So with RGBW that would be 256 * 4 bytes = 1KB. To keep the OPP firmware realtime, it uses the SPI DMA to actually feed the data to
NeopixelWS2812 data. Each WS2812 bit takes 4 SPI bits, so that means that takes 4KB of memory for the DMA data. To support fading, it requires one more copy of the data (as the final data value), so that takes another 1KB. So all said and done it is approximately 6KB for the pixel data. The processor has 20KB of SRAM, so it isn't that close, and maybe I could actually support a second SPI channel. I don't know that supporting more than 256 LEDs makes sense in a pinball machine.

256 seems already a large number !

256 serially controlled leds would seem adequate

Does the use of MOSI2 as the serial led pin mean that you can not then use a switch matrix on that wing? As i read the MPF OPP switch doco you use wing positions 2 and 3 for a switch matrix, but maybe that is just an example and is not a fixed location?

256 seems like enough.. until you put in 300ish, which I have, but I'm probably an edge case/crazy, currently running them all off a fadecandy, still have a few more to add as i haven't done the backbox lights in there yet. of course I also haven't touched the machine in a couple years so probably a moot point.

Or is this 256 per STM32? openpinballproj

anyway, nice to see OPP continue to progress, and great work on the tag team.

It would be 256 per STM32. If more than 256 are needed, another STM32 card would be needed.

Thanks cobra18t, I should have looked more carefully. I was mixing up the STM32 with the layout of the old processor