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)


12 October 2014

CIS MFSK 11+1 out of 16 7.8Bd/15.6 (XPA2)

XPA2 waveform uses a combination of 12 out of 16 possible tones: the lower tone (#1) acts as synch, or maybe as a separator/space between data, and is issued each 768 ms or each five symbols (Fig. 2). The eleven contiguous(!) tones from 6 to 16 are used for data. Room for the (possible) four tones 2-5 is not used. Notice that the tones #4 and #6 are used as EOM sequence. tones #1 and #16  as initial synch sequence. 
Manipulation speed is 7.8Bd while the separation between the "active" tones is 15.66Hz (Fig. 1). XPA2 is a Russian mode believed to be used by at least one of the Russian intelligence services.
Fig. 1
Assuming that the tone #1 acts as a separator/space between five 4-bit symbols (Fig. 2), the transmission could be interpreted as a commonly used five LGs/FGs off-line encrypted message.

Fig. 2
https://yadi.sk/d/Jmkm0ehj2omkRA







11 October 2014

Rivet e i suoi modi

Tralasciando i networks in Morse/CW, ci occuperemo oggi del decoder Rivet e della decodifica dei seguenti sistemi:

CIS36-50 (in LF a 36 baud, in HF a 50 baud): Russian Navy
CROWD36Russian Gov/Intel
XPA (10 e 20 baud): Russian Gov/Intel (*)
XPA2: Russian Gov/Intel (*)

(*) impiego non confermato da fonti ufficiali ma stimato tale

Il decoder che impiegheremo per la decodifica e' Rivet: decoder scritto in Java e quindi eseguibile su qualsiasi PC dove e' installata la Java Virtual Machine (java VM): nel caso mancasse, basta andare sul sito ufficiale di Java www.java.com   per il suo download e installazione in maniera del tutto automatica. L'ultima versione di Rivet e' la build_88 del Dicembre 2013, scaricabile da questo indirizzo: 
essendo scritto in java, Rivet ha l'estensione .jar quindi non preoccupatevi se non vedere nessun file exe. Sacricatelo sul desktop e, come ogni altro programma, eseguitelo con il solito doppio click sull'icona.
Andiamo a vedere le principali opzioni del menu' ed il loro impiego.

Main


Copy All to the Clipboard
L'intero contenuto della finestra di output viene copiati negli appunti. Utile se si desidera includere una sezione di una decodifica da Rivet in un documento mail o word processor.

Load a WAV File
Rivet decodifica non solo l'audio proveniente dal ricevitore ma può anche decodificare i dati contenuti in file WAV registrato in precedenza. Si noti che Rivet e' in grado di decodificare solo file WAV che sono stati registrati in modalità mono e in determinate frequenze di campionamento (di solito 8000 Hz).

Reset Decoding State
Se questa voce di menu è selezionata, Rivet ripristina le impostazioni predefinite per il modo correntemente selezionato.

Save the Current Settings
Permette il salvataggio di tutte le impostazioni selezionate (modalità, ecc) nel file "rivet_settings.xml". Al successivo riavvio, Rivet caricherà quelle impostazioni e le usera' come predefinite.

Save to File
Quando questa opzione è abilitata tutto il traffico che viene decodificato da Rivet sarà salvato in un file di testo ASCII. Quando si seleziona questa opzione viene mostratala richiesta del nome e del percorso del file.
 
Save Bit Stream to File
Permette il salvataggio in un file (prefisso .bsf) dei dati binari. Utile per l'analisi e il reverse engineering di una modalita' sconosciuta.
 
Soundcard Input
Quando questa opzione è abilitata Rivet accettera' l'audio dalla sorgente audio selezionata dal vostro mixer PC.

Audio
Audio Devices
Consente di indicare a Rivet l'ingresso, fra quelli disponibili sul vostro PC, da dove prelevare il segnale da decodificare
.

Modes

  
Useremo questo menu' per selezionare il sistema che vogliamo decodificare. Rivet non ha ne' spettro ne' waterfall e non ha bisogno di centrature di frequenze (lo fa' automaticamente) ma solo l'indicazione, tramite appunto l'opzione modes, di cosa si vuole decodificare. Oltre alle modalita' citate all'inizio, Rivet consente la decodifica  di:

