Go Down

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


Jul 15, 2014, 06:10 pm Last Edit: Jul 15, 2014, 10:16 pm by saschak86 Reason: 1
Hi @all,

I just got my new weather station - obviously a relabeled http://www.froggit.de/product_info.php/info/p163_wetterstation-froggit-wh5300.htmlFroggit WH5300, sold by Conrad as RW53 http://www.froggit.de/product_info.php/info/p163_wetterstation-froggit-wh5300.html.

It uses 433 MHz and I tried it with my trustworthy UNO and an regenerative receiver to get data - but all I got is some flicker. RemoteSensor-Library does not seem to support is and rc-switch is also helpless  :(

I got some pictures from the inside of the receiver/station, please see the attached images for reference :)

Any ideas?



please post smaller images  (600x800 is often ok)
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)


Can you make pictures of the datastream ?
You can use the audio input of the computer with Audacity program.


I'm sorry about the pictures, I'll edit the first post to include thumbs  :smiley-red:

As for the trace, attached is an export of the receiver. I attached my Salae logic to the receiver module and magically got data when the display showed the 'I'm receiving data' icon. So, there's a screenie and a VCD export.

Maybe someone can shed light on this. And maybe also why my regenerative module did not receive anything - the frequency is correct. Maybe FM/ASK difference? How to tell?

Thanks for your help,


Is that output of a data burst ? I can't recognize it. The white blocks at the end seems very strange. Normal code would have wide and small pulses. In most cases all the small pulses have the same duration and all the wide pulses have the same duration.


So you think I made a mistake capturing the data?

I really thought I got good data as other captures show similar results. Btw, I also checked if I get the data with my super-regenerative receiver and got it working - it has just been a range issue. Moving the sender towards the receiver solved it.

Any other ideas on how to get further?



Jul 16, 2014, 07:24 pm Last Edit: Jul 16, 2014, 07:26 pm by Peter_n Reason: 1
Can you show the analog data with a picture with higher resolution. I really can't recognize a pattern in the picture.
Most receivers output show a pattern of pulses that still has analog information in it.

I'm used to a pattern like this: http://bertrik.sikken.nl/433mhz/
or this: http://tickett.wordpress.com/2012/06/27/more-433mhz-rf-hacking/
or this: http://thepiandi.blogspot.nl/2013/08/gertboard-camera-remote-control-finding.html


So attached are the screenshots of a new telegram.

whole_telegram - Full telegram view
SOF - Start of Frame - First bit
FirstBits & FirstBits2 (not shown due to attachment restrictions) shows the first SlowBits - those seem to be a preamble

FastBits shows the tight bits at the end of the telegram. The Timing is 2.5ms per transition with
1.05 ms
1.44 ms

for different bits. Seems to be the RZI PWM mentioned on http://www.susa.net/wordpress/2012/08/raspberry-pi-reading-wh1081-weather-sensors-using-an-rfm01-and-rfm12b/ - do you agree?



I'm sorry, but your screendumps don't say a lot to me.
You show a digitized signal, and that shows differences in width of pulses, while they could have been transmitted with the same width. The FastBits show a good pattern, but then again the resolution of the picture is too low to say anything about it.


I'm sorry, but your screendumps don't say a lot to me.
The FastBits show a good pattern, but then again the resolution of the picture is too low to say anything about it.

Thank you very much for still looking into this. I'm not sure if you want a more zoomed in view, so I attached one. Also attached is the trace file for Saleae Logic (GUI Download: https://www.saleae.com/downloads)



Jul 21, 2014, 04:13 pm Last Edit: Jul 21, 2014, 04:32 pm by saschak86 Reason: 1
Hi Rob,

I've tried your DebugVersion.ino but don't really know what to put in for sDelay and bDelay.
Maybe you could get me started?

Your explanation of Manchester Encoding is really well-written. Thank you for your links!

Btw, I noticed the Saleae Logic has Manchester-Decoding built in. However, I don't know what to put into for Bitrate(/s). Any way to determine from the timing I sent?


PS: To answer your last question, it surely is possible as there seem to be a variety of other stations around. I tried to limit my capture to my station by capturing when my station showed new values.


Jul 22, 2014, 02:12 am Last Edit: Jul 22, 2014, 03:47 am by robwlakes Reason: 1
Thank you Sascha,
That knowledge of Manchester encoding was very hard won, I thought I had it worked out several times before I really got a handle on it.  I felt other explanations I found on the web had little nuggets of information in them but few of them clearly spelled out all the most important aspects.  I am very pleased you took the time to read it.  Now down to your question.

Using your fastbits.png I have analysed it and there would appear to be approximately 7 "ones" in 11 milliseconds (ie the header section).   So a bit waveform estimate would be  around 1.57 mS.  This means 0.39mS for the 1/4 duration sDelay and 0.78 for the 1/2 duration bDelay (390uS=sDelay and 780uS=bDelay).  Now both of these may need fine tuning a little, though I have found experimentally that with this sort of decoding program it is tolerant to about +- 15% (because it keeps locking onto the data transitions and errors do not accumulate).  The main variable that could cause a change to these timings is how much time is taken up with the processing (as the delays are outside of the processing, hence the true delay is processing+delay).  However the calculation above points to the upper limit of what is best to try first.  Reduce a little if you want to try changing them, however it should be easy to find a sweet spot once you get a signal, and then try a few settings around that point.

