MFSK16

Technical Specification

Rev 1.2       11 July 2000
© Murray Greenman ZL1BPU

Tidied up and reformatted 15 Oct 2009 (with no technical changes)

Specification Menu

 A. Objectives
 B. Description of Modes
 C. Transmission Technique
 D. The Receiver
 E. Other Requirements
 F. Documentation

Purpose of Specification

To describe and specify an Amateur Radio MFSK mode for HF DX, nets and rag-chewing. To describe functions of software providing this MFSK mode. The mode offers modest typing speed for HF (especially long path) and MF / low HF, and convolutional coding for minimizing errors.

Each numbered paragraph in this specification is open to comment and revision by consensus for later releases. Please circulate your comments to all interested parties, via the MFSK mailing list. Your comments will be distilled into future enhancements of the specification.

'Comments' and 'Suggestions' which follow the specification paragraph are editorial notes and do not form part of the specification.

A. Objectives

A.1. Use
An easy to use Amateur chat mode for real-time QSOs, nets and broadcast of bulletins, but not intended for contesting or BBS use. A half-duplex non-ARQ forward error corrected mode.

A.2. Slick Operation
The default mode offers comfortable typing speed and quick manual half-duplex end of over turn-around, for reasonably slick operation. Turn-around time will not exceed five seconds using the default mode.

Comment:
Slick operation requires both low latency (the time for data to trickle through the system), and low turn around time (the time to end an over plus the time to start a transmission and have synchronism acquired at the other end). Obviously the typing speed is dependent on mode and FEC settings, and the turn-around time will scale with baud rate changes and increase with addition of FEC.

Very slick operation (as required for RTTY and CW contests) is not considered to be a goal of this mode. Latency is not an issue at all for beacon and bulletin broadcast use.

A.3. DX Performance
Very good performance for long-haul DX, such as long path 20 metres. The software will be robust in fading conditions, and in moderate QRM such as is prevalent in Europe. The software will be robust in lightning and man-made burst noise such as is common on 80 metres.

A.4. Ease of Use
Operator ease of installation and use is considered to be very important. No special equipment will be required to set up a station to operate this mode.

A.5. LF and Super-DX
Paragraph deleted in this release. (Now taken over by DominoEX and THOR) A low speed option would provide good performance for LF or VHF weak signal use where superior signal path stability can be assured.

B. Description of Modes

B.1. Choice of Modes
The choice of useful modes offered by the software is limited. Other modes offered will be sufficiently different in nature and application to be obvious to the non-technical user (for example PSK31 is a suitable alternative). for a release product must be limited, to avoid operator confusion as to their use, and also difficulty in deciding which mode is being received. The final choice will be of modes easily discriminated by sound (baud rate for example) and by bandwidth, easily discernable on a waterfall display.

The default mode will be 16-FSK, 16 tone 15.625 baud with FEC ON, Interleaver ON. The FEC will be R=1/2 K=7, L=10, using the NASA algorithms. (CCIR definition 316HF1B)

Comment:
Nino proposes different baud rates for each mode chosen, as this allows auto baud rate selection, and therefore auto mode selection. This would imply only one choice from each of the groups in the table in section B.2. Final choice of modes will be made once tests have ascertained which modes (very limited number) provide the best mix of performance.

B.2. Mode Options
Paragraph deleted in this release. The modes will selected once testing (both on-air and using ionospheric simulation) has clearly indicated the best few modes. The choices will be from the following:
MFSK
NAME
MFSK
Modee
Symbol
Rate
Bandwidth
Hz
Data Rate
bps
Approx Spd
Non-FEC
Approx Spd
FEC
8FSK8 8FSK 8 baud 96 Hz 23.44 25 WPM -----
16FSK8 16FSK 8 baud 192 Hz 31.25 30 WPM 15 WPM
32FSK8 32FSK 8 baud 384 Hz 39.07 37.5 WPM -----
8FSK16 8FSK 16 baud 192 Hz 46.88 50 WPM -----
16FSK16 16FSK 16 baud 384 Hz 62.50 ----- 30 WPM
32FSK16 32FSK 16 baud 768 Hz 78.13 75 WPM -----
8FSK4 8FSK 4 baud 48 Hz 11.72 10 WPM -----
16FSK4 16FSK 4 baud 96 Hz 15.63 15 WPM 7.5 WPM