CCIR493-4 : un particolare selective calling usato in HF
FSK200/500 : Russian Diplo e intelligence messages
FSK200/1000 : Russian Diplo e intelligence messages
FSK (raw) : per utenti esperti, consente la investigazione di sistemi FSK
GW FSK (100 baud) : Sistema di comunicazione ship to shore

Options
Consente di impostare alcuni parametri per la corretta decodifica di una trasmissione. Per i nostri scopi, segnalo in particolare:
CIS36-50 Options
Permette di impostare il valore di shift (default 200 Hz) (vedi piu' avanti)

Set the CROWD36 High Sync Tone
Permette di impostare il numero (0-34) del tono piu' alto di sincronizzazione che viene utilizzato  nella trasmissione CROWD36 che stiamo ricevendo, default 24 (vedi piu' avanti)

Finestra di output di Rivet



10 October 2014

Russian Navy Morse


This short text does not claim to be complete or exact, it is just an attempt to collect and consolidate sparse notes about the Rus Navy way to Morse. I did examined my own logs, browse some Navy and Defense websites, mainly from Russia, N&O columns / Spooks newsletters, public available sources and public sites/forums on the web (later reported). You have to know that this document is always-under-construction and may be outdated, incomplete or even wrong.
Comments are welcome.

Morse code: it's just beeps in the air

Morse CW is cheap and straightforward; many examples suggest, it often is used as last attempt in case of technical - or propagational problems with fast transmission modes. It is however absolutely clear: the vast amount of data is exchanged by transmission lines via satellite or landline.
The Russian Navy (and other Russian Forces) still use the Morse Code and during these peacetime periods they openly transmit Morse Code references to activate voice and data links. They transmit the frequencies in Morse in the clear and the recipient ship-shore station transmits/receives according to the information received.  The Russians wouldn't be sending such open transmissions if the deployment wasn't peacetime operations.
Monitoring such transmission is not illegal, it is not an hostile behavior!
Ask yourself why the Russians still use Morse Code? You seriously think that all transmissions used by an adversary, or potential adversary is not routinely monitored by the other side? Do you not think that signals intelligence collection agencies interested also routinely monitor these open broadcasts? 

....  .  .-.  .     .--  .     --.  ---
tips
they use T ( _ ) as an abbreviation for zero ( _ _ _ _ _ ); 

the char K indicates that the recipient(s) are asked to confirm or just a "fast exchange" between two stations;
the sequence '+ ar' (end pf message) may be replaced by +, K, 'RPT AL QLN +', or similar endings such 'RPT AL QLN K' repeat back online (see later the section "procedural signs"); 
WLHN (rare) is believed to be a collective call, ie for all forces, and believed to be originated from Moscow HQ; 
<BT> is the prosign for = and in some cases it could depend on the decoder (see later the section "procedural signs");

common preamble format (if present)

preamble example: 
162 30 18 1202 162 = 517 = [message]

162 message number
30   groups count
18   day of month
1202 local time
517 (if present) appointment code, a specific person or dept at the address


the preamble may include the senders callsign too;
the preamble is not used in plain requests and replies using the Q-code (radio checks, ec.);  

the preamble may precede:
- encrypted messages: 
 [preamble] = [ 5FG or 5ALG with or without encryption group and coded end-group]

- weather reports:   
[preamble] = recipients = [FM-13 synoptic data]

status/priority of the message
RKT (rocket) higher in the hierarchy;
XXX flash message, can be compared with the USAF EAMs messages since they seem to use a certain set of codewords. It should be something like a "get attention" for a message of high priority;
SML (aircraft) a precedence higher than routine;
UUU as preface means routine;

