Go Down

Topic: Decoding of Froggit WH5300 Weather Center (Read 39422 times) previous topic - next topic

robwlakes

#15
Jul 28, 2014, 01:16 pm Last Edit: Jul 28, 2014, 03:10 pm by robwlakes Reason: 1
Alert: Make sure you download the latest one, the earlier version had a tricky bug that I have eliminated
DebugManchester.ino at
DebugManchester.ino

Another thing that has come to my attention is that the cheaper 433MHz Rx's have slow AGC and you may find that a stronger TX closer to the RX will cause weaker signals from sensors to be lost as the AGC does not recover in time to give them a fair go, so to speak in ultra scientific lingo!  Try the Dorji line: RF-DRA886RX-S Dorji 443MHZ 107 dBm ASK Receiver, SMD Package  

Cheers, Rob
Learning Flute and C++, heading for a meltdown.

saschak86

#16
Jul 28, 2014, 04:20 pm Last Edit: Jul 28, 2014, 05:18 pm by saschak86 Reason: 1
Hey Rob,

sorry for the late answer to the great answers you posted - been busy offline this weekend  XD

I got a feeling my setup really mixed up some sensors/transmitters in my range so I went ahead and recorded directly on the transmitter inside the sensor-array (btw, it's got wind (speed, direction), rain and temp/humidity. There's also a version with DCF-77 (atomic clock broadcast) around which I don't have...)

I now have leads soldered to the receiver inside the station in order to see the same data as the central. Turns out that the receiver is powered on and off in about 45s intervals. Just after power on of the receiver circuit, data arrives and the receiver is shut down again.

Long story short, I recorded the same scheme so that's giving me trust enough to proceed :)

With your new Sketch, I could not get any data to display  =(

Attached is another recoding of the data. I'd be really grateful if you could take a look at that capture and apply some if your wisdom to it  ;) In the meantime, I'll be busy trying all sorts of settings on the stuff I received (btw, would really be cool to 'save a recording' and apply other settings and see if it works better - waiting a minute every time is really a show-stopper  :smiley-red:)

Cheers,
Sascha

PS: I'm from Germany

EDIT: I tweaked inside the logic analyzer software and applied a Manchester analyzer with these settings: Mode: Manchester, Bitrate 800 Bits/S, Negative Edge is binary one, 8 bits per Transfer, LSB first, 0 bits preamble, 25% tolerance - starting to analyze at the first bit looking like manchester. Attached is the updated logic-file and an CSV export (well, not usable right now I guess)...

EDIT2: I added
Code: [Select]
          Serial.print("HEAD: ");
          Serial.println(headerHits);

where it throws an header error
          noErrors=false;//landing here means header is corrupted, so it is probably an error
to see what the sketch thinks of the header. I merely got numbers greater than 2 in there, so I think the timing is far from perfect. Also the great difference in timing between the first and the second part of the received data is a mystery to me  :smiley-roll:

saschak86

Hey Rob,


Germany eh, that sounds awkward for a quick turn around of ideas, beside you guys would still be busy celebrating the World Cup wouldn't you?  :)  A bit like having to wait 45 seconds to get data each time.

Hahaha, nice analogy :) Well, the spirit disappeared too fast and everyday life took over soon after winning :( But as thing go, maybe we will sport the next world cup again http://www.euractiv.com/sections/global-europe/german-politicians-mull-moving-2018-world-cup-russia-303719 - shame on the politicians here  :0

I did exactly as you wrote - increase delays and then changed polarity. Please see MassiveData.txt.

Using a delay of 1/4 bitWaveform 260 uSecs 1/2 bitWaveform 520 uSecs, I found good-looking data:
Code: [Select]
D 55 01010101 55 01010101 56 01010110 AA 10101010 AA 10101010 AD 10101101 EA 11101010 AB 10101011 55 01010101
D 5B 01011011 FF 11111111 6D 01101101 5A 01011010 AB 10101011 6B 01101011 7A 01111010 FB 11111011 55 01010101


Continuing from this, I counted the leading ONEs until 11 appeared (at 5555) and applied them (=10) to headerBits. Now I get every time a single valid datagram :) I know, it's only valid because of it's header ;)

