sebmillet / RF433any

GNU Lesser General Public License v3.0
39 stars 4 forks source link

2 codes per button #8

Closed kavakopoulos closed 1 year ago

kavakopoulos commented 1 year ago

Hello and thank you very much for this library. I try to copy the code of my awning remote but I get 2 consecutive codes when I press the button once. How do I put 2 codes in the RF433send library?

button pressed once 9:36:01.592 -> Received 39 bits (x2): 11 7a a4 02 aa 19:36:01.592 -> Received 32 bits (x1): 22 f5 48 05

button pressed again 19:36:01.762 -> Received 39 bits (x2): 11 7a a4 02 aa 19:36:01.762 -> Received 32 bits (x1): 22 f5 48 05

also the timings are different

19:46:05.660 -> Decoded: yes, err: 0, code: T, rep: 1, bits: 39, data: 11 7a a4 02 aa 19:46:05.660 -> I=65535, LS=365, LL=722, HS=0, HL=0, S=7825, U=4249, V=1485, Y=0, Z=717 19:46:05.660 -> Decoded: yes, err: 0, code: T, rep: 1, bits: 39, data: 11 7a a4 02 aa 19:46:05.660 -> I=0, LS=365, LL=722, HS=0, HL=0, S=7834, U=4832, V=1496, Y=0, Z=716 19:46:05.660 -> Decoded: yes, err: 0, code: T, rep: 1, bits: 32, data: 22 f5 48 05 19:46:05.660 -> I=0, LS=365, LL=722, HS=0, HL=0, S=0, U=4824, V=1498, Y=0, Z=714

Thank you very much in advance

sebmillet commented 1 year ago

Hello

my impression is that there is kind-of sync sequence of 8 bits or so, followed by two 32-bit codes. But difficult to say without looking at raw signal (signal timings recording). For sure the timings are identical, the I=65535 followed by I=0 on subsequent codes, is logical: the "initial sequence" (initseq, the long HIGH signal that just announces something is going to arrive...) is used typically once, then RF433any will consider the initseq has been used and further initseq are shown as zero. But still, there must be some sort of separator between sequences, something RF433any is not very good at identifying.

In order to go forward, could you please post the snif of the code. You may use rf433snif, available here: https://github.com/sebmillet/rf433snif

thus we can see what is going on in terms of timing (maybe there is an initial SYNC sequence and it confuses RF433any).

Thanks,

Regards, Sébastien Millet

kavakopoulos commented 1 year ago

Thanks for the immediate answer below is the result of rfsniff for button with codes: Received 39 bits (x2): 11 7a a4 02 aa Received 32 bits (x1): 22 f5 48 05

