Commodore Amiga CDTV: new protocol or RCA-38(old)?

[Barf]

Please have a look at this issue. It is claimed that this is a new protocol. As I ("bengtmartensson") wrote, decodeir (within IrScrutinizer) identifies the signal as RCA-38(Old) (D=8) However, I get the impression that the timing differences may be significant.

Searching for this device gave me only a Lirc file. This also decodes with IrScrutinizer as RCA-38(old), but with different device number (0), although the timings appear to be off.

This is the C code written:

Code: Select all

#define CDTV_BITS          24
// timing intervals in usec
#define CDTV_HDR_MARK    8850                   // start burst
#define CDTV_HDR_SPACE   4450                   // pause after start
#define CDTV_BIT_MARK     350                   // pulse
#define CDTV_ONE_SPACE   1250                   // receive a '1'
#define CDTV_ZERO_SPACE   450                   // receive a '0'
#define CDTV_RPT_SPACE   2250                   // repeat signal
// message sizes measured in raw pulses
#define CDTV_RAW_REPEAT_LENGTH     4    // CDTV_HDR_MARK + CDTV_HDR_SPACE + CDTV_BIT_MARK
#define CDTV_RAW_SIGNAL_LENGTH     52   // CDTV_HDR_MARK + CDTV_HDR_SPACE + CDTV_BITS * (CDTV_BIT_MARK + CDTV_ZERO_SPACE | CDTV_ONE_SPACE)

//+=============================================================================
#if SEND_CDTV
void  IRsend::sendCDTV(unsigned long data, int nbits) {

        // set IR carrier frequency
        enableIROut(40);

        // send header
        mark(CDTV_HDR_MARK);
        space(CDTV_HDR_SPACE);

        // send data
        for (unsigned long mask = 1UL << (nbits - 1); mask; mask >>= 1) {
                if (data & mask) {
                        mark(CDTV_BIT_MARK);
                        space(CDTV_ONE_SPACE);
                } else {
                        mark(CDTV_BIT_MARK);
                        space(CDTV_ZERO_SPACE);
                }
        }

        // send footer
        mark(CDTV_BIT_MARK);
        // always end with the LED off
        space(0);

}
#endif

Is this a new protocol, or is it RCA-38(old)? Is DecodeIR too tolerant here?

[The Robman]

They are both 24 bits but the timings look different.

Leadin:
9063 4434 - CDTV
3680 3680 - RCA

One
0451 1147 - CDTV
0460 1840 - RCA

Zero
0451 0348 - CDTV
0460 0920 - RCA

Leadout:
62323 - CDTV
07360 - RCA

So, they're certainly similar, but I don't know if they're similar enough for an RCA signal to control a CDTV, but you could certainly use the RCA executor as a basis for a new CDTV executor. I don't think we have a 38k frequency RCA executor, so you'd need to take the 56k version and adjust the freq.

[3FG]

Clearly the decode of RCA(old) is erroneous. I took a quick look at DecodeIR.cpp and from what I can see, if a protocol is recognized as gap with 24 bits, and hasn't been identified as some other protocol, it defaults to RCA. In this case the leadin more closely resembles RCA(old), so that's what DecodeIR calls it.

In truth I've never understood how DecodeIR works, especially the routine that decode gap type signals. I understand/remember even less now. I've handled the 2.42 through 2.45 versions of DecodeIR, but I am no longer willing to work on it, partly because it is pretty difficult and partly because I am close to providing a public version of a Java program which decodes IR signals using a single decoding engine which takes descriptions of IR protocols from an ASCII file. For me, it is much easier to understand, and should allow anybody to add protocols. However, it is not a direct plug-in replacement for DecodeIR.

[Barf]

3FG, thank you very much for the answer. So you support considering it as new protocol?

Regarding DecodeIR, I have responded in a new thread.

Thanx also to Rob.

[The Robman]

Do you own a CDTV Bengt, and if so, do you need a JP1 upgrade for it?

[Barf]

Thanx Rob, but the answer is "no". My interest is purely academic, in the context of the issues linked in the first post.