Q-codes
They use an extended set of Q-Codes. Some are known, many others not.
QTC I have a message (message follows)
QWH I start send on frequency (KHz)
QWH 9700/rptd = 12056/rptd will send on 9700, alternatively on 12056
QWH 9700/8536 = 12056/12572 the link will run with two parallel frequencies
QYR I start working on 81 Baud RTTY (presumed)
QYS I start working on duplex RTTY
QYT4 I start use MS-5 system
QYT4 QMO adjust your MS-5 system
QSX I will listen on frequency (KHz)
QSX 8440/rptd = 12414/rptd I will listen on 8440, alternatively on 12414
QLS use (upper) alternative frequency or change frequency
QRS send slower
QCM your transmission is affected by technical problems
QLN  rpt via landline
QSA radio check (request and reply)


plain Q-code example messages (from my logs)
"VVV RIT RIT RIT DE RMWT RMWT QSA? QTC K"
"RBEG QSL 435 K"
"RGR70 DE RIW K"
“RAL2 DE RHW2 QSA 2 ? K”
"RMDV DE RIT QYT4 QMG 1"
"RDNK RDNK DE RIW RIW QSA? K"
"RCV DE RJT22 QYT QSX 5736 K"
"RCV DE RMGB QSA2 QRV K"
"RCV DE RMGB QSU1 QSX 8770 K"
"RMI93 OK QRU k"


weather reports messages
Ships send weather reports every 6 hours (usually 0000, 0600, 1200, 1800 UTC) for their current location. They use the standard observation method as described by NOAA in their observation handbook, and within this message format there is a Lat/Long position report for where the observation took place: so you are able to localize the positions of the ships by decoding the Code FM-13-X-SHIP (or shortly FM-13). This ships synoptic code is comprised of 23 groups of symbolic letters representing meteorological and oceanographic elements, report identification and ship location data (see resources later at the end of this post).

1) Ship current position is coded in the Ships Synoptic Code Section 0:
... 99LaLaLa QcLoLoLoLo ...
... 99662 10345 ...

99 Data on Position Follow

LaLaLa (662) Latitude in degrees and tenths of a degree. Always coded with three digits, the first two digits are actual degrees, the last digit for tenths of a degree (66.2)

Qc
(10) Quadrant of the globe (specify whether the latitude is north or south and the longitude east or west). 
If north of the equator (north latitude):
- 1 when east of the Greenwich Meridian (east longitude)
- 7 when west of the Greenwich meridian (west longitude)
If south of the equator (south latitude):
- 3 when east of the Greenwich meridian (east longitude)
- 5 when west of the Greenwich meridian (west longitude)



LoLoLoLo (345) Longitude in degrees and tenths of a degree. Always coded with four digits, with the leading (hundreds) figure coded as 0 or 1. The first three digits are actual degrees, the last digit for tenths of a degree (34.5)

2) the ship movement data is coded in Section 2:
... 222DsVs ...
... 22232 ...

222 indicator
Ds (3)
true ship’s course made good during the three hours preceeding the time of observation:
0
Ship hove to
1
NE
2 E
3 SE
4 S
5 SW
6 W
7 NW
8 N
9 Unknown
/ Not reported

Vs (2) Ship’s average speed, in knots, made good during the three hours preceeding the time of observation:
0
0 knot
1 1 to 5 knots
2 6 to 10 knots
3 11 to 15 knots
4 16 to 20 knots
5 21 to 25 knots
6 26 to 30 knots
7 31 to 35 knots
8 36 to 40 knots
9 Over 40 knots
/ Not reported

Examples:

VVV RJD99 DE RBC89 QSA? QTC RBC89 572 9 5 0955 572 = FOR RJD90 RJH74 =
050?? 99662 10345 41/96 9230? 00050 40000 52020 70222 89/// 22232 00030 20202 232// 40302 88000 05016 = + RBC89

