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.
Zaptor checksum (Motorola VIP1903)
Moderator: Moderators
-
The Robman
- Site Owner
- Posts: 22057
- Joined: Fri Aug 01, 2003 9:37 am
- Location: Chicago, IL
- Contact:
Last edited by The Robman on Sun Oct 05, 2014 5:03 pm, edited 1 time in total.
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
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.
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.
-
theforcedk
- Posts: 8
- Joined: Wed Oct 01, 2014 5:22 am
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.
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.
-
vickyg2003
- Site Admin
- Posts: 7109
- Joined: Sat Mar 20, 2004 12:19 pm
- Location: Florida
- Contact:
That is the truth!theforcedk wrote: It's just a lot of information to take in, ...
it kind of makes your head hurt taking it all in, doesn't it.Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.