sabato 4 febbraio 2017

QSL da Radio Freedom Smooth Jazz

Appena ricevuta la eQSL di Radio Freedom Italy Smooth Jazz, ascoltata stamani stamani su 6850 kHz con buon segnale e ottima musica.
Rapporto inviato a radio.freedom_2014(AT)

AM Rally 2017 ARRL

Vi informo che tra il 1 e 3 aprile pv ci sarà l’AM Rally, un contest per incoraggiare l’uso dell’AM in HF, sponsorizzato dalla ARRL.
Nel sito  ci sono tutte le informazioni necessarie.

Suggerito da I0FDH Riccardo


Le radio del 900   in mostra dal 2 al 12 febbraio presso il centro commerciale Aprilia2 (LATINA) 

mercoledì 1 febbraio 2017





Confronto tra il C4FM Fusion Yaesu e altri sistemi digitali (DMR, D-STAR)
Il C4FM e WIRES-X lato user (parlare in simplex, via ripetitore, il link, spostarsi tra le ROOM)
Accesso alla room ITALY attraverso altri sistemi Digitali
Il C4FM e WIRES-X lato amministratore di nodo (come installare, configurare e gestire un nodo WIRES-X e una ROOM)
WIRES-X Italia e altre realtà nel mondo.
Il DMR lato user (parlare attraverso i vari TALKGROUP)

Via Ponte dei Bari,5  51016 Montecatini Terme (Pistoia)

cars, chameleons, networks, and other stories (part 2)

i56578 SWL, Antonio 

In the first part of this post there were the cars, here are the chameleons: such name is not related to the ALE Addresses but rather to the configuration of the stations. A third part will follow in case of news or updates.
The two following networks, although they exhibit different behaviors, share some aspects which lead to think to the same source/organization or at least to the same Country. As said in the first part, the purpose is only hobbystic; sensitive and confidential messages contents, if any, are anyway not published. I'm interested on the way the "boxes" travel and NOT on their content.

AB net (5838.0 KHz, ...)
Stations and ALE addresses of this network are: ABD1, ABG6, ABF2, ABS5, ABK4, ABH3, and ABC7 that acts as net-control. Transmissions are scheduled on tuesday and thursday from about 0730 UTC and usually follow the schema link-send-terminate. Links are initiates by ABC7 and always in the same order, ie: ABD1 first then, ABG6, ABF2, ABS5, ABK4, and ABH3 as last. Other than 188-141A for ALE, STANAG-5066 is used for messaging and STANAG-4285 as HF waveform (fig. 1), settings are 1200bps and short interleaver. I monitored this net on 5838.0 KHz/USB, that seems to be the main channel, but other frequencies are also used.

fig. 1
In the firts loop, stations are contacted by ABC7 for a radio-check, then  in case the net-control has messages to send, the stations are again contacted and always in the same order. Sometimes the sending phase follows the radio-chek so that the stations are worked one time only, the sending is always preceeded by a voice-exchange of a pair of authentication keys according to the sequence diagram of fig. 2. A common phrasebook for telecommunications, in english, is strictly used.

fig. 2 - sequence diagram
The authentication keys consist of 4 numeric digits for the "my-auth-id" key and 2 numeric digits for the "auth-id" key , eg:

ABC7: alpha bravo x y this is alpha bravo charlie seven, authenticate 79
ABXY: alpha bravo charlie seven, this is alpha bravo x y, my authenticate 6843, authenticate 74
ABC7: this is alpha bravo charlie seven, my authenticate 2895
ABXY: ok send your message

A fter finishing sending the message, the net-control station asks the receiver peer to confirm the message-number then link is terminated and the next station in turn is contacted.

fig. 3 - 188-141A 3-way handshake and Auth keys exchange
The messaging system use the HBFTP protocol to deliver compressed e-mail files, COMSEC devices are not present (unclassified messages?) so, once removed STANAG-4285 and STANAG-5066 overheads, important clues and information can be drawn from an examination of the e-mail headers (fig. 4).

