Decoding the Fine Offset station RF transmissions ?

[AllyCat]

Hi,

OK, so I've plugged in my PICaxe breadboard and logged the output from a recent Maplin transmitter. In the tenth byte of the Wireless Protocol, bits 0 - 3 report the Vane Direction, bit 4 (rather surprisingly) is the "Low TX Battery" flag and bit 7 signals "Wind Vane Cable Disconnected or bad". However, for some reason, the Low Battery flag must get "lost" without being copied to the Logging Memory (and presumably the same would apply to bits 5 and 6). Two examples:

Low TX Battery, Vane ESE:
88=FF A2 82 48 38 00 00 00 58 15 E8 *CRC*OK*
A=162 Temp=18.4C,Hum=56,Wind=0mph,Gust=0mph,Rain=88

Good TX Battery, Vane cable unplugged:
88=FF A2 82 4C 37 00 00 00 58 80 9D *CRC*OK*
A=162 Temp=18.8C,Hum=55,Wind=0mph,Gust=0mph,Rain=88

In my added "diagnostics", the first "88" (decimal) is the number of received bits and A=162 (decimal) is the Address of the transmitter, but I didn't actually decode the Vane/Flags byte (perhaps the reason for my rather woolly recall).

So it looks (again) as if I will need to use bit 0 (of the Wind Direction byte) to signal "Sunshine" from my homebuilt dongle. It will definitely also monitor the battery voltage (since this requires literally zero-hardware and two lines of code with a PICaxe) so a low battery might be signalled, for example by reporting "Sunshine" for a few minutes around midnight. But that's jumping well beyond my current stage of development.

Cheers, Alan.

[jim-easterbrook]

I think so. I'm reasonably convinced now that the bit I'm seeing set (the top bit) is because my wind vane doesn't work, and that as far as I can see, when I put duff batteries in and the 'tx battery' icon on the console flashes, this is not reflected in the data read by Cumulus.

This is my interpretation of what I've seen as well. It's also a bit more logical - why would 'low battery' not have been added to the existing status byte?

[mr.sneezy]

Wow, I could hear the thread's 'crickets chirping' while typing out my last post, then bam, another two pages of posts in two days.

Seems there has been much going on with you guys in other threads that I don't monitor.
I read the posts above, and found the console memory map page and spreadsheet, but I can't find the 88bit wireless frame protocol mappings. Maybe I missed it in there ??
Obviously I have my own notes, but I'd like to compare what you guys have written.

I also reduced the images size of my DIY project and reposted them.

Cheers,
Martin

[mr.sneezy]

@Martin (Mr S). Nice pictures, pity they're a bit large for my PC screen. Is there a "cheap" version of PICbasic? The PIC16F1509 doesn't even seem to be supported by the (cheaper) "Student" version.

Now, a small "advert" (I have no connection with the company): For anyone else considering such a project, consider the PICAXE, basically an "Educational" platform with excellent support and very low costs. It can certainly do the above (using very similar hardware) because I've already written much of the code myself, but have not yet reported/documented it on their forum.

@Steve: Incidentally, perhaps now is an appropriate time to reveal that I've been working (very, very slowly) on a low cost (PICaxe) project to transmit a "The Sun is Shining" flag in the Low Bit of the Wind Data (which is largely irrelevant with unmodified FO anemometer Vanes). Could it be possible to use that flag in the same way as the input from a Blake Larson sensor?

Cheers, Alan.

If the student version doesn't support the 16F1509 I might be able to modify the code and recompile for a different PIC. The problem may be the program code size, as I only moved to that PIC to get more code space when the 16F819 ran dry. If you find something supported in the Student version that has the same or more memory let me know.
Martin
PS. PM'ing you also.

[AllyCat]

Hi Martin,

I believe the protocol was (mainly) documented in the link from Kevin Sangeelee's post in this thread.

But here is the "declarations" section from my PICaxe code:

; Fine Offset (solar) message BYTE offsets:
;Example= FF AE B2 59 2D 05 06 0000 15 33 = CRC OK
symbol FOrunin = 0 ; Fine Offset Runin byte = FF
symbol FOaddro = 1 ; Address (1.5 bytes?)
symbol FOtemHo = 2 ; Temperature High byte (in low nybble only) 0 = -40 degC
symbol FOtemLo = 3 ; Temperature Low byte, tenths of a degree units (binary)
symbol FOhumo = 4 ; Humidity byte (binary)
symbol FOwinAo = 5 ; Wind Average speed byte, 0.75mph units (binary)
symbol FOwinGo = 6 ; Wind Gust speed byte, 0.75mph units (binary)
symbol FOraino = 7 ; Rain Counter Word, High byte first (binary)
symbol FOvaneo = 9 ; Wind Vane (in low nybble),$10=Low batt,$80=Bad direction
symbol FOcsumo = 10 ; CRC checksum (CRC-8 shifting left)

It was actually derived from the "Solar" (WH3080) transmitter, but the latest "Maplin" protocol seems identical. There are also other message types though: A separate "Solar Data" packet contains 64 bits and the FO transmitters which don't support Wind Direction only send 80 bits. There is also a packet which contains the Radio Controlled Clock data (WH3080, not 3081) but I don't recall its length (it's transmitted rather infrequently).

PICaxe chips (now) have a relatively large memory, but most is occupied by their embedded interpreter, leaving typically 2 or 4 kbytes for user code in the small-medium sized versions. But the user program can be quite compact, the code that produced my listing samples above (serial output to a terminal emulator) is only about 500 bytes and I believe a basic LCD driver should be just a few hundred bytes.

Cheers, Alan.

[mr.sneezy]

Thanks Alan,

I think my code ran to about 4k but had debug and other stuff in there that bloated it somewhat. Just could not fit in the 3.5k of the 16F819 I started with.

Hey, on a tangent, I noted to day that there has been some advances with RTL-SDR receiver dongles and decoding signals similar to the weather stations.
I use a $10 R820T type RTL-SDR dongle for decoding weather balloons already, it's not a large stretch of imagination to see that with a dongle and custom PC decoding software you could bypass the FO consoles all together (and not have to make any RF receiver).

FYI, not Windows based but it shows the possibilities.
http://rtlsdr-dongle.blogspot.com.au/20 ... pe-of.html

Martin

[AllyCat]

Hi Martin,

I don't think think that the fundamental "problem" is in receiving the (Weather Station) transmissions, it's more logging the data (when/if the computer is off) and particularly getting the data into Cumulus. AFAIK the "Easyweather file" method is quite limited.

Strangely (perhaps), it appears that the "best" way is still via the serial COM port(s), because multiple instances of Cumulus can use different COM port numbers, whilst "similar" USB stations cannot be distinguished. Sadly, the only practical method appears to be emulation of the Davis protocol, being the only one formally documented, but rather complex. Also, currently there is the "unknown" Davis DLL in the data path, but Steve has indicated that this may/will change eventually.

Cheers, Alan.

[tumutbound]

Martin,
Thanks for the mention of RTL-SDR in relation ot weather stations. I have one of these cheap dongles so I might see what I can find out.
Raspberry Pi and RFM12B is on hold pending some missing 'bits'

[xayide]

Is there a possibility to team up Fine Offset stations with an USB-stick with RFM01 or 12B using sandaysoft?
(so that the display discrepancies can be omitted)