JP1 Remotes

do you not notice that the binaries that end in a "0" have a leadout that is just an OFF time, and the binaries that end in a "1" have a leadout that is a single unit of ON time followed by an OFF time, and are shorter by 1 bit?

As long as you get the ON times right, the device will most likely forgive errors in the leadout OFF time.

theforcedk,
This last post of yours suggests to me that you haven't understood the situation, because you refer to "your signal" (meaning Rob's) and how it is different from the one you captured. In fact, Rob took your signal, converted it into a format he is more comfortable with, and showed that the correct decode is 0x10006955.

You seem to still believe that your signal for button 2 decodes to 10006954. It doesn't. We can look at your png file and read off the decode manually without recourse to any tools-- we just need to understand how bi-phase IR signals work. The key is that bi-phase signals are interpreted by looking for edges. The IR lead in establishes a time zero, and the 0 or 1 values are determined by the direction of each edge. In your png, a rising transition is a zero, and a falling transition is a 1. But you have to sample only the edges which occur at 660uS intervals. In your png file, the signal starts with the sequence rise-fall-rise-fall, which is the lead in. The very next transition is a rise and it means zero. Then, looking only at transitions occurring at 660uS (which is just double the width of the narrowest pulses), we can read off an additional 2 zeros, a one, and then 13 consecutive zeros. etc. Notice that an on/off burst pair of single width implies a bit which is a duplicate of the previous bit, while double width implies the complement of the previous bit.
The last pulse is double width, and that tells us immediately that the decode can not possibly end in 0x4.

Hi 3FG/Robman

I apologize if I come off sounding like I don't want to listen. It's just a lot of information to take in, on top of what I thought was correct, and therefor I wanted to provide as much information as I could without actually changing my code at that point - but I believe I understand your last replies where you explain why this is happening. I've fixed my decode rutine to handle this and I now get the same decode as Rob.

Again, I really appreciate your help and explanations.

theforcedk wrote: It's just a lot of information to take in, ...

That is the truth! it kind of makes your head hurt taking it all in, doesn't it.