Re: [wsjt-devel] Post a "Know Issues" list?
Tom, Regarding your comments about the release notes, if fact almost all of the issues that I addressed as examples are NOT covered in the latest released notes. I do like your idea of having to go to another page to read the list of known issues (and then possibly having to check a box?) before being able to download the latest RC version. As far as maintenance of the list, it would take far less time for developers like Joe, Bill(s), Mike, etc. to add a new known RC issue to the list than having to compose separate replies to users, as is being done now. 73, Rich - K1HTV = = = From: Richard Zwirko - K1HTV To: "G4WJS, Bill" , WSJT < wsjt-devel@lists.sourceforge.net> Cc: Bcc: Date: Fri, 23 Nov 2018 04:01:04 -0500 Subject: [wsjt-devel] Post a "Know Issues" list? Bill, et al, Wouldn't it be a good idea to post a list of known WSJT-X issues on a regular basis? We all see SO MANY repeat posts complaining about problems being experienced with release candidates. Hopefully, posting such a list would greatly reduce repeat problem complaints. Some known issues could include: > Colors for stations worked/needed, etc aren't working. > Poor RC4 sensitivity (Not a problem, RC4 can't copy 75 bit signals) > Why the error message about LOTW and how to fix it (Win32 Open SSL) > Not running split and wondering why stations don't copy TX tones above 2500 HZ. > Etc, etc. 73, Rich - K1HTV -- Forwarded message -- From: Tom Melvin To: WSJT software development Cc: Bcc: Date: Fri, 23 Nov 2018 10:38:20 + Subject: Re: [wsjt-devel] Post a "Know Issues" list? Do you think that would help 90% of the posters - sorry I don’t think so. The 77 bit signal and LOTW errors are very clearly mentioned in the release notes - which everyone is advised to read but don't Those looking at the mailing lists - there is an archive/search option - even just reading what was in last few hours in some cases would show the answer. Posting a list - while many people will get a nice warm feeling of things actually happening esp on some of the more obscure issues but don’t think will affect the number of similar queries. Many people do not understand the concept of beta tests - they think it is just another upgrade, jump in with both feet and are surprised when there is a slight issue, panic, scream and start reloading old versions and wasting so much of their time in the process where a 1 mins check of the dreaded … Release Notes - would have answered it. Human nature is not to RTFM no getting away from it - posting a list of known/fixed issues would be great to refer people to but won’t cut down repetitive questions. 73’s Tom - GM8MJV P.S. What may help is on the download page you have to go via another page of ‘issues’ before being able to download but that would take maintenance and the dev teams have better things to do. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Post a "Know Issues" list?
Bill, et al, Wouldn't it be a good idea to post a list of known WSJT-X issues on a regular basis? We all see SO MANY repeat posts complaining about problems being experienced with release candidates. Hopefully, posting such a list would greatly reduce repeat problem complaints. Some known issues could include: > Colors for stations worked/needed, etc aren't working. > Poor RC4 sensitivity (Not a problem, RC4 can't copy 75 bit signals) > Why the error message about LOTW and how to fix it (Win32 Open SSL) > Not running split and wondering why stations don't copy TX tones above 2500 HZ. > Etc, etc. 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Possible Compatibility Issue WSJT-X and Mac OS 10.14.1 (Mojave) - UPDATE
Robert, This comment is regarding your signal not being copied when you were transmitting with an audio tone above 2800 Hz. One parameter you did not list under the 'Radio' tab was the "Split Operation" setting. If you have it set to "None", then it is possible that your transmit audio tones over 2800 Hz are being adversely affected by the radios TX filter. If this is the case, it would explain why stations are not decoding your transmissions. To confirm this, set up a schedule with a station, first transmitting in the normal 200 to 2000 Hz range. Then try it again with the higher 2800+ Hz TX tone setting. See if your transmissions are being decoded at both ends of the TX audio spectrum. GL & 73, Rich - K1HTV = = = From: Robert Rearden To: WSJT Developers List Cc: Bcc: Date: Sat, 17 Nov 2018 10:42:13 -0600 Subject: [wsjt-devel] Possible Compatibility Issue WSJT-X and Mac OS 10.14.1 (Mojave) - UPDATE This is a followup to my earlier email regarding a possible compatibility issue between WSJT-X and Mac OS 10.14.1 while using v1.9.1 software. The issue I reported earlier was that decode does not occur during the receive portion of the T/R sequence when ENABLE TX is active. I have since installed v2.0.0-rc4a891ad and have observed the same failed decode behavior that was reported in my earlier email for v1.9.1. RC4 INSTALLED - In preparation for the v2.0.0-rc4 install, I deleted the v1.9.1 application, the /library/Application Support/WSJT-X folder and contents, the /Library/Preferences/org.k1jt.wsjtx file, and the /Library/Preferences/WSJT-X.ini file to ensure I had a clean install. - Installation of v2.0.0rc4 appeared normal and no issues or error messages were encountered. DESCRIPTION OF A FAILED QSO - On 11/17/2017 at 15:31:00 - 15:33:00 UTC a QSO was attempted with AA7A on 14074.00 MHz offset 2823 Hz. - Input signal level adjusted to approximately 40dB in the presence of signals. - Prior to the attempted QSO decode function worked properly to decode messages in the MONITOR mode from several stations active at the time (i.e., AA7A, K4IU, N4ART, N4JBB, KT9X). - The waterfall displayed incoming signal activity while in MONITOR mode. - At 15:31:00 UTC on 14074.00 MHz offset 2823 Hz, I double-clicked in the band activity window on AA7A's CQ message. ENABLE TX mode was enabled and a Tx1 standard message was transmitted (i.e., AA7A AE5UV EM12). - During the entire attempted QSO, the waterfall advanced displaying incoming signal activity during the "Rx" portion of the each T/R sequence. - Although the waterfall indicated AA7A was transmitting a message, no decoded message was received from him or any other active station on the waterfall. - At about 15:32:45 I halted transmit, decode of incoming messages resumed and they were displayed in the band activity window. - At 15:33:00, I decoded AA7A's response to my Tx1 message of a minute earlier which was "AE5UV AA7A -03". - The QSO was a fail. Below is information on my configuration and preference settings. CONFIGURATION - Computer: MacBook Air (early 2015), 1.6Ghz processor, 256GB SSD - OS: Mac OS 10.14.1 (18B75) - Program: WSJT-X v1.9.1 r8747 - Soundcard: SignaLink USB - Radio: Kenwood TS-480SAT WSTJ-X MAIN WINDOW SETTINGS - Auto Seq: ON - Call 1st: ON WSJT-X PREFERENCE SETTINGS - General tab / Station details -- My Call: AE5UV -- My Grid: EM12hq -- AutoGrid: OFF -- IARU Region: All -- Message generation for type 2 compound callsign holders: Full call in Tx3 - General tab / Display settings -- Blank line between decoding periods: ON -- Display distance in miles: ON -- Tx messages to Rx frequency window: ON -- Show DXCC entity and worked before status: OFF -- Show principal prefix instead of country name: OFF - General tab / Behavior settings -- Monitor off at startup: OFF -- Double-click on call sets Tx Enable: ON -- Disable Tx after sending 73: ON -- Enable VHF/UNF/Microwave features: OFF -- Allow Tx frequency changes while transmitting: OFF -- Single decode: OFF -- Decode after EME delay: OFF -- Tx watchdog: 4 minutes -- Periodic CW ID Interval: 0 - Radio tab -- Rig: None -- PTT Method: VOX -- Poll interval: 1s - Audio tab -- Input: USB Audio CODEC -- Output: USB Audio CODEC -- Save Directory Location: /Users/RobertRearden/Library/Application Support/WSJT-X/save -- AzEl Directory: /Users/RobertRearden/Library/Application Support/WSJT-X -- Remember power settings by band Transmit: OFF -- Remember power settings by band Tune: OFF - Reporting tab / Logging -- Prompt me to log QSO: ON -- Convert mode to RTTY: OFF -- dB reports to comments: OFF -- Clear DX call and grid after logging: ON -- Op Call: blank - Reporting tab /
Re: [wsjt-devel] ESC Key New Feature on rc4 and future v 2.0 NOT A Good Idea!
I strongly agree with George regarding NOT using the ESC key to abort a QSO. It is just too easy to accidentally do so. N1MM Logger, the world's most popular contest software, for decades has used either Alt-W or Ctrl-W to WIPE data from QSO fields. Using either, or both, or another 2-key combination would be a much better than using the ESC key as is presently being done in RC4. 73, Rich - K1HTV = = = From: George Hall To: wsjt-devel@lists.sourceforge.net Cc: Bcc: Date: Thu, 15 Nov 2018 22:24:55 + Subject: [wsjt-devel] ESC Key New Feature on rc4 and future v 2.0 NOT A Good Idea! Greetings wsjt-devel Group, In the recently released Quick-Start Guide to WSJT-2.0 manual by Joe Taylor, K1JT dated November 12, 2018 there is a new feature regarding the ESC key (listed as #7 on page 6) which in my opinion is a very bad idea. First of all, the ESC key is “all by itself in left field” on the top left side of the keyboard. Due to its physical location, this key can be very easily and unintentionally be hit or pressed; especially in the “heat of the moment” during a contest, working a ATNO or your “Second Op” (in my case my cat) happens to visit you and strolls across your keyboard! In my opinion, any key stroke intended to create such a multi-function effect like aborting a QSO, clearing the DX Call and selecting Tx6 has planned by pressing the ESC key; should be very carefully re-examined before permanently placed into action in wsjt-x 2.0. Perhaps a much better way to execute this aborting QSO multi-function feature would be to utilized the Control key plus simultaneously pressing a letter key, i.e. like pressing the Control (“Ctrl”) key plus pressing the letter “A”. By doing this fully intentional two keystroke procedure; this should help prevent errors of unintentionally aborting a QSO. Additionally, has a fail-safe a drop-down window should appear asking “do you really want to about this QSO?” and the ability to select your desired action by selecting a “Yes” or “No” box. Finally, again in my opinion; the Escape (“Esc”) key should be dead and non-functional in all wsjt-x software programs because its just too easy to hit by mistake. If for some reason the need of the Escape key must be used; then a fail-safe drop-down message should follow allowing the user to select their desired action. 73, George N2CG ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X stops decoding: Found out why
Foe months, occasionally WSJT-X would stop decoding. The waterfall would indicate plenty of signals and the clock was in sync but it wouldn't decode. A restart of WSJT-X would not resolve the issue either. When it happened, no matter which version of WSJT-X was run, none would decode any signals.. The cause was traced to my Chrome browser. After not closing the browser for many days, Chrome continued to hog more and more memory. Eventually there came a point that so much memory was being used by Chrome that WSJT-X would not decode. The fix was to close Chrome, then restart it. With all of the URLs that previously were running started up again, WSJT-X would once again decode.normally. Just thought I'd share this with other Chrome users that may have experienced the same decoding failure. 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] "L" instead of colors for LOTW
With the past few WSJT-X release candidates there have been a number of concerns expressed about the use of colored letters over various colored backgrounds to indicate decoded stations that use LOTW. In addition to the visibility issues, the user now has to remember the meanings of the various colors. If it is at all possible, why not get away from colors and KISS. Keep It Simple use a single letter "L" to indicate an LOTW using station. The "L" could be placed on the far right side of the line after the country prefix or name. RXCLUS, a program that I've been using for over a decade to monitor DXcluster nodes, appends an "L" on the far right side of putouts for LOTW users. It works great. If you don't want to see it, simply shrink the right side of the display. I believe that the use of an "L" versus using various colors is a much more effective and less confusing way to indicate FT8 stations that use LOTW. 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X changes for future contests
WSJT-X changes for future contests I have a few suggestions for changes to the present WSJT-X 2.0.0-rc2 software. These changes would allow the FT8 mode to be easily incorporated into the dozens of State and regional QSO parties and other worldwide contests. This change would remove the need to create an individual setup for specific contests as is presently being done for the ARRL FD, RTTY RU and VHF contests. The suggests are: 1) Supplement or replace the present 'ARRL RTTY Roundup' bullet with one marked 'Other Contest'. Associated with this selection would be a box into which a multi-letter contest Identifier (EUFD, CQP, PODX, SARL, 1010, FQP, etc.) would be typed. This Contest ID would be incorporated into the TX6 'CQ' message, such as 'CQ NJQP K1JT'. 2) With this 'Other Contest' selection, associate an 'Exch:' box into which is typed the alpha-neumeric characters of the exchange (59 VA, SDGO, NYC, etc.). This box would be left blank if only an incrementing number is the only exchange required (see #3 below). 3) Add an optional bullet, if checked, would add an incrementing number to the exchange, as used by DX stations operating in the recent mock 'ARRL RTTY Roundup' test. Making these additions to WSJT-X would allow FT8 to be more easily incorporated into many future operating contests/competitions. 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Mock RTTY RU results and bug
The RU went well running 75W and a wire antenna on 40M. 20M propagation wasn't very good so I spent the hour on 7078 KHz. There were plenty of stations calling CQ RU. I worked 20 stations, 3 of them DX (TG, SV and VP8). When the contest was over, I noticed in the DXKeeper log that there were no sent or received reports. I checked the WSJT-X LOG.ADI file and noticed and ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
