Are we there yet?

Not quite, but at least the machine is done enough to be moved into the living room. :)

1) Close, but no cigar. But at least the scotch is cooling, awaiting the cigar!

Double polarity LED's... who knew?

Oh boi. I'll just say it.
Shame on me - I missed a couple of diodes.

The bumpers and flashers were still "unprotected" and on top of that, the LED's I had installed were double polarity meaning they worked in both directions....  Who could have known, right?

The good news are that lights are now working somewhat properly (we'll get to that) and I've updated the main board with the correct lights and what not. This means I'm kinda back where I was before recreating the light board. And that's a good thing! I've also fixed sound and music, which had a few bugs that has stayed uncorrected since moving to the new system and board. Tried a couple of quick games too. 8-)


The bad news is that there is a slight flickering when a couple of lights are active at the same time. This flickering occurs on the light board itself as well, so it may be due to lack of power in the board or shift registers. I'm currently using a row/col based approach, which lights up to 12 lights per channel. I will try converting to col/row so that each row only ever power a single light at once. Hopefully that solves things.
 
I've also noticed that the servo handling the target bank was dead.
So I replaced it, only to find out that that servo too died after a few on/off's. The servos are beefy ones and are moving up to 5kgs, which is more than enough for the purpose, but somehow they die anyway. This last one has frozen in place, unable to turn, but it sounds like it's working. I'll have to investigate this further.

On top of that, the captive ball lane captures balls despite having no ball lock. The irony...

Code revision on the game will have to wait until the servo is corrected, as well as the captive lane.

But yeah, progress! \m/  

It's not me, it's.... something else.

So, got my dirty hands on the light board and re-did the whole "extra board" thing. It still looks like crap, but at least now it doesn't glitch or have connectors that risk failing.

Then I realized, by accident really, that there was no ghosting to speak of in the board.
There wasn't even a problem with the board itself, besides the glitchy MOSFET, that is.
The problem is that somehow, don't ask me how, current is traveling back through the light grid/matrix and "triggers" other ports.

1) Light board only. No light cables or playfield connected. The camera had a rough time trying to photograph this, but everything looks just fine IRL. Crisp and sharp lighting and most importantly - no ghosting.

2) The very same light setup except that the power connector to the playfield has been connected as well. Behold - The mother of all double triggering, ghosting, annoying and downright irritating setup is created.

I don't know for sure at this point why this is happening, and it's rather hard to measure with a multimeter. Since it's using 3 MOSFET's enabled per active light it's also extremely/"impossible" to troubleshoot outside the cabinet. But here's what I got so far -

Everything is working perfectly with no extra cables attached.
Since the board has diodes from each MOSFET to the power lines and that the LED matrix on the lightboard is just that - LED's - current must be coming back through the very same power lines.
Unless I'm measuring wrongly, I'm also reading negative voltages on the ports that should be off.

That means the board _should_ work perfectly fine and that the problem should indeed be in the light matrix/series on the playfield itself.

Could I have connected something wrongfully? Possibly.
But still, I don't understand why it should be that - I got diodes installed on each lamp. So current can only flow in one direction, unless I made a mistake somewhere. But with everything attached there's just too many variables to investigate. Have to narrow down the search area...
I'll most likely troubleshoot this in a rather naive way -
By disconnecting all power cables from the playfield and adding them back one at a time (possibly with a diode as well).

Light and Sweet!

Finally got a little work done!

Not a whole lot, but at least lights are active again. :)
The ghosting is pretty horrible thou, but should be easier to troubleshoot this now since I have a proper load on the circuit.

 

1) Long time since the board was lit up!

Looking forward to the day (hopefully soon) when I start re-labeling the lights and hopefully get rid of the ghosting. 

The Bride of Frankenboard

Rise, my child, RISE!