Now I got some data... look at this *smile*
Code: [Select]

D 00 00001111 01 22223333 02 44445555 03 66667777 04 88889999 05 AAAABBBB 06 CCCCDDDD 07 EEEEFFFF 08 00001111 90 22223333
D 6D 01101101 5A 01011010 AB 10101011 6D 01101101 56 01010110 BD 10111101 AA 10101010 AA 10101010 AA 10101010 AB 10101011 AA 10101010 AA 10101010
D 6D 01101101 5A 01011010 AB 10101011 6D 01101101 5A 01011010 BD 10111101 AA 10101010 AA 10101010 AA 10101010 AD 10101101 55 01010101 55 01010101
D 6D 01101101 5A 01011010 AB 10101011 6B 01101011 F5 11110101 EE 11101110 AA 10101010 AA 10101010 AA 10101010 DA 11011010 AA 10101010 AB 10101011
D 6D 01101101 5A 01011010 AB 10101011 6D 01101101 56 01010110 BD 10111101 D5 11010101 55 01010101 55 01010101 5A 01011010 AA 10101010 AA 10101010


Do I now have to experiment with maxBytes? Or didn't I get it yet :)

Thank you very much and greetings to the outback  :D
Sascha

saschak86

#18
Aug 07, 2014, 05:49 pm Last Edit: Aug 07, 2014, 05:55 pm by saschak86 Reason: 1
Hi Rob,

sorry to let you wait on this, been busy and just found some time.

I've laid the sender on my desk and fixed wind direction and speed sensors. Also Rain sensor is fixed so only temperature and humidity may change automagically ;)

Additionally, I've patched 2 wires to the sender directly - GND and Signal before the SAW resonator.
I'm getting good values with this sketch:
Code: [Select]

int pushButton = 8;

// the setup routine runs once when you press reset:
void setup() {
 Serial.begin(115200);
 pinMode(pushButton, INPUT);
}
int old;
unsigned long dur;

// the loop routine runs over and over again forever:
void loop() {
 // read the input pin:
 int buttonState = digitalRead(pushButton);
 if (buttonState != old) {  // print out the state of the button:
  Serial.print(old);
  Serial.print(" ");
  Serial.println(micros() - dur);
  old=buttonState;
  dur=micros();
 }
}


Here's a packet (State and duration in micros):
Code: [Select]

0 29014452
1 100
0 736
1 308
0 824
1 300
0 804
1 300
0 812
1 300
0 816
1 300
0 812
1 300
0 812
1 292
0 812
1 308
0 808
1 1280
0 752
1 300
0 812
1 1288
0 752
1 1280
0 752
1 300
0 820
1 300
0 812
1 308
0 816
1 304
0 812
1 1296
0 752
1 1280
0 744
1 308
0 812
1 1280
0 756
1 1280
0 744
1 300
0 812
1 1288
0 740
1 304
0 808
1 1288
0 748
1 1288
0 752
1 1280
0 752
1 1296
0 744
1 1284
0 752
1 308
0 812
1 300
0 820
1 1280
0 744
1 1280
0 752
1 300
0 804
1 304
0 808
1 304
0 812
1 300
0 812
1 1288
0 740
1 300
0 816
1 1288
0 752
1 1288
0 744
1 1288
0 752
1 1296
0 744
1 1280
0 744
1 1296
0 740
1 1284
0 744
1 1296
0 740
1 1280
0 752
1 1280
0 752
1 1288
0 752
1 1280
0 752
1 1296
0 748
1 1280
0 752
1 1288
0 740
1 1288
0 744
1 1284
0 736
1 1280
0 756
1 1288
0 752
1 1280
0 752
1 1288
0 752
1 1288
0 752
1 1280
0 752
1 1280
0 744
1 1280
0 748
1 1296
0 736
1 1280
0 744
1 1296
0 748
1 1284
0 744
1 1288
0 756
1 1292
0 744
1 1280
0 752
1 1288
0 744
1 1272
0 752
1 1280
0 748
1 1284
0 752
1 304
0 820
1 300
0 812
1 1296
0 748
1 1284
0 744
1 300
0 820
1 1292
0 752
1 296
0 816
1 1288
0 748
1 296
0 820
1 1284
0 744
1 1280
0 752
1 300