in plain text:
"ship  RBC89 (calling RJD99) at (Moscow) time 0955 was at 66.2N 34.5E , heading SouthEast @ 6-10kts"
the position of RBC89 is decoded from 99|662 10|345, with the heading/speed obtained from 222|32.

CW "771 19 9 1551 771 ...99548 10198...22242...AR RMWT K"
in plain text:
"ship RMWT position at 1551 Moscow time: 54.8N 19.8E  heading South @ 6-10kts"
https://goo.gl/maps/fwcRV

Since the time of reception differs from the one indicated in the preamble (does not matter if UTC or Moscow Time), it is presumed that the preamble time is the time when the message was prepared and not the time of the transmission: i.e. the data relate to the observation at 1603 Moscow Time (1203z) but sent (and then received) at 1220z.

about the procedural signs (wikipedia)

In Morse code, prosigns or procedural signals are dot/dash sequences that do not represent text per se, but have a special meaning in a transmission: they are generally not copied down, they are a form of control character.
They are used to indicate formatting of the text being copied or to indicate operational changes in transmission. They may be written as if they were composed of two or three ordinary alphabetic characters but they are sent "run together", omitting the normal inter-character spaces that would occur if they were being sent as normal text. These ligatures are often represented in print either by a ligating bar (overline above the letters) or by surrounding the run-together letters with angle brackets (such as <BT>), indicating that they are linked and sent as one contiguous sequence.




Sources and References
Informations in this document was submitted by independent radio monitors or has been obtained from public available sources and public sites on the web. Wherever data was obtained via the web or elsewhere, references and/or links to these sources have been noted.


http://www.numbersoddities.nl/
http://www.vos.noaa.gov/ObsHB-508/ObservingHandbook1_2010_508_compliant.pdf
http://en.itar-tass.com/military-defense 
http://defencerussia.wordpress.com/ 
http://www.cvni.net/radio/nsnl/nsnl072/nsnl72mil.html 
http://sp8wjt.cba.pl/TELEGRAFIA/rus_navy.html 
http://planesandstuff.wordpress.com/ 
 

8 October 2014

PRV: experimental beacon from Greece


07/10/14  06549.6 PRV: experimental beacon Preveza, GRC 2003z CW "PRV"



Occasionally active, on other frequencies also, with irregular schedule.
AFAIK the beacon is operated by SW6HMU, Mr. Plastiras Stilianos, CAA, Preveza Airport GR-48100 Preveza, Greece.


QSL via sw6hmu@yahoo.gr



4 October 2014

FEC, ARQ e SITOR: un po' di chiarezza

FEC e ARQ non sono vere e proprie modulazioni digitali bensi' “tecniche” di correzione errori che vengono applicate su alcuni modi digitali con l'obbiettivo di rendere le trasmissioni il piu' possibile immuni da errori.

Il termine FEC (Forward Error Correction) indica un meccanismo di rilevazione e successiva correzione degli errori a valle di una trasmissione digitale, ottenuta grazie alla introduzione di ridondanza di bit al flusso informativo. Vale a dire che rispetto al segnale originale vengono trasmessi dati aggiuntivi: il ricevitore, elaborando i dati ricevuti, può quindi effettuare controlli sull'integrità di questi e, se rileva uno o più errori, può tentare di correggerli basandosi sulle informazioni veicolate dai dati aggiuntivi. Vediamo un semplice esempio:

trasmissione senza FEC
dati da trasmettere: ABCDEF
dati tx: ABCDEF
dati rx: AB(errore)DE(errore)
dati interpretati: AB?DE
vengono persi i dati “C” e “F” !

Trasmissione con FEC (in questo esempio i dati vengono trasmessi tre volte)
dati da trasmettere: ABCDEF
dati tx: AAABBBCCCDDDEEEFFF
dati rx: AAABBBC(errore)CDDDEEE(errore)FF
dati interpretati: ABCDEF
il ricevitore recupera gli errori con una scelta “a maggioranza”!

