Quantcast
Channel: diario SWL I-56578 Antonio
Viewing all 623 articles
Browse latest View live
↧

STANAG-4539 in multichannel mode: Thales HF XL modem (likely "SALAMANDRE" tests)

June 10, 2017, 5:42 am
$
0
0

This system has been copied on 9 different simultaneous channels from ~6200 to ~6400 KHz on USB during 9 June morning. The analysis reveals it's a STANAG-4539 modem (frame length is 287 PSK-8 symbols) running at different data signaling rates at constant 2400Bd data rate. The system uses bursts and (possibly) ARQ mode. My friend KarapuZ too copied this system but on a different HF segment.

Fig. 1
Fig. 2

The decisive contribution for the identification of the signal came from my friend ANgazu: he suggested that these transmissions could be the Thales HFXL modem, since they use up to 16 narrowband channels in 200 Khz bw just using 4539 waveforms. Most likely, the heard transmissions are tests related to the Thales /French MOD contract: PEA "SALAMANDRE".

Indeed, as depicted in Thales presentation of the HFXL modem:
they uses an evolution from the SANAG-4539 frame structure, mainly differing in the preamble parts as shown in Figure 3 

Fig. 3
Other than the long miniproble (32 symbols length rather than 31), they added a third 124 PSK-8 symbols part (termed "Extended") to the S-4539 initial synchronization preamble. The data block length (256 symbols) and the mini probe length (31 symbols) remain unchanged so that the period counts 287 symbols as in S-4539 (Figure 2).
The extended synchronization preamble is specific to  HF XL.  This part, not included when operating according to S-4539 or MS 188-110C ISB modes, is combined with the main preamble to carry all  information  necessary  to  the  HF XL  waveform, in particular information on modulation choice for each channel. Furthermore, a specific redundancy capability is introduced, that ensures resilience to the loss of a channel as long as the number of channels is greater or equal to 3.

A deeper look at the preamble of one heard transmission confirms the Thales HF XL modem, as depicted in Figures 4,5

Fig. 4 - the whole preamble
Fig. 5 - the 124 symbols (51.6 msec) added by Thales
As further confirm, ANgazu measured the parts of the preamble (Fig. 6) and time durations fit perfectly:

Fig. 6 - parts durations in HF XL preamble
A: syncronization preamble (76 ms)
B: initial sync 287 symbols (b1 of 184 and b2 of 103 symbols)
C: extended Thales preamble (124 symbols)


The adaptive wideband HF waveform termed “HF XL” relies on the usage of several non-contiguous 3 kHz channels spread over a 200 kHz wide sub-band.

Fig. 7
Expanding on the high performance of the serial tone modem technology standardized in STANAG 4539 for 3 kHz sideband to conjugate a plurality of channels in a multi narrow band (MNB) waveform, this approach can be seen as an extension of the US MIL-STD-188-110C appendix F “ISB”, with the addition of specific redundancy capabilities to provide resistance to the highly variable HF channel conditions.  As illustrated in Figure 7, these channels do not need to be contiguous, which allows to select only good quality and authorized channels.
A 4G ALE alternate proposte ?

Thanks to ANgazu for the identification and collaboration.

Links:
https://events.thalesgroup.com/euronaval/en/article/778731/SALAMANDRE-HF-with-wideband-capability 
http://www.hfindustry.com/meetings_presentations/presentation_materials/2014_feb_hfia/presentations/8-HFIAfeb2014ThalesXLALEfinal.pdf 
http://www.hfindustry.com/meetings_presentations/presentation_materials/2013_jan_hfia/presentations/8-HFIA_HF_modemXL.pdf 
http://lamyc.free.fr/publications/NORDICHF2013_1.pdf 


https://yadi.sk/d/iS9KPa-h3Jybxq

↧
Search

(not such) logs

June 13, 2017, 1:41 am
$
0
0
06303.0: ---: Unid 1959 USB 3G-HF 2-way FLSU handshake followed by LDL32 transfer(09Jun17) (AAI)
06363.2: ---: Unid prob French Navy 0550 USB THALES HF XL modem, likely "SALAMANDRE" tests (09Jun17) (AAI)
06909.0: ABC7: Croatian Military, HRV 0737  USB MIL 188-141A call ABG6 (06Jun17) (AAI)
07401.0: ZBOR: German customs Patrol vessel Borkum, D 0732 USB MIL 188-141A call BMEK (29May17) (AAI)
07498.5: ---: Unid 0600 USB STANAG-4197 modem (31May17) (AAI)
07500.0: AI1: Polish Military, POL 1030 USB MIL 188-141A call SZ1 (28May17) (AAI)
07559.0: ---: Unid 0731 USB 3G-HF Circuit Mode in MIL 188-110A Serial (29May17) (AAI)
07559.0: ---: Unid 0800 USB 3G-HF 2-way FLSU handshake followed by HDL+ transfer (29May17) (AAI)
07628.0: A98: Unid Chinese net, C 2108 USB MIL 188-141A handshake D78 (07Jun17) (AAI)
07630.0: ---: Unid 0618 3G-HF 2-way FLSU handshake followed by LDL352 transfer, sending 675-byte Citadel encrypted data (07Jun17) (AAI)
07651.0: ---: Unid 0403 USB 3G-HF FLSU failure (02Jun17) (AAI)
07712.0: ---: Unid 0407 USB 3G-HF 2-way FLSU handshake followed by HDL12 transfer (02Jun17) (AAI)
07745.0: TBB: Turkish Navy, TUR 0617 STANAG-4285 600bps/L CARBs "//TBB040I(0)/TBB041I(0)/TBB044I(0)/TBB042I(0)/TBB043I(0)/TBB047I(0)/TBB045I(0)/TBB046I(0)/TBB048I(0)/TBB049I(0)/TBB050I(0)//" (31May17) (AAI)
07756.0: ---: Unid NATO stn 0707 ISB LINK-11 SLEW modem (29May17) (AAI)
07761.0: 6007: Unid 2024 USB MIL 188-141A sounding (09Jun17) (AAI)
07788.0: ---: Unid 0823 USB R&S GM2100 modem (06Jun17) (AAI)
07793.0: ---: Unid 0615 USB 3G-HF Circuit Mode in MIL 188-110A Serial (31May17) (AAI)
07803.0: ---: Unid French Forces stn, F 0653 (cf) ARQ-E 184.6Bd/388 modem (29May17) (AAI)
07813.0: J62 Moroccan Military, MRC 0600 USB USB MIL 188-141A sounding (06Jun17) (AAI)
07814.0: ---: Unid 0609 USB 3G-HF Circuit Mode in MIL 188-110A Serial (31May17) (AAI)
07860.0: PC21: Unid (Algerian Military?) 0612 USB MIL 188-141A call NX20 (31May17) (AAI)
07898.0: 049112: German Red Cross, D 2113 USB MIL 188-141A sounding (07Jun17) (AAI)
07899.0: XS72: Unid 0627 USB MIL 188-141A handshake NX40 followed by unid vocoder (06Jun17) (AAI)
07930.0: ---: Unid 0413 USB 3G-HF 2-way FLSU handshake followed by HDL12 transfer (02Jun17) (AAI)
08000.0: ---: Russian Military, RUS 0747 USB CIS-Makhovik BPSK 1200Bd before CIS-12 (31May17) (AAI)
08005.0: 920: Unid 2103 USB MIL 188-141A sounding (07Jun17) (AAI)
08023.0: BX80: Unid 0713 USB MIL 188-141A call NX80 (03Jun17) (AAI)
08072.0: PEM01D: French Navy, F 0645 USB MIL 188-141A call PEM05D (07Jun17) (AAI)
08151.0: TYMT2: Spanish Police Toledo, E 0628 USB USB MIL 188-141A sounding (07Jun17) (AAI)
08162.0: 035: Hungarian Army, HNG 0712 USB MIL 188-141A handshake 082, female voice comms followed by unid vocoder (10Jun17) (AAI)
08163.0: ---: Unid 0339 USB 3G-HF FLSU failure (02Jun17) (AAI)
08182.0: XGL: Unid UK-DHFCS node 0811 USB MIL 188-141A call XSS (29May17) (AAI)
08218.0: ---: Unid 0614 USB 3G-HF 2-way FLSU handshake followed by HDL12 transfer (06Jun17) (AAI)
08297.0: ---: Portuguese Air Force, POR 0742 USB STANAG-4197 (03Jun17) (AAI)
08297.0: ---: Portuguese Air Force, POR 1205 USB STANAG-4197 16-tone library only (02Jun17) (AAI)
08327.0: ---: Unid 2016 USB 3G-HF 2-way FLSU handshake followed by HDL24 transfer (09Jun17) (AAI)
08906.0: ---: Santa Maria, AZR 1953 J3E/USB wkg 9364ER (09Jun17) (AAI)
09018.3: NAVY1: Iraqi Navy HQ, IRQ 1754 USB MIL 188-141A call P103 (10Jun17) (AAI)
09018.3: P102: Iraqi Navy Patrol Boat P103, IRQ 1741 USB MIL 188-141A call NAVY2 Iraqi Navy HQ (10Jun17) (AAI)
09019.0: 220208: GBR-RAF A/c C17A 1730 USB MIL 188-141A call [?] CMD AMD [TAZ RRR6395 REQ TAF EGVN]
"to XSS (TAZ) de RAF flight 6395, request weather for Brize Norton, UK (EGVN)" (10Jun17) (AAI)
09025.0: 220208: GBR-RAF A/c C17A 1727 USB MIL 188-141A call XSS (10Jun17) (AAI)
09272.5: ---: Unid French Forces stn, F 1155 (cf) ARQ-E 184.6Bd/388 modem (29May17) (AAI)
10035.0: K36: Israeli Air Force, ISR 1356 USB MIL 188-141A call AA2 (28May17) (AAI)
10211.6: ---: Polish Intel, POL 0700 FSK 100Bd/620, 96-bit ACF (26May17) (AAI)
10590.5: ---: Swedish Armed Forces, S 0831 3G-HF Circuit Mode in MIL 188-110A Serial carrying STANAG-5066 data (31May17) (AAI)
10627.0: ---: Unid 0740 3G-HF 2-way FLSU handshake followed by HDL3 transfer (30May17) (AAI)
10638.0: EK9: Greek Military, GRC 0848 USB MIL 188-141A call GEF (29May17) (AAI)
10642.0: AC4: Unid 1730 USB MIL 188-141A call DD3 (29May17) (AAI)
10750.0: HQ4: Unid (presumed Egyptian net)1534 USB MIL 188-141A handshake GANOB5 followed by CLOVER-2000 modem and voice comms in Arabic (29May17) (AAI)
10820.0: ---: Unid 1744 USB 3G-HF Asynchronous FLSU call (29May17) (AAI)
10947.0: CAIRADIO: Unid 1504 USB MIL 188-141A sounding, also on 11300.0 KHz/USB (29May17) (AAI)
10960.0: HWK01: Swedish Armed Forces, S 1124 3G-HF Circuit Mode, MIL 188-110A carrying STANAG-5066 as bearer for unid MMHS (06Jun17) (AAI)
10975.0: 1SR: NATO BALTOPS-2017 Exercise 0650 USB MIL 188-141A call BRO (06Jun17) (AAI)
10994.2: HWK01: Swedish Armed Forces, S 1036 3G-HF Circuit Mode, MIL 188-110A carrying STANAG-5066 as bearer for unid MMHS (06Jun17) (AAI)
11022.0: ---: Israeli Navy 0710 ISRNy-HYBRID Parallel/Serial modem (06Jun17) (AAI)
11050.0: SK1: Unid (Egyptian net ?) 1343 USB MIL 188-141A call SZ1 (30May17) (AAI)
11050.0: SK1: Unid (Egyptian net ?) 1348 USB MIL 188-141A handshake SV1 followed by MIL 188-110A Serial (30May17) (AAI)
11050.0: SK1: Unid (Egyptian net ?) 1354 USB MIL 188-141A handshake XV1 followed by MIL 188-110A Serial (30May17) (AAI)
11112.0: CLC: Unid 1020 USB MIL 188-141A call CLB (11Jun17) (AAI)09018.3: BOT: Iraqi Navy HQ, IRQ 1844 USB MIL 188-141A call P104 (10Jun17) (AAI)
11112.0: CLC: Unid 1045 USB MIL 188-141A call HIC (11Jun17) (AAI)
11112.0: CLC: Unid 1232 USB MIL 188-141A call VIK (11Jun17) (AAI)
11114.5: ---: Unid 0647 USB ARCOTEL MAHRS 2400Bd serial modem (06Jun17) (AAI)
11215.0: 400001: Unid Mauretanian net, MRT 1944 USB MIL 188-141A sounding (09Jun17) (AAI)
11215.0: 400013: Unid Mauretanian Net, MTN 1750 USB MIL 188-141A call 400001 (29May17) (AAI)
11217.0: UKE303: RAF E-3 Awacs 1504 USB MIL 188-141A sounding (30May17) (AAI)
11430.0: ---: Unid 1743 USB 3G-HF 2-way FLSU handshake followed by HDL+ transfer (29May17) (AAI)
12386.0: ---: Unid 1416 Unid BPSK 62.5Bd (BPSK63 HAM) modem, encrypted msg (28May17) (AAI)
13077.1: ---: Unid USB STANAG-4285 600bps/L modem, KG-84 encrypted messages (02Jun17) (AAI)
↧
↧

unid STANAG-5066 RCOP/UDOP client, Swedish Army "C2" integrator? (tentative)

June 16, 2017, 2:47 am
$
0
0

As said in the previous post, in all the monitored transmissions the chosen 3G-HF service is the Circuit Mode, and 1200 bps MIL 188-110A is the used traffic waveform. Data are transferred by STANAG-5066 D_PDUs and both the RCOP (Reliable Connection Oriented Protocol) and UDOP (Unreliable Datagram Oriented Protocol) are used as basic end-to-end transport protocols, but so far the client protocol which run over S-5066 has not been yet identified. Me and my friend Johannes started to analyze these transmissions since several days and below are exposed the tentative results in order to get comments from out there, further posts will follow.

Figure 1 shows two bitstreams after MS-110A removal and after synced on 0xEB90 (S-5066 D_PDU synchronisation sequence): in this cases all the D_PDUs are of type 7 (non-ARQ delivery) and 0 (Simplex data transfer) and carry UDOP and RCOP protocol.

Fig. 1
It's interesting to note in Fig. 2 the initial same structures which are present in all the recordered copies, in both RCOP and UDOP data, after the removal of D_PDU encapsulation
 
Fig. 2
 Let's have a look at ASCII rapresentations of a series of decoded transmissions (Fig. 3):

Fig. 3

Data are structured as a series of headers having the format {<length>,<content>}:

{5,HWK01}{3,PFY}{3,001}{3,001}{10,1570853327}{0}{143,...}{0}
{5,HWK01}{3,ZHO}{3,001}{3,001}{10,2096500086}{0}{625,...}{0}
{5,HWK01}{3,ZHO}{3,001}{3,001}{10,2097463403}{0}{937,...}{0}
...
...

A possible explanation could be:

{5,HWK01}{3,PFY}
source and destination IDs

{3,001}
number of the current data-block (see later)

{3,001}
total number of data-blocks (see later)

{10,1570853327}
most likely a timestamp (see later)

{0}
unknown. So far, never seen something different at this position, probably marks the start of a data block (SOF).

{143,data-block}
number of bytes followed by data.

{0}
unknown. So far, never seen something different at this position, probably marks the end of a data block (EOF).

The particular format of the headers {<length>,<content>} leads to think to a wrapper protocol that acts as a mediator/integrator between two systems (eg X.400 and ACP127 networks, although STANAG-4006 performs that task).

By the way,"The Sweidish Army uses C2 systems that are not interoperable and data must be manually transferred between them. Sweden began to integrate all the service's C2 systems, at all levels, in 2005 under the name SWECCIS. [...] Swedish Armed Forces HQ tasked FOA, FMV and FHS to propose a vision for a mobile military joint C2 system for 2010, this project has been expanded to include civilian C2 elements [...] the goal is a single C2 environment..."[1].
But it's only a supposition(!), although some clues come also from this picture [2]



For what concerns the timestamp header, it seems related to the "wrapped" data file. By examining consecutive transmissions, the granularity is in milliseconds and the Epoch Time started on Sat May 13 2017 00:00 CEST (GMT +2): possibly the date on which this "service" came into production?

Looking at Figure 4, if the data-block length is greather than 1977 bytes then it is segmented into smaller blocks, each block consisting of the same {<length>,<content>} headers. In this case, the 'timestamp' header remains unchanged while the 'current data-block' header is updated. Note also that the data-blocks are not filled if their length is less than 1977 bytes. 

Fig. 4
Protocol data are transferred in PDUs of 200 bytes length, and in case of UDOP the bitstream just exhibits a strong 1600-bit ACF. Well, looking at the hex rapresentation of an UDOP bitstream (Figs. 5a, 5b) we see that PDUs are sent twice, unless the last PDU and the first PDU of the successives 1977-byte blocks. This makes sense to improve the reliability, since the nature of UDOP protocol itself (it's a basic connection-less protocol) and the use of S-5066 non-ARQ service.

Fig. 5-a
Fig. 5b
A not clear point is the presence of the number 8008 in all the records (Fig. 6) just before the headers elements. Maybe a TCP/UDP port? if so, it's the HTTP alternate port (IANA).

Fig. 8
For what concerns the nature of the data-blocks, since the {<length>,<content>} headers  are in plain-text, the encryption if any is performed upstream before this protocol.
A termed here "magic string", in the form  ZLLLL (ie "Z" followed by 4 uppercase letters), appears in the first 40 bytes of the data-block and it is always preceeded by the 34-byte sequence 0x7E0862...61D5EE20 (Fig. 7). In case of a multi-blocks transfer the magic string is present only in the first block ( Fig. 4). So far, the seen values are: empty, ZXPBC, ZXPBD, ZRTBC, and ZRTBD. This is another unclear point and needs further observations.

Fig. 7
The data obtained after the removal of the headers do not exhibit particular structures or recognizable patterns, unless the firts 40 bytes followed by the magic string. 

For what concerns the HF network, they have tens(!) of channels. Anyway, at least from a monitoring by Johannes, each channel is always used with the same RCOP/UDOP protocol.
So far, matching S-5066 addresses and src/dest headers we got:

[006.046.000.zzz] block
HWK01   006.046.000.028, 006.046.000.102
ZMK002  006.046.000.037

[006.046.001.zzz] block
DWY  006.046.001.009
PFY    006.046.001.010
ZHO   006.046.001.028
RJY    006.046.001.029
GZL   006.046.001.030
HEH,HEH002  006.046.001.34
CAU   006.046.001.046

In the vast majority of the cases (almost 99%) traffic is originated from 006.046.000.zzz block nodes (HWK01,ZMK002) to 006.046.001.zzz block nodes. Very few traffic in the reverse direction. Maybe 006.046.000.zzz block is assigned to the main (strategic?) nodes of the net?
Anyway, it's interesting to note that in some transmissions the same ID "HWK01" appear in both the src and dest blocks, although with different S-5066 addresses (anyway belonging to the same block 006.046.000.zzz):

Fig. 8
where:
{5,HWK01}{5,HWK01} have the S-5066 addresses 006.046.000.102 and 006.046.000.028

Perhaps two possible reasons:
a) the ID HWK01 acts like a sort of ZIP-code or global-ID with different users/services, each with a distinct S-5066 Address 
b) these are two physical instances. As shown in [2] they have separated Rx and Tx stations. Maybe this is a information transfer from one Tx to its corresponding Rx station which logically share the same ID.

