a STANAG-4285 autobaud waveform?

Interesting STANAG-4285 transmission heard on 14000 KHz/USB and sent me by my friend GrandBleu from radiofrecuencias.es (Figure 1)

Fig. 1 - STANAG-4285 segments

The 35 sec segments seem a modified S-4285 waveform since they begin with a block, that I here refer to as "header", and which is not referenced in the standard. The header has a duration of 116ms and is modulated using PSK2, as you may see in Figure 2.

Fig. 2 - PSK2 modulation detected in the initial "header"

I used the SA phase detector and its relative bitmap in order to "browse" the signal and to better indagate the header. Looking at Figure 3 you may see a 13.333ms repeated pattern: well, 13.333ms @ 2400 symbols/sec makes a duration of 32 symbols (31,999) or 32 bits, since the header is PSK2 modulated (ie 1 bit = 1 symbol).

Fig. 3 - 32-bits repeated pattern in the header of the heard S-4285 waveform

Consequently, I tried a PSK2 demodulation of the headers of some segments and after their differential decodings I obtained  bitstreams which exhibit a well-defined structure consisting of initial and final "01"s sequences and characterized by a 32 bits sequence which is six times repeated immediately before of the final "01"s sequence and that exactly matches the pattern seen in the bitmap of Figure 3.

[10100001001111001111100011011110]

Fig. 4 - differential PSK2 decoding of a header

The same 32-bit sequence was found in all the headers I demodulated (just 3 of them are shown in Figure 5), even if it didn't appear in the same order I wrote it: one must consider the characteristcs of the SA's generic (!) PSK-n demodulator .

Fig. 5

I don't think this so-called header is actually a “transmit level control” (TLC) block. Indeed, no information is carried by the TLC since it's a sequence of symbols intended solely for the purpose of establishing the radio TGC (transmit gain control), ALC (automatic level control) and AGC (automatic gain control) before the actual preamble is sent/received. In my opinion this S-4285 waveform feature an “autobaud” facility (1) which is coded in the initial header (perhaps a Walsh coded sequence?). As shown in Figure 5, the autobauding information would consist of 6 frames, each with a duration of 13.3 ms and a length of 32 bits (total length of 192 bits), and precedes the S-4285's usual synchronization preamble.

And let's get to the data blocks. To identify which sub-mode is used I chose from time to time the various options made available by a S-4285 decoder (k500) until I found the option that had 100% confidence and 0 errors: that is, 300bps and zero length interleaving.  As a test, I used a second S-4285 decoder and always got the same result even if the resulting bitstreams didn't seem structured. Although these decoders indicated 100% confidence and 0 errors (corrections), curiously they did not detect/show the 32-bit words used for signaling the Start Of Message (SOM = 0x03873C3C MSB first) and End Of Message (EOM = 0x4B65A5B2 MSB first): could it be sign of a "fake" decoding? Finally, I used a third, more sophisticated, decoder configuring it in "auto-detect" mode: this third test also confirmed the 300bps/N sub-mode but with the reporting of corrections and a resulting bitstream with a 40-bit/5-byte period that has - in my opinion - a bit more sense.
The 40-bit length period is due to the presence of a sequence that is four times repeated near the end of all the decoded segments (Figure 6). Note that the same considerations made above apply to the sequence in question.

[1101101000100111101001111111000111100101]

At first glance it could be an EOM/EOT signal but the bitstream should come from a higher level protocol (datalink layer) i.e. after the removal of the S-4285 overhead and therefore should have a different function.

Fig. 6 - a data blocks bitstream

That datalink protocol (if any ) is at present unknown to me.

Back to the initial headers, I remembered having seen something similar a while back while I was analyzing Harris' serial PSK8 waveforms [1] and by demodulating their initial headers I found a correspondence between those headers and the one analyzed here: that is, a sequence of 32 bits of length which is repeated six times between sequences of initial and final "01"s (Figs. 7,8)

Fig.7

Fig.8

From the above it seems that L3Harris (and perhaps not only them) have added the "autobaud" function to some waveforms such as STANAG-4285, obviously it is only my hypothesis which has no direct or indirect confirmation: your comments and other submissions will be as usual welcome and may assist in resolving this matter.

