As long as I can join.

If we could attach XML files, this thread would be a very convenient way to share settings. Hopefully, we can keep it focused on settings and use the other thread for sales issues.

Really?!? I've never been able to make use of anything that high, but you have me intrigued. I'm going to try it on my RBION as soon as I get some spare time.

FS: RBION Mudflaps Edition

Not that I'm aware of. I've been curious about it for a long time, but lack of time to work on it, limited access to Capcom games, and limited demand have prevented me from starting work on it. The final straw is that it would take two OCD boards since there are two matrices in Capcom games.

It also depends on how picky you are. Even though I picked the defaults to make them the best compromise for all games that I could, I still end up tweaking nearly every game I get. Others tell me that they're perfect out of the box. Even more confusing is that when I owned HS2, I had a bunch of custom settings. My brother's HS2, with the same brand and colors of LEDs, I ended up staying with the defaults after tweaking on it for about 15 minutes.

What I usually end up doing is set it to something that looks close, play a while, tweak a little more, then ask my wife to look at it. Her eyes are more sensitive than mine, so if it passes her test, I call it done.

There's not really a waiting list any longer. You can sign up for notifications via the website. Also, the ETA for new stock is updated on the website.

I'm going to try to get around to trying it this evening.

I tried a delay setting of 5 on my RBION last night, and for me, I think it's too high. The biggest thing that jumped out at me was that a blinking continent insert was just barely pulsing, and you had to pay fairly close attention to tell between that and a fully lit one.

It could be dependent on the type of LEDs as well, but for my preference, in my machine, I wouldn't set it that high.

Thanks for the heads-up. I hadn't caught that those TSPP inserts were missing from the file when someone sent it to me. I just updated the archive on the website, so they will be included from now on.

Any "extra" stuff in the bulbs will make it harder for the OCD to control the brightness because it will have less direct control.

If you want to stick with Cointaker, I'd recommend trying the regular "Frosted" or "Super":
http://shop.cointaker.com/category.sc;jsessionid=80DCBBAB7FFDD906B2D4D40D9CCE7CCD.m1plqscsfapp05?categoryId=6
http://shop.cointaker.com/category.sc;jsessionid=80DCBBAB7FFDD906B2D4D40D9CCE7CCD.m1plqscsfapp05?categoryId=60

I prefer to get most of my bulbs from Comet. 90% of what I used is the 5050 SMD Frosted:
http://www.cometpinball.com/product-p/1smd5050.htm

If you need more brightness, 4 SMD Supreme:
http://www.cometpinball.com/product-p/4smd3528.htm

The only thing at risk by doing this is your LED bulbs. All the other components can easily handle it. Even the bulbs are a bit of crapshoot when it comes to the correct maximum setting. The resistor inside the bulb will determine how much current flows through the LED emitter, and there is no standard resistor value across different vendors, or even different bulbs from the same vendor. The default setting is a conservative value, and usually can go higher without any problems.

Since it would be part of a matrix running at 250 Hz, there is no way to make a single bulb continue to receive power. It HAS to turn off so that the next column can turn on. You CAN try to limit the cycle resetting by keeping that single bulb's duty cycle longer than others. For example, try a ramp something like:
0 0 0 0 100 100 100 100

It might still reset, but this would at least keep it on as much of the time as possible in a matrix configuration.

Any changes made to the downloadable software are limited to the PC software. It doesn't update anything on the board, so the game will always work the same unless you replace the microcontroller with one that has different code. I hope this doesn't have to happen since it would be a major pain to mail out new chips.

As far as critical updates to the PC software, I would suggest using the latest version. If you're not experiencing problems, like data files not being read properly, etc. you can safely use the version you already have, though. The changes are almost always minimal and they will never be able to affect the boards function other than letting you set the values differently.

The first thing I'd try would be to set B8 to 85%. Settings as high as 100% often don't allow enough time for the transistors to turn off fully before switching to the next column, causing ghosting.

What is the "Eye of Sauron TV Ball mod"? Anyway, try using the manual mode to set it to 100%. If it still blinks, there will be no settings that can fix it. Some special bulbs and mods do not work well at the higher refresh rate, and there's not really anything you can do about it.

It makes it take longer between switching from one brightness level to another, basically slowing down the fade time. If you have a bulb that is not blinking, it will have no affect.

So, the Palantir that Jay makes. There's a lot of different versions of it, but the one I had looked great. It flickered (like the other insert lamps) without an OCD installed, but looked great with the OCD. Nothing I would call blinking in either case.

The Williams/DE PCB is 3.35" x 5.8"

There is not really a wait list any longer. You can sign up for notifications via the website to receive email when I add to inventory.

I received my shipment today, and I will be doing final assembly and test on them over the next few days. I'll probably be shipping the first ones out on Saturday (hopefully). Whether or not that gets it to Ottawa in time, I can't be sure.

50 boards, but I have limited cable sets. More cables are on order, but it's going to be a while on those. I can build some cables myself if needed, but that really eats up my free time. I'm planning to see how quickly these go, then adjust accordingly.

