28 October 2014

DGPS: the new frontier of DXing ?

Differential Global Positioning System (DGPS) is an enhancement to Global Positioning System that provides improved location accuracy, from the 15-meter nominal GPS accuracy to about 10 cm (!) in case of the best implementations.
DGPS uses a network of fixed, ground-based reference stations to broadcast the difference between the positions indicated by the satellite systems and the known fixed positions. These stations broadcast the difference between the measured satellite pseudoranges and actual (internally computed) pseudoranges, and receiver stations may correct their pseudoranges by the same amount. The digital correction signal is typically broadcast locally over ground-based transmitters of shorter range. Just these stations are called DGPS Beacons.

DGPS serving marine navigation

DGPS serving inland users

Differential correction techniques are used to enhance the quality of location data gathered using global positioning system (GPS) receivers. Differential correction can be applied in real-time directly in the field or when postprocessing data in the office. Although both methods are based on the same underlying principles, each accesses different data sources and achieves different levels of accuracy. Combining both methods provides flexibility during data collection and improves data integrity.


Real-time DGPS
occurs when the base station calculates and broadcasts corrections for each satellite as it receives the data. The correction is received by the roving receiver via a radio signal if the source is land based or via a satellite signal if it is satellite based and applied to the position it is calculating. As a result, the position displayed and logged to the data file of the roving GPS receiver is a differentially corrected position.

Postprocessing Correction
Differentially correcting GPS data by postprocessing uses a base GPS receiver that logs positions at a known location and a rover GPS receiver that collects positions in the field. The files from the base and rover are transferred to the office processing software, which computes corrected positions for the rover's file. This resulting corrected file can be viewed in or exported to a GIS.


postprocessing


These signals can be found on LF, on the channels listed in the Marine Beacon Bandplan in Section Nine; in Europe the band covers 283.5 to 315 kHz, but in some other parts of the world 315 to 325 kHz are also used.  DGPS beacons are heard using G1D modulation with Minimum Shift Keying (MSK), a frequency shift keying mode with very small bandwidth, and their sound resembles a RTTY/Navtex signal. 


DGPS spectrum [1]
The baud rate in many cases will be 100 bps though there are still quite a lot of 200 bps beacons in some parts of the world (especially North America). Baud rate setting may be set manually or automatically by the decoder.
tuning a DGPS beacon on 286.5 KHz
You can use software such as DSCdecoder or Multipsk to decode DGPS signals and see where they are coming from: DSCdecoder my be downloaded from the following site , it has a 21 days test period and costs Euro €25 (plus VAT for EUresidents) for personal use. Personally I use Multipsk and SkySweeper (see below).

Pay attention to the false decodes which return "exotic" beacons. The reasons for these being created are more complex, but sometimes not being tuned in properly, or even loud static bursts can start the decoder going and ‘invert’ signals , and this can be a problem when unattended monitoring is being attempted, and the user can’t see what is causing it. Moreover, most Message Types used by DGPS beacons fall into a limited category, so anything outside of these should be treated with caution, especially if only one decode ‘frame’ is received, and not multiple identical decodes. 

As David GM8XBZ say:
"The station details that a decoding programme gives are from a lookup table that it holds. When it gets a station reference, it prints out the info it has in the software. All you receive is the station number. If that is an error, the software doesn't know.
The big clue, besides the range and time, is the Z-count value. In a 'good' decode, this should be the same as the time-stamp from the PC.  for example, at 21:12:30, the Z-count should be close to 1230 (12 min 30secs)."






DGPS Message Types
There are a number of different ‘Message Types’ broadcasted by the various DGPS beacons, and below is a list of what these are in my log and what they mean:

Message Type: 1 Differential GPS Correction
Message Type: 3 GPS Reference Station Parameters

Message Type: 5 GPS constellation health
Message Type: 6 GPS null frame
Message Type: 7 DGPS Radiobeacon Almanac
Message Type: 9 GPS Partial Correction Set

but there are up to 63 message types:

DGPS message types [1]
DGPS decoders and reception
Below a DGPS transmission received just some minute ago from station number 469 (Porquerolles FRA 286.5 Khz TXID 339 100bps): the same transmission has been decoded with Multipsk and SkySweeper (this one showing local time, UTC -1):

