Decoding the Fine Offset station RF transmissions ?

[mcrossley]

Correction I am using the RFM01 module, not the RFM12b.

[KarlS]

Guys, have you looked at this thread lately?

[mr.sneezy]

Noticed this today while on Ebay
http://www.ebay.com.au/itm/Wireless-Rem ... 0795662196?
Very cheap if it works with the FO transmitters.

[mcrossley]

Guys, have you looked at this thread lately?

Yep, I'm following the progress there. I was wondering if the 'incompatability between older FO units and the newer ones was that they shifted from OOK to FSK when they started using the RFM modules.

[mr.sneezy]

Guys, have you looked at this thread lately?

Yep, I'm following the progress there. I was wondering if the 'incompatability between older FO units and the newer ones was that they shifted from OOK to FSK when they started using the RFM modules.

My FO WH2081 display has a RFM02 receiver in it and sends OOK if that helps at all.

I've seen that pi thread before.
I'm glad I didn't have so much drama with the PIC.
Martin

PS. I rearranged the LCD to now show rain as well, but I need to get some rain to confirm the right byte is used to send the info. Also added a piezo buzzer that will chirp every rain increment. Taking a break now for a few days though.

[mr.sneezy]

I've been refining my code and testing RF configuration settings bit by bit. Still find that the ones recommended to me seem to work the best. I can make a more RF sensitive config, but it gets noise inputs from other 433Mhz devices near me. In the end I've decided to have two settings, selected by a link, that can be chosen before power up by the user.

With the inevitable feature creep, I hit the limits of the PIC16F819 code space. I still had CRC-8 and other code to add, so I decided to move the code to a PIC with more ROM. 2K to 28K actually. I bought a couple of PIC16F1518 MCU's from RS Components. They are only around $2 each and are a 28Pin chip (up from 18pin on the 16F819).

We had some little rain last week, so now found the right byte for that measurement.

I'll post the frame info soon for anyone else tinkering with this stuff from a WH2081 transmitter.
Martin

[KarlS]

I've been playing with my Raspberry Pi and a 915MHz RFM01 module for a while and now I'm able to consistently receive the temperature, humidity and wind data from the FO transmitter. In a few weeks the snow will turn to rain and I'm hopeful to record these data as well . The BMP085 barometric pressure module is in the mail ...

For the time being I just print out the data. I've not yet decided where I will take it from here, but I'm thinking about a MySQL connection. The data look like this:

Code: Select all

12:57:56 Temperature: 5.0°C --- Humidity:  61% --- Windspeed: 2.4m/s (8.6km/h) --- Windgust: 3.4m/s (12.2km/h) --- Bearing: NNE
12:58:44 Temperature: 5.0°C --- Humidity:  61% --- Windspeed: 1.0m/s (3.7km/h) --- Windgust: 2.4m/s (8.6km/h) --- Bearing: SE
12:59:32 Temperature: 5.1°C --- Humidity:  62% --- Windspeed: 0.3m/s (1.2km/h) --- Windgust: 1.0m/s (3.7km/h) --- Bearing: SW

Here is the strangest thing: this morning I checked the Cumulus screen and saw a red light flashing. Over 2 hours’ worth of "Lost sensor contact" messages. As expected the FO console showed "-----" ... yet the Raspberry Pi was happily receiving and recording data! The FO console and the Raspi sit right next to each other, so they should both get the same signal.

Time to get rid of this unreliable FO console and switch everything over to the Pi ...

[mr.sneezy]

Here is the strangest thing: this morning I checked the Cumulus screen and saw a red light flashing. Over 2 hours’ worth of "Lost sensor contact" messages. As expected the FO console showed "-----" ... yet the Raspberry Pi was happily receiving and recording data! The FO console and the Raspi sit right next to each other, so they should both get the same signal.

Time to get rid of this unreliable FO console and switch everything over to the Pi ...

Wow it's cold where you are. Does your unit display temperatures below zero C ?
I coded mine up to handle that, but I doubt I'll see anything below zero for a long time here.

With your FO console. I think the console can loose it's wake-up time sync with the transmitter if another nearby device happens to hit the FO TX transmissions a few times in a row.
Once this has happened the console goes into power save until it gets a user prompt to attempt a re-sync with the TX (the 48 second TX period). I guess this is to save battery power in the event the TX battery has died or the TX has been removed. I also guess all the re-sync would do is unmute the RX module and wait for a valid transmission, then start it's 48 second timer (probably 47 sec actually) and go to sleep again to save battery power.
My DIY RX unit (and I suspect yours) does not power down the RX module or MCU between transmissions, as saving power is not a concern (running off a plug pack here eventually). So mine will just get the next transmission if one or two are corrupted by another device. In my case that corrupting device is my mains fuse box power monitor system (an Efergy e2 unit)...

