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?
joshhawk:
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?
I had looked at this a while back when thinking of best algorithm for reading pulses and concluded a 1-2-3 ratio. 1 being a clear bit , 2 being a set bit & 3 being packet start. You could maybe create some clean sequences in audacity using copy & paste and play them to your code that logs interrupt periods so you can fine tune the timings.
I think it’s possible to read the burst successfully using falling edge interrupts only. The interrupt code would be a simple state machine that determine duration between edges and this duration would drive the states.
Wait for a 3x duration then start reading bits
if duration < 1x then back to state 1. if duration > 3x then back to state 1 if all bits have not been read
check correct preamble and stop bits, back to state 1 if wrong
copy value to buffer and set flag for main code to read it. revert back to state 1
Main code would wait for flag and then compare/copy value with previous value(s) if you have 2 or more same values then assume it’s a good reading and decode as needed.
I finally managed to pull together enough time/resources to tackle this reading/decoding problem.
*** First off I don’t have a weather sensor so none of this code is confirmed working in the real world. ***
I captured the sample .wav files attached to several of the posts in this thread into my UNO to convert to logic level so I could record them with a logic analyser. I then wrote the attached test code for reading the playback from my analyser and it seems to work okay with the samples I have.
It uses pin 2 interrupts to read the data and interacts with the main program using flag bits.
To signal data available F_HAVE_DATA is set, because the data does not contain any form of CRC if 2 or more consecutive reads are the same then F_GOOD_DATA is also set. You read the unsigned long result from ‘read_Buffer’ and should then clear F_HAVE_DATA so you know when another reading arrives.