working 469 DGPS beacon with Multipsk


working 469 DGPS beacon with SkySweeper

When loggin a DGPS beacon, its "reference ID" is indicated as "station number" by decoders: this number is usually taken as its callsign while the TX ID number is noted in details within the its baud rate. In the above case I'll log:

00286.5 469: DGPS Porquerolles, FRA 1243 TXID #339 100bps

The "station number" helps to identify the received beacon. As seen, two numbers exits (see the table below): 

1. GPS reference station number
2. DGPS broadcast station number (see the table below)

The numbers itself are not part of the RTCM standard, but are assigned by IALA. Some authorities stick to the RTCM standard and send the reference station number, others use the broadcast station number.
DGPS beacons in the UK, Norway and Denmark, for example, transmit reference station numbers, while those in The Netherlands, Germany, Sweden and Finland send the broadcast station number.
This confusion has not been resolved so far.



Stations Numbers [1]

European Differential Beacon Transmitters (European DGPS Network)

Trinity House have changed the frequency of many of the UK DGPS beacons, see:
http://www.trinityhouse.co.uk/pdfs/gps_ukireland.pdf 
  
 



Happy DGPS DXing ! 

27 October 2014

the poor-man guide for ship plotting


using Google Earth to display positions of the ships

from my logs of 25 October:

12464.0 RMCW: Russian Navy ship "Donuzlav" 1205z
CW "RCv DE RMCW = SML FOR RJE73 RJH45 = ...99417 1T296...22212"
-> position 41.7N 29.6E Heading North-East @6-10 knots


12464.0 RMGB: Russian Navy ship "Iman" 1207z
CW "RCV DE RMGB = SML FOR RJH45 RJe73 = ...99351 10239...22262"
-> position 35.1N 23.9E Heading West @6-10 knots


12464.0 RJC20: Russian Navy unid ship 1210z
CW "RCV DE RJC2Ø = SML FOR RJH45 RJE73 =...99351 10235...22232"
-> position 35.1N 23.5E Heading South-East @6-10 knots



Now we want to plot (and save) the above ships positions using google earth. You have to know that you may create your own google-earth kml files (Keyhole Markup Language)  in order to show the ship's position on google-earth or google-maps. Just write a single kml file for each ship you want to trace then save the file with then ".kml" extension. 

First creates a special directory in your documents folder, naming it as you want (assume "ships positions"). Then in order to create your kml files use this very very basic default schema:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
  <Placemark>
    <name>placemark name shown in the map</name>
    <description>description shown by clicking on the placemark</description>
    <Point>
      <coordinates>
longitude(E or W),latitude (N or S)</coordinates>
    </Point>
  </Placemark>
</kml>

for example, file for RJC20 tracking:
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
  <Placemark>
    <name>RJC20</name>
    <description>Russian Navy RJC20, position at 25 October</description>
    <Point>
      <coordinates>23.1E,35.1N</coordinates>
    </Point>
  </Placemark>
</kml>

Then save the file using a self-explaining name and the appropriate extension such as "RJC20-25-oct.kml" in the directory that you created earlier (i.e. "ships positions").
PAY ATTENTION you may use the basic block-notes program by Windows but remember to select all files mode when you save the file so to give it the right extension (.kml), otherwise the file will be saved with the ".txt" extension.

Now start your google-earth program and click File > Open, navigate to your "ships positions" directory, select your previous saved .kml file, and click Open. The file will be added to the Temporary Places section of your Places panel and the position will be imported and displayed. By clicking on Temporary Places - file name you may the refine the map and store it... et voila' !





25 October 2014

CODAN-9001/3012: MPSK-16 QPSK

The CODAN 9001 modem uses the 16 QPSK carriers for the transport of data (payload), each carrier is independently modulated with data so it carries a distinct channel-packet. All the 16 concurrent channel-packets constitute a frame and a number of frames constitute a multi-frame.



