If the definition of "1" and "0" in RC5 is:
(Pause (889us) | Burst (889us)) = "1"
(Burst (889us) | Pause (889us)) = "0"
The duration of each bit is the same (~1778us), what defines a bit is the sequence of a burst/pause. Pause-Burst = "1", Burst-Pause = "0".
So it doesn't make sense to talk of a fixed sequence of durations: "first pulse, fist blank; second pulse, second blank; third pulse, third blank". I would expect something like: "pause-pulse; pause-pulse; pulse-pause ... (110 ...).
So how the output of the IRToy works, how you define a "1" and a "0" in the IRToy's output?
RC5 "TV 1"
0026 002C 0026 002C 0050 002C 0027 002C 0026 002D 0026 002C 0027 002C 0026 002C 0027 002C 0026 002C 0026 002C 0027 0055 0026 FFFF
889 889 889 889 1778 889 889 889 889 889 889 889 889 889 889 889 889 889 889 889 889 889 889 1778 889 1398077
I believe the IRToy requires you to make the conversion between "1" and "0" in the protocol, versus pulse and pause. In other words, when sending durations, you're talking about pulses and pauses, without regard for whether a pulse will be interpreted as a "1" or a pause will be interpreted as a "0" or even any combination of pulse and pause or specific time slots.
Think of the IRToy the way you would think of a logic analyzer that (generally) doesn't have protocol decoder. When you see high and low on a logic analyzer, it does not literally translate to "1" and "0" in the decoded protocol. You have to do the interpretation yourself, or add a decoder. The reverse is true as well. When you send a sequence to the IRToy, you must do more than simply encode the high level protocol bits. You must translate those "1"s and "0"s into pulses and pauses. As you note, there are specific rules for this with RC5, but the protocol rules are different for Sony IR remotes.
To put it another way, it's up to you to convert from your preferred "pause-pulse; pause-pulse; pulse-pause ..." into "first pulse, first blank; second pulse, second blank; third pulse, third blank ..." (in your RC5 example, that would be "pulse length 1, pause length 1; pulse length 2, pause length ? ...")
Note that because of the translation, you must merge adjacent pulses and adjacent pauses. If your RC5 command has "pulse-pause; pause-pulse" then those two adjacent pause durations must be combined into a single double-duration pause, and since the IRToy expects you to specify the duration, it will know exactly what to do so long as you translate correctly.
Think of the IRToy command as drawing a picture with relative movements. You "draw" the first pulse for a length proportional to its duration, then "draw" the blank as a low for a length proportional to its duration. The caveat is that you cannot ask the IRToy to concatenate two pulses or two blanks for you - you must do that combining yourself. I realize that this may seem like a lot of work, but it is actually about the only smart way to handle transmission without limiting the support to only RC5 and nothing else. The IRToy has to be more universal than any one protocol that you're examining in detail like this.
Is the first 889us a lead-in duration? As if the receiver recognizes a signal is coming in, but when it finally starts decoding it misses the first 889us?
889 889 889 1778 vs 889 889 889 889 1778
I've been referencing San Bergmans' Philips RC-5 Protocol (http://http://www.sbprojects.com/knowledge/ir/rc5.htm).
First of all, San notes that
half a bit time is elapsed before the receiver will notice the real start of the message.
... and coincidentally, the IRToy protocol forces you to start with a pulse, too, so the first blank is not included. Keep that in mind.
Taking San's example:
RC-5:
11000101110101
corresponds to: S1=1 S2=1 T=0 Address=00101=5 Command=110101=0x35=53
Expressed as RC5 pairs (pulse-blank or blank-pulse):
(implicit blank)-pulse; blank-pulse; pulse-blank; pulse-blank; pulse-blank; blank-pulse; pulse-blank; blank-pulse; blank-pulse; blank-pulse; pulse-blank; blank-pulse; pulse-blank; blank-pulse
Then combined into alternating pulse and blank sections (in my notation here, I use -1 for 889µs and -2 for 1778µs):
pulse-1 blank-1 pulse-2 blank-1 pulse-1 blank-1 pulse-1 blank-2 pulse-2 blank-2 pulse-1 blank-1 pulse-1 blank-1 pulse-2 blank-2 pulse-2 blank-2 pulse-1
Then as IRToy:
889 889 1778 889 889 889 889 1778 1778 1778 889 889 889 889 1778 1778 1778 1778 889
... all that to say Address:5 Command:53
Hopefully that makes sense.
Now, to look at the example you gave:
889 889 889 889 1778 889 889 889 889 889 889 889 889 889 889 889 889 889 889 889 889 889 889 1778 889 1398077
Using my notation from above (1=889µs, 2=1778µs), that's:
(implicit blank) pulse-1 blank-1 pulse-1 blank-1 pulse-2 blank-1 pulse-1 blank-1 pulse-1 blank-1 pulse-1 blank-1 pulse-1 blank-1 pulse-1 blank-1 pulse-1 blank-1 pulse-1 blank-1 pulse-1 blank-1 pulse-1 blank-2 pulse-1
... back into RC-5 pairs:
(implicit blank)-pulse; blank-pulse; blank-pulse; pulse-blank; pulse-blank; pulse-blank; pulse-blank; pulse-blank; pulse-blank; pulse-blank; pulse-blank; pulse-blank; pulse-blank; blank-pulse
or
11100000000001
in RC-5:
S1=1 S2=1 T=1 Address=00000=0 Command=000001=1
Does that make sense?
For other protocols, the conversion can be even trickier, because there are more than two timing lengths, but times may not be constant, and start pulses can be much longer than bits.
Thanks, I got it by reverse engineering from the bitstream, just wanted to make sure the first blank could be ignored for all protocols.
[quote author="liyin"]Thanks, I got it by reverse engineering from the bitstream, just wanted to make sure the first blank could be ignored for all protocols.[/quote]Well, I don't know if "ignored" is the right terminology to use. You certainly have to be sure and adjust for it, depending upon the protocol.
The primary reason for this is that the receiver cannot tell the difference between silence and when an IR remote transmits the initial blank. Thus, any receiver that deals with a protocol that allows leading blanks will have to adjust. Since many of the IR protocols have a long start bit, the leading blank is never a problem. RC-5 happens to be a little odd in this respect.
The sampling mode output only shows durations and change. I thought you needed foreknowledge of the protocol to determine the "1's" and "0's". But ...
//the first falling edge starts timer0
If the first falling edge (receiver low) starts the timer, then ...
- The signals always start with the 889us of the first falling edge (low), and the next duration (889us or 1778us) determines if it is a "1" or a "0".
- The first 889us is not relevant in the sense that it will always be the same, the first falling edge (_). Knowing the state of the receiver at the beginning of the bitstream allows you to decode the "1's" and "0's", but the first 889us is not part of the original bitstream.
[hr:][/hr:]
WinLIRC's config file for RC-5 has this header info:
[font=courier:]one 889 889
zero 889 889
plead 889[/font:]
plead = leading pulse
@rsdio - great break down, can I add that to the wiki as an example? (license becomes CC-BY-SA)
//the first falling edge starts timer0
I don't understand your two conclusions, but I wanted to clarify what this means. The IR receiver inverses the signal - an IR pulse causes it to go low, when there's no signal it's high.
-so-
The first falling edge (caused by the first pulse of IR light) starts the timer. The time is measured until the next change. The first byte pair in the sample will always be the duration of the pulse time, the second will always be the duration of the blank time, and so on. As rsdio said, it's not possible to tell the difference between the RC5 blank time at the beginning and just normal silence.
The sbprojects website linked above is my favorite IR resource too, I highly recommend it. That's where I learned to write the RC5 decoder in the IR Toy.
[quote author="ian"]@rsdio - great break down, can I add that to the wiki as an example? (license becomes CC-BY-SA)[/quote]Certainly. If anyone thinks it needs clarification or editing, drop me a line and let me have first right of refusal on editing it. Obviously, the wiki will allow anyone to edit, but I just want a chance to phrase it with a consistent voice before it morphs.
@liyin: The first 889µs pulse is very relevant. You never ignore any part of the bitstream except the giant, trailing blank section. Instead of ignoring any part of the bitstream, you actually need to invent an additional blank section at the beginning of any protocol like RC-5 which does not always start with a pulse. I think Ian has described this quite well in his response, so I hope this is making sense.
Thanks, I posted it here:
http://dangerousprototypes.com/docs/Rsd ... _breakdown (http://dangerousprototypes.com/docs/Rsdio%27s_RC5_breakdown)
but it'll be monday before I have time to clean up the formatting for the wiki.
Thanks. I did some formatting which is hopefully readable.
This is a graphical representation of what I said before.
In RC-5 you always get a lead-in period of 889µs, and the first start bit is always "1".
So you do know the state of the IR receiver:
1) If the first period "in the protocol" is 889µs, then the IR receiver was low before it received the first start bit (as per the image).
2) If the first period "in the protocol" is 1778µs, then the IR receiver was high before it received the first start bit.
[quote author="liyin"]This is a graphical representation of what I said before.[/quote]I don't understand what you're saying here at all. I see that the graph is inverted compared to the RC-5 protocol, like the IR receiver, but I do not understand your other comments.
In RC-5 you always get a lead-in period of 889µs, and the first start bit is always "1".
The second start bit is always "1", too. Only the third bit, Toggle, changes.
So you do know the state of the IR receiver:
1) If the first period "in the protocol" is 889µs, then the IR receiver was low before it received the first start bit (as per the image).
2) If the first period "in the protocol" is 1778µs, then the IR receiver was high before it received the first start bit.
The IR receiver is always low before before the first start bit. As far as I understand, the IRToy triggers on a falling edge from the IR receiver, which represents a rising edge in the RC-5 prototcol. It never starts on the opposite condition. Therefore, the IR receiver is always high during silence between IR commands, and during the first half of the bit time for the first start bit.
In other words, when receiving RC-5 without interference, the first period in the IRToy sample mode is always 889µs, and it represents a pulse (high in RC-5, low from the IR receiver). Because there are two start bits for RC-5, and they're both always "1," that means it's impossible to receive a 1778µs period at the beginning of the IRToy sample mode unless something is wrong. Ways that it could go wrong are that you start sampling in the middle of a message instead of the start, or if there is interference in the IR spectrum from another remote, IR jammer, the sun, etc.
This is the diagram from sbprojects for RC5.
The IR toy will never start sampling on a blank period, the interrupt checks that the pin is low (IR signal) and ignores and resets if it's high (illegal condition). If there was a constant IR signal when you entered IRsample mode it wouldn't do anything (no pin change), then if you stopped that signal (Low->High change) it wouldn't do anything either.
Is there any use for the IRIO mode anymore?
No much any more, the IR sample has a lot of improvements, and IRIO won't be developed any further.
The images below show that the first period is really the second-half period of the first Start bit (I was wondering if that was the case). I suppose all protocols have some sort of start bit that activates the IR receiver.
Indeed they do
A lot of remotes have an actual header, a long space followed by a long pulse to kick off the decoding. The header just says, i'm here and i am conforming to protocol X.
If you want to decode sample mode. Theres 2 ways to do it:
1) just blind match the pulse/space values. This should work fine other than the problem of toggle bits but it's not a deal breaker.
2) Decode into 1's and 0's
It's fairly easy to do this. There are 2 main encoding modes, Manchester encoding, where the pulse and space values are the same length. Fairly easy to detect. Or this one
(http://http://www.sbprojects.com/knowledge/ir/recs80mod.gif)
Where a 0 is a short pulse followed by a long space, and 1 is a short pulse followed by a longer space. If you strip away the headers, you can decode pretty much most protocols into a stream of 0s and 1's that way. The irman mode works something like that. 6 bytes, gives you 48 bits, that's enough for pretty much every protocol.
(http://http://i53.tinypic.com/2ivi39e.jpg)
(http://http://www.sbprojects.com/knowledge/ir/rc5train.gif)
Easier graphic to understand. Yours is drawn upside down for some reason.
It depicts the IR Toy's sampling mode protocol for RC-5 (IR Receiver), with the zeros and ones (Remote) representing the original bitstream sent by the remote.
We should probably standardize on the IR format graphics used by Sans Bergman. The IR Decoder component inverts the signal due to its nature as a simple phototransistor, but I don't think it will help clarity to depict everything inverted.
As for the IRToy sampling mode, it's really just a sequence of number pairs. There is no actual "hi" and "low" in the protocol. Since the PIC triggers on a falling edge, that make the first number in each pair correspond to a "hi" even though the IR Decoder has fallen to zero because of its inversion. In other words, IR "pulses" are the "hi" parts of the signal.
@liyin: When you say "the original bitstream sent by the remote," I don't think you're accounting for the fact that the IR decoder inverts the signal.
Some might be thinking in terms of the diagram from SB-Projects for the RC-5 protocol. My diagram is not that diagram, it's purpose wasn't to illustrate an RC-5 IR signal.
I wanted an illustration of the activity of the IR decoder in relation to the timing pairs and the original bitstream.
The protocol is about durations, not hi or low, but the IR decoder is. It is between the bitstream and the protocol, and the diagram summarizes the relationships between them (obviously the bitstream and protocol timings are simplified). It was helpful in understanding the sampling mode.