Please explain

[ArminJo]

Hi Bengt, I just want to understand.

As opposed to IRremote and IRLib, our sequences always start with a space and end with a gap. It is claimed to be a more relevant representation than the one of IRremote and IRLib.

What is the difference between your starting space and rawbuf[0]?
Is the gap the minimal gap between two sends? and what is the gap value on receiving?

[bengtmartensson]

Sorry, I messed up the terms, the paragraph (from README.md) should read

An IrSequence is a vector of durations, i.e. sequence of interleaving on-periods (sometimes called marks or flashes)
and off-periods (sometimes called spaces or gaps).
It does not contain the modulation frequence. As opposed to IRremote and IRLib, our sequences always start with
a on-period and end with an off-period. It is claimed to be a more relevant representation than the one of IRremote and IRLib.

(I managed to used "space" in the sense of on-period... shame on me...)

IRremote's rawbuf[0] (which is its first off-period) is the amount of time that has passed between the reception was started and the first positive edge. This is not a part of the signal, and most likely, not of interest to the user. Why did Ken Shirriff do it that way? I can only guess, but my guess is that he would have removed it as soon as decided to clean up...

Why a final ending off-period? (For example, Lirc leaves it out, and even the post-Lirc Linux IR stuff does it that way). It is more consequent and logical to tread the final silence as part of the signal. You cannot send a subsequent signal too early that way. Having a "minimal gap between subsequent sends"- variable instead has a few shortcomings: Some signals (like NEC1) have a constant length (in ms), but sending different payloads take different amount of time (a 1 takes twice as long as a 0). Also, the initial sequence is much longer than the repeats, all which the sending program has to take into account. It leads to messy code. Note that the timing issue is not just "you are prohibited to send until...", but the timing has to be reasonable correct for, for example, a repeated volume up to be recognized as such.

what is the gap value on receiving?

The measured final off-period on receiving is of course not the corresponding parameter of the sending program ;-). Instead, it is the amount of
time that has passed since the last on-period. Differently put, we have verified that this time has passed without any activity. This is generally a timeout in the receiver (endingtimeout in my software). Note that this value may very well be of interest to the user: For example, say that the signal is a NEC1 with one repeat, and the last ending is 50ms. In this case, it may very well be that the original signal contains of several repeats --- which we are discarding --- since 50ms will cut between the repeats of a NEC1.

[ArminJo]

Thanks a lot for your elaborate explanation.

Why did Ken Shirriff do it that way? I can only guess, but my guess is that he would have removed it as soon as decided to clean up...
rawbuf[0] is used in almost every decoder to detect a repeat. so it is not useless at all. I ask myself how other libraries decide for repeats without this information.

Am I right, that the final gap on receiving is always equal endingtimeout ?

[bengtmartensson]

rawbuf[0] is used in almost every decoder to detect a repeat. so it is not useless at all. I ask myself how other libraries decide for repeats without this information.

Can you point me to the code? IMHO, identifying a repeat is a complicated task that is well beyond the capacities of an ATMega328. It is better done in a program running on a larger computer, like IrScrutinizer/IrpTransmogrifier (class RepeatFinder).

Am I right, that the final gap on receiving is always equal endingtimeout ?

Sort-of, it should not be smaller, but may be slightly longer.

[ArminJo]

Can you point me to the code?

I have done a search for rawbuf[0] and found the code 😉 .