Ok so I just went from being totally stuck and posting that blog post, to being unstuck in about 30 minutes. Ok, so in the last post, I was thinking I needed to figure out what the bit encoding was for the pulses coming in. WHen you look at the in a long row, it's hard to see the patterns. So I was reading the man page for mode2, and it says there's another command line switch called --mode, which is helpfully described as " enable alternative display mode". Ok, what could it hurt right? So I ran it. Instead of getting the two column pulse/space list, you get a more helpful:
6700 650 900 700 900 700 900 700 900 700 900 3150 900 3150 900 3150 900 750 850 750 850 700 900 700 900 700 850 700 900 700 850 750 850 700 900 700 900 700 900 700 850 750 900 3200 850 700 900 3150 900 700 850 700 900 700 850 700 900 700 900 700 900 3200 900 700 900 1382500
Which is a lot easier to read, and makes deltas between two different settings stand out. That one was a blue, this one is a red.
6700 650 900 700 900 700 900 700 900 700 900 3150 900 700 900 700 900 700 900 700 900 700 900 700 900 700 900 700 900 700 900 700 900 700 900 700 900 700 900 700 900 700 900 3150 900 700 900 3150 900 700 900 700 900 700 900 700 900 700 900 700 900 3150 900 700 900 2267300
Notice how C2 R3 and C4 R3 change from 3150 to 700? That pattern holds for yellow and green as well. You end up with a pretty simple table:
If you count the spaces as clock ticks and the pulses as 'bits' you can then start to map things out. The last huge number in C6 R11 is the time between the last event and the next event. The last event recorded does not have this value, it is blank and can be discarded. The first pulse is a 'double-high' value which marks the beginning of a frame. This gives you effectively 32 bits. Now I just have to get a perl or python script to read the device instead of the 'mode2' command and I'm off to the races. That will have to wait for another day however, because I need to get back to work.
fixed the dead link...
ReplyDelete