Re: [wsjt-devel] qt5_use_modules no longer available in Fedora Rawhide
On 31/05/2018 21:43, Richard Shaw wrote:
While trying to build wsjtx 1.9.1 I got a build error. It looks like
the long depreciated qt5_use_modules macro has been removed from the
release of qt5 in Fedora Rawhide.
I made some simple changes as recommended[1], here's an example snippet:
@@ -1343,7 +1343,8 @@ else ()
)
endif ()
endif ()
-qt5_use_modules (wsjtx SerialPort) # not sure why the interface link
library syntax above doesn't work
+find_package(Qt5SerialPort)
+target_link_libraries (wsjtx Qt5::SerialPort) # not sure why the
interface link library syntax above doesn't work
# make a library for WSJT-X UDP servers
# add_library (wsjtx_udp SHARED ${UDP_library_CXXSRCS})
The find_package stuff could probably go higher up in the
CMakeLists.txt but this approach in a couple of places allowed me to
build 1.9.1.
Thanks,
Richard
KF5OIM
[1] https://doc.qt.io/archives/qt-5.10/cmake-manual.html
Hi Richard,
this will probably have to be a patch for now as the version of Qt we
use on some platforms (5.5) does not have full implicit dependency
support for some of the Qt modules, in particular QtSerialPort. I
suspect we may be stuck with Qt5.5 for a while, until Ubuntu 16.04 LTS
gets to end of life amongst others.
73
Bill
G4WJS.
--
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
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt_status.txt
It's a typowsjtx_status.txt %TEMP%\WSJT-X\wsjtx_status.txt de Mike W9MDB On Thursday, May 31, 2018, 4:12:59 PM CDT, Pino Zollo wrote: I am running th 1.9.1 since a couple of days, but I can not locate the file wsjt_status.txt as stated in http://physics.princeton.edu/pulsar/k1jt/New_Features_1.9.1.txt - DX grid locator sent to wsjt_status.txt, for use by applications like PstRotatorAZ 73 Pino ZP4KFX -- 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 wsjt-devel@lists.sourceforge.net 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] wsjt_status.txt
I am running th 1.9.1 since a couple of days, but I can not locate the file wsjt_status.txt as stated in http://physics.princeton.edu/pulsar/k1jt/New_Features_1.9.1.txt - DX grid locator sent to wsjt_status.txt, for use by applications like PstRotatorAZ 73 Pino ZP4KFX -- 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] working stations over 10000 km on 6m
On 5/31/2018 9:43 AM, Joe Taylor wrote: Of course this could be done in FT8. But as I emphasized in a previous email, we did not want to use a different solution for FT8 and MSK144. As currently implemented, MSK144 has no spare bits. Two thoughts. First, aren't FT8 and MSK144 designed for very different kinds of propagation? If so, couldn't FT8 use one of those spare bits to indicate contest mode? Second, my concern is the same as Ned's -- it took me several cycles to see that window (on a different monitor), and I lost control of WSJT-X until I found it I clicked on No. ALL I want is to NOT have to acknowledge it and continue on my merry way. AND -- every time this guy called me with a weird grid (he was probably in contest mode), I got the same notice. In other words, I don't need the bit, just not to have the notice window stop me in my tracks. 73, Jim K9YC -- 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] qt5_use_modules no longer available in Fedora Rawhide
While trying to build wsjtx 1.9.1 I got a build error. It looks like the
long depreciated qt5_use_modules macro has been removed from the release of
qt5 in Fedora Rawhide.
I made some simple changes as recommended[1], here's an example snippet:
@@ -1343,7 +1343,8 @@ else ()
)
endif ()
endif ()
-qt5_use_modules (wsjtx SerialPort) # not sure why the interface link
library syntax above doesn't work
+find_package(Qt5SerialPort)
+target_link_libraries (wsjtx Qt5::SerialPort) # not sure why the interface
link library syntax above doesn't work
# make a library for WSJT-X UDP servers
# add_library (wsjtx_udp SHARED ${UDP_library_CXXSRCS})
The find_package stuff could probably go higher up in the CMakeLists.txt
but this approach in a couple of places allowed me to build 1.9.1.
Thanks,
Richard
KF5OIM
[1] https://doc.qt.io/archives/qt-5.10/cmake-manual.html
--
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
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Start time, not end time, logged
According to my LOTW account it's the start time being recorded in the QSO...not the end time. On Thursday, May 31, 2018, 12:17:40 PM CDT, Tom Melvin wrote: Hi I much prefer the start time - if it takes me 30 mins to work a station I am ‘on the air’ for 30 mins - a) I need to log this to stay legal and b) it allows me to see historically how long QSO;s take. 73’s Tom GM8MJV On 31 May 2018, at 16:36, Steve London wrote: > Version 1.9.0 > > When making a difficult QSO, many minutes can pass between the time the QSO > was initiated and the QSO was completed. These are identified in the log > screen as "Start Time" and "End Time". Currently, when a QSO is logged, the > Start Time is placed in the ADIF file, and sent to clients such as N1MM+. > This is not standard for logging programs, and will lead to non-QSO time > mismatches in LoTW. The End Time should be written to the ADIF file and sent > to clients. > > 73, > Steve, N2IC > > -- > 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 > wsjt-devel@lists.sourceforge.net > 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 wsjt-devel@lists.sourceforge.net 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Start time, not end time, logged
LoTW allows a mismatch of up to 30 minutes. This issue bit me yesterday during the 6 meter JA opening: - Called a station, no response. - Took a 30 minute break, without working another station. - Called the same station, worked him. Was very surprised to see the QSO time reported to N1MM+ as the start time, 31 minutes earlier. This is different than every other logging program which records the QSO time as the end time, not the start time. 73, Steve, N2IC On 05/31/2018 10:47 AM, Tom Melvin wrote: Hi I much prefer the start time - if it takes me 30 mins to work a station I am ‘on the air’ for 30 mins - a) I need to log this to stay legal and b) it allows me to see historically how long QSO;s take. 73’s Tom GM8MJV On 31 May 2018, at 16:36, Steve London wrote: Version 1.9.0 When making a difficult QSO, many minutes can pass between the time the QSO was initiated and the QSO was completed. These are identified in the log screen as "Start Time" and "End Time". Currently, when a QSO is logged, the Start Time is placed in the ADIF file, and sent to clients such as N1MM+. This is not standard for logging programs, and will lead to non-QSO time mismatches in LoTW. The End Time should be written to the ADIF file and sent to clients. 73, Steve, N2IC -- 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 wsjt-devel@lists.sourceforge.net 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] A nano-feature request
In the midst of all of the pondering about what to do with the >1mi QSO's (nb. I made one to JA last night. Quite a thrill!) is it possible to make the contents of the "Hold TX Frequency" checkbox sticky when changing from FT8 DXpedition mode or from MSK144 back to "normal" FT8? I find myself acting very noobie when I forget to re-check the box upon re-entering standard FT8. I know...It's only a click away... Very low priority... 73, Ted K9IMM -- 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] working stations over 10000 km on 6m
On 5/31/2018 1:16 PM, George Molnar wrote: Would a unique CQ message for contest mode work, or is that asking for confusion? Normal mode: CQ KF2T FM18 Contest mode: CX KF2T FM18 The contest community is smaller than the general population, so it might be an easier “sell." *George J Molnar* Arlington, Virginia, USA KF2T - FM18lv Confusion, to be sure. But that's not the real problem. To understand the real problem you need to understand the way JT-style structured messages fit all the necessary information into 72 bits. If you care, a good place to start would be Reference #4 here: http://physics.princeton.edu/pulsar/k1jt/refs.html "CQ KF2T FM18" is a standard JT-style structured message. "CX KF2T FM18" is a free-text message. Double clicking on it will not start a QSO. The problem is not the contest community. Serious contesters know what to do. Casual operators who get on during the contests are the important target audience here. One final point. Structured messages are essential to the extreme sensitivity of WSJT-X modes, nd to packing all that user information into 72 bits. Consider the following message, an example of messages frequently exchanges in EME QSOs: KA1ABC WB9XYZ EN37 OOO Like all other standard messages in WSJT-X, this 22-character message is conveyed in 72 bits -- effectively 3.273 bits per character. Conveying the same message on a character-by-character bases would need ~120 bits, and the loss in sensitivity would be 10*log10(120/72) = 2.2 dB. We don't give away even tenths of a dB without serious thought and the promise of major advantages. -- 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Start time, not end time, logged
On 31/05/2018 16:36, Steve London wrote: Version 1.9.0 When making a difficult QSO, many minutes can pass between the time the QSO was initiated and the QSO was completed. These are identified in the log screen as "Start Time" and "End Time". Currently, when a QSO is logged, the Start Time is placed in the ADIF file, and sent to clients such as N1MM+. This is not standard for logging programs, and will lead to non-QSO time mismatches in LoTW. The End Time should be written to the ADIF file and sent to clients. 73, Steve, N2IC Hi Steve, the following fields are included in the WSJT-X ADIF log file: QSO_DATE TIME_ON QSO_DATE_OFF TIME_OFF They are derived from the "Log QSO" window's start date-time and end date-time fields respectively. so I am not sure what issue you are referring to. 73 Bill G4WJS. -- 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] working stations over 10000 km on 6m
I think that might be a good solution Bill as NA contest mode is pretty much a "VHF/UHF/Microwave feature". 73 Jay. KA9CFD Sent from my U.S.Cellular© Smartphone Original message From: Bill Somerville Date: 5/31/18 12:08 (GMT-06:00) To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] working stations over 1 km on 6m On 31/05/2018 17:43, Joe Taylor wrote: On 5/31/2018 12:22 PM, Jay Hainline wrote: Joe, is it possible to use one of the extra FT8 bits as a flag that you are transmitting in contest mode or not? Would that be useful to keep the program on the receiving end from being confused? 73 Jay KA9CFD Of course this could be done in FT8. But as I emphasized in a previous email, we did not want to use a different solution for FT8 and MSK144. As currently implemented, MSK144 has no spare bits. Casual operators can get confused enough with type of "NA VHF Contest: mode, let alone two different ones. -- Joe, K1JT Hi Joe and Jay, perhaps we should only have the automatic detection of NA contest mode messages when "Enable VHF/UHF/Microwave features" is enabled. That way user could set up a configuration for 6m multi-hop Es operating that will not get confused by such long DX. 73 Bill G4WJS. -- 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] working stations over 10000 km on 6m
Would a unique CQ message for contest mode work, or is that asking for confusion? Normal mode: CQ KF2T FM18 Contest mode: CX KF2T FM18 The contest community is smaller than the general population, so it might be an easier “sell." George J Molnar Arlington, Virginia, USA KF2T - FM18lv > On May 31, 2018, at 1:08 PM, Bill Somerville wrote: > > On 31/05/2018 17:43, Joe Taylor wrote: >> On 5/31/2018 12:22 PM, Jay Hainline wrote: >>> Joe, is it possible to use one of the extra FT8 bits as a flag that you are >>> transmitting in contest mode or not? Would that be useful to keep the >>> program on the receiving end from being confused? >>> >>> 73 Jay KA9CFD >> >> Of course this could be done in FT8. But as I emphasized in a previous >> email, we did not want to use a different solution for FT8 and MSK144. >> As currently implemented, MSK144 has no spare bits. >> >> Casual operators can get confused enough with type of "NA VHF Contest: mode, >> let alone two different ones. >> >> -- Joe, K1JT > Hi Joe and Jay, > > perhaps we should only have the automatic detection of NA contest mode > messages when "Enable VHF/UHF/Microwave features" is enabled. That way user > could set up a configuration for 6m multi-hop Es operating that will not get > confused by such long DX. > > 73 > Bill > G4WJS. > -- > 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 > wsjt-devel@lists.sourceforge.net > 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Start time, not end time, logged
Hi I much prefer the start time - if it takes me 30 mins to work a station I am ‘on the air’ for 30 mins - a) I need to log this to stay legal and b) it allows me to see historically how long QSO;s take. 73’s Tom GM8MJV On 31 May 2018, at 16:36, Steve London wrote: > Version 1.9.0 > > When making a difficult QSO, many minutes can pass between the time the QSO > was initiated and the QSO was completed. These are identified in the log > screen as "Start Time" and "End Time". Currently, when a QSO is logged, the > Start Time is placed in the ADIF file, and sent to clients such as N1MM+. > This is not standard for logging programs, and will lead to non-QSO time > mismatches in LoTW. The End Time should be written to the ADIF file and sent > to clients. > > 73, > Steve, N2IC > > -- > 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 > wsjt-devel@lists.sourceforge.net > 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Start time, not end time, logged
On 05/31/2018 05:36 PM, Steve London wrote: Hi Steve & All, > When making a difficult QSO, many minutes can pass between the time the > QSO was initiated and the QSO was completed. These are identified in the > log screen as "Start Time" and "End Time". Currently, when a QSO is > logged, the Start Time is placed in the ADIF file, and sent to clients > such as N1MM+. This is not standard for logging programs, and will lead > to non-QSO time mismatches in LoTW. The End Time should be written to > the ADIF file and sent to clients. In an ADIF record, there is a start time AND an end time. Unfortunately, the ADIF spec doesn't specify which ones are necessary or mandatory. To be sure, the best is to insert both, so that the matching can be tried on both. In the past, I have mentioned twice a problem occurring with WSJT-X, when the logging window is popped up because of the setting of the option in the config. In this window, the end time is already set to the current time although the QSO has not ended at this time. Depending on the condx, the real ending time can be minutes later. On good condx, it is usually 30 s later. I have proposed two alternative solutions to solve this problem: The first one is to add a button named "set the end time to now", in the logging window. The second one is to add a button named "set the end time to now and save". Please excuse me to use such long text for the button. I have tried to explain the function. Perhaps the development team can examine my proposal again. Best wishes, Claude (DJ0OT) -- 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] working stations over 10000 km on 6m
On 31/05/2018 17:43, Joe Taylor wrote: On 5/31/2018 12:22 PM, Jay Hainline wrote: Joe, is it possible to use one of the extra FT8 bits as a flag that you are transmitting in contest mode or not? Would that be useful to keep the program on the receiving end from being confused? 73 Jay KA9CFD Of course this could be done in FT8. But as I emphasized in a previous email, we did not want to use a different solution for FT8 and MSK144. As currently implemented, MSK144 has no spare bits. Casual operators can get confused enough with type of "NA VHF Contest: mode, let alone two different ones. -- Joe, K1JT Hi Joe and Jay, perhaps we should only have the automatic detection of NA contest mode messages when "Enable VHF/UHF/Microwave features" is enabled. That way user could set up a configuration for 6m multi-hop Es operating that will not get confused by such long DX. 73 Bill G4WJS. -- 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] working stations over 10000 km on 6m
On 5/31/2018 12:22 PM, Jay Hainline wrote: Joe, is it possible to use one of the extra FT8 bits as a flag that you are transmitting in contest mode or not? Would that be useful to keep the program on the receiving end from being confused? 73 Jay KA9CFD Of course this could be done in FT8. But as I emphasized in a previous email, we did not want to use a different solution for FT8 and MSK144. As currently implemented, MSK144 has no spare bits. Casual operators can get confused enough with type of "NA VHF Contest: mode, let alone two different ones. -- 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] working stations over 10000 km on 6m
Joe, is it possible to use one of the extra FT8 bits as a flag that you are transmitting in contest mode or not? Would that be useful to keep the program on the receiving end from being confused? 73 Jay KA9CFD Sent from my U.S.Cellular© Smartphone Original message From: Joe Taylor Date: 5/31/18 10:34 (GMT-06:00) To: WSJT software development Subject: Re: [wsjt-devel] working stations over 1 km on 6m Hi Jay, Ned, and all, On 5/30/2018 8:57 PM, Jay Hainline KA9CFD wrote: > We had a big opening to JA today on 6m. Some of the contacts were over > 10,000 km and I have heard some ops report their WSJT-X software would hang > up asking if they want to switch to contest mode. Apparently the program > sees the grid from JA and thinks they are in contest mode? I don't have much > more details. Maybe someone can chime in or advise if this would be a bug > that needs fixed. > > Jay Hainline KA9CFD Ned AA7A wrote: > This happened to me at the most inopportune time. I was sending a signal > report to DS4AOW for a ATNO on 6m and it sent a NA Contest TX3 exchange > instead of what was expected. The only way I could clear the problem was to > change the mode to to anything other than FT8 and then back to get the right > TX3 message. While I was sorting that all out, the band faded and I did not > complete. > > It's rare to hear stations over 10 KM, so this is a hard thing to test. Jay KA9CFD wrote: > Hopefully the developers will have some insight. I never have like the idea >of using the opposite side of the world grid to represent an R-grid contest >report. Causes confusion for non-contesters, and some bad side effects >apparently. :-) Contesters pleaded for an easy way to send "R+grid" rather than "R+rpt" in the message sequence. They wanted this feature in both MSK144 and FT8. FT8 has three extra information bits in its message payload, not all of which are (yet) used. MSK144 does not have these extra bits. There is no foolproof, satisfy-everybody, mode-independent way to squeeze "R+grid" messages along with all other standard message features in a 72-bit packet. We therefore decided to use the "antipode grid" method of conveying "R+grid". QSOs on VHF bands over distances greater than 10,000 kkm using MSK144 and FT8 are expected to be rare. When you're lucky enough to be working East Asia on 6m, using WSJT-X v1.9, just hit "No" when asked if you should be in contest mode. In any future (or possibly enhanced) modes we will most likely reserve a few additional bits for message types that solve this problem (as well as Rover callsigns and a few other nagging issues of message structure) in a better way. The necessary price will be a small (less than 1 dB) loss of sensitivity. -- 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 wsjt-devel@lists.sourceforge.net 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Start time, not end time, logged
Version 1.9.0 When making a difficult QSO, many minutes can pass between the time the QSO was initiated and the QSO was completed. These are identified in the log screen as "Start Time" and "End Time". Currently, when a QSO is logged, the Start Time is placed in the ADIF file, and sent to clients such as N1MM+. This is not standard for logging programs, and will lead to non-QSO time mismatches in LoTW. The End Time should be written to the ADIF file and sent to clients. 73, Steve, N2IC -- 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] working stations over 10000 km on 6m (Ned)
Ned & Jim, Using WSJT-X V 1.9.1 v8747, to activate the "NA VHF Contest" check box hit F2 (File/Settings) and click the 'General' tab. check the "Enable VHF/UHF/Microwave" features" box. After you click 'OK', the "NA VHF Contest" box will appear on the main WSJT-X screen under the 'Hold Tx Freq' check box. Jim, K9YC, nice to work you last night on 6M double hop. Lots of W6/W7 stations. If you want to see what I'm decoding on 6M and other HF bands you can connect to 'k1htv.to.us:7373". I'm using a Redpitaya that son Andy, K1RA, gave me for my birthday, as an 8 band FT8 skimmer. 73, Rich - K1HTV = = = On 5/30/2018 6:30 PM, Ned wrote: This happened to me at the most inopportune time. I was sending a signal report to DS4AOW for a ATNO on 6m and it sent a NA Contest TX3 exchange instead of what was expected. The only way I could clear the problem was to change the mode to to anything other than FT8 and then back to get the right TX3 message. While I was sorting that all out, the band faded and I did not complete. It's rare to hear stations over 10 KM, so this is a hard thing to test. - -- Yes, this needs to get fixed. I ran into it tonight when an east coast station called me and and gave me an NF grid. To deal with my neck posture issues, I run WSJT-X on an extension screen above my laptop, and the NA contest exchange query showed up on the laptop screen. It took several cycles before I even noticed it. He kept calling me, I kept trying to respond. We also lost the QSO. I had to kill First Call and ignore him. FWIW -- I t doesn't happen often, but I have almost a dozen 6M Qs greater than 10,000 km (SA, VK, ZL, FK, other OC), mostly CW, a few JT65, all short transequatorial openings. The fix could be something as simple as not requiring that the operator acknowledge the message. 73, Jim K9YC-- 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] working stations over 10000 km on 6m
Hi Jay, Ned, and all, On 5/30/2018 8:57 PM, Jay Hainline KA9CFD wrote: We had a big opening to JA today on 6m. Some of the contacts were over 10,000 km and I have heard some ops report their WSJT-X software would hang up asking if they want to switch to contest mode. Apparently the program sees the grid from JA and thinks they are in contest mode? I don't have much more details. Maybe someone can chime in or advise if this would be a bug that needs fixed. Jay Hainline KA9CFD Ned AA7A wrote: This happened to me at the most inopportune time. I was sending a signal report to DS4AOW for a ATNO on 6m and it sent a NA Contest TX3 exchange instead of what was expected. The only way I could clear the problem was to change the mode to to anything other than FT8 and then back to get the right TX3 message. While I was sorting that all out, the band faded and I did not complete. It's rare to hear stations over 10 KM, so this is a hard thing to test. Jay KA9CFD wrote: Hopefully the developers will have some insight. I never have like the idea of using the opposite side of the world grid to represent an R-grid contest report. Causes confusion for non-contesters, and some bad side effects apparently. :-) Contesters pleaded for an easy way to send "R+grid" rather than "R+rpt" in the message sequence. They wanted this feature in both MSK144 and FT8. FT8 has three extra information bits in its message payload, not all of which are (yet) used. MSK144 does not have these extra bits. There is no foolproof, satisfy-everybody, mode-independent way to squeeze "R+grid" messages along with all other standard message features in a 72-bit packet. We therefore decided to use the "antipode grid" method of conveying "R+grid". QSOs on VHF bands over distances greater than 10,000 kkm using MSK144 and FT8 are expected to be rare. When you're lucky enough to be working East Asia on 6m, using WSJT-X v1.9, just hit "No" when asked if you should be in contest mode. In any future (or possibly enhanced) modes we will most likely reserve a few additional bits for message types that solve this problem (as well as Rover callsigns and a few other nagging issues of message structure) in a better way. The necessary price will be a small (less than 1 dB) loss of sensitivity. -- 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Release of WSJT-X Version 1.9.1
Great work Joe and team. I found one minor bug when upgrading to 1.9.1 from 1.8 on Windows 10. When I first opened WSJT-X after installing 1.9.1 it defaulted to DXpedition mode Hound in FT8. I was not using DXpedition mode in the previous version so it was not carried over from there. On Thu, May 31, 2018 at 6:21 AM, Joe Taylor wrote: > WSJT-X Version 1.9.1 is now available for download. This version corrects > a flaw in Version 1.9.0 that unintentionally restricted the full use of FT8 > DXpedition Mode by "Fox" stations. > > New features and enhancements to WSJT-X since Version 1.8.0 are summarized > here: > http://physics.princeton.edu/pulsar/k1jt/New_Features_1.9.1.txt > > As we have stated before, FT8 DXpedition Mode should be used only in > rare-entity circumstances in which sustained QSO rates well above 100/hour > are expected. Detailed instructions for FT8 DXpedition Mode can found here: > http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf > > Upgrading from earlier versions of WSJT-X will be seamless; there is no > need to uninstall a previous version or move any files. Please do not > continue using any "release candidate" -- that is, any beta release with > "-rc#" in the version name. > > Links to installation packages for Windows, Linux, Macintosh, and Raspbian > Jessie are available here: > http://physics.princeton.edu/pulsar/k1jt/wsjtx.html > > You can also download the packages from our SourceForge site: > https://sourceforge.net/projects/wsjt/files/ > It may take a short time for the SourceForge site to be updated. > > We hope you will enjoy using WSJT-X Version 1.9.1. > > -- 73, 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 > wsjt-devel@lists.sourceforge.net > 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Dev branch?
On 31/05/2018 15:15, Black Michael via wsjt-devel wrote: Is this the current development branch? It's build 1.9.1 as of now...it was building 1.10.0 on 5/28 http://svn.code.sf.net/p/wsjt/wsjt/wsjtx/trunk/ Also interesting it says rev 8745 on "svn info" and "svn log" but the "svn update" and the website says 8747. Hi Mike, ^/wsjtx/trunk is the WSJT-X development branch. Do not worry about the version number too much, that is only really relevant for releases. FYI it was moved back to 1.9.1 to make the recently announced critical FT8 DXpedition mode bugfix release. This was cut from the devlopment branch as no other changes of significance had been made since the v1.9.0 release. The reason for the differing Subversion revision numbers is the same reaason they are not used to signify releases. The Subversion revision number is a monotonic incrementing unique change-list number for the whole repository, hence it can inscrease when there are no changes to a particular branched code line. Note that releases are built from the tag of the same name so the revision number of a release is the latest change-list number on that tag. Try the following to see the correct information: svn sw ^/wsjt/tags/wsjtx-1.9.1 (use ^^ on Windows) then try: svn info 73 Bill G4WJS. -- 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] message changed from R+02 to calling other station.
Using WSJT-X v1.9.1 r8747 Windows 10 I was in a qso on 17m with JA1NCZ. All was going as expected until he gave up and gave a report to RU3DK. My MM5AGM JA1NCZ R+02 then changed to me calling him - JA1NCZ MM5AGM IO85. 142245 Tx 1934 ~ CQ MM5AGM IO85 142300 7 0.1 1934 ~ MM5AGM JA1NCZ -22 142315 Tx 1934 ~ JA1NCZ MM5AGM R+07 142330 8 0.1 1934 ~ MM5AGM JA1NCZ -22 142345 Tx 1934 ~ JA1NCZ MM5AGM R+08 142400 5 0.1 1934 ~ MM5AGM JA1NCZ -22 142415 Tx 1934 ~ JA1NCZ MM5AGM R+05 142430 5 0.1 1934 ~ MM5AGM JA1NCZ -22 142445 Tx 1934 ~ JA1NCZ MM5AGM R+05 142500 2 0.1 1934 ~ MM5AGM JA1NCZ -22 142515 Tx 1934 ~ JA1NCZ MM5AGM R+02 142545 Tx 1934 ~ JA1NCZ MM5AGM R+02 142615 Tx 1934 ~ JA1NCZ MM5AGM R+02 142630 2 0.1 1934 ~ RU3DK JA1NCZ R-06 142645 Tx 1934 ~ JA1NCZ MM5AGM R+02 142700 3 0.1 1934 ~ RU3DK JA1NCZ 73 142715 Tx 1934 ~ JA1NCZ MM5AGM IO85 142745 Tx 1934 ~ JA1NCZ MM5AGM IO85 Colin MM5AGM -- 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Dev branch?
Is this the current development branch? It's build 1.9.1 as of now...it was building 1.10.0 on 5/28http://svn.code.sf.net/p/wsjt/wsjt/wsjtx/trunk/ Also interesting it says rev 8745 on "svn info" and "svn log" but the "svn update" and the website says 8747. Working Copy Root Path: C:\JTSDK\src\wsjtx\trunkURL: http://svn.code.sf.net/p/wsjt/wsjt/wsjtx/trunkRelative URL: ^/wsjtx/trunkRepository Root: http://svn.code.sf.net/p/wsjt/wsjtRepository UUID: ab8295b8-cf94-4d9e-aec4-7959e3be5d79Revision: 8747Node Kind: directorySchedule: normalLast Changed Author: bsomerviLast Changed Rev: 8745Last Changed Date: 2018-05-30 19:25:48 -0500 (Wed, 30 May 2018) de Mike W9MDB-- 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Release of WSJT-X Version 1.9.1
WSJT-X Version 1.9.1 is now available for download. This version corrects a flaw in Version 1.9.0 that unintentionally restricted the full use of FT8 DXpedition Mode by "Fox" stations. New features and enhancements to WSJT-X since Version 1.8.0 are summarized here: http://physics.princeton.edu/pulsar/k1jt/New_Features_1.9.1.txt As we have stated before, FT8 DXpedition Mode should be used only in rare-entity circumstances in which sustained QSO rates well above 100/hour are expected. Detailed instructions for FT8 DXpedition Mode can found here: http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf Upgrading from earlier versions of WSJT-X will be seamless; there is no need to uninstall a previous version or move any files. Please do not continue using any "release candidate" -- that is, any beta release with "-rc#" in the version name. Links to installation packages for Windows, Linux, Macintosh, and Raspbian Jessie are available here: http://physics.princeton.edu/pulsar/k1jt/wsjtx.html You can also download the packages from our SourceForge site: https://sourceforge.net/projects/wsjt/files/ It may take a short time for the SourceForge site to be updated. We hope you will enjoy using WSJT-X Version 1.9.1. -- 73, 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