That's what this thread is supposed to be, but it hasn't really caught on; probably because there's not an easy way to attach files or a place to put them.

BTW, having a file won't bypass the need for a Windows computer. You still need a Windows computer, or at least a Windows VM / emulation.

Were you signed up for notifications of the boards or the cables? I just happened to think that some people may be signed up for cables, and I only sent notifications to the board list. I have yet to be able to figure out how to view the lists within Zen Cart, so I can't look up who is on a list OR which lists a customer has signed up for. I get aggravated every time I start looking up how to do it.

Anyway, the notifications did work, or at least partially did, because the orders started rolling in just after the most recent notification I sent. Also, I regularly get emails that come through the website contact form, so I'm not sure why I haven't gotten yours.

I'm not sure I would say the premium LEDs are the problem, but they definitely don't work as well as plain LEDs. I assumed you would have a few plain LEDs lying around to try, and it would be a quick test. If you don't have any, trying other things to narrow the problem would be worthwhile.

Here's what we know so far:

1. It's only two lamps, so it's not a dead transistor (or any other parts on the board).
2. You have told me that you made no changes to the configuration, but you also said you set the brightness to 8. I would like to be able to verify the configuration by reading the settings from the board, then taking a screenshot.
3. You said "I did the manual test on each of those sockets and confirmed they were getting juice." You are referring to the manual test built into the LED OCD software, correct? Does that mean you used a DMM to test the sockets? Did they light up? I hate to ask such obvious questions, but without being able to see anything, I need precise answers to be able to narrow down the problem.

Putting the board in passthrough mode will cause the lamps to be flickery, but it will also make the matrix timing match what the game normally does. If that makes them light, it's almost certainly due to the premium bulbs.

There's things we can check before resorting to buying new bulbs, but honestly, the boards really do work best with the plain LEDs rather than using premium.

I thought the same thing, but beelzeboob sent me a screenshot, and the settings are fine.

It's not a power issue. Other lamps in the same column and in the same row are working fine.

My most recent thought is that it might be a cracked solder joint (or two) on a lamp board or a broken wire at a lamp socket.

Oh, and as for why the dimmer LEDs might light. If it is an intermittent solder joint, it may be making contact for a very short period of time that is long enough to light the dim bulb, but not a bright one.

...and it only took me about a half dozen guesses.

I was playing Scared Stiff last night, and everything was fine. I forgot it on overnight , and when I woke up this morning, I had lamps that weren't lighting (cracked solder joint), flashers that weren't lighting (blown fuse), and the spider wheel backbox plastic was peeling off (crappy spray adhesive I used on the repro I recently installed).

That's awesome! I had thought it would work, but until it was tested, I couldn't be sure. Thanks for the feedback.

The boards are in now, and I just need to finish testing them. They will be ready by December 1 or maybe a day or two later.

Unfortunately, like pezpunk said, it does not affect flashers. They are a different type of circuit. I use incandescent flashers in nearly all of my games.

I sold my Getaway before I designed GI OCD, so I never switched it's GI to LEDs. My suggestion would be to try some LEDs in it and see how you like them. If you decide it's too flickery, then you can think about whether to get a GI OCD, turn off dimming, or keep incandescent.

There's a setting in the game menus, something like "Allow GI dimming". Make sure it is on. If so, and it's still OK, I wouldn't bother with a GI OCD. If it's off, turn it on, and see what things look like.

1. A while back, I sent a GI OCD to Bill Ung, and he was working on a compatible chase lamp board. He told me he had something that was basically working, but I haven't heard much since then. You could probably move those lamps into the normal GI, but you'd lose all the "chasing".

2. When you send settings, they are temporary unless you save them. Just click the "Save" button once you have it working the way you want.

I'm not sure if all 8 levels are used. You may have already done this, but try turning on advanced mode so that you can change the intermediate values.

Yes, even without GI OCD, 7 and 8 are both solidly lit, so there's no way to interpret them differently.

As for why they might change when the game starts, do you have the "Activity" checkbox for that string checked? If so, it will use the bottom row of values while the game is being played.

I know Pezpunk has one in his STTNG.

Even when using the test menus to control the GI brightness without a GI OCD, B7 and B8 are the same. The machine keeps the TRIAC turned on all the time for both. As a result, GI OCD interprets both as B8. There is no way around it.

One quick note on this. Running at 99%, you are over-driving your LEDs somewhat. The rectifier on the GI OCD converts the game's AC input to about 9V DC. If you're running at 99%, you basically running your LEDs at a full 9V. They're probably OK, but they may end up failing sooner than they would otherwise.

I'm in no hurry, but the guys with CFTBL might be.

Sorry, but no. There was a bit of a "run" on them last week and more were purchased in one week than in the previous three months.

I estimate February for the next batch to be ready. They'll be on the website when they're in stock.

Hey, I just happened to think that Comet Pinball might have a few in stock.
http://www.cometpinball.com/Stern-LED-OCD-Board-p/ledocdstern.htm