fig- 4
The sender and receiver stations belong to the e-mail domain 123 (point 1) and it's the common domain of all the stations of this network. The message has been received from, and by, the same host whose name is; "CROZ ESMTP/HMTP Gateway" most likely is the name of the STANAG-5066 application (point 2).  The IP address in the field "Received from" is or localhost (not wired to a LAN ?).
The hostname and the e-mail client fingerprint (point 4) clearly reveal that they use a Linux system, specifically: SUSE Linux 3.1.14. Indeed, the mention of chameleons I adopted  just derives from the official logo of SUSE.
The system language is the plain en-US without  language/keyboard customization.

The use of Linux is per se an interesting and peculiar element of this network, but it's not the only one.  The email includes one attached jpeg/image file whose name is "PRILOG 5 - PRILOG ZA SLANJE E-MAILA.jpg". This language suggest a Slavic origin (google-translator), as confirmed by the system timezone at point "3" (+0200), time-zone and especially the language restrict the candidate Countries to two: HIB and HRV. Anyway, the most surprising fact is that the e-mails I decoded have that same attached filename although it refers two images, in other words  they always use the same name for the attachments (fig. 5).

fig. 5 - two e-mails, different ricipients but same attached filename
On my side I can't rebuild the original images from the received S-5066 fragments but I can see at least the upper part of such images: they are always the same (fig. 6), although the image "B" is the most used in the attachments.

fig. 6
The reasons behind such way to comunicate are obscure: test? steganography?.., difficult to state unless speculations

In the above fig. 2 we have seen that the net-control stations asks a confirm of the received message-number: this a progressive number and matches the subject of the corresponding e-mail. The message-number is initialized to a new initial value at each day and assigned to the subject of the e-mail sent to the first station in the calling list (ie: ABD1, user1@asdf.123) and then is incremented by one at each step (fig. 7).

fig. 7
The choice of the initial value is apparently odd: fig. 8 is an example
06 Oct: initial value 600
11 Oct: initial value 603 
13 Oct: initial value 508
18 Oct: initial value 610  

fig. 8

5054 net (5054 KHz)
I spotted a QRG, 5054.0 KHz/USB, where stations of this network do not use 188-141A before messages sending and traffic is less frequent, not to say sporadic.  STANAG-5066 HMTP protocol is used instead of HBFTP (fig. 9) and, as for the AB-net, STANAG-4285 is the transporting HF waveform. The lack of the ALE phase is quite odd since the heard transmissions are not bcasts but rather PtP messages: or links are negotiated in other channels/way or receivers are always in listening state. For sure, no 188-141A means no ALE Addresses to collect from this network. 

fig. 9 - HMTP-66 protocol
By a quick examination of the e-mails headers (fig. 10) it's easy to see that this network belongs to the same organization/authority of the previous AB-net: same OS (Linux SUSE), same STANAG-5066 application (CROZ ESMTP/HMTP Gateway) and - above all - same attachment filename (PRILOG 5 - PRILOG ZA SLANJE E-MAILA.jpg) can't be a coincidence.

fig. 10

Addresses and origin/owner of the networks
I never heard e-mail exchanges between the two nets but only e-mails sent from linux-a5kz to the other stations of AB-net and e-mails sent from to other stations of 5054-net: this leds to think that these are the main stations of their respective networks. It's interesting to pay a look at the e-mail addresses of the two newtorks:

ALE  e-mail address
ABC7 user1@asdf.123
ABD1 user1@sdfg.123
ABG6 user1@dfgh.123
ABF2 user1@fghj.123
ABS5 user1@ghjk.123
ABK4 user1@jklp.123
ABH3      ?

  -  user1@aysxd.111
  -  user1@lost62.111
  -  user1@dres32.111
  -  user1@fejk8.111