Having your station on the same table (not too close) and not using an antenna on your 433MHz receiver is one way to be sure you are only listening to the weather station.  With that excellent scope that made the "screen shots" of the waveform, you should have very little trouble picking the waveform apart, the images are excellent (what is it  btw? Edit: I have found it https://www.saleae.com/logic).  Just reduce the Vertical component so you can see a more square waveform, it will help you track the transitions easier.

One of the virtues of the Manchester encoding in the "old days" was that it could be hardwired with dedicated logic fairly easily and with its self locking timing, could provide a very stable/reliable data transmission. The  Saleae Logic would be as good I am sure, it should let you investigate length of header, polarity and packet length easily?  Our early hard drives used a similar waveform and it was hence tolerant of disc wow and flutter to use an audio concept.

Let me know how you go,

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


Good Morning Rob,

so I just gave it a go with 390uS=sDelay and 780uS=bDelay but there was apparently no data detected. So I tried other values up to sDelay=630;bDelay=1250 but the LED13 was not even flickering :( I always upload the sketch and wait for the display of the main unit to refresh to be sure there must have been data flowing.

Did you download the GUI from Saleae? It's really great but the beta (1.1.20) has some big improvements (time markers etc). The hardware can be had knock-off for about 10 USD but I prefer the real deal ;)

I'll keep looking into getting the sketch to 'find' any data. Yesterday, I got occasionally an 'I' when receiving data - does that indicate the data validation on line 268 has triggered?
Serial.print("I "); //debug validation, enable this if you feel you are getting lots of errors, otherwise disable

Is it possible to output the received data pattern with your sketch?

Again, thank you very much :)


Hi Rob,

what about this :D

H!010101010101010101010101010101010V D 00110010 11011010 10110101 01010110 11100011 10101010
This data has been verified as validD 00110101 11011010 10110101 01010110 11101001 10101010

It appeared the second as the console showed outside humidity, temperate and wind. Here's my settings:

boolean toggle  = true; //reflects the line polarity from the TX
boolean header  = false; // sets whether a valid header has begun
boolean firstData = false; //sets the detection of first zero after the header of 1's
byte logic = false; //manchester logic encoding flag
byte Q1 = false; //manchester state at 1/4 through waveform
byte Q3 = false; //manchester state at 3/4 through waveform

byte  dataBit = 0; // reflects the data bit stream polarity
byte  dataByte = 0;  //accumulates the bit information
byte  nosBits = 0; //Counts to 8 bits within a dataByte
byte  headerHits  = 0; //counts the number of "1"s to determine a header
byte  maxBytes = 6; //set the bytes collected after each header  NB only 6 are compared, reduced to 6 for Ambient
byte  nosBytes = 0; //counter stays within 0 -> maxBytes
byte  bank = 3; //points to the array of 4 results from 4 last data downloads
byte  nosRepeats = 1; //number of times the header/data is fetched usually 4

byte  manchester[4][16]; //stores 4 banks of manchester pattern decoded on the fly
//you may have to twiddle with these timings for Ambient
word  sDelay    = 300;   //about 1/4 of bit duration  begin with 370
word  bDelay    = 600;   //about 1/2 of bit duration  begin with 740, 1/4 + 1/2 = 3/4

Tables turned as I changed nosRepeats=1 and sDelay to <320. Data is output only when the console also updates its display.

I have the strange feeling that this data is only valid because of nosRepeats=1 - cloud you please proof me wrong ;)? Also my stomach tells me there's more bytes to it as only one 'message' is thrown at the serial but all this data (temperature down to .1, humidity, wind (speed&direction)) needs more space...

So, where to continue :)

Thanks for your efforts!


Jul 27, 2014, 10:11 am Last Edit: Jul 28, 2014, 01:17 pm by robwlakes Reason: 1
Hi Sascha,

Over the weekend I have written a totally new "general" Manchester protocol debugger, and is a stripped down receiver where setting two delays and a  few other numbers will allow you to receive raw bytes from your transmitter.  I have included a stripped down "how-to-use-it" instruction page as well.  The variables in the program are set up to allow configuring of the receiver quite easily from the early program variable definitions, and you need not change anything in the body of the program until you have good reception.

I have also managed to streamline the decoding logic as well so that all the decoding is in one unified section now, rather than a header section followed by a nearly identical packet section.  I have had it working on my Oregon Scientific WS sensors so I know it works on Negative Polarity, no discards and minimum 10 header bits.  You will need to alter it to suit your system, which I think is Positive Polarity to start of with. You will have to experiment a little  and see what you can do.  Here is the GIT-Hub link:


Let me know how you go, any feedback would be appreciated.

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

Go Up