Yes, passthrough is only available on the Williams/DE boards. It is not possible on the Stern boards the way it is currently designed.

Detailed instructions are on the website, but here's a summary for a Stern game:
1. Mount the LED OCD board
2. Disconnect 2 cables from the Stern board
3. Connect them to the LED OCD board
4. Connect the 2 included cables to the Stern board where you removed the connectors during step 2
5. Connect the other end of the 2 included cables to the LED OCD board

Other games are a little more involved, but everything will be cables with connectors; no soldering, no alligator clips, no wire splices, etc.

Blinker bulbs are hit and miss. I have a couple in my SS that work fine. Other in my TZ do not. I use incandescent blinkers in it because of this.

I believe is has to do with how the blinkers are implemented, and if they are without power for long enough they reset their sequence. That doesn't really explain why they wouldn't work at 100%, though. Is it a steady 100, or a ramp with a max of 100?

I have recently made an update to the firmware that increases the pulse rate to 1kHz. Believe it or not, I got a message from a guy that could see strobing at 250 Hz! Anyway, I'm theorizing this increased rate might also help blinker LEDs. I have some on order that I'm going to test. The only bayonet one I have works, but I want to fill all 6 spots in TZ.

You can use a mix as long as you don't go over 2A per string. It could probably handle more, but the bridge definitely shouldn't go above 10A. I would have liked to make it so that you could still use a bunch of incandescent if you really wanted, but the amount of current required just made the requirements for the bridge and caps too big and expensive.

There are a lot of variables. LEDs, the game's power, ambient lighting, etc. My brother and I have both owned HS2 in the past. I bought him identical LEDs for his, but I ended up using different settings on his. That's why configuration is important.

This is a stupid question, but I have to ask. The LEDs and incandescent are blinkers, right? An incandescent does have to heat up, so there is a minimum value at which they will work. 100% should definitely do it, though. Similarly, with the LED, at 100%, it is straight DC with no PWM. It should work no matter what LED you're using.

Can you post your configuration? If they're set to a solid 100%, but the blinker LEDs are erratic, something's wrong.

100 to 100 still goes to 0 when string 3 is off. Only "Always On" or manual test will stay on all the time. I don't know about whether they have non-ghosting circuitry in them, but if you're sending it DC and the lamp doesn't blink, it's either broken or you're not really sending it DC in the right voltage range.

Unless you're willing to set it to "Always On" permanently, it's not going to matter anyway. Like I mentioned before, I'm hoping that the new firmware will fix it, but I'm running incandescent blinkers in mine for now.

So, a bit of bad news. The new firmware helped a little, but blinker bulbs still do not work reliably. I even set up a test where I pulsed them at 50 kHz, and they STILL didn't work. It's just not going to happen through a firmware update.

The only ways I've been able to get them to work is to increase the duty cycle to 100% or by adding some hardware to the bulb. A capacitor to smooth the power with a diode to keep the other bulbs in the string from stealing it works. I haven't had enough time to figure out how big the capacitor needs to be. Unfortunately, to make this plug and play, the parts would have to go in the bulbs.

The family's napping, so I had a little more time to work on the blinkers. I have a solution, but it's no cakewalk. I disassembled some LEDs and added capacitors to the inside. Since there was a bridge inside of them, I didn't need the diode any longer, just the capacitor. They're the ones from Comet, so I'm not sure about others.

These are bayonet blinkers, so they're more work than the wedge would be.

1. Desolder the bottom contact.
IMG_4086.JPG

2. Break loose the glue holding the metal base on the bottom and remove it.
IMG_4087.JPG

3. Break loose the glue holding the white plastic ring from the small PCB and remove it.
IMG_4088.JPG

4. This is a 1uF surface mount ceramic capacitor in an 0805 package. It is just the right width to be able to reach the DC output pins of the bridge.
IMG_4089.JPG

5. Solder it in place.
IMG_4090.JPG

6. Reassemble everything, using glue to secure everything again. Sorry, no pictures of this step.

I modified six of them and put them in my TZ with GI OCD. I can now drop the brightness down to 1% and the blinkers still blink.

As you can see, however, it's a bunch of tedious work.

Have you tried the procedure at the bottom of this page?
http://ledocd.com/usage_led.html

The only way I can think of that it would actually be running through the entire lamp cycle twice as fast would be if the "delay" was set to a lower value. More likely, you are seeing some artifact of the dimming that SM does on those inserts.

If you go into lamp test in the Stern test menus, do you see the same thing? Could you post your settings?

As long as you're willing to work on it, I don't let things go very easily. Having outstanding issues bugs the crap out of me. Trying to narrow down what's happening without seeing it is very difficult, though, and everyone describes things differently.

Are you saying that you see a different ramp rate on certain inserts during attract mode, even if all of them are set to the same profile? Does it only do it after changing those inserts? Are the "delay" values of the two profiles the same?

