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.