domenica 22 ottobre 2017

PETIZIONE - Base Bove, Sito Storico! Eretta da Renato Cepparo I2VZP


di Julius Fabbri IV3CCT

CQ, CQ, CQ YL and OM! Please, sign The International Petition to give an HSMs (Historic Sites and Monuments) status to the ruins of the first italian scientific station in Antarctica, called 'Giacomo Bove Station' (GBS). The Base was built by Renato Cepparo (I2VZP) on January 1976 and destroyed by the Argentine Navy on September 1976.  The goal and high significance is this: save the historic memory, underline the importance of respecting the Antarctic Treaty and stop an international indifference.Thank you, de Julius IV3CCT for II3BOVE (WAP - 271) in honor of I1SR MM (Mobile Marittimo). If you sign, the probability to receive a rare and special QSL after the DXpedition, will increase :) Please, give us a chance to win, thank you! Spread the word, please.
                                            *   *   *   *   *   *   *
La Base Giacomo Bove è stata eretta in Penisola Antartica dal Cav. Renato Cepparo nel 1976 e donata al governo italiano. Poco dopo la costruzione, la prima base scientifica italiana in Antartide è stata distrutta dalla Marina Militare argentina. Il sito è strategico, di pregio ambientale, ma lasciato nell'incuria e nell'abbandono. L’episodio è volutamente dimenticato (damnatio memoriae) e Cepparo messo al bando, invece d’esser insignito del titolo di Pater Patriae. È un’offesa per tutto il popolo italiano che la vicenda sia ancora ignorata dopo 42 anni. Con questa petizione Chiediamo che il governo italiano valuti di proporre la “Istituzione del Primo Sito Storico italiano in Antartide”, affinché sia preservata la memoria della presenza storica italiana in un’area strategica e di pregio, gestita da soli 5 (cinque) altri paesi. Ciò accrescerebbe il prestigio e l’influenza dell’Italia in campo internazionale, favorendo le cooperazioni scientifiche e, soprattutto, restituirebbe ai connazionali l’orgoglio d’essere italiani. Le autorità italiane ed argentine non rilasciano i documenti storci. L'Argentina, in particolare, non rivela dove siano nascosti i resti della Base che sarebbero ancora in un Container a Buenos Aires. Con l'istituzione del sito, si attuerebbe, dunque, l’istituto del FOIA (Freedom Of Information Act) calpestato dai funzionari preposti, con la complicità dei paesi aderenti al Trattato Antartico che, pur essendo informati, si girano dall’altra parte.
 Per realizzare il progetto, basterebbe che il Ministero degli Affari Esteri inviasse un'email (una proposta già redatta dall'Ass. cult. Adri-Antartica, in inglese) al Trattato Antartico (ATCM).

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

wrapper protocol MTU and data-block length 
As shown in Figure 1, if the length of the data-block is longer than the max allowed value (1977 bytes in this case) it is segmented into smaller blocks. The timestamp header in the segmented block remains unchanged while the current data-block number and the data-block length are updated. The data-blocks are not filled if their length is smaller then the maximum allowed value. [1]

Fig. 1
Moreover, the maximum lenght of the data-block changes according to the length of the Source/Dest IDs, as shown in Fig. 2
Fig. 2
Now let's have a look at a D_PDU which transports the wrapper protocol. The S-5066 D_PDUs are visible once removed the 188-110A overhead and synched the bitstream on the sequence 0xEB90 (all D_PDUs, regardless of type, begin with the same 16-bit synchronisation sequence).
As shown in Fig. 3, the Application Data, ie the data coming from the S-5066 client application (our wrapper protocol), begin just after the Application Identifier field of the UDOP/RCOP U_PDU. It's worth noting that  the Apllication Identifier is "0x8008", that just belongs to the values which are available for user-defined applications (S-5066 Annex F, table F5).
Fig. 3
So far I found the same 4-byte sequence "00 00 00 01" for both RCOP and UDOP protocols and, in my opinion, it is a sort of identifier of the wrapper protocol PDU (Fig. 4)

Fig. 4
Given the initial 4-byte "identifier" and the lengths of all the headers, the Maximun Transmission Unit (MTU) of wrapper protocol is equal to 2039 bytes for both RCOP and UDOP protocols:

ID{5,HWK01}{5,HWK01}{3,001}{3,002}{10,2367731361}{0}{1975,......}{0}
4 + 56 + 1975 + 4 = 2039 bytes

ID{5,HWK01}{3,VJL}{3,001}{3,002}{10,2223461543}{0}{1977,......}{0}
4 + 54 + 1977 + 4 = 2039 bytes

As for above, the maximum lenght of the data-block must vary according to the lenght of the sender/destination IDs and the used timestamp format (9 or 10 digits):

*10-digit timestamp {10,2367731361} (15-byte length)
1975 bytes (Dest ID = 5 bytes)
1977 bytes (Dest ID = 3 bytes)

*9-digit timestamp {9,nnnnnnnnn} (13-byte length)
1977 bytes (Dest ID = 5 bytes)
1979 bytes (Dest ID = 3 bytes)

