Decoding the Fine Offset station RF transmissions ?

[mcrossley]

Good find, I have updated the decode spreadsheet in the Wiki

[AllyCat]

I wonder why they didn't put it in the existing 'status' byte, which seems to have 6 spare bits.

Hi Jim,

Yes, strange. The "old" FO (Maplin) stations do use the "Low TX" flag to display an icon on the LCD, but it appears to be only updated (in the Console) each midnight ! However, that flag didn't seem to get copied to anywhere in the (logger) memory map, so AFAIK Cumulus can't use/display it (EDIT: Ah, have you found it ?). Also, the Solar version (WH308x) does seem to display/update the Low TX icon "instantly", but I haven't yet tested the "new" (Maplin) version of the protocol/Console.

@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.

[steve]

@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?

It wouldn't be hard; it would only be a couple of lines of code to actually process the flag and a few more lines to read a cumulus.ini setting to turn it on. And while I'm changing the code in this area anyway...

Just to clarify, you mean the least significant bit of byte 9 (from zero) of the logger memory?

[tumutbound]

I'm glad this thread was updated otherwise I would have missed it.

As I documented in another thread, I have a Raspberry Pi as my webcamera and, looking for something else for it to do, decided receiving the WH1080 transmissions would be a good project.
I've found an adapter to add the RFM12B to the RPi at the http://openenergymonitor.org/ site. As I have a couple of RFM12B and the more recent RFM69CW, I'm going to make my own adapter rather than get one with the unneeded RFM12B fitted which should e easy enough as the PCB design is open source.

[AllyCat]

Thanks Steve,

No, I think it's the LSB of byte 12, the The Wind Direction.

I hope to explain all in much more detail later, but for now just a brief comment on my idea / project.

The original concept was to communicate "The Sun is Shining" wirelessly using the existing FO (108x) hardware, completely unmodified. The (8-pin) microcontroller (located in a loop-through "dongle" on the Wind cable) will read the Wind direction directly from the Vane (and of course also measure the light level) and supply modified "direction" data when the transmitter "reads" the Vane each 48 seconds.

It might appear that this will give "worse" Wind direction data, but actually I expect it to be a considerable improvement. The micro can / will read the direction several times between each 48 seconds transmission and calculate a true average, not just a random "snapshot". It will also "remember" the last few reported values so that if, for example, the "true" direction is ESE, but it can only report E or SE (because ESE would signal that the sun is shining and it isn't), then it will alternately transmit E and SE, to produce a correct average.

Cheers, Alan.

[steve]

No, I think it's byte 12, the The Wind Direction.

Oh I see. Would it not be better to use one of the remaining top 4 bits, as Cumulus is now going to be ignoring those?

We should probably take this to another thread, or PM.

[AllyCat]

Hi Steve,

Would it not be better to use one of the remaining top 4 bits,

Well, it would, if I could access them. But the micro / dongle can only signal a "fake" wind direction (one of 17 "analogue" values - the last is "vane disconnected" / invalid) to the transmitter. Edit/Added: IIRC, bit 4 (value 16) is the "invalid direction" flag (console displays "--").

But I suppose one could modify the battery circuit of the transmitter so that when the sun is (not) shining the transmitter sees a "low" battery voltage and signals that as "Sun is (not) Shining". Potentially easier to do, but I had come around to the view that my improvement to the wind direction value might actually be as much a useful enhancement as the "Sunshine" data.

Cheers, Alan.

[AllyCat]

Hi Steve,

We should probably take this to another thread, or PM.

Yes, I will start a new thread when I have a definitive proposal, but this seemed a good opportunity to raise the concept whilst you were "looking" at the status flags. For now, just a quick update and summary:

I've just tested a "new protocol" Maplin Console and the "Low TX" icon now responds "immediately". Or to be precise, it appears to need two consecutive transmissions (with the flag set) to start the icon flashing, which then becomes constant after the next message. The threshold voltage appears to be very close to 2.4 volts (+/-100 mV), so a "Low TX" may be reported if using NiMH rechargeable cells.

It looks as if the "Wind Direction" byte actually contains more "status" data than the "real" status byte ! Bit 7 is "Low TX Battery" and Bit 4 is "Wind Vane disconnected"* (or an invalid analogue voltage level). Both can be "externally generated" without any need to even open the transmitter case, let alone attempt to "hack" the program / hardware (probably an impossible task). Bits 3 - 1 contain "useful" data (i.e. the primary wind directions) but Bit 0 is almost redundant (because an unmodified vane rarely sets it). So there are three flags (b7, b4 & b0) which potentially could be "hijacked" for more useful purposes. The other two (b5 and b6) are really only accessible if one is building custom hardware / firmware to emulate the FO transmission protocol.

The purposes I have in mind are "The Sun is Shining" and/or "It's Raining" (from a Hydreon RG11 - individual "Rain Tips" need too much data capacity). But the (re-)allocation of the flags rather depends on user-preference. For example putting "Low TX battery" on b4 would allow "continuous" transmission of another flag (e.g. "Rain" or "Sun" on b7) but (or because) setting b4 "hides" the wind direction (i.e. the FO Transmitter/Console generates/recognises "Wind Direction = 16" but not 17 - 31.

*EDIT: Note that the functions of the Bit 7 and Bit 4 flags are (still) reversed in this post. The correct allocations become apparent later in this thread.

Cheers, Alan.

[mcrossley]

Wiki now updated to v6 - added invalid wind direction flag to bit 4 decode.

[steve]

Have I confused the issue here by assuming that I have low batteries? My wind direction byte is $80, so I assumed that the top bit was low battery. But my anemometer is disconnected, so why do I not have the 'wind vane disconnected' bit set?

I changed my batteries for ones that I know to be low, and the low tx battery indicator lit up on the console; it wasn't on before. But my wind direction byte is still $80. Confused, I am.

[jim-easterbrook]

It looks as if the "Wind Direction" byte actually contains more "status" data than the "real" status byte ! Bit 7 is "Low TX Battery" and Bit 4 is "Wind Vane disconnected" (or an invalid analogue voltage level).

Just to note that one of my stations (the oldest, from 2008) has disconnected wind sensors but does not report anything in bit 4. Not all Fine Offsets are the same!

[AllyCat]

Hi,

It's some time since I examined my (old) Maplin station so I may be mis-remembering something, but bit7 seems correct (also reported by Kevin in another thread, I believe):

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...

However, my Consoles do "know" when the Wind Vane is disconnected, because they display <no arrow> (sorry, I previously wrote "--"), whilst b0 - b3 can only report the 16 "real" directions N .... NNW (0 - 15), so there must be another flag somewhere. I'll try to get my "breadboard" (PICaxe) RF protocol monitor up and running again soon.

Cheers, Alan.

[jim-easterbrook]

I've just checked and my station with disconnected wind vane is reporting a solid 0x80 for wind direction, i.e. bit 7 is set. The console shows no wind arrow (and no "low battery" warning).
Another station, with no outside sensors running, also reports 0x80 wind direction and is flashing its low battery warning. The status byte is 0x40, i.e. 'lost contact', as you'd expect.

[AllyCat]

Hi,

Near the top of this page (4):

However, that [Low TX battery] flag didn't seem to get copied to anywhere in the (logger) memory map, so AFAIK Cumulus can't use/display it (EDIT: Ah, have you found it ?).

So perhaps my memory was only slightly at fault. Is it that the "Low TX battery" is (as was previously thought) NOT recorded in the memory map, but the Disconnected / bad Vane Position is in bit 7 ?

Cheers, Alan.

[steve]

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.