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.
I didn't manage to do it yet. I also couldn't get the two libraries to work on same receiver unfortunately.
I can get the receiver on separate arduino and run it for sereral hours to get readings one by one with values, so they may vary a little. I'll do this today right after work.
andriej:
I also couldn't get the two libraries to work on same receiver unfortunately.
If your receiver has 2 outputs did you try connecting one to the weather sensor receive interrupt pin and the other to the remote interrupt pin and see if they work side by side?
I can get the receiver on separate arduino and run it for sereral hours to get readings one by one with values, so they may vary a little. I'll do this today right after work.
Thanks, but no hurry. I'm working all weekend so may or may not have time to play.
Code works - the third interrupt gets data. But - again - strange thing happens...
It reads the code only when sensor is very,very near the Mega.
On Uno it read without problems from outside.
andriej:
Code works - the third interrupt gets data. But - again - strange thing happens...
It reads the code only when sensor is very,very near the Mega.
On Uno it read without problems from outside.
I have no clue why it could happen now...
I can only guess the Mega is generating RF noise that interferes badly at 433Mhz. I'm not sure if you could test this by laying the Mega in a biscuit tin lined with something to prevent Mega shorting out and and lay the lid on top. Run the wires to the receiver outside of the tin. This wont stop all noise but may eliminate radiated RF. Beyond this you may need RF chokes but this is not my field and someone else may have better suggestions.
I got tired of wondering why it didn't work and I wired one of my nodes (used in room anyway) to weather station. Same scheme - DATA (pin2), GND-GND.
It works even better than on the receiver module (as it now gets a lot more readings).
It's getting readings ATM and will do overnight, but before that I saw same-readings with different CRC (only once happened so far):
Ok, so after almost all-night logging I've put up to the google doc (at the bottom, below arduino code): EZ6 Meteo Temp&Humi Sensor - Google Docs
all the values that didn't duplicate one by another (signal is so strong, that your code puts up like 5-6 readings at the time).
Also - strange thing (or we don't know everything). A lot of readings shows 'battery=0', but weather station doesn't report battery as 'low' (the indicator doesnt show up). Maybe the 'low batt' bit is hidden somewhere else?
Thanks for the extra data buy after looking for several readings that only alter by 1 bit in the data (not CRC) I cannot find what I'm looking for. It could take weeks to collect enough data to get the value I need and a long time sorting the data to find them.
Only idea I can think of is a little drastic if your not into soldering and that's to de-solder the temperature sensor so the temperature will never change and only humidity values will alter.
As to the battery indicator bit, yes this probably could be wrong. Does the base station have several degrees of battery power indication (like bars on a mobile phone battery indicator) or is it a simple good/bad indication? Powering the sensor from a bench PSU would allow accurate voltage adjustments and the battery indicator on the base station could be noted as the power is slowly decreased and the data captured. This would help narrow down the battery bit(s).