Arduino Forum

Topics => Device Hacking => Topic started by: 3zero8 on Jan 31, 2014, 02:11 am

Title: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: 3zero8 on Jan 31, 2014, 02:11 am
For my first RF project, I'm attempting to capture and decode 433 MHz RF signals received from a remote Thermo-Hygrometer sensor in order to perform some home automation at various temperature and humidity levels.  This is the Thermo-Hygrometer that I am using:
http://www.ambientweather.com/amws08x2kit.html (http://www.ambientweather.com/amws08x2kit.html)

I'm able to capture the RF signals in Audacity using a setup similar to this one:
http://davehouston.net/learn.htm (http://davehouston.net/learn.htm)

I have attempted to decode the signals with NRZ and Manchester coding then searching the results for the BCD and binary representation of the decimal temperature/humidity, in various bit and byte endianness, but have not been successful.

I would like to know:
> Is there anything I am missing?
> Am I using the correct decoding?
> Any suggestions or next steps?

Signal Screen Captures:

18.6 C 36%RH
https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF2.png (https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF2.png)

000000000011100101001100000100000000101000101011000000000000011100101001100000100000000101000101011000000000000011100101001100000100000000101000101011000

18.6 C 36%RH
https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF3.png (https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF3.png)

000000000011100101001100000100000000101000101011000000000000011100101001100000100000000101000101011000000000000011100101001100000100000000101000101011000

18.7 C 44%RH
https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF6.png (https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF6.png)

000000000011100101001100000100010000001010000011000000000000001110010100110000010001000000101000001100000001000000111001110011000001000100000011100111110000

19.2 C 43%RH
https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF7.png (https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF7.png)

000000000011100101001100000100011100110000010100000000000000111001010011000001000111001100000101000000000000001110010100110000010001110011000001010000

19.3 C 38%RH
https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF8.png (https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF8.png)

000000000011100101001100000100010100010000100011000000000000011100101001100000100010100010000100011000000000000011100101001100000100010100010000100011000

Signal pattern repeated 3 times:
https://dl.dropboxusercontent.com/u/54300346/WS-08RF/Pattern.PNG (https://dl.dropboxusercontent.com/u/54300346/WS-08RF/Pattern.PNG)

RF Signal Width Distribution Graph:
I used this to determine what should be considered a long pulse and a short pulse
https://dl.dropboxusercontent.com/u/54300346/WS-08RF/Signal_Width_Distribution.png (https://dl.dropboxusercontent.com/u/54300346/WS-08RF/Signal_Width_Distribution.png)

Thank you in advance for any assistance you can provide!
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: jremington on Jan 31, 2014, 02:44 am
I couldn't make out the signal traces on my screen, but with long and short pulse you are on the right track.

Temporarily assign 1 and 0 to one or the other and compare the patterns you see with the numbers you know are being transmitted. There is probably a preamble, a device ID, some data coded as either binary or binary coded decimal, and a checksum of some sort.

There are lots of examples on the web of similar transmissions that have been successfully decoded. Here is a collection at http://fredboboss.free.fr/tx29/index.php
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: 3zero8 on Jan 31, 2014, 08:21 pm
Thank you for the encouragement jremington; I feel a little better having someone tell me that I'm on the right track.

I have performed a great deal of research, testing, sampling, and analyzing before posting here.  As you noted there are a lot of great resources for decoding weather station signals and RF signals in general.  I will share a few that I have come across in case they are useful to someone else:

http://forum.arduino.cc/index.php/topic,110662.msg840578.html#msg840578
http://forum.arduino.cc/index.php/topic,112699.0.html
http://forum.arduino.cc/index.php?topic=145341.0
http://lucsmall.com/2012/04/29/weather-station-hacking-part-2/
http://www.f6fbb.org/domo/sensors/tx3_th.php
http://thekidd.ca/blog/tech/home-automation-ac-wall-plugs-rf-modules-and-an-arduino
http://rayshobby.net/?p=3381
http://bertrik.sikken.nl/433mhz/

As for the message, I believe that the entire data stream is repeated three times within each transmission.  You can see the repetition in the following:

(https://dl.dropboxusercontent.com/u/54300346/WS-08RF/Pattern.PNG)

When comparing multiple RF transmissions, one can see that the first 32 bits, in red below, never change… this I assume is the preamble, device id, unused data fields, and possibly a check sum.

(Each new line below is a separate transmission)
0000000000111001010011000001000000010010100001010000
000000000011100101001100000100000000101000101011000
000000000011100101001100000100000000101000101011000
0000000000111001010011000001000000010010001010010000
0000000000111001010011000001000000010010001010010000
00000000001110010100110000010001110011000001010000
000000000011100101001100000100010100010000100011000
0000000000111001010011000001000110101001001011000
0000000000111001010011000001000111001011001010000
00000000001110010100110000010001101010100100001000

If you remove the static bits, the bits below remain to store the temperature and humidity…

(Each new line below is a separate transmission)
10010100001010000
101000101011000
101000101011000
10010001010010000
10010001010010000
1110011000001010000
10100010000100011000
110101001001011000
111001011001010000
1101010100100001000

According to the manufacturer, the humidity is in the range of 10-99 which I believe would require 7-bits minimum to store.  The temperature values are from -40 to 140 degrees F, again I believe requiring a minimum of 7-bits for a total of 14-bits to transmit both humidity and temperature.

None of the signals are shorter than 14-bits so this is feasible… but no matter how I flip the bits or the order I read them I am not able to decode... This is what causes me to suspect that I may be interpreting the signal incorrectly...
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: jremington on Jan 31, 2014, 09:16 pm
Decoding that signal may not be easy, but it is an interesting challenge.

It is very helpful to compare signals that differ by the minimum possible number of bits. For example, if you could compare several signals reporting exactly the same humidity, but minimal variations in temperature of for example 18.5, 18.6, 18.7 etc. degrees, that will help a lot. Also, if you can capture a temperature of exactly 0.0 degrees, that can be very useful.

Another useful piece of information is how a presumed checksum (usually one byte, but I've seen a 4-bit checksum) varies with any change in the message. If the message changes by exactly one bit, but many checksum bits change, then it is probably a CRC type of checksum. If only one checksum bit changes when one message bit changes, it is probably a simple sum.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Feb 01, 2014, 08:21 am
Hi folks I have "hacked" two different brands of weather stations, the Bios (or Thermor) and the Oregon Scientific V3.0 and been able to intercept the signals successfully.  I have documented this in these two postings where source code (plus comments!) are provided -
http://forum.arduino.cc/index.php?topic=167364.msg1432791#msg1432791 (http://forum.arduino.cc/index.php?topic=167364.msg1432791#msg1432791) The Bios weather station
http://forum.arduino.cc/index.php?topic=203425.0 (http://forum.arduino.cc/index.php?topic=203425.0) Oregon Weather  Station V3.0 protocols

I had to ditch the Bios as it just wore out, and I am now concentrating on the Oregon system. The Oregon is now providing local weather information for my website http://www.laketyersbeach.net.au/ (http://www.laketyersbeach.net.au/)

Both systems use Manchester encoding, but with opposite polarity conventions.  The signal frame's timing was similar but the data structures were quite different.

The Bios had a single transmitter (all the sensors were wired to a common point), no checksum and varying length data payloads, but transmitted 4 copies of the data for three different sensors every 40secs (approx). So it took 120 secs to get all the data.  The repetition meant receiving 4 identical data payloads = data is ok.

The Oregon has separate transmitters in the rain gauge, anemometer and temperature, and all periodically transmit a single data payload in different length cycles (eg anemometer say every 20 seconds, rainfall every 80 seconds) , so some overlapping data corruption is inevitable.  However it has a constant length data payload, and employs a simple checksum routine to check the integrity of the data.  The Oregon is versatile in that other sensors from the V3.0 format could be added easily to the line up eg a UV light detector.

Both designs used a rolling ID number that changed every time it was reset or batteries were changed and both used a mixture of BCD and pure binary in number formats.  Both used a stream of ones to synch the receiver, about 80 for the Bios and about 20 for the Oregon.  The Bios had its first zero in the data stream outside of the data byte boundaries, whereas the Oregon has the first zero within the data byte boundaries and hence part of the checksum.

You may find the two programs interesting in your quest to understand the protocol even though they are different brands to yours.  I employ a system of delays to sample the waveform rather than counting with interrupts and then decode the data.

I will look at the progress with interest, Cheers, Rob
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Feb 01, 2014, 09:19 am
Sorry to not have spotted this earlier 3zero8, but I missed your very long and thin graphics of your signal sampling.  I have had a much closer look at your data.

I noticed that you were assuming the data stream begins with 0's when most Manchester formats begin with 1's.  This made me suspect that analysis of the data stream into 0&1's may not be correct.

I have only worked on the first 20 or so bits as a Manchester encoding to test the water and see what you think.  I think it is encoded with a 0->1 signal transition in the middle of the bit period means a 1, and a 1->0 signal transition is a zero (so similar to the Bios).  The black arrows going down, are where zeros are found and where the green arrows are going upwards are ones. (The signal transitions not so marked are actually at the start and finish of the of the full bit patter. The signal transitions that indicate the data, 0 or 1 are in the middle of this, and when the data stream swaps from 0->1 or a 1->0 there is actually no transition at the end and start of the bit patterns.  Weird but true!  It allows the signal polarity to swap.).  If the green and black arrows are evenly spaced that makes it likely it is Manchester.

As you can see your bit stream of 0&1's is quite different from mine.  I maybe wrong with this attempt but I think it is worth considering.
Yours- 000111001010
Mine- 11110101000101100
So if it is Manchester then discard the first 4 '1's' above as a header of ones to stabilise the AGC on the RX, so no data in them.
The next 0 is what synch's the rest of the data stream and may or may not be included in the data byte boundaries.
The rising edges in the header zone is what the search program synch's with and sets the place where all other transitions are sampled.  Signal 0->1=logic 1 and Signal 1->0= logic 0. The first time a 1->0 transition occurs at that time, and this then marks where data payload begins.
Keeping your program locked into this waveform format is the next challenge, and my programs I have listed in my previous post will help you with that sampling.
When you can confidently get a stable stream of  a header, the start 0, and data payload as a binary list then you can more confidently start picking the patterns to unravel the weather data hidden within.  Using a dump routine that formats the binary better than Serial.print(nos, BIN) which strips leading zeroes will help a lot in getting the byte boundaries worked out (again there is an example in my programs or see below).  Also be aware that if they use BCD encoding of numbers, then they will not conform to the "such and such number range" will require so many bits to be encoded.  Decoding the bytes to Hex can help detect BCD.

Code: [Select]

void binBank(){
 //Print the fully aligned binary data in manchester[] array
 Serial.println("D 00 00001111 01 22223333 02 44445555 03 66667777 04 88889999 05 AAAABBBB 06 CCCCDDDD 07 EEEEFFFF 08 00001111 90 22223333");
 Serial.print("D ");
 for( int i=0; i < maxBytes; i++){
   byte mask = B10000000;
   if (manchester[i]<16){
     Serial.print("0"); //pad single digit hex
   }
   Serial.print(manchester[i],HEX);
   Serial.print(" ");
   for (int k=0; k<8; k++){
     if (manchester[i] & mask){
       Serial.print("1");
     }
     else{
       Serial.print("0");
     }
     mask = mask >> 1;
   }
   Serial.print(" ");
 }
 Serial.println();
}


I hope I am on the right track, and this will help you.
Let me know what you think.

Rob

 



Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: jremington on Feb 02, 2014, 11:02 pm
If this signal is Manchester encoded, then the encoding appears to violate the premise that the transition occurs in the middle of the bit period. The spacings between the green and black arrows in robwlakes' proposal aren't equal. However, at least one of the three Oregon Scientific protocols is a Manchester code with an off-center transition, so that is certainly possible.

I agree that transmissions usually start with a collection of "1" bits, so it would be useful to reverse the 1/0 assignments you've already made to see if that helps. It would also be good to measure the LOW pulse widths to see how their statistics look. If the signal is Manchester encoded, there should be two pulse widths for LOW and two for HIGH, with approximately equal timings. If that turns out to be the case the decoding will be easy.

Post your results and we will try to help!  Again, if you can, collect transmissions that differ by the minimum possible number of bits.

Edit: After looking at one of the transmissions a bit more closely, I tend to agree with robwlakes assessment that the encoding is Manchester, but the bit transition does not occur in the middle of the interval. A bit time of about 48 pixels seems to fit the data for RF2.png. A transition late in the interval, from low to high, is likely to be a "1" and a transition from high to low, early in the interval, is likely to be a "0" as he suggested.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: 3zero8 on Feb 04, 2014, 01:33 am
Hello everyone and thank you for your assistance.  I had a chance to collect additional samples and work on this problem some over the weekend. 

JRemington I took your suggestion to eliminate the humidity as a changing variable in the data.  To ensure a consistent humidity reading, I cracked open the sending unit and hacked the humidity sensor.  Also per your recommendation, I collected a number of temperature readings which varied by only .1 degree C.  I was able to do so by placing the sensor in close proximity to a light bulb which steadily increased the temperature without any jumps.

Rob I had previously come across your BIOS and Oregon Scientific station posts and they are a wealth of information; I studied the Oregon Scientific protocols document that you posted at length a couple weeks ago.  As far as the Ambient Weather signal, you were spot on with the Manchester encoding. I had decoded a few signals by hand this way, but after not finding the values I was looking for, had given up thinking that the signal widths deviated too greatly for Manchester encoding.

With your helpful posts, I believe that I have successfully extracted temperatures and humidity from a number of samples, however analysis on a wider range of data is needed to confirm.  I will also be attempting to determine the checksum area and method, which I believe is in the last 2 bytes of data.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: 3zero8 on Feb 04, 2014, 02:09 am
Samples with Temperature and Humidity positions















TTTTTTTTTTTHHHHHHHH
21.1C 11RH11111111111010100010101001111000001000100101100001011010100100000
21.0C 13RH11111111111010100010101001111000001000100101000001101011100010000
21.1C 13RH11111111111010100010101001111000001000100101100001101001100100000
21.2C 13RH11111111111010100010101001111000001000100111000001101010011000000
21.3C 13RH11111111111010100010101001111000001000100111100001101000011110000
21.4C 13RH11111111111010100010101001111000001000101001000001101111111110000
21.5C 13RH11111111111010100010101001111000001000101001100001101101111000000
21.6C 13RH11111111111010100010101001111000001000101010000001101010001000000
21.6C 13RH11111111111010100010101001111000001000101010000001101010001000000
21.7C 13RH11111111111010100010101001111000001000101011100001101100000010000
21.8C 13RH11111111111010100010101001111000001000101100000001101000000110000
22.2C 13RH11111111111010100010101001111000001000110000000001101010101000000


Given the following example: 21.3C 13RH 11111111111010100010101001111000001000100111100001101000011110000

Extract Temperature:
Temperature bits: 10001001111
Convert to decimal: 1103
Equation: (1103 - 400) * 0.1 = 70.3 or 21.3C (rounded)

Extract Humidity:

Binary: 00001101
Convert to decimal: 13 RH
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: jremington on Feb 04, 2014, 02:51 am
Good job!

I'm guessing that the next 8 bits after the humidity is a CRC-type checksum. If you convert the message to hex, then reveng is a program to help work out the checksum polynomial. The source code for reveng is here http://reveng.sourceforge.net/  See this thread for an example of reverse engineering the CRC calculation of an Oregon Scientific weather sensor: http://sourceforge.net/p/wmrx00/discussion/855158/thread/62e765df

I used Code::Blocks to make a PC console application of reveng.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Feb 05, 2014, 10:45 am
Hi 3zero8,
More on your checksum/CRC challenge -
http://www.youtube.com/watch?v=UAtmQKvMuoQ (http://www.youtube.com/watch?v=UAtmQKvMuoQ)
suggests it is
Quote
Checksum is CRC8 (polynomial x8+x5+x4+1 = 100110001)


And if that does appear to be the case, then this may help set it up http://www.leonardomiliani.com/2013/un-semplice-crc8-per-arduino/?lang=en (http://www.leonardomiliani.com/2013/un-semplice-crc8-per-arduino/?lang=en)

The V3.0 Oregon Scientific was a simple 4-bit sum of the preceding Nibbles, much simpler than a CRC8 polynomial. Plus if the same payload is transmitted identically more than once in a packet then it may not have a checksum of any sort (as per the Bios).

Nice work on the decoding so far, excellent progress,

Rob
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Feb 08, 2014, 11:41 am
How's it going 3zero8?
I don't want to put any pressure on, but I am intrigued as to how you are progressing.  I was very tempted to buy the Ambient system myself, and would love to know what the final format was.  The integrated solar system was very attractive as well as the overall integrated package on the one "pole". Plus suppliers also seemed to sell spares on the internet as well.  I can't change brands myself now, but your work will be appreciated by many I am sure. Will you go on to do the Anemometer and rainfall etc as well?
Cheers, Rob
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: jenfour6 on May 23, 2014, 04:01 am

For my first RF project, I'm attempting to capture and decode 433 MHz RF signals received from a remote Thermo-Hygrometer sensor in order to perform some home automation at various temperature and humidity levels.  This is the Thermo-Hygrometer that I am using:
http://www.ambientweather.com/amws08x2kit.html (http://www.ambientweather.com/amws08x2kit.html)

I'm able to capture the RF signals in Audacity using a setup similar to this one:
http://davehouston.net/learn.htm (http://davehouston.net/learn.htm)

I have attempted to decode the signals with NRZ and Manchester coding then searching the results for the BCD and binary representation of the decimal temperature/humidity, in various bit and byte endianness, but have not been successful.

I would like to know:
> Is there anything I am missing?
> Am I using the correct decoding?
> Any suggestions or next steps?

Signal Screen Captures:

18.6 C 36%RH
https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF2.png (https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF2.png)

000000000011100101001100000100000000101000101011000000000000011100101001100000100000000101000101011000000000000011100101001100000100000000101000101011000

18.6 C 36%RH
https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF3.png (https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF3.png)

000000000011100101001100000100000000101000101011000000000000011100101001100000100000000101000101011000000000000011100101001100000100000000101000101011000

18.7 C 44%RH
https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF6.png (https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF6.png)

000000000011100101001100000100010000001010000011000000000000001110010100110000010001000000101000001100000001000000111001110011000001000100000011100111110000

19.2 C 43%RH
https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF7.png (https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF7.png)

000000000011100101001100000100011100110000010100000000000000111001010011000001000111001100000101000000000000001110010100110000010001110011000001010000

19.3 C 38%RH
https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF8.png (https://dl.dropboxusercontent.com/u/54300346/WS-08RF/RF8.png)

000000000011100101001100000100010100010000100011000000000000011100101001100000100010100010000100011000000000000011100101001100000100010100010000100011000

Signal pattern repeated 3 times:
https://dl.dropboxusercontent.com/u/54300346/WS-08RF/Pattern.PNG (https://dl.dropboxusercontent.com/u/54300346/WS-08RF/Pattern.PNG)

RF Signal Width Distribution Graph:
I used this to determine what should be considered a long pulse and a short pulse
https://dl.dropboxusercontent.com/u/54300346/WS-08RF/Signal_Width_Distribution.png (https://dl.dropboxusercontent.com/u/54300346/WS-08RF/Signal_Width_Distribution.png)

Thank you in advance for any assistance you can provide!


Sounds like a good plan, just on a side note remember to regularly re-calibrate the thermo-hygrometer.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Jul 01, 2014, 09:55 am
hi jenfour6,

I have looked at the first captured waveform image in your list and I believe you are dealing with Manchester encoding.  I have gone through and annotated it below the waveform with what I reckon are the correct bit decoding (see attachment).  There are three packets I believe, as the bit pattern repeats three times ABC.

If you would like a good intro to Manchester encoding I have made an effort to explain it here https://github.com/robwlakes/ArduinoWeatherOS (https://github.com/robwlakes/ArduinoWeatherOS).  Briefly it is based on transitions rather than durations (each bit, 0 or 1 has the same amount of "lo and hi" time) and in your case lo->hi =1 and hi->lo=0. The trick is being able to recognise what is happening in the middle of any bit pattern.  Transitions in the middle tell what the data bit is.  Then being able to ignore the transitions (or no transition!) that occur at the start or end of a bit pattern, as they don't matter.  My article is about my Oregon Scientific WS which has a Manchester polarity that is the reverse hi->lo=1 and lo->hi=0, but the general principles of understanding the code and how to decode are provided there.

My older Forum article http://forum.arduino.cc/index.php?topic=167364.0 (http://forum.arduino.cc/index.php?topic=167364.0) on Bios/Thermor WS's will also be very relevant as it covers Manchester encoding with same polarity as yours, and it also uses a "triple-packet-send" as a data validation process.  It also has handy debug printing routines that will help you print the packet in hex and then this will allow you to put together the bytes in the packet, and the environmental readings, easier. eg dumping the whole packet to a hexadecimal string.

Cheers, Rob
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: Tops on Jul 14, 2014, 08:53 pm
Hello,

I was pleased to find this forum - I am trying to do the same thing but am stuck. First I thought I should share some of the info I think I have deduced so far which is not yet here. Using the binary from the 21.1C 11RH example already posted-

The first 21 bits appear to always remain constant
111111111110101000101

The next 8 bits appear to reset randomly each time there is a battery change
01001111

The last three bits of the next 4 appear to be the channel number. There are eight channels that can be set using the dip switches on the back of the unit and these are represented 000 (Channel 1, sent as 0) through to 111 (Channel 8 sent as 7). All the examples shown in this thread appear to be from a unit set to channel one. As the first bit is not required to communicate channel number it may have another purpose.
0 000

The following single bit is in fact part of the temperature reading, it indicates whether the reading is positive (0) or negative (1).
0

The rest is as previously discussed - 11 bits of temperature reading, 8 bits of humidity then 8 bits of CRC.
10001001011 00001011 01010010

Anyway I was wondering if anybody had got a working sketch, I am still having difficulties with
1. Separating the signals from multiple sensors
2. Cracking the CRC
3. Getting my code to work

Andrew
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Jul 15, 2014, 02:19 am
Hi Andrew,

Pleased to be of any assistance.

Quote
The first 21 bits appear to always remain constant
111111111110101000101
This would probably be the header (1's + a Zero) and the ID of the type of unit it is in the Ambient range.

Quote
The next 8 bits appear to reset randomly each time there is a battery change
01001111
this is to distinguish your system (hopefully) from any other nearby Ambient transmitter of the same type, eg a Neighbour's WS with the same ID

Your next analysis I can only agree with as having a system to experiment with is the only way of checking, ie check Arduino outputs with what the Ambient console is showing.  I don't have one to experiment with.  However going on your evidence I have doctored my debug version for my old Bios/Thermor WS for you to try and further develop if you get any success from it.

I believe the Bios protocol shares a few important aspects with the Ambient.  Such as lo-hi=>1, hi-lo=>0 for the Manchester Encoding.  I am not sure if it has the first (sync) 0 within the byte boundaries or outside them.  I have indicated in the program where you can alter that to try either way.  You have to look where your other data is falling to work it out.  eg does the temp and humidity data fall squarely within bytes?  The Bios WS did not have a checksum as it sent the whole packet 4 times over each time, so getting 4 identical packets was how the data was validated.  Given the Ambient sends the data 3 times I have adjusted the program to look for 3 identical packets.  Also the Bios had about 80 header bits, more than enough I think!!!  The Ambient looks to have about 10 or 11 so I have adjusted the program to look for 7, so we have a few left over (the program just dumps any excess).

The program is also set up for you to dump the whole three packets into a byte array and then dump this out as binary for your inspection.  At the moment it only dumps out when it gets three identical packets, however you may need to change it to have it dump/debug all three packets separately to look at what you are getting if they are not identical first up.  The program is set to capture 6 bytes (I counted 54 bits in the packet (including a few 0's at the end that looked like padding) so I thought 6x8=48 should be an ok number to collect.  Change it to 5 if you find you can't validate with 6.

The last bits after the humidity could be just junk for padding. Anyway you can have a look as see what they do once you get it dumping binary/hex.  For example all the data you really need to check maybe in the first 5 bytes and you will be able to ignore the last byte if it has random junk in it.  However it could also be a checksum as you say.  My Oregon Scientific WS on the other hand does not repeat the sensors's packet and has a simple summing check-byte at the end of the data bytes, not a difficult polynomial check like some have.  I do have a reference to one of these I can dig out, but I would be betting on no check sum with a repeat of three packets occurring.

The rest of the program is to do with processing the packets according to the Bios WS rules, you will need to devise your own for the Ambient to suit your application, however I hope they don't just get in the way and do help you formulate your own calculation routines.

I have run a compile check on the program and it appears error free in that respect, however the chances I have cracked a perfect score for you so it "runs straight out of the box" are very slim, so I wish you all the best to get any final wrinkles out of it.  Eg enable the printing of the "H" when a valid header is received, if you need to check that).

Let us know how you go, best wishes,

Rob


Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: Tops on Jul 27, 2014, 05:25 pm
Rob,

Thank you so much for your excellent articles on decoding weather signals and for your encouragement. I have had lots of fun playing with the code.

I have taken a while to reply as I still have not got anything working and I wanted to check obvious possibilities before reposting.

First - I know that my hardware is set up correctly. I used the code below to monitor the RX input.

Code: [Select]
//Define settings
const int INPUT_PIN = 8;                                       //Input pin
const unsigned int MAX_SAMPLE = 256;                           //Maximum number of samples to record
const unsigned long MAX_TIME = 30000UL;                        //Maximum record time after start pulse (msec)

//Variables used in the ISR
volatile boolean running = false;
volatile unsigned long last = 0;
volatile unsigned int count = 0;
volatile unsigned long samples[MAX_SAMPLE];

void setup() {
  pinMode(INPUT_PIN,INPUT);
  Serial.begin(9600);
  while (!Serial) {};
  Serial.println("RecordPin sketch started");
}

void loop() {
  unsigned long startTime;
  int startState = 0;
 
  while (Serial.read() != -1) {};                              //Clear the serial input buffer
  Serial.println("Send character to start");
  while (Serial.read() == -1) {};                              //Wait until we receive the first character
  while (Serial.read() != -1) {};                              //Clear the rest of the buffer
  startState = digitalRead(INPUT_PIN);                         //Save the initial port state
  attachInterrupt(0, receiver, CHANGE);                        //Interrupt 0 = Pin 2
  count = 0;
  last = micros();
  running = true;
  Serial.print("Running. Send a character to stop");
  startTime = millis();
  while (running && ((millis() - startTime) < MAX_TIME)) {     //Run until the buffer is full, the time is up, or we receive a character
    if (Serial.read()!= -1) {                                  //Stop if we receive a character
      running = false;
    }
  }
  Serial.println("Stopped");
  detachInterrupt(0);
  Serial.print("I recorded ");
  Serial.print(count);
  Serial.println(" samples");
  for (unsigned int x = 0; x < count; x++) {
    Serial.print("Pin = ");
    if (startState == 0) {
      Serial.print("Low ");
    } else {
      Serial.print("High");
    }
    startState = !startState;
    Serial.print(" for ");
    Serial.print(samples[x]);
    Serial.println(" usec");
  }
  Serial.println("");
}

//Pin change interrupt routine
//Called when the state of the input pin changes
void receiver()
{
  if (running) {                                               //If we are running
    samples[count] = micros() - last;                          //Save the time from the last change to this one
    last = micros();                                           //Reset the time of last change
    count++;                                                   //Go to next buffer entry
    if (count > MAX_SAMPLE) {                                  //If we are past the last entry
      running = false;                                         // we stop
    }
  }
}


The results look like this

Code: [Select]

Pin = High for 480 usec
Pin = Low  for 488 usec
Pin = High for 484 usec
Pin = Low  for 480 usec
Pin = High for 480 usec
Pin = Low  for 484 usec
Pin = High for 492 usec
Pin = Low  for 476 usec
Pin = High for 488 usec
Pin = Low  for 484 usec
Pin = High for 484 usec
Pin = Low  for 492 usec
Pin = High for 472 usec
Pin = Low  for 488 usec
Pin = High for 484 usec
Pin = Low  for 484 usec
Pin = High for 488 usec
Pin = Low  for 484 usec
Pin = High for 476 usec
Pin = Low  for 968 usec
Pin = High for 980 usec
Pin = Low  for 960 usec
Pin = High for 1004 usec
Pin = Low  for 920 usec


To make sense of this I have manually decoded the packet using hi-lo => 1 and lo-hi => 0. From sampling hundreds of highs and lows I also know that the average bit is 968 uSecs. So below is the decoding the results above (I have split the longs up to show the result):

Code: [Select]

Pin = High for 480 usec    RX State 1
Pin = Low  for 488 usec    RX State 0 (rising Manchester logic 1)
Pin = High for 484 usec    RX State 1
Pin = Low  for 480 usec   RX State 0 (rising Manchester logic 1)
Pin = High for 480 usec    RX State 1
Pin = Low  for 484 usec    RX State 0 (rising Manchester logic 1)
Pin = High for 492 usec    RX State 1
Pin = Low  for 476 usec   RX State 0 (rising Manchester logic 1)
Pin = High for 488 usec    RX State 1
Pin = Low  for 484 usec    RX State 0 (rising Manchester logic 1)
Pin = High for 484 usec    RX State 1
Pin = Low  for 492 usec    RX State 0 (rising Manchester logic 1)
Pin = High for 472 usec    RX State 1
Pin = Low  for 488 usec   RX State 0 (rising Manchester logic 1)
Pin = High for 484 usec    RX State 1
Pin = Low  for 484 usec    RX State 0 (rising Manchester logic 1)
Pin = High for 488 usec    RX State 1
Pin = Low  for 484 usec   RX State 0 (rising Manchester logic 1)
Pin = High for 476 usec    RX State 1
Pin = Low  for (484) usec  RX State 0 (rising Manchester logic 1)
Pin = Low  for (484) usec   RX State 0
Pin = High for (490) usec   RX State 1 (falling Manchester logic 0)
Pin = High for (490) usec   RX State 1
Pin = Low  for (480)usec   RX State 0 (rising Manchester logic 1)
Pin = Low  for (480)usec   RX State 0
Pin = High for (502)usec    RX State 1  (falling Manchester logic 0)
Pin = High for (502)usec    RX State 1
Pin = Low  for (460) usec    RX State 0 (rising Manchester logic 1)



You may now recognize the sample above as the header with the first two bits of the first byte at the end.

Now to the problem: I cannot capture the data packets! I have tried both the sketch you provided and the interrupt sketches.

Interrupt sketches find the data but it does not match the binary I am decoding manually, the Debugversion sketch reliably finds the header and first 0, but the data packet is very rarely valid (I have captured four in the last week) and the valid captures do not match the binary I extract manually.

I would be very grateful if you, (or any other interested readers) could give me some ideas to correctly capture the four bytes of binary that follows the header and first byte.

Header
1111111111101
First byte (constant)
01000101

Many thanks!
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Jul 27, 2014, 06:02 pm
Hi Tops,

Well done. You have certainly done some excellent research.  I have been helping another person tracking down their weather station decoding on different thread and over the weekend I have tried to produce a general purpose Manchester decoder that people can use to at least get the raw binary in bytes from their weather stations or what ever.  I would expect that once they have achieved that much they will then be happy go on to decipher the packet code add their own calculations etc

You can find the Debug program here:
https://github.com/robwlakes/ArduinoWeatherOS (https://github.com/robwlakes/ArduinoWeatherOS) and it's called DebugManchester.ino.

It would seem that you have got some solid data of 960uS for the bitWaveform duration.  So in the program I have tried to produce (above) try using sDelay=240, and and lDelay=480, and use Polarity= 1, ie negative polarity. ( the first 960approx pause is low, so the rising edge at the end of that is a 0, so lo->hi=0).  I disagree with how you have interpreted the timings.  I think it should decode as  1 1 1 1 1 1 1 0 1 0 1. (My commas separate the bit waveforms, and approx 960 is a full waveform).
Code: [Select]

Pin = High for 492 usec  hi
Pin = Low  for 476 usec  lo = = 1,
Pin = High for 488 usec  hi
Pin = Low  for 484 usec lo  ==1,
Pin = High for 484 usec  hi
Pin = Low  for 492 usec  lo ==1,
Pin = High for 472 usec  hi
Pin = Low  for 488 usec lo == 1,
Pin = High for 484 usec  hi
Pin = Low  for 484 usec  lo ==1,
Pin = High for 488 usec  hi
Pin = Low  for 484 usec  lo ==1,
Pin = High for 476 usec   hi
Pin = Low  for 968 usec  lo ==1, lo    
Pin = High for 980 usec   hi ==0, hi
Pin = Low  for 960 usec  lo ==1, lo
Pin = High for 1004 usec hi ==0, hi
Pin = Low  for 920 usec   lo ==1, lo


Hopefully this will make good use of your excellent efforts so far and give you the bytes you are looking for.  I have tried to produce a recipe style program so change those 3 values in the set up, and hopefully you will see results  :smiley-roll-sweat:  There is also a short guide to how to use the program called Debug.md.

Let me know how you go...

Cheers, Rob  
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: Tops on Jul 27, 2014, 07:02 pm
Thanks Rob,

You are absolutely right with your analysis of the timings - I mucked up the copy pasting when I posted it!

The new sketch works brilliantly and I am now reliably getting all the data - the only problem is aligning the bytes.

The first 0 and the following 1 are both outside the 1st byte - How would I change the program to nudge everything one along when excluding the 1st zero?

Andrew
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Jul 28, 2014, 12:58 am
Hi Andrew,
Very good news indeed.  I have altered the DebugManchester.ino program (and renamed it as well, GIT-Hub can track the versions for me) so that the number of leading bits to discard can be chosen.  Limiting it it to just either keeping or dumping the leading zero proved to be too limited as you have shown.

https://github.com/robwlakes/ArduinoWeatherOS (https://github.com/robwlakes/ArduinoWeatherOS) DebugManchester.ino

I have just introduced a variable "discards" to set to the number to dump, so in your discards=2.  Whereas in my case I keep them all so discards=0, others would use discards=1 to just dump the leading zero.

I would love to know how you went about figuring out your byte boundaries and what processing was required for your data bytes to turn them into human readable form?

Cheers and keep up the good work,
Rob
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Jul 28, 2014, 01:16 pm
Alert: Make sure you download the latest one, the earlier version had a tricky bug that I have eliminated
DebugManchester.ino at
https://github.com/robwlakes/ArduinoWeatherOS (https://github.com/robwlakes/ArduinoWeatherOS)

Another thing that has come to my attention is that the cheaper 433MHz Rx's have slow AGC and you may find that a stronger TX closer to the RX will cause weaker signals from sensors to be lost as the AGC does not recover in time to give them a fair go (so to speak in ultra scientific lingo!)  Try the Dorji line: RF-DRA886RX-S Dorji 443MHZ 107 dBm ASK Receiver, SMD Package

Cheers, Rob
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: Tops on Jul 29, 2014, 06:17 pm
Hello Rob,

Thank you for your invaluable help. Below is my working sketch with commentary in the header. I have had problems with range using my RX so will look into the one you have recommended.

https://github.com/AMcAnerney/Arduino-F007th-Sketches

So the next goals are:
Incorporate error checking to remove the 3% of bad readings
Incorporate a warning if a sensor does not communicate for an extended period of time
Stop printing the data twice (is there something really basic I have overlooked?)
Work on negative temperatures
Devise a way to store values and send them only once a minute on the serial (as a precursor to sending updates to a server later on)
Improve the reception range (probably a hardware issue)

Please let me know if you have any comments or suggestions

Andrew
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Jul 30, 2014, 12:04 am
Hi Andrew,

What excellent progress  :)  very good work.  Thank you for your comments.

I have a few suggestions to make and maybe answers for some of your questions.

I will email your code back to you.  I am just a beginner on GIT-Hub and not confident about the push/pull process.  However I won't attach it here and indirectly publish it myself, and you will obviously need to consider what you keep and what you alter.

There was a late edition to the Debug program (won't be the last I am sure!) that concerned checking the first zero and also making sure the header hits had been equaled or exceeded.  I have added that in.
Code: [Select]
if ((!firstZero)&&(headerHits>=headerBits))
It basically forces the header to be valid before the first zero is accepted.

Secondly I have also simplified the idea of how to discard the leading zero and one in a more general way (Thanks to your request  :) ) track the variable "discards" and you will spot what I have done. However it means the first byte in the manchester[bank][0] array is where to begin for the data ie index=0.  You will need to alter your calculations for temp and hum as they will be one byte out now.

I  have also added a 1 second interrupt that calls a small routine that can trigger off a 1 minute output of your data.  Not original but you will find the acknowledgement in the code.

If you increase the number of bytes required until you stop getting data then you know will have to reduce the maxBytes by one and then you should be looking at all the stable data.  If you are getting two quick transmissions of the same packet then you will probably need to store each packet in a separate manchester[bank][byteNos] and then compare them.  I have inserted a bank check routine that will check all four banks so feel free to modify that as you need.  It may send the packets twice as some form of redundancy and still have a check sum as well.  Watch the byte you suspect is the checksum and see what its behaviour is with changing values in the rest of the bytes.  The Bios WS sent the packet 4 times as validation check, the Oregon Scientific had a simple arithmetic checksum based on nibbles. Ambient may just rely on a comparison of two packets.

If you intend have multiple sensors each with its own transmitter you will need some way of stopping the output until all of them have registered valid numbers, then after that, send output each minute.  Each Tx'er ORing a bit in a byte if successful will allow an easy check.  Now that you have a timer in there you can also set up a check for Tx'ers going "quiet" for too long as well.

You will probably need a more generalised way of calculating from the Manchester[bank] the values for the transmitter/sensors so that your output to the server will be more manageable?   I think you need to use an array of some sort.

These changes may get rid of the 3% bad readings, especially the validation of course.

The final caveat is all I have done is see if the program with my alterations compiles which is definitely no guarantee it is still working.  I am looking forward to see what you do now.  I am impressed and feel you are definitely on the homeward stretch to quite a useful package.

Cheers, Rob 

Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: Tops on Aug 25, 2014, 09:24 pm
Just to let everybody who might be interested know..

My much improved sketch for the arduino and Ambient Weather F007th is available at

https://github.com/AMcAnerney/Arduino-F007th-Sketches

There is some error checking which has almost eliminated the number of bad readings (there are exceptionally humidity readings between 100% and 128%).
I have tested the sketch with negative temperatures (using a ziplock bag and my freezer) and negative temperatures appear to register correctly.
The sketch prints the temperature and humidity readings to serial every 5 minutes.

The final stage for me is to get this data uploaded and logged on a website, my adafruit CC3000 breakout is on the way!

Thank you to all the forum members who have helped.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: Tops on Sep 23, 2014, 07:22 pm
Attached is the final working code.

This accurately captures temperature and humidity data for 6 Ambient Weather F007th sensors and uploads it to Xively every 5 minutes using the Adafruit CC3000.

The code leaves 5 minutes between starting and uploading the first reading - this gives each sensor 5 chances to send in a reading before it becomes a datapoint.

Once the starting temperature and humidity is established the sketch rejects any values where the humidity is outside the range 1-100% OR the humidity is changing at a rate faster than 5% a minute OR the temperature is changing at more than 1.5C per minute.

As as I write this, the sketch has been running smoothly for 5 days without a problem.

Good luck with your own solutions!
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: BaronVonSchnowzer on Jan 22, 2015, 12:26 am
First, thank you to those who worked on the F007TH sketch, especially the manchester decoding.
I choose the Ambient for my project since the code existed, but was not happy not being able to verify the checksum. So I've reversed engineered it. The code is below and here is a link (https://eclecticmusingsofachaoticmind.wordpress.com/2015/01/21/home-automation-temperature-sensors/) to an article on how I tackled it:


I hope that is payback to those who did the heavy lifing on the decoding.

Code: [Select]


uint8_t Checksum(int length, uint8_t *buff)
{
    uint8_t mask = 0x7C;
    uint8_t checksum = 0x64;
    uint8_t data;
    int byteCnt;

    for ( byteCnt=0; byteCnt < length; byteCnt++)
    {
    int bitCnt;
data = buff[byteCnt];

for ( bitCnt= 7; bitCnt >= 0 ; bitCnt-- )
{
            uint8_t bit;

            // Rotate mask right
    bit = mask & 1;
    mask =  (mask >> 1 ) | (mask << 7);
    if ( bit )
    {
mask ^= 0x18;
    }

    // XOR mask into checksum if data bit is 1
    if ( data & 0x80 )
    {
    checksum ^= mask;
            }
    data <<= 1;
}
    }
    return checksum;
}

Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: jremington on Jan 22, 2015, 11:39 pm
Congratulations! That was a heroic effort, and begs the question, why did they do it that way?

BTW the code on the web page is screwed up by the html translations of ">" etc.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: BaronVonSchnowzer on Jan 23, 2015, 01:47 am
Yeah, I wondered if this was random, original algorithm or if it is based on some accepted methodology.

Thanks for the note on the web page. I was so focused on the indentation and style I totally missed those &amps!
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: jremington on Jan 23, 2015, 05:02 am
Some error checking algorithms are actually "forward error correcting", that is, they can be used to correct a limited number of bit errors in a message after it has been received. Hamming codes are an interesting example, where several extra check bits are sent, like 3 extra bits for each set of 4 message bits. This can correct all single bit errors and detect 2 bit errors, but not correct them. See http://en.wikipedia.org/wiki/Hamming_code

It is conceivable that this is one of those algorithms, but that is certainly not obvious and in any case, I doubt more than one bit in the entire message could be corrected using a single byte "checksum" like this one.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Jan 25, 2015, 01:22 pm
Excellent work.
Can you share the rest of your code?
Cheers Rob
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: BaronVonSchnowzer on Jan 25, 2015, 07:25 pm
Would be glad to if you can point me to an easy way of posting the code somewhere. It exceeds the 9K character limit of a post for posting it inline and I haven't tackled using git (I'm still back on Subversion).

Also, is there a way of monitoring a thread? I've marked my replies with "Notify me of replies" but I'm not getting email notifications.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: BaronVonSchnowzer on Jan 25, 2015, 08:37 pm
Per robwlakes request, <update: link removed, code is attached in my next reply) It is based on the excellent work of others on the Manchester decoding found in the F007th sketches. Apologies for the changes for style - it is simply personal preference. I also modified it to use arrays rather than 7 scalars. And removed the Wifi and Xively code I wasn't using. I plan to soon combine it with the webserver example via the exec library and serve the sensor values via my Ethernet shield.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: TomGeorge on Jan 25, 2015, 10:20 pm
Hi, use the Attachments and other options, to attach your sketch.

Tom..... :)
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: BaronVonSchnowzer on Jan 25, 2015, 10:54 pm
Thanks for the pointer. Duh!
Here is the full code attached.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Feb 02, 2015, 11:52 am
That is looking very good. Very compact, effective coding.  Nicely done.

Glad to be of assistance,

Rob
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: whatsupskip on May 25, 2017, 05:05 am
The Ambient F007TH Sensor appears to be the same as the (Australia & NZ) Jaycar XC-0328 kit and the Jaycar XC0329 individual sensor. I just noticed today that they have put both of these on clearance, so this connection is only likely to be of use to those who already have one.

I have been trying to understand the basic parts of the code. I would like to use a NodeMCU ESP8266 or WEMOS equivalent to replace the CC3000 in the existing code.

If I understand correctly, one of the key lines is:

pinMode(RxPin, INPUT);

I can see that "int RxPin = 8;    //The number of signal from the Rx"

I don't understand what this corresponds to. Is it the number of potential sensors? Is it the input on the CC3000?

Using a RXB6 receiver module I was able to decode 433MHz codes from a 433MHz RF switch.
The code used for that used
"mySwitch.enableReceive(13); // Receiver on interrupt GPio 13 => that is pin D7"

Would the line become?:
pinMode.enableReceive(13);

Any assistance would be very much appreciated.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: jremington on May 25, 2017, 05:31 am
Quote
pinMode(RxPin, INPUT);

I can see that "int RxPin = 8;    //The number of signal from the Rx"

I don't understand what this corresponds to.
Arduino pin 8 is used in this case as an input to read the data output by the receiver. Any cheap 433 MHz receiver should work with the code in reply #33 above.

Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on May 25, 2017, 06:14 am
int RxPin = 8;

means that instead of using the character/number "8" to represent the number of the pin in question, the label "RxPin" can be used instead.  Change 8 to another number in that line and that number will be used by the rest of the program wherever RxPin is used. The comment added after the // is quite unhelpful.  As jremington suggests the 433MhzRx's output is attached to pin 8 which is the input in this case.


Quote
Using a RXB6 receiver module I was able to decode 433MHz codes from a 433MHz RF switch.
The code used for that used
"mySwitch.enableReceive(13); // Receiver on interrupt GPio 13 => that is pin D7"

Would the line become?:
pinMode.enableReceive(13);
This is more confusing to me.  mySwitch.enableReceive(13); would be some sort of procedure call either in another part of the same program or a library call.  If it is an Arduino it sounds some what unusual as I am not aware that 13 is the interrupt pin on an Arduino. Usually people just make use of Pin13 as an output with a status LED on it.

pinMode() sets the operation of a given pin as either an input or as an output,  and should not be considered interchangeable with mySwitch (most likely a library call?).

If you have code working with CC3000 it is unlikely you can swap a  NodeMCU ESP8266 or WEMOS in and not adjust your code to the new hardware.  Most likely you will need appropriate libraries for the new hard ware and then have to adapt the main program to use the new hardware library.

I hope this helps, R


Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: whatsupskip on May 25, 2017, 07:01 am
Thank you both for such helpful and prompt responses.

Looks like I will need to do more research on this topic, but at least I appear to have found working code and a well known name and model number of these sensors.

I wonder if Ambient is going to discontinue these sensors or it is just a decision taken by the local importer/distributor Jaycar?
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on May 25, 2017, 07:13 am
I had to swap from a "Bios" weather station setup using a USB interface, to my current one with Oregon Scientific + Arduino->USB and it works so much better.  I bought a second OS Anemometer as a backup, as that was what broke on the Bios (I had bought 2 Bios systems when they were no longer sold, so third time unlucky). However the swap to the OS+Arduino solution is so much better, forced me to move on. I also have a 3-D printer now so could probably print repairs eg broken cups.  :)