This "data" waveform is an asynchronous adaptive ARQ system. The modulation rate of each of the 16 tones is 75 Baud; the modulation type is quaternary phase-shift keying (QPSK). The QPSK scheme uses from 656.25 Hz to 2343.75 Hz, these center frequencies are derived from a 600 Hz to 2400 Hz frequency spread and 112.5 Hz per QPSK channel (http://signals.radioscanner.ru/base/signal85/)




While the CODAN-9001 transports data, the CODAN Chirp provides the ALE/selcall (Automatic Link Establishment) part between the peers.

Each payload data packet has a constant length and a sequence number. However, the numbering only serves as an example, and due to the use of ARQ-based retransmissions the numbering may not be sequential.

CODAN-9001 16 tones schema
Independent of the payload data field, the sequence number field has its own error detecting and correcting code. Payload data in each channel packet is protected by a cyclic redundancy code (CRC). This feature is included in order to allow the ARQ protocol to request retransmission of packets received in error.
A session consists of one or more multi-frames. Depending on the amount of data queued for transfer the length of a multi-frame may vary. The receiving modem will extract the frames from the multi-frame determining the number of channel packets and checking whether payload data was received without errors. If a channel packet was received in error a re-transmission is requested. It should be clear from this that a multi-frame may consist of a mixture of new data and re-transmitted data. Re-transmitted data may appear on any channel and in any position within a multi-frame.
Additionally the transmitting modem may opt to send ALE-like parity bit packets in a separate frame and even on another channel within the same multi-frame as the payload data packet to which it belongs. This is indicated by the two packets belonging together carrying the same sequence number. This mechanism is predominantly seen when the link quality deteriorates and consequently the number of re-transmissions increases.

CODAN CALM

While CODAN-9001 transports data, CODAN CALM (CODAN Automated Link Management) provides the ALE part between the peers. CODAN Chirp uses PSK-2 modulation across 32 channels with 80Hz of spacing and speed of 80 Baud,  and uses ~2600 Hz of bandwidth.
http://hf-ssb-transceiver.at-communication.com/en/codan/hf_ssb_transceiver_ngt.html 


   

Below a Codan CALM session followed by data sent in Codan 9001 (Egyptian Diplo)

24 October 2014

BATHY, TESAC, TRACKOB reports and GSVMF

Russian Navy Morse | BATHY, TESAC, TRACKOB reports and GSVMF

Other than the basic FM 13 weather observations, the oceanographic and hydrographic ships of the Russian Navy send other specialist messages containing information about sea temperature, salinity and current at different depths. Think: salinity and sea temperature versus depth could be vital to a commander of a submarine who needs to hide his boat under a halocline or thermocline layer (it was discovered that thermal layers affect sonar performance; below a thermal layer, a submarine's active sonar performed poorly when trying to acquire a target. Conversely, a surface ship's sonar pings were reflected and scattered by the layer as well, allowing the submarine to hide beneath it).These messages are known as BATHY, TESAC and TRACKOB reports and, as well as the FM 13 ones, are sent to the Hydrographic Service of the Russian Navy. First, let's take a look at this service.

The Hydrographic Service of the Russian Navy (GSVMF) is one of the important national bodies responsible for the safety of navigation. Although the Hydrographic Service forms a part of the Navy, it also meets the requirement of merchant and fishing fleets and vessels of other ministries and agencies.  The Hydrographic Service is under the direction of the Department of Navigation and Oceanography of the Russian Federation Ministry of Defense (DNO of the RF MD), which is traditionally located in St Petersburg.

The principle functions of the DNO of the RF MD are:

— to carry out oceanographic, hydrographic and geophysical surveys in the World Ocean
— to compile and produce Nautical Charts, Publications and Guides to Navigation
— to develop and produce Guides, Instructions, Regulations and Methodical Directions on carrying out the World Ocean surveys and processing of their results
— to equip the coast of the Russian Federation by aids to navigation
— to organize mariner notification about changes in navigational conditions and regime
— to develop up navigational instruments and complexes.


As reported by defencerussia "In 2014, survey vessels of three fleets of the Russian Navy will make long trips [...] The main objectives of the campaign are comprehensive oceanographic studies of the Mediterranean Sea, the collection of data for the next hydro-navigation proof nautical charts, manuals and handbooks on shipping, a study of the navigation system, ensuring the presence and demonstration of the flag of the Russian Navy,” the Russian Navy Captain of the 1st Rank Igor Dygalo said. 
To carry out ocean ographic surveys some special units have been created as a part of the Hydrographic Service of the Navy, such as expeditions and parties. 
The surveys are being run by oceanographic and hydrographic ships of up to 9000 tons displacement, equipped with modern navigational and oceanographic facilities. Ships may have anti-terror team on board consisting of marines in order to maintain security during the cruise. 

The Oceanographic and Hydrographic observations are sent daily by the Hydrographic ships (FM 13 reports at fixed times 00, 06, 12 and 18 UTC) to the ground stations of the GSVMF.  Such messages are not sent directly to ground stations but forwarded via Naval HQs:

RJP99 547 18 4 2214 547 = FOR RJH74 RJH45 = ... (via RIT, NSF HQ Severomorsk)
RMCW 6T2 18 23 16TT 6T2 = SML FOR RJE73 RJH45 =... (via RCV, BSF HQ Sevastopol))

