I want to build an autonomous GPRS weather station

Just capture signal isnt good enought without knowing what exactly system send.

"Wind" device basicly have 4 sensors :

  1. Wind Speed
  2. Wind orientation
  3. Outside temperatura
  4. Outside humidity

I did some research becouse I need that device to send data via 1-wire network, but finaly I decide to use both information (I like wide LED screen :slight_smile: )

What sensor is used :

  1. Wind speed (reed switch)
    Half period on / half period off (not so usual but O.K.)
  2. Wind orientation (not sure at the moment)
    From outside device come 7 wire, 2 of them are for Wind Speed , so
    we have 5 other , 16 orientation of wind , that mean 2^4, 1 wire in 4
    out maybe digital/or analog
  3. Outside temperature (Normal thermo resistor)
    Analog value
  4. Humidity sensor (Low lewel)
    Measuring resistance beatween two cooper field

Rain gouge
Standard dual reed switch system

If I am on your place I will use rein gouge for testing and alayzing signals.

When I finish 1-wire implementation I will send more info on forum.

Thank you for the info, i'm also using the rain gauge for testing and have come to the same conclusion. But i will try a different approach, my idea is to try to patch in to the base station itself and somehow extract the data. It receives the sensor data, calculates and displays it on the lcd. There has to be a way i can intercept the displayed calculated values.

Hi everybody.
I also got the auriol weather station and would like to interface it to the pc.
Aerozg i like your approach , i am looking forward for your results.

Some small changes :

Rain gouge :

  • only one reed switch, count off state (which is very unpractical, battery life)
  • 1-wire ready (4N25)

Wind station:

  • wind speed count Low state (GND) - 1-wire ready (4N25)
  • wind orientation is reed short time before sending data and very probably used 4 reed switch and few diodes

I have few picture of inner PCB which will be posted later.

Finally, in my opinion it will be very hard to decode radio communication from central device, because electrically all 3 devices are different construction, and doesnt seam to be from same source.

Especially central device isnt good example how to create industrial PCB :slight_smile: (it look like amateurs work).

Wind orientation on central device display dont show exat position at measuring time (maybe I need to configure something :slight_smile: ).

Algoritam of orientation presentation is very upredictable, it doesnt appear it is avrage position after few reeds. It show some adding behavior, but still upredictable.

Aerozg if I understand correctly you study aerospace engineering (FPZ) maybe you know what algoritham is used for wind orientation presentation ?

I have also opened the base station housing and took some pics of the PCB, which is like you said, not a good example of PCB design. It looks like it was done on the fly. Here are some pics:

The wind direction is not shown in real-time. I've fiddled with it, it takes a few seconds for the update to show on the display. There are various wind direction algorithms out there and written in C, they are not complicated, and are free. I don't yet have any way of knowing what algorithm is used in this particular base station.

What I'm trying to do is connect it to a SCADA system. Then i might be able to make some progress, i hope. I'm starting to think that maybe i should get the Weather Meters form SparkFun and build my own system form scratch.

So it's actually a re-branded Ventus w155!
http://www.ventusdesign.com/products/w155-weather-station-with-rain-gauge-and-anemometer/

jumpjack: unfortuantly no :slight_smile:

In this particular case I prefer to talk about same parts not actual complet . Auriol rain gouge are different, probably diferent elctronic .

Happy new year everyone :slight_smile:

Did any of you have some luck with decoding the wireless sensors data? I have an Alecto WS-3500 which has the same raingauge as the Ventus w155 but the display unit looks more like the one from Auriol... (standard LCD with blue backlight - not inverted like the Ventus device...)

Could someone translate the wireless packets into a binary sequence? I think if we could figure out how to read the temperature and humidity values from the transmission, we would have a first step :slight_smile:

Thanks and great work on that!

Hi everyone,

I have decoded the most part of the Auriol weather station data. The document is available on my website, but the board does not allows to post any active links in the first post. Maybe in the next...

PS: Sorry for my bad english, it is not my mother language.

Second try...

There is the link: http://www.tfd.hu/tfdhu/files/wsprotocol/auriol_protocol_v10.pdf

Regards
TFD

TFD! You're a genius! :slight_smile:

I'll try to modify the practical arduino weather station sketch to make it work with that... Will keep you guys posted.

(If anyone has some working sketch already, I'd be very pleased though :smiley: )

TFD, thanks for information , it is very good job.

However some things need to be chage :slight_smile: (nop I didnt tested, but it is logical) .

  1. Please send some array of random ID , my guess is that isnt so random .
  2. How central device know which device send data ?
  • according your information it may be from :
    a) random ID
    b) bits 8,9,10,12,13, 14
  1. How central device know which format is in use ?
    -may you send binary data log I would like to chechk real value

Regards,
Dubravko

Congratulations TFD, very good job! And thanks for sharing!

About the faulty rain gauge, my one has no weak signal, but no signal at all sometimes, due to the magnet being too far from the sensor in some situations: be sure to hear the "click" every time you move the "bucket" left and right when performing your tests!

Interesting development, nice work there TFD!

First of all thank you for your appreciation!

@SnJDK:

I think the following is a simple way to distinguish data packets:

if( bit9 == 0 )

      temperature/humidity data

else
{
      switch( bit14_bit12 )
      {
            case 1: average wind speed data
            case 3: rain gauge data
            case 7: wind direction and gust data
      }
}

Here are some real samples (my test receiver outputs each nibble as a hex digit, regarding the bit order):

B606F082F random id: 0xb6, temperature: 0x0f6 -> 246 -> 24.6 °C, relative humidity: 28 %
B66100E09 average wind speed: 0x0e -> 14 -> 2.8 m/s
B66F6132D wind direction: ( 0x16 << 1 ) | 1 -> 0x2d -> 45 °, wind gust: 0x23 -> 35 -> 7.0 m/s

I have collected also some random id's. Listed in order of appearance, all are hex values:

2E 16 6E E6 62 F6 B2 1E E6 26 EE 9E 06 32 7E BA 0A EE AE C2 AE C6 EA 12 22 22 12 A2 EE 9E 32 EA 72 66 C2 2A 9A 76 E2 A6 EE 9A DA D2 7A 0A EA EE BA 76 EA EE 5E CE D2 AA 86 EE DE 6E CA 32 9E 56

@jumpjack:

I have experienced the same problem with the rain gauge's magnet. However it seems, that it works fine when the unit stands firmly on a flat surface. The problem is somewhere in the RF section of mine unit, because i hear the transmission bursts on the communicaton receiver used to monitor the occurences of transmissions, but the test receiver, nor the base unit does not receive anything. I have managed to capture only a few samples by placing the rain gauge and the test receiver here and there.

Regards
TFD

Hi all,

does anyone have some code for that already? I just noticed that my C coding skills suck badly and I don't actually quite get how to grab the packets.

I have a few questions and it would be great if someone could help me on that:

Should I start the packet detection on the 8 times 1bit 'preamble'?

How is the DATA output of a basic ASK 433MHz receiver working? Can I just use that output directly to map HIGH to 1 and LOW to 0? Or do I need to actually define the lengths of each pulse to parse a 1 or 0?

Thanks for your help (I'm a proud Arduino UNO user for a week so far and I have just started to learn...)

Greetings,
l33chy

P.S.: @TFD: Just out of curiosity: How did could you find out the specs of the transmission protocol? By using a professional logic analyzer?

I used two different 433 RXs, and both of them just output a "digital wave", i.e. I have to "manually" process it to determine what is "1" and what is "0", depending on length of high and low bursts.

I didn't write any code yet. ::slight_smile:

Thank you jumpjack, that's very helpful!