interesting protocol challenge

(8 posts) (3 voices)

Tags:

No tags yet.

twinkel
Hi all,
I bought a simple weather station a few days ago to play with the wireless moisture sensor (443 MHz). I have not been successful in decoding the data so I would like to ask you guys here if somebody is able to hint me in a good direction.
I have ookScoped the transmitter input to eliminate any radio problems and I seem to get some consistent data, but .... my data seems to consist of 4 different pulse widths (not counting the preamble and a small glitch following that) 976, 2048, 2304 and 2460 us.
Does anybody know a protocol that uses such a coding scheme? Here is a part of the data in 1 transmission, logged by JeeMon. I reformatted it a bit so that is (almost) seems logical. data = temp= 24,3C RH=23%
```
    P 9782 81 
    2304 976 2048 976 2048 976 2048 976 2560 
    976 2048 976 2048 2304 2048 2304 2560 
    2304 2048 2304 2048 976 2048 2304 2560 
    2304 2048 976 2048 2304 2048 2304 2560 
    976 2048 976 2048 2304 2048 2304 2560 
    2304 2048 976 2048 2304 2048 2304 2560 
    2304 2048 2304 2048 2304 2048 2304 2560 
    976 2048 976 2048 976 2048 976 2560 
    2304 2048 976 2048 976 2048 976 2560 
    976 2048 976 2048 976 2048 976 3840
```
There seem to be some patterns in the data and the length is consistent throughout a longer period. All blocks end with a 3840 us pulse and start with an almost 10ms pulse. Another correlation I found was that 2560 - 2304 = 256 and 2304 - 2048 = 256
Posted 21/06/2010 18:07:23
jcw

The "81" is not a glitch but a count of the number of reported intervals, IIRC.
What I've been doing (with far less accurate data than this), is to map these to ASCII strings, i.e. 976 = ., 2048 = -, 2304 = +, 2560 = | or something like that. Then you get lines of text. Try collecting a bunch of this while the readings change. Put them underneath each other. Sometimes you can see patterns, such as whether these things change in units of 4, 8, or 9 bits. And guess where checksums are, sometimes even see xor'ed individual checksum bits correspond to changes.
What sensor is this, btw?

