Skip to main content

Improvements to use the FT8 protocol on the Cortex-M base

Improvements to use the FT8 protocol on the Cortex-M base

Several experiments are underway to use FT8 on the Cortex-M base. The previous experiment can be seen in the link below.

1.Previous experiment
 1.1 Implement FT8 protocol to operate on Cortex-M base
 Refrence : (forked from kgoba/ft8_lib and modified)

  and gcc fortran compiler

 1.2 Adjust Sampling Frequency and FFT size to use FPU of MCU

 1.3 Previous experiment results
  The FT8 protocol should be completed decoding and ready for next transmission within 15 seconds. The encoding for FT8 transmission is very simple and time consuming, so Ignore it.
  For normal communication, it is still necessary to reduce the time by about 2 to 3 seconds.

2. Parallel processing using DMA and FPU for speed improvement
 The experimental conditions are the same as before.

 2.1 Structure for FT8 decoding
  Approximately eight steps are required to decode FT8 in Wsjt-X 2.0. I divided the time consuming part into four large parts.
Power Data (frequency domain data per time unit)

The FT8 requires 12.65sec of transmission time, but I added 900msec to account for the time error. (This time may change later)

After receiving the data for about 13.5 seconds, the FFT process is performed.
It is the longest part of decoding the FT8 signal. (3.5sec)

I adjusted the sampling rate and the FFT unit to use this part in the Cortex-M's built-in FPU. As a result, I reduced the time by about 2 seconds.

 2.2 Modified Structure for FT8 decoding

Power Data (frequency domain data per time unit)

I changed the structure so that I could process the FFT together while receiving the signal.

Receiving data is handled by DMA, while Main Core is processing FFT while DMA is receiving data. Note that the FFT processing must end within the DMA 1 cycle.
To understand Cortex-M's events, handlers, and pending times, I recommend the following book:

This method reduces most of the time required for FFT.

3. Hash callsign (Recent callsign)
 In Wsjt-x 2.0, a non-standard callsign was added to extend the FT8 protocol. This is the best way to add functionality without changing the length of the protocol.

non-standard callsign has 58bit Length
=> Dec 288230376151711743

Non-standard callsign can only use the following 38 characters.

38^11 = 238572050223552512
58bit can transmit up to 11 characters.

Below is the processing structure of Non standard Callsign added in Wsjt-x 2.0.

In this experiment, I added the above structure to make it compatible with Wsjt-x 2.0

4. Experiment
 The experimental conditions are the same as before.
I used one UART as the MCU's output device for debugging.

 4.1 Processing speed improvement test

Start Receive and FFT -> Calculate power
In the screen below, each time two "." Are output, the FFT operation is performed by parallel processing.

complete decoding

620ms + 887ms = 1507msec

Almost came close to the goal. But there is a problem.
The less the number of decoded messages, the longer it takes.
Up to 1 sec can be increased.
That is, the time to decode the message is variable. 800msec ~ 1500msec

 4.2 non standard callsign test
non standard protocol ('CQ OZ/LA6OP') is decode and displayed normally on the screen below.

'OZ / LA6OP' will be stored in the hash10, has12, and hash22 repositories respectively.

The stored hash code is being converted normally.
(IZ4... <OZ/LA6OP> >

Below is another example of a non standard call

Below is another example of a non standard call

Test Video for this article

5. Conclusion
Perhaps the next experiment may be delayed.
My main project (for business) has started and I am going to be very busy with this semester class lecture.
My seasonal courses are matlab related classes. Maybe I could use this project for my class.
Whenever it is time, I will worry for improvement.

Thanks for reading.


Post a Comment

Popular posts from this blog

uBITX with Nextion LCD (CEC Firmware) - Installation and Introduction

uBITX with Nextion LCD (CEC Firmware) - Installation and Introduction uBITX CEC Firmware supports various LCD since Version 1.08 (16x02 Parallel, 20x04 Parallel, 16x02  I2C, 20x04 I2C, 16x02 Dual LCD with I2C).
Supports Nextion LCD (Graphic LCD) from Version 1.09, Version 1.09x is primarily aimed at Nextion LCD support. Also 1.09x will continue to be Beta version. If you want a stable version, please use 1.08 or 1.1 version to be released in the future.

uBITX Firmware CEC Version 1.1 Release

uBITX Firmware CEC Version 1.1 Release
Version 1.1 is the first major release since 1.097, I will release it after a 50-day beta test.

Version 1.1 includes all additions or improvements from 1.08 to 1.09, 1.093, 1.095, 1.097 

How to upgrade uBITX Firmware

uBITX is based on Arduino Nano. So uBITX's firmware upgrade method is the same as Arduino.
There are two ways to upgrade the firmware of uBITX.

The first is to compile the source from the Arduino IDE, and the second is to upload the compiled hex file using the Firmware Upgrade Tool.

I'll show you how to upload a compiled hex file as a second method.

1.Connect the uBITX's USB cable to the computer.

2.Run Device Manager on your computer.
  The way to open the Device Manager for each OS Version differs slightly.
  In most Windows, you can easily launch the Device Manager by running.

  On your computer, press the Windows key + R.

 Type devmgmt.msc and press OK Button.

On most operating systems, there will be a serial port named Ports with CH340. If so, the next step is skipped.

If the serial port is not installed as below, you need to install the driver.

Included in uBITX is the Adonano, which uses the CH340 USB To UART part.

Download the latest CH340 driver from the Internet.