In the lirc file I use, there is  a large section with some hex-codes, but also a smaller section with so called 'raw codes', see here a snippet with the raw codes for "POWER_ON".

begin remote

      begin raw_codes

          name POWER_ON
              896     853    1792    1749    1792     874
              874     874     874     874     874    4437
              874     874     874    1749     896     832
             1792     874     874     874     874     874
              874     874     874     874     874     874
              874    1770     896

      end raw_codes

end remote

My Raspberry Pi, that also has an IR receiver, never understood these. And as they only contained codes I didn't use on the Pi anyway (as I use some other codes to control the Pi) I didn't bother.

Now it is the other way around, I use a uC to control the amp, so now they became more important.

When looking at the lirc documentation, the raw codes were just raw pulses and pauses, starting with a pulse. So the code above beneath POWER_ON would send out a 896us pulse, then 853us of pause, 1792us pulse, 1749 pause, and so on. Given that a 1 is encoded as approximately a 889us pause, followed by a 889us pulse and a 0 the other way around, It is not that hard to decode. Which I started on some time ago already.

(Note, that 889us is based on a 36kHz carrier signal (64/frequency/2; 64 carrier pulses at 36kHz per bit, half of the bit is pulse, half pause). I mentioned in a previous log that the receiver in the Marantz is a 38kHz version. I don't exactly know what is right, the captured raw codes above would indicate a 36kHz signal. Either way, both setting the output to 38kHz and 36kHz work when I put it in my programming. There's quite some tolerance on the input..)

Knowing the START bit is always a 1, it should start with that. Obviously the first pause is not included, so only half of the START bit is actually in the raw code, then it follows that the start of the code would be 0b1101 0000. And then there's a 4437us pause. Which didn't make sense to me in the RC-5 protocol, as that would be 2.5 bits worth of pause (4437/889 is about 5 half bits). And that's not part of the standard.

RC-5x

But that's where the x comes in.

According to the internet, there is a not very well documented RC-5x protocol standard. There is a reference on kernel.org and a more interesting mailing list discussion, that also contains the image below.

It is called the "Marantz Extended Data Word" in the discussion, but according to Mona, it is "actually the RC5x protocol". But as said, searching for RC-5x doesn't give a lot of results, definitely a lot less than RC-5.

And it shouldn't be confused with extended RC-5! Extended RC-5 uses the 2nd start bit (or field bit) as an extra command bit. But extended RC-5 has the same length (14 bits) as normal RC-5.

RC-5x however has a length of 22 bits. Including 2 bits of spaces, in which the signal doesn't go high at all. And that matched perfectly to my binary code with the mysterious 2.5bit pause above!

Now the command could easily be finished to 0b1101 0000 ss 0011 0000 0001 (with ss the 2 spaces) or hexidecimal 0xD0301 (with the spaces after bit 8 cut out).

Sending that to the amp also worked flawlessly (after correcting a few errors I made in the decoding that is), so now POWER_ON also works!

For completeness, here all 4 decoded raw codes that were listed in the lirc config. Just don't forget to add a 2 bit space after bit 8 when sending.

• POWER_ON - 0xD0301
• POWER_OFF - 0xD0302
• AUX1 - 0xD0006
• AUX2 - 0xD0007