Helps, comments and recordings are welcome!
(to be continued) 

Links:


↧

THALES HFXL modem, "SALAMANDRE" tests go on

June 21, 2017, 7:30 am
$
0
0
Likely another "SALAMANDRE" test session for the new Thales HFXL modem spotted this morning on the 7MHz band. This time the modem uses 12 non-contiguous 3 kHz channels from 7505.8 KHz up to 7656.1 KHz (~150 KHz bandwidth). The HF waveform is a modified STANAG-4539 with the extended preamble of 124 symbols added by Thales developers; further info about the modified waveform and the modem, as well as useful links, can be read in this post.

Fig. 1
It's interesting to note in Figure 2 the use of a double 188-141A 2G link setup exchange before the beginning of the HFXL session: the ALE exchanges happen just on the first and last channel of the next HFXL transmission as to negotiate/announce the used band; anyway, the HFXL session starts after the usual 2G 3-way handshake (as in Fig. 1). This initial link setup part is termed by Thales as the "3KHz phase" and it is illustrated in one of theirpresentations. 
By the way, the used ALE calls are XLA and XLB and almost surely they stand for (HF)XL modem-A and modem-B and belongs to French Forces network.

Fig. 2
The HFXL modem 12 channels have been tracked using SDR-Console v3 software configured for twelve simultaneous receivers, in this sample all the channels exhibit a PSK-8 modulation at 2400 symbols/sec (Figs. 3,4): the channel #4 is damaged by an adiacente FSK-2 transmission.

Fig. 3
Fig. 4

↧

the beauty of grayline

June 23, 2017, 1:02 am
$
0
0
188-141A calls copied this morning around 0455 UTC on 11111.0 KHz/USB (Fig. 1). The ALE addresses  belongs to the French Navy naval bases at overseas departments and territories Papeete and Noumea:
1OMFUM French Navy OMAR Net, Papeete OCE
1OMFUJ French Navy OMAR Net, Noumea NC
more than 16000 Km far from my antenna: reception has been possible thanks to a grayline-path (Fig. 2).

Fig. 1 - decoding
Fig. 2 - the grayline at the reception time
Garyline observations and predictions can be read at the VOACAP (Voice of America Coverage Analysis Program) site:
http://www.voacap.com/p2p/index.html
as well as a lot of interesting and accurate services about about HF propagation:
http://www.voacap.com/ 

French Navy OMAR (Organisation MARitime des transmissions haute fréquence) HF New-Generation program have the task to modernize all the High-Frequency transmissions media of about 80 assets of the Ocean forces of the French Navy, maintaining interoperability with other NATO Navy. The project was committed to Thomson-CSF (now THALES):

↧
↧

Logs

July 1, 2017, 1:30 am
$
0
0
08195.0: BU4: Roumenian Police Bucuresti #4, ROU 0624 USB MIL 188-141A handshake 1PY followed by MIL 188-110A (30Jun17) (AAI)
07665.0: ---: Unid 0605 USB 3G-HF FLSU 2-way handshake followed by LDL128 transfer of 451 bytes Citadel encrypted msg (30Jun17) (AAI)
11421.0: ---: Unid prob. V22 Chinese Intel/Diplo 1520 BPSK 62.5 Bd, 9-bit ACF (29Jun17) (AAI)
06358.5: XSA: GBR-DHFCS, U 1517 USB MIL 188-141A sounding (29Jun17) (AAI)
08303.0: IDR: Italian Navy S.Rosa Rome, I 0824 J3E/USB working ASV, STANAG-4285 600bps/L KG-84 encrypton (29Jun17) (AAI)
07561.5: ---: Unid 0809 USB USB MIL 188-141A handshake in Linking Protection mode followed by MIL 188-110A (29Jun17) (AAI)
07559.0: ---: Unid 0715 USB 3G-HF FLSU 2-way handshake followed by LDL320 transfer of 591 bytes Citadel encrypted msg (29Jun17) (AAI)
07840.0: RD21: Algerian Military, ALG 0623 USB MIL 188-141A call NX20 (29Jun17) (AAI)
11130.0: X44: Moroccan Army, MRC 0535 USB MIL 188-141A sounding (29Jun17) (AAI)
08025.0: 1PYC3: Roumenian Police, ROU 0630 USB MIL 188-141A call GALc3 (28Jun17) (AAI)
07899.0: XS72: Unid 0610 USB MIL 188-141A call XN40 (28Jun17) (AAI)
07899.0: XS72: Unid 0556 USB MIL 188-141A handshake XS69 followed by unid vocoder/scrambler (28Jun17) (AAI)
11050.0: AI1: Unid 0845 USB MIL 188-141A call RE1 (25Jun17) (AAI)
11050.0: AI1: Unid 0842 USB MIL 188-141A call RF1 (25Jun17) (AAI)
10958.0: ---: Unid 1359 USB 3G-HF 1-way FLSU request followed by MDL/LDL288 transfer of 563 Citadel encrypted msg (24Jun17) (AAI)
11050.0: AI1: Unid 1313 USB MIL 188-141A handshake XV1 followed by MIL 188-110A serial (23Jun17) (AAI)
11250.0: MATHILDE: Unid French Air Force asset, F 0935 USB MIL 188-141A LQA Exchange w/EVI same QRGs as 0935 log (23Jun17) (AAI)
11250.0: EVI: French Air Force Istres, F 0935 USB MIL 188-141A call MATHILDE, repeated on 11187,11214, 11217, 11235,11250, and 11253. -80dB in JN52 (23Jun17) (AAI)
08218.0: ---: Unid 0716 USB 3G-HF 2-way FLSU handshake followed by LDL32 transfer of 139 Citadel encrypted msg (23Jun17) (AAI)
08350.0: ---: Unid 0711 USB 3G-HF 2-way FLSU LQA exchange (23Jun17) (AAI)
06255.7: HWK01: Swedish Armed Forces, S 0647 USB 3G-HF 1-way FLSU call followed by MIL 188-110A Circuit Mode carrying unid S-5066 UDOP client (23Jun17) (AAI)
10170.0: ---: Russian Mil/Gov, RUS 0540 CIS-VFT/3x100Bd/1440Hz (23Jun17) (AAI)
11111.0: 1OMFUM: French Navy OMAR Net, Papeete OCE 0455 USB MIL 188-141A call 1OMFUJ French Navy OMAR Net, Noumea NCL  (23Jun17) (AAI)
07500.0: SZ1: Unid 1245 USB MIL 188-141A call ND1 (21Jun17) (AAI)
07505.8: XLA: French Armed Forces, F 0632 USB MIL 188-141A handshake XLB followed THALES HFXL modem running on 12 channels (21Jun17) (AAI)
10330.0: 920007: Unid 2126 USB MIL 188-141A call 920001 (20Jun17) (AAI)
10425.0: SWI: Unid 2050 USB MIL 188-141A call SDS (20Jun17) (AAI)
10915.0: 105004: Unid 2034 USB MIL 188-141A sounding (20Jun17) (AAI)
10914.5: GWD111: Brasilian Navy unid vessel, B 2029 USB MIL 188-141A call GWPWZ33 (20Jun17) (AAI)
10390.0: 1304: Moroccan Civil Protection, MRC 2020 USB MIL 188-141A sounding (20Jun17) (AAI)
11340.0: 400001: Unid Mauretanian net, MTN 2015 USB MIL 188-141A call 400010 (20Jun17) (AAI)
11010.0: GWPWZ33: Brasilian Navy HQ Rio de Janeiro, B 2009 USB MIL 188-141A call GWPWSP Almirante Sabóia – G25 (20Jun17) (AAI)
06903.0: WI3 Polish Military, POL 0629 USB MIL 188-141A call AV5 (20Jun17) (AAI)
06903.0: TO9 Polish Military, POL 0626 USB MIL 188-141A call HU1 (20Jun17) (AAI)
06903.0: RO2 Polish Military, POL 0626 USB MIL 188-141A call AV5 (20Jun17) (AAI)
10390.0: 1325: Moroccan Civil Protection, MRC 2212 USB MIL 188-141A sounding (19Jun17) (AAI)
06906.0: 5003: Unid 0537 USB MIL 188-141A sounding (19Jun17) (AAI)
05731.0: E06: Russian Intel, RUS 2132 J3E/USB male voice repeating 315 then into 5FGs (16Jun17) (AAI)
08118.5: D02: Dutch Military, HOL 0754 USB MIL 188-141A call D12 (14Jun17) (AAI)
10900.0: VIR: Unid 0720 USB MIL 188-141A LQA exchange w/ PAA (14Jun17) (AAI)
11186.0: ---: Unid 0715 USB 3G-HF 2-way FLSU handshake followed by HDL3 transfer (14Jun17) (AAI)
11002.0: VIR: Unid 0710 USB MIL 188-141A LQA exchange w/ PAA (14Jun17) (AAI)
07457.0: ---: Unid 0624 USB MIL 188-110 Appendix B OFDM 39-tone followed by short Arabic voice comms (14Jun17) (AAI)
08224.0: ---: Unid 0617 USB HARRIS Autolink-I waveform (14Jun17) (AAI)
07860.0: RD21: Algerian Military, ALG 0602 USB MIL 188-141A call NX20 (13Jun17) (AAI)
06956.5: ---: Unid 0504 USB (offset 1500Hz) R&S ALIS 228Bd/170 calling 220 (13Jun17) (AAI)

↧

