Project Logs

Collapse

• Part Four - Screaming in Digital

  Jason Nelson • 08/17/2025 at 16:27 • 0 comments

  Once I saw patterns in the logic analyzer traces, I began thinking about other reverse engineering projects, and a couple stood out, where I'd found I2C-ish protocols. So I zoomed in and started looking at how the data was being transmitted. At the same time, I wrote some arduino code that was a software I2C slave and would read data.

  Yes, I said slave, because I'd realized from tracing one of my spare board sets that about two seconds after bootup, the plunger chip began screaming out these packets. The timing was close to regular, though not regular enough to be able to build a timing loop, not even in a arduino uno clone doing *nothing* but reading packets. My software slave reported statistics like "number of clock cycles," "0s" and "1s," stops and starts. And my stop/start count was just wrong. Which of course could have been my code (and probably was my code a few times) but as I began looking very closely, I realized data only transitioned *when* the clock signal was high, which is to say, the signal was inverted.

  Flipping that logic gave me patterns I could see change as the plunger moved.

  11 bits per byte, four bytes per packet, roughly 87ms (or 60ms, or 90ms or 80ms) between packets.

  11 bits, I figured 8 bits for a byte, a start bit, a stop bit and a parity bit.

  Masking off bits off of best guesses yielded numbers that rose and fell as I pulled the plunger in and out.

  A few iterations and some code to analyze showed that the first bit was always 1, the last always 0. The second bit, it turned out, was a parity bit. 

  I really expected that last bit to be a LSB because the numbers it output looked "right," but after much futzing I concluded that the output from 0-65, with 65 being all the way out, and 0 being all the way in.

  I also discovered the sensor was picky - it only reads the magnet in one orientation and it needs a very strong magnet to read anything.

  It was time to get something working.