Good luck...
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: whatsupskip on May 25, 2017, 07:23 am
Just remember to scan the cups before they are broken. If it is broken in a storm, you might not have all the bits to work with.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: whatsupskip on May 31, 2017, 07:53 am
int RxPin = 8;

means that instead of using the character/number "8" to represent the number of the pin in question, the label "RxPin" can be used instead.  Change 8 to another number in that line and that number will be used by the rest of the program wherever RxPin is used. The comment added after the // is quite unhelpful.  As jremington suggests the 433MhzRx's output is attached to pin 8 which is the input in this case.
Thanks for the help again.

I now have the WEMOS D1 Mini reading the data correctly and outputting the serial monitor.
Here are the changes I made to the code to get it to work.

Code: [Select]

// Libraries
// #include <SPI.h> Not needed as this is already included for ESP8266

#define MAX_BYTES 7
#define countof(x) (sizeof(x)/sizeof(x[0]))
// Interface Definitions
int RxPin           = 13;   // Receiver on interrupt GPIO 13 => that is pin D7

Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: whatsupskip on May 31, 2017, 11:45 pm
https://github.com/robwlakes/ArduinoWeatherOS (https://github.com/robwlakes/ArduinoWeatherOS)

Cheers, Rob 
Rob I was having a look at your Github page, very impressive work. I didn't think a Github page could look that good. In the circuit diagram I noticed that you have the ground next to the antenna connection on the 433MHz receiver going to the ground on the Arduino Uno. If I understand correctly, this is not the correct way to do it. This particular ground is the ground plane for the antenna. Now depending on the physical design of your system and where the antenna is located, the way you have it may actually degrade the reception sensitivity of your system. If it is working fine, then don't worry.

