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.

Resolution of the problem!

Success!
The board is now running different voltages without any interference!

I swapped the P-Channel for a N-Channel on the 12V "rail" and pull-downs to pull-up's on the remaining P-Channel MOSFET's. No more weird double triggering.

As for ghosting;
There's unfortunately still plenty of it.

I'm thinking this is my fault when designing the board since rows and columns are operated on the same chain of shift registers. This means I cannot turn off rows and columns independently from each other but instead have to rearrange everything at once. I've also hardwired the OE (output enable) of the shift registers to permanently being on, which of course is a part of the problem.I don't expect this to be a big issue, but I'll have to see.

In case it is a major nuisance I can always add a few control lines and possibly OE as well.
I'm thinking OE would be most significant, as this would allow me to properly turn off the matrix while transitioning rows (and columns). 

Confirmation of the problem

Indeed it's the voltage that is the culprit, and there's a solution in sight.

I've created three example circuits;

Top - current and erroneous 12V circuit (should be off)
Middle - current and functional 5V circuit (is off)
Bottom - proposed and functional 12V N-channel circuit. (is on)

Example circuits

( No resistors in these circuits, but they don't affect the outcome here )

Ironically - a while back when transferring the lightboard from design to product, I found that I couldn't use N-Channel MOSFET's, and yet here it is saving me. I must have made some real booboo's on that breadboard when I deemed N-Channels nonfunctional for the lights, since there's really no reason for it not to work - it's all about which direction the current goes.

Weird Science

Ok, so I've found the problem with the lightboard after extensive search - When using two different power voltages (sources?) it doesn't work.

Why?
I honestly don't know.

I've double checked the hardware and rewritten the software, nothing seems to make a difference. I've done no change in the circuit, but simply removing the +12V and attaching a cable from the +5V input to the +12V makes it work perfectly. The both grounds are tied together as well and has always been. So the circuit itself should be alright, I guess?

My best guess now is that somehow power leaks into the "on-switch" of the 12V MOSFET since it's not connected to the same power chain as the rest normally, and therefor possibly allows the current to flow differently there. Putting diodes could possibly remedy it. But there's really no room on the board for extra parts, meaning some ugly Frankensteining of parts on top of parts etc.

I'll keep looking. Nobody wants weak 5V flashers... :C

Edit - 

Ok, I think I'm on to something here. And if so, it's a hardware error by design (by me). 
I'm connecting the gate to ground to keep it from floating, but that is how it's done for N-Channel MOSFET's, not P-Channel as those are active when grounded/low. So that'll have to change and will probably help a little with the ever so slight ghosting issue. 

Secondly; 
I thought the VGS value of a MOSFET was some kind of fixed requirement for turning it on. Well, it is - but it also depends on the load. So in this case when using logic level voltages (i.e up to 5V) the gate can be properly held shut by the shift register as the voltage is less or exactly the same as the gate voltage. In comes 12V and I'm suddenly short 7V to properly close the gate using my 5V, and the circuit is held open. Imagine closing a door standing in a river compared to closing a door in a shower, the pressure of the river is just to big to properly close the door and water will leak through etc. 

So I need to first fix the resistors from pull-down to pull-up, and then I guess add a N-Channel MOSFET on top of the P-Channel to act as a valve for opening/closing the P-Channel and thus the heavier load. I'm so glad I've moved the board to an easier to reach location!

1) Colors are off and the light numbers doesn't correspond with the correct channels yet, but you can clearly see there's no wrongful "double" triggering here.

Balls Be Lockin'!

Well, soon enough at least!

This is what I've come up with so far.
Should be fairly easy to manufacture; Five sheets of 10 mm plywood/board with standard drilling/sawing at most and a couple of 2 mm aluminum details etc.

1) Left: Open state. The holder solenoid bracket is spring loaded against the main solenoid plunger, and once the main solenoid triggers and the plunger reaches the endpoint, the bracket pushes forward and locks it in place. Right: Closed state. The holder solenoid and main solenoid is inactive and springs are doing their thing together with physics. When it's time to open I'll fire the main solenoid briefly to release tension, hold the holder solenoid while the plunger drops and then release the holder solenoid.

