9/27/2014 – Incandescent driver board tested

Here is a picture of the populated incandescent driver card:

The picture shows the MOSFETs in the correct orientation, and all the connectors placed the correct way.    The four and two pin connector on the right side should be a six pin connector, but I made due with what I had for the first card.  Same with the two connectors on the top right.

Spent a couple hours today and tested out the incandescent driver board.  To test the board, I built another board to use a computer’s parallel port to drive the SPI signals, and an old PC power supply to prove the 12V and 5V.  The picture below shows the parallel port to incandescent interface on the top right corner, and the incandescent driver tester on the bottom.  I haven’t had a chance to cut the two boards apart yet.

The converter board at the top has spade terminals for the 12V, 5V and ground from the power supply.  It also has the six pin connector that gets connect to the incandescent driver.  I cut a DB25 cable in half and used D0-D2 from the parallel printer port drive MOSI, SCLK, and SS*.

The test board is at the bottom of the picture.  Each pin of the four two pin connectors drives an incandescent lamp.  The incandescent driver board can be used as either a high side switch or a low side switch.  All of the playfields I have looked at in depth use a wire braid to return the GI lighting current back to the power supply.  That means that you need to provide a high side switch (i.e. cut switch the voltage on and off instead of switching the connection to ground on an off).  Since it is a high side switch, and I’m using an N-channel FET, to turn the FET on and off, a voltage is needed which is VLED + Vthreshold for the FET.  The threshold voltage for the BS-170 is 3.0V max, and most pinballs use 6.3VDC, so about 10V is needed to turn on the FET.  The power supplies provide 12V, so that should work perfectly.

So trying to lay out the board quickly, I messed up one signal.  The G* signal on the STPIC6D595 needs to be grounded instead of pulled up.  That’s a simple cut of a trace and add a wire on the back of the board.  The mistake is disappointing, but it is easy to fix.

Since the incandescent driver boards are being used as high side switches, the spade terminals on the card are connected to VLED.  I bought a couple of buck converters to change the voltage from 12V to 6 or 7V to drive the LEDs.  That should make them look a lot less anemic.  Each pin of the two pin connectors go to a light bulb and provide the power to turn it on and off.

Next step is moving towards the Pi.  My laptop doesn’t have a real parallel port, so now I can’t easily run feature lights and the serial interface off the laptop, so it is time to start getting stuff working on the Pi.  That will reduce the amount of voltage conversions that I need to do.  I will end up using a voltage converter chip to move the 3.3V Pi signals to 5V for the old driver cards (won’t be necessary with the next generation of cards), and then the conversion to convert the SPI bus signals to 5V.  I will put down a second chip to convert the 5V from the Tx output from the input/solenoid driver boards back down to 3.3V.

I have to build a bunch of boards for Cactus Jack, but I’m not sure how he is going to drive them.  That might require a few emails to figure out how he wants to drive that stuff.

Oh yeah, here is  a link to the video of the incandescent driver running the test fixture.  A 200ms sleep was tossed in so that it didn’t blink too rapidly to film.  Running at full speed, the flashing was so fast my eyes couldn’t detect it.

9/20/2014 – Incandescent Driver boards

Boards showed up on Friday. The boards contain the next generation of driver cards and four copies of the incandescent driver boards. I got a chance to build up one of the cards and immediately noticed that I put all the MOSFETs in backwards.  Grrrrr.  I originally planned on using one MOSFET, but opted for one that could sink more current instead.  The new one is in the same package, but it is pinned out in reverse.  I’m glad that I picked the new packaged because the current is higher than I expected.

The first built board is always a learning experience. You learn which components to solder first, and where the gotchas are. I rushed the board a little bit too much, and didn’t leave enough space between boards. Because of the tightness between the boards, I needed to use the Dremel tool to cut between the boards instead of the tile saw. When I use the Dremel, I can’t set up a fence to get the cuts perfectly straight. I’m disappointed by that because I feel I could have spent a little bit more time, and made sure there was enough space so I could have used the tile saw.

