reception of last bit before separation window

[danyhm]

Hello,

First of all thank you very much for this library. it is way better than RCSwitch. I always wanted to write a library like this and then I stumbled upon yours. I'll modify it a little for my own needs.

there's an issue regarding the last bit of data. for example in hcs301 IC which is 66 bits it only detects 65 bits. I dug deeper into the code and found out that the bit detection algorithm is based on short and long detection of the signal level and only if the logic timing is correct then the bit is considered valid. So far so good. the problem with the last bit is that the consecutive rising edge doesn't happen until the next packet and this causes problems for the detection.

___----_________________[start of next packet]---__......

that is why it doesn't detect the last bit because once the signal level goes to 1 in the next packet the timings are incorrect for the last bit. surprisingly this doesn't cause an issue with EV1527 protocol because the last logic element is actually the start of the next packet and is outputted right after the last bit so the last bit is detected correctly.

have you implemented any way to detect the last bit in this scenario?

[sebmillet]

Hello

Re-checking the source code, I see that the tribit automat (similarly with with tribit-inverted one) we have:

{ W_CHECK_BITS,     AD_NB_BITS,        AD_NB_BITS,      14,   4 }, // 13
{ W_WAIT_SIGNAL,    ADX_ZERO,          ADX_ZERO,        15,   0 }, // 14
{ W_CHECK_DURATION, AD_LO_LAST_INF,    AD_LO_LAST_SUP,  16,   0 }, // 15
{ W_WAIT_SIGNAL,    ADX_ONE,           ADX_ONE,         17,   0 }, // 16
{ W_CHECK_DURATION, AD_SEP_INF,        ADX_DMAX,         1,   2 }, // 17

The important line is the last one, where you find ..., AD_SEP_INF, ADX_DMAX, ... This means, once the number of bits is obtained, the next timing should be at least equal to the separator or above (no high limit). In the source code you might "remove" this test by replacing the line with another line:

   { W_CHECK_DURATION, AD_SEP_INF,        ADX_DMAX,         1,   1 }, // 17

The last "2" is replaced with a "1" (meaning: the test is useless and always reaches successful end-of-decoding status).

This is all I can suggest. Obviously if instead you are using tribit-inverted, same idea.

Besides, are you sure your code is 66 bits? I find it odd, there's a good chance there are some "initialization" zeros at the beginning (and maybe in the end?) and the real code managed by the device is 64-bit long.

Regards

[danyhm]

Hi,

Thanks for the suggestion.

That's actually what i did to get the last bit.

And yes the device HCS301 sends 66 bits as per the documentation.

Just like the EV1527 sends 24 bits. The reaaon your code works without configuratuon for 24 bits is that right after the last bit the header for the next packet is appended which looks like a bit whereas in reality it's the next packet starting.

Regards,