Still waiting for the bigger PIC MCU's to lob in from RS Components. Got all the stuff in the order that wasn't critical, the PIC's however went on to back-order

[mr.sneezy]

A bit of a six monthly update.
My bigger PIC MCU's finally got to me after a re-order, and I cut over my code to suit it. Now that I have some spare code space to burn I've got the project nearly where I want it.

I added CRC checking to ensure I ignore corrupt data, and that's going well. I have changed the settings of the RFM12B radio chip again, now reduced the LNA gain parameter and getting better results.

I was lucky enough to have the Fine Offset TX battery run low during testing recently, so I found the byte that indicates that condition too now. Turned out to be the high nibble of the Wind Direction byte...

I've added user software controlled PWM backlight control from the PIC MCU, and added a beeper for keypress feedback and I also have it beep softly when a rain increment occurs.

I used a White on Blue 16x2 backlit LCD, but I hate the way it looks at night even on minimal brightness. It's not good on your eyes and lights up the bedroom room too much. So now I've found a nearly identical footprint Red on Black 16x2 LCD to replace the blue one soon when I get back to it.

I still have a couple of Debug screens showing data for 2 seconds each before the main user info screen updates. I'll post some pictures.

Still to add is USB serial connection via a $4 USB-to-TTL module from Ebay. With that I should be able to program alarms and stuff via PC, or it could be attached to a PC to give weather data just like the OEM display console does. Currently it just dumps serial frame data in a string or error message string to the TTL pin on the board (like the pictures I posted previously).


Cheers,
Martin

[mr.sneezy]

Another six monthly update, and maybe the last on this thread.
The project is mature enough to use as is for what I wanted it for (a bedside table display) and I've stopped working on it.
I did change the LCD to a Red on Black style, and that is MUCH better to see at night compared to White on Blue. I highly recommend the Red/Black LCD's for night viewing now.
I ironed out a couple of bugs in the code that caused lockups, but one minor remains that every so often (once or twice in six months) it gives a massive random rain reading (it's not a roll over event either). Resetting rain value is a button press anyway...

Here are some pictures of the final lash up. I have no schematic as such, I just work from datasheets and scribbled notes. The circuit could be worked out from the photos and the PicBasic code I guess IF anyone needs too. The major components are a PIC16F1509 and an RFM12B 433Mhz transceiver (used in RX only). The rest is regulators and a couple of transistors IIRC and supporting components.

I didn't add the TTL-USB converter module inside as planned, I just didn't see an ongoing need after the debugging was finished.
Power for the unit is from a USB wall wart type power pack that also charges other stuff I have in the room, so it takes 5V DC in, the PIC and the LCD run at 5V, the RFM12B is running from a 3.3V regulator on board.

On a tangent, I noticed a new weather station in the street this week, and better positioned on the hill side for wind speed than mine. I looked up the model, and found that it probably has a spread-spectrum transmitter (a new Davis Vantage station). I guess that will make a DIY receiver for that one unviable.
Cheers,
Martin

[mcrossley]

Good stuff, as for decoding the Davis spread spectrum, its already been done. Look for the work by DeKay on the WX forum - and his own blog. He has done it for the US frequencies, but they use a much broader spectrum than the EU devices. The main stumbling block is that the rfm12b modules are not really suitable for the Davis signal pattern.

[jim-easterbrook]

I was lucky enough to have the Fine Offset TX battery run low during testing recently, so I found the byte that indicates that condition too now. Turned out to be the high nibble of the Wind Direction byte...

I missed this little snippet. This is news to me - thanks for discovering it. I'd seen the occasional 'strange' wind direction but hadn't put two and two together. Looking through old data it seems my batteries go low briefly almost every morning.
I wonder why they didn't put it in the existing 'status' byte, which seems to have 6 spare bits.

[steve]

Does this mean that the wind direction byte in the logger memory will be the same, or is it just in the RF protocol?

[jim-easterbrook]

Does this mean that the wind direction byte in the logger memory will be the same, or is it just in the RF protocol?

It's the logger memory I was looking at (as decoded by pywws) - I've not got any RF decoding stuff.

[steve]

Yes, I was just about to answer my own question. My anemometer isn't working, but I can see that my wind direction byte has a value of $80, so clearly my TX battery is low. I'll fix the code and see if I can do anything with the battery status.