When I did the initial soldering of the FETs on the card, I used too much solder. I ended up needing to wick off some of the extra solder, but corrected the mistake on the second group of four MOSFETs.  Luckily, since I put all of the FETs in backwards, this was now simply my practice board.  The second board that I soldered went much better and looks very clean.

I measured the current through multiple 44 and 47 bulbs.  These were old bulbs that were already installed in the machine.  At 5V, they measured anything from 200 mA to 350 mA.  That gives them a range of  resistances from 14 to 25 Ohms.  The new FETs (BS170) can sink 500 mA continuously so that should be plenty of headroom.

I would really like to switch over to LED bulbs, but I can’t find any succinct information about the light output at 5V.  All of the LED bulbs have internal current limiting resistors, but without that info, and the spec on the LED itself, it is tough to say what it will look like.  An LED has a steep voltage to light output curve at low voltages, then flattens out at higher voltages.  The current limiting resistor determines the location on that graph, and it may or may not be a huge difference in the amount of light.  (At higher voltages/currents, most of the extra current is converted to excess heat.)   I’m going to ask some people around here if I can borrow a bulb or two for a week to see if I can make some measurements.

The big plans for this weekend are to try and get the incandescent driver board actually driving lights.  I’m planning on using a computer parallel port to test the boards.  I just finished the voltage converter board.  A printer parallel port outputs 3.3V but must be converted to 5V since the STPIC driver needs 4.25V for a logic high. The output of the printer parallel port will drive the gate of N channel MOSFET which will convert the 3.3V level to 5V. The output will be inverted since a high level on the parallel port will turn on the MOSFET which will ground the pullup to 5V.

I will probably end up doing a simple python script to bit bang the SPI interface using the parallel port.  That gives me a simple way to test the boards after I solder them to make sure they are working properly.

Ended up building a simple test fixture for testing the boards.  It contains 8 LEDs to test the 8 drivers on the incandescent driver board.  Take that, add an old PC power supply that I have laying around, and I should be set to go pretty soon to test the boards.

I had big plans of finishing the testing this weekend on the driver boards, but it now seems like I won’t get to it this weekend.  Probably sometime during the week.  The board is populated, the test fixtures are created.  I just figured out that a USB to parallel port won’t work, grrrr.  I started working on the Python test script, but I probably won’t have the time tonight to test, do a video, etc.

So about a month ago, somebody contacted me to get some boards so he could run an old playfield.  I was still looking for another alpha site to make sure somebody else tested the hardware and gave me feedback on the documentation, etc.  Since I tend not to use real names for people, I’m going to call him Cactus Jack.  (The name is completely based on the fact that he has a cactus at the front of his house.  Looks like a nice cactus.)  He has been working hard, and has tossed up a couple of videos and a little bit of a blog entry.  Of course, now he is waiting for me to finish up the incandescent driver boards.

The videos and blog are located at http://www.kerform.com/.

OPP Cards Displaying Status on Remote PC, 9/4/2014

So two weeks ago, a board was sent out to the board house (Iteadstudio) and all was well. I needed to get that work item done, so while it was being manufactured, and shipped I could do other things in parallel. I spent the next week trying to scare somebody away from the project, but utterly failed in that attempt. He has an old playfield Bullseye/301 with nothing to drive it. No cabinet, no electronics…basically a perfect match for using OPP cards. Joe has been dogging it lately (something about being busy with something other than designing his pinball machine), so I haven’t gotten as much feedback as I wanted from him.

I feel to insure the viability of an open source project, it needs to either be so simple that no documentation is needed, or there has to be enough information so that a person who understands the topic can easily find the necessary documentation. Pinball controllers are relatively complex. There are three main boards that are required to control a pinball machine. The overall design, architecture, and implementation are in my head, but how does a person that simply wants to re-use the board designs start with their machine?