As expected, the networks belong to two different e-mail domains "123" and "111": behind such choice there is surely a certain logic but unfortunately do not offer any clue for identification.
AB-net seems to use non-sense (?) alphabetical addresses (asdf, sdfg,...) while 5054-net seems to use a sort of "structured" names (lost62, dres,32, fejk8,...).  It's worth noting that the AB-net addresses, if listed in the order of the calling list,  exhibit a left-shift of 3 letters. According to this schema, ABH3 could have the address user1@klpq.123 (m,n,o seem to be not used).

A big help in the identification of the source is given by the examination of the collected STANAG-5066 nodes addresses:

ALE  Stanag-5066 address e-mail address
ABC7     user1@asdf.123 (ncs)
ABD1     user1@sdfg.123
ABG6     user1@dfgh.123
ABF2     user1@fghj.123
ABS5     user1@ghjk.123
ABK4     user1@jklp.123
ABH3          ?

  -     user1@aysxd.111 (ncs)
  -     user1@lost62.111
  -     user1@dres32.111
  -     user1@fejk8.111

About the assignments of the STANAG-5066 addresses, the global-regional blocks are defined by the 4 most-significant bits of the full length address (i.e., the first element w of the dotted-decimal form w.x.y.z): from fig. 11, 6.x.y.z is assigned to Europe. 

fig. 11
Within the global-regional blocks, specific 5066 addresses are assigned to individual Nations using the second element “x” of the dotted-decimal address form w.x.y.z.
Now, what european nation matches 6.8.y.z ?
The answer is in Table N-6 "National Address Schema" STANAG-5066 Edition 3 Annex N: 5066 is a NATO unclassified document that may circulated freely and is available on:
Sadly, no part of S-5066 Edition 3 can be published but the mentioned Table N-6 matches the "proposed allocations" which are visible at page 14 (here reported in fig. 12) of  a very interesting pdf file freely downloadable from: (note that NC3A, NATO C3 Agency, is now NCIA or NATO Communications and Information Agency).

fig. 12

It's worth noting that the stations dfgh.123 and aysxd.111 exhibit the same S-5066 address, i.e. the same node: as far as I know a certain S-5066 address should not be shared by two or more nodes (duplicate address) hence we face the same physical node. Looking at the "Received" headers of one e-mail sent by aysxd.111 (fig. 13) we see that the e-mail is originated (from) and received (by) the same host this means that the e-mail client and the S-5066 gateway application are running inside that same host. Moreover, the IP address (which refers the sender) is the address of the localhost: this means that the host, i.e. the S-5066 node, is not wired to a LAN.

fig. 13
Keeping in mind that a node is generally assumed to include the HF modem and radio (and cryptographic) equipment required for communications, a possible explanation could be the configuration in fig. 14, that also clarifies the lack of "cross-messaging" between AB-net and 5054-net: such traffic is handled "inside" the hosts. Unless they assigned the same S-5066 address to two distinct S-5066 nodes or use some other configuration that I do not know.

fig. 14
Rockwell-Collins HF Messenger allows a such configuration (fig. 15) in which two clients, belonging to different domains (i.e. two e-mail accounts), share the same S-5066 resource. Anyway, this is not our case since HFM only run on Windows-based pc and we face a Linux based nodes (SUSE Linux 3.1.14).

fig. 15

STANAG-5066 gateway application
The S-5066 application running in the Linux gateway nodes add the string "CROZ ESMTP/HMTP gateway" in the received-by header, most likely its "fingerprint":

It is an application that acts either as Extended SMTP server (on the LAN side) or as HMTP gateway (on the HF network side). They do not use a Stanag-5066 applications from the most "popular" manufacturers in the place:

IsodeIcon 5066**(development, not released)
Rohde & SchwarzR&S 5066*-(client part in Java)
Selex (Leonardo)MDH*-
Thales-*-(client part in Java)