https://drive.google.com/file/d/1WD9gBFzbGnmMdBFITTOYFf5AOTWCij4y/view?usp=sharing

(1) the “autobaud” facility enables the receiver modem to automatically adapt the transmitter’s data rate and interleaver configuration without operator intervention

[1] http://i56578-swl.blogspot.com/2021/11/harris-psk8-2400-bd-digital-voice.htm

Some comments about the German Navy STANAG-4285 fleet broadcast

updated
I noticed that in their STANAG-4285 600bps/Short fleet broadcast the German Navy use a 7-bit framing consisting of [5-bit data] + [one parity bit (even parity)] + [one pahsing bit], such framed stream is differential encoded and then forwarded to the S4285 modem.

Fig. 1 - 7-bit framing adopted in S4285 600bps/Short broadcasts

Fig. 2 - the differential decoded stream is parity bit checkd

Such peculiar framing, a "new one" for me, is used in several frequencies (see Table I) and most likely is thinked for their "domestic" fleet broadcast (as the French Navy does with their characteristic 21-bit framing); indeed in other S4285 frequencies the German-Ny run the NATO "standard" fleet broadcast consisting of the S4285 600bps/Long sub-mode and KW-46 encryption (figure 3).

Fig. 3 - KW-46 sync sequence in S4285 600bps/Long broadcasts

The 5-bit user data are most likely encrypted, the quality of the cryptography can be evaluated with a statistical method or by calculating the Shannon Entropy of a stream. The statistical test determines the randomness of the bit stream, the number of single bits in the stream is counted, then the double bits, then the triple bits and so on to the end. The result is a graph: If the information is not systematic, the adjacent columns should be half the size of the previous ones. The tes for these bit streams show good encryption quality. The measure of the Shannon Entropy can be used, in a broad sense, to detect whether data is likely to be structured or unstructured. 8 is the maximum, representing highly unstructured, 'random' data. Properly encrypted or compressed data should have an entropy of over 7.5

Fig. 4 - measurements about the presence of encryption in the 5-bit user data sub-frames

I also noticed that each 773 frames (5411-bit length blocks) a sequence of 588 bit length is inserted into the stream for a total length of 5999 bits (figures 5,6): that sequences are not repetitive, do not have a defined period, do not have a parity bit check, and do not seem  generated by a polynomial (at least in my attempts).

Fig. 5

Fig. 6

Just two coincidences:

1) in differential mode the bits after the inserts are of the same number of the inserted 7-bit frames (84)

2) as you know, the block consisting of 773 7-bit frames plus the 588 inserted bits has a length of 5999 bits that corresponds to a 10 seconds interval of a  stanag-4285 transmission at 600 bps (unless 1 bit)

 

In my opinion the 588-bit blocks are inserted before the differential encoder:

 

and they could be the "control bits" (also termed "EDAC bits", Error Detection And Correction bits) which are appended to the source bits after their comparison with a parity check matrix (1). If so, the dimension of the check sub-matrix shall be:

- (588 rows, 5411 columns) if the check is applied to [5-bit data]+[parity bit]+[phasing bit], ie to the whole 7-bit frame
- (588,4638) if the check is applied to [5-bit data]+[parity bit]
- (588,3865) if the check is applied to [5-bit data] only

 

Obviously, the possibility of such a matrix presupposes the use of a polynomial of degree 588 (!). 

But I have still some doubts. Data integrity is in some way "ensured" by the use of the parity bit and the differential encoder, moreover data are FEC encoded (rate 1/2) and interleaved by the S4285 modem, so why use a such complex CRC? It is also necessary to take into account the processing time necessary for the formation of one 588-bit block (and check it at receive side) since up to 5411 comparisons are required for each single EDAC bit (more than 3 million comparisons per block in the worst case, more than 2 million  in the better one).

 

Frequencies/modes so far monitored along with DFs of Tx sites (TDoA algorithm) are reported in this page.

 

18th June update