I have been amazed at the range I have been obtaining with the RXB6. I just have it on a breadboard without an antenna and it is picking up the signal at the other end of the house. Never expected that.

Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Aug 05, 2017, 08:53 am
Yep, I agree with what you are saying, I now use a bit of coax with the shield stripped back and the core as an antenna.  So the shield goes to the earth nearest the ANT and the core to the ANT connection.  I have found it works really well.

I have added an indicator light as well as incorporating a UV detector and original sensor in to the design as well.  i am pleased you are getting value from this project.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: AnotherGingerlee on Dec 05, 2017, 04:36 pm
What a great project!

I am really interested because I have built a multi zone heating controller using a Raspberry Pi, but now it needs some wireless thermostats, well, thermometers. I considered porting this code to run on a PIC which would be connected to the Pi using I2C but then I thought that it would be quicker to use an Arduino, but I know NOTHING about them.

Could someone give me some Arduino hints, please.

EG Would a 'Arduino Nano v3.0 - Compatible Board CH340G 5V 16MHz atmega328 Tested' be compatible?
Could I connect it to a PC using USB and no fancy hardware programmer, and then modify the code to send the data to the Pi over I2C or bit-bang it out - using a free development environment?

This is a non-commercial hack so as cheap as possible, please.
I have a homebrew PIC programmer and free C development environment so it would only cost 2.40GBP/3.20USD for a PIC12F1822 if I went that route. (I also have vero board etc lying around)
But I'm sure you want to persuade me to go Arduino, don't you? (where's the smiley face button?)
Sorry to those that get offended at the mention of such 'other' devices!
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Dec 06, 2017, 12:53 am
Well it is up to you of course.  As a PIC user from wayback, there is no way I would return those processors with what the Arduino ecosystem offers now.

I have used the Oregon Scientific (Chinese BTW) sensors and think they are quite good quality for the money.  My GIT-Hub pages outline two types of project.  One is to build an Arduino Uno base station that intercepts OS sensor signals and allows you complete freedom to  build your own system from there on.  The main trick provided in the code is how to intercept the 433MHz signals and decode them.  My strategy was to turn these signals into a string and simply send a serial message across the Arduino's USB/Serial connection back to the main computer (it is now a RPi3, but was an Intel Atom previously). Again this string can be interpreted by Python programs and processed to your hearts content.

433Mhz interceptor:  https://github.com/robwlakes/ArduinoWeatherOS

It also has a good run down on Manchester protocol, which many weather stations use in one way or another, if you wanted to try to roll your own Arduino or PIC version.

The second project involves making your own sensors that can integrate into the OS system without too much hacking.  In essence it is designing your own OS sensor (I have one one monitoring solar energy at the moment, and previously had one monitoring lightning strikes).  All I had to do was extend the code for the list in the Interceptor to detect the new sensors, and add that to the exported string.

Roll your own OS: https://github.com/robwlakes/Weather-Station-OS-Sensors

Note it easy to create a wireless Temperature sensor from Arduino bits and (as shown in the example given) much cheaper as well, if you have the bits lying around.  However it is much harder to replace the OS temperature sensor where low power consumption and long battery life is important.  The OS sensors are very battery efficient and getting a home built sensor into this range is certainly a higher level of difficulty.

The Solar Power sensor I made is based on an Arduino Mini-Pro (the only low power alteration is the power LED has been removed) and it survives long term as it uses a solar panel (and why not? ;-) ) to charge a LiPo battery. If your sensor points are near permanent power, then this will not be a worry.