• Part Three - Patterns

  Jason Nelson • 08/17/2025 at 16:10 • 0 comments

  Two years passed. Again, writing this up with functioning software and a knowledge of how it works, this seems ridiculously long but in that time I learned to desolder SMD chips, got a bga 153 reader to dump EMMC chips, dug deep into some weird 3d printer mainboards and generally speaking had a blast.

  But every once in a while, while booting up PinballFX I'd glance at the wire harness leads tucked away and think "I should do something there."

  When I finally did, the first step was to check all my wiring and take fresh samples with both logic analyzers, on the theory that the salae logic clone and the actual one should either show me the same thing or show one of them was wrong.

  They showed the same thing for both startup and "general use traces." Then I decided to see how the chip would behave in some odder situations. I disconnected the accelerometer.

  Immediately the I2C garbage changed, and it changed in recognizable ways, throwing less traffic (1/4 the traffic).

  And I began to wonder if perhaps I was looking at this all wrong and this was some kind of UART style data.

  The logic analyzers quickly disabused me of that. The time periods between traffic weren't regular, the time period between pulses wasn't even consistent, and while I could get relatively close to predicting when a burst of data would come, this wasn't some baud rate I could read at.

  The breakthrough came when I was zooming out and keying down to look at where the traffic sometimes switched to "general write" instead of "general read." I was talking to myself out loud and said "The number of resets isn't even consistent.

  Sigh.

  I turned off the protocol decoders and zoomed out, just looking at the wave forms. 

  There was data there, I'd just been too obsessed with the wiring to see it.

  Yes, I'm aware the decoders are still present, I don't have the original screenshots anymore, these are from the traces. You can see that the clock line is clearly a clock signal, but what you can also see is that the data line is different (and you'll have to trust me it repeats), across the first of four bytes.

  Which mean the SCL and SDA meant "Serial Clock" and "Serial Data" but not necessarily "I2C" traffic. 

• I2C or not I2C (That was the question)

  Jason Nelson • 08/17/2025 at 15:58 • 0 comments

  In hindsight, typing this up, this feels dumb, because now I know exactly what I was looking at, but at the time, having successfully read traffic from the accelerometer, I expected similar success with the plunger.

  I wired up a nice jig that let me hook the logic analyzer to the plunger bus and then ran through a few games where I pulled the plunger all the way out, let it back slowly, and so on. Then I took a second trace from startup.

  What I found was to (then me) baffling.

  The I2C decoder in both pulseview and DSview got very, very confused and showed traffic. And the problem was the traffic was similar to conversations with the mentally ill guy outside the local safeway. It was syntactically correct but didn't make any sense.

  Every 80ms, the bus master would issue a read to the general call address (address 0) on the I2C bus.

  And nothing responded.

  Again, in hindsight, this just hurts to write up, but I KNEW the plunger was functioning and yet the traffic just made no sense. The first thing I thought was "This has to be caused by my wiring. Or I'm not sampling fast enough and I'm missing portions of the conversation." The problem was, when I hooked up known good I2C devices, I could scan them perfectly well.

  That was my cue to bring in the BusPirate, which confused the everloving daylights out of me. It has an I2C scanner built in, and scanning I found components I found reasonable, a GPIO extender and a few other things.

  The results were consistently inconsistent, though. The scanner almost always returned the same addresses but if I attempted to become a bus pirate myself and "speak" to them, the responses made no sense.

  And the entire time, these general call address reads kept issuing.

  This is where past experience burned me badly. I'd dealt with an automotive device before that used  a very similar model, and applied that knowledge (wrongly) here.

  That device had a bus master that would issue a general read and any of the five trinkets attached would respond. So, in that way, the general read (sort of) made sense. I'd already realized the plunger IC was the interpreter for the accelerometer, so it was likely the main board had a polling loop where it said "Where's the plunger at?"

  Except there weren't valid responses.

  Eventually I decided I was spending too much time on a project that I wasn't making progress on, and I shelved it, just playing pinball instead of analyzing it. I left the logic analyzer harness wired in, though. 

  I kept my spare boards, and I kept telling myself, I'll get to it.

• Part One - The hardware

  Jason Nelson • 08/17/2025 at 15:45 • 0 comments

  The Legends Pinball (I think it's called Legends Pinball 'HD', or ALP) is a decent way to get into the world of virtual pinball. It has a ton of built-in tables, it has a decent build and if one excuses the mish-mash artwork, looks good.

  You can buy and download pinball packs that add many well known tables, but where it truly shines is in what they call "OTG," where a PC running PinballFX or PinballFX3 (or M, though I haven't tried it) takes over the playfield (and backglass if you have the board it should have included toi start, the Video Input Backglass something, or VIBS) and turns the RK chip into a glorified joystick and sound system.

  But eventually, those RK boards die. Or they refuse to switch modes and allow you to play OTG. Or they just stop registering.

  When that happens, people say "It's time for a full gut" in which one switches to a 32 inch monitor, rewires all the controls and adds a potentimeter based plunger.

  The plunger kits cost ~50 bucks from Cleveland software design.

  This is how I decided to spend way more than fifty bucks to save fifty bucks. Probably not smart financially but I love a good project and it just made no sense to change hardware that *should* work.

  The plunger is essentially a magnet on the end of the plunger rod and a magnetometer chip that reads how far the plunger is away and produces a signal based on that.

  It has a daughter board that's a MMA8451, though I have three plunger sets and one of them comes with a knockoff that's labled YJ<unreadable> but responds to the exact same responses, so a clone of the MMA8451.

  The plunger IC has four pins coming off it and a separate I2C bus going to the accelerometer. Putting a logic analyzer on the accelerometer showed normal, boring I2C traffic with readings that made perfect sense.

  The plunger IC runs on 5v and downconverts to 3.3v to talk to the accelerometer.

  The four pins running back to the rockchip mainboard are labeled GND, VCC, SDA and SCL (the same as the pins that accelerometer runs on). 

  The bus does not connect between the 3.3v and 5v sides, the unlabeled IC is the only thing speaking to the accelerometer. A LDO on the board generates the 3.3v and a level shifter makes sure the plunger IC doesn't cook the accelerometer.

  Simple enough, so far.

  Then I put the logic analyzer on the plunger, and that's where it got weird.

View all 4 project logs