Chinese 433Mhz Temperature Sensor protocol

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is probably a longshot, but maybe someone knows these.

 

I have recently acquired a set of XT200 temperature sensors, they are cheap, Chinese products and lack any kind of documentation. They are stated to be XT200 433Mhz Temperature sensors and come from a firm called Imagintronix. I've found a whole bunch of Chinese suppliers for exactly the same unit, but I cannot find the protocol these things use. I can receive the things just fine on my RFX USB device, but have a hard time making sense of just what I am receiving.

 

Has anyone seen these before and perhaps know the protocol? I've included some pictures, maybe somebody recognizes them. Anyone know the protocol these things use? 

 

Code, justify, code - Pitr Dubovich

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting.  Apparently, it is part of a "set".  Apparently, it has FCC information.

 

http://fccid.net/document.php?id...

http://thermometerhk.en.alibaba....

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, it's often part of a set. I was able to acquire some on the cheap, just the sensor. Now it's the challenge to find the protocol :)

Code, justify, code - Pitr Dubovich

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you post a sample of the data, I'm sure somebody would have a crack at decoding it...

 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I cracked a cheapy temp/hygro sensor on the weekend. The protocol was rather simple:
Fixed high time of 500us
Low time 8ms was start
Low time 4ms was a 1 bit
Low time 2ms was a 0 bit
Frame was 36bits repeated 7 times

As John says, post the sample data. You can use you PC's sound card as an oscilloscope. Software like audacity can capture tons of data. The salae logic analyser is more convenient. Some captures where the temperature is different helps as well as what temperature was indicated.
There's an arduino project where a number of protocols have been cracked - the name escapes me at the moment.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chances are these will be ASK or OOK.  A transmission will likely start with a training preamble, then possibly a frame start code, followed by some DC-balanced encoding (manchester encoding, 4-of-6 encoding, etc.) for the payload, then an FCS...

 

The payload is what you're after, but you'll have to untangle the low level stuff first.  Post captures of a few received packets.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, glad to know there is some interest here, awesome :)

 

Using an RFXtrx433E USB unit I was able to get the following after playing around a bit, hex code it seems, every few seconds, about 30 seconds.

Don't know if I should go lower level. 

 

Just at room temps;

09	03	04	25	22	A2	4C	FF	EF	40
09	03	04	24	26	CA	24	CF	FE	F4
09	03	04	21	26	CA	2C	97	FC	14
09	03	04	1F	26	CA	2C	7B	FE	B4
09	03	04	1E	26	CA	30	7B	FD	38
09	03	04	1A	26	CA	3F	EF	FE	14
09	03	04	1B	26	C9	DF	A7	FE	68

Towards zero, putting the room unit in a bag of ice

9	3	4	38	26	CA	24	EB	FD	F8
9	3	4	3A	26	CA	24	EB	FD	F8

Moving cooler even, longer in the bag of ice

09	03	04	4B	26	C8	A2	87	FF	0C
09	03	04	4C	26	C8	9A	87	FC	D0
09	03	04	54	26	C8	92	DB	FD	E0

Another unit, at room temps

09	03	04	5B	26	C9	AD	83	FE	94
09	03	04	5C	26	C9	A9	83	FF	8C

And a unit, pulled from the freezer;

 

09	03	04	B1	26	C4	CE	EF	FF	8C
09	03	04	B2	26	C4	E2	2F	FF	24
09	03	04	B3	26	C5	0B	4B	FC	70
						
09	03	04	B9	26	C6	46	DF	FD	DC
09	03	04	BA	26	C9	9A	47	FD	D0

Edit: Hex paste cut of leading zeroes, this is better.

Code, justify, code - Pitr Dubovich

Last Edited: Mon. Jan 12, 2015 - 11:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You'll need to provide some context. The transciever you're using can be configured a great many ways. You'd at least need to provide the config which lead to the output you posted.
Better would be to use one of these:
http://www.laipac.com/easy_434a_eng.htm
They are ASK modules and have both an analog out and a digital out. Capture the analog out if you can. The analog out is a tap on the input to the integrated 'slicer', and may be more helpful in reverse engineering the protocol.
Of course if your modules are FSK, this won't work, but I'd be surprised if they were more than just ASK or OOK.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Those numbers mean little to me - I'll have to figure out how your magic usb device translates the raw data into those magic numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

a number fo things need to be known before you can start interpreting data.

first you need to know what transmission protocol the sensors use like OOK, ASK, FSK, NRZ..........

knowing that you can go and see if you can receive data. Note that some protocols are 'overlapping' and thus that when you use a wrong receiver you will get data, but that all will be garbage.

 

then you need to find out what data protocol is used.

how many bits are there in a transmission. how many start bits, and how many data bits.

note that you need to think in bits here not in bytes.

The great thing here is that normally the number of start bits (frame synchronisation bits)  will not change, as these will be for synchronisation with the  receiver side.

knowing that you have a bit stream available.

 

Another thing here is that it might be that a single transmission is repeated a number of times to ensure that it is received correctly.

another thing that will most likely be present is a CRC at the beginning or the end(most likely)  of the transmission.

and another thing that might be present is some sort of a timestamp, or battery indicator.

 

but that should all become clear when you know how the data stream is build up and if you receive a large number of frames you should be able to see patterns emerge.

but make sure to always look at bit level rather than byte level.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The transceiver I use, http://rfxcom.com/store/Emetteur..., the RFXtrx433E, was made specifically for these types of sensors and has a broad range of protocols enabled by default.

I was going through the protocols available and when I selected 'La Crosse' the unit started spitting out these at me;

 

10-1-2015 16:10:39= ------------------------------------------------
0903042026C9D3FBFE40 
Packettype        = UNDECODED RF Message
UNDECODED LACROSSE:26C9D3FBFE40 

 

I am not that versed in protocol analysis, but I did find this blog post https://www.pitt-pladdy.com/blog...

 

It seems to be the same type. 

Code, justify, code - Pitr Dubovich

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If your doodad is doing all the protocol detection for you, then what are you trying to accomplish exactly?

 

Your doodad thinks that it is hearing a La Crosse weather station data packet.  Whether your module does in fact conform to a La Cross packet format is by no means certain, but if it turns out to be the case then shouldn't you be looking for information on La Crosse packet formats?

 

Thirty seconds spent on Google:

http://hackaday.com/2011/06/13/reverse-engineering-wireless-weather-stations/

http://makin-things.com/articles/decoding-lacrosse-weather-sensor-rf-transmissions/

https://github.com/kjordahl/Arduino-Weather-Station/blob/master/lacrosse.pde

https://www.google.ca/search?q=la+crosse+temperature+packet

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What Joey said.

I did a similar search on "La Crosse". Quite a bit of stuff out there.

 

 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am trying to determine the protocol. Never occurred to me to search for that Lacrosse bit. I will check the links, thank you!

Code, justify, code - Pitr Dubovich