but rather the MoD preferred to have a proprietary product, entrusting the development of the application to CROZ, an IT Company located in Zagreb and Belgrade, as contractor partner in the project. The result of this collaboration is the NATO Stanag-5066 compatible application named CroS5066 (fig. 16).

fig. 16 - CroS5066 schema
The mean features of the product can be read in their pubblication "CRO FYI" of  September 2009, page 14: the publication is available for reading and download on their web site: 
CroS5066 is fully interoperable with other S-5066 systems, positive tests were made during NATO exercises Combined Endeavor 2008 (Lager Aulenbachhere, Germany and Lora Naval Base in Split, Croatia).

(to be continued)

COMUNICARE VIA RADIO di Giacomo Menni - Download gratis

Comunicazione ricevuta da RRM

Questa guida, scritta da un utente "HOTEL" iscritto al Progetto, a differenza di molti altri documenti amatoriali presenti online, illustra fedelmente le procedure operative radio ufficiali che ben si prestano alle comunicazioni radio che avvengono sul CANALE 8-16 della RRM.

Oggi vi proponiamo un testo molto pratico, adatto a tutti, che non contiene nozioni tecniche sulle radiocomunicazioni ma solo linee-guida pratiche (alfabeto NATO, protocolli comunicativi, fraseologia convenzionale, etc.) tratte da fonti ufficiali internazionali, quindi niente prassi locali che a volte si ascoltano anche tra esperti radioamatori.

Scaricala da qui:

Ulteriori info:


Pirata russo su 7055 kHz e altri ascolti

Qualche ascolto a Milano con l'Elad FDM-S2 e il solito dipolo ripiegato. Questa volta sulla banda dei 40 metri (Ham) è spuntato un pirata russo nostalgico, con tante vecchie canzoni russe. 73, Giampiero

4885 30/1 1748 Echo of Hope, S.Korea, px to North Korea, talks, mx, fair //6348
4930 30/1 1739 VOA, Mopeng Hill, Botswana, reports, African lang., fair
4965 24/1 1820 Voice of Hope, Lusaka, Zambia, talks, religious mx, weak

6005 31/1 1730 Schweizer Radio SRF, Kall-Krekel, Germany, reports, in German, fair/good

6030 22/1 1935 Bible Voice, Nauen, Germany, English, religious talks, good
6065 22/1 1831 Voice of Hope, Lusaka, Zambia, religious, fair/good // 4965 After 1900 better, less QRM

6070 22/1 1940 R.Vaticana, S.Maria di Galeria, Holy Rosary in Latin, very good
6110 30/1 1612 Radio Fana, Ethiopia, talks, fair
6115 22/1 1920 Radio Congo, Brazzaville, songs, weak
6130 22/1 1927 TWR, Manzini, Swaziland, talks, rel songs, good
6130 30/1 1605 PBS Xizang, Tibet, China, English program, fair
6348 30/1 1748 Echo of Hope, S.Korea, px to North Korea, talks, mx, fair, LSB to avoid utility, //4885

7055 27/1 1515 Pirate radio, presumed Russian, LSB songs, talks, fair/good (tnx to A Borgnino)
7120 31/1 1850 Radio Hargheisa, Somaliland, Somalia, talks, fair

9460 27/1 1105 AWR, Agat, Guam, Russian, talks, weak/fair fading
9540.29 31/1 1830 Radio Cairo, Egypt, Italian px, really bad mod. not usable!
9570 30/1 1813 MWV New Life Station, Madagascar, Russian, tk, songs, good
9650 31/1 1836 Radio Guinée, Conakry, French, talks, songs, fair/good
9730 30/1 1818 Voice of Vietnam, Hanoi, Spanish px, reports, weak/fair
9760 27/1 1110 Radio Japan DRM, via UK, "Babcock DRM", perfect
9830 30/1 1826 Deutsche Welle, Sao Tome, African lang., reports, good
9925 30/1 1822 Radio Pilipinas, Tinang, talks in Tagalog, fair
980031/1 1842 LWF Sauti Linjilia, Issoudun, France, talks, Afr. lang. fair/good
9935 24/1 1935 Voice of Greece, Avlis, football live, fair QRM by TWR Swaziland 9940 very good

