Menu
▾
▴
wsjt-devel
|
From: Joe T. <jo...@pr...> - 2018-03-19 14:09:25
|
The WSJT Development Group is pleased to announce a third Release
Candidate of WSJT-X Version 1.9.0. A second release candidate,
v1.9.0-rc2, has been tested in the field over the past three weeks,
including a public test of FT8 DXpedition Mode conducted on March 6-7.
A General Availability (GA) release of v1.9.0 will be announced at a
suitable time, probably in the near future. After that time you should
stop using any -rc# release candidate.
Here’s a short list of features and capabilities added to WSJT-X since
Version 1.9.0-rc2:
1. Corrected a number of flaws in Fox behavior, FT8 DXpedition Mode
2. Allow Hounds to use compound callsigns in FT8 DXpedition Mode
3. Write debugging information to FoxQSO.txt
4. Fix the "Blue Decode Button" bug
5. Allow partial processing of incoming UDP Reply messages so that
non-CQ/QRZ decodes can be processed. The processing is the same as
double-clicking the same decoded message within WSJT-X except that
"Enable Tx" will not be enabled.
6. Send DX grid locator to wsjt_status.txt, for use by applications like
PstRotatorAZ
7. Correct the display of DXCC status of KG4 calls
8. Updated copy of cty.dat
9. Updates to documentation
10. Updated Hamlib functionality including changes to the Yaesu FT-817
back end that allows the uBITx kit transceiver to be CAT controlled
by WSJT-X.
10. Other minor bug fixes
###############################################################################
*Second Public Test of FT8 DXpedition Mode*
-------------------------------------------
If you decide to install v1.9.0-rc3, please help us by participating in
the second public test of FT8 DXpedition Mode scheduled for April 7.
Once again, the goal is to simulate a rare-DXpedition pileup by having
many stations ("Hounds") calling and trying to work a designated
pseudo-DXpedition station ("Fox"). Note that everyone participating in
the test *MUST* use WSJT-X v1.9.0-rc3. In addition, you must read,
understand, and carefully follow the instructions posted here:
http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf
Please be sure to read this document carefully, again. A few of its
details are different from the previous version.
If you have legitimate access to more than one callsign (spouse, club
call, or whatever) please feel free to call and work the Fox more than
once. We want the test pileup to be as deep as possible.
The scheduled test will take place as follows:
Date UTC Frequency Fox callsign Operator
---------------------------------------------------
April 7 1400 14.105 MHz W1/KH7Z N1DG
April 7 1500 14.105 W7/KH7Z AA7A
If last-minute instructions are necessary they will be announced on the
"Ping Jockey Relief" chat page:
http://www.pingjockey.net/cgi-bin/pingtalkB
###############################################################################
Installation packages for Windows, Linux, Macintosh, and Raspian Jessie
have been posted on the WSJT web site here:
http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
Scroll down to the bottom of the page to find a link to the installation
package for your system.
You can also download the packages from our SourceForge site:
https://sourceforge.net/projects/wsjt/files/
Please report any problems to email list
wsj...@li.... You must be a subscriber in order to
post there.
-- 73 from Joe, K1JT, for the WSJT Development Group
|
|
From: Saku <oh...@sr...> - 2018-03-19 16:36:49
|
Hi ! Just installed rc3. Found out that double click of non-cq decode on band activity sets general messages ready, but also makes TX enable RED. How ever TX is never fired. And receive period after that "goes over" like it does if TX would have been on during period. (what it actually has not) Red color disappears on next properly decoded RX period. Small cosmetic error for nice feature that replaces single click patch very well. I'll test later what happens if command comes via UDP. Assume it has same effect also then. Next testing schedule looks good when looking UTC times at this side of world. Thanks again for great program to whole team. -- Saku OH1KH |
|
From: Saku <oh...@sr...> - 2018-03-19 16:49:07
|
Sorry!!! Too busy to report! My fault. I had switched my digi-PTT line of while hunting 3C0W on 17m CW. (got it after 3 days of trying, would have been easier with FT8. No linear and just dipole here) I started to wonder because also double click on CQ did not fire TX but turned button red. Too many switches here :( So no problem. (Actually is because I liked the single click feature. But it is my problem, anyway.) Saku kirjoitti 19.03.2018 klo 18:36: > Hi ! > > Just installed rc3. > > Found out that double click of non-cq decode on band activity sets > general messages ready, but also makes TX enable RED. > How ever TX is never fired. > And receive period after that "goes over" like it does if TX would > have been on during period. (what it actually has not) > Red color disappears on next properly decoded RX period. > > Small cosmetic error for nice feature that replaces single click patch > very well. > I'll test later what happens if command comes via UDP. Assume it has > same effect also then. > > Next testing schedule looks good when looking UTC times at this side > of world. > > Thanks again for great program to whole team. |
|
From: Joe T. <jo...@pr...> - 2018-03-19 16:49:39
|
Hi Saku, I cannot reproduce the behavior you describe. The "double click of non-CQ decode" feature seems to work as expected, here. Please provide a step-by-step recipe that will reproduce your perceived problem. -- 73, Joe, K1JT On 3/19/2018 12:36 PM, Saku wrote: > Just installed rc3. > > Found out that double click of non-cq decode on band activity sets > general messages ready, but also makes TX enable RED. > How ever TX is never fired. I cannot reproduce the behavior you describe. The "double click on non-CQ decode" feature seems to work as expected, here. Please provide a step-by-step recipe that will reproduce your perceived problem. -- 73, Joe, K1JT |
|
From: Black M. <mdb...@ya...> - 2018-03-19 17:08:55
|
I can reproduce it. If Double-click on call option is on then clicking any non-cq in either WST-X window enables TX. From JTAlert don't see the beahvior.
Bill didn't apply my complete patch so needs to review it again to see if the other portions should be included as that behavior doesn't happen with the complete patch.
de Mike W9MDB
On Monday, March 19, 2018, 11:52:37 AM CDT, Joe Taylor <jo...@pr...> wrote:
Hi Saku,
I cannot reproduce the behavior you describe. The "double click of
non-CQ decode" feature seems to work as expected, here.
Please provide a step-by-step recipe that will reproduce your perceived
problem.
-- 73, Joe, K1JT
On 3/19/2018 12:36 PM, Saku wrote:
> Just installed rc3.
>
> Found out that double click of non-cq decode on band activity sets
> general messages ready, but also makes TX enable RED.
> How ever TX is never fired.
I cannot reproduce the behavior you describe. The "double click on
non-CQ decode" feature seems to work as expected, here.
Please provide a step-by-step recipe that will reproduce your perceived
problem.
-- 73, Joe, K1JT
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsj...@li...
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
|
|
From: Karza <oh...@sr...> - 2018-03-19 17:11:32
|
Hi Joe, Saku & all I have the same issue as Saku, double-clicking on non-CQ line immediately starts TXing. So if I see something like "CALL1 CALL2 RRR" and double click on that line, the program immediately ( not at start of next period ) goes to TX with message "CALL2 OH2GQC KP20" Is this the expected bahvior? I am running WSJT-X v1.9.0-rc3 on Ubuntu 16.04.4 LTS Cat is via Hamlib NET rigctl. BR Kari oh2gqc On 03/19/2018 06:49 PM, Joe Taylor wrote: > Hi Saku, > > I cannot reproduce the behavior you describe. The "double click of > non-CQ decode" feature seems to work as expected, here. > > Please provide a step-by-step recipe that will reproduce your perceived > problem. > > -- 73, Joe, K1JT > > On 3/19/2018 12:36 PM, Saku wrote: >> Just installed rc3. >> >> Found out that double click of non-cq decode on band activity sets >> general messages ready, but also makes TX enable RED. >> How ever TX is never fired. > > I cannot reproduce the behavior you describe. The "double click on > non-CQ decode" feature seems to work as expected, here. > > Please provide a step-by-step recipe that will reproduce your perceived > problem. > -- 73, Joe, K1JT > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > |
|
From: Karza <oh...@sr...> - 2018-03-19 18:44:43
|
Hi, I made a short video about the problem: https://youtu.be/jlyQsUZWwRk You can see that double-clicking on non-cq message immediately starts TX. 'Kari On 03/19/2018 07:11 PM, Karza wrote: > Hi Joe, Saku & all > > I have the same issue as Saku, double-clicking > on non-CQ line immediately starts TXing. > > So if I see something like > > "CALL1 CALL2 RRR" > and double click on that line, the program immediately > ( not at start of next period ) > goes to TX with message "CALL2 OH2GQC KP20" > > Is this the expected bahvior? > > I am running WSJT-X v1.9.0-rc3 on > Ubuntu 16.04.4 LTS > Cat is via Hamlib NET rigctl. > > BR > Kari oh2gqc > > > On 03/19/2018 06:49 PM, Joe Taylor wrote: >> Hi Saku, >> >> I cannot reproduce the behavior you describe. The "double click of >> non-CQ decode" feature seems to work as expected, here. >> >> Please provide a step-by-step recipe that will reproduce your perceived >> problem. >> >> -- 73, Joe, K1JT >> >> On 3/19/2018 12:36 PM, Saku wrote: >>> Just installed rc3. >>> >>> Found out that double click of non-cq decode on band activity sets >>> general messages ready, but also makes TX enable RED. >>> How ever TX is never fired. >> >> I cannot reproduce the behavior you describe. The "double click on >> non-CQ decode" feature seems to work as expected, here. >> >> Please provide a step-by-step recipe that will reproduce your perceived >> problem. >> -- 73, Joe, K1JT >> >> ------------------------------------------------------------------------------ >> >> >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> wsjt-devel mailing list >> wsj...@li... >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > |
|
From: Bill S. <g4...@cl...> - 2018-03-19 20:12:36
|
On 19/03/2018 17:11, Karza wrote: > Hi Joe, Saku & all > > I have the same issue as Saku, double-clicking > on non-CQ line immediately starts TXing. > > So if I see something like > > "CALL1 CALL2 RRR" > and double click on that line, the program immediately > ( not at start of next period ) > goes to TX with message "CALL2 OH2GQC KP20" > > Is this the expected bahvior? > > I am running WSJT-X v1.9.0-rc3 on > Ubuntu 16.04.4 LTS > Cat is via Hamlib NET rigctl. > > BR > Kari oh2gqc Hi Karl, this is normal behaviour. It is up to you to only double-click a decode when you know that calling them is not going to cause QRM. The normal use would be to tail-end a QSO rather than waiting for them to call CQ. As with other modes you must be confident that it is either their frequency or you are calling them offset so that you do not QRM the other station they just worked. The transmit is immediate because you have just decoded them on their period and you are transmitting back to them on the other period. 73 Bill G4WJS. |
|
From: Saku <oh...@sr...> - 2018-03-19 18:18:11
|
Oops! Posted this with wrong sender address. This should now go to list: Sakari Nylund kirjoitti 19.03.2018 klo 20:10: > HI all! > > As I said: My apologies for too fast reporting. As explained on my > 2nd message it was my PTT line switched off. Sorry. > > I have now written an update to cqrlog where I used that non-cq > feature and it works as expected: sets std messages, but does not fire > TX. > What Karza writes came up also to my mind: > > Why double click on non-cq in "band activity" fires TX ? > It would be good that it just loads std messages. Nothing else. Or > that firing TX could be enabled or disabled in this case via > configuration, or check box. > That would make it like "single click" feature. > > The update to cqrlog has no proper purpose, just tried it. I can not > figure any true need for this in external program. > Actually if I would like to produce "single click" like feature via > cqrlog I had to write a new copy of "band activity" window to it. > And that is stupid copying. > > I have not used JTAlert ever (no need, I have same features in cqrlog) > but I have feeling that it collects all heard calls from band (not > just cqs) and makes "needed list" from them. I that case there is need > for this kind of feature (?) to initiate std messages for needed > (non-cq) call. > > So back to question: why double click on "band activity" should fire > TX (and disturb ongoing qso) ? > -- Saku OH1KH |
|
From: Joe T. <jo...@pr...> - 2018-03-28 17:35:54
|
The second public test of FT8 DXpedition mode will be conducted on April 7, a little over a week from now. You are cordially invited to join us for this test. See the original announcement (copied below) for details. Even if you read it before, be sure to read the latest revision of the *FT8 DXpedition Mode User Guide.* It is dated March 28 and is available here: http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf There are some changes from previously posted instructions! I draw your particular attention to the following sentences found on page 1: ############################################################################ Please note: DXpedition Mode is not yet ready for “production” use. Until WSJT-X v1.9.0 is fully released, this mode should be used only in controlled test situations. Please remember to send us your test results. ... Subject to future revision, we are temporarily suggesting the following frequencies for testing DXpedition mode: 1.8265, 3.567, 7.066, 10.1405, 14.105, 18.095, 21.067, 24.911, 28.067 MHz. ############################################################################ The first warning is included because several operators or groups have been trying, against our advice, to use the not-yet-complete DXpedition Mode in real pileup situations. This misuse of a WSJT-X beta release (or of code taken from the WSJT-X development branch) has been counter-productive, to say the least. The second item copied above is the result of early efforts to identify suggested FT8 DXpedition Mode operating frequencies for each HF band that will minimize interference with other modes. We will welcome thoughtful suggestions that might improve this list of suggested frequencies. We hope to see you in the pileups calling W1/KH7Z and W7/KH7Z on 14.105 MHz, 1400-1600 UTC on April 7! -- 73, Joe, K1JT On 3/19/2018 10:09 AM, Joe Taylor wrote: > The WSJT Development Group is pleased to announce a third Release > Candidate of WSJT-X Version 1.9.0. A second release candidate, > v1.9.0-rc2, has been tested in the field over the past three weeks, > including a public test of FT8 DXpedition Mode conducted on March 6-7. > > A General Availability (GA) release of v1.9.0 will be announced at a > suitable time, probably in the near future. After that time you should > stop using any -rc# release candidate. > > Here’s a short list of features and capabilities added to WSJT-X since > Version 1.9.0-rc2: > > 1. Corrected a number of flaws in Fox behavior, FT8 DXpedition Mode > > 2. Allow Hounds to use compound callsigns in FT8 DXpedition Mode > > 3. Write debugging information to FoxQSO.txt > > 4. Fix the "Blue Decode Button" bug > > 5. Allow partial processing of incoming UDP Reply messages so that > non-CQ/QRZ decodes can be processed. The processing is the same as > double-clicking the same decoded message within WSJT-X except that > "Enable Tx" will not be enabled. > > 6. Send DX grid locator to wsjt_status.txt, for use by applications like > PstRotatorAZ > > 7. Correct the display of DXCC status of KG4 calls > > 8. Updated copy of cty.dat > > 9. Updates to documentation > > 10. Updated Hamlib functionality including changes to the Yaesu FT-817 > back end that allows the uBITx kit transceiver to be CAT controlled > by WSJT-X. > > 10. Other minor bug fixes > > > ############################################################################### > > *Second Public Test of FT8 DXpedition Mode* > ------------------------------------------- > > If you decide to install v1.9.0-rc3, please help us by participating in > the second public test of FT8 DXpedition Mode scheduled for April 7. > Once again, the goal is to simulate a rare-DXpedition pileup by having > many stations ("Hounds") calling and trying to work a designated > pseudo-DXpedition station ("Fox"). Note that everyone participating in > the test *MUST* use WSJT-X v1.9.0-rc3. In addition, you must read, > understand, and carefully follow the instructions posted here: > http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf > > Please be sure to read this document carefully, again. A few of its > details are different from the previous version. > > If you have legitimate access to more than one callsign (spouse, club > call, or whatever) please feel free to call and work the Fox more than > once. We want the test pileup to be as deep as possible. > > The scheduled test will take place as follows: > > Date UTC Frequency Fox callsign Operator > --------------------------------------------------- > April 7 1400 14.105 MHz W1/KH7Z N1DG > April 7 1500 14.105 W7/KH7Z AA7A > > If last-minute instructions are necessary they will be announced on the > "Ping Jockey Relief" chat page: > http://www.pingjockey.net/cgi-bin/pingtalkB > ############################################################################### > > > Installation packages for Windows, Linux, Macintosh, and Raspian Jessie > have been posted on the WSJT web site here: > http://physics.princeton.edu/pulsar/k1jt/wsjtx.html > Scroll down to the bottom of the page to find a link to the installation > package for your system. > > You can also download the packages from our SourceForge site: > https://sourceforge.net/projects/wsjt/files/ > > Please report any problems to email list > wsj...@li.... You must be a subscriber in order to > post there. > > -- 73 from Joe, K1JT, for the WSJT Development Group |
|
From: Hasan al-B. <hba...@gm...> - 2018-03-28 18:39:43
|
Excellent, Look forward to it, Joe. 73, N0AN Hasan On Wed, Mar 28, 2018 at 12:35 PM, Joe Taylor <jo...@pr...> wrote: > The second public test of FT8 DXpedition mode will be conducted on April > 7, a little over a week from now. You are cordially invited to join us for > this test. See the original announcement (copied below) for details. > > Even if you read it before, be sure to read the latest revision of the > *FT8 DXpedition Mode User Guide.* It is dated March 28 and is available > here: > http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf > There are some changes from previously posted instructions! > > I draw your particular attention to the following sentences found on page > 1: > ############################################################ > ################ > Please note: DXpedition Mode is not yet ready for “production” use. Until > WSJT-X v1.9.0 is fully released, this mode should be used only in > controlled test situations. Please remember to send us your test results. > > ... > > Subject to future revision, we are temporarily suggesting the following > frequencies for testing DXpedition mode: 1.8265, 3.567, 7.066, 10.1405, > 14.105, 18.095, 21.067, 24.911, 28.067 MHz. > ############################################################ > ################ > > The first warning is included because several operators or groups have > been trying, against our advice, to use the not-yet-complete DXpedition > Mode in real pileup situations. This misuse of a WSJT-X beta release (or > of code taken from the WSJT-X development branch) has been > counter-productive, to say the least. > > The second item copied above is the result of early efforts to identify > suggested FT8 DXpedition Mode operating frequencies for each HF band that > will minimize interference with other modes. We will welcome thoughtful > suggestions that might improve this list of suggested frequencies. > > We hope to see you in the pileups calling W1/KH7Z and W7/KH7Z on 14.105 > MHz, 1400-1600 UTC on April 7! > > -- 73, Joe, K1JT > > > On 3/19/2018 10:09 AM, Joe Taylor wrote: > >> The WSJT Development Group is pleased to announce a third Release >> Candidate of WSJT-X Version 1.9.0. A second release candidate, v1.9.0-rc2, >> has been tested in the field over the past three weeks, including a public >> test of FT8 DXpedition Mode conducted on March 6-7. >> >> A General Availability (GA) release of v1.9.0 will be announced at a >> suitable time, probably in the near future. After that time you should >> stop using any -rc# release candidate. >> >> Here’s a short list of features and capabilities added to WSJT-X since >> Version 1.9.0-rc2: >> >> 1. Corrected a number of flaws in Fox behavior, FT8 DXpedition Mode >> >> 2. Allow Hounds to use compound callsigns in FT8 DXpedition Mode >> >> 3. Write debugging information to FoxQSO.txt >> >> 4. Fix the "Blue Decode Button" bug >> >> 5. Allow partial processing of incoming UDP Reply messages so that >> non-CQ/QRZ decodes can be processed. The processing is the same as >> double-clicking the same decoded message within WSJT-X except that >> "Enable Tx" will not be enabled. >> >> 6. Send DX grid locator to wsjt_status.txt, for use by applications like >> PstRotatorAZ >> >> 7. Correct the display of DXCC status of KG4 calls >> >> 8. Updated copy of cty.dat >> >> 9. Updates to documentation >> >> 10. Updated Hamlib functionality including changes to the Yaesu FT-817 >> back end that allows the uBITx kit transceiver to be CAT controlled >> by WSJT-X. >> >> 10. Other minor bug fixes >> >> >> ############################################################################### >> >> *Second Public Test of FT8 DXpedition Mode* >> ------------------------------------------- >> >> If you decide to install v1.9.0-rc3, please help us by participating in >> the second public test of FT8 DXpedition Mode scheduled for April 7. Once >> again, the goal is to simulate a rare-DXpedition pileup by having many >> stations ("Hounds") calling and trying to work a designated >> pseudo-DXpedition station ("Fox"). Note that everyone participating in the >> test *MUST* use WSJT-X v1.9.0-rc3. In addition, you must read, understand, >> and carefully follow the instructions posted here: >> http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf >> >> Please be sure to read this document carefully, again. A few of its >> details are different from the previous version. >> >> If you have legitimate access to more than one callsign (spouse, club >> call, or whatever) please feel free to call and work the Fox more than >> once. We want the test pileup to be as deep as possible. >> >> The scheduled test will take place as follows: >> >> Date UTC Frequency Fox callsign Operator >> --------------------------------------------------- >> April 7 1400 14.105 MHz W1/KH7Z N1DG >> April 7 1500 14.105 W7/KH7Z AA7A >> >> If last-minute instructions are necessary they will be announced on the >> "Ping Jockey Relief" chat page: >> http://www.pingjockey.net/cgi-bin/pingtalkB >> ############################################################################### >> >> >> Installation packages for Windows, Linux, Macintosh, and Raspian Jessie >> have been posted on the WSJT web site here: >> http://physics.princeton.edu/pulsar/k1jt/wsjtx.html >> Scroll down to the bottom of the page to find a link to the installation >> package for your system. >> >> You can also download the packages from our SourceForge site: >> https://sourceforge.net/projects/wsjt/files/ >> >> Please report any problems to email list wsj...@li.... >> You must be a subscriber in order to post there. >> >> -- 73 from Joe, K1JT, for the WSJT Development Group >> > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > |
|
From: Jay H. <ka...@mt...> - 2018-03-29 11:18:58
|
Is the suggested Dxpedition frequency 1.8265 a typo? That would put it right in the middle of the CW DX window on 160m. Surely a frequency of 1.836 would be a better choice IMHO. Jay KA9CFD -----Original Message----- From: Joe Taylor <jo...@pr...> Sent: March 28, 2018 17:36 To: WSJT software development <wsj...@li...> Subject: Re: [wsjt-devel] WSJT-X v1.9.0-rc3: Testing of FT8 DXpedition Mode The second public test of FT8 DXpedition mode will be conducted on April 7, a little over a week from now. You are cordially invited to join us for this test. See the original announcement (copied below) for details. Even if you read it before, be sure to read the latest revision of the *FT8 DXpedition Mode User Guide.* It is dated March 28 and is available here: http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf There are some changes from previously posted instructions! I draw your particular attention to the following sentences found on page 1: ############################################################################ Please note: DXpedition Mode is not yet ready for “production” use. Until WSJT-X v1.9.0 is fully released, this mode should be used only in controlled test situations. Please remember to send us your test results. ... Subject to future revision, we are temporarily suggesting the following frequencies for testing DXpedition mode: 1.8265, 3.567, 7.066, 10.1405, 14.105, 18.095, 21.067, 24.911, 28.067 MHz. ############################################################################ The first warning is included because several operators or groups have been trying, against our advice, to use the not-yet-complete DXpedition Mode in real pileup situations. This misuse of a WSJT-X beta release (or of code taken from the WSJT-X development branch) has been counter-productive, to say the least. The second item copied above is the result of early efforts to identify suggested FT8 DXpedition Mode operating frequencies for each HF band that will minimize interference with other modes. We will welcome thoughtful suggestions that might improve this list of suggested frequencies. We hope to see you in the pileups calling W1/KH7Z and W7/KH7Z on 14.105 MHz, 1400-1600 UTC on April 7! -- 73, Joe, K1JT On 3/19/2018 10:09 AM, Joe Taylor wrote: > The WSJT Development Group is pleased to announce a third Release > Candidate of WSJT-X Version 1.9.0. A second release candidate, > v1.9.0-rc2, has been tested in the field over the past three weeks, > including a public test of FT8 DXpedition Mode conducted on March 6-7. > > A General Availability (GA) release of v1.9.0 will be announced at a > suitable time, probably in the near future. After that time you > should stop using any -rc# release candidate. > > Here’s a short list of features and capabilities added to WSJT-X since > Version 1.9.0-rc2: > > 1. Corrected a number of flaws in Fox behavior, FT8 DXpedition Mode > > 2. Allow Hounds to use compound callsigns in FT8 DXpedition Mode > > 3. Write debugging information to FoxQSO.txt > > 4. Fix the "Blue Decode Button" bug > > 5. Allow partial processing of incoming UDP Reply messages so that > non-CQ/QRZ decodes can be processed. The processing is the same as > double-clicking the same decoded message within WSJT-X except that > "Enable Tx" will not be enabled. > > 6. Send DX grid locator to wsjt_status.txt, for use by applications > like > PstRotatorAZ > > 7. Correct the display of DXCC status of KG4 calls > > 8. Updated copy of cty.dat > > 9. Updates to documentation > > 10. Updated Hamlib functionality including changes to the Yaesu FT-817 > back end that allows the uBITx kit transceiver to be CAT > controlled > by WSJT-X. > > 10. Other minor bug fixes > > > ###################################################################### > ######### > > *Second Public Test of FT8 DXpedition Mode* > ------------------------------------------- > > If you decide to install v1.9.0-rc3, please help us by participating > in the second public test of FT8 DXpedition Mode scheduled for April 7. > Once again, the goal is to simulate a rare-DXpedition pileup by having > many stations ("Hounds") calling and trying to work a designated > pseudo-DXpedition station ("Fox"). Note that everyone participating > in the test *MUST* use WSJT-X v1.9.0-rc3. In addition, you must read, > understand, and carefully follow the instructions posted here: > http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf > > Please be sure to read this document carefully, again. A few of its > details are different from the previous version. > > If you have legitimate access to more than one callsign (spouse, club > call, or whatever) please feel free to call and work the Fox more than > once. We want the test pileup to be as deep as possible. > > The scheduled test will take place as follows: > > Date UTC Frequency Fox callsign Operator > --------------------------------------------------- > April 7 1400 14.105 MHz W1/KH7Z N1DG April 7 1500 > 14.105 W7/KH7Z AA7A > > If last-minute instructions are necessary they will be announced on > the "Ping Jockey Relief" chat page: > http://www.pingjockey.net/cgi-bin/pingtalkB > ###################################################################### > ######### > > > Installation packages for Windows, Linux, Macintosh, and Raspian > Jessie have been posted on the WSJT web site here: > http://physics.princeton.edu/pulsar/k1jt/wsjtx.html > Scroll down to the bottom of the page to find a link to the > installation package for your system. > > You can also download the packages from our SourceForge site: > https://sourceforge.net/projects/wsjt/files/ > > Please report any problems to email list > wsj...@li.... You must be a subscriber in order > to post there. > > -- 73 from Joe, K1JT, for the WSJT Development Group ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ wsjt-devel mailing list wsj...@li... https://lists.sourceforge.net/lists/listinfo/wsjt-devel |
|
From: Joe T. <jo...@pr...> - 2018-03-29 13:57:47
|
Hi Jay, On 3/29/2018 6:52 AM, Jay Hainline KA9CFD wrote: > Is the suggested Dxpedition frequency 1.8265 a typo? That would put it right in the middle of the CW DX window on 160m. Surely a frequency of 1.836 would be a better choice IMHO. Thanks for catching this error. Not a typo, exactly, but 1.8265 is the likely CW (not FT8) frequency for the KH1 DXpedition. They are not currently planning to use FT8 on 160m. For now, I will simply delete 1.8265 from the list of suggested FT8 DXpedition frequencies. Do you have a suggestion for something else for 160m? 1.836 would clobber the WSPR sub-band. 1.843 or thereabouts might be OK, except for JA. JA will need something like 1.900, I believe. -- 73, Joe, K1JT |
|
From: Jay H. <ka...@mt...> - 2018-03-29 14:22:52
|
That's a touchy one Joe. The JA's have been using 1908 for their FT8 window. Anything above 1845 you start running into SSB stations. Maybe 1838 to be just above the WSPR. I know you will run into the established 1840 FT8 but a compromise will be needed. Another choice maybe is 1833 for dxpedition mode. Maybe that might work. I hope some other TB dxers could chime in. Jay KA9CFD -----Original Message----- From: Joe Taylor <jo...@pr...> Sent: March 29, 2018 13:58 To: WSJT software development <wsj...@li...> Subject: Re: [wsjt-devel] WSJT-X v1.9.0-rc3: Testing of FT8 DXpedition Mode Hi Jay, On 3/29/2018 6:52 AM, Jay Hainline KA9CFD wrote: > Is the suggested Dxpedition frequency 1.8265 a typo? That would put it right in the middle of the CW DX window on 160m. Surely a frequency of 1.836 would be a better choice IMHO. Thanks for catching this error. Not a typo, exactly, but 1.8265 is the likely CW (not FT8) frequency for the KH1 DXpedition. They are not currently planning to use FT8 on 160m. For now, I will simply delete 1.8265 from the list of suggested FT8 DXpedition frequencies. Do you have a suggestion for something else for 160m? 1.836 would clobber the WSPR sub-band. 1.843 or thereabouts might be OK, except for JA. JA will need something like 1.900, I believe. -- 73, Joe, K1JT ---------------------------------------------------------------------------- -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ wsjt-devel mailing list wsj...@li... https://lists.sourceforge.net/lists/listinfo/wsjt-devel |
Thanks for helping keep SourceForge clean.
X