Well well

Looking at various widths of ones and zeroes that I had captured, I settled on a 220 uSec. bit width, clocking it with a timer. It was an ugly hack

1. Wait for 150 mSec. of zero
2. Wait for the rising edge
3. Wait 1/2 of a bit width
4. Capture the first bit
5. Start the 220 uSec. clock
6. Capture the next bit when the timer has elapsed
7. Repeat step 6 until all 32 bits are received
8. Send the value to the PC

Before long, I added some ANSI terminal control values to the data to format the captured data. Only one value appeared to change. I don't have many of the notes I made during this time, so I'll skip ahead a bit. Eventually I worked out the bit order and whether, or not, to invert the incoming bits and that considering the data as two 16 bit values made the most sense.

The upper 16 bits are in the range of 0x9001 to 0x9012, while the lower 16 ranged from 0x45 to 0xffff. Only the value attached to 0x9011 varied over time, hovering at about 0x9a0. That happens to be 2464, 10 times the phase to phase voltage that the pump is connected to. Not much happened until the well pump turned on while I was working on this project. While the pump ran, 0x9010 and 0x9012 were also changing. My antique clamp-on AC ammeter showed about 11 amps while the pump ran, while the number reported by the monitor was bouncing around 0x450. Looks like these are the operating current values, though scaled by 100.

Knowing voltage and current and being able to detect the running time, there are a number of faults that can be detected. I must build something! But first the software controlled timer needed to be improved, it would generate 33 interrupts for each incoming value. I'd like to save some CPU cycles for other uses, could I use the SPI interface to collect the data? I'll need a clock source. A bit of re-wiring the Z8 dev board and rewriting code reduces the load to just 5 interrupts per incoming value, much better. The IR detector is now connected to both the SPI data input and a GPIO pin and a timer's output is connected to the SPI-CLK, watch what hppens

1. Configure a timer for a 220 uSec. period and preset the timer count to slightly less than 110 uSec.
2. Wait for 150 mSec. of zero
3. Set and enable the GPIO to interrupt on a rising edge
4. On the GPIO interrupt, disable the GPIO input, enable the timer for continuous operation
5. SPI receiver will interrupt when it receives a byte, store it
6. When the fourth byte is received, disable the timer and preset the count to the value used in step 1, re-enable the GPIO interrupt
7. Since we are waiting for the GPIO interrupt, the main loop is free to process all sorts of things.

With 10 seconds of data, there was a lot of horizontal scrolling to do.

Shown above is the first pattern to emerge, a 154 mSec. gap followed by two 137 mSec. gaps. A small code change to the digitizer and it waits for a 150 mSec. gap before it starts capturing data. Breaking the capture on the 154 mSec. gaps, then stacking the pieces another pattern appears. This time, every 60th cluster of pulses contains a 4.56 mSec. logic high.

Here is a closer look

Every block looks to start with the same double spike and gap pattern, could that be a preamble for Manchester encoding? Days of toying with this idea yielded nothing but decoding errors. Also, assuming the preamble represented four bit durations, the data lengths appeared to be about twenty bits. How odd.

The breakthrough came when I split the data on 10 mSec. gaps and stacked those segments.

Supposing that the starting pattern is 4 bits, then each line ends up being 32 bits wide. That sounds more reasonable.

This section spans about two months of work. It took that long because I wanted to get the job done with the tools that were on hand.

Without going in to excessive detail about the reasoning, I picked a Z8 dev board to take the first look at the signal. Over the course of a few weeks, my code went from a for(;;) loop watching an I/O pin to two timers linked to the DMA controller. In the end, the latency and resolution were both reduced to a single clock cycle. I used the "gated" mode of the timer, one timer running while the I/O pin was at the high level and the other running while low. The timer's interrupt would be triggered when the timer's gate signal went to the inactive state, or when the timer reached its' stop value. Also, at that moment, the timer's count value would be stored in the DMA buffer. When a DMA interrupt triggered, the buffer's contents would be sent to the workstation via RS-232. There's a race-condition or two, but there are also periodic 150 mSec. pauses in the input signal, so there should be adequate time to transmit the bits. Now what?

My first step was to convert the clock-cycle counts into something I could display in GNUPlot, but seconds of data with 50 nSec. resolution became unmanagable. Enter PulseView and VCD file format. With a little bit of Ruby to convert the captured data to an acceptably formatted VCD, I can finally begin reverse engineering.

You've probably read that photo-transistors are slow to respond to an input signal. Try it sometime, setup a 555 to drive an IR-LED at about 1kHz and a 1k resistor in series with the transistor. If you are quick enough, you could count one Mississippi, two Mississippi...

OK, not really. Still, the transistor I grabbed needs help. Let's try a cascode, but not just any cascode, a folded cascode. Why this configuration? It will operate nicely on the 3.3V supply used by the microcontroller and provide a logic level signal to the processor.

This is the circuit

as it stands today, though I still twiddle with it from time to time. A pending change is to use a 2N5087 in place of the A733. In the past, when I had 20m of cable between the circuit and dev board, there was an emitter follower on the output. (This was just a quick sketch, I should have checked annotations.)

Infrared does not normally rank very highly on my list of things to do. Suddenly, it is at the top of thay list. Confirimg the presence of a source was easy enough, I pointed a cellphone's camera at the control box, to discover a fairly bright, but flickering, light.

Digging around parts bins and junk boxes I find a selection of both photo-transistors and photo-diodes, but which to use? The transistors out numbered the diodes by a fair margin, so transistor it is. Taking a peek inside the monitor's case revealed a PIC16 microcontroller which was driving the IR LED via a single transistor. I'm guessing that maximizing the data rate was not a great priority for the manufacturer.

The first test was simply the transistor in series with a resistor, with a pair of AA batteries to power it and an oscilloscope to see the result. Well there was a square-ish wave, but I couldn't get my analog, non-storage, scope to lock on to the signal.

Let's digitize it!