MFSK16

Purpose of Specification

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 (invitation only) mailing list MFSK@egroups.com. To join the list, send email to the moderator at as149@detroit.freenet.org. 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

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 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 IZ8BLY MT63 "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.

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.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.

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 development team "committee" will review all source and executables 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.