Discussion in 'Amateur Radio News' started by IW2BSF, Mar 2, 2018.
thanks for the specifics.
I think we should probably not overextend the good things about FT8. Yes, it can get a signal through at low power and difficult conditions, but JT65 and JT9 is clearly better, while they take 4x the time. The minimal messages conveyed in WSJT-X modes cannot be expected to have more than very limited use in emergency communication and only in quite unique situation. When SSB doesn't work and CW isn't known, quite a few elegant digimodes, like Olivia and Contestia, have been developed for weak signal conditions. Although they require better SNR than the WSJT-X modes, they have excellent abilities in getting a signal through, and at "baud rates" and particularly message contents well above FT8, JT65, JT9, etc. Applications like Winlink add to it.
Remenber, the WSJT-X modes are made for very specific purposes. Message content and baud rate (except for the fast scatter modes) are not among them. So, let's praise FT8 for what it is good at, and be very realistic on everything else.
Same thing about FT8 Dxpedition mode: made for very special situations, with very specific instructions, which will require time, understanding and practice to be followed by all users. It looks promising, although still only in beta testing. Time will show how it fares; my prediction is that it will "go live" working well, level the field between big guns and small pistols, teach us many interesting lessons on propagations, and be fun.
73 de Frode LA6VQ
It's interesting to see that the new DXpedition mode is already in use and most FT8 users can't communicate with the DX station.
Currently, TY7C, The Benin dxpedition 2018 By F6KOP, is on 40 meters at the lower end of the fT8 'band' and 283 from the bottom.
The instructions of the TY7C QRZ web page state that they will use dxpedition mode.
It's really too bad that the author did not use a PW to prevent the use of the FOX mode until the final release of the package.
With open source code, I guess a password would soon be removed. A password would also be much more exciting to break, so I believe it wouldn't help much.
The FT8 DXpedition mode is developed for very specific and limited use, involving multi-operator high volume DXpeditions to very rare locations (like KH1 Baker for which it is intended), involving a very high number of callers, heavy pileups, etc. As such I find it difficult to beta test without exposing it to similar conditions, like last week's test. Now the test results must be evaluated, bugs fixed, more testing, more bug fixing, and eventually a general release, to be used by big dx-peditions to really rare entities.
The FT8 DXpedition mode is specifically not to be used in ordinary FT8 frequencies, and therefore comes with an intrusion into frequencies normally used by other digimodes. This "feature" alone very clearly states, at least to me, that FT8 DXpedition mode shall be used only in exceptional case. If this mode will be limited to the really big dx-peditions to the rarest DXCC entities remains to be seen, but it should clearly not be used in your average IOTA-expedition to some Caribbean DXCC entity, activated every year, or a QSO party, field day, SOTA, NPOTA, 13 States, or any other proposal for use in regular, repeated activities. And certainly not for contests, blatantly breaching the contest rule of not more than one signal on any band at any time.
73 de Frode LA6VQ
I saw a spot last night that TY7C was using the DX-pedition mode, so I downloaded the new release and read how to use it. It took me about 20 minutes to get in log on 80M FT8, from the time I saw the spot.
FYI - TY7C reportedly is using FT8 DXped mode as a Fox, but so far when I have observed them they are only xmitting one frequency slot data stream. Compared to the recent OTA beta test where the Foxes were transmitting multiple slots (3-5).
And yes, they are on the "normal" FT8 channels, not on the alternate channels designated for use in the beta test. And by xmiting with only one stream, their observed QSO rate was a fraction of what was seen in the beta test, not much better, if any, then achievable using "normal" FT8 mode.
I am currently using WSJT-X v1.9.0 r8533 beta software. It allows switching between "normal" FT8 and DXped mode.
My first FT8 QSO with TY7C was on 30m @ 0039Z 3/9. It was confusing. At first, with them xmting only one stream low in the channel, it seemed it was "normal" FT8, but then I saw some xmsns containing data consistent with DXped mode.
I tried DXped mode but didn't get response, and saw then make some QSO's in what appeared to be "normal" data format. So I switched back to "normal" FT8 mode.
They were not weak, -11db at my end, and my xmtr output was 100w. However, call and call as I did, I had no joy. Then I noted their DT was being reported as >1.5 differential. My PC clock was exact per Time.is. So I tweaked my PC clock a bit manually just using the Win7 utility to better sync with them. That way I was able to get the DT down to 0.2.
Then I was able to pretty quickly made a full QSO. However, I was NOT using FT8 DXped mode, it was just "normal" FT8 with manual selection of TX1 and TX3. So there appears to be compatibility between the DXped mode and "normal" mode if manipulated correctly.
On 3/15 I made another FT8 QSO with them on 40m. That time I did not have to adjust my PC clock (it was again "exact") and again I used "normal" FT8 mode, not DXped Hound.
OH and TY7C is also in-the-log four times on CW and once on RTTY (no tally-ho required)
Best DX and 73, John, WØPV
So you are implying many MSK144 meteor scatter contacts are invalid according to IARU, as reports are not exchanged in contest mode and most operators stop at RRR. Yet for some unknown reason, we still get credit and awards for those contacts via ARRL and other organizations.
That's an unnecessarily low blow.
Good point. I also question the stated IARU position regarding signal reports and QSO validity.
Not just MSK144 but ALL modes in both the ARRL and CQ VHF contests require only the exchange of grid square data. Same is true in the Stew Perry Top Band Distance Challenges.
In the CQ VHF a signal report is specifically to be excluded from any submitted log. In the ARRL and Stew Perry it is only optional.
No RST in the ARRL Sweepstakes exchange either! Many operating events do not require signal reports.
Sergio and John,
Near the top of this discussion, Dave W7UUU elmered me that I should make myself acquainted with the entire context of the comments made in the discussion. I think elmering is one of the best elements of ham radio, and I am happy to pay it forward.
1. I do not imply anything. I am referring. If you you want to draw any implications from the information provided, feel free, as long as you present them as your implications, not mine.
2. This is a discussion on the on the air test on HF of the FT8 DXpedition mode. It involves no other mode than FT8, nor other part of the frequency spectrum than HF.
3. As a reply to a direct question from KL1T, I provided a direct reference. KL1T seemed to be satisfied as he "liked" the reply.
4. The information provided comes from an IARU Region 1 meeting in Sun City, South Africa in 2011, and from the very person who presented the proposal. The exact wording can be found in the Region 1 HF Managers Handbook chapter 2-1, page 2 (the 9th page of the pdf document), downloadable from https://iaru-r1.org/index.php/downloads/func-startdown/776/
For the benefit of the readers I quote:
A valid contact is one where both operators during the contact have
1. mutually identified each other
2. received a report, and
3. received a confirmation of the successful identification and the reception of the report.
It is emphasized that the responsibility always lies with the operator for the integrity of the contact.
In chapter 2-1, page 3 (page 10 of the document), it states that for "report" the RST system is recommended, with the addition of the RSQ system for digimodes below 30 MHz.
Although IARU works to harmonize the three IARU regions, the different regions may have slightly differing wordings of their requirements for an HF QSO, but I believe they all include call sign, report and confirmation that the call sign and report have been received. You may want to check the definition for your IARU region.
5. Award issuers can issue their awards with whatever requirements they want. I believe there are very few award issuers today that require signal reports for a QSO to qualify for their awards, including ARRL for DXCC. However, I remember I saw many years ago that for one award that an RS of minimum 33 was required. Validity for an award is no guarantee that the QSO meets the IARU requirements.
6. Contest-makers can require whatever contest exchange they want, which may or may not include a signal report. Validity for a contest is no guarantee that the QSO meets the IARU requirements.
The above is relevant for my response to KL1T's question.
***Now some comments to your message.
7. MSK144 and VHF has nothing to do in this discussion on the HF on the air test of FT8 DXpedition mode.
However, since you bring it up, I'd add some comments:
8. MSK144 seems to be developed by professors Franke & Taylor, the developers of FT8. In the MSK144 part of WSJT-X instruction manual, it appears that the contents of an MSK144 QSO are quite similar to those of an FT8 QSO, and that an MSK144 QSO includes signal reports in the SNR format.
9. The IARU Region 1 requirements for a valid VHF QSO are identical to the requirements for at HF QSO. You will find them in Section 4.1 (page 46/159 according to the page numbering) of the IARU Region 1 VHF Handbook, which you find in https://www.iaru-r1.org/index.php/vhfuhsshf/1737-vhf-manager-handbook-version-8-00 . It appears in section 4.4.9 that the requirements for a meteor scatter QSO are similar to other QSOs (Call sign, report, confirmation of call sign and report). While the two-digit reporting system is different from the RST (as described in section 126.96.36.199), it is still a report, and required for a valid QSO. You may want to check whether your region maintains a similar definition of a VHF QSO.
10. If you read my reply to KL1T, you will find that I say exactly that the formalities are completed when RRR has been received. Finishing off with a 73 is still considered polite and good behaviour, though. Just to keep this message near the topic of this discussion, FT8 DXpedition mode QSOs should also stop at RRR, and move on to the next caller. However, I have noticed from various reports from the on the air test that the software kept repeating RRR messages, apparently expecting a 73 to complete the QSO.
11. If you, under certain circumstances like a contest, want to perform MSK144 QSOs with a different format and content than advised by WSJT-X, please do. However, I believe that your choice will not change the quite clear and easy-to-understand requirements for a valid QSO. And, the contest parts of VHF Handbook clearly states that a report should be part of the exchange. That may vary in your region.
12. What becomes a valid QSO for an award or a contest, is determined by what you and your QSO partner choose to put into a QSL card, a GCR list or an LoTW, eQSL or log upload. I believe that ARRL's DXCC or other award programs, other award issuers or contest makers are in no position to redefine the IARU requirements for a "valid QSO", so the fact that you receive awards/contests credit from them for non-report QSOs, pertains only to their awards/contests, not to its status as a valid QSO. If award/contest credit is your goal, its fine with me. If you want to apply stricter standards, that is fine as well.
13. If you and your QSO partner QSL or upload as a valid QSO, a QSO that included no report, that is entirely on you and him/her. However, that brings forward the final part of the IARU requirements for a valid HF and VHF QSO:
"It is emphasized that the responsibility always lies with the operator for the integrity of the contact."If everybody comply with this emphasized reminder of integrity, everything should be OK. If not, repairing any issue with the integrity of the contact is the choice of the operator. I believe its unlikely that non-repair would have any consequences for the operator, other than lowering the standard of integrity.
73 de Frode LA6VQ