Comment:
The first six modes are to be assessed for the normal HF mode, the last two are for LF or VHF use. The user documentation and the design of the software should discourage the use of the widest modes, and should also discourage changing to a wider mode during an established QSO, which is considered by some to be poor operating procedure.

The suggested LF/VHF modes place extreme stability and tuning requirements on the equipment. FEC is not recommended at the slower speeds as latency of decoder and interleaver become excessive.

In deference to the average Joe Ham, many potential options are omitted. Even-tone non-FEC modes have been omitted. The LF/VHF modes should be hidden completely via a setup option. Then Joe Ham will have fewer settings to choose from.

B.2. Mode Names
The default mode will be known as MFSK16. During testing these modes will be known as, and referred to in the software and documentation as, 18FSK16, 16FSK16, 8FSK16 etc, where the first number is the number of tones and the second number the (rounded up) baud rate. An "F" suffix is used to imply FEC=ON. These names are given in the above table.

Unique descriptive names may be given to the modes ultimately selected for general use.

B.3. Mode Selection
The user software will automatically select number of tones, baud rate, FEC and interleaver regimes from a single menu selection, invisible to the user. The user will not be able to change any of these parameters, nor will they be shown what the settings are. See paragraph B.1.

Different modes with clearly different performance will only provided from a limited list which descriptively names the modes.

Comment:
The purpose is to ensure that the average user cannot easily end up with the wrong selection.

For expert users, extra menus (normally hidden) could offer changes of numbers of tones and baud rate for experimental purposes.

C. Transmission Technique

C.1. MFSK Technique
The transmission will be based on 16-FSK (sequential single tone FSK), with continuous phase (CPSK) tones. There will be no delay between tones, and no shaping of the tones.

Comment:
This implies a sin(x)/x transmission with sidelobes. Expert advice is that filtering these sidelobes will (a) require a linear transmitter, (b) will only reintroduce the sidelobes and additional in-band intermod if the transmitter is not linear, and (c) would result in a transmission not well matched to the receiver. The solution is in line with the KISS principle, but we will therefore need to consider the width of each selected mode carefully.

Tests have shown this to be a reasonable assumption. The signal sounds pleasing and is not aggressive and is reasonably sharp to tune across.

C.2. Performance Options
Paragraph deleted in this release. Different performance options will be offered at different bandwidths (numbers of tones) and baud rates, rather than different tone spacing. This is to enable the various options to be differentiated easily by sound and bandwidth.

C.3. Default Mode
Paragraph deleted in this release. The default mode will be the most reliable option under most conditions in both normal and LF/VHF cases. No mode wider than baud rate x number of tones = 1 kHz will be offered. Final choice of modes offered is still to be made.

C.4. Transmission Bandwidth
Transmission bandwidth will be less than the number of tones x tone spacing x 2 at the -30dB point relative to a single carrier when properly adjusted. The transmitter does not need to be linear.

Comment:
This is outside the second sidelobe, so should be easily achievable. The CCIR requirement is for less than 0.005% of the total power to be outside the necessary bandwidth, which is 316 Hz for the default mode 16FSK16. See FCC Part 47, paragraph 2.202.

C.5. Symbol Rate and Tone Spacing
The system will use a tones spacing numerically equal to the baud rate. Each symbol will consist of a single square keyed pulse with the same start and finish phase as all others, and concatenated with others. No single or isolated pulses, or gaps between pulses will be emitted.

Comment:
If tone spacing = baud rate, i.e. spacing = 1/T, orthogonal reception with non-coherent demodulation is assured. Tests to assess the doppler crosstalk and multi-path timing margins are required to confirm the practicality of this stipulation. In practical tests it looks good so far.

C.6. Symbol Rates Offered
Paragraph deleted in this release. Only one symbol rate (15.625 baud) is offered. The system is to offer a minimum of symbol baud rates for LF or other weak signal use. The purpose of this stipulation is so that the different rates can be easily determined by ear.

