I thought I'd try the above sketches just in case my weather station used the same protocols as the Thermor/La Cosse ones; As expected, I had no luck.

I decided to look a little deeper, and pieced together this circuit to capture transmissions with my computer's soundcard:

After inspecting the recording with Audacity I've run into a problem. I can see the section where the station transmits its signal, but can't see any meaningful data in that section of the recording.

I've attached a sample to this post.It contains 3 transmissions:1) [@0.3sec] The weather station I want to receive data from (transmits every 48sec).2) [@1.25sec] Some other random device that transmits every 60sec.3) [@2.2sec] Remote for a RF toggles power board that I triggered myself.

I included the other two transmissions as they both clearly have data in their transmissions.

So I'm kind of stuck here. I'm not really a hardware guy and don't have much experience with RF communication; I was thinking maybe it's got something to do with FSK/ASK/OOK. Like transmissions 2 & 3 are using ASK and the weather station is using FSK and that's why i can't see any data?

Again, I'm rather unfamiliar with RF so any suggestions or pointers in the right direction would be greatly appreciated.

Let me know if there's any more info that would help.

Cheers.

EDIT: Sorry, I wasn't aware you had such an issue with filehosting.org. I didn't notice the option to attach files to the post the first time 'round, but have done so now.

SirFloyd

That wav file is a recording of what I captured from the 433MHz receiver when I connected it to my sound card. You're supposed to inspect it with Audacity or some other audio editing software (details are in the bottom two links of my inital post).

Ultimately I plan to use an Arduino to interpret the data, but at this stage it's easier to capture it with my sound card and analyse the waveform to figure out how it's encoded.

Most of the common wireless weather stations use some form of Manchester coding, http://www.atmel.com/images/doc9164.pdfto transmit the data, as this provides a more reliable form of transmission.Usually there is a framing sequence of some kind consisting of alternating 1 and 0 to allow the AGC in the receiver to stabilise.The best way to figure out what is being sent is to get one of the sensors, like a temperature sensor and capture what it sends .You will have to pull it apart and sample the data on the data pin of the Transmitter Module.The benefit of looking at the transmitted data is that it gets rid of all the other signals and interferance that confuses what you are seeing.You are going to need something better than a sound card though to do this, some kind of CRO at a minimum to capture the entire data sequence, as you have to figure out if any kind of CRC is used or not.The CRC is sent at the end of the transmission.

Is it possible that the device is looking for a response from the base controller first? or that the data is at a rate beyond the capacity of the sound card. For example the data you read might well be a preamble or ID for the base station to identify and or lock on to the remote (dotting) before the data payload and that your method of saving it and analyzing it are missing the data payload?

Bob

--> WA7EMS "The solution of every problem is another problem." -Johann Wolfgang von GoetheI do answer technical questions PM'd to me with whatever is in my clipboard

SirFloyd

The best way to figure out what is being sent is to get one of the sensors, like a temperature sensor and capture what it sends .You will have to pull it apart and sample the data on the data pin of the Transmitter Module.The benefit of looking at the transmitted data is that it gets rid of all the other signals and interferance that confuses what you are seeing.

My understanding is that the individual sensors don't send their readings independently, but rather they are all read and sent together in a single transmission.

I see what you're saying. Unfortunately, pulling apart the transmitter module isn't really an option, as it's glued together (I assume to reduce cost and provide some basic weather protection, as it's outside) so it's not really feasible without doing irreversible damage. I also don't own a CRO or logic analyser.

Hypothetically, let's say I had a CRO and connected it to the transmitter's data pin and I've worked out the encoding/protocol it's using. How does that help? I still can't see any data sequence for the weather station in what it being captured by my receiver (although I can clearly see data sequences for two other devices). The whole point of this project was to be able to get the data from the RF transmissions so that the weather station itself remained untouched.

CRC seems irrelevant at this stage, as i'm not getting any binary data from the station.

