YAESA

Yet Another Environment Sensor Aggregator<br>

Remote wireless temperature sensors and remote wireless weather station with temperature/humidity/rain/wind sensors.<br> Local sensor with temperature/humidity/pressure and another local'ish sensor with a temperature sensor at the end of a long wire.

Updates 2022/03/10 - <br>

• The base station that came supplied with the F007T sensors can display up to 8 remote sensors and there are currently only 5.
• Added a 433Mhz OOK transmiter to relay the 868MHz WH1080 and the one-wire DS18B20 temperatures and transmit as imitation F007T messages on the 433MHz band.
• These additional 2 readings are seen by the supplied base station as the 6th and 7th.
• The manchester encoding is implemented using PIO.
• The 433MHz OOK receiver 2 cm away from the transmitter simultaneously receives its own transmitted messages too but ignores them.

Updates 2022/03/01 - <br>

• Currently, at initialisation, the bme680's chip id is checked and the sampling rates and run mode are initialised.
• The chip id is also checked before every sensor read.
• Added a check that the sampling rates and run mode are as expected before every read.

Updates 2021/09/09 - <br>

• for WH1080 and F007T messages, if both queues have messages available to send, choose the oldest first by comparing the timestamps from when the messages were originally queued
• add incrementing sequence number to messages sent - for primative sanity of the receiver
• try to fix .pio's with end of lines that keep reverting to windows CR/LF - the pio assembler is not currently EOL agnostic
• tidy up repeating code patterns used for output formatting

Updates 2021/09/01 - <br> some cmakec flexibility

• If PROJ_BOARD_STDIO_UART environment variable is defined then use UART 0 for stdio <br> Based on PICO_BOARD, if tiny2040 then tx is 28 and rx 29 otherwise 21 and 22 <br> With no USB for stdio being used the default alarm pool is disabled
• If PROJ_BOARD_COPY_TO_RAM environment variable is defined then set PICO_COPY_TO_RAM variable to 1
• Treat setting the flash size indepentently from the board being used
• If PROJ_BOARD_FLASH_SIZE environment variable is set then copy and sed modify the appropriate linker script
• BE AWARE - if build type was specified with variable PICO_NO_FLASH then the flash size isn't changed! <br> Assumed are the location/names of the linker scripts and a sed pattern match that also expects to find the pico default 2048k <br> The linker script customisation is placed in the build directory so the hard coded file memmap_flash_8mb.ld is redundant/deleted <br>
• With some of the above changes, the code size including SDK can reduce from just under 50K to under 22K

Updates 2021/08/27 - <br>

• replaced repeating_timer calls with simple'ish 1 ms tick scheduler (sched_ms.c and h) that triggers callbacks running on each core
• the Tiny2040 board has 8 MB flash but by default the linker allocates only 2 MB. As an experiment, if environment variable PICO_BOARD is set for the tiny2040, then a custom linker script is added to set it to 8. I'm not sure if this is the correct way but in any case the current total code size including SDK is less than 50 KB so perhaps even 2 MB is generous. I guess the larger flash sizes better suit applications that create a file system e.g. python environment

Updates 2021/08/22 - <br>

• Builds for Pimoroni's Tiny 2040 boards (and hopefuly still for pico)
• Having gone to that expense (for less pins !), added some PWM LED control (led_control.c and h)
• To evaluate the PWM LEDs at runtime, added override with control received from the uart.
• Added non-blocking stdin to do just the same as the uart receiver (renaming source files uart_io.c and h to serial_io)
• Also added a minimum sanity check before every read of the BME280 sensor data to check the device 'id' is valid and so the sensor data is also possibly readable.

Using RP2040 and PIOs - <br>

• Two PIO state machines to detect bit pulse streams from the raw incoming data provided by two RF AM receivers, both with OOK modulation but one Manchester encoded and the other PWM encoded. Receiving data from
  • five remote F007T temperature sensors transmiting at 433 MHz
  • one remote WH1080 weather station transmiting temperature, humidity, rain, wind data and date/time at 868 MHz.
• One PIO state machine to provide a simple very blocking implementation of the one-wire protocol to a parasiticaly powered DS18B20 on a long'ish wire (only had 8.5 m available).
• Also a local BME280 with temperature, humidity and pressure currently using a version of the Raspberry PI (Trading) Ltd.'s BME280 SPI example code.

Why do it?

