Group Actions
Engagement
  • Author Author: JWx
  • Date Created: Date Created
  • Views 1441 views
  • Likes 9 likes
  • Comments 2 comments
Related
Recommended

Radio controlled clock/weather station using second-hand Oregon outdoor sensor

JWx
Radio controlled clock/weather station using second-hand Oregon outdoor sensor

A sensor

During preparation for my ADALM Pluto road test I have obtained set of second hand outdoor weather sensors which were cheaply sold as incompatible with seller's weather station. Half of them were readily decoded using rtl_433 software, the rest (pair of identical La Crosse sensors) were probably too old and using different protocol than more modern parts with the same marking.

One of working sensors was particularly interesting - marked not only as temperature and humidity sensor, but also a RF clock receiver. Assuming RF clock to be DCF77 signal (long wave reference clock signal, broadcasted at 77.5kHz frequency, commonly used for synchronizing wall clocks) this would be really useful - considering that DCF signal propagates mainly in straight lines and in my location it is rather weak, possibility of putting receiver in some convenient place and then transmitting received timestamps to  base station using 443MHz frequency band would be really interesting.

This sensor looks like this:

{gallery}Oregon sensor

sensor front

Sensor's front

sensors back

Part number

works in 433MHz ISM band and is powered by one AA battery.

Protocol and software

Oregon Scientific sensor communication protocol was researched by many developers, resulting not only with different implementations of decoders, but also documentation resulting from reverse-engineering. Main focus was given for temperature and humidity decoding - for example:

https://www.osengr.org/WxShield/Downloads/OregonScientific-RF-Protocols-II.pdf

doesn't even mention frames carrying datetime payload. The same situation happens with software decoders - I have encountered implementations trying to parse time frames as temperature ones, returning strange values in the result.

RTL_433 Gnu/Linux software has a decoder that correctly processes both types of frames, but it needs a Linux host and supports only more advanced radio modules, beginning with RTL-SDR dongle. Although rtl_433 was recently ported to ESP family SoC, I have decided to look for something simpler.

Arduino Oregon library runs on standard Atmega based Arduinos and interfaces with cheap OOK radio receivers so it looked promising, but failed to properly decode datetime frames, so I had to look for alternative. Fortunately, there is an improved version of it, this time correctly decoding both frame types. Sample of data decoded from sensor is presented below:

3CCC
 id: 181
 channel: 1
 temperature: 25.70
 humidity: 43
 bat: 0 ok
3CCC
 id: 181
 channel: 1
 temperature: 25.70
 humidity: 43
 bat: 0 ok
3CCB
 id: 181
 channel: 1
 temperature: 25.70
 humidity: 43
 bat: 0 ok
3CCB
 id: 181
 channel: 1
 temperature: 25.70
 humidity: 43
 bat: 0 ok
3CCA
 id: 181
 channel: 1
 temperature: 25.70

[...]

3EC8
 id: 181
 channel: 1
 valid clock: 2
 date: 2023/09/15
 time: 14:16:22
local time updated from RF clock
RTC updated from RF clock

[...]

every frame (transmitted at interval of about minute) is transmitted two times and differentiated with rolling code (in this example: 3CCA, 3CCB, 3CCC).

Receiver module

First attempts were made using XY-MK-5V receiver from the set similar to the presented below:

XY-MK-5V

but the results were poor - reception distance was several centimeters without antenna and when antenna was added signal was unstable (sometimes reception was good then stopped without any apparent reason) - probably because of limited selectivity of this receiver it was overdriven by strong signals from different bands.

Eventually it was replaced with - pin compatible - AK-119S module, looking like this:

ak119s

that has resolved reception range problem.

Station construction

Base station was designed around 4 digit 7-segment TM1637 display module. Paired with Arduino Nano clone, DS1302 RTC module for preserving time information through restarts and radio receiver module it made a completer radio controlled clock with weather data readout. It is connected as below:

schematics

RTC module has one modification - instead of CR2032 battery, 1F/5V supercapacitor was installed. It was done for supercap performance evaluation and standard module can be used instead - in this case, following lines should be commented out in source code:

  RTC.writeEN(1);
  RTC.writeRTC(DS1302_TRICKLE, 0xa5);
  RTC.writeEN(0);

This section enables supercapacitor charging circuit inside of DS1302, which is not needed (and can be dangerous to the battery) when standard module is used.

During runtime, Arduino constantly tries to decode radio datastream for potential information from weather module. When valid datetime frame is received (that can be not very often, because of RF clock reception problems), local clock is updated with this information.

Additionally -  every second - new display data is sent to the display module. It is usually current hour and minute, with colon mark switching every second. When weather information is considered "fresh" - that means, transmitted within last 10 minutes, display cycles between displaying time, external temperature and humidity (3 seconds each).

Below there is a proof of work for running wireless weather station, cycling between time, temperature and humidity read from the sensor

and source code is included in the following archive:

3364.sub1Ghz_weather.zip