Can you see anything? Perhaps settings for your sketch?
Meanwhile, I'm trying your perfects sketches on this setup :)

Thanks
Sascha

EDIT: Just analysed count and duration over a few telegrams. May data be encoded in the length of the ones and zeros?
Code: [Select]
    2 108
   2 312
   2 824
   3 100
   3 1304
   4 1276
   5 760
   9 1272
   9 296
  10 292
  17 736
  17 804
  21 1292
  22 808
  23 756
  23 816
  27 740
  33 1296
  33 308
  35 1284
  39 304
  48 820
  67 748
  80 812
  98 300
116 744
154 1280
156 1288
162 752

robwlakes

Hi Sascha,
I have had a look at you timing data.  I am really impressed with the results you got from your approach of directly connecting to the Sensor's serial signal.  The program is simple and I have only one suggestion with it, is to separate the two numbers with a comma (see attachments). This means the timing data can be copied really easily into a CSV format file.  My Python 2.7 program (attached) reads the timing results and plots it into a graphic that can either be annotated in an image editor or on a printout.

The graphic really shows how good your timing data is, very very nice!!!  No noise at all, lovely!!

Now to the graphic, what does it mean?  Well I think I means we are not dealing with Manchester Protocol.  The spacings appear have a common unit duration, and the other durations between transitions are either single, doubles or triples of that basic unit.  In Manchester only singles or doubles occur.  I reckon yours is one of the other protocols so you may be lucky and have someone on the forum recognise it and point you in the right direction and provide you you with an almost ready made solution, or alternatively you will be on your own cracking and decoding the code.  My programs will be of little immediate use though they do have features that are worth adapting.  Try searching on bi-phase data???

As yet I can't put one's (apart from what appears to be the header) and zero's against the graphic, so I guess it is up to you.  I know it will torment me until either you, or me, or someone else, cracks it. So I have not given up, but it is not immediately obvious to me.

Thanks again for that simple little program and the direct connect idea, nice one!!!  Very powerful idea.

Over to you,  :)

Rob

Learning Flute and C++, heading for a meltdown.

saschak86

Wow - I'm amazed of that python goodness. I've tried to change the code to implement something like http://en.wikipedia.org/wiki/Bipolar_encoding so as to correct timings by, say, 20% and graph it again.

However, after 2 hours, I've not been successful on installing pillow/image neither on mac nor debian  =( May I kindly ask you to graph the data again with the bipolar encoding?  :smiley-roll-sweat:

Thanks for your support - me neither getting released until this is done  :smiley-mr-green:
Sascha

robwlakes

#21
Aug 08, 2014, 02:57 pm Last Edit: Aug 12, 2014, 02:13 am by robwlakes Reason: 1
Hi Sascha,
I think my program merely shows (from your excellent timing data) what the ideal waveform would look like. So it can't be easily adapted to particular protocols (though it could be used to "proof" a particular decoding strategy, however this would take a fair bit of time and at the moment I don't know quickly how I would change it), but it at least shows visually what the decoding program in the Arduino will have to deal with.

Just taking a wild shot in the dark I am suggesting in the attached graphic that it maybe, just maybe
Edit:
750uS Lo followed by 300uS Hi is a "1"
750uS Lo followed by a 1300uS Hi is a "0"  

(NB just taking rounded number guesses from your list of timings below to illustrate my thinking)

Anyway have a look at the graphic. You would need to capture more packets and know what the readings were on the console each time you got a packet to see what changed and what stayed the same.  Your method of capture is ideal to grab nice clean packets so well!!  What a tool?!

