The Black Knight Rises - Progress Update

These past two weeks have been very productive, and I am getting closer and closer to firing up the solenoids.  There's so much to talk about.

In this post I cover my new 5v LED power supply (tweaked to 5.5v), measuring the Chameleon IO Controller's power consumption, updates to the ChameleonIOController.dll, a custom 3D printed wire connector bracket, wiring up main power and ground to the power drivers, a potential ChameLED v2 redesign, playing around with the IO controller's latency now that it's hooked up to the playfield, and beginning the Chameleon Pinball Engine's software updates.

Yeah, that's a lot to cover, so be sure to click through to read the whole post.

5.5v LED Power Supply
I picked up a new 5v 5A industrial power supply to handle the LED's.  With it hooked up to my voltage meter, I trimmed the potentiometer to set the output voltage to 5.5v, splitting the difference between my ChameLED's and the CoinTaker LED's voltage designs.

Powering up the LED's with this new power supply, the difference was night and day (or more like night turned into day, that's a lot of light!).  The 6.3v CoinTakers now look fantastic, nice and bright and with almost no flicker at all when PWM dimmed.  And of course the ChameLED's are still bright and beautiful with absolutely no flicker!  I'm not really sure why the CoinTakers has a minor bit of flicker, but I expect it is due to their fully-rectified AC/DC design, though it could be because I'm still slightly underpowering them.

I put my ammeter on the new power supply with all 76 LED's lit up, and I recorded 4.4A, so it's safely within the 5A capacity of this tiny power supply.  Looks like I got a winner.  This also means that, on average, I'm now pulling about 58mA per LED, though I haven't yet retested the ChameLED vs. the CoinTaker to see how each performs.

Chameleon IO Controller Power Consumption
One thing I've wondered about for a few years now is how much USB power my Chameleon IO Controller design will consume.  I know that seems like a silly question, since I designed this board and have the specs on all the components.  But the specs on the various IC components only have max power draw, and actual power draw can vary greatly on how you configure the USB controller and programmable SoC's.  I've disabled some of the power consuming capabilities and turned down the various clocks I don't use to their slowest settings, in the hopes of saving a few extra milliamps.

I was fairly certain my design was under 500mA, well within USB 2.0 limits, but secretly was hopeful it would come in much lower.  Why?  My one big regret on the Chameleon IO Controller v2 design was omitting a downstream USB port for daisy chaining another board.  After all, I have a 4-port USB hub controller built into my board, but it's only connecting to 3 SoC IC's, leaving one extra port that I simply turned off.  I can't believe I didn't at least add a PCB landing pad for the USB port in my design, but I guess in my pursuit of making the board as small as possible, I omitted expandability.

Had I included that downstream port, I could have connected a 2nd board with dedicated LED outputs, possibly adding an additional 192 LED lines.  Why so many?  For RGB, which devours 3 outputs per LED.  

While the Chameleon IO Controller has 112 outputs now, a typical pinball build will take 16-24 of those for controlling solenoids, magnets and possibly mechanical toys (servos, motors).  That leaves about 88 outputs for LED's, and if doing a full RGB build that only allows for 29 or so RGB bulbs.  That's just not enough lamps, a full pinball machine would need 3x as many.  On a playfield like The Black with 76 lamps, I could convert about 6 of those to RGB before running out of outputs.  Though if I really needed to, I could double up some general illumination LED's on a single output and still be within board power specs, freeing up more outputs for RGB signaling.

Anyway, since I didn't know the power draw of a single board, I wasn't sure if it would even be possible to daisy chain a 2nd board and stay within the 500mA USB 2.0 spec.  And without a working board, I had no way to test.

Well, until now.  Finally, after all these years, I've unearthed the answer.  

I bought a USB power measurement dongle that plugs into your USB port, and measures the voltage, current, and power consumption of whatever you plug into the dongle.  I had to make sure I bought a power meter that had data passthrough, otherwise I wouldn't be able to control the Chameleon IO Controller to run any tests.

It only took a few seconds to plug everything together and I was instantly measuring power consumption.  I was amazed that at idle the Chameleon IO Controller v2 was only consuming 150mA!!!  

Measuring the actual USB power draw of the Chameleon IO Controller - just 150mA - 220mA

I then ran it through several rigorous tests, turning all lamps on, doing fast sweeps and random patterns.  With all outputs on, current climbed to 180mA, revealing that it takes only about 30mA to enable the LED output power drivers.  Triggering switches didn't make the current fluctuate at all, but that's not too surprising.  In some of the fast sweep lighting tests the current rose slightly beyond 180mA, a few times hitting 210mA, and at least once hitting 220mA.  Perhaps it takes extra current to turn an output back off?