The only way that I can make sure the information is available is to get somebody else to use the cards, and to document questions and steps during the process. Essentially take on an alpha customer to force the information to be generated. Joe was supposed to be that person, but alas, building a machine completely from scratch takes a long time. I’ve had the cards for more than two years (actually almost three) at this point, but things moved at a snails pace. (Much of it was caused by fear of actually cutting whitewood. If I had a CNC router, it would be a much easier process, but to build one of those, it is a couple month hit in time.) When the SS2 playfield was purchased, the decision was made to bring it back to life. It does not have a fan layout so that actually drew me to it. SS2 is relatively rare, which makes it more appealing to me. Next big step forward was getting a rotisserie. I had set up the Camelot playfield and batted the ball around, controlled all the solenoids, but it was sitting on blocks of wood, and with every flip of the flipper, it would almost fall off the table. Every time I wanted to work on the underside, it would be a half an hour production to go between the table top setup, and the leaning against the wall so I could solder it. A couple months ago I built the rotisserie, and it lets me move between playing and wiring in the span of about a minute. With the amount of testing that I did on the SS2 playfield and previous tests, I felt confident in the cards. When the new person contacted me about getting a few cards to drive his playfield, it seemed like a good match. He seems technical enough to get it working, and from reading his blog, it seems that he is better with a soldering iron than I will ever be. Once he gets some information up on his website I will post a link to it.

Last week I sent him enough cards to control the playfield and read all the switch inputs. After sending those, I immediately realized that he would need some sort of documentation to start the rewiring of the playfield. Well, all the information is in the blog, but who has the time to go through two years of my random mumblings (most of it pointless) to find the technical details. I’ve started a rewiring a playfield document to provide this information. The initial version of the document should be available in the repository by the time I post this blog entry. There is also another guy, (I think I’m calling him Pierre since he is from Canada), who says he wants to take care of the Google code repository wiki. That would be a perfect place to put much of this information or at least pointers of where to find it.

So last weekend after building cards, shipping cards, working on a document, etc., I finally got back to working on SS2. I finished the wiring for all the switch inputs, and wired the communications between all the cards. I dragged the laptop down to the basement, and ran PinBrdGui.py.

PinBrdGui is basically a debugging aid that I wrote a couple months ago. You tell it what serial port to look at, and it goes out and auto-discovers all the boards on that serial port. In SS2, there are two solenoid boards and two input boards. It displays the current state of each of the switch inputs on the input cards, and it displays if a solenoid has been triggered on solenoid cards. Input cards can also be configured to report edges, but that is not as useful to debug if the switches are working. When a solenoid bit detects the correct edge (usually falling edge since input bits are pulled up, and closing the switch grounds them), the next status read from the card will have a ‘1’ in the correct bit position indicating the solenoid has fired. After the status is read, the solenoid driver card clears the status bit automatically. That means if the main processor doesn’t get around to reading the status for a while, it will not miss the fact that a solenoid has fired. In the embedded world these types of bits are called clear on read bits.

So here is a link to the video of the laptop getting real time status of input bits, solenoid kicks, from all the SS2 cards. https://www.youtube.com/watch?v=jKv1SIMZt1w. Couple notes on the video. On solenoid card #1, you can see the lsb fluttering. That is caused by a manufacturing defect on the card (probably a whisker of solder). That should only take about 5 minutes to fix when I have the time. The PinBrdGui helped me figure out that issue immediately since I could leave the switch open and see the fluttering, and close the switch, and see the fluttering immediately stop. Some persistence should be added to the displaying of the solenoid status bits. Since the status rate is so fast and the bit is only set for a single frame, it is easy to miss a solenoid input bit going past. A frame rate should be added. I’ve estimated and calculated the worst case status frame rate, but having PinBrdGui print out the actual number of frames per second would be a great debugging tool.

I have notes to write about 10 more things, and frankly I need to finish the playfield rewiring document. In the above blog entry, I promised the document would be finished before I posted this. I lied. I’ll write more after that is in the first draft form.