You transmitter sends 42 bits but the subroutine to display the data as binary only does 32 chunks so 2x 32 bit chunks displays 64 bits with leading zero's instead of just 42 bits.
Humidity is stored as low/high order nibbles. In the example above take the first 4 bits and tack them on the end of the next 4 bits. 11010101 becomes 01011101 that is 93 decimal. Not done temperature yet but it look like it's also split into nibbles.
Wow, Riva, I'm amazed of the knownledge you get here. I wouldn't manage to get that never, probably.
As I've written on google docs - temperatures may be in fahrenheit.
Sensor, after changing batteries, views temp. as F degrees. I have to push button on the back to switch to celsius - the data sent by transmitter doesn't change by that.
I also see about that you also used 'preamble' - do you know why would it change when changing batteries?
Usually I see the battery-indicator in the transmission as a "high"/"low".
Maybe it was too late for me (and I was tired) but there are more changes in bits than one-two in preamble part.
Looks like temperature is transmitted as 12 bits in 3x nibbles ranging from low to high nibbles. A fixed offset of 900 is applied to the temperature value so 0 degrees F = 900 and each degree F change is 10 decimal. In the example 001101000101 becomes 010101000011 that is 1347 decimal.
1347-900 = 447
447/10 = 44.7
44.7F = 7.1C
Riva:
The transmitter will probably generate a random number when first powered on (or batteries changed) and this will become all/part of the preamble.
I'm not sure about this, because - how its possible to sensor to generate the same number again when putting back 'normal' batteries?
As you can see from here (and I don't know if I cut the lead 'zeroes' properly) - we have the same preamble after tries with 3 other sets of batteries.
Compare: "starting point" and "typical setup" - preamble is the same.
0001010111 01010011010001011101010110011000 - your preamble (7,1, RH93%)
0010100100 00011100010001100000001000000001 - starting point
0000101111 10010010001101100111001000001010 - battery + old ni-mh
0010101101 00011100001101100101001010001010 - used battery (1 GOOD, 1 'used')
0011110101 00010111010001100100001010001011 - used battery (1 GOOD, 1 nimh used)
0010100100 00011100010001100011001010000110 - typical setup (2AA varta batt.) (same as "starting point")
Great job with the temperature - as I see the biggest problem will be the code.
Temp*C RH% -Preamble- BC CH Temperature- Humidity --CRC?--
BB CC LLLLMMMMHHHH LLLLHHHH
7,1*C 93% 0001010111 01 01 001101000101 11010101 10011000
I still wonder if first 8/10 bits are random number used as device ID
BC looks like 2 bit battery condition
CH is channel number from switch position?
Have not figured out the CRC yet but that's what I assume it is.
Riva:
I still wonder if first 8/10 bits are random number used as device ID
BC looks like 2 bit battery condition
CH is channel number from switch position?
Have not figured out the CRC yet but that's what I assume it is.
CH is indeed 3 position switch behind the sensor. Currently I use it on CH2 because on CH1 there's some sensor near used by neighbour and i got 2 readings (but can't reach them lately).
The device ID - look at the google document here: EZ6 Meteo Temp&Humi Sensor - Google Docs
I've marked yellow the moment, that (what you assume BC is) changes.
Batteries didn't change by that moment, the only thing that changed was the sensor was held by me in hand and I was pushing "transmit" button all the time to get near-readings every fewteen seconds.
The other thing is, that on the most of the readings on that document i cut out all leading 'zeroes' which i assume was a mistake now.
But all the same readings are in post above here - i'll paste them back there.
andriej:
CH is indeed 3 position switch behind the sensor. Currently I use it on CH2 because on CH1 there's some sensor near used by neighbour and i got 2 readings (but can't reach them lately).
The device ID - look at the google document here: EZ6 Meteo Temp&Humi Sensor - Google Docs
I've marked yellow the moment, that (what you assume BC is) changes.
Batteries didn't change by that moment, the only thing that changed was the sensor was held by me in hand and I was pushing "transmit" button all the time to get near-readings every fewteen seconds.
Cold temperatures degrade the battery output. You did not change the batteries but the temperature is steadily climbing and the batteries power output with it. This is probably why the BC condition changed like this.
The other thing is, that on the most of the readings on that document i cut out all leading 'zeroes' which i assume was a mistake now.
The data packet looks to be 40 or 42 bits long (see image) so as long as your keep 42 bit there is no problem trimming off the leading zeros
But all the same readings are in post above here - i'll paste them back there.
I've reedited the google document now to get easier group-readings (and see the battery easier):
I don't know if its possible (or used ever before), but maybe the battery sensor reading is 3 bits left of CH?
So, by:
5,7*C it was outside: 101 - dec: 5 (out of 10?)
inside, got a little warmer:
110 - dec: 6 (out of 10?)
later readings all are 6/10 (batteries are outside for 2-3 months already, and it is winter now)
then i started manipulating with batteries and other reading:
100 - dec: 4 (weaker battery, got a little stronger last read)
and after all the mess i threw sensor outside again and the last read noticed is:
010 - dec: 2 which messes all my theory... (or maybe it's 10 - 2/10? so battery is 8/10...)
Edit:
Also, about CRC.
Assuming it's again LLLLHHHH, the only values I see on LLLL are:
The CRC has me stumped. Though it might not be a CRC! Program code I wrote should be fairly robust as it reports 2x consecutive matching reads.
But here is what I see sofar.
I've just added some new regular readings, without touching the sensor outside. CH2, temperature around 2.7*C on last read, humid 80%.
In the doc: EZ6 Meteo Temp&Humi Sensor - Google Docs
Riva made some updates to the code, testing it right now. We thought we caught the battery bit... But I've found 2 nimh accu's loaded with around 1,2V and had 2 good 1,46V batteries for comparison.
Just look at the payloads in the code below or under the doc: EZ6 Meteo Temp&Humi Sensor - Google Docs
I don't get a thing... it looks like whole payload is random except two leading zeroes...
It's even more strange because on one pair I caught a "low battery" indicator on weather station.
I also managed to put sensor in cold place (around -13*C degrees) - everything is below...
I got almost-succesful one lucky-shot of CRC calculation, but I couldn't repeat it with others...
I summed up values of: Random + CH-dec + tempF (the after-dot value) and HUM - the number altogether was 1-2dec different from CRC (CRC 137, value 138).
Also one strange thing - same CRC, same temp and HUM, different binary?!
I give up trying to figure out the CRC.
As such a small change like flipping the bits of the transmitter channel can make such a large difference to the CRC I can only guess it's a proper CRC system instead of the usual simple byte sum methods. Way beyond my maths skills to work it out.
These sensors use a slightly different protocol with a 36 bit packet length with no humidity information. These are the changes I made to extract the temperature info from the packet:
in the definitions:
const unsigned long bit1_MIN = 2300;
const unsigned long bit1_MAX = 2700;
const unsigned long bit0_MIN = 1330;
const unsigned long bit0_MAX = 1730;
const unsigned long sync_MIN = 4300;
const unsigned long sync_MAX = 4700;
const unsigned long glitch_Length = 300;
In the loop section:
if (bitRead(isrFlags,F_GOOD_DATA) == 1) {
// We have at least 2 consecutive matching reads
myData0 = read_Buffer[0]; // Read the data spread over 2x 32 variables
myData1 = read_Buffer[1];
bitClear(isrFlags,F_HAVE_DATA); // Flag we have read the data
dec2binLong(myData0,4);
dec2binLong(myData1,32);
Serial.print(" Temperature=");
int Temperature = (myData1 >> 12) & 0xFF; // Get Temperature word by shifting 12 bits to the right
Serial.println(Temperature/10.0,1);
}
I'm not 100% sure about all the bits in the packet but I get the temperature reading pretty well all the time.
Bits 0-7 are a random ID, bit 8 battery state and three other unknown bits.
The temp data is in bits 12-23. For temps between 0 and 25.5 degrees, bits 16-23 contain the temp in .1 degree increments.
All I have to do now is figure out what to do when the temperature turns negative or goes above 25.5 degrees and the temp info spreads out to 12 bit instead of eight. I think it's a twos complement or something like that. At the moment it works for a single byte temp reading for temps between 0 and 25.5 celsius.
Glad it's working for you with a few small modifications.
Did you also change #define allDataBits 42 // Number of data bits to expect
to 36 else I would expect it to never set F_GOOD_DATA