To see what this is all about, go here:
https://www.hfunderground.com/board/index.php/topic,32334.0.htmlAll transmissions received in Denver, CO, USA using an SDRplay RSP2pro and a 1m diameter homebrewed magnetic loop antenna
Latest update: 31 July 2017, 16:00 UTC
Date (DDMMYYYY): Numbers: File name or repeat: Frequency (kHz) and time(UTC):
01/07/2017 76127 12327612.txt * 11530 1700
48762 81054876.txt *
06621 64770662.txt *
10843 08031084.txt *
51773 65525177.txt *
14054 42011405.txt *
Note - the signal of the "morning" broadcasts (UTC 1600, 1700, and 1800) is generally poor to fair out where I live in the western USA. It was better during the winter months but tends to be noisier and weaker in summer. So I was suprised when, at about 1745, the signal suddenly jumped way up in signal strength. Not SIO 555 or anything, but a dramatic enough shift to make me wonder about the power. Pedro's known for patching RHC and having trouble with his PC, but I can't say that I've noticed an issue like this before.
* these files were first transmitted in June, in fact HM01 has been transmitting the same number groups and files since June 23. Please see June HM01 log for info, and also for a link to the files. They will not be included in July's folder.
https://www.hfunderground.com/board/index.php/topic,35238.0.htmlDate (DDMMYYYY): Numbers: File name or repeat: Frequency (kHz) and time(UTC):
02/07/2017 76127 repeat 11435 1600
48762 repeat
06621 repeat
10843 repeat
51773 repeat
14054 repeat
June 23's numbers.
03/07/2017 76127 repeat 11635 1800
48762 repeat
06621 repeat
10843 repeat
51773 repeat
14054 repeat
June 23's numbers.
04/07/2017 76127 repeat 11635 1800
48762 repeat
06621 repeat
10843 repeat
51773 repeat
14054 repeat
June 23's numbers.
05/07/2017 76127 repeat 11435 1600
48762 repeat
06621 repeat
10843 repeat
51773 repeat
14054 repeat
June 23's numbers.
06/07/2017 86671 60468667.txt 16180 2200 **
48763 repeat
06621 repeat
10844 repeat
51774 repeat
14055 repeat
Progressing by one day, rather than playing catch-up.
** Transmitted on 16180 for both 2100 and began again for 2200. 16180 cut off suddenly at 2206. It did not reappear until 22:14, when it began already in progress on 17480.
Date (DDMMYYYY): Numbers: File name or repeat: Frequency (kHz) and time(UTC):
07/07/2017 86672 repeat 11435 1600
48764 repeat
06622 repeat
10845 repeat
51775 repeat
14056 repeat
Finally progressing one digit like it's supposed to.
08/07/2017 86673 repeat 11435 1600
48765 repeat
06623 repeat
10846 repeat
51776 repeat
14057 repeat
Transmission began at 1557 reading yesterday's numbers. At 1558, a second recording began with today's numbers. The two ran together for almost two minutes, before the recording with yesterday's numbers stopped. There were numerous Windows sounds heard during those three minutes.
Date (DDMMYYYY): Numbers: File name or repeat: Frequency (kHz) and time(UTC):
09/07/2017 86674 repeat 11435 1600
48766 repeat
06624 repeat
10847 repeat
51777 repeat
14058 repeat
UPDATED 1710 UTC. Broadcast on 11435 began at 1600 with two recordings playing simultaneously, which ceased at 1601. A single recording began, but it was 7 July's numbers (in other words, the final digit in each number group is subtracted by one, rather than added).
I tuned in again to 11530 at 1700 and noted that the last digits in each number group are now progressed +1 as should be expected, rather than repeating 8 July's or regressing to 7 July's, as happened at 1600. No new number groups or files sent. Everything is updated for this date.
Date (DDMMYYYY): Numbers: File name or repeat: Frequency (kHz) and time(UTC):
10/07/2017 86675 repeat 11435 1600
48767 repeat
06625 repeat
06221 50300622.txt
51778 repeat
14059 repeat
Broadcast began at 1557 UTC with number groups from 9 July with the final digit advanced by +2 (no new number groups), but after a minute it restarted with the final digit advanced +3, and with one new number group. WILL UPDATE when I can decode the new file, which is often difficult for me with this broadcast. The 1700 broadcast on 11530 usually has a stronger signal out my way.
UPDATE: received file
Date (DDMMYYYY): Numbers: File name or repeat: Frequency (kHz) and time(UTC):
11/07/2017 86675 repeat 11435 1600
48767 repeat
06625 repeat
06221 repeat
51778 repeat
14059 repeat
No transmission til 1612, at which time it was RHC in Spanish, not HM01. This cut off after about 75 seconds, Windows computer sound heard at 1614. Just an empty carrier for two minutes, then it started the broadcast from the top with 10 June's number groups. Windows sound copied at 1617. Broadcast suddenly restarted at 1628, the likely reason being that that put the broadcast back on schedule. Still 10 July's numbers.
UPDATE FOR 11 JULY:I tuned in late to the 2200 UTC transmission for 17840, and Pedro appears to have updated the numbers sometime between now and the 1700 transmission (which I copied on 11530, despite not logging it here). The problem is that I couldn't catch all the groups while scrambling to get DIGTRX going and referring back to my notes, and I'm not sure if the order of the number groups is the same, so I will check again tonight at 0500. But I THINK that the groups are as follows:
Date (DDMMYYYY): Numbers: File name or repeat: Frequency (kHz) and time(UTC):
11/07/2017 61901 40326190.txt 17480 2200
48768 repeat
06626 repeat
06221 repeat
06221 50300622.txt
07511 45660751.txt
NOTE: I forgot to tune in for the 0500 transmission to see what was happening. But I did hear that the number groups during the 2200 transmission were out of order (e.g., 61901 was formerly the last group, and was now the first.) So based on the 12 July / 1600 transmission, I'm fairly confident that the number groups and files now listed for 11 July / 2200 is accurate. I should get confirmation with 13 July's transmission, but will also tune in this afternoon to the 2100 or 2200 broadcast.
Please also note that there are now TWO different number groups, 0622#, which are associated with different files and began being sent on different dates.
Date (DDMMYYYY): Numbers: File name or repeat: Frequency (kHz) and time(UTC):
12/07/2017 61901 repeat 11435 1600
10661 03031066.txt
06627 repeat
06222 repeat
06221 repeat
07511 repeat
13/07/2017 61902 repeat 11530 1700
10661 repeat
06628 repeat
06223 repeat
06222 repeat
07512 repeat
14/07/2017 61903 repeat 11435 1600
10662 repeat
06629 repeat
06224 repeat
06223 repeat
07513 repeat
Transmission began early (approx. 15:54, but didn't see exactly when) and gave 13 July's numbers. It restarted at 15:58 with the correct number groups.
15/07/2017 61900 repeat 17480 2200
48768 repeat
06626 repeat
06221 repeat
06221 repeat
07511 repeat
Repeating
11 July's numbers. I tuned in to several different broadcasts just to make sure that Pedro wasn't going to realize his mistake and put in the proper ones.
16/07/2017 61905 repeat 11635 1800
10664 repeat
72071 64307207.txt
06226 repeat
06225 repeat
07515 repeat
Also tried during 1700 (11530) and 1800 (11635) transmissions, but signal was fair at best for all three broadcasts. Finally got the file during the 2200 (10715) broadcast.
Date (DDMMYYYY): Numbers: File name or repeat: Frequency (kHz) and time(UTC):
17/07/2017 61906 repeat 11435 1600
10665 repeat
72072 repeat
06227 repeat
06226 repeat
07516 repeat
18/07/2017 90241 32409024.txt 11435 1600
10666 repeat
72073 repeat
06228 repeat
06227 repeat
07517 repeat
1600 transmission at 11435 is very weak, which is typical for my QTH in the summertime anyway. I wasn't able to get a good enough signal to decode the new file until the 1800 broadcast on 11635.
19/07/2017 90242 repeat 11435 1600
10667 repeat
72074 repeat
82851 60158285.txt
06228 repeat
11581 86021158.txt
Very strong carrier (S9+10) up at 1555. Audio began at 1556, but was severely undermodulated. It sounded as if two recordings were being played simultaneously. Audio came up to proper modulation (as proper as Cuba can make it) at 1601. However, due to various instances of bad luck (whether it was DIGTRX crashing just as that RDFT was being sent, or SDRuno freezing up because of some resource grab on my PC), I wasn't able to get one of the files decoded until the 1800/11635 broadcast.
Date (DDMMYYYY): Numbers: File name or repeat: Frequency (kHz) and time(UTC):
20/07/2017 90243 repeat 16180 2100
10668 repeat
72075 repeat
82851 repeat
06229 repeat
11581 repeat
21/07/2017 90244 repeat 11435 1600
10669 repeat
72076 repeat
82852 repeat
82151 36168215.f1g
11582 repeat
22/07/2017 90244 repeat 10345 0600 (23 July)
10669 repeat
72076 repeat
82852 repeat
82151 repeat
11582 repeat
Repeating 21 July's number sets and files.
23/07/2017 90244 repeat 11435 1600
10669 repeat
72076 repeat
82852 repeat
82151 repeat
11582 repeat
Repeating 21 July's number sets and files. (Will check back later in the day to see if that changes.)
Date (DDMMYYYY): Numbers: File name or repeat: Frequency (kHz) and time(UTC):
24/07/2017 90244 repeat 11435 1600
10669 repeat
72076 repeat
82852 repeat
82151 repeat
11582 repeat
Repeating 21 July's number sets and files.
25/07/2017 90244 repeat 11435 1600
10669 repeat
72076 repeat
82852 repeat
82151 repeat
11582 repeat
Repeating 21 July's number sets and files.
HOWEVER....25/07/2017 90248 repeat 10860 0500 (26 July)
61843 35746184.txt
58101 80535810.txt
82856 repeat
82154 repeat
11586 repeat
Once again, at some point during the HM01 broadcast "day" (which supposedly begins with the 1600 broadcast and ends with the 1000 of the following UTC day), Pedro got the transmission up to date, and started with this set of numbers with two files not previously sent.
Date (DDMMYYYY): Numbers: File name or repeat: Frequency (kHz) and time(UTC):
26/07/2017 37631 72403763.txt 11435 1600
61844 repeat
58101 repeat
82857 repeat
82155 repeat
11587 repeat
So far this seems to show that HM01's "day" is still supposed to begin with the 1600 UTC transmission.
27/07/2017 37631 repeat 11530 1700
61845 repeat
58102 repeat
02801 41850280.txt
82156 repeat
11588 repeat
28/07/2017 37632 repeat 11435 1600
61846 repeat
58103 repeat
02801 repeat
82157 repeat
11589 repeat 27090 71462709.txt
HM01 changed the last number set at some point today 7/28, while leaving the rest unchanged. It definitely sent 11589 during the 1600/11435 and 1700/11530 broadcasts. I noticed the new set during the 2100/11635 set and copied the file during the 2200/10715 transmission.
Date (DDMMYYYY): Numbers: File name or repeat: Frequency (kHz) and time(UTC):
29/07/2017 37633 repeat 11435 1600
61847 repeat
58104 repeat
02802 repeat
82158 repeat
27091 repeat
30/07/2017 37634 repeat 11435 1600
80181 74728018.txt
58105 repeat
02803 repeat
38301 70423830.txt
27092 repeat
31/07/2017 37635 repeat 11435 1600
80181 repeat
58106 repeat
02804 repeat
38301 repeat
27093 repeat