A Distributed Longwave Time Service

Wide Area Time Service with Extended Features

Abstract

The Digital Radio Mondiale standard for long / medium / short-wave digital audio broadcasts (freely available for downloading as ETSI TS 101980) includes time data.

However, as with RDS and DVB and ATSC, the data format specification is not really optimized towards high-precision clock synchronization and is too complex for simple receivers.

The DRM COFDM demodulator needed is significantly more complex than the AM receivers that decode the time signals listed above.

This Wide Area Time Service is meant to fix the many myriad problems of this technological design shortcoming.

Frequency Band Allocation

Longwave : Bandwidth (LW):
Shortwave : Bandwidth (SW): 500 hz / 1000 hz / 2000 hz

Transmission Layer

Waveform & Coding Specification : Longwave Transmission

To send data over longwave frequencies, nearly raw binary is best. This is absolutely necessary as bandwidth is limited very often to 1000 Hz or less.

WWVB, JJY, MSF and DCF77 all claim to use 1 hz of bandwith to send out their Civil Time Signals, but this is strictly speaking not true. As beeping sounds are often associated with these time signal stations, one has to assume 500 Hz maximal bandwith.

However, this is at a rate of 1 bit per second aka 1 baud. This is terribly slow and in many ways a very inefficient way to transmit a time signal. Also, as the coding formats for these time signals date to the 1960s when even having 60 bits of memory was pricy -- the 1 baud format is extremely rigid and easily troubled by futureproofing issues.

The obvious solution for longwave, with respect to keeping receiver complexity low -- is to use 1 bit per second but with multiple carriers.

But you have to code a full message each second, or else it is a botheration scheme so you might consider

8 carriers, but this does not allow one room to code a message
16 carriers, this allows for some room to code your message but you may have futureproofing issues
24 carriers, more than enough room for lots of message types + version numbers + ...
32 carriers, as 24 but with more breathing room for more data types ...

A 24 carrier system should, as in the WWVB & JJY general specification have

If the period of reduced power is one-fifth of a second (0.2 s), this indicates a data bit with value "zero"
If the period of reduced power is one-half of a second (0.5 s), this indicates a data bit with value "one"
If the period of reduced power is four-fifths of a second (0.8 s), this indicates a "marker"

Zero can also mean "Not Set" and One can mean "Set" in data fields.

JJY uses the exact opposite signalling regime (aka time durations) for its data and marker bits that WWVB uses, for propagation on 60 khz this is logical and reasonable but causes hardware and software incompatibilities.

DCF77 uses much shorter times for designating "0" and "1" and does not really have any marker bits. MSF also behaves very similarly, but has limited marker bits.

However, in a multiple carrier system the "marker" can be disposed of as it has little meaning. The marker bit should at least reserved for propagation measurements.

The European vs North America & Japan way of doing time signal modulation and signalling are quite different -- and very few dedicated hardware units can decode more than one format. The old ideas for time signalling are useful, but too varied to be coped with modern software and hardware.

The 32 Carrier Time Signal Format

So, for the purposes of this proposal each carrier must signal

"0" with a duration of 0.3s
"1" with a duration of 0.6s, after all the "0"s have been signaled!
The 1s and 0s must not conflict with each other in time so as to increase electromagnetic compatibility.
"marker" with a duration of 1.0s, but with an understood 0.05s rise and fall time. This is an atomic time second and not a civil time second.
There is an understood 0.05s rise and fall time for signalling the 0s and 1s. This may be tightened up as better modulators are built, but 0.01s is the most optimal value permitted.
The First (f0) and Last (f31) carriers are not modulated, this is to allow receivers the ability to lock on to the signal during very poor propagation conditions.
However, in the interest of spectrum management the f0 and f31 carriers must be amplitude suppressed as part of overall modulation envelope management conditions. I recommend 6db of carrier power suppression during bad propagation conditions and 9db during good propagation conditions. The bare minimum carrier power suppression should be 1.5 db, but 3.0 db nominal.

Packet Format

So, there are 22 carriers (bits) to play with. So how to best user them?

Bit allocation table

Bits	Total	Use	Bits Used (22 max)
01 to 05	4	Traffic Type	4
06 to 09	4	Version Number for Traffic Type	8
10	1	Traffic Header Parity Bit (Odd)	9
11 to 29	18	Payload	29
30	1	Payload Parity Bit (Even)	30

Bit Allocation Table Laid out Linearly

Bit	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30
Use	T	T	T	T	V	V	V	V	P	PL	PL	PL	PL	PL	PL	PL	PL	PL	PL	PL	PL	PL	PL	PL	PL	PL	PL	PL	PL	P
	1	2	3	4	1	2	3	4	A1	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	A1

T = Traffic Type
V = Version
P : Parity Bit
PL : Payload
A1 : Same as 1 but to avoid confusion

Traffic Type (4 bits, 16 traffic types)

Reserved
Civil UTC Date
Transmitter Future State
Civil UTC Time
Solar Terrestrial Weather
POSIX Time (60 bits; 4 records; Binary not BCD)
Transmitter State
Reserved for "0" and "1" signal timing at the receiver.
Alternate Frequency, Call Letters
Civil Time Offsets
UT1 Offsets, including Gaussian Second
Land or Maritime Storm Warnings (mainly for Cyclones)
TAI Offsets, Gaussian Second
Data Expiration Timers (Traffic Type, Version, Minutes or Hours until invalid; CRC5)
Geophysical Alerts
Reserved

Waveform & Coding Specification : Shortwave Transmission

By encoding the data to transmit (what you type on the keyboard) in a complex way, using 64 different modulated tones, the MT63 developer Pawel Jalocha SP9VRC has been able to include a large amount of extra data in the transmission of each character, so that the receiving equipment can work out, without any doubt, which character was sent, even if 25% of the character is obliterated.

MT63 has the facility for a secondary channel running simultaneously alongside the main channel. This can be put to a variety of uses, such as the generation of a continuous identification or beacon.

I have not decided what information, if any should be used in this channel for this telecommunications service, however it would be acceptable to transmit an idle stream of {...01010101...} until a proper use can be found for this low complexity low bandwidth channel.
The secondary channel is not a prime function within the current MT63 specification -- therefore some software provides for its use while other software does not.
The option to transfer binary files in MT63 (such as higher-level documents or spreadsheets) is at the whim of the programmer with respect to the current MT63 specification.

MT63 sounds unusual, (it sounds like a roaring noise) but the performance is spectacular.

Some users maintain that under poor propagation conditions (namely excessive fading and multipath) find that MT63 works better than the current PACTOR waveform or Clover. Under good conditions the performance advantages of MT63 are less obvious.

Jamming immunity within the existing MT63 specification

MT63 is also far more immune to unintentional man made interference (QRM), jamming (QRJ) as well as natural interference (QRN) than the majority of existing conventional radiotelegraphy modes.

In a "long interleave" option, the spreading is over 64 symbols (6.4 sec), with consequent improvement in resistance to impulse and periodic interference, but of course double the time taken for the data to "trickle through" the Walsh encoder and decoder pipeline.
Using "short interleave" MT63, the signal is still not viable for sending time signals. The time delay is still too large to be of any use for public use.

MT63 bandwidth guidelines

below 5 MHz, only use 500 Hz mode
between 5 MHz and 15 MHz use 1 Khz mode
from 15 MHz to 30 MHz use 2 Khz mode

MT63's Walsh coding: a design flaw?

The current 7-bit version (base128) of MT63 uses Walsh codes, with temporal interleaving.

This may not be an optimal coding scheme with respect to error correction.

It must be pointed out that turbo codes could be used to accomplish the same task, with a ~25% increase in efficiency.

Justification

Walsh: 7 bits → 32 bits
Turbo: 8 bits → 24 bits (the need for varicode can be eliminated)
Walsh - Turbo = 8 bits, a 25% increase in system efficiency

The same temporal interleaving techniques could be used with turbo codes, but as a general principal only short length interleaving should be used with turbo codes.

Physical Layer Coding

The current Walsh + Convolusional coding of MT63 (for ECC) must be completely abandoned for this application. Error Correction with the raw bitstream at the Physical Layer should be done via (low complexity) Hamming codes, specifically a low complexity Hamming (6 , 2) Code

http://www.ee.unb.ca/cgi-bin/tervo/hamming.pl?X=+Generate+&L=6&D=2&T=000000
It would be assumed that using 5 of the 6 Hamming Code bits is appropriate, pending further research.

These Hamming parameters should provide adequate error correction with minimal decoder complexity. Most codewords in this codebook have a Hamming Distance of either 2 or 4. Many codewords have a Hamming Distance of 6.

The average Hamming Distance in this case is around 3.

As this transmission system is only best designed for 1 hop shortwave service (under 1500 km), and medium power LW service -- this ECC provision [although imperfect] is adequate.

Packet Coding