-----BEGIN RF433 LOW HIGH SEQUENCE----- , 30937 000 4244, 1488 001 360, 720 002 360, 720 003 724, 360 004 360, 720 005 360, 720 006 360, 720 007 720, 360 008 360, 724 009 720, 360 010 720, 360 011 720, 360 012 720, 364 013 360, 724 014 720, 364 015 360, 724 016 720, 364 017 356, 724 018 720, 360 019 356, 724 020 360, 724 021 720, 364 022 356, 724 023 356, 724 024 360, 728 025 356, 724 026 360, 724 027 356, 724 028 356, 724 029 356, 724 030 720, 364 031 356, 724 032 720, 364 033 356, 724 034 716, 364 035 356, 724 036 716, 364 037 356, 724 038 720, 364 039 356, 728 040 716, 7844 041 4840, 1500 042 356, 728 043 356, 728 044 716, 364 045 356, 720 046 356, 728 047 356, 728 048 716, 368 049 356, 728 050 716, 364 051 716, 368 052 712, 368 053 716, 368 054 352, 728 055 716, 368 056 352, 728 057 716, 368 058 352, 728 059 716, 368 060 352, 728 061 352, 728 062 716, 368 063 352, 728 064 352, 728 065 352, 728 066 352, 728 067 352, 728 068 352, 728 069 352, 728 070 352, 728 071 712, 368 072 352, 728 073 716, 368 074 352, 728 075 712, 368 076 352, 728 077 712, 368 078 352, 728 079 712, 368 080 352, 728 081 712, 7848 082 4832, 1500 083 352, 728 084 352, 732 085 712, 368 086 352, 732 087 352, 732 088 352, 732 089 712, 368 090 352, 732 091 712, 368 092 716, 368 093 712, 368 094 712, 368 095 352, 732 096 712, 368 097 352, 728 098 712, 368 099 352, 732 100 712, 368 101 352, 728 102 352, 732 103 712, 368 104 352, 732 105 348, 732 106 352, 732 107 352, 728 108 352, 732 109 352, 728 110 348, 732 111 352, 732 112 712, 368 113 352, 732 114 712, 368 115 352, 732 116 712, 368 117 352, 732 118 712, 372 119 352, 732 120 712, 372 121 348, 732 122 712, 7848 123 4832, 1504 124 348, 732 125 348, 732 126 712, 372 127 352, 732 128 352, 732 129 348, 732 130 712, 372 131 348, 732 132 712, 372 133 712, 372 134 708, 372 135 708, 372 136 348, 732 137 708, 372 138 348, 732 139 712, 372 140 348, 732 141 712, 372 142 348, 732 143 352, 732 144 708, 372 145 348, 732 146 348, 732 147 348, 732 148 348, 732 149 348, 732 150 348, 732 151 348, 732 152 344, 732 153 708, 372 154 348, 732 155 712, 372 156 344, 732 157 708, 372 158 348, 732 159 708, 372 160 348, 732 161 708, 372 162 348, 732 163 708, 7844 164 4824, 1504 165 348, 732 166 348, 732 167 708, 372 168 348, 732 169 348, 732 170 348, 732 171 708, 372 172 348, 732 173 708, 372 174 708, 372 175 708, 372 176 708, 372 177 348, 732 178 708, 372 179 348, 732 180 708, 372 181 348, 732 182 708, 372 183 348, 736 184 348, 732 185 708, 372 186 348, 732 187 348, 732 188 348, 732 189 348, 732 190 348, 732 191 348, 732 192 348, 732 193 348, 732 194 708, 372 195 348, 732 196 708, 372 197 348, 732 198 708, 372 199 348, 732 200 708, 372 201 348, 732 202 708, 372 203 348, 732 204 708, 7836 205 4824, 1504 206 348, 732 207 348, 732 208 708, 372 209 348, 732 210 348, 732 211 348, 732 212 708, 372 213 348, 732 214 708, 372 215 708, 372 216 708, 372 217 708, 372 218 348, 732 219 708, 372 220 348, 732 221 708, 376 222 348, 732 223 708, 372 224 348, 732 225 348, 736 226 704, 372 227 344, 732 228 348, 732 229 348, 732 230 348, 732 231 348, 732 232 348, 732 233 348, 732 234 344, 732 235 708, 372 236 348, 732 237 708, 372 238 344, 732 239 708, 372 240 344, 732 241 708, 372 242 348, 732 243 708, 372 244 344, 732 245 704, 7840 246 4816, 1504 247 348, 732 248 348, 732 249 708, 372 -----END RF433 LOW HIGH SEQUENCE----- Waiting for signal...

sebmillet commented 1 year ago

Hello

when throwing your timings into RF433any I get the below output: -----CODE START----- // [WRITE THE DEVICE NAME HERE] rf.register_Receiver( RFMOD_TRIBIT, // mod 29696, // initseq 4224, // lo_prefix 1488, // hi_prefix 0, // first_lo_ign 352, // lo_short 720, // lo_long 0, // hi_short (0 => take lo_short) 0, // hi_long (0 => take lo_long) 704, // lo_last 7808, // sep 39 // nb_bits ); -----CODE END-----

In the timings I can only see the 39-bit sequences, never a 32-bit sequence (I guess it comes too late, when recording has already ended).

The code above is fit for RF433recv. Some adjustments are needed for RF433send. That is:

[...]

include "RF433send.h"

[...]

TO BE UPDATED WITH YOUR SCHEMA

define PIN_RFOUT 4

