Wide Area Time Service with Extended Features






Abstract

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

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

The DRM (Shortwave / Medium Wave / Longwave) COFDM signal structure is significantly more complex than the AM receivers that decode the time signals listed above.

This Wide Area Time Service Proposal is meant to fix the many myriad problems of this technological design shortcoming of having a too complex a signal for the transmission of civil time and other services such as solar weather, marine weather alterts, etc... 





Frequency Band Allocation

  • Longwave : Bandwidth (LW) : 500 hz nominal, but 1000 hz typical if above 100 khz
  • 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, but 500 Hz is typical.

WWVB, JJY, MSF and DCF77 all claim to use 1 hz of bandwidth 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 bandwidth, with 800 Hz probable.

WWVB, JJY, MSF and DCF77 encode bits at a rate of 1 bit per second aka 1 baud.

This is terribly slow and 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 future proofing issues.

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

One would have to encode a full message each second, not one bit.

So what are the multiple carriers payoffs and costs?
  • 8 carriers, but this does not allow one room to code a message
  • 16 carriers, this allows for some room to code messages but you may have future proofing issues
  • 24 carriers, some room for some message types + version numbers + ... but not enough
  • 32 carriers, as 24 but with more breathing room for more data types ...
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, but at this point it is not specified.



The 32 Carrier Wave Time Signal Format

For the purposes of this proposal each carrier must signal
  • "0" with a duration of 0.4s, from the beginning of a second!
  • "1" with a duration of 0.8s, from the end of a second! (a case of Pulse Posistion Modulation) 
  • "Minute Notice" a "10101" should be sent on all "even" active carriers at the Pulse Rate of 5 baud at the 59th Second before each minute that ends with a Zero so :10, :20, :30, :40, :50 ... the "odd carriers" should be suppressed by at least 6 db to 9 db.
  • The 1s and 0s must not conflict with each other in time so as to increase electromagnetic compatibility.
  • The 1s and 0s must be of obviously different lengths from each other so as to lessen decoder confusion.
  • "marker" with a duration of 1.0s, but with an understood 0.05s rise and fall time, though the standard could support a rise and fall time of 0.025s if indicated in a transmitter (modulator) information group. This is an atomic time second and not a civil time second.
  • As better modulators are built, a rise and fall time of 0.0100s could be permitted.
The First (f0) and Last (f31) carriers are not modulated. Allowing f0 and f31 to be phase invariant would allow cheaper receivers the ability to lock on to the signal during very poor propagation conditions. It may be permissible to allow for f(31) = f0 + 180º to aid PLL locking of the entire signal for more expensive decoders.
However, in the interest of spectrum management the f0 and f31 carriers must be amplitude suppressed as part of overall modulation envelope management conditions.
  • A recommended 3db to 6db of carrier power suppression during bad propagation conditions is advised.
  • A recommended 9db carrier power suppression 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 20 carrier (bits) to play with. So how to best user them?

Bit allocation table
Bits Total Use Running Total 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 27
30 1 Payload Parity Bit (Even) 28



Bit Allocation Table Laid out Linearly
CW#
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

































Bit X
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
X

































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 -

































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

"-" : Used only for modulation, allowing for easier PLL lock on cheaper decoders.
CTR : Bit Use Counter
CW# : Carrier Wave Number
T = Traffic Type
V = Version
P : Parity Bit
PL : Payload
A1 : Same as 1, but to avoid confusion; used with Parity Bits only




In order for the Traffic Type and Version Number to not devlop too much of an energy pattern in the transmission, both must be offset by +4 for the Traffic Type and +4 for the Version Number. If this is not needed to be done this should be delteted from the proposal.

Traffic Type (4 bits, 16 traffic types)
  1. Reserved, DC bias suppression
  2. Civil UTC Date (Calendar Mode + Subtype {Years, Years since 1970 : [16 bit unsigned int]; Month & Day in Century})
  3. Transmitter & Modulator : Future State [Scheduled Maintenance, Future Modulation Levels]
  4. Civil UTC Time (Calendar Mode + Subtype {Hour in Century; Minute in Century; Hour in Decade; Seconds in Day ...})
  5. Solar Terrestrial Weather (14 different data groups; A Index, K Index; X-Rays; 304A; Proton & Electron Flux; Magnetic Flux; ...)
  6. POSIX Time (60 bits unsigned, 64 bits signed; 4 records minimum, 6 for redundancy; Binary not BCD; crc24 advised for final record)
  7. Current Transmitter & Modulator State, Antenna VSWR?
  8. Reserved for "0" and "1" signal timing at the receiver.
  9. Alternate Frequency, Call Letters
  10. Civil Time Offsets (includes alternate calender offsets), Future Leap Second; Future DST State; ...
  11. UT1 & GNSS Offsets, including Gaussian Second
  12. Land or Maritime Storm Warnings (mainly for Cyclones)
  13. TAI Offsets, Gaussian Second
  14. Data Expiration Timers (Traffic Type, Version, Minutes or Hours until invalid; use USB crc5)
  15. Geophysical Alerts
  16. Reserved, DC bias suppression 


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.


MT63 spectrum,
                2nd example


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

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




Related Links

Transmission issues
Error correction
Odds and sods






Author
Initial idea

Document created
Document last revised
Last Change

Revision State


Max Power
22 April 2002
29 April 2002
14 October 2013
Spelling

Intermediate 0.91b