Sandaysoft

Not a concern for me it will only ever need to run for a week at a time maximum and usually a lot less than that.

I had a feeling you were after something more low level than the bit I understand.
It would be easy enough to make the interval configurable (I've been thinking of doing that anyway); I'd just have to check to make sure that I haven't written any code that currently relies on the 10 second interval. It would have to read all of the data at the same time, not just the wind data.

_________________
Steve
Sanday Weather
----------------------------------------------------------------------------------------------------------------------------------
Like Cumulus and want to support it? Please donate!

Well I'm making progress, I've isolated the bits of the data stream that indicate :-

Wind speed
Direction
Rainfall
Temperature
Humidity
Low battery
possibly TX battery voltage?

But I haven't been able to work out how the numbers sent correspond to what's displayed yet. Next stage is to make a dummy transmitter so I can send numbers of my choice and see what they correspond to on the display. There's also a lot of bits that don't seem to change whatever I do, maybe reserved for other features?

Martin.

Ah what I though may be battery voltage looks like it may be a checksum which is a bit of a stumbling block until I can work out what checksum method they've used.

Martin.

Can you please share your findings so far? I'm planning on rigging up a microcontroller to receive the data from my station (I'm just awaiting a pitch changer for the RF transceiver I've got, so I can attach it more easily) - so anything you're able to share would be a great help, both in terms of your setup and the protocol. I've got a TI Launchpad (with an MSP430G2553) lined up for the job, with a CC1101-based transceiver module, but no matter what you're using I'm sure there'll be some room for collaboration (i.e. the protocol).

Cheers,
Paul

I've created a receiver for my WH1081 (Maplin branded, 433MHz) using a Raspberry Pi. As part of the project, I had to figure out the wireless protocol, which I've documented in the (link) here.

Kevin

Well done.. Great project for a rainy day

_________________
Terry Wiltshire
http://www.janter.co.nz/weather/index.htm

Nice work!

_________________
Steve
Sanday Weather
----------------------------------------------------------------------------------------------------------------------------------
Like Cumulus and want to support it? Please donate!

Also interesting that the radio data packet does have a checksum, so unless the base station ignores it, these 'wacky' values coming from the FO must be generated in the base station? Though I doubt the base station multi-tasks so my initial thought about possibly reading memory locations that are partially written to would seem unlikely?

_________________
Mark
Wilmslow Astro Weather

Hi,

Or the "Transmitter" (external module) is creating/reading wacky values before calculating the checksum?

Yes, well done Kevin; I suspect that "m" is indeed the top nibble of the rain count. I seem to remember that the rain count from the Console (USB/memory map) is two bytes (but of course the Console could maintain an "overflow" from the "n" nibble locally). However, it should be easy to test, just plug the Wind (anemometer) cable into the Rain socket for few hours !

I'm fairly sure that that protocol is the "new" one, introduced on the 308x (Solar) models and apparently now on "recent" Maplin units. The earlier protocol seems to be quite different (surprisingly using a significantly higher data rate) because the full transmission takes less than 50ms (but no "repeats") with earlier models.

Personally, I don't have an RPi but as it appears you've posted the source code, perhaps someone else will be able to analyse some of the "other" protocols. The x080 models transmit the Radio Controlled Clock data as well, and the 308x models transmit solar data in a separate packet (with 60 seconds repetition rate). That might be easier to decypher (now that you've cracked the basic data format) because the Solar Pod encodes the data packet to send to the transmitter, so it can be read (on the Solar Pod cable) even without a radio receiver.

Cheers, Alan.

I expect it could be used to analyse most OOK-like signals on frequencies the RFM01 supports, given a bit of experimentation if the bit-rate is completely unknown. My original logic-analyser capture helped an awful lot though, since I then knew what I was looking for on the receiver side.

The bit of code that captures transitions on the DATA pin into 'rssitime_buf' is more or less all that would be needed, other than the hardware setup code. That buffer name is a bit of a misnomer - it was originally based on the RSSI state, but that wasn't a very reliable way of doing it - I should have renamed it 'highduration_buf'.

Also, for anyone who might use the code to investigate other data packets, be aware that I throw away all 'low->high' transitions, because these are just the (1ms) clock pulses in my WH1081 transmitter. For a true OOK signal, you'd want to include these in the buffer too (or have a corresponding 'lowduration_buf').

Thanks for the tip on getting rain readings - saves me running back and forth with a watering can!

Kevin

hmm... on top if the black blob there is "SPL191B1".

Googling it gives us that SPL191B1 is a Sunplus 8-bit CMOS microprocessor with 256K ROM (to store the program - can we read it?) and 704 bytes RAM and 20 I/Os
There is probably info to be found about Sunplus SPL191B, like datasheets, but they don't seem to be accesible for free.