Posted 21/06/2010 19:46:09
twinkel
This is from a cheap china brand from last weeks supermarket (BAS) offer in Holland. No real brand name (to prevent law suits from Thiery Mugler, who' s name is on the unit?). I call it PromOcean for now, after a name i found in the user manual.
Your suggestions made things a lot easier now. I made a command line version out of ookDecoder to experiment. Here's what I got after a few trials: 976=1, 2304=0, the rest seems to be sync stuff.
```
    01111 1100 1100 0100 1001 1000 0000 0010 1110 1111} 
    0000 0000 0000 0000} 
    01111 0100 1100 0100 1001 1000 0000 1100 1000 111100000 0000 0000 0000} 
             2    3    2   9    1
this is 23.2C and 19% RH. data is reversed BCD. All data is reported in reverse order actually.
```
The second line could have been part of the first line. Could it be that the JeeMon part of ookScope splits the data? So there may be actually just 2 lines, the first line reporting the values in the previous transmission. You can tell the temp dropped 0.1 degree in this report. The only thing that worries me now is the first bit (has 9 pulses).
Posted 21/06/2010 21:33:09
jcw

There's often a bit of preamble - fixed bits, to condition the receiver AGC circuit.
My guess from your example is that the 3rd digit is for 100% humidity (submerged? probably useless). Or perhaps a battery-low indicator, but I doubt it. And then two checksum "nibbles", perhaps? Maybe one of them is the xor of all the preceding nibbles, and the other is the sum of those same nibbles - that's one way of doing this sort of thing which I've seen a few times.
Yeah, other bit timing for syncing is possible. Or maybe a parity bit using different timing?
But hey, I think you've essentially nailed it. Congrats!

Posted 21/06/2010 22:51:23
jcw

Ok, looking again at your data, here's a guess: checksum 1 is sum of preceding 6 nibbles. Checksum 2 is xor of preceding 7 nibbles (i.e. incl checksum 1). Modulo some constants. All nibbles are in lsb-to-msb order, and all numbers are in low-to-high decimal order, as you said.

Posted 21/06/2010 23:05:51
twinkel
This is the current output from ookDecoder (running on linux command line, fed by tail out.tcl)
```
    P01+1+1+1|0+0+0+0|0+0+1+0|0+1+0+0|0+0+0+1|1+0+0+0|0+0+0+0|0+0+0+0|0+0+1+1|1+1+1+1<36>]P0+0+0+0|0+0+0+0|0+0+0+0|0+0+0+0+<52>]
    PROM 00000fc0018240
    24.0C 18% <0f c0 0>
```
```
    P01+1+1+1|1+0+0+0|0+0+1+0|0+1+0+0|0+0+0+1|1+0+0+0|0+0+0+0|0+1+0+0|1+1+0+0|1+1+1+10:1952::1456:0+0+0+0|0+0+0+0|0+0+0+0|0+0+0+0+<53>]
    PROM 00000f32018241
    24.1C 18% <0f 32 0>
```
I had to fiddle a bit with the data. figures between "<>" are pos counters for debug purposes. There are to numbers in there which I will leave for now. This is the output at the transmit end. Since the receiver output seems to give unreliable results, I will proceed further than this when I have a proper 433MHz receiver.
Posted 22/06/2010 19:59:44
twinkel

And here is the code, still a bit sloppy but hey, it works, for now! todo:
- always test on 01111 start data to reset the decoder.
- handle 2 unknown frequencies
- further investigate checksum
- further investigate 9th nibble, seems to have sth to do with battery and/ or restart
- further investigate channel coding
- test with link over 433MHz.
- port back to JeeNode (should go in there 1:1 as long as I leave the printf's out)

    class PromOceanDecoder : public DecodeOOK {
    public:
        PromOceanDecoder () {}

virtual char decode (word width) {

    #define DEBUG 1

// check 1-bit length = 2048, boundary -64 + 224

        // values seen: 2016 2048 1952 1920
        if (1984 <= width && width < 2272) {
            // this is inter bit sync
    #ifdef DEBUG
            Serial.print("+");
    #endif
            return (0);
        }
        else {	// check 1-bit length = 976, boundary -64 + 256
                // values seen: 1072 1104 1088 1200
           if (912 <= width && width < 1168) {
               // this is a "1"
               gotBit(1);
    #ifdef DEBUG
               Serial.print("1");
    #endif
           } 
           else { // check 1-bit length = 2304, boundary -64 + 128
                  // values seen: 2304 2368
              if (2240 <= width && width < 2432) {
                  // this is a "0"
                  gotBit(0);
    #ifdef DEBUG
                  Serial.print("0");
    #endif
              }
              else { // check 1-bit length = 2560, boundary -128 + 128
                     // values seen: 2496
                 if (2432 <= width && width < 2608) {
                     // this is a EOL
                     if((pos8+bits == 5) && (data0 == 0xf0) { // was this line a telegram start?
                        resetDecoder();
                     }
    #ifdef DEBUG
                     Serial.print("|");
    #endif
                 }
                 else { // check 1-bit length = 3840 - 64 + 64
                    if (3776 <= width && width < 3904) {
                       printf("<%d>", 8pos+bits);
    #ifdef DEBUG
                       Serial.print("]");
    #endif
                       if (pos > 5) { // concatenate 1st two blocks
                                      // iow add 0's block to 1st block
    //                         done(); // needed this before reverseNibbles  
                          reverseTelegram();
                          return(1);
                       }
                       else
                          return(0);
                    }
                    else {
    #ifdef DEBUG
	printf(":%d:",width);
                        Serial.print("");
    #endif
                    }
                 }
              }
           }
        }
        return 0;
    }
    };
And in class DecodeOOK, I added:

    void reverseTelegram( void ) {
        for (byte i = 0; i < ((pos)/2); ++i) {
            byte temp = data[i];
            data[i] = data[pos-1-i]; // remember, pos is 1 too far
            data[pos-1-i] = temp;    // swap 1st and last byte
        }
    }