Decoding of Froggit WH5300 Weather Center

saschak86 · July 15, 2014, 4:10pm

I just got my new weather station - obviously a relabeled Froggit Wetterstationen Shop - Froggit Wetterstationen WH5300, sold by Conrad as RW53 Froggit Wetterstationen Shop - Froggit Wetterstationen.

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?

Thanks,
Sascha

robtillaart · July 15, 2014, 6:10pm

please post smaller images (600x800 is often ok)

Peter_n · July 15, 2014, 6:13pm

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

saschak86 · July 15, 2014, 8:11pm

I'm sorry about the pictures, I'll edit the first post to include thumbs

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,
Sascha

Weather data.vcd (40.7 KB)

Peter_n · July 15, 2014, 10:55pm

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.

saschak86 · July 16, 2014, 5:18pm

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?

Thanks,
Sascha

Peter_n · July 16, 2014, 5:24pm

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: 433 MHz projects
or this: More 433Mhz RF Hacking | Tickett's Blog
or this: The Pi & I: Gertboard - Camera Remote Control - Finding The Patterns

saschak86 · July 17, 2014, 12:37pm

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
and
1.44 ms

for different bits. Seems to be the RZI PWM mentioned on Raspberry Pi reading WH1081 weather sensors using an RFM01 and RFM12b – SusaNET - do you agree?

KR
Sascha

Peter_n · July 17, 2014, 1:02pm

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.

saschak86 · July 17, 2014, 1:18pm

Peter_n:
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: Downloads)

HTH
Sascha

Weather.logicdata (10.3 KB)

saschak86 · July 21, 2014, 2:13pm

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?

Thanks,
Sascha

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.

robwlakes · July 22, 2014, 12:12am

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 Logic Analyzers from Saleae - #1 with Professional Engineers). 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,

Rob

saschak86 · July 22, 2014, 4:10am

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
Sascha

saschak86 · July 23, 2014, 3:16pm

Hi Rob,

what about this

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!
Sascha

robwlakes · July 27, 2014, 8:11am

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:

DebugManchester.ino

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

Rob

robwlakes · July 28, 2014, 11:16am

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

saschak86 · July 28, 2014, 2:20pm

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 )

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

          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

Weather2.logicdata (3.96 KB)

WeatherManchester.txt (111 Bytes)

saschak86 · July 29, 2014, 4:45pm

Hey Rob,

robwlakes:
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 German politicians mull moving 2018 World Cup from Russia – Euractiv - 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:

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

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
Sascha

MassiveData.txt (9.95 KB)

saschak86 · August 7, 2014, 3:49pm

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:

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):

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?

robwlakes · August 8, 2014, 10:17am

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

PythonGraphIt.py (1.02 KB)

PacketData.csv (2.15 KB)

SaschaDebug.ino (502 Bytes)

Topic		Replies	Views
Intercepting 433Mhz from an OS WMR86 Weather Station Device Hacking	2	4564	May 6, 2021
Weather Rstation Receiver decoding Programming Questions	2	883	May 5, 2021
AWS Arduino Weather Station - Much needed help (with pics) :) Project Guidance	4	2385	May 5, 2021
Wireless Weather Station help Programming Questions	12	761	May 5, 2021
Yet Another cracked external weather temperature sensor on 433MHz (4-LD2289-5) Networking, Protocols, and Devices	2	5761	May 6, 2021

Decoding of Froggit WH5300 Weather Center

Related Topics