Ovviamente la percentuale di errori che possono essere corretti con queste tecniche non è totale, ma limitata: se una trasmissione è particolarmente disturbata, oppure l'antenna mal direzionata o si verifica la presenza di oggetti estranei tra trasmettitore e ricevitore (ad esempio il ramo di un albero), la quantità di errori rilevata dal ricevitore può superare la soglia critica e non risultare più correggibile: in questo caso, il dato ricevuto non sarà più utilizzabile.

ARQ (Automatic Repeat-reQuest) è anchessa una strategia che ha il compito di rivelare un errore... ma non di correggerlo. Come lo stesso termine indica (richiesta automatica di ripetizione) i dati corrotti vengono scartati e automaticamente il sistema inoltra una richiesta della loro ritrasmissione.

Esempi di applicazioni sono il SITOR (SImplex Teletype Over Radio), in particolare:
- SITOR-A (o ARQ/SITOR-A) usa la tecnica FEC-ARQ 
- SITOR-B usa la sola tecnica FEC. 
entrambi sono modulazioni FSK con velocita' 100 baud e shift 170/200 Hz.
Gli OM usano SITOR ma viene chiamato AMTOR (AMateur Teleleprinting Over Radio), AMTOR-A e' il SITOR-A mentre AMTOR-B (chiamato anche AMTOR-FEC) e' il SITOR-B
 
Le due tecniche FEC e ARQ hanno vantaggi e svantaggi (maggiore occupazione di banda nel caso di FEC e maggiore latenza nel caso di ARQ) ma non sfugge che solo i sistemi bi-direzionali, ovvero stazioni rice-trasmitenti, potranno usare la tecnica ARQ. 

riassumendo...
  • i sistemi FEC sono adatti a trasmissioni broadcast/multicast
  • i sistemi ARQ sono adatti a trasmissioni unicast (PTP o point-to-point)
Infatti, quando le stazioni costiere devono trasmettere informazioni meteo sullo stato dei mari, e quindi trasmissioni dirette “a tutte” le possibili imbarcazioni in ascolto, usano Sitor-B che come detto e' un sistema FEC. La stessa stazione usera' invece un sistema ARQ (Sitor-A) quando dovra' comunicare con una singola imbarcazione.

In particolare, in ambito di navigazione civile, trovano applicazione i sistemi SITOR: 

NAVTEX (Navigational Telex) non e' altro che una particolare formattazione di messaggi di testo che sono trasmessi in SITOR-B ed usano il set di caratteri CCIR-476;
GMDSS/DSC (Digital Selective Call) è una variante del SITOR-B sempre a 100 baud e con shift 170 Hz che utilizza un set di 127 simboli.

Come si vede esistono sovrapposizioni di sigle e termini fra le quali e' semplice perdersi e fare confusione: per l'appassionato di radiosacolto bastano pero' alcune semplici nozioni in prima battuta per orientarsi al meglio: avreste mai detto che il NAVTEX e' un SITOR-B e, tutto sommato, un sistema RTTY?


2 October 2014

SERDOLIK MFSK-34 (CROWD-36)

Serdolik MFSK-34, aka CROWD-36,  is a MFSK-34 system with 40Hz spaced tones modulated at speed of 40Bd speed. The needed bandwidth is ~ 1500 Hz. This waveform is also known as CROWD-36 just because the grid of the tones clearly exhibits 2 empty places, so that the possible tones sums to 36 (34+2).

In the past CROWD.36 transmitted encrypted information in the form of 5 digit numbers then later moved to online encryption. These days the mode seems to be being used for link setup information with the actual traffic being sent in another mode such as OFDM if the conditions are suitable. So we'll have frequently a long MFSK-34 sequence repeating the same chars (cit. from Rivet decoder).