DGPS decoder in Spectrum Lab's Digimode Terminal

For some 'DX' reception tests with DGPS beacons, a crude DGPS decoder (actually, RTCM SC-104 V2.x) was implemented in Spectrum Lab .

MSK is in worldwide use for DGPS beacons on medium wave (near 300 kHz). This document describes how to use Spectrum Lab for DGPS reception on medium wave.

Input Filtering

Even though the MSK-demodulator performs its own passband filtering, it helps to use additional passband filtering before the signal enters the decoder:

analog filtering using the medium wave receiver's IF filter: In own experiments, a 500 Hz filter worked ok; but a 270 Hz wide IF filter cause too much phase distortion which made the result actually worse than without analog filtering;
digital filtering, for example using Spectrum Lab's FFT-based filter (in the digital signal path, before the MSK signal enters the demodulator).
To do this, open the circuit window, find the box labelled "Digimode Detector" (bottom), click on it's input label (by default, something like "L1" which is the input from the soundcard or an SDR), then select "L4 = Left Filter" as source for the digimode demodulator. If you use one of the preconfigured settings, the circuit as well as the FFT-based audio filter will already be configured so don't care about the details here.

For 100 baud DGPS beacons, use a passband width of 120 Hz or so (to avoid phase distortions or "ringing", especially at the edges of the passbands).
For 200 baud DGPS beacons, use something like 240 to 500 Hz (depending on the filter actually used; be generous with analog filters).

If you use a soundcard for input, and your MW receiver only has "wide" filters, try this one:

From Spectrum Lab's main menu, select: Quick Settings .. Other Amateur Radio Modes (!) .. Narrow CW Filter, adjustable with frequency markers. The red diamond ("VFO") on the frequency scale must be set to the center of the MSK signal; the blue diamond ("Audio BW") just outside the upper edge of the MSK signal in the waterfall display. Don't touch the green "Zero Beat" marker - it should remain at 650 Hz which is the audio center frequency for most of the preconfigured digimode settings (650 Hz was the author's preferred "CW pitch" frequency, also for analog audio filters).
In the main spectrum display, the MW DGPS beacon band may look like this, including the frequency markers to "tune" the filter:

Configure the 'digimode terminal'

The digimode terminal can be activated from SpecLab's main menu ('View/Windows') or from the component window. The DGPS decoder can be activated by selecting one of the "preconfigured" settings, or configured for your own needs as explained in the steps further below.

Screenshot of the 'Digimode' terminal window

Simple method (using a preconfigured setting) :

In Spectrum Lab's main window, select Quick Settings ... Predefined Digimodes ... DGPS / RTCM SC-104 ... MSK 100 bd (or MSK 200 bd) .
In the Digimode Configuration screen, check the 'Center Frequency (RX)'.
This field must be set to the precise center frequency of your audio filter.
For example, shortwave receivers with a 500 Hz "CW" filter use audio frequencies around 650 to 800 Hz.
On Kenwood rigs like the TS-850, this parameter is called "Pitch" and can be adjusted somewhere.
Confirm the settings in the Digimode Configuration screen by clicking OK.
If not done yet, start the demodulator and decoder by pressing F9 (or select Mode .. Receive in the terminal's menu).

Alternative (without using the preconfigured settings) :

Open the digimode terminal window. If not visible, use View/Windows in spectrum lab's main window, and select Digimode Terminal .
There, select Settings ... Digimode Configuration
On the Basic tab, set the following parameters:
Basic mode : CHARACTERS (!)
Modulation type : MSK (for the moment, use the 'normal' MSK demodulator... work on an improved demodulator is in progress.. 2009-10).
Code Set : RTCM SC-104 (DGPS)
Encoding : None (one to one; RTCM does not use differential encoding !)
Center frequency (RX) : To the center frequency of your audio filter; 650 Hz for the example from the previous chapter.
Symbol rate; Baudrate : 100.0 or 200.0 ( depending on the beacon; you can estimate this from the spectrum display, or find it in DGPS beacon lists).
The parameter 'Frequency shift or span' doesn't matter for MSK, because the shift is dictated by the symbol rate
(remember, the 'shift' divided by bitrate is always 0.5 otherwise it wouldn't be MSK..).
Now switch from the Basic to the Advanced tabsheet. There, set...
Rx Character Display to "Normal (plain text)" to let the DGPS decoder produce human readable text.
If nothing appears on the screen (after starting the receiver, see below), you can set this field to
"Debugging (type 1)" or "Debugging (type 2)". In these modes, the decoder may print additional info into the receive text window, which may help to find the reason "why" it doesn't work. For example, the decoder may mark parity errors as such, or emit raw "ones or zeroes" if it cannot synchronize the received stream.
Now switch to the Tuning Scope tabsheet, and set....
Tuning Scope Mode to "u(t) - amplitude over time";
Horizontal: One symbol time per division .
The tuning scope on the left side of the digimode screen will now show the eye pattern of the receive raw bits, which is a good tuning aid (especially to see if the frontend filtering doesn't confuse the demodulator).
Close the Digimode Configuration screen. All parameters will be saved for the next session, so you don't need to go through the above again.
If not done yet, start the demodulator and decoder by pressing F9 (or select Mode .. Receive in the terminal's menu).

If all works ok, and the receiver is properly tuned to a DGPS beacon, with sufficient signal-to-noise ratio, decoded messages will now be displayed in the "Receive" part of the digimode terminal. Since you will never transmit DGPS messages with this program, you can reduce the size of the 'Transmit' area of the window by moving the splitter down.

Details on the format of the decoded messages follow in one of the next chapters.

Receiving DGPS messages in the 'digimode terminal'

To check the MSK demodulator, the author tried to receive some European DGPS beacons on medium wave. Many of those beacons (like the Zeven DGPS transmitter on 303.5 kHz) use 100 bit/second, so the 'symbol rate' in the digimode configuration dialog must be set to 100.0 symbols/second (here, the same as 100 bit/second).

Occasionally check the eye pattern on the tuning sope. Zero crossings of the green line should only happen between two bit slots, and the "peaks" coinciding with the vertical grid (each vertical line in the grid indicates the center of a bit slot; not the separation between two bits). The red curve shows the envelope, which should be almost a flat line (for MSK). There may also be a yellow curve (depending on the MSK demodulator in use) which shows the bit synchronisation clock.

(eye pattern of a properly tuned MSK signal)

By default (following the setup in the previous chapter), the decoder will print "human readable" text, if it can decode anything at all. It if doesn't (for example, because the signal is too weak, distorted, mistuned, wrong bitrate, etc..), check the eye pattern again, and switch to a different output format. For example, the "binary" or "debug" format allows you to see the raw bits pouring out of the demodulator (not the decoder).

To select between different formatting options (for the decoded output), select Settings .. Advanced Settings in the terminal's menu, and set the Rx Character Display option to Translated (type 1) or Translated (type 2). 'Type 1' will show the DGPS signal as 30-bit GPS words, with an indicator for the parity check (*=parity check ok, -=parity check failed). 'Type 2' may present the output in a different format, which wasn't clear at the time of this writing yet.

The 'Debug' character display modes are subject to frequent change; for that reason they are not explained here. Most likely, the debug modes will show a binary, or hexadecimal output if the decoder cannot convert the message into plain text.

In the normal (default) character display mode, received DGPS messages will be displayed as plain, human readable text. In this mode, the decoder doesn't print anything if he doesn't decode valid DGPS messages. The Receive window will be filled with something like this (more about the display formats in a later chapter) :

Msg9: RefID=763 L=5 Z=14:Ø4.8 S=Ø H=Ø Data= Ø6FD86 Ø53615 FE69Ø4 ØE1ØFE 94Ø551 Msg9: RefID=763 L=5 Z=14:Ø7.2 S=1 H=Ø Data= ØAFCF9 Ø36E1E FBDAØ4 58Ø5FE 13Ø35A Msg9: RefID=763 L=5 Z=14:Ø9.Ø S=2 H=Ø Data= 1FFEØ5 FDØ8ØD FBEØFF 2Ø1DFE BEFD21 Msg9: RefID=763 L=5 Z=14:12.Ø S=3 H=Ø Data= Ø6FD8B Ø73615 FE6CØ5 ØE1ØFE 96Ø551 Msg9: RefID=763 L=5 Z=14:13.8 S=4 H=Ø Data= ØAFCFB FF6E1E FBDDFB 58Ø5FE 17FE5A Msg9: RefID=763 L=5 Z=14:16.2 S=5 H=Ø Data= 1FFEØ8 Ø6Ø8ØD FBE2Ø8 2Ø1DFE CØØ721 Msg9: RefID=763 L=5 Z=14:18.Ø S=6 H=Ø Data= Ø6FD8E ØE3615 FE6FØD ØE1ØFE 98ØD51 Msg9: RefID=763 L=5 Z=14:19.8 S=7 H=Ø Data= ØAFCFA FD6E1E FBDFFE 58Ø5FE 19FD5A Msg9: RefID=763 L=5 Z=14:22.2 S=Ø H=Ø Data= 1FFEØ9 F7Ø8ØD FBE1F5 2Ø1DFE C1F721

Like in the above example, most DGPS becons use message type 9 to send DGPS correction date. For medium wave DXing, the "RefID" is the most important output of the decoder, because you can see that 'BC Reference ID' in many beacon lists, for example the ones at www.ndblist.info/datamodes.htm .

The 'Sync Histogram'

The sync histogram is displayed at the bottom of the terminal window, as long as the RTCM decoder is active.
It is a quality indicator for the decoder's ability to synchronize to the received stream of 30-bit GPS words, by virtue of the six parity bits in each word.

Note:: The sync histogram hasn't got much to do with the bit-clock synchronisation as displayed in the eye-pattern diagram !
The eye pattern shows the output of the (MSK-)demodulator, while the sync histogram explained below is specific to the (RTCM-)decoder .
A nice eye pattern doesn't mean the demodulated signal can be decoded.
But a poor eye pattern indicates problems on the demodulator level; in that case the sync histogram will only show random distribution.

Sync-Histogram: ..1..............1.9.1........

To understand the sync histogram, it's important to know a little bit about the bit transport layer used by the MF DGPS beacons.

Without going too much into the details here, the official standard for the bit transportation layer is explained in a document titled

NAVSTAR GLOBAL POSITIONING SYSTEM
Interface Specification
IS-GPS-200
Revision D
7 December 2004

All messages are packed into 30-bit words, as explained in Chapter 20.3.5 of IS-GPS-200 .

After each received bit, the decoder (as implemented in Spectrum Lab) checks the parity as explained in IS-GPS-200 Table 20-XIV, as if a 30-bit word was complete. If the parity check fails, a counter for the current bit slot (out of 30 possible bits) is decremented, otherwise incremented. Each of the 30 counters is limited to a range of 0 to 9.

After each received bit, the decoder also searches for the larget value in the array of 30 counters. The counter with the largest value will most likely be the one which marks the end of a 30-bit word, because this bit slot has the largest number of successfull parity checks. Since there are only 6 parity bits in each 30-bit word, even with purely random noise at the input, there is still a chance of 1 out of 64 (= 2 power 6) to get "successful" parity checks.

Now the 'Sync Histogram' simply shows the values of those 30 counters (one counter per bit in the 30-bit GPS word). For better visibility, counter values of zero are displayed as dots. Since the maximum counter value is limited to 9, this is the best (largest) value which can appear in the sync histogram.

Due to the 1/64 chance of false "successfull" parity checks, even with a perfect input signal, the sync histogram will show occasional 'ones' besides the main peak (9). Don't worry about that. More important is that the 'main peak' in the sync histogram reaches at least 5, but ideally 9. The decoder starts outputting decoded messages at a peak value of 3, but such a bad parity ratio will sometimes produce garbage.

The absolute position of the main peak in the sync histogram doesn't matter - it depends solely of the time when the demodulator emitted the first data bit to the decoder, which is purely random. If the position of the sync peak moves left or right (within the 30 possible positions), there may be something wrong with the soundcard (lost input samples), or too large CPU load (also causing a loss of samples), or a soundcard sampling rate which is too far off the nominal value. To cure the latter, try to "calibrate" the sampling rate as described here.

DGPS decoder output formats

The output format (displayed in the receive window) depends on the Rx Character Display setting on the 'Advanced Settings' tab of the digimode control panel.

This can be one of the following:

Normal (plain text) = default:
The decoder uses a relatively verbose output format, possibly more than one line per message.
If possible, bitfields in the messages are scaled into physical values, and displayed with their physical unit (like "m" for meters).
Translated (Type 1):
The decoder tries to use one line per message only. The data after the two-word header are printed in hexadecimal form (very compact, but complete).
Translated (Type 2):
The decoder uses a very verbose output format, for example one line for each satellite.
Unlike the 'Normal' output format, bitfields are not converted into their physical value.
Instead, values are printed in decimal form, but without scaling.
Debugging (Type 1,2):
Similar as 'Translated" (types 1,2), but if the decoder cannot make sense from a received message, it dumps the GPS words as hexadecimal values.

The following tokens are used to display the common header for all DGPS message types:

RefID= the station's BC Ref ID (as mentioned in the beaconworld lists, decoded from the header);
L= length; actually the number of 30-bit GPS words which follow in the message (after the two-word header);
Z= Z-Time; here split into minutes and seconds of the current hour. It indicates the time for which the message is valid.
Because GPS (unlike UTC) ignores leap seconds, this time-offset is always a few seconds ahead of the local time (or UTC).
S= Sequence number. If no packets are lost, this counts from 0 to 7 and then wraps to 0 (actually a 3-bit number).
H= Health indicator. The only value observed so far was 0 (zero).
Data= heaxadecimal dump of 24-bit words (i.e. without the six parity bits in each of the original 30-bit GPS words).
In the 'verbose' output format, the data field in some message is not dumped in hexadecimal format,
but decoded in extra lines (after the line with the message header), as explained further below.

The following tokens are message specific, and are only used in the 'verbose' output formats:

SatID = Satellite Identifier. Identifies the satellite, for which the correction data shall be applied.
SF = Scaling Factor (for the pseudorange data, presumably).
SF=0 means "multiply the range data by 0.02 meters",
SF=1 means "multiply the range data by 0.32 meters".
Not displayed in the "very verbose" output modes; when the PRC is displayed in meters anyway.
UDR = User Differential Range Error. One of the following:
0 = less than 1 meter, 1 = 1 to 4 meters, 2 = 4 to 8 meters, 3 = more than 8 meters
PRC = Pseudo-Range Correction.
RRC = Range Rate Correction.
IOD = Issue Of Data. Quoted from Klaus Betke's description of DGPS station:
> If not equal to the IOD received from the satellite,
> satellite state has changed and this satellite should not be used.

In the default 'verbose' format, the decoder output may look like this:
(If the slash-zero ..Ø.. looks too ugly, turn it off in the digimode terminal configuration under Advanced Settings..)

Msg9: RefID=763 L=5 Z=ØØ:27.Ø S=5 H=Ø Corrections: SatID=13 UDRE:<1m PRC=-2Ø.34m RRC=-Ø.Ø16m/s IOD=55 SatID=23 UDRE:<1m PRC= -7.52m RRC=-Ø.Ø2Øm/s IOD=59 SatID=11 UDRE:<1m PRC= -6.2Øm RRC=-Ø.Ø2Øm/s IOD=45 Msg3: RefID=76Ø L=4 Z=17:15.Ø S=1 H=6 N5Ø°2Ø'Ø1.9" EØØ7°38'22.2" h=377.2m Msg3: RefID=761 L=4 Z=ØØ:15.6 S=Ø H=Ø N54°22'28.Ø" EØ12°56'Ø2.4" h= 49.4m Msg3: RefID=762 L=4 Z=3Ø:15.6 S=1 H=Ø N54°1Ø'59.Ø" EØØ7°54'42.Ø" h= 52.4m Msg3: RefID=764 L=4 Z=15:15.Ø S=6 H=Ø N48°49'48.8" EØØ8°Ø6'41.5" h=18Ø.8m Msg3: RefID=72Ø L=4 Z=45:21.6 S=5 H=Ø N56°26'37.6" EØ15°39'19.8" h=156.9m Msg3: RefID=686 L=4 Z=45:15.6 S=3 H=Ø N57°Ø8'2Ø.4" WØØ2°Ø2'54.8" h=1Ø8.7m Msg7: RefID=426 L=3 Z=Ø5:Ø7.8 S=6 H=Ø Beacon Almanac: BcastID=426 Freq=3Ø2.ØkHz Pos=N51°36'28" EØØ4°55'18" 2ØØ bit/sec MSK async Msg7: RefID=762 L=6 Z=3Ø:15.Ø S=2 H=Ø Beacon Almanac: BcastID=491 Freq=3Ø8.ØkHz Pos=N54°22'56" EØ12°55'49" 1ØØ bit/sec MSK async BcastID=492 Freq=298.5kHz Pos=N54°11'24" EØØ7°54'35" 1ØØ bit/sec MSK async Msg7: RefID=763 L=12 Z=55:16.2 S=2 H=Ø Beacon Almanac: BcastID=761 Freq=3Ø8.ØkHz Pos=N54°2Ø'28" EØ12°21'53" 1ØØ bit/sec MSK async BcastID=762 Freq=298.5kHz Pos=N54°11'24" EØØ7°53'56" 1ØØ bit/sec MSK async BcastID=763 Freq=3Ø3.5kHz Pos=N53°17'2Ø" EØØ9°15'ØØ" 1ØØ bit/sec MSK async BcastID=493 Freq=3Ø2.5kHz Pos=N5Ø°22'18" EØØ7°34'49" 1ØØ bit/sec MSK async Msg16: RefID=761 L=1Ø Z=ØØ:15.6 S=1 H=Ø RS Gross Mohrdorf Testbetrieb Msg16: RefID=762 L=8 Z=ØØ:15.6 S=2 H=Ø RS Koblenz Testbetrieb Msg16: RefID=763 L=8 Z=ØØ:15.6 S=3 H=Ø RS Zeven Test Operation Msg16: RefID=764 L=9 Z=ØØ:15.Ø S=3 H=Ø RS test betrieb monitored Msg16: RefID=686 L=8 Z=Ø1:ØØ.Ø S=3 H=Ø Gridle under maintenace("Gridle"?? where's that ;o)Msg16: RefID=851 L=9 Z=11:Ø8.4 S=3 H=7 Beacon Obristvi under test

Message 7, the beacon almanac, sometimes lists a few beacons in the neighbourhood of the station which sent this message.
In the verbose output modes, the decoder emits a new line for each listed reference station, including the 'broadcast ID' (see note on this below), the position in WGS-84 format (or ECEF coordinates), the frequency, beacon range, and possibly some information about the bitrate and modulation.
Some beacons do not send info about their 'neighbours' as you can see in the examples above.

(Note that some beacons identified themselves itself with the same value for the "Broadcast ID" and the "Reference ID".
By the time of this writing it was not totally clear why, because other beacons show different values in message 7).

For the medium wave DXer, the 'Reference ID' (short: RefID) is probably the most important parameter. Fortunately this parameter is contained in the header of each message, and thus listed many dozen times per minute.For other users, it may be more interesting to catch only message types 3 (GPS Reference Station Parameters), 7 (DGPS Radiobeacon Almanac), or 16 (text messages).
To achieve this, open the digimode configuration again, switch to the Decoder Specific tab, and enter the message type number to reject there.

Decoding DGPS data recorded with other programs

To test the decoder "off-line" (using 'raw' demodulated, but neither synchronized nor decoded bits), use the 'raw bit' file analysis mode described here.

You can use any plain text file which only contain 'ones' and 'zeros' (in ASCII) to let any previously recorded bitstream run through the decoder, and watch the decoder's output in the RX window.

Interpreter functions to access output from the DGPS decoder

Up to now, the following functions have been implemented in SpecLab's interpreter to access the output of the decoder.
The purpose of these functions is to plot the PRC values in the watch/plot window.

dgps[terminal_index].sat[sat_id].prc
retrieves the Pseudo Range Correction value (in meters) for the specified satellite (sat_id).
The terminal index is optional (0=first terminal ... 3=fourth terminal), it can be used to observe the output of different DGPS beacons, using different digimode terminals tuned to different beacons.

< ToDo: Complete this ... >

Last modified: 2009-11-15 (YYYY-MM-DD)