Auriol / Ventus Arduino Support

nadabro
2011-02-04
2013-06-12
1 2 3 4 > >> (Page 1 of 4)
  • nadabro

    nadabro - 2011-02-04

    Hi..

    Is it possible to add support for the Auriol h1372 /Ventus / Clones using a Arduino?

    -The Data from the RF modules is sent in 433.93Mhz.
    -The communication protocol can be find here http://www.tfd.hu/tfdhu/files/wsprotocol/auriol_protocol_v20.pdf

    My low cost idea, is just a Arduino Duemilanove+RF 433.92Mhz Module..but the problem is no one is working in the Arduino code, and i´m null at programming :(

    Thanks for your great software..

     
  • A Weather Guy

    A Weather Guy - 2011-02-04

    The current (version 1) hand-made weather shield should be able to receive the transmissions. Just omit the barometer and temp sensor if you don't want them. The one thing I'm not certain about is the 9 msec off-period associated with the sync pulses. There is some risk that the receiver's AGC (automatic gain control) circuit might kick in an cause problems - the only way to know for sure is to try it. You would need an oscilloscope to look at the receiver's output.

    The RF modulation is different enough from the OS signals that it would be easiest to write a new library (the wxrx.c/wxrx.h files). However, the message format is similar and you might be able to keep the WxReceivers.cpp/WxReceivers.h files without too many changes. Just a guess, however.

    Anyway, I don't have time to work on this right now, but there must be others out there who have one of these weather stations and the programming skills, and could spend some time on it…?

     
  • nadabro

    nadabro - 2011-04-11

    Hi..

    I already got my Arduino catching the RF packages from my Weather Station and Serial.print the data. There is still some work to do in the code, but the basic is complete: receiving all RF packages and translated to data:

    Temperature
    18.2º
    Humidity
    88%

    How can i make it compatible with WX Data Logger?

    Thanks

     
  • A Weather Guy

    A Weather Guy - 2011-04-11

    Congratulations! I think most of the hard work is over…integrating with WSDL will be easy and I can modify WSDL as necessary to support this.

    The data sent to WSDL consists of ASCII records. Each record is terminated by a line feed. Records always start with a three character messsage ID followed by a colon. This is followed by zero or more optional data fields. Here are a couple of examples:

    WXS:2.3
    WXH:3.2
    XXX:

    The first one identifies the sketch version as 2.3. The next one indicates that hardware version 3.2 is present. The third one is a request for WSDL to reboot the arduino board - this is handy if you detect a problem and need a hard reset.

    The philosophy I've used so far is to put as little smarts as possible in the arduino sketch and move the complexity of decoding RF data into WSDL. Therefore, RF data from OS sensors is reported like this for version 2.1 and 3.0 RF protocols:

    OS2:<rf data nibbles>,<analog signal strength>,<digital signal strength>
    OS3:<rf data nibbles>,<analog signal strength>,<digital signal strength>

    The RF data nibbles are sent in the order received and include the two checksum nibbles. The signal strength fields are optional, since only the newer version of the shield supports that capability.

    Here's an example of a valid version 2.1 message:

    OS2:1D204B80921076004

    Data fields are in reverse order and most data is in BCD format. For example a temperature of +12.9C would be sent as 9210 and the last zero is the sign flag that becomes 8 for negative values. This example omits the signal strength fields. This is from a temp/RH sensor (1D20) on channel 4 with a rolling code of 8B (B8), flag nibble of zero (0), temperature of +12.9C (9210), RH of 67% (76). The next zero is not understood and the checksum is 40 (04).

    If you wanted to get going right away you could dummy up one of these OS2: or OS3: messages. However, what I would prefer is if you can create a new message that contains the RF nibbles for you sensor, and I will modify WSDL to decode the RF nibbles. I have some time to work on that right now and could get you a beta version probably later this week.

    If you want to go this way then pick a new message ID for your hardware, something like "AUR" or "VEN". Your choice just so it is 3 characters long. Unless you have other data such as signal strength there would only be one field - the RF nibbles, like this (I just made up some nibbles here):

    VEN:2303F9030

    Then I just need to know how to decode the RF nibbles into temp/humidity/etc…

    One other thing - somewhere in the RF data I would at least expect to find a channel number so that multiple temp/RH sensors can be distinguished from each other. If you have or want to include a 2-nibble "rolling code" I can handle that also - this allows for having two or more sensors set to the same channel and we can still tell them apart.

     
  • nadabro

    nadabro - 2011-04-14

    Hi..

    Sorry for only reply now, but i didint have internet access last couple days.

    Believe it was hard work to get the code working, specially for me, until 3 weeks ago i didint know what a variable was :)

    70% of the time lost in this code was to resolve the WindAverage and WindDirection+Gust packages, because this two packages are in the same transmission (36bits+36bits)..but i was only able to receive one package in a transmission..now its working, but i´m loosing 3 out of 4 checksum bits in the WindD+Gust package..

    I will explain the transmissions:

    Rain:
    It´s sent every 37 seconds (even if there is no rain data for a couple of hours), it only sends the total accumulated rain in the pluviometer since the batteries was inserted on it (if batteries removed, data lost).

    Temperature/Humidity
    It´s sent every ~2minutes, both temperature and humidity are sent in the same transmission.

    WindAverage and WindDirection+Gust
    Its sent every 31seconds (if there is some wind change),  in the first 36bits i receive the WindAverage, in the next 36bits i receive the WindDirection+Gust.

    But i´m not understanding if the example above OS2:"1D204B80921076004" is the complete RF message (with all nibbles) received from a Weather Station and WSDL do all the working? Or i have to build my own message, defining a new sensor ID etc..

    My code is doing all the work, first receive 36bits, then search for the sensor id, convert from Binary to Decimal according to the sensorid and Serial.print it…but you prefer the Arduino just send the 36bit in binary with VEN: before the 36bits?

    Example:
    VEN:110001010010011000110000011011101111

    11000101 -randomID (only the 4 bit is always "0" in all sensors)
    0 - battery status
    01 - sensorID for Temperature/Humidity (also it can be 10 or 00, but never 11)
    0 - transmission requested or shedulled
    011000110000 - Temperature, in reverse order, in this case 198 / 10 = 19.8º
    0110 - Humidity "6"
    1110 - Humidity2 "7"   Both are in reverse order, giving 67%
    1111 - Checksum

    But if you wish i can do something simplier..(or even in CSV format), example:
    VEN:WINDA13;

    WINDA - WindAverage package
    13 - needs to divided by 5
    ;  - separator

    My idea of the Arduino doing all the work, is if in the future someone wants to add his own weather station to WSDL (with a different RF protocol), it just need to Serial.print according to predefined format…make a "universal" protocol. Just an idea, i dont know what are the limitations of doing this :)

    Also i have the situation of WindA and WindD+Gust, i´m only able to receive this way
    110001110110100000000000110010001100 (Wind Average Package)
    xxx110001110110100000000000110010001 (Wind Direction + Gust, i loose the last 3 bits)

    Sorry for noob explanation..

    Regards

     
  • A Weather Guy

    A Weather Guy - 2011-04-15

    Well, I think both ideas have value. WSDL doing the decode makes it easier on the sketch, but having a generic protocol also has some attraction.

    Let's talk about a generic protocol first. These first ideas may have some problems so please feel free to suggest alternatives. Mainly this is just a starting point.

    We could use the prefix "GEN:" for this protocol. To keep things consistent, each message could start with the following data:

    Sensor type (e.g. temp/wind/rain) and this could be a single letter, like "T", "W", "R"
    Channel number could be a one hexadecimal characters (one for each nibble ("0" through "F"))
    Random code could be two hexadecimal characters
    A single hex digit for the battery status and other flags there might be like the scheduled/requested bit

    I think that covers it for the data that would be in all the messages. Then as a function of the sensor type this would
    be followed by hexadecimal data to represent the sensor data. This could be either BCD or binary but we need to pick one. In this example I'll assume BCD

    Temperature/Humidity: Temperature with two decimals and humidity with one decimal. The temperature would start with a sign digit that would be zero for positive and some other value (like "1" or "8") for negative. I'm using the extra decimals because that will accomodate higher resolution sensors if we every find any in the future. For example +19.8C with 67% humidity would be:

    01980670

    This would be followed by a checksum with 2 hex digits (the sum of all nibbles in the message).

    An example of a compete message would be:

    GEN:W34F081980670xx  (xx is the checksum digits)

    You can easily send hex digits for each nibble if you create a static  16-element character array that contains the characters "0".."9","A".."F". Then just use the nibble you want to send as an index into the array.

    What do you think so far?

    Do the wind average and wind gust packets arrive close in time to each other? Is there anyway you could aggregate that data into a single message?

     
  • A Weather Guy

    A Weather Guy - 2011-04-15

    Let me try that example again:

    GEN:T34F081980670xx

    Temperature, channel 3, random code 4F, battery 0, temperature -19.80C, humidity 67.0%

     
  • nadabro

    nadabro - 2011-04-15

    Hi..

    My opinion a generic protocol would be great, because its much simplier to add a weather station to WSDL, even its a Lacrosse, etc. Also people can add its own custom weather station..example: Lacrosse TX3 Humidity/Temperature with a BMP085, SCP1000 or any other type of barometer; Also windmill and rain modules are sold separately relative low price and RF protocols are becoming everyday more available from different parts.

    I think that message will work fine and its simple enough:
    -Sensor Type: T - Temperature and Humidity ; W - WindDirection, Gust and WindAverage; R - Rain ;
    -Channel number: It will help if anyone adds a inside Temperature, hygrometer..
    -About the schedule or requested bit, i prefer not to use that bit, because it doesnt give useful information.
    -Battery : 0 - Battery ; 1 - Battery Low

    I prefer using BCD format, but something i never thought before, does Oregon send "8" to define when its positive or negative temperature? In my station i still didint find how the module sends the info about positive or negative temperatures..i need to do some research on that.

    The Wind Packages arrive in the same transmission one next to the other..so i can aggregate the two in the same transmission.

    The Wind Average and Gust will be sent in m/s? I receive in m/s, but i can convert to km/h
    The Wind Direction will be sent as 45; 90; 0; or in N ; S ; W?

    How can i make the message for Wind data?
    Wind Direction 180º
    Wind Gust 2.8 m/s
    Wind Average 0.8 m/s

    About the Rain message, i dont know if the WSDL Rain Info (Rate/hr; ThisHR; Today; Since) are given by the Oregon Weather Station or if its calculated by WSDL. My weather station only send the Total Rain, but i´m calculating the Rate/hr also..

     
  • A Weather Guy

    A Weather Guy - 2011-04-15

    Thanks for the feedback. Yes - OS sends an "8" to indicate negative temps. Based on your feedback give me a little time and I'll post a more complete proposal for your review. Maybe later this evening or tomorrow morning…

     
  • A Weather Guy

    A Weather Guy - 2011-04-16

    OK, here's the proposal. Let me know if you want to change anything and when we've agreed on this I can start implementing it. Shouldn't take too long.

    Generic Arduino Sensor Data Format

    The general format is as follows:

    <Header>:<Sensor Type><Channel><Random Code><Status><Sensor Data><Checksum>

    Message Header: "GEN"

    Sensor Type: One character (see below)

    Channel: A single hexadecimal character (0..9,A..F)

    Random Code: Two hexadecimal characters. This is displayed in the sensor
    manager dialog by WSDL and used to select from several sensors that may be
    on the same channel.

    Status: One hexadecimal character representing four status bits. Currently
    only bit zero is defined and indicates a low battery when high. In other
    words, "0"=battery ok and "1"=battery low

    Sensor Data varies according to the type of sensor and is spelled out below
    for each sensor type.

    Checksum: Four hexadecimal digits which are the sum of each ASCII character
    value in the message, including the header characters. The checksum is optional
    and can be omitted if desired.

    Sensor Data fields

    In what follows, "S" indicates a sign character "+" or -",

    "D" indicates a decimal digit to the left of the decimal point,

    "F" indicates a fractional digit to the right of the decimal point

    Temperature is in degC, wind speed is in meters/sec, direction in degrees,
    humidity in %, rain in mm, rain rate in mm/hr, UV in unitless UV scale numbers

    Individual sensor messages

    Data blocks below are separated by spaces but these spaces are only
    for clarity and are not actually included in the message.

    Type Sensor Data            Notes

    t Temp only        SDDDFF
    h Humidity only DDDF
    T Temp+humidity SDDDFF DDDF Temperature followed by humidity
    W Anemometer DDF DDD DDF DDD
    Avg speed/direction then Gust speed/direction

    R Rain DDDFF DDDDDFF DDDDFF DDDDFF
    Rain rate, total, today, last hour

    U UV DDF

    Examples (optional checksums ommitted)

    GEN:t-02836 = Temperature -28.36C

    GEN:T+034100240 = Temperature +34.1C, humidity 24.0%

    GEN:h0980 = Humidity 98.0%

    GEN:W021112118090 = Avg wind 2.1m/s at 112deg, gust 11.8m/s at 090 degrees (east).

    GEN:R021370098832005544000103 = rain rate 21.37mm/hr, total 988.32mm,
                                    55.44mm today, 1.03mm this hour

    GEN:U083 = UV index 8.3

    Remaining Questions & Comments

    Does the UV index system allow fractional values or only integers?

    Temperature can go into the hundreds of degC in case there are ever any sensors
    that could be placed in an oven for example.

    The highest average rainfall anywhere on earth is around 11.7 meters, which
    is why the total rainfall field has 5 digits to the left of the decimal point

    In general, there are more digits to the right of the decimal point than
    most sensors transmit. This is to allow for future sensors which may have
    more resolution.

    If a sensor does not transmit a random code, then just put any two
    hard-coded hexadecimal digits in the message. "00" is a good choice,
    but anything will work as long as it does not change from message to message.

     
  • nadabro

    nadabro - 2011-04-16

    Hi..

    First i want to thank you the effort on making a generic protocol to anyone wants to add his weather station to WSDL..not only to Arduino users, but with any micro-controller.

    The protocol is easy to understand and to accomplish. It covers the most relevant weather data  :)

    I´ve some last questions..

    -How can WSDL determine if the Temperature and Humidity are from Inside or Outside sensors?

    -Is it possible  to add a Barometer sensor type? Some barometers also have Temperature sensors, but i think its better to work with Barometers with Temperature has separated messages, one for barometer and other for temperature (like "t" Temp only).

    -I´m having a bit difficulty to understand how the Rain package calculate the values for "Today" and "Hour", I can store some values in Arduino, but i think its not easy to accomplish, Also i dont know how can i make Arduino understand when a new day starts, maybe i need to communicate with Arduino . Can WSDL calculate rain "Today" and "Hour" based on Rain Total or its better to Arduino calculate those values?

    -About the UV index question, i cant answer that one, because my station doesnt have one..but i think it allows fractional values, then the Weather station can verify if the UV Index is rising or falling using decimals. Just guessing..

    Thanks again for the support :)

    Hopefully it will be easy to include the generic protocol into WSDL, i will start on my Arduino code.

    Regards.

     
  • A Weather Guy

    A Weather Guy - 2011-04-16

    1) Indoor and outdoor sensors are normally determined by the sensor's channel number. Channel 0 is indoor and 1 is outdoor. However, WSDL does not require this since you can give each channel a different name and specify which channel is to be uploaded to WU/PWS etc. With Arduino it gets even more flexible (and complicated). To see this, get the latest beta copy of WSDL and set the hardware type to "Arduino" (WSDL will restart automatically). Now select the menu Tools…Arduino Sensor Manager. It takes some getting used to, but this allows you to map any sensor to any channel number you want. See the user manual that comes with the beta release for details. I'm trying to make this a bit easier to use but it is going to  take som work.

    2) I knew I forgot something. How about this - we'll use "B" for barometer and there will be three data fields in this order: station pressure, QNH pressure and SLP pressure. Some barometers may reporte one or more of these types of pressure and you would only fill in the fields that applied. Each data field would be DDDDFFF in millibars (hPa). For example, "1013250" would be 1013.250mb. Fields that you don't use would be reported as seven X's like this: "XXXXXXX".

    3) Not all rain gauges will report all of the values - so if your rain gauge only reports rain rate and total rain then just substitute X's for the other fields. WSDL only needs the rain total to do it's job and the other fields are optional.

    4) We'll leave the decimal in there on UV then.

    I'll begin work on implementing this in the next few days or so and let you know when I have a beta release for you to try out.

     
  • DAVE

    DAVE - 2011-04-17

    Man!! Aweatherguy, you are a VERY busy weather guy.

     
  • nadabro

    nadabro - 2011-04-21

    Hi..

    I´ve already the Arduino sending messages according to the protocol.
    The Wind Average and Gust, is still being a bit tricky, because i´m having difficulty to Serial.print with decimal values without a dot ".", but with Temperature is working  (199, 102, etc).

    Thanks :)

     
  • A Weather Guy

    A Weather Guy - 2011-04-22

    Great! I've already some work on WSDL and can finish it this weekend. Look for a new beta release perhaps on Sunday. I will write the WSDL software to ignore decimal points (periods) in case you don't get that fixed. Also if you get stuck let me know and I'll give you some ideas how to do that…

    Cheers,

     
  • Giuseppe Chiodaroli

    Why not extend the operation of additional sensors including custom sensors?

    I mean, I created a sensor for counting the lightning, and I'd like to use WSDL to display the data, the idea would be to read the data from the main station (in my case, the WMR100) and use an Arduino to interface these sensors.

    WSDL should read both the data from the console, both those that arrive via the serial port to Arduino.

     
  • Giuseppe Chiodaroli

    The idea of ​​the protocol is excellent.
    I wanted to point some things:
    1) it can not use the checksum? this to save memory on arduino.
    2) the part on the direction of the wind should have at least one decimal
    3) add the solar radiation sensor with the letter S
    with 5 digits and a decimal and as a measure w/m2
    4) a snow height sensor with the letter s with three digits and a decimal unit of measure cm.
    5) to count lightning sensor with the letter L and 3-digit

     
  • Giuseppe Chiodaroli

    Another sensor could be the presence of rain, the letter r and a single digit 0 for no rain for 1 rain presence

     
  • A Weather Guy

    A Weather Guy - 2011-04-27

    Thanks for all the inputs.

    I've released a new beta, 4.2.2.1 that should respond to these new messages. I tested it with a hand-made "T" message and it seems to work but have not tested any other messages. This first release will accept a checksum if present but does not verify the checksum.

    Regarding the inputs, I can see where it might be nice to have input from an Arduino augment data from the OS console. Something else to add to my list of enhancements!

    1) The checksum is optional. It will not complain if you omit the checksum.

    2) I could add a decimal to the wind but do you think that will be useful? Most of the OS anemometers have a resolution of 22.5 degrees - is that why you wanted the decimal - to pick up the 0.5 in 22.5?

    3) I can also add the solar radiation, snow and lightning but the larger task will be to add support of the data within WSDL in the log file and for graphing, display and so on. I will put this additional data on my list of enhancements but I can't say just now when I might be able to work on that.

    What are you using for a lightning sensor? How well does it work?

     
  • Giuseppe Chiodaroli

    ok to the point N. 1
    To the Point 2, since the anemometer 22.5 marks I also read the 0.5.

    The lightning sensor is a simple counter made ​​with the 1-wire network, I send you the link

     
  • DAVE

    DAVE - 2011-04-27

    Aweatherguy, are you still there?

     
  • A Weather Guy

    A Weather Guy - 2011-04-27

    Okay, I will work with nadbro to get a decimal point added to wind direction.

    I should probably come up with a generic technique for adding new columns and new data types to the weather log. Then WSDL could be enhanced to collect any sort of 1-dimensional data versus time. I'll think about that a bit…

     
  • nadabro

    nadabro - 2011-05-01

    Hi..

    Sorry for only replying now..but i´m in vacation (didint bring the weather station with me lol), next thursday i will try the new version of WSDL and give some feedback for Temperature/Humidity, Wind and rain Data.

    Thanks again for the support aweatherguy :)

     
  • A Weather Guy

    A Weather Guy - 2011-05-02

    No worries - enjoy your vacation!

     
  • nadabro

    nadabro - 2011-05-05

    I did enjoyed my vacation, but it was too short :)

    I´m testing only the Temp+Humidity message..the Arduino is sending this:

    GEN:T+021900620

    But WSDL doesnt receive any data, WSDL is working with the arduino, because i see the LED blinking when i receive a new RF package..but WSDL is still blank. I just went to Hardware Options and choose "Arduino" and the correspondent COM Port.

    Using 4.2.2.1 version.

    Is the Temp+Humidity message correct?
    Am i missing any other WSDL configuration?

    Thanks

     
1 2 3 4 > >> (Page 1 of 4)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks