Instrumenting the Repeater

From Stu2
Jump to navigation Jump to search
Grafana graph in dashboard

Summary 2020

This page explains how we developed and installed a system to sense, track and display key operating parameters of the Woodbridge Wireless repeater hut. The system measures transmit output power, temperatures and battery backup voltages. Measurements are stored in a database and displayed using a web browser.

There are two types of displays; real time and trends. The real time display (Repeater Graphs) shows transmit output power and current temperatures in near real time. When somebody keys up the repeater, you'll see the power output gauge indicate forward and reverse power in near real time. The trend graphs show the history of all the data we are collecting. The real time information will be available to club members and the trend graphs will be made available on a case by case basis.

As a result, we already discovered a couple things we didn't know.

  • The TX output power drops over time as the repeater is used. It's temperature dependent. We added a fan which helped lower the temp and stabilize the power output.
  • The inside temperature gets a lot hotter than expected - reaching 90+ degrees. WA0DYJ added an exhaust fan and intake. W7IY built a control system for the AC.
  • The APRS transmitter stays very busy. The TX overheats and power drops. So the output power was set to medium instead of high.
  • Using a web browser to control the AC and Heat was very inconvenient. W7IY and WA0DYJ added physical buttons to interface with the control program. Now you can turn on the AC or Heat by pressing a button.

I'm sure there are more things to instrument. For example, it would be fun to interface with the RX S-Meter and display the reading in real time. This might help troubleshoot intermittent problems.

The rest of this document provides more details about the system. We use components from past projects - almost like we know the Internet would come some day! So make sure you check out those links for the technical details.


System Description

The system is built from several specialized components, connected together with standard, open source software applications. Links to the custom sensors are provided below. (Battery Monitoring System and Power Meters) This wiki provides detailed and technical information, which isn't repeated here.

Power Meter Trend Graphs


Several years ago, we designed and built a custom battery monitoring system to monitored individual cell voltages in several banks of batteries. The batteries provide back up power to the repeater, if the commercial power is lost. The batteries provide enough time to bring in a portable generator.

Measuring the individual cell voltage is tricky. Ground isn't ground. After searching the Internet, we found an interesting idea that used the linear region of a photocoupler to solve this exact problem. A photocoupler provides isolation and an A to D converter can measure the output voltage. In version 1, the voltage values were stored on a SD card and fed Round Robin Database graphs. However, multiple writes to the SD card eventually crashed the system and the graphs weren't remotely accessible. So we couldn't set any alarms, etc. In version 2, the Perl code was replaced with Java and we used the emerging IoT architecture based on MQTT messaging. Now, we can use Grafana to plot the trends and issue alerts.


Temperature Gauge

What would a IoT system be without temperature sensors and relays? The battery monitoring project uses Dallas 1-Wire sensors. The Java code on the BeagleBone ships the temps to the MQTT broker, just like the other sensors. We also have a 8 relay board manufactured by Denkovi. Analog sensors are attached to the transmit amplifiers, placed inside the hut and outside the hut. Values are read via SNMP once per minute and sent to the MQTT broker. A Node-Red flow listens for the MQTT messages and displays the values in real time on a Node-Red gauge.

The relays provide the ability to turn things on and off. (e.g. the Air Conditioner) They are controlled via SNMP, too.

Power Meters

Power Meter - Inside

Battery voltages are interesting, but they don't (or shouldn't) vary much. We decided to look at the transmitter output power, reflect power and SWR for each of the repeater's systems. (2M, 222, 450 and 2M APRS). We procured several Bird sampling strips from the Dayton Hamfest and build a power monitoring system using odd, practically (and cheap) Bird slugs. Each sampling strip has a place for two slugs; one for forward power and one for reverse power. Using an A to D converter in a ESP-32, we sample the voltage provided by the slugs and ship the values over WiFi to a MQTT broker. Using the same IoT architecture, we can plot the power values over time.

Real Time Graphs

Real time power meters

Grafana provides trend graphs over time. We wanted real time meters. So we used the same MQTT data to drive Node Red gauges. Node Red is a popular visual programming environment. Developers drag 'nodes' to the canvas and connect them together to create a flow. Each node is highly specialized. The code is 'deployed' to the target and the program starts running.


Of course, keeping all these applications properly configured and updated could be tedious. To address that problem, we used docker and docker-compose to manage containers to create a 'service'. A container has a minimal operating system and a single application. (Or applications to perform a single function.) For example, node red runs in a container. Docker-compose uses a single configuration file to configure all the docker containers to create a service. So in this project, we used containers for grafana, node red, influxdb, telegraf and mosquitto.

IoT Architecture

System Architecture

Our IoT architecture uses mainstream IoT concepts. In general, data are gathered by a sensor and transmitted to a MQTT broker for redistribution to a data store. (MQ Telemetry Transport) A graphing package (Grafana) pulls data from the time series data store and displays the trend graphs in web browser. Each component in the architecture uses standard Internet Protocol (IP) based communications. This means, the components can be separated (by inches or hundreds of miles) and specialized to their individual tasks. It also means each component can be designed to a known standard.

nginx is used as the web front end. A docker container with both nginx and letsencrypt provides a TLS proxy, which limits exposure of unnecessary ports and creates an encrypted path between the system and your browser. Certs signed with letsencrypt will be trusted by the browser because their root certificate authority is already installed in all the different browsers.

The system uses the following components:

  • Mosquitto MQTT Broker for messaging
  • InfluxDB time series database for storage
  • Grafana graphing system for plot trends and exploring the data
  • Node-Red visual program environment
  • telegraf moves data from the broker to the database
  • nginx proxy to help with security
  • letsencrypt for the TLS certs
  • Sensors:
    • Custom Battery Monitoring System
    • Denkovi relay board
    • Custom Power Meter


This project was built using several different types of software.

  • Eclipse - Java IDE
  • github - code repository
  • Visual Studio Code - IDE for developing ESP-32 code
  • PlatformIO - used to build and remotely flash firmware (very cool!)
  • Node-RED - visual programming language.

Here is an example of a node-RED flow.The flow connects to the MQTT broker and subscribes to a topic. When a message arrives, the payload is unpacked and the temperature gauges are updated. Click on the picture to get a larger image.

Example Node-RED flow.