Thursday, August 4, 2016

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.

Thursday, July 21, 2016

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. :/

Wednesday, July 20, 2016

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.


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.

Tuesday, July 19, 2016

Resolution of the problem!

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

Monday, July 18, 2016

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.

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. 

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.

Saturday, July 16, 2016

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