unid STANAG-5066 RCOP/UDOP client, Swedish Army (update-1)

July 5, 2017, 8:55 am
$
0
0
[ previous post ]
A recent copy of S-5066 transmissions exhibits a change of paradigm in the so-termed "wrapper" protocol (depicted in the previous post), more precisely the content length of the header Timestamp is reduced from 10 to 9 bytes: 

Fig. 1
Most likely the change happened in coincidence with the reset of the timestamp, ie on 2 July 00:00:00 UTC as can be deduced from a simple calculation (time and date of reception has been taken as the starting date!) and the exposed timestamp (296595868):

Fig. 2
Other than a RCOP new transfer (the above copies regard UDOP protocol), we have also to wait for a capture of a multi-block transmissions to verify if the MTU too is changed.
Note that the copied transmission also offers the opportunity to see the new magic string "ZXPBG", so far never encountered.

For what concerns the source/destination IDs, I could find a possible clue about "HWK01".
Sweden Air Defense Regiment has two air defence battalions equipped with Robotsystem 70 (RBS 70) and Robotsystem 97 (RBS 97): 
Recently, defence and security company SAAB has signed a contract with the Swedish Defence Materiel Administration (FMV) for a service life extension of the RBS 97 air defence missile system, this order ensures the continuing effectiveness of a missile system that is the backbone of Sweden's two air defence battalions:
The RBS 97 is a surface-to-air missile system that is better known as "HAWK", then  it could be that HWK01 = HAWK 01 = Air Defence Battalion 1.

(to be continued)

↧

STANAG-4538, optimized Asynchronous FLSU call ?

July 7, 2017, 1:46 am
$
0
0

I copied these 3G-HF transmissions very often and, since the "extended" duration of the first burst, I always thinked to Asynchronous FLSU calls; but, apart from the un-expected ending BW5 burst, a careful examination of the first burst in some cases may reserve an interesting aspect as in the present sample.

Asynchronous FLSU calls consist of a sequence of Async_FLSU_Req PDUs sent consecutively on the channel: FLSU protocol use burst waveform 5 so an Async FLSU call can be easily detected in the ACF output screen just thanks to the BW5 spikes (Figs. 1,2).

Fig. 1 - BW5 timing
Fig. 2 - ACF output of an asynchronous FLSU request
Analyzing the recording in question, my analysis tool reveals only one initial BW5 burst, instead of the expected n-bursts (!), which is then followed by a block consisting of 2400Bd PSK-8 modulated symbols. I had a look at the on-air symbols and found that they have a 768-bit period length which corresponds to 256 PSK-8 symbols (Fig. 3).

Fig. 3
BW5 uses a Psuedo Noise spreading sequence that is generated using a table that just contains 256 values [S-4538 #13.9.6] thus the whole first burst match the BW5 waveform (also note the repeated patterns that characterize the bitstream).

Looking at the BW5 timing (Figure 1) and the ACF output screen of the signal (Fig. 4), it seems that the TLC (Transmit Level Control) section is sent only in the first BW5 burst while the following bursts are a bit shorter and consist only of the preamble and data sections, as shown in Figure 5.

Fig. 4
Fig. 5 - the Async FLSU request in question
This is in contrast with what I seen so far in Async FLSU requests in which the BW5 bursts are contiguously transmitted, each with its own TLC section (Figs. 2,6) 
Fig. 6 - ASsync FLSU request as depicted in STANAG-4538
Indeed, STANAG-4538 does not specify this point "The Asynchronous call begins with the LBT (for at least one dwell period), followed by the transmission of about 1.35N Async_FLSU_Request PDUs on the requested link frequency, where N is the number of channels in the scan list, and 1.35 is the duration of each dwell (in seconds)." [STANAG-4538 #5.1.3].

The initial TLC section is used for transmitter level control and receiver AGC settling [1], thus sending TLC sections in contiguous BWn bursts make a poor sense: it's my guess that probably the removal of the redundant TLCs is an optimized implementation adopted by this manufacturer.
By the way, my analysis tool fails because most likely uses a burst-duration approach in order to identify the waveform.







[1] Johnson, Koski, Furman, Jorgenson, "Third Generation and Wideband HF Radio Communications"
Existing HF radios were generally not designed with burst waveforms in mind. For example, MIL-STD- 188-141 military radios are allowed 25 ms to reach full transmit power after keying. While the transmitter radio frequency stages are ramping up, the input audio signal level is adjusted by a transmit level control (TLC) loop so that it fully modulates the transmit power. At the receiver, an automatic gain control (AGC) loop must also adjust to a new receive signal. To accommodate these characteristics of existing radios, the 3G burst waveforms begin with a TLC section of “throwaway” 8-ary PSK symbols that are passed through the system while the transmitter’s and receiver’s level control loops stabilize. 
↧
Search

a burst ARQ mixed system (MS110 & S4539)

July 13, 2017, 12:24 am
$
0
0

transmission was spotted only once on 7906.0 KHz from 0603 UTC (tune time) until 0639 (signal off). It's a burst ARQ system in which one station uses STANAG-4539 and the other one uses MIL 188-110A, both running at fixed data rates (respectively4800 and 2400 bps) and carrying STANAG-5066 frames. 
Difficult to say who sends data and who send ACKs. Only the Stanag-4539 bursts have a relative good quality for their analysis (Figs. 1,2): these bursts in large part carry STANAG-5066 DTS control frames (D_PDU type 6) so the station that uses 188-110A could be the data sender, although their duration is very short. Most likely it's a test transmission.

Fig. 1 - frame structure of STANAG-4539 bursts
Fig. 2 - 287 symbols period of STANAG-4539 bursts
It's worth noting that in many D_PDUs (S4539 bursts) the address of the destination node belongs to the block assigned to France (006.014.yyy.zzz) while the source address belongs to a reserved block (015.xxx.yyy.zzz).

Fig. 3



↧
↧

short bit-analysis of a STANAG-4538 HDLn transfer (BW2 bursts)

July 14, 2017, 10:37 am
$
0
0
 

Each HDLn transfer consists of n TX Frames (n = 24, 12, 6, or 3) each consisting of n data packets; each data packet consists of 233-byte data segment plus a 17-bit Sequence Number. Each TX Frame is sent using burst waveform BW2.
During the construction of BW2, a 32-bit Cyclic Redundancy Check (CRC) value is computed across the 1881 payload data bits of each data packet (233 bytes of user data, plus the 17-bit of Sequence Number) and is then appended to the data packet. Then, seven encoder flush bits with values of zero (Flush) are appended to produce an Extended Data packet of 1920 bit length,ie: 233 data bytes + 7 overhead bytes (17-bit sequence number + 32-bit CRC + 7-bit flush). See this post about the formation of a BW2 burst.

That said, we can go back to the original datagram by inspecting the last 56 bits of the Extended Data packets in the two BW2 bursts (Fig. 2a).
The value of the Packet Number fields varies from 0 to 5, this means that it's a 2 x HDL6 transfer; looking carefully at CRC fields we note that the two HDL6 bursts carry exactly the same datagram: maybe the destination station requested a retransmission (the first BW1 ACK burst) or the datagram is sent twice so to improve the reliability of the transfer (Fig. 2a):

Fig. 2a
That said, we can focus on the Extended Data packets (below termed only "packets") of a single BW2 burst (Fig. 2b).
The values of the six Packet Number fields are: 0,1,2,3,0,1. If TxDatagram buffer is not completely emptied the remaining packet positions are filled with repetitions of packets already residing in other positions of TxFrame buffer. The HDL transmitter is at liberty to select packets from the current datagram to repeat as it pleases (the HDL receiver shall inspect the sequence number of each packet received without errors,and use this information to discard duplicate packets).
The original datagram, in this sample, is then composed of the packets #0 #1 #2 #3.

Fig. 2b
Looking at the Packet Byte Count fields in the first four packets (Fig. 2c) we see that the firts three packets carry 233 bytes of user data (as expected, since HDL) and the last packet carries 224 bytes of user data (the remaining 9 bytes are filled with "0" value bytes).
Thus, the length of the original datagram is (233 x 3 ) + 224 = 923 bytes. 

Fig. 2c
Back to the whole bitstream, once structured in a 1920-bit period (the Extended Data packet length), the original datagram can be extracted by isolating the firts 4 rows and removing the overhead bytes: the resulting is an HARRIS "Citadel" encrypted file of 923 bytes length (Fig. 3).

Fig. 3
The duplicated HDL6 burst (A,B), the retransmitted packets (C,D) and the "0" value bytes filling a single packet can be noted looking at the whole bitstream in Figure 4. 
Please note as the bitstream is misleading: at a superficial glance, one could think to four "Citadel" encrypted files!

Fig. 4
↧

playing with psk-Sounder and Stanag-4285

July 21, 2017, 9:48 am
$
0
0
I used the word "play" because this post does not claim to be a scientific treatment or a in-depth study on propagation mechanisms. HF propagation is not a sort of "deterministic machine" with a certain set of known rules to apply, is not so immediate as a multiplication table, but rather it's a very complex science which involves several disciplines; there is a lot of things to know and a lot of still not clear things... and something unpredictable. Almost casually I found the psk-Sounder software and decided to have just a close look at it: the results are shown in this "cheap and cheerful" post. I want to thanks Murray Greenman, a great expert on HF propagation (20 years experience) and co-developer of psk-sounder, for the precious help and clarifications.

Background
STANAG-4285 is basically a 2400 baud PSK-8 signal, transmitted in frames of 256 symbols in a frame. The intersting thing is an 80-symbol section of this frame which contains a repeated 31-bit pseudo-random binary sequence (PN). PSK-Sounder uses frames of the same length and its cross-correlator allows to locate each frame exactly in time. Since a PN sequence is transmitted every 256/2400 secs, by comparing the time of the frame with a clock in the computer, we can also measure changes in the propagation delay of the received signal over time and plot such measures in the so-termed Correlogram.
The Correlogram is then a representation of propagation delay (vertically), elapsed time (horizontally) and correlation significance (relative signal strength of each ray) as brightness. You can use the mouse to read off the delay between responses.

Fig. 1 - psk-Sounder monitoring a STANAG-4285 transmission on 17MHz from CTA Monsanto (Portugal)
"As an example, imagine we are receiving a signal from a station some distance away, which is providing both ground wave and F-layer ionospheric signals - the classic NVIS situation. The ground wave will be delayed by just a millisecond or two (300km per millisecond at the speed of light), while the F-layer signal, travelling a further 300km up to the ionosphere and another 300km back, will be delayed an extra 2ms. Both these signals arrive at the receiver, and the cross-correlator has to work with the combined signal. So, it will in fact find two peaks, about 2ms apart, and we can display or plot this information, and measure the delay. Very often the propagation is even more complex, especially at greater distances, and of course very often the ground wave signal is not received at all." 
PSK-Sounder, along with documentation, instructions and examples, can be downloaded from:
http://www.qsl.net/zl1bpu/SOFT/PSKSounder.htm

Notes
1) a serious approach requires the monitoring of several stations and frequencies for long periods, say one year at least, so to observe the changes in propagation in different seasons and in different hours of the day per each station/frequency (...the sun is not a light bulb). For my scope, I monitored only two S4285 stations at fixed times (for about a 5-minutes period) during the day:

- 5215.6 KHz French Navy Toulon F, 445 Km West from my QTH
- 8698.2 KHz Norwegian Navy Bodo NOR, 2721 Km North from my QTH

It's important to note that in the case of Toulon the path is in large part over the sea (83.5%).
 
Fig. 2 - the "monitored" STANAG-4285 stations
2) There are empty areas in some of the following correlograms which are due the lack of S4285 sync. It's always difficult to achieve really long monitoring times with PSK Sounder, as something inevitably disrupts the bitstream and consequently the synchronization with the incoming S4285 signal is lost. Obviously, real modems resynchronise to the PN sequence instantly, but PSK-Sounder is not locked at all and simply observes where the PN sequence is! (as said above).

3) I have no stations within ground wave range (say 50 km at 5 MHz, 100 at most), the closest is IDR  Italian Navy from Santa Rosa (Rome), so the lowest 0 seconds fligth-time track in Correlograms (that would be the ground wave) is here the E layer response, ie the region about 30-50 km up from earth. This means that the delays are not the real ones but are related to E responses, when present, or at least to the lower one.

4) Combined Correlograms (Toulon/Bodo) would be very interesting but unfortunately I do not have a such tool at my disposal.

One could say that similar tests do not make a great sense (and that's right), anyway, although the above limitations, some interesting observations can be noted.

Correlograms - Bodø (8698.2 KHz - 2721 Km North - 20 July)

Fig. 2a

Fig. 2b
Fig. 2c
Fig. 2d

I am not in a position to correctly describe the above scenarios, but I can give a rough description of what I see. While around 1000Z (Fig. 2b) the reception is sustained by E layer, around 1400Z (Fig. 2c) the propagation is mostly due to F layers: you can see the different heights (ie delays) of the thickest black line. Pobably, at that time (1420Z) the absorbing D layer is disappeared, signals have a greater strength and can penetrate E layer and reach the upper F region.

Correlograms - Toulon (5215.6 KHz - 445 Km West - 20 July)

Fig. 3a
Fig. 3b
Fig. 3c
 
Fig. 3d
In the morning (Fig. 3a) are visible two well distinct paths reception due to the refractions by E and F layers. In the central part of the day, the E response line is a less pronunciated line and delayed responses up to 4-5 msec begin to be visible (Figs. 3b, 3c); it's very interesting the short duration scatter in Figure 3c which causes a cloud of delay responses > 5 msec.
As said, I am not in a position to give an explanation to this, I asked Murray and I quote here the reply he sent me (it's worth reading it): "[...] It's very difficult to say from just the Correlogram. If you consider a triangle with a base of 450 km (the station's distance from you), which is a flight time of 1.5 ms, and a total 'distance' of the two sides of 4.5 ms (the delay added by the path you are interested in), then you can construct an isosceles triangle which will have the refractive point at the peak. The sides will each be 2.25 ms, and the vertical height to the peak can be calculated to be 4.44 ms, or a height of 1332 km above the base.
We know that the F layers are 200 - 300 km in altitude, so clearly the scenario I just described is not correct. There are two factors involved: (1) the possibility that the signal bounced around (is scatter); and (2) that the speed of light is much reduced at the refractive layer, since the refractive index is high here. So therefore the path is not a simple triangle, but has an area of multiple refractions with reduced propagation speed.
So the complicated answer is that I consider that area to be one of multiple scatter, the signal bouncing around between layers (probably F1 and F2) for some time before returning to earth. It is probably not a small  'cloud' as such, but a wide layer which was briefly in the right place for you to see the effect. Another point to consider is that the ground wave range on 5 MHz is about 50 km, 100 at most, so what looks like the ground wave is most likely the E layer response, the layer about 30 - 50 km up. [...]". Anyway, bounces between sky and sea are also probable.
Around 2000Z (Fig. 3d) the E response returns to be preminent along with the lower F layer, probably still many bounces cause delayed responses up to 5msec. 

Final note
HF propagation is a fascinating part of our hobby but things get very complicated if one want to deepen his knowledge about it. Unlike what it may seem from reading some websites, propagation is not summarizable in a few simple rules but there are a lot of things to study ...and "The trouble is that this sort of study raises more questions than we have answers for!", as Murray Greenman says.

↧

Arecibo ionosphere HF campaign, 24-31 July 2017

July 25, 2017, 2:15 am
$
0
0
quoting from Chris Fallen KL3WX  "If you are reading this then another radio event of possible interest is the upcoming Arecibo ionosphere HF heating campaign during 24 to 31 July 2017. The new Arecibo ionosphere HF heater nominally transmits 600 kilowatts net power (100 to 200 megawatts effective radiated power) and has a unique Cassegrain dual-array antenna design that increases gain of three crossed dipoles for each band using the signature 1000 ft spherical dish reflector.[...]. During the upcoming campaign, the Arecibo HF transmitter is limited to two frequencies, 5.125 and 8.175 MHz. Campaign HF transmissions will start at approximately 1600 hours UTC and be active approximately 24 hours per day, with some occasional downtime for maintenance and other activities lasting one or more hours. Generally, the 8.175 MHz transmissions will occur in the daytime when foF2 is expected to exceed that value, between approximately 1830 and 2230 hours UTC. Otherwise the HF transmissions will occur at 5.125 MHz.
These transmissions will be in the vertical direction so this is an excellent opportunity to observe NVIS from a powerful transmitter in Puerto Rico."


 
Notice that 5125 and 8175 KHz, depending on local foF2, are just estimates and the actual transmitted frequency may be adjusted slightly from those values for various reasons.
I copied one of their transmission on 5095 KHz around 2145 Z on 24 July: the working frequency was comunicated by Chris Fallen in his twitter account: https://twitter.com/ctfallen (follow him if you want tune such these transmission from Arecibo). Although at a first glance the signal appears as "carrier", it consists of O-mode or X-mode polarized CW pulses (Fig. 1):

Fig. 1 - the received signal
These transmissions leave the earth in the vertical direction so this is an excellent opportunity to observe NVIS from a powerful transmitter in Puerto Rico: signals in Europe are probably heard thanks to secondary radiation lobes at 5 MHz (Fig. 2), as depicted in: 

Fig. 2







↧

unid STANAG-5066 RCOP/UDOP client, Swedish Army (update-2)

July 26, 2017, 3:42 am
$
0
0
Just a small update to notice that from recent copies it seems that they returned to using 10 bytes for the length of the timestamp element:


So far, these are the S5066 Addresses that have been found:

[006.046.000.zzz] block
HWK01   006.046.000.028, 006.046.000.102
ZMK002  006.046.000.037

[006.046.001.zzz] block
DWY    006.046.001.009
PFY    006.046.001.010
ZHO    006.046.001.028
RJY    006.046.001.029
GZL    006.046.001.030
HEH    006.046.001.034
HEH002     --"--
CAU    006.046.001.046
VJL    006.046.001.054 

and these the "magic string" values:

ZAPCK
ZXPBC
ZXPBD
ZXPBG
ZRTBC
ZRTBD 
 
↧
↧

Logs

July 27, 2017, 5:55 am
$
0
0

05200.0: ---: (no call) 2100 USB voice comms using Hagelin HC-256 scrambler (06Jul17) (AAI)
05255.0: R4: Unid 2017 USB MIL 188-141A call R7 (06Jul17) (AAI)
05305.0: TC01: Algerian Military, ALG 2045 USB MIL 188-141A handshake NX01 / voice comms using HARIS AVS vocoder (06Jul17) (AAI)
05405.0: JCI: Saudi Air Force, ARS 2042 ISB MIL 188-141A call RFI (06Jul17) (AAI)
05453.0: RHP: Saudi Air Force, ARS 2038 USB MIL 188-141A call AAP (06Jul17) (AAI)
05775.0: XS69: Unid 2031 USB MIL 188-141A call XN40 (06Jul17) (AAI)
06208.4: XLA: French MOD, F 1745 USB USB MIL 188-141A handshake XLB / THALES HF XL modem, upper channel 6393.1 KHz (07Jul17) (AAI)
06362.5: D23: US Customs P-3B Slick, USA 1437 USB MIL 188-141A call A82 UH-60 CPB (09Jul17) (AAI)
06416.5: XSS: DHFCS, UK 1543 USB MIL 188-141A call XDV (09Jul17) (AAI)
06516.0: MedNet: Mediterranean Cruiser Net 0605 J3E/USB lady in English lang. working cruising vessels (06Jul17) (AAI)
06550.0: GRIFFIN: TF Griffin Camp Bondsteel, HRV 0520 USB MIL 188-141A sounding (14Jul17) (AAI)
06715.0: CROSPR: US-GCS Croughton AFB, UK 0509 USB MIL 188-141A call MOBD02DAT (06Jul17) (AAI)
06715.0: OFFSPR: US-GCS Offutt AFB, US 0503 USB MIL 188-141A call MOBD02DAT (06Jul17) (AAI)
06840.0: GRIFFIN: TF Griffin Camp Bondsteel, HRV 0442 USB MIL 188-141A sounding (06Jul17) (AAI)
06938-0: HBLZDRD1: Roumenian Militay, ROU 0709 USB MIL 188-141A handshake HFJCDRD1 / MIL 188-110A Serial (17Jul17) (AAI)
07394.5: KW7: Polish Military, POL 1231 USB MIL 188-141A call SA2 (01Jul17) (AAI)
07401.0: ZBOR: German Customs Patrol Vessel Borkum, D 0626 USB MIL 188-141A, call BMEK (02Jul17) (AAI)
07450.0: ABC7: Croatian Military, HRV 0712  USB MIL 188-141A Handshake / STANAG-4285 1200bps L, email to ABG6 using CROZ STANAG-5066 HMTP (06Jul17) (AAI)
07455.0: NAA: Navy Isabela, PTR 0630 USB (offset +2000) NATO-75 75/850, continuous bcast (02Jul17) (AAI)
07460.0: 24191: Moroccan Civil Protection, MRC 0539 USB MIL 188-141A sounding (13Jul17) (AAI)
07464.0: HWK01: Swedish Armed Forces, S 0737 USB 3G-HF 1-way FLSU call flwd by Circuit Mode MIL 188-110A serial, unid S-5066 UDOP client (05Jul17) (AAI)
07467.0: SL2: Slovakian Military, SVK 0600 USB MIL 188-141A call MC1 (07Jul17) (AAI)
07505.8: XLA: French MoD, F 0858 USB THALES HF XL modem, 12 channels test transmissions to XLB (21Jul17) (AAI)
07530.6: ---: Unid 0620 (cf) Siemens CHX200 F1-modem (CHP-200) FSK 249Bd & 250Bd/170Hz, selcall mode (02Jul17) (AAI)
07568.0: KRAKOW: POL MSWiA net Krakow, POL 0636 USB MIL 188-141A call BYDGOSZCZ (06Jul17) (AAI)
07568.0: POZNAN: POL MSWiA net Poznoan, POL 0710 USB MIL 188-141A call BYDGOSZCZ (06Jul17) (AAI)
07600.0: ---: Unid prob French Military 0739 THALES Skymaster MFSK-8 ALE / THALES proprietary 2400Bd PSK-8 waveform (06Jul17) (AAI)
07615.0: ---: Unid prob French Military 0822 THALES Skymaster MFSK-8 ALE / THALES proprietary 2400Bd PSK-8 waveform (25Jul17) (AAI)
07630.0: ---: Unid 0709 (cf) NATO-75 75/850, KG-84 encrypted message (10Jul17) (AAI)
07677.5: NX40: Algerian Military, ALG 0837 USB USB MIL 188-141A call XS69 (15Jul17) (AAI)
07692.0: CX3: Moroccan Gendarmerie, MRC 0659 USB MIL 188-141A call IC2 (22Jul17) (AAI)
07693.0: ---: Unid 0725 USB THALES Skymaster MFSK-8 ALE (10Jul17) (AAI)
07720.0: ASB01D: French Naval Network, F 0819 USB MIL 188-141A handshake AM103D / MIL 188-110A Serial (26Jul17) (AAI)
07765.0: FQ71: Unid 0845 USB MIL 188-141A call NX80, also heard on 7841.0 and 8023.0 (01Jul17) (AAI)
07788.0: ---: 0541 USB 3G-HF 2-way FLSU handshake / LDL128 tranfser, Harris "citadel" encrypted 451 bytes file (20Jul17) (AAI)
07788.0: ---: Unid 0615 USB 3G-HF 2-way FLSU handshake flwd by LDL128 transfers, switch of data traffic directions (04Jul17) (AAI)
07813.0: GR2: Moroccan Military, MRC 0703 USB MIL 188-141A sounding (24Jul17) (AAI)
07840.0: PC20: Unid (Algerian Military?) USB MIL 188-141A call NX20 (09Jul17) (AAI)
07840.0: XPU: UK-DHFCS, G 0737 USB MIL 188-141A call 1VR (01Jul17) (AAI)
07841.0: ---: Unid 1435 Unid BPSK/62.5Bd (BPSK63F HAM) modem, 31-bit ACF encrypted msg (12Jul17) (AAI)
07875.0: PEGASO: EVA (Escuadrón Vigilancia Aérea) Spanish Air Force Torrejón de Ardoz, S 0800 J3E/USB, radio checks with POLAR (Zaragoza) and SIROCO Lanzarote (26Jul17) (AAI) [I]
07906.0: ---: Unid 0600 USB unid burst ARQ system using STANAG-4539 & MIL-188-110A Serial (11Jul17) (AAI)
07930.0: ---: Unid 0453 USB 3G-HF 2-way FLSU handshake flwd by HDL12 transfer (05Jul17) (AAI)
07978.5: ---: Unid 0627 USB (offset +1500) R&S ALIS 228Bd/170, selcall to 220 (03Jul17) (AAI)
07990.0: ---: Unid: 0630 USB phone comms scrambled using HF CRY-2001 (Sailor-2001) (14Jul17) (AAI)
08016.0: S21: NPRD-Net Split, HRV 0740 USB MIL 188-141A sounding (01Jul17) (AAI)
08016.0: S21: NPRD Network, HRV 0712 USB MIL 188-141A sounding (24Jul17) (AAI)
08016.0: S22: NPRD Network, HRV 0703 USB MIL 188-141A sounding (24Jul17) (AAI) [I]
08021.5: 4KV: Unid 0612 USB MIL 188-141A call 1KV (20Jul17) (AAI)
08054.0: ZD02: Algerian Military, ALG 0825 USB MIL 188-141A call ZD01 (21Jul17) (AAI)
08058.6: ---: Unid 0607 USB (offset + 1600) BELL 103 compatible modem FSK 300Bd/200 in selcall mode (04Jul17) (AAI)
08103.7: HWK01: Swedish Armed Forces, S 0655 USB 3G-HF 1-way FLSU / MIL 188-110A Serial, S-5066 Circuit Mode service, unid RCOP client sending data to VJL (25Jul17) (AAI)
08105.0: CFI: Unid 0550 USB MIL 188-141A call CONRRD19 (09Jul17) (AAI)
08105.0: CFIRRD19: Unid 0534 USB MIL 188-141A call D2IRRD19 (13Jul17) (AAI)
08105.0: CFIRRD19: Unid 0542 USB MIL 188-141A handshake CONRRD19 / MIL 188-110A Serial (13Jul17) (AAI)
08138.0: WAF: ENI/NOC Al Wafa field, LYB 0634 USB MIL 188-141A call MEL Mellitah terminal, short French language male op-chat (04Jul17) (AAI) [1]
08163.0: ---: Unid 0651.0 USB 3G-HF 2-way FLSU handshake / HDL6 tranfser (25Jul17) (AAI)
08168.5: CFIRRD17: Unid 0604 USB USB MIL 188-141A call D2IRRD17 (20Jul17) (AAI)
08190.0: STANISCI: Italian GdF Ship G.1 28 "Vicebrigadiere Stanisci", I 0558 USB MIL 188-141A call MESSINA (24Jul17) (AAI)
08195.0: 10536: Unid 0554 USB MIL 188-141A call 8536 (09Jul17) (AAI)
08234.0: BB1: Israeli Air Force 30th AB, 124 Sqn Palmachim, ISR 0519 USB MIL 188-141A call AAA (05Jul17) (AAI)
08244.5: ---: Unid 0824 USB Arcotel MAHRS-2400 based ARQ system, proprietary 2400Bd PSK-8 burst waveform (17Jul17) (AAI)
08311.0: ABC7: Croatian Military, HRV 0742  USB MIL 188-141A Handshake / voice comms, radio-check w/ABS5 (25Jul17) (AAI)
08327.0: ---: Unid 0709 USB 3G-HF FLSU handshake / LDL160, sending 139 bytes CITADEL encrypted file (10Jul17) (AAI)
08875.0: X44: Unid (prob. Moroccan Military) 0535 USB MIL 188-141A sounding (14Jul17) (AAI)
08992.0: SIGONELLA: US NAS Sigonella, I 2004 J3E/USB test count (06Jul17) (AAI)
10051.0: ---: New York Volmet, USA 0450 J3E/USB Aviational Weather Tampa, Bermuda, West Palm Beach,... (04Jul17) (AAI)
10713.0: SNB813: Polish Military, POL 1335 USB MIL 188-141A sounding (25Jul17) (AAI)
11050.0: ND1: Unid 1016 USB MIL 188-141A handshake FS1 / RFSM8000 serial modem (09Jul17) (AAI)
11056.0: Z01: Croatian NPRD Net Zagreb, HRV 0627 USB MIL 188-141A sounding (07Jul17) (AAI)
11075.0: PEM04D: French Navy, F 0819 USB MIL 188-141A call PEM01D (13Jul17) (AAI)
11111.0: TUD: Tunisian MOI net, TUN 0854 USB MIL 188-141A handshake / PACTOR-II, encrypted email to STAT24 (06Jul17) (AAI)
11186.0: ---: Unid 0517 USB 3G-HF 2-way FLSU handshake flwd by LDL352 sending 699 bytes Citadel encrypted file (04Jul17) (AAI)
11412.0: ---: Unid (Czech Diplo?) 0710 USB (offset +1500) PacTOR-III messages (02Jul17) (AAI)
11490.0: ---: Russian Mil/Intel, RUS 0517 (cf) MOROZ FSK 50Bd/500, reversals (04Jul17) (AAI)
13200.0: ANDREWS: Andrews AFB, USA 0600 J3E/USB test count (12Jul17) (AAI)
13500.0: ---: Unid 0550 USB CIS 6 x 100Bd/120Hz VFT system (12Jul17) (AAI)
14371.0: CENTR2: Roumenian Diplo Bucarest #2, ROU 0723 USB MIL 188-141A handshake / MIL 188-110A Serial, short message to PHG using STANAG-5066 (14Jul17) (AAI)
14550.0: R65: Moroccan Military, MRC 0758 USB MIL 188-141A sounding (14Jul17) (AAI)
14693.5: N64: Unid 0741  USB MIL 188-141A call A85 (14Jul17) (AAI)
14773.5: N64: Unid 0709  USB MIL 188-141A call A85 (14Jul17) (AAI)
14800.0: CVZ: Algerian Air Force, ALG 1228 USB MIL 188-141A call HA2 (24Jul17) (AAI)
16716.0: ---: 0819 USB 3G-HF 2-way FLSU handshake / HDL6 tranfser, Harris "citadel" encrypted 923 bytes file (14Jul17) (AAI)
16964.0. ---. UNID 0640 usb (cf +1800) PacTOR-II FEC (15Jul17) (AAI)
17122.0: ---: Unid 1303 USB HARRIS Autolink-I flwd by MIL 188-110 App.B 39-tone modem sending 5LGs (01Jul17) (AAI)
17127.3: CTA: Potoguese Navy Monstanto, POR 1450 LSB STANAG-4285 600bps/L, Channel Availability for ship-shore "1450Z//CTA02I/CTA08I/CTA12I/CTA14I/CTA16I/CTA19I//" (16Jul17) (AAI)
17398.0: XSQ: Guangzhou Radio, CHN 1506 J3E/USB Navigational warnings (16Jul17) (AAI)
↧

Russian MFSK-17 125Bd/125Hz burst system (selcall waveform?)

July 29, 2017, 2:37 am
$
0
0

Unid MFSK-17 burst system heard on 11090 KHz/USB, modulation speed 125 symbols/sec and separation between tones is 125 Hz (Figs. 1,2)

Fig. 1
Fig. 2
The waveform-1 seems to have some LMF components and a curious tones format (Fig. 3) maybe used to wake-up receiving modems or  matching a certain known tone-sequence. Waveform-1 is then followed by a Russian male operator calling the other station: "first calling twentieth" (thanks my friend KarapuZ who translated the voice comm).

Fig. 3
Bursts have a duration of ~1080 msec and sent each 4000msec in waveform-2.
The same signal, more precisely the here-termed waveform-1, was reported about one year ago in radioscanner.ru forum. "Sometimes a multi-frequency transmission with spreading has been observed" my friend KarapuZ say.




 
↧
Search

short bit-analysis of a STANAG-4538 LDLn transfer (BW3 bursts)

August 3, 2017, 1:38 am
$
0
0

Each LDLn transfer consists of a TX Frame consisting of one data packet; A data packet is defined as a fixed-length sequence of n-byte data segment (n = 32,64,96,...,512) followed by a 17-bit Sequence Number plus an 8-bit Control Field (presently unused), both added by the LDL protocol. Each TX Frame is sent using burst waveform BW3.
During the construction of BW3, a 32-bit Cyclic Redundancy Check (CRC) value is computed across the  data bits of each data packet (8n+25 bits) and is then appended to the data packet. Then, 7 flush bits having the value 0 are appended to the data packet with CRC (8n+57 bits) to ensure that the encoder is in the all-zero state upon encoding the last flush bit. 
That said, we can go back to the original datagram by inspecting the last 64 bits (17-bit Sequence Number + 8-bit Control Field + 32-bit CRC + 7 flush bits) of the ten BW3 bursts  (Fig. 1):

Fig. 1
 Some aspects must be first considered:

a) the 8-bit reserved field is added after the CRC field and not after the Sequence Number, as specified in Annex C to STANAG-4538; I don't know if it's the modus operandi of the decoder;
b)  following the last bit of the Payload field-value, the bits of the Sequence Number field are transmitted starting with the least significant bit (bit 0) rather than the most significant bit (bit 16). Most likely it's the modus operandi of the decoder, as above;
c) as in the Sequence Number of HDL Tx frames (see the previous post), the bits 14-6 of the first packet in datagram contain the number of user bytes in packet -1 and this contrasts what specified in Table 7.1.4.1-2; it depends on the particular STANAG-4538 implementation?

