[ken66]

I want a micro-controller weather station that uploads to Weather Underground and this site is a mine of information.

I am interested in Fine Offset Sensors and have some queries about them in the General Discussion / Weather Equipment thread. Using the existing transmitter looks the cheapest and easiest way to use these sensors and I understand this can be done for Auriol Sensors using AuriolDuino. I see that Fine Offset uses different signal encoding and uses slightly different but nearly the same encoding for different transmitters which probably includes this one. As far as I can tell AuriolDuino only decodes signals from Auriol transmitters even though I see the Oregon Scientific protocol described here.

Is that correct or could I use AuriolDuino to decode 433MHZ signals from Fine Offset or other sensors?

[werk_ag]

Is that correct or could I use AuriolDuino to decode 433MHZ signals from Fine Offset or other sensors?

Maybe the AuriolDuino hardware can be used for that purpose, I don't know, but the AuriolDuino software can only be used with the following weather stations:

Auriol H13726, Ventus W155, Hama EWS 1500 / Meteoscan w155 w160 / Alecto WS-3500 / Balance RF-WS100

[AllyCat]

Hi,

I see that Fine Offset uses different signal encoding and uses slightly different but nearly the same encoding for different transmitters which probably includes this one. As far as I can tell AuriolDuino only decodes signals from Auriol transmitters even though I see the Oregon Scientific protocol described here.

I wish the "hot links" were more "contrasty". Originally, I didn't realise they were there!

I don't believe that either of the "Fine Offset" protocols that you've linked above are correct for their complete Weather Stations. The first link is "similar", but the stations use data packets of 8, 10 and 11 bytes (depending on the data being carried). The last byte is a Cyclic Redundancy Check (CRC) not a simple checksum. The second "Watson" transmitter link looks exactly like a "La Crosse" T/H sensor that I have - Oh the joys of "Badge Engineering"!

As far as I can see, the FO protocol is completely different to that used by Oregon (and Arduino/Weatherduino?). I believe quite a lot of "research" into the FO protocol has been done on the Raspberry Pi forum. So I think you can assume that the AuriolDuino is NOT directly compatible.

The data tranmission format(s) that Weatherduino can use is also of interest to me. My own project is a homebuilt "Solar Sensor" that is "Fully Compatible" with the FO "Solar Pod" (i.e. it will transmit the standard 8-byte FO data packet). It might be possible to arrange my software to also transmit WeatherDuino format data (when I discover what it is), but that will be ever further along my (very slow) development path.

Cheers, Alan.

[werk_ag]

The data tranmission format(s) that Weatherduino can use is also of interest to me. My own project is a homebuilt "Solar Sensor" that is "Fully Compatible" with the FO "Solar Pod" (i.e. it will transmit the standard 8-byte FO data packet). It might be possible to arrange my software to also transmit WeatherDuino format data (when I discover what it is), but that will be ever further along my (very slow) development path.

Hi Alan,

For data transmission WeatherDuino uses the Arduino VirtualWire library.
Basically messages are sent with a training preamble, message length and checksum. Messages are sent with 4-to-6 bit encoding for good DC balance, and a CRC checksum for message integrity.
Payload message can be up to 80 bytes.

You can find more info about it here:
http://www.airspayce.com/mikem/arduino/VirtualWire/

Currently I know nothing about the FO protocol, but if possible with the receiver already used, maybe in future I could make something to make the WeatherDuino compatible with your Solar Sensor.

[AllyCat]

Hi Werk_AG,

Thanks for your reply; yes that's rather what I expected, but your links have helped me to look deeper into "VirtualWire". I don't believe anybody has ported that to the (PICaxe*) processor that I'm using, so I may have to do it myself. I'm reasonably happy wth the run-in ("training") and message data, but am always worried about CRCs, because they are hard to debug if they don't work (especially if you don't understand the maths). I see it employs a 16-bit library for the CRC, but does it use only 8 bits?

AFAIK the Fine Offset data can be decoded by "bit banging" in much the same way as I believe you used for the Auriol protocol. It uses a long/short pulse coding for 0/1, the first byte always "FF", then the address/message data and finally an 8-bit CRC. Adding a FO reception protocol might be useful for many users, because there are so many FO stations "out there". But it is probably not the best use of your time. However, if you decide it is worthwhile, then I should be able to at least confirm the message data format(s). The FO "Solar Pod" sends data only in "coded" format, but I haven't seen the Pods available as a "spare part" anyway. Also, the "Solar" coding format is not very versatile - 3 bytes (22 bits theoretically used) for the "Lux" value, but only 4 bits for the UV (i.e. UVIndex = 0 to 15 in integers).

Also, I note from another thread that WeatherDuino uses a 9+ volts supply for the transmitter, whilst FO use 3 volts (or less). That may (partly) explain why the FO wireless link is so "Iffy" (not sure if that translates into Portuguese).

* The reason that I use PICaxe is because it can potentially operate at power levels "compatible" with the Fine Offset battery-powered systems (i.e. 3v from 2 x AA cells). Thus the "design target" for my "compatible" solar pod design is to use a 50 milliwatt PV panel (from a solar garden light) for the power, with an average power consumption of <1 milliwatt. That's one reason my progress is so slow.

Cheers, Alan.