I am not particularly happy about the numbers above and happy to be proven wrong, but I make this suggestion as an indication of the way you will need to think to crack it.

ie assume there are 1's at the start then a 0, so then look at how the data repeats and how the pattern survives later on in the packet, does it make sense?  Pls try other ideas as well, don't take this as gospel, at this stage.

Cheers, Rob

Learning Flute and C++, heading for a meltdown.

robwlakes

#22
Aug 09, 2014, 08:15 am Last Edit: Aug 12, 2014, 02:11 am by robwlakes Reason: 1
Back to it again...

I have written down the 1&0s packet I attached as a graphic as there are two things that worry me about my attempt at decoding your packet.

Here is the binary -
Code: [Select]
11111111 header
first zero included in bytes
0100111100100101
0000011001111010
0000000000000000
0000000000000000
0000110010101001

Edit:  the number of bits here I reckon are wrong.  I think it should be 79 bits (including the sync 0 at this stage).

First is the number of Zeroes in the packet, however this could reflect the fact the weather station is on the bench which means wind speed and say wind gust if it sends that as well (Oregon Scientific does) will all be zero.

The other problem I have with my solution of (Edit:) 800lo followed by 300hi ==1 and 800lo followed by 1300hi==0 is that these values are not going to have exactly equal hi to lo times and hence alter the bias of the signal.  If there were a reasonable ballance of 1&0s in the packet it would not be too bad, however for packets where the packets was mainly 0s (as above) or 1s then the bias would be altered away from the mid point.  (Higher in the case of many 1s and lower in the case of many 0s)
Just to check it I also ran a spread sheet on to check the numbers
Code: [Select]

111111111
0100111100100101
0000011001111010
0000000000000000
0000000000000000
0000110010101001

Edit:Please check more recent analysis

Short =301.5uS, mid=768.8uS and long=1285.6uS, so my guess was not far out.

I have included a Spread sheet analysis according to my logic in the last post and this one.  
It shows
Code: [Select]
Value of each nibble (including sync 0)
4 15 0 2 0 5 0 0 0 6 0 7 0
10 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 0 9 0 5 0 0

Edit:Please check more recent analysis
So what you can do (if you agree with my process of decoding the bit pattern, and at this stage my suggestions are indeed high speculative and I could be shot out of the water at any time! eg we were originally working on it being Manchester  :~) is capture more streams of data (say changing only rainfall) using your nifty approach and copy them into the spread sheet for convenient processing and see what numbers it throws up relative to the console.  I could add to the python program if you like to do it, now that I have gone through the logic in the spread sheet.

Then copy the CSV version of the timings into the right position in the spread sheet and it should do the calculations for you.  Are you comfortable with spread sheets?  You will have load the CSV into a blank spread sheet to begin with and then copy the resulting two columns on the left into the spreadsheet I have given below.

Cheers,
Rob
PS For you convenience don't forget to add the comma into the Arduino timing program.  It will make the CSV stage so much easier.
Learning Flute and C++, heading for a meltdown.

robwlakes

#23
Aug 09, 2014, 10:22 am Last Edit: Aug 10, 2014, 04:12 am by robwlakes Reason: 1
Hi Sascha,
Can you run Python 2.7??

If so I have whipped a few more extras into the program so it prints the 1&0's onto the graphic and also calculates the binary and bytes and reports in decimal at the end of the run.

If and only if, we are on the right track  :smiley-roll-sweat: this could allow you debug a few listings with known settings and verify a bit about the protocol before trying to do the whole thing directly with the Arduino. ie prove the logic, byte boundaries and position of sensor values and whatever processing might be required if possible.

Otherwise post a few and I will run them through for you. Here is a sample....
Code: [Select]
Data in Binary
[1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 0, 0, 1, 1, 1, 1, 0, 0, 1, 0,
0, 1, 0, 1, 0, 0, 0, 0, 0, 1, 1, 0, 0, 1, 1, 1, 1, 0, 1, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 1, 0, 1, 0, 1, 0, 0]
Data in Decimal Bytes
[79, 37, 6, 122, 0, 0, 0, 0, 25, 80]


Cheers,
Rob
Learning Flute and C++, heading for a meltdown.

saschak86

#24
Aug 10, 2014, 10:16 pm Last Edit: Aug 11, 2014, 05:42 am by saschak86 Reason: 1
Hey Rob,

attached are many, many telegrams of the unit with only changing temperature and humidity. I have not yet had the time to analyse this further but it would be very helpful if you could render those with your python script  ;)

Inside the csv is a comment at the end  where I rotated the wind speed sensor in order to see the changing bits - hopefully this helps :)

THANK you very much for your support  8)

Kind regard and thank you in advance  :smiley-sweat:
Sascha

EDIT. got it  8) Here's my python script to analyze the data. the data really seems to be in the length:
Code: [Select]
 1 import sys
 2
 3 def parse( str ) :
 4     list=str.split(',')
 5     bin=list[0]
 6     len=list[1]
 7     len.strip()
 8     bin.strip()
 9     len=int(len)
10     if len > 100000:
11       print
12     elif len > 1200:
13       sys.stdout.write("0")
14     elif len > 780:
15       sys.stdout.write("1")
16     elif len > 175:
17       sys.stdout.write("0")
18     else:
19       sys.stdout.write("!")
20     return
21
22 with open("froggit.csv") as f:
23     for line in f:
24         parse (line)
25


Length to binary state was examined by these codes:
Code: [Select]

$ cut -d, -f2 froggit.csv | sort -n  | uniq -c
$ grep 2.. froggit.csv # what data is when duration is around 200us? == 1
$ grep 800 froggit.csv # same for 800us == 0
# same for 1200us and very low (<200)

Attached is my previous samples file, notice the last line where the wind speed sensor was actuated... seems to get to the point, tomorrow ;)

robwlakes

#25
Aug 11, 2014, 04:11 pm Last Edit: Aug 12, 2014, 02:06 am by robwlakes Reason: 1
Hi Sascha,

I have processed the printouts for you.  I have run off a list of decimal results and a binary set of results.  I think this will help you pick the trends in the numbers easier.  It is not too much trouble t convert one to the other if you need to crosscheck them (I did have a printout with the Binary followed by the equivalent in Decimal combined but it all looked rather too busy.

I tend to to agree with you that it looks like the data is encoded with different on times to off times, but we, or you, I should say are now down to the pointy end of the process in trying to match the readings to the displayed values on the console.  I tried to match up where you entered the comment about the wind sensor, I believe I have got it right

It is possible that the protocol does not run a packet to a whole number of bytes (ie all multiples of 8 bits).
Code: [Select]
eg last one with Wind sensor???
[0, 1, 0, 0, 1, 1, 1, 1,
0, 0, 1, 0, 0, 1, 0, 1,
0, 1, 0, 0, 1, 0, 0, 0,
0, 1, 1, 0, 1, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
1, 0, 0, 1, 1, 0, 1, 0,
0, 0, 0, 0, 1, 0, 0, 1,
0, 0, 0, 0, 1, 1, 0]
79 bits I make it

I believe there is 79 bits (including the sync 0) in a packet.  Curiously the first byte in the packet is 79 as well (again if the sync 0 is included). A bit weird and makes me feel a bit uneasy.  It would be interesting to to try one before battery removal and after  batteries are replaced.  That may reveal the rolling code??

I have attached the printouts for the decimal and binary versions of the list of timings you sent me. (And just for the hell of it the graphics of the same  8))  The graphics were quite important in debugging the 79 bits.  I could not figure out why the last bye in every packet was even when some finished in 1 and it was because (I reckon we don't have an 80th bit) it was the 79th bit, ie no LSB.

Plus I have changed my mind about the durations and what they mean, I think it is
lo 750, high 1300 ==0  (rather than the other way around)
lo 750, high 300 ==1   as it makes the last time duration make sense. See attached graphic).

