Go Down

Topic: Decoding RF signal from Ambient Weather Thermo-Hygrometer (Read 60707 times) previous topic - next topic

robwlakes

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


Learning Flute and C++, heading for a meltdown.

AnotherGingerlee

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.

robwlakes

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


Learning Flute and C++, heading for a meltdown.

gliebig

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

robwlakes

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
Learning Flute and C++, heading for a meltdown.

gliebig

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


robwlakes

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
Learning Flute and C++, heading for a meltdown.

AnotherGingerlee

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.

robwlakes

Congratulations....
Nice work folks,
Excellent application,
Rob
Learning Flute and C++, heading for a meltdown.

pandur


mefi01

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
 



Go Up