JP1 Remotes

johnsfine · Posted: Fri Dec 12, 2003 3:37 pm Post subject:

I had only looked at the four signals posted earlier in this thread. (so I saw roughly 5% variance from presumed center and thought my 10% different center might be too high).

If the rest of the learned signals varied so much that the average was down to 1064, then it doesn't seem likely that we needed to fine tune this at all. The one you posted or either that I posted should be all the same to the device.

jon_armstrong · Posted: Fri Dec 12, 2003 3:57 pm Post subject:

Sorry, I should have mentioned the variability of the off time but I was having "fun" and it is a slow afternoon.

Back to the new technique, is this something that can be substituted in PB for a mid frame burst rather than tie it to the lead-in On and Off times? It seems close enough for many cases and we can always tweak the values with testing, just like in this case.
_________________
-Jon

johnsfine · Posted: Fri Dec 12, 2003 4:12 pm Post subject:

Done as simply as I did it here, it only provides a one time (first frame only) extra lead in which could be ahead of or in place of the real lead in. If that's in place of a real first_frame_only lead in (as in this case) then it does free up the normal lead in burst to be used as either a mid frame burst or a lead out.

It could be done in a slightly more complex way so the extra lead in burst was on every frame not just the first. In the near term I don't want to put that large a chunk of effort into PB for this obscure feature.

I was actually think about this approach for RC6-6-32. The bit doubling approach for RC6 exceeds the max bit count for any RC6 over RC6-M-24. So the streached toggle bit gets quite tricky (even if it doesn't actually toggle). Even if this trick solved the lead in, the toggle bit still is likely to be -2+2 rather than +2-2 so it can't be done as a mid frame burst. I have some ideas, but nothing solid. Doing the whole thing raw is much simpler (and can easily be much smaller than the way UEI did it) but tricking the IR generation engine is a more fun puzzle and might somehow make an even shorter protocol.

jon_armstrong · Posted: Fri Dec 12, 2003 4:45 pm Post subject:

If it is not difficult to do, maybe use this technique if the Lead-In style is set to something other that "none" and you also select a mid-frame burst.

IIRC, I have had several of these recently where the only workaround was to set the definitions of One and Zero to be only On and Off respectively.

BTW and OT, I recently used that technique with an ASCII protocol where One=0,-840 and Zero=840,-0 and unless I selected reverse polarity for Zero, I kept getting a short Off pulse between successive Zero's. (It is possible that I have everything exactly backwards)

The point is NOT that it needs to be fixed but if you ever see a problem with this style One/Zero definition, try reversing the polarity on the zero.
_________________
-Jon

johnsfine · Posted: Fri Dec 12, 2003 5:21 pm Post subject:

There is a feature of the IR generation engine I only vaguely understand. It is used to prevent the phase problems and gaps that would otherwise occur one bit ends in "on" state and the next bit starts in "on" state. I don't know whether PB can or should be turning that feature on when required. I believe certain combinations of other features make the IR engine itself turn it on and I think what your seeing is the difference between that feature being on and off.

usblipitor · Joined: 10 Oct 2003 Posts: 516 Location: Greenbelt, MD

John & Jon,

Thank you both so much. I can't wait to try out the protocol! (I am certain that it will work, given whom the authors are.) I also can't wait to try to figure out how it works.

Thank you both again! Happy Holidays! Mr. Green

_________________
-Steve
Beginner's Guide
CodeSearchFAQ
JP1Files