Still, a measly 220mA to power a USB hub plus 3 programmable SoC IC's!!! I'm quite excited by this performance.  This opens the door to a future revision, a Chameleon IO Controller v3 that includes a downstream port (and possibly other minor design tweaks), plus a separate Chameleon IO Expander with at least 192 extra outputs, maybe even more.

With those two boards together, you could have 24 solenoids (and other gizmos) + 280 LED's, or if doing RGB a still impressive 93 RGB LED's.  That should be plenty for even demanding pinball playfield designs.  

And by daisy chaining the expander board to the main board, that design would allow for a single USB connection to the host PC, same as the current solution.  That's pretty sweet.

I still have a substantial investment in v2 PCB boards, and since the design is perfectly functional as-is, I have no plans to throw those away.  They're perfect for non-RGB or limited-RGB pinball builds like The Black Knight Rises.

ChameleonIOController.dll Updates

In the last post, I had a beta version of my new Chameleon IO Controller's dynamic link library working pretty well, but it was missing a few key features.

Since then I've added hot-plug support, and it works perfectly.  Even in the middle of a lighting test, I can unplug the controller board, wait a bit, and plug it back in, and my software never throws an error, adapts automatically, and immediately resumes updating the outputs and reading button presses as soon as the PC recognizes the board is connected again.

Now, why would you need hot-plug on a pinball controller board?  No freaking idea.  But hey, it works.

I also added in a few more API options to set the hardware PWM modes, and to toggle the software controlled outputs between PWM and PFM. At this point, I think  the DLL is 99% complete, so I can finally turn my focus to updating my pinball code.

Playfield Cable Connectors Mounting Bracket
A few years ago when I was working on a Modern Firepower tune-up, I added a 3D printed bracket onto the playfield to hold the 50v power and 5v/12v DIN plugs.  This turned out perfectly, so I decided to do it again for The Black Knight Rises.

The 3D printed cable plug mounting bracket I designed for Modern Firepower.

For The Black Knight Rises project, the bracket design was more complicated due to the two-level playfield.  I had to design a longer stand on the bracket to allow it to be mounted to both the upper and lower playfields at the same time, as there simply wasn't any other ideal mounting locations. 

My newly designed cable connector mounting bracket for The Black Knight Rises.

Instead of using a DIN style plug for the 5v power, I instead used a standard 5.5x2.1mm power adapter plug.  The solenoid power connector for the 38v power supply is a standard 0.093" Molex style 2-pin connector.  I also added in a 3rd connection, a USB port extension.  

Here you can see how the new connector bracket bridges both the lower and upper playfields.

Right before printing my new design, I realized I also needed to raise the connections off the playfield about half an inch to clear the playfield rotisserie bracket, otherwise I wouldn't be able to plug anything in unless I moved the playfield into the cabinet. 

By offsetting the holes by about half an inch, the connectors clear the playfield rotisserie's support arm.

I was really happy I caught this detail in time, as now I can plug everything in on the bench and make sure it works before putting the playfield back into the cabinet.  Just like my Modern Firepower build, these three cables (38v, 5.5v, and USB 2.0) are the ONLY connections from the playfield to the cabinet.

The USB connection is just a simple 18" extension running from the Chameleon IO Controller.

The 5.5v power and 18" USB extension cable connected to the Chameleon IO Controller v2.0

In case you're confused how I'm running 5.5v into my USB based controller board, it's because the chips use USB provided 5.0v power separate from the 5.5v I'm using for the LED's.  Technically, I can use any voltage from 0-50v for my LED outputs, it's fully isolated from the USB chipset voltage.  This means you could easily use the Chameleon IO Controller with a 6.3v power supply if you use 6.3v bulbs (LED bulbs only, though, to stay within amperage limitations of the board).

I also 3D printed some mounting brackets for the 38v power supply, to mount it in the cabinet.  Luckily I found an existing design on Thingiverse that worked perfectly.

I 3D printed these well designed power supply mounting brackets that I found on Thingiverse

Solenoid Power Wiring
When I was last working on The Black Knight playfield 4 years ago, I had already wired up the solenoids and magnets, and connected them to the Chameleon Power Drivers.  But I had not wired the power drivers to each other or the incoming power supply.  I finally got to this last step this week, and now everything is wired up and ready to go once my software is ready.  

Running the 38v power to the first Chameleon Power Driver board.  Need to daisy chain to the next...

I did discover another oversight in my power driver v4 board design.  I had thoughtfully included two connectors each for main power and ground, so that I could daisy chain the boards together.  You can see that in the photo above, the green screw terminal has four wire connections.