Get some Arduino Mini-Pro boards, some 433MHz Tx boards and some DS18S20 for the sensors, and an Arduino Uno and 433MHz Rx for the base station and get into it.

The Arduino system does not need a dedicated programmer board, usually just a stock USB cable.  And you get the IDE free with a multitude of very handy libraries.

Cheers, Rob


Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: AnotherGingerlee on Dec 11, 2017, 11:45 am
Thanks Rob for your detailed reply.

I already have a couple of F007TH sensors and a Pi Zero ready to ask for thermometer data over 5v I2C, so  a simple arduino setup to receive the signal, decode it and await the Pi's request is all I need.

A Uno is rather large for an embedded component so I've gone for a Nano clone. I nearly bought a pro micro as its cheaper and smaller but then realised that it makes it difficult to use I2C (apparently D4 and D5 aren't exposed) and also I would need to buy an additional programmer for it as it doesn't have a USB connection.

I currently have a PC connected by USB to a Nano 3 clone CH340 (with the right driver!) connected by D8 to a 433mhz receiver. I have downloaded BaronVonSchnowzer's Temperature.ino and immediately got it working as it sends output to the USB serial device which I can view using serial monitor in the IDE.

I would like to create an I2C slave device but it may not work very well as the RF receive code is timer based. So is there a good reason for it not being interrupt driven? Is it just that state machines are scary? There is already Arduino code out there to do IR receive which uses interrupts, maybe I could adapt that.