Finally, copying the values from the example exactly will not give you the best results. Those are specific to the type of LEDs used in the test game. If default 7 works well for your LEDs, start with the default 7 values, then make the B2/B3 pair and the B5/B6 pairs match.

Like this:
6 Modified 10 25 25 40 55 55 70 85 2
7 LED 85% 10 20 30 40 50 60 70 85 2

Rather than continue to tie up this thread, I'm going to send you a PM. Basically, I'm not sure what you're seeing at the moment, and the questions I'm asking are an attempt to narrow the problem down.

That sounds like my idea of hell! I talked briefly with Art about it, and he didn't say no. He didn't say yes, either. I'm guessing that the number of these that would be used is not high enough to make ordering a batch of them worthwhile.

The capacitor I used was a Yageo CC0805ZRY5V8BB105, but that's only because I had them on hand. The only thing that really matters for this use is the size and value.

Cool. Where did you buy them?

Williams/DataEast LED OCD - 5.8" x 3.35"
Stern LED OCD - 4.95" x 3.55"
GI OCD - 6.0" x 2.225"

Assuming you're planning to use the customization, don't forget to leave room for the USB port.

It's coming along slowly. Most of my progress is documented here:
https://pinside.com/pinball/forum/topic/leds-in-capcom-games#post-2550560

In summary:
1. There are two kits made by hacking up a couple of the kits for Williams games that are running in a BBB and a PM. The owners of these games say these are working well.
2. There is some video of the BBB, and it is posted in the above thread.
3. I have preliminary video of the PM, but the owner says he will shoot some new video of the game after I made a couple of changes to the firmware.
4. A prototype board that combines the two controllers into one smaller design is in process. The bare board is being fabricated now, and I have parts on order.

Just Capcom. It requires two controllers to handle the two matrices, and having two separate boards in this case only adds complexity. The only other boards that could be combined would be a LED OCD/GI OCD combo for WPC, and not everyone wants both.

As for shrinking them, I don't see much incentive for it. For Capcom, I tried to make it small to fit closer to the driver board, hopefully eliminating some cabling. For WPC, it would never fit close enough to the driver connectors, and Stern already does.

Just to clarify, the bridge is fine. You can use "AC" bulbs with no issues. It's the filter crap that keeps LED OCD from working at it's best.

Depending on your current results, that might be overkill. You will get better results if you do, but how much better is somewhat variable. If you are happy with how it looks now, it's probably not worth spending all the money and time to replace the bulbs. You could install a few easy to reach "dumb" bulbs to compare the difference. You could also use the manual mode to see how your bulbs react to low brightness values.

I'm starting to wonder if a video showing the difference between the bulbs and how to use manual mode would be helpful. This question comes up all the time.

Nice video! Do you mind if I link to it from my website?

Not available.

Working from memory, I'm thinking Kiss looks pretty good stock. Granted, I was a bit tipsy last time I played it.

BTW, good to see you back Boob.

No, nothing for Pin2000. Maybe I can take a look at it after I get some other projects under control.

One thing I learned from designing the one for Capcom is that doing it without having access to a game is a total pain in the butt. You have to have someone on the other end that is totally dedicated to making it happen, and even then, it will take WAY longer. I have too many projects going right now as it is, but once they settle down, I will look into it a bit.

Well, call me the worst salesman ever, but "need" is a strong word. The PBB kit will work, but depending on how particular you are about how it looks, you may "want" an LED OCD to go with the kit. It will look better with LED OCD, but I don't want anyone buying on false pretenses like thinking the PBB kit won't work without it.

For stuff that you want to blink fast, and the LED OCD defaults oversmooth the blinking, you have two options.

1. You can reduce the delay value. This will allow it to move from one brightness value to the next more quickly.

2. You can change the ramp shape by decreasing the low-mid brightness values (B2 and B3) and increasing the mid-high brightness values (B5 and B6). You can take a look at the Iron Man file in the software archive for an example of this.

Just taking someone else's settings probably won't get you where you want since it depends on your bulbs max brightness, your ambient lighting, personal preference, etc. If you can make it too dim or too bright, what is keeping you from picking something in between? If there's not a profile in the defaults that is exactly what you want, just modify one to make it what you want.

Since this is an opinion, it's debatable, but I will add that when I owned LOTR, I kept incandescents in it. This was after trying a number of different LEDs in those white inserts. It did feel a bit dim, but none of the LEDs had the color I wanted.

Sure. Any of that kind of stuff can be sent to admin at ledocd.com. Data files (csv) for games that don't have them are always helpful. Custom settings (xml), please try to let me know what the changes affect. For example, Spider-Man (More blinky during multiball).

Thanks

I would first make sure there is not a big load of some sort on the GI. Like pezpunk suggested, incandescents could put a big load on it, though a few of them are fine. You just don't want to have anything in the range of ~10.

LED strips hanging off the GI can also be a problem.

As for why it would only blow when powering on, there is a capacitor bank that has to charge when the game is turned on, and the inrush current along with additional load on the GI strings could cause this.