Discussing with my friend cryptomaster we think that the differential mode probably does not apply, indeed this "trick" of converting the phasing-bit to the parity-bit was noticed for istance some times ago when anaylzing the Chinese PSK2 2400Bd serial waveform:

https://i56578-swl.blogspot.com/2021/12/chinese-psk2-2400bd-serial-waveform.html
Repeating the tests of my friend, I took a small amount of bits from an unsystematic stream (fig. 7a) and reshaped them to a 10-bit period stream (fig. 7b), then I edited the last column by inverting some bits and turned them into a phasing bits column (fig. 1c). As a result of the differential decoding, I received a uniform parity check, except for the first combination of bits (fig. 7d).

 

Fig. 7

That said, it could be that they use a channel which is designed to work with a 7-bit framing (for istance the one used in the "standard" NATO fleet broadcast) to send 5-bit encrypted data. If so, they have to add two bits (1's) to the 5-bit encrypted data and two bits (0's) to the 5-bit framed Initialization Vectors (perhaps to distinguish them?). The 588-bit CRC (computed on 773/761 frames) instead is sent as-is. Is not clear if CRC is computed on five or seven bit frames.

 https://disk.yandex.com/d/enA0cP2fI__ePw

 

(1) As usual, code verification is carried out by comparing each line of code in turn with all the 588 rows of the check sub-matrix: the vertical correspondences of the "1s" positions in the code line and in the row #n of the check sub matrix are counted. If the matches are even then the correspondent position #n in the EDAC bits will be "1", otherwhise (ie matches are a odd number) will be "0". The values 1/0 of the EDAC bit will be the opposite in case of odd parity.

a curious STANAG-4285 transmission

Really curious STANAG-4285 transmission sent me by my friend IK1YDE Andrea who was the first to spot and analyze the signal. The oddity is that, after S4285 demodulation, the Initialization Vectors, as well as being repeated within each message, consist of the unique(!) and a bit "basic" sequence: 0x0001000100010001 (see figure below).
Actually, KG-84/KIV-7 devices use 2 x 128-bit sequences as IV and these sequences - as well as in other crypto devices - change with each new message, even if the same message is repeated (in this case 0xFFC00000000000000000000000000000).  

Fig. 1

 

Andrea heard that transmissions on 4165.6 KHz/USB, the only (Freq/Mode) match I found dates back to 2005 and refers to French-Ny FUE. No other interception in recent days, even if sporadically monitored.  No idea what this transmission is, maybe tests of new setup?

https://disk.yandex.com/d/LiEE2Jn6VCwtRg

odd 16 times expanded 5N1 framing (UK DHFCS)

Rather curious pattern transmitted by the UK DHFCS site in Crimond on 4538.0 KHz/USB, reported to me by friend Linkz, using the STANAG-4285 waveform at 1200 bps/L submode: it's about a 16 times "expanded" asynchronous 5N1 stream (112-bit length framing, as shown in figure 1):

Fig. 1 - 16x 5N1 framing (112-bit period)

The source 5N1 framing can be obtained after removing the overhead bits: this can be easily done by manually editing the demodulated bitstream, for example with BEE, or by "downsampling" the bitstream by a factor of 16 using a simple script coded - for example - in Octave (figure 2).

function [a]=downTo16(fn)
  # pkg load signal before to run the script)
  # fn = filename containing a stream of ASCII 0's and 1's w/out spaces!
  a =[];
  k =7;
  fp =fopen(fn);
  fsk =fgetl(fp);
  fclose(fp);
  bits = fsk=='1';
  y =downsample(bits,16);
  n =floor(length(y)/k);
  a =reshape(y(1:n*k),k,n)';
  dlmwrite("5N1.txt",a," ");
  imagesc(a);
endfunction

Fig. 2

After "downsampled" the bistream  (ie reduced to its "natural" 5N1 framing) and removing the initials reversals and start/stop bits, it's possible to detect the KG-84/KIV-7M sync sequence as well as the two 128-bit initialization vectors, here twice repeated (figure 3). 

Fig. 3

Now, given the adopted frame's structure and the 1200 bps speed, it turns out that the actual data rate is 1200÷16 = 75 bps (!) and therefore it matches the speed of STANAG-4481F (obviously bps=Baud in case of FSK): it's worthwhile to note that such STANAG-44881F transmissions from Crimond had already been reported [1].  

KG-84 devices talk to each other at 75 bps

I don't know why such a 112-bit pattern is used: definitely it's not an error detection and correction measure (too high ratio codeword/data, 93.75%). Judging by the bitstream, the 16x stuff sits between the crypto device and the STANAG-4285 modem, one could venture the hypothesis of  a failure of the FSK modem and its (temporary?) replacement with that workaround (1200bps is their usual STANAG-4285 speed)... but it's just a mere guess.

Fig. 4 - DF results (KiwiSDR TDoA algorithm)

https://disk.yandex.com/d/3ZAITNGcf3qs5w
(the zip file contains the wav recording, the 112-bit demodulated stream and the Octave scripts downT016.m and upTo16.m, so you can play with them. A quick howto for installing Octave is here)

[1] https://i56578-swl.blogspot.com/2021/03/async-stanag-4481f-with-kg-84kiv-7.html

8N1 async operations

8N1 async operations using STANAG-4285 and 110A Serial modems (1200bps/S, 1200bps/L respectively) recorded on 6.9 MHz band, the first likely from Turkey. After the removal of the framings, the 8-bit streams are not in clear text and therefore (off-line) encrypted.

Fig. 1 - STANAG-4285 user data

 

Fig. 2 - 110A ST user data

 

https://disk.yandex.com/d/oYXY9Rh4c9dm8Q

Echotel 1810 and STANAG-4285, ie don't blindly trust decoders

It happened by chance to analyze a complete session of data exchange in MAHRS mode (ALE + traffic) while I had a STANAG-4285 decoder in active state on the desktop: to my surprise the decoder started printing out a bitstream though - as said - it was set for STANAG-4285 (Figure 1)

Fig. 1

Intrigued by that fact, I went to see the points that S4285 and MAHRS Echotel HF modem have in common enough to confuse the decoder, other than the obvious features such as speed (2400Bd) and modulation (PSK8).  

The first thing that stands out is the equality of the ACF values, Figure 2: 106.6 ms, or 256 symbols. Thus - in my opinion - it seems that the decoder in question (Sorcerer and therefore also K500) tries to identify a signal by analyzing its ACF: probably those kind of decoders have an internal table that allows this association.  

Fig. 2 - ACF values for STANAG-4285 and Echotel serial

The structure of the frames is anyway very different, unless the first 80-symbol preamble which is common to both the waveforms (Figure 3): S-4285 framing consists of an initial 80 symbol preamble followed by 4x32-symbols data segments and 3x16-symbol probes; Echotel framing consists of the initial 80 symbol preamble that is followed by a data block consisting of 176 data symbols. 

Fig. 3 - framing structure for STANAG-4285 and Echotel

As third common feature, both the 80-symbol preambles are modulated using BPSK: the pronounced BPSK states in the constellation plane of the Echotel 1810 signal are quite eloquent (Figure 4)

Fig. 4

STANAG-4285 is not an autobaud waveform so the decoding is based on the user settings, just for fun I played with some sub-modes even if - as obvious - the decoder can't find the expected known symbols (16-symbol probes). The best results, in terms of "confidence", were obtained by setting the bit rate to 2400 bps, obviously the corrections are equal to zero in the uncoded mode:

It must be said that this Echotel 1810 waveform is not the only S4285-like waveform, another example is the 2400Bd PSK-8 serial waveform from the THALES TRC-1752 modem (Thales Système 3000 family), although the latter is more properly defined as "variant".

Fig. 5 - THALES TRC-1752 STANAG-4285 variant

 

At the end, do not blindly trust decoders: they are not infallible and there is no magic wand; just open your wav files and analyze them.

STANAG-4285 async 1200bps test transmissions from Turkey

For about a week I monitored STANAG-4285 1200bps async transmissions heard on several frequencies in the 6 MHz band according to Table I; after April 23th the transmissions have stopped (at least in the 6 MHz band and until today). About the used frequencies, I have not found any match either in the UDXF group logs database or in other resources on the web.