It's interesting to note in Fig.5 that in case of use of UDOP protocol each D_PDU is transmitted twice unless the last. This makes sense to improve the reliability, since the nature of UDOP protocol itself (a basic connection-less protocol) and the use of S-5066 non-ARQ service.
Also note in Fig.5 that the C_PDU is segmented into 200-byte size C_PDU segments (each segment will be encapsulated in one D_PDU !): as you see, the overhead bytes added by C, S and U sublayers are present only in the first segment (although it's repeated).


Fig. 5
Curiosly, the used C_PDU-Segment size (200 bytes) is the same than the one used in the segmentation examples depicted in STANAG-5066 C.4.2 Edition 3, in our case the max size of C_PDU is 2051 bytes (Fig. 6).
Fig. 6

Since the Maximum C_PDU-Segment size within a D_PDU is a configurable parameter, the choice of a 200-byte size and the "double send" of the UDOP D_PDUs are probably a STANAG-5066 configuration implemented to support the wrapper protocol client. 

data block
Adding the data blocks to form a single file show a repeated 33-byte length pattern which precedes the "magic string", probably  a  common heading to all the messages (Fig. 7). As well as for the "magic string", it's difficult to say the scope of these sequences: indeed, further analysis will focus on the data block trying to get some meaningful. Recordings, help and tips are welcome!

Fig.7

Some interesting observations from the recent catches.

1. I had the chance to copy a transmission on 5206.3 KHz followed by an identical one on 5059.4 KHz after few seconds (Fig. 8). This is quite easy to accomplish since they use S-4538 FLSU for link setup, so the stations of the network are synched and scan the same pool of frequencies at same times. Repetitions increase the reliability of the system but do not know if it was just a planned episode or a routine scenario (more powerful monitoring tools would help...)

Fig.8

2. Usually transmissions are originated from nodes belonging to 006.046.000.zzz block (mostly HWK01) and directed to nodes of the 006.046.001.zzz block. This time I copied a trasmission inside the 006.046.001.zzz block (never copied so far), namely from BYN21 (006.046.001.006) to NZH21 (006.046.001.052).
As above: episode or a normal way to operate?

Fig.9

3. Luckily I copied some transmissions probably just few minutes after the start of a new epoch time of the timestamp clock and thus with a timestamp exhibiting a length of 7, 8 and then 9 bytes (Fig. 10). This is a full automated system working in a FIFO logic, ie the messages are wrapped and forwarded in the same order they arrive  (first came first served).  As well as for the IDs, the wrapper does not use a fixed length for the timestamp: it simply catches the value, computes its length and arrange them in the form {<length>,<content>}. This clarifies why so far I found transmissions with 9 and 10 bytes lengths.
As already debated, the variable lengths of IDs and timestamp affect the length of the data block since it shall be computed to fit the max transmission unit of the protocol (2039 bytes). 


Fig.10


STANAG-5066 Addresses and "Magic Strings"
heard so far:


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

[006.046.001.zzz] block
FRJ    006.046.001.001 *
BYN21  006.046.001.006 *
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
NZH21  006.046.001.052 *
VJL    006.046.001.054

ZAPCA
ZAPCG
ZAPCK
ZAPCH *
ZNTCH *
ZRTBC
ZRTBD
ZXPBC
ZXPBD
ZXPBG
ZXPCK
ZXPDA *
ZXPDK *

* new ones


Conferenza “ Meteorologia – Strumentazione e standard installativi” 27 Ottobre 2017 Savona


La Sezione di Savona dell’A.R.I. – Associazione Radioamatori Italiani, è lieta

di invitarti alla conferenza “ Meteorologia – Strumentazione e standard installativi”
che si terrà Venerdì 27 Ottobre 2017 , alle ore 20.30 presso il CRAL Porto in
Via dei Carpentieri, 5 a Savona.
Distinti saluti.
Presidente Sezione ARI Savona
Delio Coletti  I1JZV

venerdì 20 ottobre 2017

ANALOG FM : STEREO vs MONO - MYTHS and TRUTH

Most of the people think that FM Analog STEREO has better quality than MONO .
It depends what we intend for QUALITY .

If the parameters of QUALITY are :

A) DISTORTION
B) BANDWIDTH
C) SIGNAL TO NOISE RATIO

The reality is :

A) Distortion and bandwidth are the same in MONO and STEREO
B) Signal to Noise Ratio in much better in MONO ( in the range of around 20dB or higher !)
20 dB means that , to have the same S/N ratio from a STEREO signal respect to a Mono Signal , a power 100 times higher is needed .

The obvious advantage  in STEREO is that you have a " SPATIAL BIDIMENSIONAL IMAGE " .
In other words , you can perceive if the sound of different music components come from an arc Left - Center -Right .

The big disadvantage of STEREO vs. MONO is  the big loss  of Signal to Noise , that limits the STEREO coverage respect to the MONO coverage with the same Signal to Noise Ratio .

