PT2260 support - sniffing unsupported devices?

wszak commented 8 years ago

I have a remote controller looking exactly like this one on eBay: 361529945280 and a XY-MK-5V receiver. The controller is said to have the PT2260 chip, which is not on the list of chips supported by this library.

My problem/question is that I can't get any readings using RCSwitch, although I can see that some data is coming from the receiver. I also tried some other remote controllers I found at home (car openers) but also didn't get any readings from RCSwitch.

Is that the expected behaviour? I just wonder if it's because the chips in my remotes aren't supported or is it because the protocols may use rolling codes. I thought RCSwitch should be able to show/sniff the transmission anyway? Is that right or it won't sniff such transmission and I must find a simpler remote to see the transmitted codes?

fingolfin commented 8 years ago

Actually PT2260 is the name of a chip used in many 433Mhz remotes, including some supported by RCSwitch. I'd dare say it is (or at least was) the most common chip to be used, in fact.

So in principle, RCSwitch should have no problem receiving these signals. But of course that's just "in theory", in reality all kind of things can go wrong... :-).

Let's start at the lowest level: How did you verify that your hardware setup is correctly receiving data? You write that you "can see that some data is coming from the receiver" -- how exactly? Perhaps you can insert your test code here?

wszak commented 8 years ago

I can see the data coming using a simple program below - what it does is just record pin changes in an array (interrupt handler) and print them (in loop function). Here is the program:

int receive_pin = 2;

#define MAX 120
int value[MAX];
unsigned long time[MAX];
int changes;
int printed;

void setup() {                
  Serial.begin(9600);
  pinMode(receive_pin, INPUT);

  changes = 0;
  printed = 0;
  attachInterrupt(0, change_handler, CHANGE);
  Serial.println("Receiver 433MHz setup");
}

void change_handler()
{
  if (changes >= MAX) return;
  value[changes] = digitalRead(receive_pin);
  time[changes] = micros();
  changes++;
}

void loop() {
  if (printed + 1 < changes) {
    Serial.print(printed);
    Serial.print(" ");
    Serial.print(value[printed]);
    Serial.print(" ");
    Serial.println(time[printed+1] - time[printed]);
    printed++;
  }
}

And here is the output I'm getting when I press a button on my remote:

As for RCSwitch I'm using the example programs: ReceiveDemo_Simple and ReceiveDemo_Advanced. They don't output anything. :(

fingolfin commented 8 years ago

OK, that's useful data. Based on what you gave here, perhaps try adding this as a new protocol in the table in RCSwitch.cpp (or, more cleanly: setup your own protocol struct, and pass it to setProtocol).

{ 30, { 37, 122 }, { 10, 43 }, { 37, 16 } },

Does that help?

UPDATE: Sorry, the 30 there should have been a 15 :-(

wszak commented 8 years ago

No, still no go (btw. setting protocol in setProtocol seems to affect only transmiting - not receiving). I also tried something like { 10, { 55, 183 }, { 15, 64 }, { 56, 24 } } - not sure if it makes sense. My reasoning was: HIGH / LOW state 550us / 1830us - sync bit 150us / 640us - logical zero 560us / 240us - logical one

I found some datasheet for PT2260 (no idea if it's recent or it's really used by my remote) and if I understand it correctly, it says that each bit is encoded by two changes from high to low. Does RCSwitch support such a scheme? www.spelektroniikka.fi/kuvat/PT2260.pdf But the data I provided don't exactly correspond to that scheme as if it didn't work that way.

fingolfin commented 8 years ago

As I said, many remote switches use the PT2260, including multiple supported by RCSwitch. The "tristate" encoding of data originates (AFAIK) from the PT2260.

But the raw data you pasted matches no PT2260 I have ever seen (which doesn't mean much -- there are countless of them out there, and I only ever had access to small number of them ;-).

Anyway: As the diagram on page 4 of the PDF you linked to explain, a "zero bit" is encoded as 128 time units of high, 384 units low, 128 units high, 384 units low. This is a 1-to-3 rati, which you can also see in the encoding of one bits, as well as the "f (floating) bit". This corresponds precisely to our protocol 1, combined with tristate encoding. See also https://github.com/sui77/rc-switch/wiki/KnowHow_LineCoding

But again, this does not match the data you gave.

fingolfin commented 8 years ago

Note that the characteristic pattern of a sync signal, plus high/low encodings for logical zero and one are the basic patterns of all protocols supported by RCSwitch, not just those generated by the PT226x family.

fingolfin commented 8 years ago

One more idea: You could open the packaging of your remote (assuming that is possible without destroying) to get a look at the PCB, and see for youself what IC(s) it uses.

wszak commented 8 years ago

Yes, I did that, but couldn't find any markings at all. I'm now ordering some other remotes on eBay to see if they will work. I'll report here whether they do and what chip they're based on. As for my current remote, I think I'll end up writing some custom program to handle its transmissions. Thank you for your help anyway!

uzi18 commented 7 years ago

support added in PR #101 proto 1 is ok for it, but separation limit was too high on some remotes.

sui77 / rc-switch

PT2260 support - sniffing unsupported devices? #60