Table I

The transmissions take place with a cycle of about 2 minutes and 25 seconds and seem to use a kind of "call/reply" mode between two stations a,b (since the different strength of the signals); don't know who's the caller and who's the called, but I noticed different patterns depending on the monitored day, as for example in Fig. 1

Fig. 1

The use of two frequencies was also observed (Fig. 2). Obviously it is automated transmissions or controlled by software. Messages, net of 32 bits each for SOM & EOM, have the same length each day, e.g. 8832/5760 bits (caller/called); user-data are encrypted and then transmitted using the 8N1 framing (Fig. 2). Note that the Turkish S-4285 async transmissions I have met so far used the 5N1.5 framing.

Fig. 2 - (the different durations of the signals on the left depend on the waterfall rate that has been selected)

As from Table I, the STANAG-4285 submode 1200bps/L was used from April 15th to April 19th, then the submode 1200bps/S was used.

The direction finding (TDoA) results indicate an area of southern Turkey as a possible transmitter site (Fig. 3); results may be a bit incorrect since the short durations of the signals, anyway it's quite credible. Such a location, along with the transmission schedule and with the encryption algorithm, allows for some observations and comments.

Fig. 3

As seen, the contents of the messages are encrypted but the encryption algorithm does not correspond to the known ones such as KG-84/BID and KW-46/KIV-7 therefore the use of a "national algorithm" can be assumed. TÜBİTAK (Technological Research Council of Turkey) National Electronic and Cryptology Research Institute (UEKAE) developed secure communication solutions in terms of cryptographic algorithms, protocols, and architecture as well as data encryption devices such as the MİLON family (MİLON-4A was also approved by NATO) [1] [2]. It is reasonable to think that these transmissions, as well as other encrypted transmissions from Turkish Armed Forces which are reported in this blog, use such encryption systems.

Fig. 4 - some encryption devices by TUBITAK
(https://bilgem.tubitak.gov.tr/.../corporate_presentation_v7-2019.04.09.pdf)

The way these transmissions are conducted suggests that they are tests. STANAG-4285 is now a consolidated and widely used waveform and therefore the tests could concern the installation of a new HF system (maybe a MRL system?). There is also another somewhat "suggestive" hypothesis: on-field tests of a SCA-based 4285 waveform on proprietary advanced SDR transceivers. Indeed, TUBITAK UEKAE ported two different waveforms to the Spectrum's flexComm SDR-4000 for demonstration to the Turkish Ministry of Defense: an implementation of STANAG-4285 for high frequency (HF) radio links and APCO Project 25 (P25) for public safety links [3].

https://yadi.sk/d/wpMhMwaNpa9NXg
https://yadi.sk/d/OnFVfIPiiBbwlA

[1] https://www.hurriyet.com.tr/gundem/natonun-kripto-cihazlari-tubitaktan-9191151
[2] https://bilgem.tubitak.gov.tr/.../corporate_presentation_v7-2019.04.09.pdf
[3] https://pdfs.semanticscholar.org/

COMSEC transmissions using a S4285 variant (2)

Secured burst transmission using a modified S4285 waveform [1] spotted around midnight on 4015 KHz/usb, the S4285 mode is 600bps and short interleaver. 

Fig. 1

After demodulation, the COMSEC preamble resembles 188-220D std and consists of 3 parts (my guess):

1) 60-bit Frame Sync (110000100000111000101111001011011101101001001011111010101100)
2) 5 x 128-bit strings, encoded Message Indicator (five times repeated)
3) 64-bit idling sequence (time to load the key?)

Preamble is followed by the encrypted data block which ends with "01" sequences.

 

Fig. 2 - demodulated stream of bursts

Fig. 3 - COMSEC preamble (my guess)

https://yadi.sk/d/nY-DTuTz-ZWG8g  (2020-01-10T005300Z, 4.015 MHz, USB.wav)
https://yadi.sk/d/oIHVEWbUO0_few   (2020-01-10T010336Z, 4.015 MHz, USB.bin)

[1] The same modified S4285 waveform was met here on 6931 KHz/usb:
http://i56578-swl.blogspot.com/2018/06/comsec-transmissions-using-s4285.html 

Indian Navy STANAG-4285 naval broadcasts (tentative)

Follwing a tip from my friend KarapuZ and his recent tweet, I started to monitor 16941.0 KHz to study the STANAG-4285 naval broadcasts from the Indian Navy [1]. They use the quite rare 2400bps/Long sub-mode and decoding produces a lot of errors just due to the high data rate and the huge QSB that sometimes affects the signals. By the way, I used the KiwiSDRs VU Hams located in Kottarakkara Kerala and colombo4s7vk located in Colombo Sri Lanka, the latter is a bit less recommendable.

Fig. 1 - one of the S4285 2400/L heard broadcasts

For what I could see, daily broadcasts starting around 1100 or 1200 Z are transmitted on that frequency. Broadcasts consist of clear-text weather bulletins and 4FG messages to VWGZ (VWGZ is the collective callsign for any/all the Indian Navy ships): indeed, they typically use a four FIG (off-line) encryption system. Either the bulletins and 4FG messages, are sent using the async ITA2 8N1 framing (Figs. 2, 3). 

Fig. 2- 8N1 bitstream after decoding

Fig. 3 - off-line decoding using Harris RF-5710A modem

It is interesting to take a look at some bulletin/message typical contents.

VWGZ
VND 677/16
ECHO BRAVO ZULU
ALPHA KILO UNIFORM
OSCAR KILO NOVEMBER
PAPA ECHO HOTEL
ROMEO QUEBEC XRAY
INDIA INDIA HOTEL
LIMA CHARLIE PAPA
DELTA HOTEL KILO
-P- 160732
GR 158
BT
ZERO ZERO ZERO EIGHT ALFA TWO TWO FOUR EIGHT 9838
6469 5315 6155 6433 5098 8353 7507 5237 5375 4271
...
8394 6708 1257 6554 6238 5987 3600 6023 9076 1083
4574 3021 1116 0342 6063 4300 2248 0008ALFA
BT
GR 158
NNNN
AAAAFIN0M0N9O8P7Q6R5S4T3U2V1
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
**************************************************
A1B2C3D4E5F6G7H8I9J0

where:

VWGZ 
collective callsign for any/all Indian Navy ships

VND 677/16 
indicates the daily serial number of the message in that broadcast, i.e. message #677 of day 16 (indeed 16 november, date of my reception). Don't know what VND stands for.

ECHO BRAVO ZULU 
ALPHA KILO UNIFORM
...
most likely the daily encrypted callsigns for specific ships

-P-
precedence indicator of the message
-R- Routine
-P- Priority
-O- Immediate (Operational Immediate)
-Z- Flash  

160732
date time of origination, no time zone indicator (!)

GR 158
the number of 4FG in the message (158 in this case)

BT
separation (break), as the usual Morse Code abbreviation 

The 4FG block is always preceeded by a 9 chars string, i.e.: 

ONE NINE NINE TWO ALFA NINE SEVEN TWO FOUR 

I noted that this string is used to "signal" the last two 4FG in the block, respectively the last and the second-to-last:
 
ONE NINE NINE TWO ALFA NINE SEVEN TWO FOUR 9072
2299 4827 3953 0701 6748 2577 4084 8109 5655 4999
...
5904 4854 4358 8628 9964 9687 9032 0282 4140 7567
5029 5582 1302 9724 1992ALFA
;
ZERO ZERO ZERO EIGHT ALFA TWO TWO FOUR EIGHT 9838
6469 5315 6155 6433 5098 8353 7507 5237 5375 4271
...
8394 6708 1257 6554 6238 5987 3600 6023 9076 1083
4574 3021 1116 0342 6063 4300 2248 0008ALFA
;
ZERO THREE NINE NINE ALFA ZERO SIX FIVE NINE 7346
0822 9678 3021 3357 0524 0160 9645 0013 4927 1959
...
5457 3192 3301 5013 5856 9799 0272 2857 8727 9046
1854 5256 7000 0659 0399ALFA