What is written here is well shown  in the following movie , where an FM Tuner that receive a signal in a fringe area of coverage is switched from STEREO to MONO .
Listening in STEREO is severely annoying , while the same signal in MONO is quite comfortable .
STEREO is when you have red light . MONO when you have blue light .
STEREO to MONO switch was made manually three times during the movie .
Please use as results the two second switching sessiones because the first time , when switching, there was also a change of program between speech and music .
Actually most of the receivers have a " Blending system "  that decides automatically when switching from STEREO to MONO , but in fringe areas this switching is annoying , so it is obvious that to avoid this , the only way is to broadcast MONO ....




The difference of S/N Ratio MONO/STEREO is well plotted in the following pictures taken from the ITU recommendations :

https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.412-9-199812-I!!PDF-E.pdf







Tropo DAB: Monaco e Nizza da Lerici


Ascolti DAB, direi grazie alla tropo: tra Lerici e Montemarcello, in provincia di La Spezia, Liguria, ho ricevuto i 2 mux di Monaco, molto bene con audio perfetto, e uno di Nizza, debole e con audio praticamente assente:


8A MCR1 Monaco, Mont Agel 4 kw

11A RNT Nice 1, Mont dee l'Ubac 12 kw

12B MCR2 Monaco, Mont Agel 4 kw



RX: Sony XDR-S41D con antenna stilo



giovedì 19 ottobre 2017

DAB & FM DXing sulla A15 Cisa: Trentino Alto Adige in digitale, Slovenia su 87.8 MHz


Prime prove di DAB DXing sull'Autostrada A15 della Cisa, senza dimenticare le FM

Con il Sony XDR-S41D appena acquistato mi sono fermato sulla Cisa, all'area di servizio Tugo Ovest, in provincia di Parma, poco prima di entrare in Toscana in galleria. Qui, alle 1430 locali del 14/10, ho ricevuto 4 mux dal Trentino Alto Adige, ritengo tutti da Cima Paganella in provincia di Trento:

10A Trentino DAB
10B RAS 1 DAB
10D RAS 2 DAB
12D DAB 1 TAA+


Il primo MUX, 10A, si riceveva proprio al limite. Bastava spostare un poco l'antenna e il segnale spariva. Gli altri tre invece arrivavano bene, senza problemi.

Il luogo degli ascolti DAB sulla A15 della Cisa
In FM invece ho ricevuto, finalmente, dopo un paio di anni di inseguimento, Radio Slovenia Val 2012 su 87.8 MHz alle 1530 locali. L'ascolto è avvenuto poco prima di Aulla, in Toscana, all'area di servizio San Benedetto Ovest. In passato, al massimo ho ricevuto qualche spezzone di audio per pochi secondi, una trentina al massimo. Questa volta ho seguito il programma di informazione, anche sportiva, per circa 40 minuti. Diversi annunci come "Radio Slovenia". Il trasmettitore deve essere

Asia e Africa in onde medie. Anche con i ricevitori portatili

1557 Taiwan & 918 AIR Suratgarh around 1630 UTC 17/10/2017 with Panasonic RF-2200 and AN-200 loop
Qualche ascolto in onde medie africano e orientale, a Bocca di Magra, in compagnia di Marzio Vizzoni e Michele D'Amico IZ2EAS. Ci siamo divertiti anche a fare DXing con tre ricevitori portatili con i quali siamo riusciti ad ascoltare Taiwan, India e altro ancora... grazie pure al piccolo ma efficiente loop AN-200 della Tecsun: Tecsun S-2000, Panasonic RF-2200, Tecsun PL.-660

Ecco alcuni ascolti, 73 Giampiero

AFRICA

840 15/10 1700 Dimtsh Hafash Eritrea songs Hoa fair

917 15/10 1810 Radio Yola, Nigeria, phone talks, fair (on other times good)

918 15/10 1803 Dimtsi Wegahta, Ethiopia, songs Hoa, fair

1550 14/10 2125 Saharawi Arab Dem. Rep. Nat. Radio, Rabouni, Arabic, fair S, QRM 1548


ASIA

918 16/10 1549 AIR Suratgarh, India, talks, weak but really clear

1188 14/10 2220 Radio Payam, Tehran, Iran, music, good

1242 14/10 2235 Radio Sultanate Oman, Arabic, songs, fair

1278 16/10 1810 Radio Sultanate Oman, talks, Arabic, fair/good

1269 14/10 2244 Radio Kuwait, Arabic, long talks, fair/good

1377 14/10 2120 CNR1 Yingyang-HEN, China, talks, songs weak/fair //4800

1521 16/10 1750 CRI, Urumqi, China, Russian, reports, music, fair //9470

1557 16/10 1650 RTI, Kouhu , Taiwan, talks, Chinese, fair

1566 14/10 2132 HLAZ FEBC, Jeju, South Korea, Korean, slow talks, good for few minutes

QTH: Bocca di Magra (Liguria. Italy)
RX: Winradio Excalibur Pro, Perseus, Tecsun S-2000, Panasonic RF-2200, Tecsun PL.-660
ANT: Wellbrook ALA1530LNP, MaxiWhip, loop Tecsun AN-200