What I didn't consider is that I also needed one of those ground connections for connecting to the solenoids.  In that photo above, the thin black wire is running to a solenoid (and from there daisy chained to the other 5 solenoids on this power driver).  I should have included at least 3 ground connections.  

2 red power and 3 black ground wires running into the 2nd Chameleon Power Driver, to daisy-chain with 2 other boards.  I should have included at least 1 more ground screw terminal to make this easier - I forgot about the solenoid ground connection.

Considering I had also overlooked including a TVS diode (for handling transient voltage spikes), I'm now considering a v5 design that would add in the TVS diode connection points, and at least one more ground connection.  It also would be nice to have 1 more mounting post between the fuse and screw terminals, as using just the three posts causes the board to flex when tightening the screw terminals.

Note that there is a TVS diode on the board in the photo above, it is just soldered on the bottom, hidden from view.  Considering how big the TVS diode is, this isn't a bad solution, as it frees up board real estate on the top side, but a proper design should have the through-holes for connecting the diode.  I simply soldered it to the screw terminal mounting posts as a quick fix.

But I won't rush into any design changes just yet.  The current v4 design still needs to be validated and stress tested to see if there are any other issues that need resolving.

ChameLED v2 Mockup

While I'm extremely pleased with both the Chameleon IO Controller v2 and Chameleon Power Driver v4 designs (even considering the potential improvements), I've come to hate my ChameLED v1 design.  

Why?  Well, look at that power driver photo above - the wiring is so ugly.  Due to the design, it was a lot of work to solder the wires to each board, a lot harder than I expected.  I don't ever want to do that again.  

And my resizable board design ended up too large, making it extremely difficult to get them to fit in tight spaces.  The worst part is that, at least for the RGB LED's I chose, they are expensive.  Each raw RGB chip I'm using is more expensive than what you can buy finished RGB LED boards from other vendors.

A few years back, I got to poke my head inside a Total Nuclear Annihilation, and one element that gave me inspiration was the RGB LED's.  They were smaller than my design, used a much larger (and cheaper) through-hole LED, and had pre-installed wire-headers.  No soldering of wires.  Nice.

With a bit of research, I discovered that the LED in use is a Piranha style RGB LED (they also come in single colors).  Anyone's that's played TNA knows the RGB lighting is gorgeous, so obviously these Piranhas are a really good LED for pinball.

Turns out, you can buy these from PinballLife:

The P3-ROC Single RGB Insert LED PCB Assembly, available from Pinball Life

While that's totally awesome, I can't use these on the Chameleon IO Controller.  They don't have built-in resistors, so each color would get the full voltage from the controller.  At best I could lower the LED voltage to around 3v, and always PWM the Red channel to a lower level to prevent burning it out.  These are designed to be used on a P3-ROC, and I'm guessing that it has the necessary resistors on that controller board instead of the individual LED board.

And while the wiring header is an improvement over my soldering approach, it doesn't have the wiring flexibility that I'm aiming for.  The P3-ROC solution leverages pre-made wiring harnesses with connectors at both ends, so if you want a custom length cable you have to make your own.  I prefer to cut custom length cables on the fly, and don't want the hassle of crimping connectors.

So with this as inspiration, I've done a quick mock-up of my potential ChameLED v2 using the Piranha RGB and screwless wire terminals:

ChameLED v2 mockup with a Piranha RGB LED, built-in resistors, and screwless wire terminals.

I was a bit lazy in my modelling - my goal was just to figure out dimensions - the 3 white boxes represent the screwless wire terminals.  All you have to do is cut the wire to length, strip the tip, and push it in to the terminal. 

The two small terminals are for the power connection, pointing in different directions, making for easy daisy chaining of the power line to the next LED board.  The larger white box has a 3 wire terminals, for connecting the RGB ground control lines. 

The small black box is a resistor, and there's actually 3 of those (the other two are hidden behind the white box), so I can tailor the board to whatever voltage I want, 5v or 3v or anything else, making it compatible with my controller design (and pretty much any other device that can control LED's).

It's hard to tell from the mockup that this design is about the same length but half the width of my ChameLED's v1, so it should be much easier to mount these in tight spots.  I don't have the actual dimensions of those P3-ROC LED's, but based on photos I've examined they are about the same length and a few mm skinnier than my design. I'm not sure why they have two mounting holes, perhaps for more mounting flexibility, and presumably you could shorten their design by around 10mm by chopping of the bottom hole.  The screwless wire terminals I'm considering are my main size driver, so I can't really go shorter without finding a different terminal.