Once again though I am still hesitant to declare victory over the decoding into bits just yet. I am still not convinced these number are right, only your console readings can help.

What do you think??

Rob
Learning Flute and C++, heading for a meltdown.

robwlakes

Hi Sascha,

Found this on our ebay http://www.ebay.com.au/itm/Wireless-Personal-Home-Forecast-Weather-Station-Indoor-Outdoor-Temperature-/390600704243?pt=AU_Gadgets&hash=item5af19dc0f3&_uhb=1

It is quite an impressive compact unit. No looping wires or separate stands etc All on the one pole.  Well worth working on.

I make it from the above advertisement that the outside sensors gather wind speed, wind direction, rainfall, temperature and humidity? So we are looking for five readings in ten bytes. MMMh! a bit cramped if we take one out for check sum (yet to be proved), one byte for rolling code (assuming they are whole bytes), one byte for station ID (maybe not necessary, all the sensors are in one unit).  That would leave less than six bytes (maybe 8 I guess) for 5 sensors.  It does not seem to have separate messages per sensor eg a packet one time might have wind speed and direction and the next time the packet carries temp and Hum, and the next time carries the rainfall.  (The Bios/Thermor did it that way).  The packets don't change much, but that is to be expected seeing it is currently lying on your table where the "weather" would be pretty calm (I hope  :) )

If the zeroes in the middle are the wind speed data it is taking up a few bytes, 3 in all. The direction could be  at a zero direction.  But when you changed it last time not much changed.  I just can't help feel we are barking up the wrong tree?

Rob
Learning Flute and C++, heading for a meltdown.

saschak86

Hi Rob,

that's my unit you found on there ;) ... and now: here's the magic:
Code: [Select]

import sys

msg=""

def analyse() :
    global msg

    # Strip header
    print msg
    msg=msg[8:]

    # Strip id
    id=hex(int(msg[:12], 2))
    print "ID:   ",id
    msg=msg[12:]

    # Temperature
    temp=msg[:12]
    temp=float( int(temp, 2) - 400 ) / 10
    print "Temp: ",temp
    msg=msg[12:]

    # Humidity
    humi=msg[:8]
    humi=int(humi, 2)
    print "Humi: ",humi
    msg=msg[8:]

    # strip average wind
    msg=msg[8:]

    # gust speed
    gust=msg[:8]
    gust=int(gust, 2) * 0.34
    print "Gust: ",gust
    msg=msg[8:]

    # strip unknown nibble
    msg=msg[8:]

    # rain 3 nibbles
    rain=int(msg[8:], 2) * 0.3
    print "Rain: ",rain
    msg=msg[12:]
   
    # unknown
    msg=msg[4:]

    # wind direction
    dir=int(msg[4:], 2)
    print "Dir:  ",dir
    msg=msg[4:]

    print
   
    return

def parse( str ) :
    global msg
    list=str.split(',')
    bin=list[0]
    dur=list[1]
    dur.strip()
    bin.strip()
    dur=int(dur)
    print dur," ",
    if dur > 2000:
      if len(msg) > 15:
        analyse ()
      msg=""
    elif dur > 1200:
      msg+="0"
    elif dur > 700:
      #msg+="_"
      test="OK"
    elif dur > 200:
      msg+="1"
    elif dur > 75:
      msg+="1"
    return

with open("froggit.csv") as f:
    for line in f:
        parse (line)

analyse ()


froggit.csv was created with the edited sketch you provided. Here's a sample output:
Code: [Select]