I had a fridge that kept freezing vegetables. It was interesting to see how bad the overshoot and undershoot of the controller was. <br> And why not monitor the freezer too. It had a much tighter controller. <br> The attic was getting extra loft insulation and I wondered how cold the water tank in the attic now got. It's only gone as low as zero so far. <br> There is also a water softener in the garage that didn't want to get too cold. <br> <br> So I got 5 Ambient Weather F007T sensors with base station. The base station was rubbish, invariably displaying 'HH', impossible temperatures and push button switches from the 1960's. <br> Now two of the five F007T sensors regularly fail - one likes to send a negative version of the temperature, the other likes 111.7 C a lot (a suspiciously raw temperature value of 0xAAA). Fortunately its fairly easy to create replacement ones using cheap 8 bit micros, DS18B20s and 433 MHz transmitters. <br> <br> Then my youngest son inherited a Fine Offset WH1080 weather station from his grandfather ...

Overview

Remote Sensors

F007T

• The particular F007T temperature sensors being used transmit 433 MHz OOK Manchester encoded messages. Example sensors are Oregon Scientific WMR86, Ambient Weather F007 and Froggit FT007. No doubt all are manufactured in China and just re-badged. Be aware that the encoding method may change between different versions of sensors.
• For this F007T, the RF receiver can be any one that does 433 MHz OOK e.g. RF Solutions AMRX9-433P or RadioControlli RCRX-434-L The message protocol is a bit limiting for the sophisticated receivers like HopeRF RFM65.
• There are also decodes for SDR. e.g. ambient_weather.c at https://github.com/merbanan/rtl_433
• Its been done on Arduino’s - Rob Ward (and the people he credits), https://github.com/robwlakes/ArduinoWeatherOS using a decoding delay algorithm. Ron Lewis, https://eclecticmusingsofachaoticmind.wordpress.com/2015/01/21/home-automationtemperature-sensors/ for the checksum algorithm?

WH1080

• The WH1080 weather station being used transmits 868 MHz OOK PWM encoded messages. Again probably re-badged and the encoding method may change between different versions of sensors.
• Simple RF OOK receivers that are low voltage are harder to come by - RadioControlli do the RCRX-868-L.
• Again there are SDR. decodes given at https://github.com/merbanan/rtl_433 by Benjamin Larsson et al.
• The sensors on this weather station have outdoor temperature and humidity, rain and wind speed and direction. It also reports date/time information a couple of times over a day - received from Mainflingen near Frankfurt in Germany.

Both RF AM receivers with automatic gain control generate spurious data between real messages but the PIO algorithms are not very defensive.<br> The WH1080 and F007T both have checksums for message integrity checking but these aren’t strong enough for all types of noise.<br> Both WH1080 and F007T repeat the message more than once in some transmissions and so if the checksum passes then the message can be compared to the previous one. If two consecutive messages pass the checksum and the messages are identical then the message could be accepted as good.<br> The WH1080 PWM OOK with 10 byte message and 8 bit CRC appears to be particularly susceptible with a lot of ‘1’s in the noise.

Code

• yaesa_rp2040.c
  • has the CPU core 0 main entry point that calls the WH1080 and F007T scheduler and PIO initialisations and also has the core 1 entry point to handle the BME280 connected by SPI, the DS18B20 one-wire protocol and the 2nd UART to output the data that's been received.
  • on core 0 the "main" loop does nothing. Its the scheduler callbacks that empty the PIO FIFOs and that "parse" the bit streams looking for recognisable messages, adding them to the message queues.
  • on core 1 the liesurely "main" loop periodically polls the meassage queues being populated by core 0 and formats them.
  • core 1 also liesurely polls the BME280 and DS18B20 sensors.
  • core 1 sends all the decoded data out on the UART.
• f007t_manchwithdelay.pio in 9 instructions and
• wh1080_pwmpulsebits.pio in 16 instructions
  • have state machine programs feeding their FIFOs with data bits for the F007T and WH1080 decoders respectively.
  • they provide limited detection for valid data bits being received.
  • the FIFOs are configured as 32 bits wide and would block on messages that aren't multiples of 32 bits. However the RF AM receivers with automatic gain control generate noise pulses between "good" messages. These spurious bits push the real bits through the FIFOs fairly quickly.
• wh1080_decode_bits.c and
• f007t_decode_bits.c
  • scheduled callbacks on core 0 empty the PIO FIFOs and stores the resulting bit stream to bit queues i.e. extending the queue depth from the FIFO limitation.
  • scheduled callbacks on core 0 read from the bit queues, "parse" the data bits looking for their respective messages and queue the results to message queues.
  • on core 0 the scheduled callbacks for the message and bit