I also did some pricing estimates, and by switching to these smaller PCB's and the Piranha RGB LED's I save enough money to add in those screwless wire terminals (they're expensive!) and still come out at about half the cost of the v1 design!  The inclusion of those screwless terminals and resistors does drive up the cost making my design more expensive than those P3-ROC boards, but I think my IO controller design more than makes up for the slightly more expensive LED design.

A single color (i.e. white) variation of the ChameLED v2 might cost up to 15% more to make than my v1, mainly because of those expensive wire terminals.  But that price difference could potentially be made up by finding a cheaper source for those Piranha's - it seems to be a common footprint made by a lot of companies, and some of these are so cheap that, assuming they're any good, they would actually make the v2 design cheaper than the v1.

Smaller, easier to wire up, and cheaper.  Yes please.  While I've got a few more important items in the work queue before tackling a redesign, I strongly think the ChameLED's v2 are a must have improvement.  I'm disliking my The Black Knight Rises LED wiring job so much I may even rip those off and replace them with ChameLED v2's!

Playing with Latency
In my previous post I did a fast sweep LED test to see how fast I could cycle through all outputs, and found that it took about 8-9ms to process each state update.  While this is pretty quick, I was expecting sub 6-ms times.  

In my earlier controlled latency tests, I triggered a gamepad button input on the Chameleon IO Controller, and measured that it took about 5-6ms for it to travel to the host PC, get processed by my test software, and travel back to the controller to turn on an LED output.  Since my sweep test was simply controlling outputs without processing any button presses, I figured it would be faster.

Turns out, I seem to be measuring two similar, yet very different, metrics.  

My sweep test is how frequently I can send updates the Chameleon IO Controller, and it turns out I can do this constantly at 120Hz.  

The button latency test is how long it takes the button press to be converted into an LED output change, and on average this is actually quicker than the 120Hz refresh rate would suggest.  This is partly because in the button test, the host PC was idle, waiting for a button press before sending any data to the controller.  In the sweep test, the host PC was busy, updating the controller over and over again as fast as possible.  

So while it may only take 5-6ms to convert a button press into LED output, there is an additional 2-3ms or so of latency before you can do that again, as the controller isn't quite ready to receive new data just yet.

This means the best way to optimize performance is to only send updates to the controller when data has changed, as otherwise sending updates repeatedly as fast as possible, even if nothing has changed, only delays the next update signal by a few milliseconds.  Fortunately, my pinball software already only sends commands if data has changed, so no updates required for take advantage of this discovery.

While figuring this all out, I did play around with button latency a bit on the actual playfield.  It's actually quite electrifying to test it, as the LED's light so quickly your brain thinks that you just got zapped, and you want to yank your finger away.  

It is definitely faster than the current performance on Modern Firepower, though I've yet to apply my recently discovered performance optimizations to my pinball code to improve it.

Here's a video of me testing performance by hitting switches with my finger.  In regular video, the response is instantaneous.

Here's another video of it in slow motion, and it still looks amazingly quick.  But there's something else to notice in this video that's even cooler (at least to me):

Notice that all LED's light up at exactly the same time!  This is NOT matrixed lighting using shift registers.  This is true discrete lighting.  I have exacting control over all outputs, and there is absolutely no flicker related to matrices being scanned line-by-line.

Pinball Software Updates
Speaking of pinball software, I've started updating my code.  I last looked at this code about 4 years ago, so it's been a slow start as I relearn my code and figure out where I left off in my last revision.

It's only been a few days, but I've made some great progress.   I hope to get it far enough along to do a solenoid test this weekend, but that's a long shot. 

 
4 years ago I was in the middle of a major playfield configurator redesign, and a lot of the code is in a broken state as I was working through a massive overhaul.  I need to get this playfield designer code working again so I can configure The Black Knight Rises' playfield in the software.

Working on the Chameleon Pinball Engine's playfield configuration tool.  Easy drag and drop pinball design!

I also need to add in support for my new ChameleonIOController.dll, and it's not just a straightforward swap with the LED-Wiz code.  

The LED-Wiz used 4 bytes to turn each of the 32 outputs ON/OFF, and separately another 32 bytes to control PWM levels, and these two commands had to be sent separately.  Because I was using multiple LED-Wiz's (3 for Modern Firepower) I also had to manage these 4 bytes and 32 bytes separately for each LED-Wiz.  What a pain.

For the Chameleon IO Controller, I just need a 112 byte array to control all 112 outputs, for both ON/OFF and PWM level.  

While that's super simple, I now have to find every place in my code that is tracking those LED-Wiz formatted values and make it optionally handle the Chameleon IO Controller values instead.  I wrote that code about 7-8 years ago now, and I don't remember how many places it lives, so it may take me a while to find every reference and add in the new logic.

Until I update the code, my Chameleon Pinball Engine can't speak to my Chameleon IO Controller, so I can't test anything.  It's frustrating and exciting to be nearing the end of a very long journey - so close, and yet still so far...