Sandaysoft

82M99, according to a post in this thread: http://sandaysoft.com/forum/viewtopic.php?f=16&t=2936

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

Thanks, a bit more detail about my plan. :-

Fit a better quality TX/RX unit with decent aerials to extend the range.
Work out the protocol for the wireless link between the units (has someone done this already?)
Work out the protocol for the USB link (ditto?).
Fit my own little micro to the transmitter which will continue sending Wind speed and direction info when the units main micro isn't.
Fit another micro to the the receiver which will send the extra data to the PC via the USB connector.

This means that the update rate on the receivers LCD display will be unchanged but the PC will get far more frequent wind information. Could cumulus cope with this?

Long term would be to completely replace the transmitters micro with my own to do all the sensors at higher speed, I doubt the LCD will update faster but the PC should.

Martin.

Others have asked about this, but I'm not aware of anyone who has actually done it.

The protocol is available unofficially from various places, e.g. http://code.google.com/p/fowsr/downloads/list

Cumulus just reads the station's current data location every 10 seconds and treats what it gets as a new set of data, even if it hasn't changed. I can't think of any code in Cumulus which would care if it actually did update more often than the normal 48 seconds. I don't really understand how your plan works, but it involves hardware so that's not surprising

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

Hi Martin,

You've omitted "Fit a larger battery to the transmitter" (or maybe add solar powering). The reason that the transmitter runs for a year or more on a pair of cells is that it only transmits for 50ms every 48 seconds (i.e. 0.1% duty cycle).

Good luck working out the RF protocol, nobody else seems to have succeeded yet.

However, I am working on a project which happens to involve "processing" the FO wind data more frequently (but it's not the prime aim of the project), maybe some details in the Homebuilt section soon.

Cheers, Alan.

Ah sorry I don't mean the USB link between the receiver and the PC I mean the bit between the micro in the receiver and the Holtek USB chip. Would there be any way of making Cumulus look at the data more frequently than every 10 seconds (at least for wind information?) My long term plan for this is for use at firework displays where wind information is a priority but what the weather in general is likely to do is also very useful so what I want to have is :-

Portable handheld receiver giving just wind information (with audible alarms) that can be carried round the site.
Existing LCD display giving an overview of the weather in general.
PC logging everything but in particular windspeed and direction.

Martin.

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.