PT2260 support - sniffing unsupported devices? about rc-switch

[fingolfin]

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]

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:

0 1 560
1 0 236
2 1 560
3 0 228
4 0 16
5 1 548
6 0 244
7 1 556
8 0 1828
9 1 556
10 0 240
11 1 156
12 0 640
13 1 556
14 0 240
15 1 556
16 0 244
17 1 152
18 0 644
19 1 556
20 0 240
21 1 156
22 0 644
23 1 552
24 0 244
25 1 152
26 0 644
27 1 156
28 0 640
29 1 156
30 0 644
31 1 552
32 0 244
33 1 556
34 0 240
35 1 560
36 0 236
37 1 556
38 0 244
39 1 552
40 0 244
41 1 152
42 0 652
43 1 552
44 0 1832
45 1 548
46 0 248
47 1 152
48 0 648
49 1 548
50 0 244
51 1 556
52 0 244
53 1 152
54 0 644
55 1 552
56 0 244
57 1 152
58 0 648
59 1 548
60 0 248
61 1 152
62 0 648
63 1 148
64 0 648
65 1 148
66 0 648
67 1 552
68 0 244
69 1 552
70 0 248
71 1 552
72 0 244
73 1 548
74 0 248
75 1 552
76 0 244
77 1 152
78 0 652
79 1 548
80 0 1832
81 1 552
82 0 244
83 1 152
84 0 648
85 1 548
86 0 248
87 1 552
88 0 244
89 1 148
90 0 652
91 1 548
92 0 248
93 1 148
94 0 648
95 1 552
96 0 244
97 1 148
98 0 652
99 1 148
100 0 648
101 1 148
102 0 652
103 1 548
104 0 248
105 1 552
106 0 244
107 1 548
108 0 248
109 1 548
110 0 248
111 1 552
112 0 244
113 1 148
114 0 656
115 1 548
116 0 1836
117 1 544
118 0 252

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

[fingolfin]

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]

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]

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]

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]

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]

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]

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