In fact, looking for example at the FM-13 reports (at least here in Southern Europe) you may see that most of these messages almost always report two recipients, mostly RJE73 RJH45 or RJH74 RJH45 usually using the "sml" priority indicator: I do not know if the recipients are local GSVMF offices at each HQ naval bases (RIT, RCV,...) or just GSVMF central offices.
As reported by  planesandstuff site, the observed calls of GSVMF ground stations are:
REG98
RJD38
RJD90
RJE69
RJE73
RJF41
RJH45
RJH48
RJH74
RMSZ

and  the observed calls related to survey/research ships are:
RFE76 Sibiriyakov
RHO62 Admiral Vladimirskiy
RJP30 Senezh
RJP99 Gorizont (belonging to the Northern Fleet)
RKB92 *
RMCW Donuzlav (belonging to the Black Sea Fleet)
RMIB *
RMQW *
RMWT *
RMX62 *
(* = not confirmed)

RJH45 = MOSCOW NAVAL METEO
RJE73 = BLACK SEA FLOT METEO
RJH74 = NORTHERN FLEET METEO
RJD38 = BALTIC FLOT METEO
RJE65 = BLACK SEA FLOT HQ, NOVOROSSIYSK


The BATHY, TESAC and TRACKOB reports are described here with tables and instructions about their decode: the data collected by these reports are sumarized below (from the same source).


The BATHY report should be used for recording temperature observations versus depth taken with instruments which provide the temperature with a resolution of 0.1 degrees Celsius or less, such as mechanical or expendable Bathythermographs, thermistor chains or others. The TESAC report should be used for temperature values with a higher resolution and/or when salinity or current versus depth are reported (see later). In addition to the temperature information, the BATHY report makes provision for encoding sea-surface current measurements and depth to the bottom, as well as other environmental information. 
Report information is designed according to the reporting code FM 63-X Ext BATHY.

The TESAC report should be used if one or all of the following data sets are available: Temperature versus depth with a resolution of 0.01 degrees Celsius, Temperature and salinity versus depth, Current versus depth. 
Report information is designed according to the reporting code FM 64-IX TESAC.

example of a TESAC message (from planesandstuff)

1836z RJP99 911 28 4 2216 911 = FOR RJH74 RJH45 =
KKXX 04093 1545/ 17000 03601 88870
20000 31149 20010 31110 20020 31096
20030 30876 20050 30402 22075 30344
30100 30344 20?43 30288 00000 55555
10144 04025 = + RJP99


The TRACKOB report should be used for recording of conventional oceanographic observations at the sea surface taken along a ship's track. The report form permits the collection and transmission of one or more parameters such as water temperature and/or salinity and/or ocean currents in terms of direction and speed.

It is designed to report spot values as well as averaged data over a selected time period. The instruments used should provide the temperature with a resolution of 0.1 degrees Celsius or less, the salinity in 0.01 of practical salinity units, the current speed with a resolution of 0.1 metres/second or 0.1 knots, and the current direction to at least 10°.
Report information is designed according to the reporting code FM 62-VIII Ext. TRACKOB. 
 
Mediterranean hydrographic vessel “Donuzlav” (defencerussia.wordpress.com)