Continuing previous parts about receiver and transmitter here.
Later addition: you can find sources here.
Previously I was working with controllable outlets, and those are now working nicely; I can control them remotely from home.
I had planned to integrate wireless temperature sensors operating on same 433 MHz band to the system. Since my system didn't seem to detect them, I had to open one up to see what kind of protocol it was using. It took me a moment to find the data pin (very different transmitter setup on board than with previous remote control), but finally I got data out from it:
Here yellow signal is (unmodulated) transmit output as probed from inside the sensor (well, very first part of it - full sequence is almost a second long) and green is demodulated data as given out by my receiver. You can once again see how noisy data signal from the receiver is when there is no data in (nearby) air.
I would guess that first yellow pulse, on left, should start transmit, and after that data begins. Receiver however doesn't receive first data pulse correctly, but I don't think that is a problem.
Looking more closely, this signal is quite different from signal sent out by outlet remote control. While it used PWM - pulse width modulation - this looks more like PPM - pulse position modulation. The positive pulses are all of same length - about 560us - but low pulse period between them changes, being either 1900us or 3800us (exactly double - not a coincidence!)
Obviously same receiver code that PWM uses doesn't work. So I just wrote parallel system that runs in same interrupt handler, in a way that they both try to figure out signals at same time.
In the end the logic to parse this PPM signal was something like this: (again, the interrupt handler triggers on both rising and falling edge transitions of signal, so I can process just that transition and exit interrupt handler so it doesn't eat up all the of MCU time)
-On idle, detect hi-to-low signal transition
-On next rising edge, check low period. If it is between (roughly) 1600-2200us, value is zero; if it is between 3500-4100us, it's one; otherwise it's spurious signal and receiver resets to idle.
Note that my choice of short period denoting 0-bit was arbitrary, it could have been inverse, but in this case my guess ended up being correct.
-Check that received high pulse is between 250-750us (due to relatively low resolution of my timer). If it's too short or long, again reset to idle.
-Repeat until 32 bits are received.
As with the PWM receiver, my code is very simple and resets receiver very aggressively to idle. This is again calculated choice; since the input signal is noise for 99+% of the time, I want to spend as little time - and MCU cycles - in the receive interrupt handler as possible. No point waiting to the end of bad data when I can minimize overhead by just rejecting it early.
In the end I receive usually multiple times same value, for example 921EC7A hex, and possibly some other values. At the interrupt handler I just put these received values in a temporary buffer. Sensor sends same value I think 8 times.
As the transmitter sent data for about 800ms total (all 8 repetitions), I set up one-second timeout (from first received value) to trigger final parsing. There I find the value with most copies listed in temporary buffer, and if there are sufficiently many (say, 3 or more of same) I can assume that was the correct value.
Now, to decode this. It helps a bit that sensor also has small display showing the current temperature so I don't have to guess as much.
For temperature of 24,0 C the corresponding received value was 921E0CE .
I got lucky and next reading was 23,9 C - value being 921DF20 .
Note that E0 and DF in middle are exactly one step apart. So I made a guess: lower 8 bits are something else, then follows maybe 11 bits for temperature. Thus decoded values ended up being 480 and 479 - doesn't sound right.
Okay, 9 lowest bits are something else? Bingo. Dropping highest bits, end result 240 and 239 exactly.
I have no idea what lowest bits could mean. There does not seem to be much of correlation between different readings so temperature in F or humidity are out. Possibly checksum? Humidity might have been nice, but expecting that from cheap sensor would have been too much. So far, I'm happy with just temperature anyway.
Received successfully.
Edit: Tested again with different type of temperature sensor, and receiver code didn't recognize it. Will need to see how it operates now...