Suggestion:
Exact baud rates suggested will be 25, 15.625 baud, 7.8125 and 3.90625 baud, for PC sound card sampling rate compatability, but when referred to in menus and documentation should be rounded up to "16 baud", "8 baud" and "4 baud" respectively.

Comment:
As suggested in C.2. and this paragraph, the baud rate and number of tones in use will be obvious from the nature of the signal. FEC selection is similarly fixed to specific modes. The fewer the modes offered, the lesser the identification problem will be. Nino's opinion on speeds offers differs at present. Final speeds and modes (other than the default 16FSK16F) to be determined.

C.7. Range of Tones
Transmission tones (and receiver tuning) should be adjustable to suit different transceiver IF filters. Low (~1kHz) and high (~2 kHz) alternatives to be accommodated without change of actual tone spacing.

C.8. Bit Stream Orientation
At the lowest level, i.e. the single symbol, the system will be a bit stream oriented transmission, allowing convolutional code FEC, Varicode and binary transfer options to be used at a higher level when specified.

Comment:
This approach allows maximum flexibility, for example it would also allow data block transmission over sequential tones, such as is used in Piccolo, with two sequential tones per character.

C.9. FEC Coding
Full-time FEC coding with interleaver will be used with this mode. FEC will be sequential R=1/2, K=7, using NASA algorithms. See attached document.

The interleaver will be self-synchronising, based on 10 concatenated 4 x 4 bit IZ8BLY diagonal interleavers (i.e. L=10) as described in the attached document. No independent FEC coding options will be offered. Modes will be selected with fixed FEC (either ON or OFF, and with interleaver if ON). The actual FEC regime will not be divulged to the user in the menu (only in the documentation). The suggested choices are:

  1. No FEC;
  2. R=1/2, K=7, using NASA algorithms.
  3. R=1/2, K=9

The coder will employ a simple interleaver to reduce burst error damage. Interleaver algorithm to be determined from tests .

Comment:
Source code for optimised R=1/2, K=7 Viterbi decoder is available from KA9Q.

C.10. Alphabet Coding
The default alphabet coding will be the IZ8BLY Varicode, using an extended ASCII character set and super-ASCII control codes. See attached document.

Comment:
There is no good reason for using the exact G3PLX Varicode, since there is no inter-operability with PSK31. Alterations include swapping LF for BS, since the latter is widely used and the former rarely. The code is also changed to reflect the different use of idle. Inter-character framing will consist of detecting the sequence "001", rather than "00", which will allow considerably more shorter sequences to be valid. Sequences "000" and "0000" now become viable within characters. A number of non-printing control character additions will also be made.

Other options such as binary file transfer, non-varicode ASCII and other character sets may be offered, but are not part of this specification.

C.11. Idle Limitation
To avoid extended periods of single tone (for example when the keyboard buffer is empty), a non-printing character will be stuffed periodically into the transmit system as though it came from the keyboard. A non- printing character will be sent whenever the transmitter is idle for 20 symbol periods. Stuffing will not occur when the buffer is not empty.

Idle will be achieved by sending ASCII NULL or other non-printing character, followed by an extended zero bit stream, e.g. "0000000000000000". The latter will be rejected by the receiver as an invalid character.

Comment:
It is intended in future releases of this specification to describe a "secondary data channel". Special characters for secondary channel data, which will be outside the extended ASCII character set defined in paragraph C.10, will allow transmission of low priority data during idle, exactly like the DominoEX or THOR 'secondary channel'. The data rate would be very low, but would permit automatic ID. These super-ASCII characters would be used in place of the above mentioned NULL character. If this secondary channel extension is exercised by developers, the binary Varicode THOR alphabet (see FLDIGI and Dave Freese W1HKJ) is to be preferred.

The purpose of the "diddle" is to allow the receiver symbol clock to remain in lock. The diddle must not be continuous, as the idle period is used for signal tuning purposes.

C.12. Beginning and End of Transmission
At the start of transmission an idle carrier representing the lowest tone will be transmitted for 8 symbol periods. At end of transmission all pending transmit characters will be sent, and the transmitter will be flushed with zeros, allowing an idle period of at least 4 symbol periods to be transmitted.

