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
No problem, just so others reading your post will not have issues. Glad the code works on your sensor with little modification. If your having problems working out temperature >25.5 then post a few readings with the displayed temperature and maybe someone can work it out for you.
Bizzarely I haven't experienced any temperatures above 25.5 in the recent past!
But I think these are some readings from the wrong side of 0 celsius:
1 1 1 1 1 1 1 1 1 0 0 0
-0.8
1 1 1 1 1 1 1 0 1 1 0 1
-1.9
1 1 1 1 1 1 1 0 0 1 0 1
-2.7
It kinda looks like an inversion of .1 of a degree less than the absolute of the actual reported temp. ie if you invert all the bits you get 7, 18 and 26 I think. I'll give it some thought.
Just for clarity, I'm not saying that the sensor only reads up to 25.5, only that it's simple to read, if it is in the range 0 to 25.5 becuase it occupies the eight bits between 16 and 23 as a straight forward .1 degree scale.
The bits between 12 and 15 are also included which allows readings greater than 25.5 and less than 0, it's just that I haven't worked out how to deal with that yet.
Have you got any further in trying to work out the CRC? I came across an interesting article here but to have a chance of calculating the Polynomial I need several consecutive readings that vary by only one bit between them. I had a look at all your results but cannot find enough samples to do this yet. I'm still trying though.