PS I've got surprisingly good range having only attached a 17.3cm length of wire to the receiver board. I was considering making a dipole but I won't need to.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Dec 12, 2017, 05:30 am
Hi AG,
I like your style!! Progress already.  I got onto some clone Arduino Pro-Mini versions that are a good size and also have the 4 and 5 exposed in a double strip across the bottom.

https://www.ebay.com.au/itm/Pro-Mini-atmega328-Replace-ATmega128-5V-16M-For-Arduino-Compatible-Nano-DA-/162507940764?hash=item25d63a639c

The only drawback is that I have to press the reset (at the right time) to get it to download, just after a compile.  However they are compact, and with the extra pins quite versatile.  There are many Pro-Mini boards on sale, but not all are like this one.

I haven't tried to create an I2C (or SPI) device, so I can't help you there.  However I have hooked up my Temp transmitter board to the parent Arduino, and removed the 433MHz Tx and RX boards all together and it worked fine, very reliable using the Manchester code.  I did that just to debug the Tx code without blasting the 'real' Rx in the shed with test signals.

The use of interrupts would be good.  I only ended up using a 1 minute "report to RPi3" interval as my old BIOS weather station had all readings combined and sent them once every minute.  My Python code was set up to use it as the time base, so I fashioned the later Oregon Scientific sensor software to replicate the same thing.  My whole Arduino to RPi3 system is centered on the weather sensors so it does not matter if they dominate the situation (plus the weather data for most sensors is only graphed for 12 hours and so the accumulated errors of using the Arduino time base is fairly small over that 12 hours).  Daily long term samples (eg rainfall) are triggered from the clock on the RPI3 which is synced with NNTP. My Arduino base station just reuses the last reading if a new one has not turned up in the last minute. eg anemometer reports every 14 seconds, so rarely (see below though) misses, however UV is 75 seconds cycle but still acceptable for my purposes. 

