Good morning,

I have open sourced my Tron disc mod. Documentation is scarce, as honestly I'm abysmal at documentation, plus I lack time

Video of the mod:

Github of the mod: https://github.com/Ashram56/Tron-Pinball-Disc-Mod

Note the licence: this is GPL3, free to use and free for commercial usage, but you are required to give credit, and to release any change (both HW and SW) made to the design publicly, ideally as a commit or a fork of my github.

Questions, feel free to ask

[EDIT]

Given the interest, I'm considering building it, so using this thread to track interest.

At this point, after a quick analysis of the BOM cost and the number of people interested, I will likely end up in the range of $150. Most of it is actually the electronic control board, which I'm outsourcing to another mod vendor, the ever excellent stumblor

Price will be refined once we have a better picture of how many people are interested, and most importantly, shipping and VAT.

Pin_Fandango has offered to act as my North America rep, which is quite cool of him. He's located in Canada, so I will arrange bulk shipping of the parts to him and he can package and ship locally

Here are the interested people so far:

ZEN
Tsunami
dts
ryank11379
Saltimbanco
Sijcolo
ulmpharmd
tdiddy
Eagle14
snakesnsparklers
Mank
matlynch91
KYmanyfacedgod
Jecco74
roscoepinball
barakawins
tatman9999
thepinballworks
Flash71
vader1979
visualmagic
gprotein
FtrMech
digitaldocc
chrishoyle99
bchron
roscoepinball
TheBaron
FtrMech
ray3127
megalo17
TG
Faust
PlayPin

and of course Pin_Fandango

I'm opening the list for interested people at the top of this thread

Just an update, most (if not all) interested pinsiders are currently in North America.

I will come back after Christmas break with a detailed plan. Still need the electronic control board, it's not ready yet as stumblor is quite busy on his own mods. My own control board, as designed, is not really suited for wide scale deployment.

It will not be directly Lollypop, although likely a derivative.

Currently the mod simply takes the relay for the motor as an input (ie direction and operation). There are three states, idle, clockwise, counter clockwise. I have yet to determine with stumblor what type of flexibility we would want to add, and if it makes sense.

To clarify:

- I'm using clear silicon rubber for the disc, to better see the effects. Although conceptually, when you take a look at the disc itself, the ledring is beneath the acrylic part and is not obstructed by the dark silicon rubber. I prefer the transparent rubber myself, still need to discuss with Pin_Fandango on the best approach

- I use both relays triggers as an input, through optocouplers, connected to a small microcontroller. These are easy to detect, because they are directly driven through the power board. Detecting switches and opto have always proven to be more complicated, because of the way the switch matrix operate, so I'd rather stay away from this.

I'm discussing with stumblor for a custom Lolly derivative, as he has the manufacturing experience with it. Conceptually the design is relatively simple, but manufacturing it and ensure it's reliable would require spinning my own design (need to add rectifiers, etc), and frankly for 20+ units it's not really worthwhile. It does increase the mod cost obviously, but you'll get Stumblor board quality and flexibility (especially for the lighting effects).