148   800   316   804   296   816   304   804   300   812   300   812   304   808   304   808   300   812   1288   748   296   816   1280   748   1288   752   304   808   308   812   300   820   300   816   1288   744   1296   752   296   812   1292   752   1280   748   308   808   1280   752   300   804   1284   752   304   804   1288   748   300   820   304   812   308   812   300   820   1280   760   1288   744   300   820   308   808   1280   752   308   812   1288   744   1288   748   1280   744   1288   748   1288   752   1284   752   1288   748   300   820   304   812   1288   752   1292   740   1280   744   1288   748   1280   744   300   812   292   820   1288   744   1288   748   1288   752   1288   756   1280   752   1288   740   1280   748   1288   744   1280   752   1280   744   1288   756   300   820   1284   744   1288   744   308   816   304   808   1288   740   300   812   1288   744   1280   748   1288   744   1280   756   1280   752   300   820   1288   748   1292   752   292   812   316   812   1280   752   1280   744   292   820   1288   740   1280   752   300   1111111110100111100100101010111100110100000001100000110000000000010011010000010011001001
ID:    0xa79
Temp:  28.7
Humi:  52
Gust:  4.08
Rain:  367.5
Dir:   9

First is the durations of bits.
Second line is the translated binary data.
Next up is the analysed stream.
Several bits are still left, but I'm done here and have the unit connected to my http://www.openhab.org  8)

Thank you very much for your efforts! I'm now up to a new topic: my remote controllable RGB LED strip with this controller: http://www.amazon.de/RGB-LED-Controller-Touch-Funkfernbedienung/dp/B00B39C1WW and with the knowledge acquired here, I'm looking forward to post the results in this forum  :)

Kind regards
Sascha

robwlakes

Very Nice work Sascha,

I am not sure how the 79 bits all panned out with the calculations.  One of the calculations appears to be using 8 bits in the calc but then increments the pointer in the string by 12 bits?

Code: [Select]
# rain 3 nibbles
    rain=int(msg[8:], 2) * 0.3
    print "Rain: ",rain
    msg=msg[12:]
   


Could you fill out/correct this for me so I have a clear idea what is what.  Here is my attempt at a summary.

Code: [Select]
Conclusions:
* Protocol has no polarity and is based on length of time of signal bursts
* Best thought of as (750uS lo,300uS hi)=1, (750uS lo, 1300uS hi)=0
* Most of the data is packed in as needed and not necessarily on byte boundaries
* No checksum discovered at this stage.
* 0100111100100101010111100110100000001100000110000000000010011010000010011001001
* IIIIIIIIIIIITTTTTTTTTTTTHHHHHHHHAAAAAAAAGGGGGGGG????????RRRRRRRRRRRR????DDDD
  12          12          8       8       8       8       12          4   4
Where I=ID, T=Temp, H=Humidity, A=Average Wind speed, G=Wind Gusts, ?=unknown, R=Rainfall, ?=unknown, D=Wind Direction
temp=float( T - 400 ) / 10 (C or F?)
humidity=H %Rel
windspeed=A * 0.34  (m/S ??)
gust=G* 0.34  (m/S ??)
rain=R * 0.3    (mm?)
direction=D (16 spaces how do they decode?)

I don't really get this bit http://www.openhab.org/index.html.  What is your relationship to this group?  I could not find your work here?

Certainly looking good. So am I correct all the Arduino provides burst of times and the program above (what is that language?) decodes it into binary and then further decodes that to human readable form.  None of the conversion etc is done on the Arduino.  So what happens if a Froggit user needs a standalone Arduino unit, can it still use it?  I don't get the bigger picture of this project.

Cheers, Rob
Learning Flute and C++, heading for a meltdown.

saschak86

Hi Rob,


I don't really get this bit http://www.openhab.org/index.html.  What is your relationship to this group?  I could not find your work here?

I run openhab as the automation platform in my home so the values from the weather station's sensors are now integrated. Just wanted to let you know what I do with the now-available values ;)


Certainly looking good. So am I correct all the Arduino provides burst of times and the program above (what is that language?) decodes it into binary and then further decodes that to human readable form.  None of the conversion etc is done on the Arduino.  So what happens if a Froggit user needs a standalone Arduino unit, can it still use it?  I don't get the bigger picture of this project.

I'm going to go on holiday tomorrow so this will take a few weeks but afterwards I'll strip my sketch down and post it of course :) As I do the receiving directly on the sender unit I don't have to filter junk receivings.

Cheers
Sascha

Go Up