In this sample the values of the Packet Number fields are: 0,0,1,1,2,2,3,3,4,4: maybe the destination station requested a retransmissions or, most likely, each TX Frame is sent twice so to improve the reliability of the transfer (also note the values of the CRC fields). Correspondly, the Packet Byte Count fileds are: 128,128,...,67,67, this means it's a LDL128 transfer.
Note that the bytes contained in the packet #4 is less than 128 bytes because it includes the last data byte of the original datagram (the remaining 128-67 bytes are filled with "0" value bytes). That said, the original datagram of this sample is composed of the single packet numbers 0,1,2,3,4 (ie BW3 #0, #2, #4, #6, #8) and its length is (128 x 4) + 67 = 579 bytes (Fig. 2); the receive station shall discard the duplicated packet numbers.
It's worth noting that in this sample there are no BW4 ACK bursts returned back: it could be an MDL (Multicast Data Link protocol) transmission or maybe I did not heard these bursts!

Fig. 2
Back to the whole bitstream, once structured in a 1088-bit period ((8 x 128) + 64), the original datagram can be extracted by isolating the firts 4 rows and removing the overhead bytes: the resulting is an HARRIS "Citadel" encrypted file (Fig. 3).
 
Fig. 3
The ten LDL128 bursts, the retransmitted packets, and the "0" value bytes fillers can be noted looking at the whole bitstream in Figure 4.

