Go Down

Topic: Remote rf protocol debug (Read 156 times) previous topic - next topic

jmsurpri

I have a fireplace with an 315mhz rf remote. I am trying to capture the signals with an arduino uno and an rf receiver. I've tried the rc-switch library and it doesn't recognize anything from the remote. I've opened up the remote and there is just a PIC microcontroller and an rf transmitter chip. The transmitter chip has 'GT-FIRE TX" text, which is the name of the company and/or remote system, so possibly a custom protocol.

Trying to figure out how to move forward. Can I use my arduino as a logic analyzer, hooking up the transmitter's data pin of the remote to an arduino interrupt pin and capture the timings and reverse engineer the protocol?

Thanks
Jason

mikb55

If you just want to use an Arduino to control the fireplace, then a 'replay attack' may be all that you need.
Simply record the data from the remote then play it back.



jmsurpri

Thanks. I was able to capture the signal from the remote and have started to try to decipher it. I am new to this so I'm not sure if this is a standard protocol, but this is what i'm seeing:

- The minimum pulse width is 400us.
- There are various pulses and gaps a multiple of 400us.
   - a 'sync' pulse of 3*400 = 1200us
   - a wide pulse of 800us
   - a narrow pulse of 400us
   - a wide gap of 800us
   - a narrow gap of 400us

- The msg starts with a sync pulse and wide gap, then a series of wide and narrow pulses and gaps, another sync pulse, repeated 7 times, so looks like 7 distinct data sections. The entire msg is sent 5 times.

- Each data section has exactly 21 400us of data, so ~8400us total time between syncs

- There doesn't appear to be a consistent wide pulse + wide gap, narrow pulse + narrow gap pattern that I can interpret as 1 and 0.  I see wide pulse + narrow gap and narrow pulse + wide gap often.

- If I just assume wide pulse = 1, narrow pulse = 0 and ignore the gaps, it results in some sections being 8 bit between syncs, sometimes 7, sometimes 9. I would think a section would exactly represent a byte of data, so this doesn't seem right to me. The fact that there are exactly 21*400us in each data section tells me this pattern is not right.

rtl_433 gives following output, so similar analysis as above:

Guessing modulation: Pulse Width Modulation with sync/delimiter
Attempting demodulation... short_width: 420, long_width: 832, reset_limit: 5300, sync_width: 1236
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=420,l=832,r=5300,g=0,t=0,y=1236'

Sample decode results from rtl_433 (matches what I get by visual inspection)

[00] { 8} ab        : 10101011
[01] { 8} ba        : 10111010
[02] { 9} fa 80     : 11111010 1
[03] { 8} 76        : 01110110
[04] { 9} f7 00     : 11110111 0
[05] { 7} 2a        : 0010101
[06] { 8} 6e        : 01101110
(repeat)

7 sections, 7-9 bits of info in each.

Another idea is to treat each 400us as a bit. If there is a pulse, it's one, otherwise 0. Every data section will have exactly 21 bits in this scenario. Maybe it represents 16bits + 5 bit CRC? This doesn't make sense either though because you would then see much wider pulses/gaps potentially to represent a string of multiple 0s or 1s.


Attached is the waveform.
Thanks for any help,
Jason



Go Up