There are a few eyeballers here, but overall it should be pretty correct. The "fork" itself is based on a couple of bolts I have (with the screw part sawed off in the design) and they are a little shorter than I would like them to be. I will also have to double check that the ball won't squeeze through the gap. In case it does, I'll have to drill new or bigger holes in the playfield since the captive ball posts where 2-3 times larger than these bolts.

Should shit hit the fan, I got a couple of blue steel ramp flaps that can be placed on the playfield "floor" to cover up any unwanted holes. But I really hope it doesn't come to that! :)

This One's For You!

Woohoo, an update! ;D

Finished all diodes (I think) today, and got plenty of work done on the machine. For starters I moved the entire light board to the playfield for easier access and debugging/status checking. Unfortunately I realized that there appears to be some kind of error with the 12V line, as these are always active when one of the 5V LED's in the same column is active. I believe this to be a software issue as I cannot reproduce the error by powering rows/cols manually. Had there been any kind of short circuit that would have shown, I think.

The downside is that my programming environment is a very old laptop and for some reason I cannot compile code for Arduino anymore, so I'll have to use my desktop computer. It's quite cumbersome to setup so I'll put that to side for now.

Edit:
Actually, the row-MOSFET's are active when held low, so it's not entire impossible for the 12V MOSFET to be wrongfully and constantly grounded and therefor constantly active. In the schematics all rows circuits are the same and only the voltage differs. But maybe I connected something to ground "just in case" and since I've previously only connected the 5V line while testing the board, the problem could have been there from the start. I will investigate this.

Edit 2: 
Nope, that's not it. The board follows the schematic (who knew?!) and they're all connected identically. I cannot measure any differences between the functional rows and the erroneous either, so it's gotta be something in the code. Probably a clock pulse in the wrong place or something like that. Let's dive into manuals, yeay!  

1) Cluttered cable mess and the installed lightboard. The board sits on rubber pads and has extra support on the edges to prevent it from falling down, should it ever vibrate loose (not visible here).

2) Dimmed global lighting and example lightshow running. Note the erroneous red row that aligns with the green lights. No actual light has been plugged in at the moment since I need to work out the issue with the programming/board before applying real voltage across the playfield, but even then it's just 20 cables that needs to be soldered. Not a big deal at all.

Then I finished the one-way gate with double switching, meaning that it blocks shots from the front but registers hits, while letting balls from the bumper area pass through and still register hits. This allows for a greater range of options for game rules etc. I'm quite happy with how it turned out, even if the final form of the switchblade had to be reshaped ad-hoc since the nut was placed differently than in my "test rig".

3) More or less the player angle of the switch area. It's got a bit "last minute" to it, but hopefully it'll play alright and the benefits are far greater than the possible visual aspect of it. But honestly, I think the Quadtych deserves to be a visible part on the playfield - and now it is.

4) Birds view of the switch area. The metal rail in the bottom (i.e playfield right) was bent with a nice fit. The original part was just too short and I was tempted to put a pole between the bumper and the rail, but then I found a slightly longer rail in my "box of random parts" which worked perfectly. Guess I've been racking up some karma points at least... :) 

5) Switch close-up. Took a bit of fiddling to get right, but it works great. Hope it keeps running smoothly in the future too.

 Lastly, I've begun work with the ball-lock / up-post thingy.
At the moment all I've done is removing the old captive ball and modifying the plastic overlay slightly to better show the locked ball.

Next I plan to construct the actual ball lock device itself, where the problem today is two fold;
Firstly there's the issue of attaching the holder solenoid to the main solenoid. I need to find a good material that I can process without heavy machinery. I'm thinking a thin(isch) sheet of aluminum should work. Plan B is to construct a plastic placeholder while I think of something else. I'm refraining quite severely from purchasing new parts at this stage, but if I have to; well, I have to.

Secondly, the "fork" I was planning to use to hold the ball was of a wood screw type and is unfit for mechanical use, so I'll have to find an alternative for that. I don't think I can use an official Stern (or similar) ball lock as the space is very limited where I'm installing it. At least in the blueprints I've looked at it looks too big.

Well, that's all for now. Hopefully I'll have functioning lights and a ball lock next time! :)