SPI would be good, and does not insist on interrupts?  I think I would prefer SPI, it does not appear as mysterious as I2C.  RPI has good SPI facilities.  You can choose ;-).  I have used the IR receive interrupt circuits (I designed an advert killer that mutes the TV when the cable adverts come on for 2, 2:30,3:00,3:30 minutes by pressing the Red, Green,Yellow or Blue buttons respectively on the Sony remote.  So it does both, Rx from the human+remote, then translates that to  Tx to mute function. Press the coloured button and it mutes, but comes back on auto-magically :-) eg when still making coffee!!)

The flexible antenna is good. I suspect the rigid helical antennas inside the Oregon Scientific sensors are too rigid and in the extremes of the weather, crack the solder or PCB and become intermittent.  Flexible is better I reckon.  Though harder to sell to the masses, not quite so tidy!!  I have fixed my UV sensor this way.  My anemometer has recently been intermittent so I bought new Lithiums yesterday to replace the batteries.  When I got them down from the roof and tested them, they were very highly charged, so I am suspecting another 17.3cm "whip" antenna coming up very shortly!!! (so to speak).

Cheers, Rob


Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: gliebig on Jan 24, 2018, 12:34 am
This is very cool. I have two F007TH sensors and four F007TP sensors used for refrigerators/freezers. This is my first Arduino project as I've been wanting to get history data from my Ambient system forever! I purchased an Arduino Uno kit (overkill for this) from Amazon along with a 080408 433 mHz receiver and was able to start getting data almost immediately. I had to tweak the code a little for my use. I found that the F007TP sensors have a different ID (datatype 0x46). I was able to modify the Arduino code that Rob posted to basically force the humidity values for the F007TP sensors to 0. I also added a variable in the setup to set the units for Fahrenheit or Celsius changed the units to F. I created some variables at the start to rename my sensors rather than changing the hard coding throughout the sketch.