One other problem I have run into is LED bulbs that can short internally. I had one that the resistors inside were bent funny, and they could short together with vibration. I blew three fuses and a transistor on my Metallica GI Theater trying to troubleshoot that one.

For TOTAN, there are a few changes that I think help it a bit. Mainly, increasing the fade delay max. When I get the time, I'll post what I used on it.

Here are the settings I used for TOTAN.

1-GI_OCD_4252016_115128_AM_(resized).jpg

LOTR is Whitestar, unless you're talking about an LE, which is a Whitestar CPU with a SAM power driver.

This link is the Whitestar installation page on my website, and I'm installing in my former LOTR.

http://ledocd.com/install_whitestar_r3.html

No, other than additional game data, profiles, etc., the PC software does not affect the performance of the board. The firmware on the board is not able to be updated short of replacing the chip (or using the ICSP header on some boards).

FLIGHT INSURANCE is on the lamp matrix, column 2, row 8, so it can be controlled by LED OCD. If you have found that it IS the lamp itself ghosting and not light leakage from another light source, here's some things to try.

1. Try to notice if it does it at the same time as some other action; a coil firing, a flasher, another lamps validly lighting.
2. Using the PC software, set the flight insurance lamp to a different profile, then set that profile to all zeros. At this point, the flight insurance lamp should stay off all the time. If not, you are either getting "true ghosting", or possibly crosstalk on the wires under the playfield.
3. Try going into manual mode in the PC software. This will turn off all the lamp matrix outputs, and it will eliminate the possibility of "true ghosting" because the adjacent lamps are not lighting.

If you can try those things and let me know the results, it would greatly narrow the possibilities.

A while back, in another thread, bstyles was talking about a bracket to allow the WPC breakout board to be installed without having to make screw holes in your cabinet. Here's a link:
https://pinside.com/pinball/forum/topic/led-ocd-im-sold/page/3#post-2903808

Since then, I bought a 3D printer, and I've designed a bracket for the new System 11 board design. I've spoken to bstyles, and he assures me I'm not stepping on his toes by sharing this. I'm planning to share the STL file for others to print their own. For those without printers, I'm still trying to decide on a solution. I could print a few, but I don't want to be printing them all the time.

Anyway, here's a picture of how it installed in my Whirlwind. I still need to tweak the hole sizes, and then I'll post the files on my website. Unfortunately, due to the nature of 3D printing, the hole sizes might need to be adjusted further for printers other than my own.

LED OCD Mini in Whirlwind using 3D Printed Bracket

I could look at that next, but one thing at a time. Also, I'm not sure what backbox feature I'd hook the bracket to.

Usually, this is caused by an issue with the game's lamp matrix; a bad diode, a short, an incorrectly installed mod, etc. The first step is always to go though each lamp in lamp test and note exactly which lamps ghost and which lamp(s) are lit when they are ghosting. For example, lamp 21 ghosts when lamp 11 is lit. The full picture of what is going on usually shows a pattern that will lead you to the problem.

Feel free to send me an email to troubleshoot.

So much for "one thing at a time". To be fair, I think the Sys 11 Mini bracket is done, short of receiving the nylon screws to mount it. Everything fits with metal screws, so I'm pretty sure it's done. Anyway, here's one for GI in my TZ. I haven't opened my WPC95 games, but I'm sure they'll need different mounting points.

GI OCD in Twilight Zone using 3D Printed Bracket

Here's the instructions and STL file for the Sys11 Mini bracket. The GI OCD bracket(s) will be a few more days.

http://ledocd.com/install_mini_bracket.html

The GI OCD bracket for WPC89 games (and any others with a hinged light panel like Scared Stiff) is on my website now:

http://ledocd.com/install_wpc89_gi_bracket.html

I still need to open my AFM to look at mounting options in a WPC95 game. From what I remember, there's not much available to hook to. A flat back on the bracket and a big piece of double-sided tape is an option, but I hate using adhesive to attach them.

The default settings work for any game. There is nothing game specific that gets saved on the board.

I don't want to be printing a bunch of them, but I have added them as an option when purchasing boards. If you have already purchased, but would like a bracket to go with it, just send me an email via the website or a PM.

I don't know how widespread it is, but the libraries around here have printers, and they will print stuff for the cost of the filament. That's way cheaper than I'd be able to make them for.

They will be an option for additional cost. I have only designed brackets for the LED OCD Sys11 Mini and GI OCD WPC89 so far, but those ones are available as options on the website now.

A bracket for GI OCD in a WPC95 game is up now:
http://ledocd.com/install_wpc95_gi_bracket.html

I ship them with 1A fast blow installed, which is very conservative. It can be increased if needed.

I shipped them that way since it's protects the board better in the case of a short, and I wasn't sure about what the new design could handle until I had more time with it.

I would suggest using the lowest value you can, at least until I can do more testing. With that said, a 2.5A is probably safe as long as you don't short to 50V. In that case, however, it might not matter how low the fuse value is. You might still damage it.