Comment:
The purpose of the idle carrier is to allow accurate manual tuning.

C.13. Tone Bit Weighting
Tone weighting will be such that the lowest audio tone represents zeros in all bits. The weighting will increase in gray-code as the tone frequency is increased. This technique provides the least Hamming distance between adjactent tones:
   Tone         Weight           Tone         Weight
    0 (lowest)   0000             8            1100
    1            0001             9            1101
    2            0011            10            1111
    3            0010            11            1110
    4            0110            12            1010
    5            0111            13            1011
    6            0101            14            1001
    7            0100            15 (highest)  1000

D. The Receiver

D.1. Demodulator Technique
The receiver will use non-coherent demodulation, using an FFT filter and demodulator technique, integrating the signal over the symbol tone period by sampling the period synchronously with the transmitted symbol. A recovered symbol clock will be used to accomplish this purpose.

Comment:
Reduction of multi-path reception effects can be achieved by windowing the symbol sample period to exclude, for example, the first and last 5ms worth of samples. It may be possible to use multiple FFTs slid slightly in time, with a fixed clock, rather than use a fixed FFT and phase adjustable clock. Nino plans to test this theory as it may be a more sensitive technique.

D.2. Decision Decoding
The symbol decision decoder which follows the FFT will preferably use bit-wise soft decisions. The symbol decision decoder may offer soft decisions to the FEC decoder.

Comment:
Phil KA9Q recommends that each data bit be recovered from the symbol received not by direct binary decoding, but by weighing all the decoder bins potentially carrying that bit against those bins that don't.

D.3. Tuning Indicators and AFC
The symbol decision decoder will provide tuning indication, as well as signal performance metering (S/N meter). Automatic Frequency Control may be offered.

Comment:
This mode will be very sensitive, and very narrow, so will require very accurate tuning. Due consideration needs to be given to accurately tuning almost inaudible signals, through use of a good expanded waterfall display. A S/N meter in arbitrary units based on data from the symbol decision decoder will be useful. AGC is not required with an FFT approach.

D.4. FEC Decoding
The FEC decoder will use soft decisions, and may use soft data from the symbol decoder. For De-Interleaver details, FEC regime and placement of the coder dibits within the symbol, see the attached document.

Comment:
The FEC regime can identify the FEC dibits unambiguously from the fixed weight bits in the received symbols. fixed bit weights for each MFSK mode, where each mode has a different even number of discrete tones. This will greatly assist FEC framing since symbol phase is well known. This is only practical with even numbers of tones, thus the suggestion that FEC only be offered for even tone modes. Definition of the placement of the dibits is, like the interleaver, to be determined.

Perhaps an R=1/3 FEC code could be used for 8 tones, since Nino IZ8BLY has successfully demonstrated an R=1/3 technique, in a single bit stream. I don't believe FEC need be offered with 32FSK, as it is not inline with the KISS principle. I'd prefer to only offer FEC on even tone modes, and not offer even tone modes for non-FEC operation. I'd prefer to see just one coder and decoder used, once again for simplicity.

D.5. Confidence Meter
The FEC decoder may provide information for a 'signal confidence' meter, which reflects the current reliability of FEC decoding from the decoder metrics.

D.6. Appropriate Settings
Paragraph deleted in this release. The receiver symbol rate (FFT solution rate) and FFT parameters will be adjusted in concert with the transmitter settings to ensure orthogonality. Filter time constants and bandwidths will be set appropriately for the baud rate and signal bandwidth of each mode.

D.7. Default Text Mode
The default receiver text mode will use a specially adapted varicode, as defined in section C.10., translating into ASCII for display. Characters outside the defined extended ASCII character set will not be displayed, i.e. will not be sent to the screen.

Comment:
This use of non-printing special characters permits these characters to provide symbol sync or carry a secondary channel text thread where supported by the software, without requiring support to be part of this specification. In binary (file transfer) mode, where supported, raw data is used without an implied character set. Binary mode is not currently part of this specification.

E. Other Requirements

E.1. Symbol Sync
Receiver symbol synchronisation will be affected by using transmitted carrier phase or data transition information, or by multiple FEC decoder voting, rather than recovering AM modulation, since the transmitter is hard keyed.