I haven't completed my project yet, but I'm very close. I still want to use the Battery Bit for notification of a low battery since I don't go into my basement very often and that would be helpful. This isn't done along with the WIFI data collection piece.

Many thanks especially to  BaronVonSchnowzer for his work on reverse engineering the data stream!
Greg
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Jan 25, 2018, 05:07 am
Hi gliebig,

Am I right here in concluding the Oregon Scientific protocol is very similar to the Ambient F007TP?  I would like to get some cheaper thermometer sensors and Ambient are a lot cheaper than the similar OS designs.

Did you use my code mainly or from someone else? Will you post code at some stage, or PM it to me?

Cheers, Rob
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: gliebig on Feb 01, 2018, 03:44 pm
Hi Rob,
Thanks for your response. I've got all 8 of my sensors up. I've used most of your code to start. I've looked at AMcAnerney's code on Github, too.  I did a significant rewrite using loops and arrays to work with the data as error checking in 8 different places with two types of sensors got very confusing.

I do have a significant code question regarding masking the first 5 bytes of rather than the first 4 bytes in manchester bank 3 for the first part of the temperature data. All the research points to using the last 4 bytes in the manchester bank 3 and all the bytes in bank 4 to get the temperature data. Occasionally I'm picking up a high bit in position 4 in bank 3. Because the mask is in place, that bit is not included into the temperature calculation. Is there a reason for this? I'm using F rather than C as I'm in the US (Wisconsin) and it's cold outside on the Front Porch!

Channel 0   Temp 119   11.9   RH    43   Front Porch
Channel 1   Temp 677   67.7   RH    23   Living Room
Channel 2   Temp 656   65.6   RH    29   Plant Room
Channel 3   Temp 653   65.3   RH    24   Office
Channel 4   Temp 394   39.4   RH    0   Basement Fridge
Channel 5   Temp 29   2.9   RH    0   Basement Freezr
Channel 6   Temp 431   43.1   RH    0   Beer Fridge
Channel 7   Temp 654   65.4   RH    0   Pellet Stove


I'm going to eventually publish the data as MQTT sensors to be included into my home automation using Home Assistant. Your comments will be very welcome. I will be happy to share my code when I figure this piece out.
Greg

Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Feb 02, 2018, 10:50 am
Hi Greg,
I will be interested to see your code, however I can't help you with question.  I don't really understand what it is you are asking me. I have to aplogise, I would need a code snippet to localise my efforts.

I know with my UV sensor is seem to get random data that gets though the simple OS checksum process,  I now just filter out big jumps in data with that sensor.  Otherwise I was getting UV blips (single readings)of 3/4 daylight magnitude in the middle of the night?? So the OS checksum is pretty good, it is not perfect.

I followed Darko's advice on how to register negative temperatures, as I rarely get any below 0 centigrade readings here.  Your experience is not so pleasant.

Cheers, Rob
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: AnotherGingerlee on Feb 06, 2018, 07:12 pm
I thought that it was time to come back and give an update.
Thanks robwlakes for your encouragement.

I have 5 F007TH sensors which transmit to a 17.3cm length of wire connected to a cheap 433mhz receiver connected to pin 8 of an Arduino Nano running BaronVonSchnowzer code from post #33 which is connected by a usb cable to a Raspberry Pi. The Arduino and receiver are powered by the Pi Usb port. I have a Python program running on the Pi with a thread listening to the USB serial connection. It has been running flawlessly for over a month now.

I made a small tweak to the code to make it indicate that it was working.
It also guarantees the thread can always be exited in under 5 seconds ...

  while (noErrors && (nosBytes < maxBytes))
  {
    ledcount++;
    if (ledcount >= 2000)
    {
      ledcount = 0;
      ledval = 1 - ledval;
      digitalWrite(LED_BUILTIN, ledval);
      Serial.print("0,1,0\n");
    }
    while (digitalRead(RxPin) != tempBit)
    {

... every 4 seconds or so it toggles the onboard LED and reports a bogus reading for channel 0, which is discarded as there is no channel 0.

So my project is complete and working - the Pi uses the thermometers as thermostats for controlling a heating system.

Thanks! I hope this will help and encourage others.
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: robwlakes on Feb 07, 2018, 12:27 am
Congratulations....
Nice work folks,
Excellent application,
Rob
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: pandur on May 25, 2018, 02:02 pm
Very nice work, tank you!
Title: Re: Decoding RF signal from Ambient Weather Thermo-Hygrometer
Post by: mefi01 on Apr 07, 2019, 10:24 pm
Hey!

I'm in trouble with these chinese f007th transmitters.
I have 2 ones, ordered from ebay about ~8 USD.

This sketch won't works for me.
I want to implement the code for Pinchange interrupt.

The data receiving and manchester encoding works very well, but i'm stucked this point.
The problem is the data decoding.

The data allocation in the bytes doesn't match this format.
I have decoded the Channel data and that's all. Somebody could help me?


The first byte 0x45 is ok, the 2nd the random byte after reset, and the next is other than this sketch.
the channel number is in the 3rd byte 4. 5. 6. bits in reveresed direction!
I can't figure out the temp and humidity datas. Dare don't think about the checksum byte.

Here is the raw datas. First line HEX data , 2nd the temp and humidity, 3rd the binary data.
All measurement are CH1. I trim the strings to fit in 1 line in the forum.
Experienced that after battery reset i usually catch 6 bytes for the first time. The next byte number are usually 14.

45 E1 41 EC A9 A6 E0 FF 8A C2 83 D8 53 4D
23.1 41%
1000101 11100001 01000001 11101100 10101001 10100110 11100000 11111111 10001010 11000010

45 E1 41 1C A8 6B E0 FF 8A C2 83 38 50
23.2 43%
1000101 11100001 01000001 00011100 10101000 01101011 11100000 11111111 10001010 11000010

45 E1 41 9C 68 B4 E0 FF 8A C2 83 38
23.2 43%
1000101 11100001 01000001 10011100 01101000 10110100 11100000 11111111 10001010 11000010 10000011 00111000

45 C5 40 62 68 6D E1 FF 8A 8A 81 C4 D0 DA
24.7 45%
1000101 11000101 01000000 01100010 01101000 01101101 11100001 11111111 10001010 10001010

45 C5 40 B2 B5 D3 E0 FF 8A 8A 81
25.5 91%
1000101 11000101 01000000 10110010 10110101 11010011 11100000 11111111 10001010 10001010

25.3 45%
1000101 11000101 01000000 11010010 01101001 11001001 11100000 11111111 10001010 10001010
 
25.3 94%
1000101 11000101 01000000 00110010 11110100 10000000 11100001 11111111 10001010 10001010
   
25,3 95%
1000101 11000101 01000000 11010010 11110101 00010011 11100001 11111111 10001010 10001010

25,3 96%
1000101 11000101 01000000 11010010 00001101 10011000 11100000 11111111 10001010 10001010
           
25,4 93%
1000101 11000101 01000000 10110010 10001100 11010000 11100000 11111111 10001010 10001010