Help with IRremote Unknown protocol

[mbarclay36]

I've been trying to get this to work now for days without any luck. I have a remote to an electric fireplace that I want to control with an arduino. I am using the IRremote library with an ir receiver to read the code coming from the remote. Then I am using another arduino running esphome and trying to transmit the code to the fireplace to control it. Here is the irDump I am getting from the IRremote library:

Protocol=UNKNOWN Hash=0x39D41DC6 12 bits (incl. gap and start) received

Raw result in internal ticks (50 us) - with leading gap
rawData[24]: 
     -65535
     +  27,-   7     +  26,-   8     +  10,-  24     +  26,-   8
     +  26,-   8     +   9,-  25     +  10,-  24     +  27,-   7
     +   9,-  25     +   9,-  25     +   9,-  25     +  10
Raw result in microseconds - with leading gap
rawData[24]: 
     -3276750
     +1350,- 350     +1300,- 400     + 500,-1200     +1300,- 400
     +1300,- 400     + 450,-1250     + 500,-1200     +1350,- 350
     + 450,-1250     + 450,-1250     + 450,-1250     + 500

Result as internal ticks (50 us) array - compensated with MARK_EXCESS_MICROS=20
uint8_t rawTicks[23] = {27,7, 26,8, 10,24, 26,8, 26,8, 9,25, 10,24, 27,7, 9,25, 9,25, 9,25, 10};  // Protocol=UNKNOWN Hash=0x39D41DC6 12 bits (incl. gap and start) received

Result as microseconds array - compensated with MARK_EXCESS_MICROS=20
uint16_t rawData[23] = {1330,370, 1280,420, 480,1220, 1280,420, 1280,420, 430,1270, 480,1220, 1330,370, 430,1270, 430,1270, 430,1270, 480};  // Protocol=UNKNOWN Hash=0x39D41DC6 12 bits (incl. gap and start) received

Pronto Hex as string
char prontoData[] = "0000 006D 000C 0000 0035 000D 0033 000F 0014 002D 0033 000F 0033 000F 0012 002F 0014 002D 0035 000D 0012 002F 0012 002F 0012 002F 0014 06C3 ";

I have tried sending it many different ways but the 2 ones that I think have the most promise are these:

remote_transmitter.transmit_pronto:
          data: "0000 006D 000C 0000 0031 0011 0031 0011 0010 0031 0031 0011 0031 0011 0010 0031 0010 0031 0031 0011 0010 0031 0010 0031 0010 0031 0010 06C3"

and

remote_transmitter.transmit_raw:
          carrier_frequency: 38kHz
          code: [1250, -450 ,1250,-450, 450,-1250, 1250,-450, 1250,-450, 450, -1250, 450, -1250, 1250, -450, 450, -1250, 450, -1250, 450, -1250, 450]

Unfortunately I haven't had any luck yet getting this to work. One of the things I feel like I don't understand and may be messing up is the leading gap. I'm not sure what that means/how I'm supposed to use it when sending. Any help would be greatly appreciated!

[hexreader]

I do not recognise that waveform as any standard protocol that I know of, but it looks very similar to the protocol used for an old Hitachi clock/radio that I used to own, but threw away long ago.

Your message looks like header 6, row 6, column 8

It looks as if each message needs to be sent twice, with the repeat message sent 35ms after the end of the first message.

Try sending twice....

---

Hitachi Clock/radio/cd remote
battery CR2032
t = 430 uS, 12 data bits total, sent in pairs of messages
3t mark 1t space = 1
1t mark 3t space = 0
1t mark, 35ms space = Gap 1 (between message 1 and message 2)
1t mark, 90ms space = Gap 2 (end of message 2)

3 bits header = 110, 3 bits row, 5 bits column, 1 stop bit 0,
Gap 1
3 bits header = 110, 3 bits row, 5 bits column, 1 stop bit 0,
Gap 2

single-shot buttons - repeats once, after 54mS to give just one pair of messages
110 010 00001 0 random
110 010 00010 0 play/pause
110 010 00100 0 open/close
110 010 01000 0 standby/on
110 010 10000 0 mute

repeating buttons - still in pairs, but pair repeats every 162mS
110 100 00001 0 stop
110 100 00010 0 skip/search back
110 100 00100 0 skip/search fwd
110 100 01000 0 volume-
110 100 10000 0 volume+

EDIT: above changed with corrected timings

[mbarclay36]

Thanks for the response! I was able to get it working by using transmit_raw, however I had to send the message multiple times like you said. What's funny is I figured out I have to send it twice to wake the fireplace up and then send it a few more times (5 seems like the most consistent number) to actually have it run the command.