Comment:
The original Piccolo used AM modulation of tones to transmit sync. MFSK16 does not, but transmits constant-phase carriers. CPFSK transmissions make these techniques possible.

E.2. Symbol Clock
The received symbol phase will remain substantially correct (within 90 degrees) for at least 50 symbol clock periods while receiving an idle condition, and will retain phase with one non-printing character every 20 symbols.

E.3. Tuning Display and Tuning
The user interface will provide a waterfall tuning display, preferably with point and click tuning, but with at least easy tuning in steps of 1/4 of the tone spacing or better.

E.4. User Interface Windows
The user interface will provide separate TX and RX windows, a type-ahead buffer and simple macros.

E.5. Mode Menu
See paragraph B3. One mode menu or other single mechanism will offer only the chosen modes with all default options preselected, in a well organised and obvious way. The selected modes will be in one menu - the general user must not be offered separate selection of baud rate, tone numbers, FEC, Interleaver or tone spacing. A sideband inversion switch may be offered separately.

E.6. Identification and Tuning Signal
Morse ID and a transmitter tuning signal will be provided.

Suggestion:
OOK of the lowest tone, or FSK between lowest and highest tones would be suitable for the ID, as it would assist receiver tuning. Transmitter idle will suffice for the tuning signal.

E.7. Transmitter Control
Transmit control will be via VOX or serial port, using the WD5GNR standard.

E.8. Receiver Squelch
Receiver squelch may be offered as an option. It may be based on Symbol Decoder metrics.

E.9. USB/LSB Reverse Switch
A reverse switch may be provided to allow copy of wrong-sideband signals. If provided, the transmitter will reverse in concert with the receiver.

F. Documentation

F.1. Software Copyright
User software (released binaries) of software offering this mode will be copyright of the author, and all rights will be retained by the various authors. All source code copyright to be retained by the author. All source code must be submitted to the MFSK development team if the software claims to be written to this specification. The ad hoc development team 'committee' will review executables (and source where necessary) before approval is given. See section F.3.

Submitted source code will not be published without the authors' permission, but if the software is approved will be retained and offered to interested developers on request.

Permission to use the MFSK16 logo will be provided for incorporation into approved software.

F.2. Non-Amateur Use
Commercial or military use of the released binaries will be permitted only as agreed by the contributing authors and owner of this specification. No responsibility for damages or lack of performance is assumed by the owner, the authors, or any of the development team.

Comment:
The purposes of this paragraph are to (a) discourage commercial exploitation of the product or concept without approval and involvement of the developers; and (b) to protect the developers from unreasonable demands.

F.3. Publication of Specifications
Algorithms and code tables sufficient to define the mode will be published as electronic documents, are referred to and referenced in this document. The documents will be retained on the MFSK web site http://www.qsl.net/zl1bpu/MFSK.

A reference version of the source code will be made available to interested developers. These released documents, along with this specification, will constitute the complete description of the mode.

F.4. User Documentation
Software developers are to make their own arrangements for documentation of their software. Installation and operating information will accompany each release.

F.5. Release of Non-compliant Software
No user software will be released which purports to support this specification but which offers for public use MFSK operation not covered by this specification. This particularly applies to test versions and beta versions. Test features in these releases must be protected from public access.

F.6. Freeware Availability
All user software (released binaries) will be made available free of charge, other than media costs, perhaps via an end-user licence. The software will be fully operational and fully documented.

Comment:
The GNU licence used for Linux products is an example of this technique. Links to the available release software will be made on the MFSK web site, http://www.qsl.net/zl1bpu/MFSK. A general guide to the use of MFSK will also be published on the web site.


End of Specification

  • All specifications and comments in this document are open to constructive criticism, suggestions and comment.
  • Volunteers are sought for all facets of improving the performance and uptake of MFSK16, DominoEX, THOR and related MFSK modes. This might include research, coding, system testing, system integration, UI design, documentation, publicity and user testing. Volunteers should contact Murray ZL1BPU in the first instance.

Copyright Murray Greenman 1997-2009. All rights reserved. Contact the author before using any of this material.