1) Bride of Frankenboard. I wanted the add-on board (to the left, with the blue sockets) to be somewhat serviceable so I created it to be removable. Originally I had a fantastic Arduino-shield like design with headers that the board would slot into, but there just wasn't space. At the moment this is the best option, but a later revision will be larger in design so that it's in fact serviceable and not just in theory (i.e without a ton of cables in the way).

Alright -
So I've created a daughter board to the light board made from an old obsolete switchboard, hence the bulky blue sockets, containing all N-Channel MOSFET's to allow for logic 5V switching of loads independent from the logic (i.e > 5V). Link to circuit.

Seems to be working fine so far!

The downside is that it's hideous. And slightly erratic in its dependency, as it seems to have a glitch somewhere, but I can't see or find it. So I guess this board will have to be a sort of "proof of concept".

But it does work.
And that means I can continue with other stuff.

2) Ignoring the broken magnet holder, here's an active light with 12V (i.e around 1.5V due to duty cycle).
Still not super bright, but...

3) ...good enough for the purpose. I will try higher voltages, probably 24-36V, in the future
as well as bulbs won't light up properly otherwise. Either that or actually converting to LED's... 
Also, note the washed out colors of the text. I have a solution for that as well, but that's a later issue.

Let's introduce our little friend; Little Mr Duty Cycle

Forgot all about the LED's being duty cycled while being multiplexed.

8 rows active (~12.5% duty cycle):

1) 12.5% duty cycle, quite dim, but still alright with LED's. Incandescent bulbs barely light up.

1 row active (100% duty cycle):

2) 100% duty cycle. Everything works peachy, including incandescent bulbs.

When all rows are active the voltage is roughly 1.2V, thanks to the ghosting - otherwise it would be lower. This is with 5V input. To get it as bright as it should be I think I'd need to go up to 30-48V for 5V actually, which requires separating the logic chain voltage from the drive voltage. 

And even weirder - the LED doesn't light up much at all when using the 12V line, so it looks like something is wrong there (probably programmatically, as that row requires special handling etc).

Welcome to nightmareland. :/

Now what?

Ok, so I went ahead and soldered separate data, clock, latch and enable lines for rows and columns and updated the code to reflect the changes.

STILL ghosting.

Albeit less, it's still apparent when the surrounding is dark. 

There's no ghosting when not switching rows so at least that narrows it down slightly.
I'm thinking that either the LED modules suck, or the MOSFET's doesn't close fast enough. The MOSFET's are rated for logic voltages and should fully saturate. However - Considering the data sheet the opening and closing times are rather large thou:

Turn on rise time: 210-430 ns 
Turn off fall time: 110-230 ns

This leads me to believe that (I haven't calculated this yet) perhaps the switching is a bit on the slow side for a LED matrix purpose.

But it is what it is, and quite possibly this is not an issue when connecting the actual lights.
So I'm moving on for now.


Edit:

So I lied.
I haven't moved on.

Apparently I need to apply some kind of load that removes excess current still in the circuit/LED's after the MOSFET's themselves have closed. It makes sense, as explained by Chris (dcel):

"With no load after the voltage falls below the LEDs turn off voltage, there is nothing to bleed off that stored energy, hence that "afterglow". You may want to put a pull up resistor on your n-chan drain as well so its not floating.

     In my troubleshooting, I put an incandescent lamp in parallel with the LED lamp and that made the channel turn off hard. Uhm... interesting, threw a 100R in with same hard off result. I experimented with increasing resistances and found for my app, that 100K was sufficient to turn the FET off hard at 1ms or less. Good enough for me. "

Something like this.

1) Fancy schematics. The resistors around the LED should lead current away from the circuit when either side shuts off.

Sounds fair enough and relatively easy to test without destroying something. #FamousLastWords

There's also ways to push the fall time below normal by forcing it shut with negative voltages. But that sounds at lot more complicated and risky to me. On a plus side; I've also found evidence that Williams had problems with ghosting in hardware as well and worked around it in software.