Fig. 4
↧

crowd funded experiment for HAARP

August 9, 2017, 12:48 am
$
0
0


This is an amateur's approach to a science experiment. It may not be in a typical fashion one would see from a physics student or a scientist. Even if my experiment doesn't provide any insightful information, as happens quite often in real scientific experiments - it will be a great opportunity to test a hypothesis! I hope this will have a positive effect of inspiring and motivating others to pursue their interests in science!
You're help is greatly appreciated. I can't do it without you!

Jeff, KL4IU

↧
↧

BPOL R&S X.25 packet radio network on HF

August 13, 2017, 2:18 pm
$
0
0

Bundespolizei See (here simply termed "BPOL") is the maritime component of the Federal Police and is responsible for the border protection of the German state on the maritime border of the North Sea and Baltic Sea (Schengen external border). Since July 1994, BPOL has been part of the "Coast Guard", a coordinating organization of the executive forces of the Federation at sea, which includes customs, water and shipping administration and fishery protection. Since January 2007, BPOL is also represented as a security partner in the joint location center (GLZ-See) of the maritime safety center (MSZ) in Cuxhaven [1].
I consulted the UDXF logs (a collection of logs since year 2008) and for more than one week I watched one of their HF channels (8132.0 KHz/USB): with the exception of rare and sporadic transmissions between ships, all the traffic is structured in a star-shaped HF network in which the coastal HQ is the net control station (Fig. 1).

Fig. 1 - BPOL star-shaped network
ALE Address - name (HF node name)
BPLEZS, BPL - BPLEZSEE Operations Center HQ Cuxhaven (BPOLBPLEZSEE_HF)
BP21 - patrol vessel "Bredstedt" (BPOLBP21_HF)
BP24 - patrol vessel "Bad Bramstedt" (BPOLBP24_HF)
BP25 - patrol vessel "Bayreuth" (BPOLBP25_HF)
BP26 - patrol vessel "Eschwege" (BPOLBP26_HF)

(*) patrol vessels BP22 "Neustrelitz" and BP23 "Bad Düben" are out of service since 28 June 2017 [2]. Just a curiosity: BP22 and BP23 are also known from the ZDF Television series "Küstenwache", where they were alternated under the name "Albatros II" [3] .

The way they operate these HF channels (8132, 5258, 4618, 3850,... KHz/USB)  is based on link establishment, using MIL 188-141A 2G-ALE, followed by data transfer, using a Rohde&Schwarz proprietary PSK-8 2400Bd waveform  and GM2100/GM2200 serial HF modem (Fig. 2a); anyway, the most large part of the heard transmissions consists of routine ALE scanning calls. 

Fig. 2a
The most interesting aspect is that data exchange is performed by means of RSX.25 ARQ protocol (Fig. 2b), a Rohde&Schwarz adaptation of the wired X.25 packet protocol to the HF radio channel. 
 
Fig. 2b

Quoting R&S papers: "The RSX.25 protocol is a modified AX.25 packet radio protocol. RSX.25 organizes the data to be transmitted in packets, which are successively transferred to the data modem. The packets contain a variable number  of  frames, the number perpacket depending on radio-link quality and being adapted at regular intervals.
The data transmitted in a packet are distributed among the frames. The length of the frame data is variable and also depends on radio-link quality: in channels of very good quality, a frame contains up to 250 data  bytes, in strongly disturbed channels 4 bytes. The HF Modem GM2100 is integrated in an optimized RSX.25 protocol that controls modulation and redundancy adaptation. With 8PSK the net data rate of the serial modem is 5400 bit/s. Errors are at first corrected by FEC, which reduces net data rate to 2700 bit/s. Errors escaping FEC are eliminated by the ARQ procedure of the RSX.25 protocol." [4][5][6] 

