Receive FT8 with WSJT-X and RTL-SDR (Windows)

FT8 has become the most popular data mode for ham radio. It is a digital mode created by Joe Taylor, K1JT and Steve Franke, K9AN which uses 8-FSK modulation. A transmission lasts for exactly 12.64 seconds and occupies about 50 Hz bandwidth (8 tones at 6.25 Hz spacing). FT8 works very well even with a lot of noise and it is simple to receive and transmit using the computer soundcard and SSB transceiver.

This post will focus on receiving only. We'll decode FT8 messages using Realtek RTL2832U hardware with software defined radio (SDR) application. However, SDR tools come with support for common analog modulation. For FT8 decoding and generation there is WSJT-X software, but this one accepts only audio input. So, I'll be using a SDR application (SDR# on Windows, Gqrx on Linux) set to SSB (upper side band) demodulation and I will pipe its audio output to WSJT-X. The latter can be configured to automatically set the frequency of the SDR software. Besides configuration, a virtual audio cable is needed, as well as virtual serial ports (on Windows only).

Old Prolific USB-Serial cable as programmer for Arduino

I got a 3.3 V Atmega328p development board for a project. Since the board will be plugged into a PCB, I choose the Arduino Pro Mini compatible design, which is just the MCU with a few external parts that are required for proper functionality. There is no USB to serial TTL converter chip. This means that in order to program this board, I needed such a converter.

And I realized I didn't have a suitable one just when the development board arrived. All I own were CH340G with Tx and Rx lines only and the CH341A programmer locked to 5 V levels. The price of such a converter is not a problem, but having to wait for a month or so to be delivered is a problem. I remembered I had some old USB phone cables with included USB-RS232 converter so I decided to make my own adapter to program the 3.3 V Pro Mini board.

PL2303 Serial Adapter for Arduino Pro Mini

Battery charging circuit of DS3231 module

I'm working on a project which requires an RTC clock. So I decided to get a module, since my project is based on a development board with ATmega328. The cheapest and most available module is a small PCB with "ZS-042" printed on it. Besides DS3231 realtime clock IC, it also includes an I²C EEPROM (24C32). Both share the same bus lines. The module is shipped without a battery. Product description (on AliExpress) mentions only LIR2032 battery and 5V supply for the module. They even say that it does not ship with the battery and that's not a big deal since it costs only "0.01 dollars". Really?!

The reason I chose DS3231 is because I need 3.3 V compatibility. I'll be using other peripherals which support 3.3 V only and ATmega328 will run at 8 MHz. RTC datasheet confirms DS3231 is 3.3 V (and 5 V) compatible. But the module specifications say you should use 5 V. I began wondering if there is something else that made sellers say this. In this post I will answer two questions: can ZS-042 operate at 3.3 V and what type of battery should you use (CR2032 or LIR2032).

ZS-042 DS3231 Module

Versatile LM317 power supply project

An adjustable power supply is mandatory lab equipment for those who regularly deal with electronics circuits. One of the most popular integrated circuit for linear power supplies is LM317. There are countless power supply projects using LM317. This one has some additional features. The usual output voltage of LM317 cannot be lower than 1.25 V. However this circuit uses an additional negative power supply derived from the same transformer winding. With this, you can pull output voltage down to 0 V. The PCB also contains an additional power supply, with fixed regulator. Its purpose is to supply power to a custom made panel voltage and current meter. But you can use it to power a cooling fan if you want.

LM317 Power supply built PCB

Configure Mosquitto™ broker with TLS certificate

Following my previous post, you should have now a running Mosquitto based MQTT broker on your OpenWrt router that listens on port 1883 for unsecured clients and on port 8884 for TLS PSK clients. But that's not all. I want to have the broker listen to 8883 port for TLS certificate secured clients. I will use this port for remote clients over the internet.

Of course, the port can be used for local clients that support TLS. This is the highest level of transport encryption available. It's the same encryption used by HTTPS. When you (your browser) send a HTTPS request to a server (website), the server responds with its certificate and public key. The browser has a database of trusted certificate authorities and if the authority that issued the received certificate is in that database, browser will trust the server and will respond with data encrypted with the public key. Server decrypts data with its private key. Client and server will negotiate a one time key that will be used throughout the session.

Install and configure Mosquitto™ on OpenWrt

The previous post was about MQTT security layers, the advantages of running a local MQTT server and how may a network of things be structured. The OpenWrt router should be ready to install and set up the server (broker) software. The software repositories contain two variants of the Eclipse Mosquitto software. One of them is built without SSL support. If you install that one, you won't be able to accept secure clients. The SSL enabled variant requires a bit more internal storage space and that's the main reason they provide both builds.

I'm using a router with Broadcom SoC and 16 MB of internal storage. There's still 86 percent free space after installing Mosquitto, the SSL enabled build. In this post I'll show you how to configure Mosquitto broker to listen to multiple ports and to accept clients with different security settings. This is because not all microcontrollers with network connectivity have enough processing power for TLS/SSL. And, as I said in the previous post, the devices in your local network are behind (at least one) firewall, and as long as no one else has physical access to the network, transport encryption between MQTT clients and server is not really needed. However, TLS/SSL is required for remote clients, over internet.