Paul,

That doesn't sound like settings or bulbs will fix it. It sounds like it isn't properly synchronizing to your driver board. Is it running Bop 2.0? I also wonder if your driver board is stock or an aftermarket. Maybe you got a bad set of cables. Send me an email, and we'll get it worked out.

Email sent.

It will work on IMVE. Just remove the small resistor terminator board first, as you mention.

TWD Prem/LE is a no-go. It uses the newer sytle serial lighting rather than a lamp matrix.

It's totally different than what they did for IMVE. For serial LED games, they have different effects entirely since their control is completely different. The serial LED games all support the same fading, but in the early ones, they did not do such a great job of driving them, and there is more flicker in those games than later ones.

It's theoretically possibly to capture and redrive the signal, but it would be a completely different approach than the current LED OCD for lamp matrices.

Yes. See the note at the bottom of step 6.

http://ledocd.com/install_sam_r3.html

When you say "wasn't thrilled", what kind of problems are you seeing?

The IM settings I use on my game are in the archive at http://ledocd.com/software/led_ocd_v1.9.0.zip. Just use import and browse to the "settings" folder.

Glad to hear it. I am going to do some more testing with incandescent and the new design, then most likely increase the value of the fuse that it ships with.

Correct.

From what I understand, the only version in TWD Pro would be a dumbed down version that plays nicely with LEDs. This would be analogous to the new IMVE lighting. I would assume the latter, just smoothing and slightly dimming.

Yes, I have ran it on Windows 10. .NET 4.5 and 3.5 are independent versions, and the LED OCD software is compiled to use 3.5. Allow it to install, and it should work fine.

I'm pretty sure that when I did it, it automatically downloaded and installed it. You could try manually downloading it:
https://www.microsoft.com/en-us/download/details.aspx?id=21

Sorry, but no, there's not. I don't think it would be practical to build and be able to install. I would actually like to see a flasher bulb with smoothing built in.

Someone may have used it and could speak from first hand experience, but I can say based on the design that it will work fine with LOTR.

The GIzmo is completely passive. It's just a bridge and some capacitors to convert to DC and slowly discharge. Removing either of the jumpers disconnects one of the capacitors so that the others discharge faster, causing the LEDs to fade off more quickly.

There are multiple places you can get them now.

Direct from LED OCD - Lowest price, and I get the biggest cut, if you care about that. I can't ship internationally, though.
Comet Pinball - Great choice, and you can buy your LEDs at the same time.
PSPA - Australian source.
Pinballshop.nl - Netherlands source with a wide selection of our kits.

I would suggest against the Premium in particular. Non-ghosting can hamper the LED OCD from doing it's thing, and CT Premium are a bit more troublesome still. If you can get the standard CT kit, that's your best bet.

Yeah, those diodes have to be in the circuit. I'm glad you found the problem.

I would say it's unlikely the missing diodes caused the transistor to fail. Usually, that just results in lamps lighting incorrectly.

Not using any of the currently available LED OCD boards. The lamps are controlled using a completely different method.

1. No problem. The flashers are untouched by the OCD boards.

2. I have not tested with Afterburners, but I have used the Comet equivalent
http://www.cometpinball.com/Pinball-Pop-Bumper-LED-Light-p/11smdbmpring.htm
The other difference is that I used them with LED OCD, not GI OCD. I did not notice any abnormal operation.

Looking at the parts on the Afterburner boards, it looks like they're simply a bridge, a bunch of LEDs, and the current limiting resistors. Basically, that's no different than a normal LED bulb. They should be fine, from what I can tell.

I have seen a few cases where the GI OCD power switching (1kHz) can lead to audible noise. I could send you a modified firmware that switches at 250 Hz. It might help, but it might also just change the noise to a lower pitch, or even do nothing. It also would make it a bit more likely that you would see strobing if your eyes are more sensitive to it than the norm.

If you're interested in pursuing it, send me a PM.

I'm wondering if I might get a bit of feedback on something I've been working on. To this point, the configuration software has been limited to Windows machines. I decided to write an alternative.

The first part of this is a command line application that can do nearly all of the same stuff as the Windows version. I'm testing on Linux running on a Rasp Pi, but it should work on any Linux machine, and probably Macs as well. Of course, it would have to be compiled for the target system. Anyway, here's a sample of what it can do:

ledocd@ledocd:~/projects/ledocd_cli$ ./ledocd_cli
Capcom detected, but matrix not specified. Defaulting to matrix A.
Use -m CAPCOMB to communicate with matrix B.
LED OCD Firmware v27
ledocd@ledocd:~/projects/ledocd_cli$ ./ledocd_cli -m CAPCOMA -c READ | grep 23
L23P=7
ledocd@ledocd:~/projects/ledocd_cli$ ./ledocd_cli -m CAPCOMA -c SETLP=23,5
ledocd@ledocd:~/projects/ledocd_cli$ ./ledocd_cli -m CAPCOMA -c READ | grep 23
L23P=5
ledocd@ledocd:~/projects/ledocd_cli$ ./ledocd_cli -m CAPCOMA -c READ | grep NAME
P1NAME=Incandes
P2NAME=LED 25%
P3NAME=LED 35%
P4NAME=LED 45%
P5NAME=LED 55%
P6NAME=LED 70%
P7NAME=LED 85%
P8NAME=LED 100%
ledocd@ledocd:~/projects/ledocd_cli$ ./ledocd_cli -m CAPCOMA -c SETPN=8,Smooth
ledocd@ledocd:~/projects/ledocd_cli$ ./ledocd_cli -m CAPCOMA -c READ | grep NAME
P1NAME=Incandes
P2NAME=LED 25%
P3NAME=LED 35%
P4NAME=LED 45%
P5NAME=LED 55%
P6NAME=LED 70%
P7NAME=LED 85%
P8NAME=Smooth
ledocd@ledocd:~/projects/ledocd_cli$ ./ledocd_cli -m CAPCOMA -c READ
P1NAME=Incandes
P1B1=30
P1B2=40
P1B3=50
P1B4=60
P1B5=70
P1B6=80
P1B7=84
P1B8=84
P1DELAY=0
P2NAME=LED 25%
P2B1=4
P2B2=7
P2B3=10
P2B4=13
P2B5=16
P2B6=19
P2B7=22
P2B8=25
P2DELAY=3
P3NAME=LED 35%
P3B1=4
P3B2=8
P3B3=12
P3B4=17
P3B5=21
P3B6=26
P3B7=30
P3B8=35
P3DELAY=3
P4NAME=LED 45%
P4B1=6
P4B2=11
P4B3=17
P4B4=22
P4B5=28
P4B6=33
P4B7=39
P4B8=45
P4DELAY=3
P5NAME=LED 55%
P5B1=8
P5B2=14
P5B3=21
P5B4=28
P5B5=34
P5B6=41
P5B7=48
P5B8=55
P5DELAY=3
P6NAME=LED 70%
P6B1=10
P6B2=18
P6B3=27
P6B4=35
P6B5=44
P6B6=52
P6B7=61
P6B8=70
P6DELAY=3
P7NAME=LED 85%
P7B1=10
P7B2=20
P7B3=30
P7B4=40
P7B5=50
P7B6=60
P7B7=70
P7B8=85
P7DELAY=3
P8NAME=Smooth
P8B1=20
P8B2=31
P8B3=42
P8B4=54
P8B5=65
P8B6=77
P8B7=88
P8B8=100
P8DELAY=3
L11P=7
L12P=7
L13P=7
L14P=7
L15P=7
L16P=7
L17P=7
L18P=7
L21P=7
L22P=7
L23P=5
L24P=7
L25P=7
L26P=7
L27P=7
L28P=7
L31P=7
L32P=7
L33P=7
L34P=7
L35P=7
L36P=7
L37P=7
L38P=7
L41P=7
L42P=7
L43P=7
L44P=7
L45P=7
L46P=7
L47P=7
L48P=7
L51P=7
L52P=7
L53P=7
L54P=7
L55P=7
L56P=7
L57P=7
L58P=7
L61P=7
L62P=7
L63P=7
L64P=7
L65P=7
L66P=7
L67P=7
L68P=7
L71P=7
L72P=7
L73P=7
L74P=7
L75P=7
L76P=7
L77P=7
L78P=7
L81P=7
L82P=7
L83P=7
L84P=7
L85P=7
L86P=7
L87P=7
L88P=7
ledocd@ledocd:~/projects/ledocd_cli$

Next, I have a good start on a web GUI that uses the command line application behind the scenes. This part is a good bit more work to set up, but it's pretty nice once it's working. You have to set up a web server, put the web code in the right places, etc. Then, you can browse to the page from the machine running the web server or any other browser on your network, including smartphones.

A couple of possibilities to make setup easier would be an image to load on a Rasp Pi or a pre-configured VM.

1 (resized).png2 (resized).png3 (resized).png

Now, the questions. Will anyone use this, or am I wasting my time? How would you like to see it distributed?

No, I don't think anyone would leave these hooked up and change settings after dialing them in.

The use I could see would be for someone who doesn't have a Windows machine or no machine that can be taken to the pins easily. You do still have to have a USB connection between the OCD and the host, but the host can be something simple, like a Rasp Pi. I've been playing around with it, and it is nice to not have to lug the laptop down to the pins.

The main issue I see, however, is that it's still a bit difficult to get running. People who are willing to put in the time would likely be able to figure out a way to run the Windows software.

Powering it on with the machine would not be hard, but it's a relatively large load to put on the pin's supply. Putting an additional supply on the AC after the switch would be the right way.

IMO, there wouldn't be much utility in it, though. When was the last time you tweaked one of yours?

If you want to do it, I'll come over; get you hooked up.

I had to look up Docker. I guess that shows how behind the times I am in the area. I'll have to research it more.