11520 27/1 1033 WEWN, Birmingham, AL, USA, Holy Rosary, English, good
11600 27/1 1037 Denge Kurdistan, via Maiac, Moldovia, drama, good
11735 30/1 1800 Zanzibar BC, Tanzania, time, id, news in English, LSB to avoid VoTurkey, fair
11750 27/1 1041 TWR, Station KTWR, Agana, Guam, talks Chinese, good
11860 27/1 1045 Republic of Yemen Radio, via Saudi Arabia, folk songs, fair
12065 27/1 1100 Radio Australia, Shepparton, news, weak
12075 30/1 1804 Afia Darfur Radio, S. Maria di Galeria, Vatican, AA talks, fair
12095 27/1 1052 FEBC, Bocaue, Philippines, songs, fair

13695 27/1 1028 AIR, Bengaluru, India, English bc, fair
15450 27/1 1000 AWR, Station KSDA, Agat, Guam, Chinese, good //17580
15760 27/1 1005 Radio Mashaal, Udon Thani, Thailand, Pastho, reports, fair
15825 30/1 1809 WWCR, Nashville, TN, USA, talks, weak

17580 27/1 1010 AWR, Station KSDA, Agat, Guam, Chinese, weak //15450
17630 27/1 1014 Radio Thailand, Udon Thani, Thai traditional songs, fair/good
17710 27/1 1020 Deutsche Welle, Meyerton, South Africa, reports, Swahili, weak, fading

lunedì 30 gennaio 2017

75bps Baudot encoding with 1.5 stop bits

Antonio i56578 SWL,

As in the age of the old-fashioned mechanical teletypes, still today some asynchronous communication systems run at 75 baud using frames consisting of 1 start bit, 5 (Baudot code) data bits, and 1.5 stop bits, i.e. the duration of the stop "signal" is 1.5 times the normal data bit duration. Although a single 7.5 bits length frame is quite easy to see in the time-domain,  its bit-oriented view is impossible at least in the tools at my disposal (unless to aggregate two consecutive frames and then get an integer number of 15 consecutive bits).
This difficulty about the representation of 7.5 bits frames may lead to misinterpretation and erros, as I did it (!) using SA/Bee to analyze what seemed a 150bps/500 Hz FSK burst transmission copied on 16155.0 Khz (cf). Speed was misured using the AM detector tool (Fig. 1)
Fig. 1
and once demodulated, each burst exhibits a 15-bit period (Fig. 2) 
Fig. 2
But the ACF tells a different story: the signal  is structured in 7.5 bits lenght frames each consisting of 1 start bit, 5 data bit and 1.5 stop bits and duration of ~100 msec (Fig. 3). This means ITA-2 coding, commonly referred to as Baudot, and a speed of 75 bps!
Fig. 3
As said, the impossibility to represent an "half bit" makes that two consecutive frames are considered and then either the speed and the period are misrepresented!
The transmission can be decoded using a common Baudot decoder and setting the right speed (75bps) and shift (500Hz): it consists of ten groups of 5 figures per burst, as shown in Fig. 4. Removing the five extra-bits (start e stop bits) from the 15-bit period stream we just get the 61 ITA2 5-bit characters of each burst.
Fig. 4
It's worth noting that things are worse trying to force the speed to 75 bps: one bit is lost  (Figs 5,6)
Fig. 5
By the way, the 1.5 bit lenght of the stop signal is derived from the design of early teletype machines, which was designed this way because the electromechanical technology of its day was not precise enough for synchronous operation: thus the systems needed to be re-synchronized at the start of each character while the stop duration gave the system time to recover before the next start signal.
Thanks to Cryptomaster for warning the (gross) error.