The 4FG blocks usually end with the separation char (BT) folowed by the repetition of the number of encrypted groups in the message (GR nnn), the usual RTTY end-of-message (NNNN) and the strings: 

AAAAFIN0M0N9O8P7Q6R5S4T3U2V1
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
**************************************************
A1B2C3D4E5F6G7H8I9J0

at present I do not know their scope/meaning, maybe test chars, but it makes some sense if they are read respectively as couples [0;1][M;V]:

AAAA
FIN (=finish ?)
0M
0N
9O
8P
7Q
6R
5S
4T
3U
2V
1

and [A;J][1;0]:

A1
B2
C3
D4
E5
F6
G7
H8
I9
J0 

It's worth noting that  in each transmission the most recent message is sent as first (a kind of LIFO). Moreover, some of the messages that were sent in the previous broadcast are re-inserted in the current one, i.e. the broadcast of 1304 Z contains the last message (#679) and the twos (#678 and #677) sent in the previous broadcast of 1255 Z
 
[2019-11-16 1152Z]
VND 677/16
VND 676/16
VND 675/16
VND 674/16

[2019-11-16 1255Z]
VND 678/16
VND 677/16
VND 676/16

[2019-11-16 1304Z]
VND 679/16
VND 678/16
VND 677/16  

Probably this method is used to improve the reliability of the system but it is not clear to me how the number of messages to be repeated is determined (precedence? duration?).

Sometimes it's possible to see short messages as:

VWGZ
VND 675/16
ZFA
VTH DE GOLF YANKEE
-O-
LIMA ROMEO MIKE
FOXTROT KILO NOVEMBER
160801
ZBQ 0805
BT
NNNN

VTH is listed as the callsign of Indian Navy Mumbai.
Note the Z codes ZFA (Following message has been received) and ZBQ (Message was received at).

Weather bulletins report Weather, Surface Wind, Visibility, Sea State, Swell, and Warnings for specific areas and period of validity (12 hours). The bulletins header indicates the originator of the message just after the precedence indicator: 

-P-  150320
FROM FOCINC EAST
TO   ALL CONCERNED

-R-  141004Z
FROM NAVAREA VIII CO-ORDINATOR
TO   NAVAREA VIII

-P-  160900
FROM CINCAN
TO   ALL CONCERNED

where:

FOCINC EAST: Flag Officer Commanding-in-Chief Eastern Naval Command. The Indian Navy operates three operational Commands, each headed by a Flag Officer Commanding-in-Chief (FOCINC): FOCINC East (Visakhapatnam HQ), FOCINC West (Mumbai HQ), FOCINC South (Kochi HQ).

NAVAREA VIII CO-ORDINATOR: the Chief Hydrographer to the Government of India.

CINCAN: Commander-in-Chief of the Andaman & Nicobar Command. The Andaman and Nicobar Command is the first and only Tri-service (army, navy, air force) theater command of the Indian Armed Forces.

Since some of the weather bulletins also report detailed "LOCAL WEATHER FORECAST FOR VISAKHAPATNAM", probably the broadcasts are transmitted from a COMCEN belonging to the Eastern Naval Command (ENC) HQ in Visakhapatnam [2]. In this respect it's noted that some logs in old WUN/UTNL newletters report "VTP Visakhapatnam" as Indian Navy station operating in CW and RTTY 50Bd/850, but not on 16941 KHz. Actually, I didn't find any "official" allocation for 16941.0 KHz but only a clue related to one of the frequecies that are used for HF communications in the Indian activities in Antarctica (IAP, Indian Antarctic Programme) [3].
Given the period of validity (12 hours, except for the forecast for Visakhapatnam which have 24 hours validity) it makes sense to expect similar broadcasts around 0000Z, likely on a lower HF band.

(to be continued)

kiwisdr.vuhams.net_2019-11-16T12_55_40Z_16941.00_usb.wav 

[1] https://en.wikipedia.org/wiki/Indian_Navy
[2] https://www.indiannavy.nic.in/node/1399#
[3] inpre07e.doc