I have this RF encoder that I am trying to customize with an MCU. The remote control device uses an encoder called HS2260. I believe it is a clone of PT2262 device. I was able to get the waveform but I have trouble understanding what modulation scheme is used. I am planning to write my own code in C for an MCU, I know a bunch of libraries exist for Arduino but couldn't find any C libraries for this. I new to RF so any help will be much appreciated.

enter image description here

This is what the waveform looks like. The frequency is 2.68 kHz.

This is what the multiple waveforms look like: enter image description here

  • \$\begingroup\$ Naming it isn't what's important; finding the patterns is. It looks like the rising edge is consistent, and then the pulse is either high for a short or long time. Turn that into ones and zeros (doesn't matter if you do it the same way as the original developer or opposite) and then look for repeating patterns. Figure out what those patterns mean. You're on the cusp of a great project, but you don't currently have a question which fits the mission of this site. \$\endgroup\$ – Chris Stratton Dec 25 '20 at 22:18
  • \$\begingroup\$ It isn't necessarily the naming that I care about, but similar to what you said, I need help with identifying the patterns. I initially thought it was similar to a Manchester encoding scheme and tried to decode it but wasn't very successful at it. Thank you however for the suggestion. \$\endgroup\$ – aeroengineer Dec 25 '20 at 22:21
  • \$\begingroup\$ This cannot be analyzed from what you've posted... especially not since it's a picture. Write code to sort the pulses into short and long and replace them with symbols. Compare the sequences to find repeating parts; compare the sequences for different commands/functions and see what is similar vs. what is different. \$\endgroup\$ – Chris Stratton Dec 25 '20 at 22:23
  • \$\begingroup\$ I'll see what I can do, thank you! \$\endgroup\$ – aeroengineer Dec 25 '20 at 22:27
  • 1
    \$\begingroup\$ looks like pulse width modulation, I think there's s special term for it when there are only two widths used \$\endgroup\$ – Jasen Dec 25 '20 at 22:47

The encoded output from the PT2262 (and clones) has already been documented, including in (at least some versions of) the PT2262 datasheet.

Each PT2262 input can have 3 possible states - low (0), high (1), or floating (F) and each causes a different pair of pulses on the output:

  • 0 = short, short
  • 1 = long, long
  • F = short, long

A sync bit is a single short pulse followed by a long gap, at the end of the data.

This diagram, taken from page 7 of the datasheet above, shows those three pulse patterns:

Address/Data bit waveforms from PT2262 datasheet

You can see that:

  • short pulse is 4α "on", 12α "off"
  • long pulse is 12α "on", 4α "off"

where "α" is the internal clock cycle length, as set by external components to the encoder.

So your 12 symbol pattern:

encoded data pattern


F F 0 0 F F F F 0 1 1 0 [sync]

for the pin order (at least on a PT2262):

A0, A1, A2, A3, A4, A5, A6/D5, A7/D4, A8/D3, A9/D2, A10/D1, A11/D0 [sync]

There is additional complexity e.g. if the decoder is a type which outputs "data bits", then the last 4 or 6 symbols (depending on the decoder) which are sent by the encoder must be either "0" or "1", so that the decoder can output those bits on its data pins - they must not be sent as "F" from the encoder. Also the encoder sends the full sequence (at least) 4 times.

More information is available at a couple of the sites I have bookmarked from previous work on this (I'm sure there are other useful sites too):

Detect And Zero Rightmost One - Wireless Remote Control PT2272 for Arduino

graznik.de - Reverse Engineering Remote Control Power Sockets - Part 1: Information gathering

(That datasheet also seems to have a mistake: It shows a "0" as just a single short pulse on page 9, but correctly shows it as two short pulses on page 7.)

  • \$\begingroup\$ There's nothing in the captured pattern which stands out as the sort of "sync" you propose or as seen at your links. Until you see that, you can't actually meaningfully decode this, since you don't know where it starts. \$\endgroup\$ – Chris Stratton Dec 26 '20 at 0:36
  • 1
    \$\begingroup\$ @ChrisStratton - The "sync" is the single bit at the end. We know that because there is the correct number of pulses (12 symbols = 24 pulses) before that. There would have been a long period without pulses following that last single "sync" pulse. This is shown on page 7 of the datasheet I linked. I acknowledge that the OP's example image doesn't show that long gap after the last data bit, but they might not have realised the relevance of the following gap. I've looked at lots of the PT2262 waveforms. The OP even says it's from a PT2262 clone, so I don't see why you say it can't be decoded?? \$\endgroup\$ – SamGibson Dec 26 '20 at 0:48
  • \$\begingroup\$ @ChrisStratton - "you don't know where it starts" If it helps, yes, we do know where that pattern starts, if we believe that the OP has given an accurate waveform image. There will always be a long gap following the full 25 pulse (12 "bit" + sync) address/data sequence, since the final sync bit is a 4 alpha "on", then 124 alpha "off", making such a long gap (the "off" state) obvious on any waveform image. The OP's waveform doesn't show that long "off", meaning that the sync bit didn't occur during the sequence shown - thus confirming it's that 25th pulse at the end. See what I mean? \$\endgroup\$ – SamGibson Dec 26 '20 at 1:05
  • \$\begingroup\$ That's making a lot of assumptions that the gap is precisely the part that is missing, no more, no less. Maybe it's right, maybe it isn't and this is some extended version different from your document. Any practical attempt would have to see the gap to sync with it regardless, since it doesn't have a human to trim the recording. The nice part is that with the gap, you don't actually have to know anything about the target system, you can just compare patterns to their purpose/effect such that you can do this for undocumented schemes and not just (possibly) documented ones. \$\endgroup\$ – Chris Stratton Dec 26 '20 at 1:16
  • \$\begingroup\$ @ChrisStratton - "That's making a lot of assumptions" I respectfully disagree - it's exactly one assumption, and knowing the PT2262 waveforms very well, it's one that I've seen done before. That gap is such an obvious "end of data" signal, once you've seen enough of those waveforms. I have commented to the OP requesting that they confirm that there is a gap there, to remove any doubts. \$\endgroup\$ – SamGibson Dec 26 '20 at 1:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.