When populating the surface mount portion of the board, I remove the footprints of all the through hole parts in the stencil. Otherwise the holes can get filled up with solder which makes it more difficult to solder the through hole parts. (Through hole parts seem to always extend below the bottom of the board, so the parts can't be placed and continue to have good contact with the surface of the hot plate.)

When soldering large parts with a big pad beneath them, the squeegee method can put too much paste for that pad. I have reduced the size of the hole in the stencil to reduce the amount of paste under the part. (It does seem like the stencil layer has broken those large areas into four smaller areas. The footprints I was working with didn't do that, which may be why I needed to modify my stencil layer).

Looks great. Only added the necessary connectors is not lazy, that is cost conscious. I don't believe that you mentioned the price that you paid for the 5 boards plus shipping. Mostly I like to know, to make sure there aren't cheaper alternatives to what I currently use for fabbing the PCBs I do. (ITeadstudio does 10 boards of 10 cm x 10 cm for $20, but, here is the kicker, they will allow you to score between multiple copies of the same board on the 10 cm x 10 cm panel.)

Your video makes me laugh. That rocks! I can't 100% remember your board layout, but you can always bring the current to the NTC on both the top and the bottom of the board. You may also want to consider not using thermal relief pads for the NTC through holes. It makes soldering the NTC more difficult, but it does reduce the resistance going to that guy. Might also spring for 2 oz copper if you haven't already. Regardless, it looks like your board is working fantastically well. Congratulations.

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.

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.)

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!)

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

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.

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

Fantastic work on this. It really shows how someone who is talented can take an older pinball game and really breath a lot of life into the game. Every time that I play a game, and think it shoots great, but it is so shallow compared to newer games...here is an example of the possibilities for that older game.

In SS3, I have a bar fight mode where each pop bumper needs to be hit multiple times. Maybe a cage match mode? As the pops are hit, the LED blinks faster and faster until the pop bumper gets knocked out. At that point, I kill the pop bumper. It is insanely difficult to get that last pop bumper to complete the mode because the pops are meant to play off each other, and disabling one of them changes the interplay between them. (I just want somebody else to use the idea because I feel it is clever, and I never complete the mode because I suck at pinball).

Congratulations again on how this is coming together. Soon you'll fall into the trap of throwing a display into the backbox. Don't do it! It is just one more hole where you will suddenly want to add a video mode, changing backgrounds for each mode, etc. Suddenly you want short animated clips for the modes.

Yeah. Hilarious way to test the code is to throw the kids at it. I was play testing VH and it was working perfectly. My kids came down to play it, and immediately caused a reset by double flipping multiple times. That is actually the origin story of the power supply filter board. There are other things too that pointed out issues such as holding the flippers as the game ended. (Who does that? I guess the answer would be my kids). Great that it is working well for you. My theory is that the fadecandy server is a relatively heavy task for at least one core of the host computer. This should reduce the load on the host computer a bit so maybe it will make a rasbpi even more possible for the host. Again, great work!

I did try and update the Pinball Makers OPP portion after cobra18t made his updates. It is hopefully now more clear what is related to STM32 versions, old PSOC versions, and information that is common to both of those versions. It is difficult for me to update certain aspects of the documentation, because I tend to add very detailed information (I like to explain why things happen while most homebrew pinball makers probably don't care). If somebody looks at the documentation and doesn't understand it, please send me a note and I can update it to clarify the information.