This is usually an issue with the lamp matrix in the game, like a reversed diode, a short, an incorrectly installed mod, etc. If you set the brightness too high using the LED OCD, it can cause ghosting, but I set them to appropriate values when they ship.

For LEDs, use pretty much any LED without non-ghosting or premium features. My favorites are:
http://www.cometpinball.com/product-p/1smd5050.htm
http://www.cometpinball.com/product-p/2smd-ct-ft.htm

I would recommend going through single lamp test, select a lamp, and noted which extra lamps light, if any. Do this for every lamp in the game. Usually, a pattern will develop that can be used to track down the problem.

That is a feature of that game. The lamps are supposed to get brighter the more times you beat them. If they are too dim, with LED OCD, you can use the configuration software to make the levels brighter.

OK, so they're not just dim, they're flickering? What kind of LEDs are you using? I don't remember how I configured your board, but it is probably using the Spider-Man settings that are included in the configuration software. Those are tuned for standard (not non-ghosting) bulbs.

Untitled (resized).png

In the image here, the red is what it uses after beating the villain once, orange is twice, and green is thrice. A setting of 12 is good for standard bulbs, but will flicker with non-ghosting. 60 at level 2 should be fine, even with non-ghosting, so I'm not sure what's up with that. I need a bit more information to be able to make suggestions without access to the game.

What bulbs are you using?
Can you read what values you're using? I'm guessing not since you had me pre-configure.
Is it only the villains? What about the white spider arrows during combos? Any others?

I've dug into Docker enough that I don't see it happening any time soon. It sounds great for the guys that are already using Docker, but given that I wouldn't know what to do with it myself, I'm going to assume that others would find it equally confusing. If anyone wants to prove me wrong by creating the container and teaching me to use it, I'm game.

I did decide to go ahead and post what I have so far. It seems to be basically working. Here are source files, along with a README to help you get it running. It's only working for LED OCD (not GI OCD) for now.

http://ledocd.com/software/ledocd_web_gui.v0.1.tgz

I also created a Ubuntu Server VM and installed the files above. I've tested it to the point that I know the GUI works, but I haven't hooked a board up to it yet. If anyone is interested in the VM, send me a PM. I think I have unlimited bandwidth on my web host, but I'd rather not learn otherwise when I get the bill.

After I get a chance to test the VM, I'll look into creating an image for the Rasp Pi. If you're handy, though, you could use the source files above to get your own running.

If I find that nobody is using these, I'll probably shelve the project and take a nap instead.

So much for that nap. I admire the initiative.

I was going to make an effort to learn, since Docker does seem very useful. Although I would like to, I haven't quite been able to give up my reliance on Windows. I normally run VM's with Linux when I need them. So, I first decided to install Docker for Windows. I found out the hard way that VMWare and Docker do not co-exist nicely. That is a bummer.

Next, I thought I could run Docker on one of my real Linux machines. All of them are still 32-bit. No go, there.

Even though it would be silly, maybe I could run Docker in a VM to learn it? Maybe a live 64-bit, or even find an unused machine to install 64-bit Linux on?

jyeakley , if you think it's useful, by all means, feel free to run with it. The only reason I'm working on any of this is help non-Windows guys, so if you can help provide more options, that's great.

The dmesg step is not necessary. It's simply a way to verify that the LED OCD was recognized and the driver was loaded. If you have a known working setup, you can just click the "Version" button to do basically the same thing.

So, how does that work in Docker? Would the driver be running on the host machine and the Docker image not need any of the serial port stuff included, just file I/O across the container boundary? In VMWare, I can either connect the USB device to the VM, or I can handle the USB stuff on the host and only connect the virtual serial port to the VM.

OK, I got the GUI to work by running Docker inside a VM. It took a few tries because I didn't have access to the docker group, then the port 80 forwarding collided with apache running on the VM. I tried to use --device for the tty, but was unsuccessful.

Am I understanding correctly that once everything is working properly, the image could be hosted on Docker's repository and a single command could pull and run it, like the base ubuntu image can now?

Edit:
Now USB seems to be working. I only have a standard USB serial cable to test with, but it's showing up in the container and ledocd_cli can open it:
docker run -d --privileged -v /dev/bus/usb:/dev/bus/usb --name ledocd -p 8080:80 ledocd/ledocd:20161212

It's possible, but it would be a completely different design. I don't see much demand for it, and I promised myself that I wouldn't try to design another without having a game to work with.

BTW, on the Web GUI topic, I have uploaded an update to my website that can be used with GI OCD as well. I have a pre-configured VM and a Rasp Pi image that are both working and on my webite, but I'm still asking that people send me a message to ask for the URL to download them. I've been successful once, but most of the time, the download hangs. I guess my webhost sucks.

Assuming the Rottendog LEDs are installed with the same polarity as the schematic shows, they will not light. Worst case, you could reverse the LEDs on the clock board.

Edit: I just wanted to mention that the Rottendog LEDs are reversed when compared to diodes in series with the lamps on the stock clock board.