Fig. 3 - RSX.25 data after GM2100 removal
Fig. 3b - the same data synched on 0x7E (01111110) flag (AX.25)

A second interesting point is that each 188-141A three-way handshake always includes the command User Unique Function (UUF) in the message section [7]:

[TO][BPLEZS][TIS][BP24]
[TO][BP24][TIS][BPLEZS]
[TO][BPLEZS][CMD USER UNIQUE WORD][TIS][BP24]

UUFs are for special uses, as coordinated with specific users or manufacturers, which use 188-141A in conjunction with non-ALE purposes. There are 16384 specific types of UUF codes available, as indicated by a 14-bit (or two-character) Unique Index (UI) which is always included in UUF when sent (Fig. 4); in this case they always use the index "00000000000111" and most likely it's closely related to the upper RSX.25 protocol:

(to)BPLEZS (cmd)|[nul][bel] (tis)BP24
1111100 00000000000111 
 
Fig. 4 - User unique functions structure

Unfortunately, linking handshakes & following RSX.25 exchanges are not as frequent as the great amount of scanning calls, indeed data exchanges are few and not all are carried by good signals: probably because of the varying propagation and the distances from my QTH, or maybe because links are performed in other channels and I do not own a scanner. 
Probably there is also another reason due to the use of HF only when a vessel exceeds the V/UHF range of coastal HQ, or exceeds the area covered by their TETRA "BOSNet" network infrastructure (the German nationwide TETRA radio system), assuming that these vessels already have this technology.  

Given the above, what is the nature of the RSX.25 exchanged data? Here is where things get a bit difficult.
As said, RSX.25 is a packet radio protocol and is meant to share tactical information and short messages. It has a typical period of 8 bits and may convey BZIP compressed files (eml, txt and others...) as well as IP frames.

Fig. 5
Email files (.eml BZIP compressed) are just simple messages and consist of "position reports", as the transmission logged on August 10 at 0806 in which vessel Bayreuth (PB25), comunicates its coordinates at 0737 and 0757 (all times in CEST). Emails are probably managed by R&S Postman software running at upper layer.

2017-08-10 07:37:48+02,BPOLBP25,54.023927,10.800935
2017-08-10 07:57:47+02,BPOLBP25,54.023125,10.800987

The transmitted coordinates can be easily imported into Google Earth using klm files (Fig. 6a).

Fig. 6a
Moreover, using web sites such as: vesselfinder or marinetraffic you could verify a received position report or just "track" the calls as in Fig. 6b.


Fig. 6b - tracking ALE calls

Back to captures, looking at txt files (Fig. 7) there are some interesting sequences that are easily recognizable (maybe related to a protocol built on top of packets?) as well as messages like "login, connected, closed" which are exchanged between the nodes. Also note that sometimes 188-141A links are terminated by the called station rather than the caller. 
What is even more interesting is the sending of one or more text strings in the format:

[yyyy-mm-dd] [hh:mm:ss UTC-offset], [vessel name]

where vessel name usually is not the one which sends the message (except when an email is also sent) and date-time is always before the transmission time. These kind of "announcing lists" are separated by semicolons and seem enclosed in <MPL></MPL> tags when sent by a vessel, and in <SPL></SPL> tags when sent by BPLEZSEE. It may also happen that these lists are empty, in this case only the tags are transmitted e.g. <MPL></MPL>.

Fig. 7
One could say that, in some way, these strings resemble the DX-Cluster spots, while the vessel positions reported in emails resemble APRS (Automatic Packet Reporting System); anyway, such messages seem related to situational awareness purposes. 

Probably this is one of the few existing packet-radio networks in HF and, the way things are these days, will be soon replaced by TETRA/SatCom systems.
↧

unid 3-of-6 multitone system (tentative)

August 16, 2017, 12:49 am
$
0
0

Recently I copied an interesting multitone signal on 14642.0 KHz and 16114.0 KHz on USB. The signal uses 6 tones, 400Hz spaced, starting from 650Hz, and it sounds just like a frog. Tranmissions do not have a preamble, last for a few minutes (the longer I heard last up to 16 minutes) and consists of 820ms blocks: 500ms data block followed by 320ms interval (Fig. 1)

Fig. 1
Transmissions end with the sending of the 6 carriers in a special sequence (Fig. 2)

Fig. 2
Three of the six tones are used to form the code symbols, ie they are sent simultaneously (Fig. 3): since given six tones there are twenty combinations of three that can be drawn without repetitions, this system use a 20 symbols alphabet set. It's important to note in Fig. 3 that each data block always consists of the ordered sequence of all the possible symbols (!) that makes a speed of 40 symbols/sec that is - in some way - coherent with the used shift (40Bd/400hz).

Fig. 3
123,124,125,126,134,135,136,145,146,156,
234,235,236,245,246,256,345,346,356,456

Many "exotic" coding could be derived from this set (as 123=A,124=B,... or 123=0,124=1,...) and a 6-bit representation is one of these: e.g. using the lower tone as the LSB we get the sequences:

000111 001011 010011 100011 001101 010101 100101 011001 101001 110001 
001110 010110 100110 011010 101010 110010 011100 101100 110100 111000

Fig. 4
(you may play around it inverting the order, changing polarity, differential decoding,...)

I don't know who they are and where the signals come from, anyway the fact of sending all the alphabet symbols leads to think that it could be a test of a new system, maybe aimed to Intel/Diplo services... but it's only a my supposition and - if that is the case - we should wait for further transmissions from the "production" frog-modem.







 
https://youtu.be/2YFKJGpbXV8 
↧

Rohde & Schwarz ALIS (RS-ARQ): pool size and frame length

August 20, 2017, 8:01 am
$
0
0
Like in other ALE systems, during an ALIS call [1] the caller station transmits a defined number of "calling" frames so that the called station could have enough time to scan the frequencies of the current pool and, in case of late entry, could ever receive at least three frames for synchronization and data acquisition (Fig. 1).
Fig. 1 - ALIS late entry support to facilitate data acquisition
Thus, the number of the transmitted frames during an ALIS call is not fixed but depends on the size of the current pool of frequencies: roughly it is = (3 x number of pool frequencies) + 1. Don't know what is the maximum of frequencies for each pool and the maximum of different pools which are allowed by the ALIS processor.
I had a look at some ALIS calls and surprisingly found different ACF results, eg (Fig. 2): 

~358.6 ms for a pool size = 6
~376.1 ms for a pool size = 8
~402.2 ms for a pool size = 9
~402.8 ms for a pool size = 10
~415.5 ms for a pool size = 11
(although there are some decoder indecisions about pool sizes 9 and 10).

Fig. 2 - pool sizes and ACFs
Since the system operates at constant speed (228.6 symbols/sec), the higher is ACF and the greater the number of transmitted symbols; this means that also the length of the frames is not fixed but it depends on the number of the frames to be transmitted, and ultimately on the pool size.
This dependence is even more neat looking at the demodulated stream in Figure 3, in which you can highlight a fixed 61-bit data block, following a variable length block consisting of a single field (here termed as "FC").

Fig. 3 - pool sizes and frame lengths
82-bit period for a pool size = 6
86-bit period for a pool size = 8
95-bit period for a pool size = 11

It's easy to note that the extra-lenght (period length - 61) matches the number of the frames to be transmitted for each pool size, according to the relation:
number of frames ~ (3 x pool size) + 1

Figure 4 shows the "vertical" comparison of the 61-bit block for three different pool sizes (6,8,11) and a my rough reading of their structure; the decoder outputs in the right boxes help to identify values and differences.
It's easy to see that the first 15-bit field (0-14) is the address of the called station, while the 23-bit last field (38-60) is probably transmitted for sync/correlation since this field exhibits the same pattern in all the 3 frames; if so, the rightmost bit should be the first to be transmitted. The 23-bit middle field (15-38) is the "status" of the caller station (FSK, voice, data, ARQ, adaptive reaction, fixed operation on a single frequency, frequency hopping mode, message key for frequency hopping mode, ...).
It's worth noting that, despite other ALE waveforms, the caller address is never transmitted.

Fig. 4 - 61-bit block structure
As you see, no field contains informations for the pool size (the middle field can't store the pool size because the first two frames have diffrent pool sizes and same value for this field!).  

Given the above, the fact that the decoder prints out the size of the selected pool of frequencies (as in Fig. 1), means that this information is obtained from the "parsing" of the variable lenght block (FC block) of the frame. I just wrote "parsing" because in this block, rather than a numeric value, they adopted a "positional" rapresentation by using the lenght of the block and the position of the 1-value bit, which is right-shifted in each received frame (Fig. 5).

Fig. 5 - FC blocks
One could say that the FC block looks like a function table of a n-bit shift register, in which each received frame acts as a transition of the clock input. 
Besides enumerate and identifiy the received frames, and consequently the pool size, the implementation of the FC block could also be used as a timing logic for re-sync the receive modem. But that's just a my opinion.

Please note that I do not own professional analysis tool so the numbers could be a bit inaccurate or different, anyway I think the underlaying reasoning remains valid. Who knows? maybe someone from R&S will read and comment... 


[1] quoting Hoka Electronic: "Some people call RS-ARQ (Rohde & Schwarz simplex ARQ) as ALIS but strictly speaking, ALIS is only the automatic link processor and frequency management system. It is not responsible for generating the traffic. ALIS is therefore somewhat of a misnomer. The modems generating the traffic are the GM857 and GM2000. Our suggestion is to stick with RS-ARQ as the system name."

↧
Viewing all 623 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>