Typically radio packet preambles are alternating 1's and 0's to enable accurate clock-recovery and decrease the risk of confusing noise for a packet.
The actual values in the packet may be raw ADC outputs from the sensors, which might be odd units - hence the need for loads of examples to tease-out the meaning.
Repeating the packet with different spacing is to enable it to get past various forms of repetitive or bursty interference with high likelyhood (I presume the system does not use a packet-acknowledgement protocol as transceivers at each end add to cost).
The actual values might even be encoded of course... Perhaps 1 should be 0 and 0 should be 1? bit order could be LSB first or MSB first - have fun code-breaking!
Yeah, have considered LSB first, perhaps they are raw ADC outputs... The bit stream just does not seem to be long enough to contain both humidity and temperature in a BCD mode. How would I go about decoding raw ADC outputs?
I've taken about 10 samples so far of various temps and humidities and they all begin with the same bit sequence 101010110101.
Another interesting thing the manual said is that the base station can use up to 3 separate sensors, and to wait at least an hour between adding new sensors to the system on initial setup. Makes me wonder about device codes in the bit stream.
I wonder if it would be helpful to take the transmitter apart and see what's going on inside.
Alright, I'm officially stumped. Everything I've found on google related to other weather station protocols have many more bits than the signal that my thermo/hygro sensor gives me.
At the beginning of every message, no matter what the temperature or the humidity reads, I have the common bits 101010110101, which as I mentioned earlier I'm guessing is probably some sort of device ID. But that only leaves 13 or 14 bits left in the stream to store a sign bit, temperature (with 1 decimal point), and humidity value.
For instance, the value I just captured, 71.2F and 39% humidity was: 101010110101 00101100111001
Here are a couple more, closer together:
70.2F 41%
10101011010100000010100101
70.0F 41%
10101011010100101100011101
That seems to rule out BCD mode, which would require at least 4 bits per digit, if there were 4 temperature digits and 2 humidity digits.
Are there any other types of common encoding systems that I should look into? Maybe this bitstream is somehow compressed, but I really have no idea how that would work. Any sort of pointers in the right direction, even if they are just a hunch, would be helpful!
I think we really need several more examples of the transmitter output to have any chance of decoding the signal.
I know you say the transmitter repeats the data several times but how often does the transmitter send new data?
Would it be possible to attach examples of the entire multi-burst sequence as raw WAV or upload to file sharing site that we may download them.
I've attached several raw wav files of a bit stream with values fairly close together to be able to hopefully find the difference between them. I can give more broad ranged values too if you'd like.
Sample B: transmitter read 71.2F and 39% humidity
Sample C: transmitter read 70.3F/21.3C and 40% humidity
Sample E: transmitter read 70.0F/21.1C and 41% humidity
Sample F: transmitter read 70.2F/21.2C and 41% humidity
The transmitter sends the burst of new data approximately every 75 seconds.
Thanks for any insights whatsoever, no matter how small!
Thanks for the samples. They are quite low level but with a bit of amplification I get the idea. Looking at them stacked on top of each other (see picture) and I wonder if it is maybe not Manchester encoded. It looks more like a MFM encode but that's normally used for magnetic media use.
Can you open the transmitter case without damage and maybe see what components are inside?
Edit:
Forgot to ask if you could supply more samples over larger ranges please.
Just to let you know what my thinkings are sofar. As transmission length varies depending on content and no long highs I feel sure it's not Manchester encoding. I wonder if it's far simpler than that in that a 1 is a single peak and a 0 is a peak followed by a trough (see image for better idea). The bit values could be reversed (peak for 0 & peak/trough for 1).
I had a quick look at the online manual and it says humidity ranges from 20% to 99% in 1% increments (though one of the samples you sent said 19% humidity?) so the range is 79 (99-20) that can fit in 7 bits. Temperature range is stated as -20 to +70 in 0.1 increments that fit's in 10 bits if you multiply by 10 to remove decimal point.
I also wonder if the last 2 bits are stop bits
A couple of samples of minus C temperatures would be helpful please.
Yes, we were talking about the possibility of that encoding scheme in a few of the earlier posts on this thread. It's still interesting to me though because with that scheme, all of the samples I have taken begin with the same bit sequence 101010110101. Perhaps a preamble/device id/"channel number" of some sort...
But that does not leave many bits left to represent temperature and humidity. Despite the manual, I have seen humidities much less than 20% before, reported on the interior and exterior display. I've attached a quick photo as proof (showing a 16% value).
I've got the transmitter in the freezer now so I will be able to give you some very cold samples very shortly.
One thing to consider: if the values sent back are raw data from the two sensors then there is no guarantee that they will have the same bit-order. Also I suspect the encoder chip used will be a standard part for IR remote controls - this link at ladyada seems worth reading: http://www.ladyada.net/learn/sensors/ir.html
Wow, you're on to something. I never considered the transmitter sending different sensor data each burst, but that makes a lot of sense. Here are some consecutive samples that I took earlier:
It looks like Reading 2, Reading 4, and Reading 6 all seem to work out with your formula (after converting to C)! I wonder what reading 1, 3 and 7 mean... Perhaps "no change" or some sort of ack/ping packet?
I'll go see what happens with bits 8 and 9 with negative C temps.
I can only assume that as 0.0C = 12 then the unit only reads to -12.0C and not the -20.0C as stated in the manual. It also seems the minimum humidity is 16% and not 20% as stated in the manual. The interesting one is as below that I can only assume to be battery level of transmitter. 101010110101 0001xxxxxxxxss
EDIT:
***IGNORE THIS The complete breakdown as I see it.
101010110101 Preamble
00 ?Possible device ID (when more than one transmitter used)
xx Control bits to define Data bits meaning. 00=Humidity, 01=?Battery, 10=Temperature
xxxxxxxx Data bits. For humidity it's the correct value.
For temperature divide by 10 and add 12 to get Centegrade value.
For ?Battery unknown.
01 Postamble
101010110101 Preamble
0 ?Unknown. Possible extra data bit OR device ID (when more than one transmitter used)
xxxxxxxxxxx Data bits.
If number <=100 then it's humidity.
If number >=300 then subtract 500 and divide by 10 to get Centegrade temperature,
01 Postamble
So I've written a preliminary sketch (basically just modified "Thermor", someone else's weather station code). I'm having trouble actually reading the packets - it seems to miss bits or miss entire packets altogether. Any idea what I could be doing wrong?
/*
* Modified from "Thermor" DG950R Weather Station receiver v 0.3
*
* Receives data from a Weather Station receiver, via
* a 433Mhz RF receiver connected to pin 8 of the arduino, and outputs
* to serial.
*
* Based on the Practical Arduino Weather Station Receiver project
* (http://www.practicalarduino.com/projects/weather-station-receiver).
* For more info:
* http://kayno.net/2010/01/15/arduino-weather-station-receiver-shield/
*
*
*/
#define INPUT_CAPTURE_IS_RISING_EDGE() ((TCCR1B & _BV(ICES1)) != 0)
#define INPUT_CAPTURE_IS_FALLING_EDGE() ((TCCR1B & _BV(ICES1)) == 0)
#define SET_INPUT_CAPTURE_RISING_EDGE() (TCCR1B |= _BV(ICES1))
#define SET_INPUT_CAPTURE_FALLING_EDGE() (TCCR1B &= ~_BV(ICES1))
#define WEATHER_RX_LED_ON() ((PORTD &= ~(1<<PORTD6)))
#define WEATHER_RX_LED_OFF() ((PORTD |= (1<<PORTD6)))
#define WEATHER_RESET() { short_count = packet_bit_pointer = long_count = 0; weather_rx_state = RX_STATE_IDLE; current_bit = BIT_ZERO; WEATHER_RX_LED_OFF(); packet_start = false; }
#define TIMER_PERIOD_US 4
#define WEATHER_PACKET_BIT_LENGTH 26
// pulse widths. short pulses ~500us, long pulses ~1000us. 50us tolerance
#define SHORT_PULSE_MIN_WIDTH 900/TIMER_PERIOD_US
#define SHORT_PULSE_MAX_WIDTH 1100/TIMER_PERIOD_US
#define LONG_PULSE_MIN_WIDTH 1900/TIMER_PERIOD_US
#define LONG_PULSE_MAX_WIDTH 2100/TIMER_PERIOD_US
#define BIG_PULSE_MIN_WIDTH 3400/TIMER_PERIOD_US
#define BIG_PULSE_MAX_WIDTH 3600/TIMER_PERIOD_US
// number of bits in a row before the stream is treated as valid
#define SHORT_COUNT_SYNC_MIN 2
#define LONG_COUNT_SYNC_MIN 2
// states the receiver can be
#define RX_STATE_IDLE 0 // waiting for incoming stream
#define RX_STATE_RECEIVING 1 // receiving valid stream
#define RX_STATE_PACKET_RECEIVED 2 // valid stream received
#define BIT_ZERO 0
#define BIT_ONE 1
//byte locations of generic weather data in weather_packet[] array
#define WEATHER_STATION_ID 0
#define WEATHER_PACKET_TYPE 1
//types of packets
#define PACKET_TYPE_HUM 0
#define PACKET_TYPE_TEMP 1
#define DEBUG
// Type aliases for brevity in the actual code
typedef unsigned int uint; //16bit
typedef signed int sint; //16bit
uint captured_time;
uint previous_captured_time;
uint captured_period;
uint current_bit;
uint packet_bit_pointer;
uint short_count;
uint long_count;
uint weather_rx_state;
boolean packet_start = false;
// byte arrays used to store incoming weather data
byte weather_packet[(WEATHER_PACKET_BIT_LENGTH)];
byte last_weather_packet[(WEATHER_PACKET_BIT_LENGTH)];
// packet counter - 4 identical packets in a row means the packet is valid
int packet_count = 0;
/* Overflow interrupt vector */
ISR(TIMER1_OVF_vect){ // here if no input pulse detected
}
/* ICR interrupt vector */
//void rise() {
ISR(TIMER1_CAPT_vect){
// Immediately grab the current capture time in case it triggers again and
// overwrites ICR1 with an unexpected new value
captured_time = ICR1;
//immediately grab the current capture polarity and reverse it to catch all the subsequent high and low periods coming in
if(INPUT_CAPTURE_IS_RISING_EDGE()) {
SET_INPUT_CAPTURE_FALLING_EDGE(); //previous period was low and just transitioned high
} else {
SET_INPUT_CAPTURE_RISING_EDGE(); //previous period was high and transitioned low
}
// calculate the current period just measured, to accompany the polarity now stored
captured_period = (captured_time - previous_captured_time);
// Analyse the incoming data stream. If idle, we need to detect the start of an incoming weather packet.
// Incoming packet starts with a big pulse and the sequence 101010.
if(weather_rx_state == RX_STATE_IDLE) {
if(((captured_period >= BIG_PULSE_MIN_WIDTH) && (captured_period <= BIG_PULSE_MAX_WIDTH))) {
// received a big pulse - indicating the start of a packet
#ifdef DEBUG
// Serial.println("packet start");
#endif
packet_start = true;
} else {
if(((captured_period >= LONG_PULSE_MIN_WIDTH) && (captured_period <= LONG_PULSE_MAX_WIDTH)) && packet_start) {
// long pulse, continue counting long pulses
long_count++;
#ifdef DEBUG
if (long_count >= 2) { Serial.println(long_count); }
#endif
} else if(((captured_period >= SHORT_PULSE_MIN_WIDTH) && (captured_period <= SHORT_PULSE_MAX_WIDTH)) && packet_start) {
// long pulse. if there has been enough short pulses beforehand, we have a valid bit stream, else reset and start again
short_count++;
#ifdef DEBUG
if (short_count >= 2) { Serial.println(short_count); }
#endif
} else {
// not a long or short pulse, therefore not a valid bitstream
WEATHER_RESET();
#ifdef DEBUG
// Serial.println("reset");
#endif
}
}
if((short_count >= SHORT_COUNT_SYNC_MIN) && (long_count >= LONG_COUNT_SYNC_MIN)) {
weather_rx_state = RX_STATE_RECEIVING;
Serial.println("receiving");
}
} else if(weather_rx_state == RX_STATE_RECEIVING) {
// incoming pulses are a valid bit stream, non manchester encoded.
if(((captured_period >= SHORT_PULSE_MIN_WIDTH) && (captured_period <= SHORT_PULSE_MAX_WIDTH))) {
// short pulse
// Serial.print("0");
weather_packet[packet_bit_pointer] = 0;
packet_bit_pointer++;
}
else if(((captured_period >= LONG_PULSE_MIN_WIDTH) && (captured_period <= LONG_PULSE_MAX_WIDTH))) {
// long pulse
// Serial.print("1");
weather_packet[packet_bit_pointer] = 1;
packet_bit_pointer++;
}
else if(((captured_period >= BIG_PULSE_MIN_WIDTH) && (captured_period <= BIG_PULSE_MAX_WIDTH))) {
Serial.println("done");
// got another long pulse, which marks a repeat of the bitstream
weather_rx_state = RX_STATE_PACKET_RECEIVED;
}
// check to see if a full packet has been received
/* if(packet_bit_pointer >= WEATHER_PACKET_BIT_LENGTH) {
// full packet received, switch state to RX_STATE_PACKET_RECEIVED
weather_rx_state = RX_STATE_PACKET_RECEIVED;
}
*/
}
// save the current capture data as previous so it can be used for period calculation again next time around
previous_captured_time = captured_time;
}
void setup() {
Serial.begin(115200);
DDRB = 0x2F; // B00101111
DDRB &= ~(1<<DDB0); // PBO(ICP1) input
PORTB &= ~(1<<PORTB0); // ensure pullup resistor is also disabled
DDRD |= B11000000; // (1<<PORTD6); //DDRD |= (1<<PORTD7); (example of B prefix)
//---------------------------------------------------------------------------------------------
//ICNC1: Input Capture Noise Canceler On, 4 successive equal ICP1 samples required for trigger (4*4uS = 16uS delayed)
//ICES1: Input Capture Edge Select 1 = rising edge to begin with, input capture will change as required
//CS12,CS11,CS10 TCNT1 Prescaler set to 0,1,1 see table and notes above
TCCR1A = B00000000; //Normal mode of operation, TOP = 0xFFFF, TOV1 Flag Set on MAX
//This is supposed to come out of reset as 0x00, but something changed it, I had to zero it again here to make the TOP truly 0xFFFF
TCCR1B = ( _BV(ICNC1) | _BV(CS11) | _BV(CS10) );
SET_INPUT_CAPTURE_RISING_EDGE();
//Timer1 Input Capture Interrupt Enable, Overflow Interrupt Enable
TIMSK1 = ( _BV(ICIE1) | _BV(TOIE1) );
// attachInterrupt(0, rise, RISING);
WEATHER_RESET();
Serial.println("\"joshhawk\" Weather Station receiver v0.01");
Serial.println("Ready to receive weather data");
}
/*
* main loop
*/
void loop() {
// weather packet ready to decode
if(weather_rx_state == RX_STATE_PACKET_RECEIVED) {
#ifdef DEBUG
Serial.println();
for(int i = 0; i < ((WEATHER_PACKET_BIT_LENGTH)); i++) {
Serial.print(weather_packet[i], BIN);
Serial.print(" ");
}
Serial.println();
#endif
WEATHER_RESET();
}
}
joshhawk:
So I've written a preliminary sketch (basically just modified "Thermor", someone else's weather station code). I'm having trouble actually reading the packets - it seems to miss bits or miss entire packets altogether. Any idea what I could be doing wrong?
Does this weather station use the same bit encoding scheme as the one your hacking?
The code is at the limits of my Amtel & C++ language knowledge (only started just after xmas). Many years ago I wrote a similar program to decode SMPTE timecode on a PIC microcontroller in assembly. I used a similar principle though only bothered with rising edges for interrupts. A quick look makes me think you could do the same using just falling edge with this signal.
No, the bit encoding scheme is different, hence the code I've written... I'm going to keep poking at it. If anyone else with some experience in this area sees where the flaw is in my code, definitely let me know!
Hey Riva, do you think that the timing of the edges can be accurately measured by what we've been doing through audacity? I've made a rough estimate that the short pulses are ~1000us from edge to edge, long edges are ~2000us, and the "big" pulse that starts and ends a packet is ~3500us. Does that seem right?