Emanuele initially sent me a sketch he came up with for the Lacrosse TX3 sensor and I studied it really hard. It was very mind bending exercise to try and grasp some of the programming concepts I've never been exposed to before. All sorts of bit shifting and binary manipulations that I've never run into all my years of coding business applications. I added a bunch of comments to it try help and bring it down to my level. I also renamed a bunch of the variables but not because I was trying to take over the code but instead to help with my exercise of trying to learn the code.
Im thinking this code works differently than some the other decoding techniques because it is triggered by a long delay in the signal. That delay is the marker sent by the weather sensor to indicate that it's data has been sent. When the delay occurs then the contents of the buffer is evaluated by the code. The buffer is 88 bits long with each item of the buffer being loaded with the time value in microseconds when the 433Mhz receiver data pin interrupt occurs. This buffer is continuously written to and is constantly being rolled over.
When the buffer gets evaluated the starting index is what ever index it was being loaded when triggering delay occurred. If that delay is occurred when when index 12 was being loaded then indexes 12 to 87 and then 0 to 11 are evaluated in order. This concept of what I'm calling a rolling buffer is not something I'm used to. I'd expect to see an array filled up from index 0 until the end and then read from position 0 to the end. And then I'd expect that array to be cleared out each time it's filled up again. But not so here. And it works brilliantly.
I'm guessing this is good coding practices for embedded systems where lightweight and speed are primary considerations?
It took me awhile to understand that the code was evaluating all the time intervals for a certain pattern. That pattern is that a LONG or SHORT interval must be followed by a FIXED interval. A LONG followed by FIXED = 0 and a SHORT followed by a FIXED = 1. LONG, SHORT and FIXED are the microsecond intervals between the data pin interrupt changes. This pattern must exist across all 88 timings in the buffer. The microsecond length of time for these three intervals is not exact and have an allowable plus/minus fudge factor. I was not getting good results with the sketch until I started playing around with this fudge factor, PW_TOLERANCE in the code, and increased it. Then I everything started falling in place.
The breakthrough for me occurred when I dumped the entire buffer each time the triggering interval occurred. Dumping it the console was very wrong as there is no way the processor could keep up with the interrupts blasting away while also displaying the huge stream of data to the console. I'm guessing some other badness was also happening here with threading and memory that I don't even understand. But the dumping made it clear what pattern needs to be. Then I just commented that dumping code out.
I have mention I running this Photon so you'll need to fix the interrupt to get it working on Arduino again. Photon has built in wifi and can handle more libraries so it's alot easier for my skill level to post the weather data to a url.
attachInterrupt(RF_PIN, storePulse, CHANGE); //Photon
//attachInterrupt(digitalPinToInterrupt(RF_PIN), storePulse, CHANGE); //arduino
This is cool stuff to lean but boy is it tricky. Also should mention that Emanuele's code has now been tested on my side with TX4 and TX7 sensors in addition to his TX3.
WS8610Receiver.ino (9.69 KB)