I've attached to this post a photo of the back of the display. It shows the RF receiver located at the lower right corner (with the red antenna). I looked on the underside of the receiver, but there didn't appear to be any part/ID number. So the only clues I've got are that it's 433Mhz and has a silkscreen "RT " on it.I supposed I could read the data from the data pin on the receiver; but again, I don't own a CRO or logic analyser (although I would have though the sample rate of my soundcard would have been sufficient).

SirFloyd

Is it possible that the device is looking for a response from the base controller first? or that the data is at a rate beyond the capacity of the sound card. For example the data you read might well be a preamble or ID for the base station to identify and or lock on to the remote (dotting) before the data payload and that your method of saving it and analyzing it are missing the data payload?

Bob

I suppose that is possible, but there's no other reason for the base controller to communicate with the remote station. Also, I thought this type of RF communication was only 1-way and so that would require two transmitter/receiver pairs (which would increase the cost/complexity unnecessarily).

To be clear, the base controller does still work, it's just the screen on it that is broken. It receives data and can be connected to a PC via USB to display readings with some proprietary software, so it's definitely still receiving accurate data from the remote station.If the base controller was sending a response, wouldn't I be able to pick that up as well?

My understanding on how the remote weather station communicates/pairs with the base station is as follows: -When the remote station is first turned on, it sends a number of transmission in quick succession, as opposed to the usual rate of once every 48sec. All transmissions include an ID unique to each remote station (in case your neighbour happens to also own one). -When the base station is first turned on, it listens for the first valid transmission from a nearby station and records the ID. Any further weather station transmissions it receives will be ignored unless it includes the that same ID.This should mean that, as long as both the remote and base stations are powered on at the roughly same time, they should be paired without the need for bi-directional communication.

I've just remembered that I'm only assuming it works this way as that's how it was described for the station used in the Practial Arduino project, so i've attached another recording that I took as I restarted both base/remote stations:

[@0.3sec] Turned base station on[@2.5sec] Turned remote station on.[@10.4sec] First periodic transmission from remote station. (same as #2 from my first post)[@15.4sec] Some other random device. (same as #1 from my first post)[@18.4sec] Second periodic transmission from remote station. (same as #2 from my first post)

It may be worth noting that i've cropped the recording to reduce the size so I could attach it. I've attached an image of the uncropped recording just in case the real world timings were important.

This is a sample of the data stream of an Oregon Scientific Weather station temp Sensor.Whilst your Weather Station wont be the same , the data format will be similar.The timebase on your audio card is far to slow to see anything sensible, and what you are seeing is the normal outputof an ASK receiver with no input, ie broadband noise converted into random rate data.You need a CRO so you can edge trigger the CRO on the rising edge of the first data byte from your transmitter.

SirFloyd

This is a sample of the data stream of an Oregon Scientific Weather station temp Sensor.Whilst your Weather Station wont be the same , the data format will be similar.The timebase on your audio card is far to slow to see anything sensible, and what you are seeing is the normal outputof an ASK receiver with no input, ie broadband noise converted into random rate data.You need a CRO so you can edge trigger the CRO on the rising edge of the first data byte from your transmitter.

I assume by timebase you mean the sampling frequency. If so, why do you think it's far too slow? The picture I uploaded (sampleImage.png) shows it sampling at 44100Hz; I've also done recordings at 96000Hz which is 96% of the sampling rate used by the oscilloscope in the image you uploaded (which also appears to far exceed what is required, given that even the short pulses in your pic are 500µs long) and it makes no difference.

Are you saying my sound card doesn't actually sample at 96KHz?

Did you look at the wav file I uploaded? You can clearly see data from other nearby devices being picked up without the need for an oscilloscope. What timebase do you think is needed here?

Could it not possibly be something as simple as me using an ASK receiver, while the weather station could be using an FSK or OOK transmitter?

It appears that guy had some luck receiving data. It even looks like he captured some data from the pins using an osciloscope (which should make mauried very happy). It also looks like the RFM01 receiver he's using is that same as the one used in the base station (http://www.hoperf.com/upload/rf/RFM01.pdf), I'll take a look into that this evening when I have some time.