[...] RfSend *tx; [...] void setup() { pinMode(PIN_RFOUT, OUTPUT); Serial.begin(115200); [...] tx = rfsend_builder( RfSendEncoding::TRIBIT, PIN_RFOUT, RFSEND_DEFAULT_CONVENTION, // Do we want to invert 0 and 1 bits? No. 5, // Sent five times nullptr, // No callback to keep/stop sending (if you want to send // SO LONG AS a button is pressed, the function reading the // button state is to be put here). 29696, // initseq 4224, // lo_prefix 1488, // hi_prefix 0, // first_lo_ign 352, // lo_short 720, // lo_long 0, // hi_short 0, // hi_long 704, // lo_last 7808, // sep 39 // nb_bits ); [...]

This'll produce timings similar to what you posted (repeated sequences of 39-bit code). In this case it is sent 5 times, you may adjust it - in your timings recorded I see the code show up at least 5 times.

About the 32-bit code that comes after

Generating the code is easy, you are to declare ANOTHER TX with its own parameters. As you can see only the number of bits differs.

tx2= rfsend_builder( RfSendEncoding::TRIBIT, PIN_RFOUT, RFSEND_DEFAULT_CONVENTION, // Do we want to invert 0 and 1 bits? No. 5, // Sent five times nullptr, // No callback to keep/stop sending (if you want to send // SO LONG AS a button is pressed, the function reading the // button state is to be put here). 7808, // initseq 4224, // lo_prefix 1488, // hi_prefix 0, // first_lo_ign 352, // lo_short 720, // lo_long 0, // hi_short 0, // hi_long 704, // lo_last 7808, // sep 32 // nb_bits );

and then invoke the two sendings one after the other. Keep in mind, tx object' send() method ensures the number of bytes provided is consistent with the number of bits declared in the constructor (39 bits -> 5 bytes, 32 bits -> 4 bytes). This is a kind-of "not-necessary" duplication of information that allows sanity check (defensive programming).

const byte data[] = { 0x11, 0x7a, 0xa4, 0x02, 0xaa };
const byte data2[] = { 0x22, 0xf5, 0x48, 0x05 };
[...]
byte n = tx->send(sizeof(data), data);
byte n2 = tx2->send(sizeof(data2), data2);

IMPORTANT One thing that I cannot be sure of is, what delay DOES SEPARATE the two codes. Is it 'initseq' (30000 us) or is it 'sep' (7800 us)? Given your first post, lines 4 and 6, my impression is that it is simply a separator (S=7834 line 4 ; I=0 line 6). But it is difficult to work it out. I suggest you do some trial-and-error here, trying to create tx2 with initseq=29696 instead of initseq=7808 or other values.

IMPORTANT (2) Actually I don't think you are receiving a secondary code... See:

When displaying your received codes in binary, I see the below.

117AA402AA_hex = 1000101111010101001000000001010101010_bin 22F54805_hex = 100010111101010100100000000101_bin

This means, the secondary code received is simply the first one, without the terminating 7 bits.

Ultimately I don't think you really have a secondary code. I'd rather say, the sending stops during the code sequence, after the 32nd bit.

Hope this helps,

Regards, Sébastien Millet

kavakopoulos commented 1 year ago

Hello again, Sorry for delaying the response. I played with various timings but it did not work. So I borrowed an oscilloscope to deep dive (hence the late response). Bellow is the picture which I believe explains a lot. First of all you were right about not being 2 codes but the same one cut at the end. The correct code is HEX 22F5480555 which is what you library receives as the second code but misses the final byte. It is 40 bits. Its seems that you library is confused due the first part and loses that last bit "1". In the beginning there is a looong high of 4250us followed by a looong low of 1500us. After that the real code follows of 40 bits with "1" being (720us high followed by 365us low) and "0" (365us low followed by 720us high). So in order to use your library what values do I put in prefix and should I put values in all // lo_short // lo_long // hi_short // hi_long ? Thanks again for being so helpful image

kavakopoulos commented 1 year ago

I used the following parameters and it worked. Thanks again for providing this library

RfSendEncoding::TRIBIT, PIN_RFOUT, RFSEND_DEFAULT_CONVENTION, // Do we want to invert 0 and 1 bits? No. 5, // Sent five times nullptr, // No callback to keep/stop sending (if you want to send // SO LONG AS a button is pressed, the function reading the // button state is to be put here). 0, // initseq 4250, // lo_prefix 1500, // hi_prefix 0, // first_lo_ign 365, // lo_short 720, // lo_long 0, // hi_short 0, // hi_long 0, // lo_last 7840, // sep 40 // nb_bits