I can even discuss with him about adding I2C input for additionnal external control units (which I'm working on separately, I have something in plans to read all output from the CPU board to the power board)

My HW schematics were not on the github? Shame on me.... I'll add them.

There's no magic anyway

Just one question : I don't see any opto coupler on your board, did I miss them?

If they're not there, I really really strongly advise to add them.

EDIT : ah unless the opto is U1?

I also see a rectifier (I think), is this for power or to detect GI (or both...)?

My design uses a wemos, but you can actually also use an ESP12F module, which can be soldered by Jlcpcb. Super tiny.

Updated list

Just as an update, I've been caught up with other mods development (yeah, it never stops), so I'd like to get feedback on how to proceed:

- I can use my existing design (or a slight derivative so it's more robust), or even Tekman design if he's ok to share (my design is probably very close anyway), launch a 20 units build and call it a day
- I can use Stumblor modified Lolly version. More expensive, but more flexible and very robust. But needs a little bit of time, Stumblor is in the middle of his UFO run for GZ, so it's taking a lot of his time
- I can decide to skip the current version of the controller board altogether, and go for another controller I'm currently working on: it's an interceptor unit that sits on the control bus between the CPU board and power board, and interpret data, so it can read inserts/flasher/coils status. Which means it can also trigger the disc to additionnal patterns reaction. The same controller unit will be used to control fiber optics

This third option has my preference, but it requires SW development (HW is almost ready, I'm going to send it to production), so it might take some time.

Let me know your preference

Cheers

Thanks for the feedback on the shaft screw. Yes I had the exact same issue, so I removed the rubber completely. Did you run into issues (glue residue for ex) ? In my case I had not bothered, I had simply acquired a new disc

It's good to see that even with black rubber it does stand out nicely.

On the connection diagram, I'm a little bit unsure I understand, can you share a block diagram.

Both relays have a drive and power signal. But you don't need to connect the power signal, what I did was connect the positive input of the opto to a common 5V or 12V rail (common to the entire machine), and just connect the Drive signal of each relay I want to the negative input of the opto (which allows to use alligator clip directly on the relay itself). GND has to be shared between the controller board and the machine for this to work of course (which is the case since I use 5V supply from one of the 5V supply to one of the opto board).

I'm indeed working on it, for no other reason that I don't have an Eli mod so I'm really missing something. I do have fiber optics installed, but they are not interactive (colors just cycle)

I have absolutely no idea if it will work with Eli's mod, since I don't have one... If you can send a picture of the wiring from the main control unit to the fiber emitter (especially the number of wires) I can probably make an educated guess, but that will be just that, a guess

But just to put things in perspective, as I don't want to overcommit on something above my skills:

- Eli did a tremendous job on the SW side. His configuration web interface is very nice, but not only that, it relies on detecting events which are hard to detect (since he does not detect switches, he has to infer from the light status). Things like detecting from blinking to solid for ex. It's really not straightforward to achieve.

Unless I subcontract the SW development to someone else, there's no chance I can reach that level of integration. HW will be capable of it, it's writing the SW that will be the issue.

So whoever has a functional Eli kit, stick with it, unlikely anything can get better in the short/middle term.

- It is going to take some time. I launched a batch of 5 prototype board, and need to develop SW. And as in any embedded design project of significance, SW is 90% of the work, if not more. I'll keep this thread alive to provide an update on how this is moving forward.

Cheers, and enjoy pinball

Truth be told, that's also something I've been looking at, but it's actually harder to implement (so kudo to Compy for doing it)

1/ You need to decode DMD frame. This is not as easy as decoding a parallel bus like the CPU-to-Power board bus, as DMD data is actually serialized, and protocol is dependent on the architecture (WPC, SAM, Spike, etc).

There is an open source Teensy based implementation, but I don't think it has been maintained and I presume a lot of work needs to be done to make it work with SAM timing.

This is what Compy uses actually (you can recognize it because of the Teensy), but he did invest into making it work reliably

I actually have an SPI based code running as well on a Jetson Nano for that on Whitestar, but it's far from being ready

2/ You then need to identify frame to trigger an event, which would seem to be easy, but remember that you have variable content (score data, etc), so you actually need to have multiple masks applied to each frame relevant to each trigger, and you need to define them. There are actually database of this nature available on various virtual pinball forums (look up PuP Packs), but still needs to be implemented

Also, you can't really detect switches with just the DMD, they are not necessarily always displayed.

So way harder than it looks.

It's also a different set of SW skills : writing a logic analyzer type SW requires essentially microcontroller expertise, whereas writing code to match frame with mask and playback videos or send commands is more higher level (gstreamer type).

It's however the only method to reliably detect game mode (ie various multiballs for ex), and the potential is quite high.

In any case, it's SW again... HW is easy.

I really wish I had paid more attention to SW in my early days...