Re: [wsjt-devel] WSJT Accessibility with VoiceOver on Mac OS?
Justin, Why not use the Hamspots website. After you have created an account, which is free, just search for N5J. A number of blind Hams in the Groups.IO QLog Users Group are using the Hamspots to find where various DXpeditions are operating. Spots are sent to the Hamspots site by stations using JTAlert. Displayed on each line is the age of the spot, the spotter's call State and Country, the frequency in Kilohertz to two decimal places and the mode. The JAWS screen reader is used by most Q Log users to navigate the Hamspots website, although I believe that some are using NVDA. The QLog program that I mentioned is a fully voiced logging program interfaced with WSJT-X and runs under Windows, but could be run using a Windows emulator on a Mac. QLog is used worldwide by over 100 visually impaired Hams to work FT4 and FT8. Once it is started, your screen reader can be turned off as QLog is fully voiced. Good luck in using Hamspots and let me know if you are interested in learning more about QLog and its support programs. 73, Rich - K1HTV www.qrz.com/db/k1htv Subject: [wsjt-devel] WSJT Accessibility with VoiceOver on Mac OS? Hi there, I’m a fan of ft8, and I use it primarily though the built-in flex radio Smart SDR for Mac app, but I’d like to use WSJTX on the Mac, since it is the native application used for this protocol. Is there a way that I could work with some one around its accessibility? The app *mostly* works, with a few caveats. The first being is that the callsigns that are displayed in the waterfall are all over the place so when a blind person is using VoiceOver, trying to find a callsign that you’d like to work is a challenge, Is there a way to have this displayed in to some kind of workable table, or have the callsigns appear as links? Second, in the preferences > general, and preferences > radio dialogues, and others, some of the popups don’t provide the state of programatic focus to VoiceOver so it is hard to navigate through those popups when you are trying to setup a radio for instance, or making changes to your station setup. I understand the need to make WSJT cross-platform, but is there anyway this could be built using some native Apple applications? This would solve 99% of the Accessibility stuff that is going on between WSJT, and VoiceOver for blind hams using a Mac. THanks, Justin-ai5os ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Initial Calls&Report line missing from TX Freq column
While working CB0ZEW on 12M FT8, the Band Activity column displayed the initial report message that I received as well as the RR73 message which followed. [image: image.png] However, the initial message with calls and report *never appeared in the RX frequency column*. Only the RR73 line appeared. Below, you can see me (K1HTV) calling CB0ZEW at 23:47:30. The 23:48:00 message from CB0ZEW, is seen on the Band Activity column *but not in the RX Freq window*. Only the message of CB0ZEW sending a -19 report to W6VJT is seen at 23:48:00 and not the message to me from CB0ZEW which appeared in the BA column. [image: CB0ZEW-RXfreq-window.JPG] Earlier, using F/H, I was moved down from my calling tone frequency to the transmit frequency of CB0ZEW. After 3 retries there and another 3 up 300 Hz the QSO was not complete. For the QSO shown above, I switched off the F/H mode and called again, this time on 2283 Hz. CB0ZEW answered my call and we completed our QSO while I continued transmitting my TX tone frequency. I have seen this before, but it hasn’t happened very often. 73, Rich – K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Unwanted Band Activity background color
Many times a day, using the most current and previous WSJT-X improved versions, the background color for the entire Band Activity column changes from the normal white to a color. The only way to go back to the desired no-color background is to do a right click, erase. But that wipes out the recent history of decodes. I think that this anomaly only occurs when the "Start new decodes periods at top" feature is used. Is there a way to stop this unwanted background color action? If not, Is there a way to remove the unwanted background without having to erase the recent history of decodes in the BA column window? 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] "Highlight orange:" feature
I have been using the "Highlight orange:" feature in the "Colors" tab screen, and have added a number of /MM callsigns to the comma delimited list of stations that I'm interested in re-working for new water grids. I noticed that in the Band Activity column, when a station on that list that I had previously contacted is decoded, the background color around the callsign briefly flashes orange, then quickly turns and stays gray. It would be better if the color behind the decoded stations on the list would stay orange and not revert back to gray. I am using the WSJT-X v2.7.1-devel 240206 improved PLUS version under Windows 10. 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45
I have noticed the same thing at times while running as Hound in F/H where the report from the Fox will appear in the Band Activity column but not in the Rx Frequency column.I am presently running the "WSJT-X V2.7.1 devel 231031 Improved PLUS" version. Also, when the "Start new period decodes at top" checkbox is checked, many times a day the background color will change from white to another background color. When this occurs it is not always the same color. Also, at times when using the "Start new period decodes at top" option, the Band activity columns display will revert back to the earliest decodes, often many tens of minutes earlier. 73, Rich - K1HTV On Fri, Jan 26, 2024 at 7:55 AM wrote: > Send wsjt-devel mailing list submissions to > wsjt-devel@lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > or, via email, send a message with subject or body 'help' to > wsjt-devel-requ...@lists.sourceforge.net > > You can reach the person managing the list at > wsjt-devel-ow...@lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wsjt-devel digest..." > Today's Topics: > >1. skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn Williams) > > > > -- Forwarded message -- > From: Glenn Williams > To: wsjt-devel@lists.sourceforge.net > Cc: > Bcc: > Date: Thu, 25 Jan 2024 08:12:51 -0500 > Subject: [wsjt-devel] skips RX frequency window (bug?) wsjtx-2.7.0-rc3 > V 2.7.0-rc3 > Last night worked FT8 F/H with TX5S 80m. Rig TS590SG, PC Win 10. (This > has happened once or twice before.) His S/N report on me popped up in > Band Act window after my TX1, but no report in RX Freq window. TX3 > completed OK in both Windows. I use COLORS and so red was instantly > obvious. Antenna is 160m inv-L about 360 feet away. Power on the order > of 450 watts with tuner. Not thinking RFI because no other times ever I > see any. > > -73, Glenn, AF8C > -- > > -- > This email has been checked for viruses by Avast antivirus software. > www.avast.com > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X 2.5.3 crashes on TX5 with slash in call
I have run into a problem with WSJT-X 2.5.3 when transmitting a TX5 message to any station with a "/" followed by /MM or /P and probably other characters. I'm running the Win 64 bit version on a Windows 10 computer with the latest updates. After transmitting the TX5 message, the receive cycle starts and runs for 11 seconds. At that point the clock in the lower left corner stops and a few lines of decoded data is displayed, then the program ends. The problem ican be reproduced. A jt9.exe process is left running, which must be deleted with Task Manager before WSJT-X can be started again. The issue only occurs with stations with a forward slash in the callsign. I tried using a non-standard callsign such as 3DA0XXX, with no problem, only with calls with slash. I've gone back to WSJT-X Version 2.5.2 and ran the same tests without the program crashing after a TX5 message with a forward slash in the call. 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X 2.3.5 anomaly
After downloading and successfully installing the Win64 version of WSJT-X 2.5.3, I made a successful FT8 QSO. After it was complete I sent one "$DX 12345" TX5 macro to that same station with my radio in the test mode. The line for that $DX message transmission appeared fine in the "Rx Frequency" column. A minute or so later, I looked up and the WSJT-X main and wide graph screens were gone. They were not in the Windows taskbar. When I tried to restart WSJT-X, an error message popped up; "Sub-process error Failed to close orphaned jt9 process". I opened the Task Manager and stopped the jt9 process. After restarting WSJT-X again, I was able to make another QSO, but a minute or so later, again WSJT-X disappeared from the screen. When I tried again to restart WSJT-X, I again received the message about the orphaned jt9 process. I again killed the jt9 process. After the third restart of WSJT-X, I made a number of successful QSOs and so far the program has not closed itself again. Has anyone else experienced this anomaly? 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-devel Digest, Vol 93, Issue 47
Thanks Mike. I've added the exclusions. 73, Rich - K1HTV On Thu, Nov 18, 2021 at 10:50 AM wrote: > Send wsjt-devel mailing list submissions to > wsjt-devel@lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > or, via email, send a message with subject or body 'help' to > wsjt-devel-requ...@lists.sourceforge.net > > You can reach the person managing the list at > wsjt-devel-ow...@lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wsjt-devel digest..." > Today's Topics: > >1. Status File Error WSJT-X v2.5.2 (Rich - K1HTV) >2. Re: Status File Error WSJT-X v2.5.2 (Black Michael) > > > > -- Forwarded message -- > From: Rich - K1HTV > To: WSJT > Cc: > Bcc: > Date: Thu, 18 Nov 2021 10:36:54 -0500 > Subject: [wsjt-devel] Status File Error WSJT-X v2.5.2 > > Since I started using WSJT-X version 2.5.2, I have seen this error message > pop up every few days. > [image: image.png] > > > Sometimes I must click the OK button multiple times to finally clear the > last of multiple “Status File Error” message boxes. > > I checked the path and there is no WSJT-X folder in the > “k1htv\AppData\Local\Temp” folder. Any idea what might be triggering this > error message? > > 73, > > Rich – K1HTV > > > > -- Forwarded message -- > From: Black Michael > To: Rich - K1HTV via wsjt-devel > Cc: > Bcc: > Date: Thu, 18 Nov 2021 15:50:02 + (UTC) > Subject: Re: [wsjt-devel] Status File Error WSJT-X v2.5.2 > Exclude the path in your antivirus. > You can google "defender exclusions" or such depending on your antivirus. > > Mike W9MDB > > > > > On Thursday, November 18, 2021, 09:47:23 AM CST, Rich - K1HTV via > wsjt-devel wrote: > > > Since I started using WSJT-X version 2.5.2, I have seen this error message > pop up every few days. > [image: image.png] > > > Sometimes I must click the OK button multiple times to finally clear the > last of multiple “Status File Error” message boxes. > > I checked the path and there is no WSJT-X folder in the > “k1htv\AppData\Local\Temp” folder. Any idea what might be triggering this > error message? > > 73, > > Rich – K1HTV > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Status File Error WSJT-X v2.5.2
Since I started using WSJT-X version 2.5.2, I have seen this error message pop up every few days. [image: image.png] Sometimes I must click the OK button multiple times to finally clear the last of multiple “Status File Error” message boxes. I checked the path and there is no WSJT-X folder in the “k1htv\AppData\Local\Temp” folder. Any idea what might be triggering this error message? 73, Rich – K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bug in 2.5.1?
Lance, W7GJ wrote: ...Maybe if there were an option to keep the signal report the same even if there are a number of intervening contacts or transmissions to other stations, I guess that is what I am trying to do by hand and failing miserably at... Do you understand my dilemma? MNI TNX and VY 73, Lance - - - Lance, maybe there needs to be an equivalent of the "599" like we all use for working DX or in contestseverybody is 599 :-). Maybe for Q65 everybody should be -25. 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Exaggerated reports given to lower tone freqs
Has anyone experienced exaggerated dB signal reports given by WSJT-X to decoded FT8 signals of stations transmitting tone frequencies below 500 Hz? I use a K3 with 2.8 KHz filter using WSJT-X Version 2.5.0 . I have also seen this in earlier versions. When stations using low audio tones are decoded, the signal levels that WSJT-X gives them far exceeds the levels given to signals with higher frequency tones of equal intensity level observed visually on the wide graph. I have run the “Measure Reference Spectrum” tool on a quiet frequency and have the “Ref Spec” checkbox on the Wide Graph checked. This didn’t resolve the noted anomaly. I first observed this on Foxes running 3 or 4 streams using tones below 500 Hz with the lower tones appearing a few DB stronger than the higher tones. Any idea as to why this may be happening. 73, Rich – K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X vs JTDX sensitivity comparison
After this past weekend's ARRL VHF contest, one of the top SOHP scorers, Mike, W3IP, posted a note to the PVRC reflector along with the breakdown of his score. In his comments he compared the FT8 sensitivity of WSJT-X vs JTDX. Mike is a technically sharp guy and I trust what he has reported. Here is what W3IP wrote: *"When operating on FT8, I ran WSJT-X and JTDX in parallel. The JTDX decode capability on weak signals is significantly better - but JTDX doesn't recognize contest mode. I had several contacts that decoded only on JTDX so I had to manually advance the transmit side exchange on WSJT-X each time. I had only one occasion when I decoded a wanted signal in WSJT-X only. What a pain!"* I wonder what might explain the better performance of JTDX over WSJT-X on weak signals and if something can be done so WSJT-X can match the weak signal performance of JTDX. I used WSJT-X v2.5.0-rc5 in the VHF contest on 6M & 2M and it performed well for me on FT8. I haven't yet compared WSJT-X at my QTH with JTDX. 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Received RR73 Tx4 msg turning off our "Enable Tx"
Presently on FT8, when we turn on our “Tx enable” button to call a station ending a QSO with another station, when we receive his Tx4 “ RR73” message, WSJT-X disables our “Enable Tx” button. Even when calling with a different Tx tone frequency, as to not cause on-freq QRM, as long as our Rx window is within 50 Hz of the station we want to call, the disabling of "Tx Enable" occurs. Is there any reason why this feature couldn't be eliminated, so we can proceed calling that station without having to re-enable the “Enable Tx” button when an "RR73" message is received? 73, Rich – K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] RC4 Watchdog anomaly
I've been running WSJT-X version 2.4.0-rc4 on a quad core Dell Z440 computer using Windows 10. I've found what appears to be an anomaly that I don't recall seeing as being reported. I was calling a BD station in China on 17M FT8,. I called using the Tx2 vs the Tx1 message. I noticed that as the minutes passed, and the BD station contacted other stations, the WD timer stayed at the default value of 6 as I continued calling higher on the widegraph screen. However, after a period of time, probably 6 minutes, the Enable Tx light went off and my transmissions stopped. The counter in the lower right corner of the main WSJT-X screen remained at 6 until the transmission stopped. It never decremented at all. Next, I tested the watchdog timer , calling the BD station using the Tx1 message, By that time that station was much weaker. As I continued calling, after about 2 minutes the WD counter decremented to 5. After another 2 minutes, the WD timer decremented to 4. But even stranger, after another 2 minutes, the watchdog time *incremented* from 4 to 5 as I continued calling that same BD station. Two minutes later, the WD timer *incremented again*, from 5 to 6. I continued calling the BD station and the WD timer then started to decrement every couple of minutes and this time it got down to 3. But, a few minutes later, it jumped from 3 to 6. At this point I stopped the test. Have others seen this strange behavior? 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Few FT8 decodes on Even cycles
Bill - G4WJS, OK on the suggestion of switching to Meinberg NTP instead of D4.EXE, which I have been using successfully for years. Today, the problem of poor odd cycle and almost no even cycle FT8 decodes started again. I checked and found the Windows Internet Time Sync tool was disabled. One would think that if D4.EXE was the cause of the problem, disabling it would stop the anomaly, so I shut down D4.EXE, but the poor decode problem continued. Note that after a week of not leaving Chrome running, I started it again yesterday and left it running. When the poor decode problem started again today, I checked Task Manager and found that Chrome's memory use had increased to over 1.3 GB. That is still a small fraction of the 16GB of available RAM. What might cause this poor and asymmetrical number of decoded FT8 stations with the number of odd cycle decodes being greater than the almost zero number of even cycle decodes? Is it possible that some of the JT9.exe decoder code in RAM is getting contaminated? I'm in the process of bringing a 4 core computer online, replacing the dual core computer now in use for WSJT-X. It will use Meinberg NTP. Hopefully the poor decode problem will go away.with the new box. 73, Rich - K1HTV = = - From: Bill Somerville To: wsjt-devel@lists.sourceforge.net Cc: Bcc: Date: Mon, 19 Apr 2021 18:07:49 +0100 Subject: Re: [wsjt-devel] Few FT8 decodes on Even cycles Hi Rich, you describe symptoms that could be explained by your time synchronization application making step changes, that is sure to cause discontinuities in the audio streams which in turn are very likely to disrupt decoding of all signals in periods where that happens. One cause of this could be multiple time sync applications running simultaneously, e.g. not disabling the Windows Internet Time Sync tool if you are running another 3rd party time sync tool. Note also that we no longer recommend SNTP time sync tools as they are prone to this sort of time stepping on systems that keep poor time when unsynchronized. On MS Windows the Meinberg NTP Client is a proper NTP implementation and only steps the time during initialization, if configured to do so, to get a fast synchronization. There are other time sync tools that implement NTP rather than SNTP, if Meinberg is not to your liking. On other platforms the default network time sync tool will be a full NTP implementation like the *nix ntpd or more modern chronyd, so there just enabling the system network time synchronization is sufficient. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Few FT8 decodes on Even cycles
Bill - W2PKY, Thanks for the idea of playing back the WAV files which had few or no decodes. I played the WAV files back and they sound normal, full of signals but still decode few if any of them when I play them back for decoding. I wonder if WSJT-X has a shared memory buffer which another program had access to which caused part of the decoding part of the program to produce the poor decodes. Another thing that I noticed was that when there were FT8 decodes on the odd cycles, at times most of the decoded signals had a DT of 0.1 then in some of the next receive cycles almost all decoded stations had a DT of 0.4 seconds. Then they would be back to 0.1 second DT numbers. However, when the problem occured, as I checked the PC clock a number of times using the "time.is" URL, it indicated "Your time is Exact" usually within 1- milliseconds of exact. My station is band switching and decoding 24/7. I've left all normally used programs running but have shut down Chrome. So far, in the past few days the problem has not re-occurred. Maybe Chrome is the culprit. The last time when the problem occured, Chrome was consuming over 1 GB of RAM, still far less than the available 16GB but still a lot. Once the problem starts, shutting down Chrome and apps doesn't fix it, only a reboot of the computer. Thanks also for the suggestion about checking if standby memory is being used when the problem occurs. Will have to do that. 73, Rich - K1HTV. -- Forwarded message -- From: Bill B To: WSJT software development Cc: Bcc: Date: Fri, 16 Apr 2021 21:56:27 -0400 Subject: Re: [wsjt-devel] Hello Rich- Have you listened to the .wav files to see if they sound clean and undistorted? Windows allows audio channels to be monitored. Open sound control panel > recording tab, locate input device > properties > listen tab > click listen to this device. Listen to the audio quality when the app fails to decode everything that’s in the waterfall. Bring up Task Manager > performance > open resource monitor > Memory and check if Standby memory is used up. That’s when my system starts acting strange. You may need to reboot more often. Hope this helps. Bill W2PKY Sent from my iPad On Apr 16, 2021, at 1:47 PM, Mike Lewis wrote: I have been seeing cycles with only a few decode counts on busy bands periodically I am usually run 2 WJST-X instances 24/7 comparing the decode count each cycle of a new SDR rig while I am working on it, compared to my K3, both on the same antenna. I watch the decode count number and waterfall images constantly, but not the actual decodes much. I do not reboot very often, the short decode count only happen to me once then back to normal. I blamed that on the possibility the missing decodes would appear in the next decode group as late decodes, but I have not verified that happens/happened. Need to look at that next time. I usually see it a few times a day. I will look to see if it is odd or even as well. This is 2.4.0-rc4. It occurred on earlier rc versions, maybe on 2.3 also. Mike K7MDL EL87sm & CN88sf *From:* Rich - K1HTV *Sent:* Friday, April 16, 2021 08:14 *To:* WSJT *Subject:* [wsjt-devel] Few FT8 decodes on Even cycles In the past couple of months, using both the GA and the RC versions of WSJT-X, I've been plagued with an intermittent decode problem while running FT8. I am using Win10 on a dual core i5-2500 @ 3.3GHz with 16GB of RAM. It may take days and sometimes less for the problem to occur. On a busy 20 Meter band, the decode count and corresponding number of decodes are normally between 30 and 60 per 15 second FT8 sequence. When the problem develops, with a full waterfall display, on the *odd cycles*, only 4 to 8 signals are decoded and counted. On the *even cycles* only a few and often NONE of the many dozen signals are decoded. The DT on most of the few decoded signals is usually 0.1 seconds, so it's not a clock issue. The only fix is to reboot the computer and then the count goes back to the 30 to 60 decodes on both even and odd 15 second cycles. When the problem occurs, checking with Task Manager, the max CPU usage on WSJT-X peaks at less than 5% and the max total CPU usage with other apps is no more than 20% on peaks. A max of 30% of the 16GB RAM is being used. I use the Chrome browser, using 300-800MB of RAM. When I shut down Chrome and all other apps, there doesn't appear to be any phantom occurrences of their processes running, but the very poor decoding problem still exists. I turned on WSJT-X "Save all" and played back the saved WAV files and the number of decodes matched the low counter readings noted for the same sequences. I switched from using the Elecraft K3 USB CODEC to using the sound card with audio from the K3 Line Out jack and get the same poor performance when the problem arises. As I said, only a reboot of the computer will bring things back
[wsjt-devel] Few FT8 decodes on Even cycles
In the past couple of months, using both the GA and the RC versions of WSJT-X, I've been plagued with an intermittent decode problem while running FT8. I am using Win10 on a dual core i5-2500 @ 3.3GHz with 16GB of RAM. It may take days and sometimes less for the problem to occur. On a busy 20 Meter band, the decode count and corresponding number of decodes are normally between 30 and 60 per 15 second FT8 sequence. When the problem develops, with a full waterfall display, on the *odd cycles*, only 4 to 8 signals are decoded and counted. On the *even cycles* only a few and often NONE of the many dozen signals are decoded. The DT on most of the few decoded signals is usually 0.1 seconds, so it's not a clock issue. The only fix is to reboot the computer and then the count goes back to the 30 to 60 decodes on both even and odd 15 second cycles. When the problem occurs, checking with Task Manager, the max CPU usage on WSJT-X peaks at less than 5% and the max total CPU usage with other apps is no more than 20% on peaks. A max of 30% of the 16GB RAM is being used. I use the Chrome browser, using 300-800MB of RAM. When I shut down Chrome and all other apps, there doesn't appear to be any phantom occurrences of their processes running, but the very poor decoding problem still exists. I turned on WSJT-X "Save all" and played back the saved WAV files and the number of decodes matched the low counter readings noted for the same sequences. I switched from using the Elecraft K3 USB CODEC to using the sound card with audio from the K3 Line Out jack and get the same poor performance when the problem arises. As I said, only a reboot of the computer will bring things back to normal. I'm at a loss to figure out what is causing this intermittent problem and how to correct it. Does anyone have any ideas of the cause and how it can be fixed? Thanks. 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Re-decoding past transmission on FT8
In the past, in the FT8 mode, after using the "CQ Only" checkbox option on the main WSJT-X screen, by unchecking it the user could display all decodes from the same cycle as the CQ Only results. Would it be possible to reinstate this feature or does the WAV file for that 15 second sequence only contain signals that pass the "CQ Only" filter? If all signals are in the WAV file, How about using the "Decode" button to re-decode that WAV file so the user could see the stations that couldn't be copied with "CQ Only": filter enabled? 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Cabrillo file creation question
For the Virginia QSO Party (VQP) this past weekend I wanted to use the WSJT-X FT4 and FT8 modes to work a number of DX QSOs. Since none of the special activities supported by WSJT-X matched the VQP requirements, I had to improvise. I stored "CUL VQP 73" as a Tx5 macro. "CUL" is my VA county abbreviation. When a station answered my "CQ DX", I used the Tx5 pulldown menu to select the stored message and prepended a 3 digit QSO number. When the QSO was completed. in order to store the QSO number sent and county number, I entered them in the WSJT-X "Log QSO" window. The "CUL" county was stored in the "Tx power" field with the "Retain" option checked so the county abbreviation wouldn't have to be entered for each QSO. The QSO number was entered into the "Comments" field. All of the required data for each QSO was successfully stored in the comma delimited "wsjtx.log" file. I would like to submit my VQP log of digital QSOs to the VQP sponsor as a Cabrillo file but can't find a way to do so. A ".cbr" file can only be exported for one of the WSJT-X "Special Activities" options. My question is, when the WSJT-X "Export Cabrillo Log" option is selected, what file is used to create the CBR file? Presently when I run this option, all I get is the header information based on information entered in the window that pops up before the otherwise empty CBR file is created. I'd like to create a Cabrillo using WSJT-X non-contest data. Is that possible? 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Re" FT8 poor decoding problem solved
Reino - OH3MA, The radio is an Elecraft K3 with audio fed via USB cable from its internal CODEC. I received a call from Sam, W2JDB, creator of the QLog program for blind Hams to use FT8/FT4. Sam suggested that the problem may be that Windows, for some reason, stops handling the time correction data. My PC clock, if not updated with a time sync program, my PC clock will be off by 2 seconds in a day. That might explain the low number of decoded stations, with clock settings that probably are also close to the +/- 2 second mark. One thing that I should have done was to check the WSJT-X time compared to my WWVB sync'd atomic clock , even though the "TIME.IS" website said that my time was "Exact". 73, Rich - K1HTV = = = To: "'WSJT software development'" Cc: Bcc: Date: Wed, 17 Mar 2021 21:07:34 +0200 Subject: Re: [wsjt-devel] FT8 poor decoding problem solved I'm passing along this info for others who might be experiencing low numbers of FT8 decodes. In the past month on 3 occasions the number of FT8 decodes on very busy bands didn’t match the activity noted on the Wide Graph. Although many dozens of stations were seen, fewer than 10 were being decoded on the odd cycles and only 1 or 2 stations were decoded during the even cycles. This same pattern was noted on all 3 times that this problem was observed. The problem occurred while using WSJT-X V2.3.0 GA as well as 2.4.0-rc1 & 3 versions. I verified that D4.EXE had recently updated the time and the “Time.IS” website said the computer clock was “Exact”, so it wasn’t a time issue. Using the Windows Task Manager, the maximum CPU usage with the dual core I5-2500 CPU running at 3.3 GHz never exceeded 40% on peaks. There was plenty of the 16GB of memory available, so it didn’t appear to be a memory issue either. The audio receive level was between 50 and 60 dB on the WSJT-X bar meter. I shut down all other apps but the poor decode performance continued with only WSJT-X running. Shutting down and restarting WSJT-X didn’t correct the problem. The fix? I rebooted the computer and during subsequent decode cycles, between 40 and 60+ stations were decoded each cycle. The reboot fixed the poor decoding each time the problem was observed. Any thoughts as to why this was happening? Thanks Rich of your positive report. Could you remind us which rig are using and how it is connected to your PC, please? 73, Reino OH3mA ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] FT8 poor decoding problem solved
I'm passing along this info for others who might be experiencing low numbers of FT8 decodes. In the past month on 3 occasions the number of FT8 decodes on very busy bands didn’t match the activity noted on the Wide Graph. Although many dozens of stations were seen, fewer than 10 were being decoded on the odd cycles and only 1 or 2 stations were decoded during the even cycles. This same pattern was noted on all 3 times that this problem was observed. The problem occurred while using WSJT-X V2.3.0 GA as well as 2.4.0-rc1 & 3 versions. I verified that D4.EXE had recently updated the time and the “Time.IS” website said the computer clock was “Exact”, so it wasn’t a time issue. Using the Windows Task Manager, the maximum CPU usage with the dual core I5-2500 CPU running at 3.3 GHz never exceeded 40% on peaks. There was plenty of the 16GB of memory available, so it didn’t appear to be a memory issue either. The audio receive level was between 50 and 60 dB on the WSJT-X bar meter. I shut down all other apps but the poor decode performance continued with only WSJT-X running. Shutting down and restarting WSJT-X didn’t correct the problem. The fix? I rebooted the computer and during subsequent decode cycles, between 40 and 60+ stations were decoded each cycle. The reboot fixed the poor decoding each time the problem was observed. Any thoughts as to why this was happening? 73, Rich – K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Rc4 Tx levels will cause future QRM problems
I noticed that while running WSJT-X v2.4.0-rc1, the original WSJT-X "Pwr" control setting produced excessive AGC levels on my K3 transceiver. TX levels are over 5 dB higher with WSJT-X Version 2.4.0-rc1 than with previous versions. Unless a software change is made so TX audio levels match those of previous versions of WSJT-X, I'm afraid that we all will be hearing more kazoo sounds on the FT8 & FT4 frequencies and will be seeing more and more spurious signals on our Wide Graph screens. "Pwr" slider idea: Would it be possible to change the way to read the "Pwr" slider setting dB level? Presently, users must move the slider setting in order to check the dB level,We should be able to read the setting without having to change it. How about adding a small "dB' box right under the "Pwr" label I think that would make more sense than the way it is now. Can this change be implemented? 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VHF Contest available bands feature?
Phil, Getting the info to all VHF contesters about the letter equivalents for each band simply won't happen. It is just as easy and more clear if you create WSJT-X macros for Tx5 such as "QSY 2M 73" or "QSY 1296 73". The space followed by "73" at the end of the line is copied as a valid 73 message by the other station. Not including the 73 in the message will result in repeat roger reports from the station you are working. Serious FT8 users in the contest will know the FT8 frequency for each band. If you work a stationon FT8 and you use a tone within 50 Hz,your message should be displayed at the bottom of his "Rx Frequency" column. If you use a tone frequency outside of this +/- 50 Hz , your Tx5 message will only appear in the left column. However, since the message doesn't include his call, he may miss the request to QSY. Because of the 13 character message limit, it is not possible to include the other station's call along with the QSY message. 73, Rich - K1HTV From: phumphr...@columbus.rr.com To: "'wsjt-devel@lists.sourceforge.net'" Cc: Bcc: Date: Fri, 22 Jan 2021 17:39:33 + Subject: [wsjt-devel] VHF Contest available bands feature? Hello Everyone, I have been having a great time using digital modes for day to day and contesting in the VHF/UHF/SHF bands. One very common complaint I get is that it is difficult to communicate to the other station that you wish to QSY to the next higher band or a specific band. While using SSB or CW you can convey your intentions, but while using digital the only way is to use the free text feature. There are 10 common bands people use during NA contesting: 2 , 222, 432, 903, 1.2, 2.3, 3.4. 5.7, 10G, 24G Most will run 6 meters continuously. Here is my idea, assign each band one letter or number. At the end of the tx5 message, indicate your next available band or a character to indicate that the current QSO is the last band you have. I don't believe that stations are using all the available data to convey the tx5 message. I had even thought that the tx4 message could be used and the tx5 message could confirm the next band to QSY to. I am sure that bands used would be indicated in the setup configuration. Taken a step further even the Tx1 message could indicate how many or which bands are available. This idea could also be used for HF Contests. I am sure others have a better ideas, but it would enhance VHF contesting without many repeated exchanges of free text during a contesting. Thank you all for the many features and improvements made to accommodate contesting modes. Phil 73 N8LRG ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-devel Digest, Vol 83, Issue 56
Thanks to Bill, G4WJS and Laurie, VK3AMA for the answer on how to get Multicasting working and for the reason why the changes were made to the settings. 73, Rich - K1HTV On Sat, Jan 9, 2021 at 6:28 PM wrote: > Send wsjt-devel mailing list submissions to > wsjt-devel@lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > or, via email, send a message with subject or body 'help' to > wsjt-devel-requ...@lists.sourceforge.net > > You can reach the person managing the list at > wsjt-devel-ow...@lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wsjt-devel digest..." > Today's Topics: > >1. Re: Multicast with 2.3.0-rc3 (Laurie, VK3AMA) > > > > -- Forwarded message -- > From: "Laurie, VK3AMA" <_vk3a...@vkdxer.net> > To: WSJT software development > Cc: > Bcc: > Date: Sun, 10 Jan 2021 10:08:11 +1100 > Subject: Re: [wsjt-devel] Multicast with 2.3.0-rc3 > The WSJT-X 2.3.0-rc's introduced a new outgoing interface selector for > multicast UDP (Reporting tab of the WSJT-X Settings). You need to have a > loopback interface selected and then tell JTAlert that your using UDP > Multicast on the Loopback via the "Settings" menu , top most entry. This is > a departure from the traditional JTAlert automatic setting of the necessary > parameters as there is now no reliable way to determine the WSJT-X settings > and if the loopback interface is being used > > de Laurie VK3AMA > > > On 10/01/2021 9:46 am, Rich - K1HTV wrote: > > With WSJT-X version 2.2.2 I had been successfully using multicat with > WSJT-X passing UDP packets simultaneously to JTAlert, GridTracker and QLog, > a program developed for blind Hams to make FT8 & FT4 QSOs. I was using a > USP server address of 239.255.0.1 with port 2237. > > In version 2.3.0-rc3, using this address and port, multicasting does not > work with any of the programs. I tried the 224.0.0.1 with port 2237 as > described in the latest release notes, but that doesn't work either. > > After running for a few minutes, JTALert displayed this message box: > [image: image.png] > > Am I the only one experiencing this problem. Any clue why? Thanks. > > For now with WSJT-X version 2.3.0-rc3 I'm stuck with only using one add-on > program at a time to receive UDP packets using 127.0.0.1 Port 2237, which > still works fine. > > 73, > Rich - K1HTV > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Multicast with 2.3.0-rc3
With WSJT-X version 2.2.2 I had been successfully using multicat with WSJT-X passing UDP packets simultaneously to JTAlert, GridTracker and QLog, a program developed for blind Hams to make FT8 & FT4 QSOs. I was using a USP server address of 239.255.0.1 with port 2237. In version 2.3.0-rc3, using this address and port, multicasting does not work with any of the programs. I tried the 224.0.0.1 with port 2237 as described in the latest release notes, but that doesn't work either. After running for a few minutes, JTALert displayed this message box: [image: image.png] Am I the only one experiencing this problem. Any clue why? Thanks. For now with WSJT-X version 2.3.0-rc3 I'm stuck with only using one add-on program at a time to receive UDP packets using 127.0.0.1 Port 2237, which still works fine. 73, Rich - K1HTV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] no decode - ntp ?
Chris, With D4.exe turned off, have you checked your PC clock to see if it is gaining or loosing time? Do a manual sync them wait 10 minutes and do another manual sync. Then hover your mouse pointer over the Dx.exe icon in the lower right toolbar. It should indicate the delta time from the last sync. One thing I noticed which adversely affected my PC clock time. When I use the PC mouse roller up or down while scrolling through documents or websites in my browser, the PC clock time slows down. I've been continuously using D4.EXE since a few years after its introduction in 1995. I've had no issues with it except when a server goes down. I've been using 'time.nist.gov' which has been super reliable for years. 73, Rich - K1HTV = = = Hello Chris, Hello Tim ntp time sync goes like this: --- your PC sends local time t1 to ntp time t2 arrived at ntp: local time t1 + delay client to ntp ( = upload delay) - offset ntp sends correct time t3 time t4 arrived at PC: ntp-time t3 + delay ntp to client ( = download delay) + offset expectation: up/down delay is the same. no jitter! time t4 is the time to set the correct time at PC Conclusion: delay for 'up' and 'down' must be the same. No jitter is allowed on both legs. --- Had a similar problem like yours using an ADSL line. The ADSL modem had apparently some hick-ups (?) resulting of delays from time to time. Using a utility, like Dimension4 seems to be not a good solution in such case. Dimension4 connects to just one ntp server all the time. If you having no decodes - dont' force sync etc, check immediately at https://time.is/ to verify your local PC time. If your time is way off, try Meinberg software. Install Meinberg software and all will be good. During setup enter your regional ntp pool server. Ntp pool can be found here: https://www.pool.ntp.org/zone/north-america Meinberg (free) software: https://www.meinbergglobal.com/english/sw/ntp.htm#ntp_stable 73's de OE1MWW Wolfgang Wednesday, July 25, 2018, 7:04:34 PM, you wrote: Tim, Mike, Well this happened again. FT8 just stopped decoding. I checked and jt9.exe was still running. I looked at the time and everything appeared OK, But I hit the sync time function in Dimension 4 and Everything started working again. So even through you can’t see it, this is apparently a time sync issue. It is a new Dell 6400, Windows 10 and I am running the Dimension 4 v5.31 sync software. A manual sync appeared to fix everything. Thanks for all the support. This is a great product, please keep up the fantastic work ! Chris - N3PLM -- 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-X sync
Chris, Sounds like you will need to set D4.exe to sync more frequently. My old PC clock was so bad that I had to re-sync every 5 minutes. GL. 73, Rich - K1HTV = = = Tim, Mike, Well this happened again. FT8 just stopped decoding. I checked and jt9.exe was still running. I looked at the time and everything appeared OK, But I hit the sync time function in Dimension 4 and Everything started working again. So even through you can’t see it, this is apparently a time sync issue. It is a new Dell 6400, Windows 10 and I am running the Dimension 4 v5.31 sync software. A manual sync appeared to fix everything. Thanks for all the support. This is a great product, please keep up the fantastic work ! Chris - N3PLM -- 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] Re FT-8 DXpedition Mode
Mark, All excellent suggestions for the development crew to seriously consider. If suggestion #4 is implemented, I'd suggest that an initial Tx tone frequency between 1000 and 2000 Hz be randomly generated, rather than a fixed 1900 Hz tone. I've had excellent luck working KH1/KH7Z using transmit tones above 3600 Hz. I was able to work them on FT8 with 75 Watts and an A3S tribander on 20M and wire antennas on 30M & 40M. On a separate topic, on the HF bands, many of 13 Colonies special event stations have been using the FT8 mode. Worked all 13 States, 8 of the QSOs while using FT8. 73, Rich - K1HTV = = = [wsjt-devel] FT-8 DXpedition Mode m.we...@yahoo.com https://connect.xfinity.com/appsuite/# To wsjt-devel@lists.sourceforge.net https://connect.xfinity.com/appsuite/# * Delete * Actions https://connect.xfinity.com/appsuite/# Hello WSJT-X developers…. This not a bug report. I’m sending this email to share a couple of thoughts that might enhance the already fine program. DXpedition Mode It is apparent to me that many hams have difficulty in understanding the settings changes that must be implemented in order to use this mode. (Witness the KH1 DXpedition.) Perhaps the addition of tabs or icons on the main data screen would help. One such tab or icon could bear the title “Enter DXpedition Mode” and a second one could be entitled “Exit DXpedition Mode.” When clicking on the DXpedition Mode, the following could occur: 1. “Hound” function would automatically be enabled, 2. A pop-up window would require the user to supply the DXpedition’s call and grid square, 3. The Rx field would automatically be set to 300Hz, 4. A pop-up would appear to alert the user to view the waterfall to select a Tx frequency above 1,000Hz. If less than 1,000Hz is entered, the entry would be rejected and a bold message would alert the user to use an acceptable Tx frequency. Perhaps a default of, say, 1,900Hz could be provided by the program. When “Exit DXpedition Mode” is clicked, all of the WSJT-X settings would automatically be restored to the normal FT-8 options. Location of adif log file I regularly import wsjtx_log.adi into my DX4WIN log. I would like to be able to select the computer directory into which the wsjt-x adif log file is to be saved. Perhaps the program could cause the log entries to be saved at the default location and concurrently at the location I specify. Thank you for spending the time to read this email. 73 & keep up the great work. Mark Weiss, K6FG-- 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] FT8: Three extra bits are available
Joe, I would hope that the enhanced 75-bit message structure will allow for the Tx3 and Tx4 messages to contain all of the 0-9 and A-Z characters. This would allow FT8 to be used in a number of other operating events & contests such as State QSO parties and Field Day exercises. Can we assume that WSJT-X would NOT include the capability of inserting an incrementing contest number? If that is the case, there needs to be a way for an operator who has a station answering his CQ, to quickly insert of the contest exchange in the Tx3 message. It would be helpful if WSJT-X could insert a fixed string variable such as 3A MDC for Field day, a 2 character State abbreviation, or a 3 or 4 character county abbreviation. This should be followed by a space, with the cursor placed after the space. This would allow for the user to quickly type in any additional data, such as a contest number, after it. The station answering a CQ would have a little more time to insert any additional contest data, such as a contest number, after the fixed format part of the contest exchange in standard Tx4 message. If things are too tight, the space could be eliminated. If the above capability could be added, FT8 could be incorporated in many worldwide contest events. 73, Rich - K1HTV = = = On Fri, Jul 28, 2017 at 8:49 PM, Joe Taylormailto:j...@princeton.edu >wrote: > Hi Palle (and other VHF+ contest enthusiasts in IARU Regioin 1), > > Thanks for the suggestions you posted to wsjt-devel concerning VHF+ > contest exchanges in EU. > > I have been sketching out some possible enhanced 75-bit message > structures for FT8 mode aimed (among other things) at supporting your Region > 1 contests. > > I would appreciate your comments on the following model contest QSO > structure based roughly on common HF contest practices: > > 1. CQ G4ABC IO91 > 2.G4ABC PA9XYZ JO22 > 3. PA9XYZ 590003 IO91NP > 4.G4ABC R 570007 JO22DB > 5. PA9XYZ G4ABC RR73 > > The 4-character locators in messages 1 and 2 are redundant (and anyway > optional). But they cost nothing to include, and they do provide some useful > initial information. > > The first two digits of the exchanges in messages 3 and 4 are an "RS" > signal report. Because of the strong forward error correction in FT8, the > first digit will always be "5". The second digit would be the FT8 S/N > reading mapped onto a S1 to S9 scale, using 6 dB per S unit. Something like > S1=-24, S2=-18, ... S9=+24 dB. > > Is this an acceptable format for your Region 1 contest exchanges? Do you > think FT8 might be a popular mode for some use in EU VHF+ contests? > > -- 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
[wsjt-devel] Decouple Contest checkbox?
Is there any reason why the WSJT-X "NA VHF Contest" checkbox cannot be decoupled from the "Enable VHF/UHF/Microwave Features" check box under the "General" settings tab? One of the most frequent questions asked on contest club reflectors, prior to and during the recent ARRL VHF Contest, related to how to find the "NA VHF Contest" box. If that check box is always available on the main screen, when an alert message about having to be in the VHF Contest mode pops up, it would be less complicated for all to activate it. This is especially important for the newer or more casual FT8 ops who haven't yet read the manual. A number of post-VHF contest emails, specifically mentioned the problem of trying to complete contest QSOs with casual FT8 ops who called w/o activating the "NA VHF Contest" box, which probably didn't even appear on their main WSJT-X screen. 73, Rich - K1HTV-- 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
[wsjt-devel] Stations with bad clocks
Notifying a station whose timing is at the edge of decoding limits is problematic because once his timing slips past the max tolerable limit, no helpful messages about his clock will be decoded by the station you are trying to alert. If WSJT-X had a rubber clock feature which would temporarily speed up or slow down the computer clock by a number of seconds, then a message could be sent and decoded by those whose with inaccurate clocks. 73, Rich - K1HTV = = = PA5Y wrote: This would be quite useful based on my recent observations on 6m. We all suffer when someone inadvertently transmits across two periods. I have on occasion sent something like PA0XX CLOCK or indeed DL0XX, ON0XX and G0XXX of course 😊 It normally works but it feels wrong because the station does not know who the message is from. I don't like doing it and it really is a last resort. Other problem is TX distortion/overmodulation/wide signals. Messages to cover that would be useful, after all no one want to radiate a bad signal or cause unnecessary interference do they? We need a better expression than PA0XX WIDE, it seems too confrontational. I do hope that when conditions on 6m get even better that alternative frequencies are used. 73 Conrad PA5Y-- 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-X v1.9.0-rc3: Testing of FT8 DXpedition Mode
Being a 160M CW DXer, I too agree that 1826.5 is NOT a good spot for the FT8 DXpedition frequency, as many other Topband DXers would also agree. The highest end of the band has plenty of room, but many antennas, cut for the low end of the band, won't load well up there. Although the 1836.6 KHz WSPR frequency has a number of users, with the advent of FT8, very few, if any, JT65 stations can be heard around 1838. Maybe that would be a better place for the DXpedition mode on 160 Meters. If not there, then 1830 to 1835 KHz, considered the Topband 'DX window', would probably work, as CW ops could slide down a few KHz without to many problems. Of course, during contests, don't expect any frequency on the band to be free from QRM. 73, Rich - K1HTV = = = 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. Jay KA9CFD-- 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] Alternative FT8 DXpedition mode freqs.
With all of the discussion about the QRM to 40 Meter PSK users from 7Q7EI's use of the FT8 DXpedition mode, it is now time to take a serious look at alternative DXpedition frequencies. IARU Regions 1, 2 & 3 already have drawn up 'Bandplan Recommendations'. You can read about their 40 Meter recommendations at: https://en.wikipedia.org/wiki/40-meter_band#Band_plans Recommendations for the use of 'DATA' modes are: Region #1 - 7040-7060 plus 7060-7200 Region #2 - 7040-7050 plus 7050-7300 Region #3 - 7025-7040 (appears to be the most restrictive, although many R#3 Pacific stations use 7074 for FT8) Also mentioned are: Japan - 7025-7030 plus 7030-7300 USA - 7025-7125 Canada - 7035-7050 (but we know that VE's use 7070 and above for the various digital modes) As I listen in the evening to hundreds of FT8 stations on 7074 KHz, using the main and Beverage antennas, I hear very few, if any, signals just above 7080 KHz. I know that during the dozen of so weekends when RTTY contests are scheduled, these frequencies (+/- tens of KHz) are full of RTTY stations. But during non-contest times, these frequencies are virtual empty. The same can be said about 20 Meters and frequencies just above 14.080 KHz and 15 Meters just above 21.080 KHz. . My suggestion would be, if possible, to have WSJT-X software inhibit the use of the already defined standard FT8 HF operating frequencies whenever the 'Fox' box is checked. In addition, notify the 'Fox' via a message box to use alternate recommended DXpedition mode frequencies from the band pull down menu. The WSJT-X Development Group selected the FT8 frequencies now being used by all. I believe that after serious consideration, they should define a recommended DXpedition mode frequencies for each HF band. I'd further recommend that the 'Frequencies' table be populated with these recommended DXpedition mode frequencies. Even better, whenever the 'Fox' box is checked, display ONLY the recommended DXpedition mode frequencies' in the band pull down menu. Comments and discussion? 73, Rich - K1HTV-- 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] FT8 for 2018 Field Day
FT8 for 2018 Field Day Regarding the use of FT8 on Field Day, you can do what I did during the recent VA QSO Party, that is, use the Tx5 (73) message to send contest data. The VQP exchange sent was number, county & State, "nnn CUL VA 73", where 'nnn' was my QSO number and 'CUL' was the abbreviation for Culpeper county. The 'VA' for Virginia was not a contest exchange requirement. The Tx5 message met the 13 character maximum and ended with '73', which trigger the '73' message of the station being worked. I created a Tx5 macro message "000 CUL VA 73". When a QSO started, I simply pulled down that macro message and manually changed the 000 to the next number in the sequence. Unfortunately almost no FT8 stations worked in the VA QSO Party knew how to send the required data. As a result I focused mainly on working DX on FT8, where the only a number (dB report) was required. 285 of the 287 VA QSO Party QSOs were with DX stations. If a future WSJT-X release could have a check box for ""Lock Tx5 message", that would allow the easier use of FT8 in various contests, such as Field Day and State QSO parties. Once the 'Lock' box was checked, the user would type in the fixed contest exchange text into the Tx5 message box. It would remain there until the contest was over and not be overwritten when a new station was being worked. Sponsors would have to explain, in their rules, how to use FT8 in their contest. The Field day exchange wouldn't present any problem. However, those State QSO parties that presently requiring sequential QSO number exchanges could switch to using the dB report as the numbers exchanged. 73, Rich - K1HTV = = = Jordan Sherer, KN4CRD wrote: At that very least you can use a free text message for the exchange, Don: "KN4CRD 1B GA" You just won't be able to use auto sequencing when operating FT8 during field day. Best, Jordan KN4CRD On Mar 27, 2018, 7:40 AM -0400, Don Goldston , wrote: Any chance that an FT8 mode that performs the required exchange of information for the 2018 Field Day could be created? I know y'all are wrapped up in DXP mode, but thought it was worth asking. Thanks,-- 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] FT8 TX2 response Bug?
TX2 bug response in v1.9.0-rc3 At times, multiple callers answer my CQs. The decoded red lines from both callers appear as expected, in both the 'Band Activity' and 'RxFrequency' columns. After working the first station, if the next station I want to work is sending me a Tx2 message (Calls & Report), when I double click on his call in the 'RXFrequency' column, instead of my sending a TX3 message, my automatic response is an incorrect TX2 message. If on the other hand I double click on the same station callsign in the 'Band Activity' column, I start sending the correct TX3 message. A Bug? 73, Rich - K1HTV-- 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] New FT8 Frequencies?
OK Gary, You've got the job. :-) When will the report be ready. Then what's next? It doesn't take a rocket scientist to see where the number of FT8 users is goingUP, UP, UP!!!FT8 use will continue to expand and with it, the need for additional frequencies. Although it appears that you have doubts, I have no doubt that more frequencies will soon, if not already, be needed on some bands. 73, Rich - K1HTV = = = [wsjt-devel] New FT8 Frequencies? g...@isect.com https://connect.xfinity.com/appsuite/# To WSJT software development https://connect.xfinity.com/appsuite/# A ‘separate small group’ wasn’t exactly my proposal, Take: I simply suggested that rather than simplyassumingorassertingthat there is an issue with overcrowding and pushing for something to be done, we should take a more scientific approach. What would help address the claim(hypothesis)that the HF FT8 allocations are “overcrowded”? For example, we could systematically collect, collate and analyze our ALL.TXT files for things such as: * How many stations are using FT8 on each of the HF bands * The proportion of FT8 overs that are repeats of previous overs, suggesting communications failures due to factors such as QRM, QRN, QSB etc. * Trends i.e. how these factors vary over time 73 Gary ZL2iFB -- 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] New FT8 Frequencies?
As we all know, when bands are open, it is not unusual to find the standard FT8 frequencies packed, end-to-end with stations. The waterfall is full of dozens of QSOs and many more dozens of stations calling others. There is no doubt that with the super success of the FT8 mode, it is imperative that additional frequency “Channels” within each HF band be identified for not only the new DXpedition mode, but more importantly for normal day to day FT8 operations. Although the number of JT65 users has greatly dwindled, there are still many of them using the mode on HF, so these frequencies and their JT65 users should be left alone. The same holds for PSK31 and its army of Hams who like its rag chew capabilities that the FT8 and JT65 modes can’t provide. Then there is, on a normal weekday, a vast wasteland of the 14.080 to 14.099 RTTY band. When you tune across that frequency range during the week, rarely do you hear more than a few RTTY signals, while at the same time, packed into 2 KHz, many dozens of FT8 stations can be heard working each other. The only times that the RTTY band comes alive is during weekend RTTY contests and during DXpeditions to countries that RTTY users need to work for digital DXCC. DXpeditions usually operate around the upper 10 KHz of the RTTY frequencies. There are around a dozen major RTTY contests spaced throughout the year, all scheduled over weekend days. A proposal needs to be made to the community of RTTY operators, most of whom probably already use FT8, to see if there would be a serious problem if some of the present RTTY frequencies could be shared with FT8. These might consist of the 4 KHz at the low end of each of the presently used HF RTTY bands. Floating the idea on the ‘rttycontesting.com’website would be a good place to start. The frequencies above the NCDXF HF beacons flagged for digital use, but as ‘Packet’ where you probably will find Winlink transmissions, so those frequencies probably should be left alone. Of course, the final additional FT8 frequencies chosen must adhere to Regions 1, 2 & 3 band plans. So, where do we start? Time is flying by and the number of FT8 users are quickly growing. Comments? 73, Rich – K1HTV-- 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] Split FT8 QSY bug?
If at all possible, I'd recommend that a 4-digit (160 thru 40M) or 5-digit (30M thru 6M) number in a CQ text message be interpreted as the frequency to set VFO-B. It is harder to misinterpret an exact frequency, especially once the DXpedition mode starts being used and DX stations use Rx frequencies well above (or below) their Tx frequency. 73, Rich - K1HTV = = = OK...so it added the 1st 3 digits as 190kHz to 1MHz to come up with 1.190 So what do we want to do with a 4 or 5 digit QSY like this? #1 Ignore it? #2 Change to it and handle it differently than the 3-digit QSY? de Mike W9MDB On Thursday, March 15, 2018, 9:59:33 AM CDT, Rich - K1HTV mailto:k1...@comcast.net > wrote: Mike, yes a QSY message was seen: >From the Band Activity window: --- 160m 112315 10 0.2 700 ~ CQ N9MB EN70 K 112315 4 1.4 864 ~ CQ WB9JOX EN61 K 112315 -18 0.7 1957 ~ CQ 1908 H40YM !where? >From the Rx Frequency window: (I clicked on the above CQ message, with this message. The K3 VFO-B switched to 1190 KHz) 112331 QSY 1.190 112337 Tx 2131 ~ H40YM K1HTV FM18 112400 Tx 2131 ~ H40YM K1HTV FM18 112441 QSY 1.190 (I had clicked again on the above CQ line) 112701 QSY 1.190 (and again, with the same QSY to the frequency that WSJT-X instructed to it to do ) 112830 Tx 2131 ~ H40YM K1HTV FM18 A 190 KHz movement would have moved the frequency from 1840 to 2030 KHz, if added, or 1650 KHz, if subtracted. So that's not the answer. Haven't yet tried to replicate the problem with another local FT8 user. 73, Rich - K1HTV-- 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] Split FT8 QSY bug?
Mike, yes a QSY message was seen: >From the Band Activity window: --- 160m 112315 10 0.2 700 ~ CQ N9MB EN70 K 112315 4 1.4 864 ~ CQ WB9JOX EN61 K 112315 -18 0.7 1957 ~ CQ 1908 H40YM !where? >From the Rx Frequency window: (I clicked on the above CQ message, with this message. The K3 VFO-B switched to 1190 KHz) 112331 QSY 1.190 112337 Tx 2131 ~ H40YM K1HTV FM18 112400 Tx 2131 ~ H40YM K1HTV FM18 112441 QSY 1.190 (I had clicked again on the above CQ line) 112701 QSY 1.190 (and again, with the same QSY to the frequency that WSJT-X instructed to it to do ) 112830 Tx 2131 ~ H40YM K1HTV FM18 A 190 KHz movement would have moved the frequency from 1840 to 2030 KHz, if added, or 1650 KHz, if subtracted. So that's not the answer. Haven't yet tried to replicate the problem with another local FT8 user. 73, Rich - K1HTV = = = [wsjt-devel] Split FT8 QSY bug? Black Michael https://connect.xfinity.com/appsuite/# To WSJT https://connect.xfinity.com/appsuite/# * Delete * Actions https://connect.xfinity.com/appsuite/# That's almost a QSY request but that format is expecting a 3-digit frequency so would've thought you'd see a 190kHz movement Did you see a QSY message in your Rx window? de Mike W9MDB On Thursday, March 15, 2018, 6:49:15 AM CDT, Rich - K1HTV mailto:k1...@comcast.net > wrote: This morning, a few minutes before local sunrise, H40YM showed up on 160 Meter FT8 on 1840 KHz calling "CQ 1908 H40YM". He was listening up the band in the 160M Japan operating area frequency window. Wanting to to work the H40 split, I temporarily set the WSJT-X File/Settings/Radio/ "Split Operations" to 'None', but left my K3 in the SPLIT mode. But, when clicked on the "CQ 1908 H40YM", instead of moving VF0-B to 1908 KHz, it was moved instead to 1190 KHz. I tried a number of times but each time VFO-B was moved to the broadcast band frequency of 1190 KHz instead of 1908 KHz. By the time manually set VFO-B to 1908 MHz, H40YM disappeared into the noise. Might there be some kind of software bug in the v1.9.0-rc2 software causing the wrong split frequency to be set in VFO-B ? 73, Rich - K1HTV-- 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] Split FT8 QSY bug?
This morning, a few minutes before local sunrise, H40YM showed up on 160 Meter FT8 on 1840 KHz calling "CQ 1908 H40YM". He was listening up the band in the 160M Japan operating area frequency window. Wanting to to work the H40 split, I temporarily set the WSJT-X File/Settings/Radio/ "Split Operations" to 'None', but left my K3 in the SPLIT mode. But, when clicked on the "CQ 1908 H40YM", instead of moving VF0-B to 1908 KHz, it was moved instead to 1190 KHz. I tried a number of times but each time VFO-B was moved to the broadcast band frequency of 1190 KHz instead of 1908 KHz. By the time manually set VFO-B to 1908 MHz, H40YM disappeared into the noise. Might there be some kind of software bug in the v1.9.0-rc2 software causing the wrong split frequency to be set in VFO-B ? 73, Rich - K1HTV-- 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] Guantanemo Bay callsigns
Yes Bill, I saw that but only the single suffix KG4 call was mentioned. Just wanted to make sure that the KG4xxx triple suffixes were also included. Thanks for all you continue to do to improve the already great WSJT-X FT8 software. Worked 3D2EU on Routma and H40YM on 60M at this morning's sunrise for my FT8 DXCC countries #207 & 208 with 75W or less.. FT8 is GREAT! 73, Rich - K1HTV > On March 13, 2018 at 11:23 AM Bill Somerville wrote: > > On 13/03/2018 15:19, Rich - K1HTV wrote: > > > > > > Bill, > > > > Not only KG4x but also KG4xxx calls need to identified as USA and > > NOT Guantanamo Bay call signs. Only KG4 callsigns with a 2 letter suffix > > should be identified as the Guantanamo Bay DXCC entity. Presently KG4x or > > KG4xxx callsign show up as USA as they should, but are highlighted in > > purple. > > > > > > 73, > > > > Rich - K1HTV > > > > > > Hi Rich, > > this has been fixed for the next release as mentioned as recently as > yesterday: > > https://sourceforge.net/p/wsjt/mailman/message/36259588/ > > 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] Guantanemo Bay callsigns
Bill, Not only KG4x but also KG4xxx calls need to identified as USA and NOT Guantanamo Bay call signs. Only KG4 callsigns with a 2 letter suffix should be identified as the Guantanamo Bay DXCC entity. Presently KG4x or KG4xxx callsign show up as USA as they should, but are highlighted in purple.73,Rich - K1HTV -- 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] Public test of FT8 DXpedition mode March 6-7
While on 20M FT8 a few days ago I saw 5B4AIF and called him. It appeared that he was using the DXpedition mode (N=1). While sending a RR73 message to one station, it was followed by a semicolon and my call and report. I had called the 5B4, hundreds of Hertz higher in frequency. When he answered my call, I received an alert message about having to be in the DXpedition mode. I did NOT enter the Fox/Hound mode, nor did I manually move lower in frequency, as the mode would do automatically. I continued calling the 5B4, but he never responded. I wonder If I had manually moved my frequency closer to him if the QSO would continue. Probably not, because the magic "byte" was not set, right? See you all Tuesday EST for the FT8 DXpedition mode test pileups. I'm sure that they will be big! 73, Rich - K1HTV = = = To WSJT software development https://connect.xfinity.com/appsuite/# * Delete * Actions https://connect.xfinity.com/appsuite/# I’m curious to know what will happen when someone wanders into these tests, without RC2, and tries to send one of the messages not used in these abbreviated sequences. Will those callers be ignored? Dave / NX6D-- 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] DXpedition mode test results
As expected, propagation from K1JT in NJ to K1HTV in VA on 20M was marginal. It took a skewed path beam heading towards SA to produce a report from Joe, but no complete QSO was made on 20M. QRM from XE1GK on 14080.250 didn't help. On 30 Meters, signals from Don, N1DG, as W1/KH7Z, started OK but the skip quickly lengthened and again XE1GK was on the bottom end of 10141 KHz, again causing QRM during the test, calling CQ and working stations. The 01Z 40 Meter test went better on this end with quick QSOs using K1HTV, K1WSN (XYL's call) and KW4VA (Jr. Op K1RA trustee of club call). Using the KW4VA call, after exchanging reports with W7/KH7Z at 0105Z , the Fox proceeded to send "RR73" reports at 0115Z, 011630Z, 011730Z,101830Z, 0120Z and 0125Z before the "RR73" messages finally stopped. Others reported same, so it looks like some debugging needs to be done. 80M signals from K9AN were great. When I stood by at times to listen during the 02-03Z hour, I copied over 40 Hounds simultaneously calling Bill. One thing noted was that there were long delays in completing QSOs. It appeared that as the Fox worked Hounds, either sending calls and reports or sending "RR73" messages, the Fox's cue of stations being worked got longer. As a result, the number of Hounds transmitting their "R-xx" reports to the Fox in the transmit range below 1000 Hz started to cause a log jam. The result is that the stations in the cue appear to be causing QRM to each other. To prove this theory, after starting a K1HTV QSO with K9AN and sending reports for 13 minutes without receiving a 'RR73", I decided to try something. I stopped transmitting and to look for a quiet spot and found one at 450 Hz and moved there. One call on that quiet frequency and I received a "RR73" message to complete the QSO! So, what is needed? More Fox TX streams? How about a higher priority be given to completing QSOs before starting more QSOs, thus reducing the number of repeat "R-xx" reports of Hound and the resulting QRM to each other in the frequency tone range below 1000 Hz. The QSO rates made in this public test are truly impressive. Congrats to the entire WSJT-X team for a great job done. Looks like a little more debugging and tweaking needs to be done, but it looks like the FT8 DXpedition mode is almost ready for prime time! 73, Rich - K1HTV -- 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] Repeating after QSO succeeds
Gil,What you are experiencing is what happens if you are using an older version of WSJT-X and working a station running the current version and sends the RR73 as the TX4 message. Instead of answering with a TX5 '73' message, with the older version, you go back to sending the TX2 message. What version are you using? Check by selecting 'Help' on the tool bar then 'About WSJT-X'. If you are NOT presently using WSJT-X version "1.8.0 r8193", you can download the latest Windows, Linux & Mac OS one at:https://physics.princeton.edu/pulsar/k1jt/wsjtx.html73,Rich - K1HTVMessage: 1Date: Thu, 4 Jan 2018 16:10:42 -0600From: "Gilbert Baron"To: "'WSJT software development'" ,"'WSJT Group'" Subject: [wsjt-devel] Repeating after QSO succeedsMessage-ID: <021a01d385a8$dd231460$97693d20$@gmail.com 021a01d385a8$dd231460$97693d20$@gmail.com >Content-Type: text/plain; charset="utf-8"I am getting some sort of QSO looping. After any QSO is confirmed with the RRR the program stars all over again as if I just double clicked on a QSO in the monitoring window. I am sure people are not happy with me doing that ?_I certainly want to stop that happening.I am attaching an example.One good thing though, I did get JTALERT to DXKeeper working although every time it sends a message that it is not able to be sure it actually logged it. It has logged it. It shows in the log with no problem, even did the QRZ lookup. Maybe that is the problem because I do not have a QRZ account, just using the free lookup for now. I may sign up since I am getting back into radio with this JT and MWA contest group and my new FT590SG ? I do not have it set to log automatically to DXKEEPER, it waits until I click Log This QSO. I may change that after I buy a QRZ account again.Outlook Desktop Gil W0MN -- 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] Another Compound Callsign Problem
A caution to those of us who often bypass the TX1 message (calls & grid) and start with TX2 (Calls and report). When calling a DX station with a complex callsign, when the DX station responds, none of the messages in his transmitted sequences will have YOUR callsign in them. There is no way to know for sure that the DX station is responding to you or another station. The fix, when calling stations with complex callsigns, is to start with the TX1 message. Another note, when using the alternate TX4 (RR73) message, if after you send your "RR73" message the station you are working responds with a TX2 (calls and report) instead of a TX5 (73) message, that indicates that the station is probably using an older version of WSJT-X. I've sent out numerous emails to those who have responded that way when I worked them and almost all have responded, confirming that they were using an older version. 73, Rich - K1HTV 196 DXCC worked, 156 confirmed with 75W - FT8 is GREAT! -- 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] Call change while logging
Mike & Mike, I agree, that it would be a good idea to inhibit the changing of the data of the station just worked until AFTER the logging has been completed and the log box has been closed. Although the call sign being logged does not change, some of the data does change to that of the newer station. I use DX Lab Suite's DXKeeper for logging. Too many times, before I get a chance to click "OK" in the WSJT-X log box, the next calling station's data gets embedded in the log data (country, continent, WPX prefix, report, etc.) for the previously station worked, but not yet logged. That throws log errors requiring editing the data in the DXKeeper log. Disabling the changing of the DX call while the logging box is open would prevent the problems now being experienced for those that don't act fast enough to log the previous QSO. 73, Rich - K1HTV = = = Date: Sat, 25 Nov 2017 13:17:13 + (UTC) From: Black Michael To: WSJT Software Development Subject: [wsjt-devel] Call change while logging Message-ID: <150424686.2916460.1511615833...@mail.yahoo.com> Content-Type: text/plain; charset="utf-8" There's a problem logging with JTAlert (and perhaps other apps too) if you leave the logging dialog box open and change the active call sign. JTAlert maintains the additional logging info by the active call signlike countryso you may end up logging the wrong country. There's a potential fix for WSJT-X that's not too oneroussimply disalow changing the DX Call while the logging box is open...simply disable it (to make it obvious) and reenable after logging. I'll be happy to make that patch if deemed appropriate. 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
Re: [wsjt-devel] Problem with standard message generation
Scott, Have you tried using the F4 key to clear the current QSO messages then click on the new station call that you want to work? 73, Rich - K1HTV sc...@bidstrup.com -- 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 Development Team Honored
Joe, Congrats to you and the whole WSJT-X team for receiving this year's Yasme Excellence Award. And thanks for acknowledging us folks on the reflector who bombarded you with suggestions, corrections, complaints, etc. as the WSJT-X software got better and better. I'm sure that all involved in its development are pleased to see how widely accepted the FT8 mode has become and how well it works. As an example, a few evenings ago, on 40 Meters, I worked ZA/IK2RLM in Albania for country #183 using the FT8 mode. We were both running low power but the amazing thing was that his antenna was a magnetic loop on the balcony of his apartment! Keep up the good work. We DXers are still waiting to see FT8 decodes from the presently active VK9MA DXpedition on Mellish Reef. Were the DXpedition features developed in time for them to use? 73, Rich - K1HTV = = = Date: Wed, 8 Nov 2017 15:38:48 -0500 From: Joe Taylor To: WSJT software development Subject: [wsjt-devel] WSJT Development Team Honored Message-ID: <4a839ada-c98f-be64-17f9-17bacabe1...@princeton.edu> Content-Type: text/plain; charset=utf-8; format=flowed Hi all, I write to share the good news that the WSJT Development Group has been awarded the Yasme Excellence Award for 2017. A few details can be found here: http://www.yasme.org/yasme-excellence-awards/ http://www.arrl.org/news/yasme-foundation-announces-excellence-awards-and-supporting-grant The award specifically cites major contributors G4WJS, K9AN, KI7MT, W9MDB, PY2SDR, and IV3NWV, as well as K1JT. But everyone who reads this list knows that the team includes many additional members who have contributed code, documentation, test reports, and suggestions for improvement. We (the callsigns listed above) have decided to donate the $1000 cash award to the ARRL Spectrum Defense Fund. Congratulations to all, and thanks again for your continued support of this project! -- 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] FT8 Call sign anomaly with 3XY4D
Hi Joe, As I mentioned, I understand what the users manual stated about the format of call signs as I also quoted it. However, in the case of the 3XY prefix, it has been used for over 18 years. Since 1999 I've made 63 QSOs with stations operating in Guinea and 46 of them were assigned the 3XY prefix include 3XD2Z, 3XM6JR, 3XY2D, 3XY8A, 3XY6A, 3XY7C, 3XY1L, 3XY1D, 3XY0A, 3XY1T, 3XY3D/p and today 3XY4D. I understand the reluctance of making 3XY a special case, but over the years, the majority of the assigned calls for Guinea have had the prefix 3X plus another letter, a number and 1 to 3 letters. Since the 1980 start of my electronic log of 131K+ QSOs, I found a total of only 106 QSOs with such formatted prefixes. So unless a general exception can be made for calls of that format I guess the DX station stuck with such a call sign and those of us calling him will just have to deal with the occasional confusion that will occur when such a station call sign shows up. Since a similar prefix, 3DA0 does not result in this problem, I guess the best fix would get the folks who maintain the CTY.DAT database to add "3XY" to the existing "3X" valid prefix for Guinea. Thanks again to you and the WSJT-X development team for a great piece of communications software. With 75 Watts, an A3S and wire antennas, as of this writing I've made 7823 FT8 QSOs in 176 countries. FT8 is GREAT! 73, Rich - K1HTV = = = Joe Taylor, K1JT wrote: The behavior you described is no surprise to anyone who has read the definition of what's treated as a standard callsign in any of the slow modes in WSJT-X. See, for example, the original defining document for JT65: J. Taylor, K1JT, "The JT65 Communications Protocol" (QEX, September-October 2005, p 3): http://physics.princeton.edu/pulsar/K1JT/JT65.pdf ... or the WSJT-X User Guide here: http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.8.0.html#PROTOCOLS Relevant text: "A standard amateur callsign consists of a one- or two-character prefix, at least one of which must be a letter, followed by a digit and a suffix of one to three letters." The callsign 3XY4D does not follow this worldwide standard convention. For this reason, the messages you showed are all treated as free-text messages. I am sure it is very frustrating for 3XY4D, and also for those trying to work him (as I did, yesterday, by using free text messages in FT8). In principle, we could make a "3XY" an acceptable, three-character prefix, as a special case. Not a very attractive possibility, but... -- 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
[wsjt-devel] FT8 Call sign anomaly with 3XY4D
This event anomaly started with me using WSJT-X RC3. A new FT8 DXCC country popped up today, 3XY4D. When I double clicked on his CQ call, it did not populate the message boxes. Thinking that he had manually typed in a non-standard format message, I typed "3XY4D" in the 'DX Call' box and generated a set of standard messages. So far so good. I started calling him but noticed that even though my Tx1 message was set to "3XY4D K1HTV FM18" what I was sending him was "3XY4D K1HTV F". So for my next transmissions calling him I send the TX2 message "3XY4D K1HTV -10". But that message was truncated so what I was sending was "3XY4D K1HTV -" After a number of calls he finally answered me but instead of receiving from him a normal "K1HTV 3XY4D -nn" report, all I saw was "K1HTV 3X4D -" . H. Assuming that he was sending some kind of dB report I followed up with calls and RRR, But instead of my Tx3 box message "3XY4D K1HTV R-10" my transmission to him instead was truncated to "3XY4D K1HTV R". Instead of me receiving from him a "K1HTV 3XY4D RRR" all I received was "K1HTV 3XY4D R". I sent Tx5 message "3XY4D K1HTV 73" and what came out was "3XY4D K1HTV 7". After completing the QSO with 3XY4D, country #176 with 75W, I thought I'd restart WSJT-X RC3. After I did I noticed that he was still sending CQ. When I double clicked on his CQ line, I still couldn't populate the message boxes. Also noticed 3XY4D working others, also with truncated messages, but the messages varied in length, depending on the number of characters in the call sign of the station he was working. OK, thought I'd better download the latest WSJT-X development build and did so. Using "WSJT-X v1.7-develop r8195", I ran the same tests with the same results. Then I replaced the "3XY4D" call with the same format call "3DA4D" (Swaziland) and ran tests of my generating and sending messages with the K3 in the TEST mode and everything came out normal. Next I simulated using "3XY4D" in Settings/General "My Call" and ran more tests. Here is what I found while simulating 3XY4D as my call. When I clicked on a station calling CQ, all of the standard message boxes were correctly populated. But... when I made simulated transmissions using 3XY4D as my call sign, the actual messages being send varied, depending on the length of the call sign of the other station. Using the TX6 CQ message "call 3XY4D IJ39": A 3 character call resulted in "call 3XY4D IJ3" being transmitted. A 4 character call resulted in "call 3XY4D IJ" A 5 character call resulted in "call 3XY4D I" A 6 character call resulted in "call 3XY4D " It appears that any "3XY" callsign being used is treated as a non standard call and is limited to the 13 character maximum limit. The Users Guide states "A standard amateur callsign consists of a one- or two-character prefix, at least one of which must be a letter, followed by a digit and a suffix of one to three letters." Looks like the prefix length needs to be expanded to include the 3-character prefix "3XY". The CTY.DAT file only has "3X" and not "3XY" as the prefix for Guinea so all WSJT-X users will be affected. So it looks like for now, Luc Jean Pierre THIBAUDAT, 3XY4D, and all "3XY" stations appear to be victims of the reported problem. 73, Rich - K1HTV cc:3XY4D -- 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] Double-click Band Activity responses
Joe, I downloaded and was using r8134 this afternoon and it works fine, as described, with no problems. I really like your idea of replacing the Tx=Rx with the 'Lock Tx Freq' option. If this option is included in the next release, the benefits of running split over simplex operation should be strongly emphasized in the documentation. I believe that the approach of a user locking his TX frequency to the quiet spot that he picked should greatly reduce the on-frequency pileups that are presently occurring. It has been frustrating to call CQ and have multiple callers but no decodes. One trick I have done is to Shift-click up or down 50 to 100 Hz. Some times at least one of the callers, with their Tx=Rx checked, will follow me. Then I can copy at least one of the callers. I was on 40M this morning and around 1150Z and decoded 4S7AB in the middle of the band. I quickly Shift-clicked on 2200+ Hz to run split and gave him a call. I almost fell off my chair when he responded to my call. A quick set of exchanges and Sri Lanka was in the K1HTV log for FT8 DXCC country #147. I was running 75W to a ZS6BKW (modified G5RV) antenna at 65 ft and the K3 at 75W. He was on solar power and using a 2 element 40M quad. Also snagged XT2AT on 60M FT8 yesterday. You might want to add 5357 KHz to the FT8 frequency list, as that seems to be the channel that FT8 and some JT65 is being worked at least in NA, Europe and by the Africans that I've seen on 60M FT8. Thanks again to you and the WSJT-X Team for all the work done to develop and improve the new FT8 mode. As I've said before, FT8 is GREAT! 73, Rich - K1HTV = = = > On September 28, 2017 at 11:14 AM Joe Taylor wrote: > > > Hi Rich, > > Now that SourceForge seems to have fixed their problems, please build > and test WSJT-X r8131 (or later) from the development branch and let me > know how you like the Tx Freq behavior. > > -- 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
[wsjt-devel] Same freq moves = QRM!
Ed, How does every caller moving to the TX frequency of a CQing station with a double click REDUCE QRM? That INCREASES QRM. The station that sent CQ is now faced with multiple callers, and as a result often NOTHING is decoded. This wastes time. Then when he finally picks out a station, he is faced with the QRM from those other on-frequency callers who insist on re-enabling their TX to continue calling, causing the receive station even more problems decoding the station he is trying to work. I believe that the way WSJT-X was configured in r8019 and r8021 would result in much LESS QRM than the way it was before r8019 and the way it is now in r8023. I encouraged Martti, OH2BH, to try FT8 in the very first FT8 DXpedition, to Market Reef, OJ0. In a post-expition exchanges of emails with Martti, he related the great frustration of having to deal with many calling on his TX frequency, resulting in a much lower QSO rate. With over 5,500 FT8 QSOs in my log, and having to deal with multiple on-freq callers,I know of what I speak! Making split the default by leaving your TX frequency where you want it and NOT moving it a CQer's frequency is the way to reduce QRM. 73, Rich - K1HTV = = = From: Ed Wilson via wsjt-devel [wsjt-devel@lists.sourceforge.net] Sent: Tuesday, September 26, 2017 6:22 AM To: wsjt-devel@lists.sourceforge.net Cc: Ed Wilson Subject: [wsjt-devel] r8123 UDP Communication I built r8123 this morning and was pleased to see that double-clicking on a station calling CQ moves both the Tx and Rx frequencies to that of the caller. Although I can appreciate the comments of some of my colleagues suggesting that only the Rx frequency be moved, I believe that moving both is the best approach to reducing QRM. Now to the subject of this posting: it appears that communication between WSJT-X and JTAlert has been lost. I cannot double-click on a caller in JTAlert and get any response from WSJT-X. I can, however, double-click on the caller in WSJT-X and make a contact as usual. I am just passing this info along to assist in the development process...I can work around the issues as they arise in the testing process. Ed, K0KC -- 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] Double-click Band Activity responses
In the development release r8121 I notice different responses when double clicking on stations in the Band Activity column. Double click on station calling CQ: The green marker moves to the CQ caller's frequencyGood. The red marker and the TX frequency both stay put Good! Double click on a station NOT calling CQ: The green marker moves to the CQ caller's frequency...Good The red marker and TX frequency also moves to the other station's frequencyBad! The TX frequency and red marker should NOT move. 73, Rich - K1HTV -- 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] r8119
I really like the change in r8119 through r8121 to move only the Rx frequency when double clicking on a CQ line in the Band Activity column. If this feature remains in future candidate releases, the number of multiple callers on the same frequency should be greatly reduced. Most casual ops will simply click on a CQ line, move the green RX marker and leave their TX frequency elsewhere in the passband. This should make running split the norm.a good thing. The result will be fewer no-decodes because of multi-caller QRM. If desired, calling on a CQing station's exact frequency can be accomplished with a Control-double click on the CQ line in the Band Activity column. This will move both green and red markers to his frequency. A CTRL-click on a frequency in the waterfall display will also move both TX and RX markers to that frequency. Setting ONLY your TX frequency is easily done with a Shift-Click while pointing to a clear frequency in the waterfall display. This should be the first step in setting up for split before calling a station. I have found that running split is really the key to completing QSOs with fewer repeats due to QRM from competing callers. The recent change, if retained, will make running split much easier for FT8 users. 73, Rich - K1HTV PS - Now up to 143 countries worked and 118 confirmed with FT8 with 75W or less. = = = From: Ed Wilson To: Subject: [wsjt-devel] r8119 I built r8119 this morning and was surprised to find that with Lock Tx=Rx unchecked, double-clicking on someone calling CQ (or otherwise calling another station) just moves the Rx frequency to that of the station calling rather than both the Tx and Rx frequency as before. I have been trying to train myself to operate without the Tx=Rx box checked and this change kind of threw me for a loop. Is this the intended behavior for the future or is it a bug? As an aside, the last few builds seem to be more effective in helping me achieve contacts for whatever reason...nice work! Ed, K0KC -- 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-X 1.7.1 builds now fail to start
Greg, Dummy me! I just created a shortcut for the latest build of wsjtx.exe from the 'install' folder and it works just fine. Many thanks for your rapid reply. With over 5000 FT9 QSOs in the K1HTV log, I'm now up to 140 FT8 DXCC countries worked and 108 confirmed via LOTW while running 50 to 75W. FT8 is GREAT!!! Thanks for all you are doing as part of the WSJTX Development team. Super job guys! 73, Rich - K1HTV = = = Date: Wed, 20 Sep 2017 00:27:26 -0600 From: Greg Beam mailto:ki7m...@gmail.com To: 'WSJT software development' mailto:wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] WSJT-X 1.7.1 builds now fail to start Message-ID: <00ea01d331d9$8780dd30$96829790$@gmail.com mailto:00ea01d331d9$8780dd30$96829790$@gmail.com > Content-Type: text/plain; charset="utf-8" Hi Rich, Typically, you do not run the build from the ?build? folder. Rather, you run it from the release/install folder, as that is where all the required QT / GCC dll?s are copied to. The auto-run setting for JTSDK (assuming that is what you are building with) changes directory to the revision / release / install directory, then runs the wsjtx.exe. This would be the same action as if you were to run WSJT-X after using the package installer. The plugins directory typically resided one level above the /bin directory. However, when running from the build directory, that structure does not exist. I can?t really speak to your older build situation. 73?s Greg, KI7MT-- 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-X 1.7.1 builds now fail to start
I had been successfully building and running WSJT-X development releases for many months up to r8072. When RC2 came out I started using it to check it for bugs and hadn't built any new 1.7.1 releases until today. I built r8098 and it auto started and ran OK. I went into the 8098/release/build folder and made a shortcut for wsjtx.exe but when I ran it I received an error message. Running the wsjtx.exe directly gives the same error. The message says that the app failed to start because it could not find or load the QT platform plugin "windows". I tried rebuilding with the same results. I also tried running wsjtx-exe from a number of older (8060 & 8071) builds which previously were working but get the same error. Can you shed some light as to what might be happening? Thanks. 73, Rich - K1HTV -- 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-X 1.7.1 builds now fail to start
I had been successfully building and running WSJT-X development releases for many months up to r8072. When RC2 came out I started using it to check it for bugs and hadn't built any new 1.7.1 releases until today. I built r8098 and it auto started and ran OK. I went into the 8098/release/build folder and made a shortcut for wsjtx.exe but when I ran it I received an error message. Running the wsjtx.exe directly gives the same error. The message says that the app failed to start because it could not find or load the QT platform plugin "windows". I tried rebuilding with the same results.I also tried running wsjtx-exe from a number of older (8060 & 8071) builds which previously were working but get the same error.Can you shed some light as to what might be happening? Thanks.73,Rich - K1HTV -- 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 suggested FT8 split option
Gary, Operating split on FT8 should be the rule and not the exception. Why would any want to call on the same frequency and a CQer? Your chances of working a station are so much better when you are calling on a clearer frequency. I use VNC Viewer with my Android smartphone to view the 3 shack monitors and control WSJT-X while working around the house or when in town. Setting up a split is much more difficult with a smart phone with no ALT key. It becomes a multi-step process which usually takes so much time that one calling period is wasted in setting up the split. Joe & the WSJT-X Team: I wonder if there could be an option which, if checked, would allow the user's TX frequency to remain as selected. If this could be done, when you double click on a station's call (without the ALT key) in the Band Activity column, only the green RX indicator would move and the red TX indicator would stay where it was set. . Implementing this option would result in much more split operating and a better frequency distribution of multiple callers. Fewer multi-station pileups would result in faster QSOs because of less single frequency QRM. Why not make this the default? Operating simplex would require a CTRL-left mouse click on that station callsign. 73, Rich - K1HTV -- Date: Mon, 18 Sep 2017 08:18:43 -0600 From: Gary McDuffie mailto:mcduf...@ag0n.net > To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net > Subject: Re: [wsjt-devel] FT8 is forcing the discipline of split ... Funny. Same guy finally forced me to go split this morning on 80m. Took about 4 tries and some moving around, but I finally got him. I?ve been seeing him pretty much daily on 80m in the morning, so some of you might want to snag this one. Gary - AG0N --- 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] FT8 is forcing the discipline of split ...
Sig, The only way I can find a way to go split after clicking on his call inJTAlert is to hold the shift key down, move the pointer to a clear frequency and left click the mouse. If you are fast enough you may be able to be decoded the first try. I find it much easier to first find a quiet frequency and shift left-click on it to set your TX frequency. Then when you see a station in the Band Activity list, hold the ALT key while double clicking on the line containing the station that you want to work. This procedure has worked very well for me in chasing and working DX. Make sure that SFile/Settings/General/Display/"Blank line between decoding periods" is checked. It makes it much easier if 15 second periods are separated by dashes. And as a bonus, you get to know what country the CQer is in. 73, Rich - K1HTV Now over 5,000 FT8 Q's in 139 DXCC countries (116 confirmed) with 50-75W = = = Message: 2 Date: Mon, 18 Sep 2017 11:30:57 -0500 From: Joe mailto:n...@mwt.net > To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net >, Gary McDuffie mailto:mcduf...@ag0n.net > Subject: Re: [wsjt-devel] FT8 is forcing the discipline of split ... I just WSJT-X and JT-Alert can figure out how to run split together. I love how JT-Alert works, and does, but any clicking in JT-Alert puts both REC and TX on the same freq no matter what you have checked in WSJT-X Joe WB9SBD Sig -- 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] Bogus Grids and message progression
Bill, G4WJS & Steve, K9AN, Thanks for your explanation in your previous messages regarding why some FT8 contesters are seeing what appear to be bogus grids being sent. So if I understand correctly, when a user checks the box for the NA contest, his grid is converted to its equivalent antipodal counterpart grid and is transmitted that way. If a receiving station is also set up in the NA contest mode, the antipodal grid which was transmitted is decoded, converted to the actual grid of the sender, and displayed correctly. But if someone receiving that transmission does NOT have the NA contest mode box checked, the grid sent is seen as the antipodal equivalent grid on his display and appears as a bogus grid square to that user, right? If that reformatting the grid for transmission in the NA contest mode is the way it must be done because of bit limitations, then the users will have to deal with it. BUT, explaining it to the average Ham FT8 user is going to be a difficult task. Teaching him how to deal with it is going to be even tougher. As long as there are less knowledgeable FT8 users, during NA VHF contests there will be those who will send contest format messages and the unknowing that will send the non-contest format messages. That is the way it is now, and in all likelihood the way it will continue for all future NA VHF contests. This will continue to cause the frustration and confusion that is being experienced during this VHF contest. How about this suggestion? Is there any way to modify the program to accept either the contest format (K9AN K1HTV FM18) or the non-contest format (K9AN K1HTV -15) as valid TX2 messages and proceed by replying with a Tx3 message? The same holds for the TX3 message reception. Could the program be written in such a way as to accept either a contest TX4 message (K9AN K1HTV R FM18) or a non-contest TX4 message (K9AN K1HTV RRR) as being valid, then continue on to the Tx5 message? If this software change can be implemented, then the situation that exists between contest mode and non-contest mode setups will be eliminated. I'm referring to the fact that presently, neither station can automatically progress through the Tx messages. They are doomed to sending the same message until the the WD timer stops them or the users manually step through the sequences to complete the QSO. Those serious VHF contesters who configure WSJT-X for the NA contest mode will see valid grid numbers, even if the sender hasn't set up for the contest mode. He will note the grid from the initial Tx1 message received. Those that don't set up to use the contest format will continue to ask "what are those bogus grids that I am seeing?". Of course, the answer to them is to RTFM or ask their local FT8 guru.. 73, Rich - K1HTV -- 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] More on bogus grid reports
OK, while running WSJT-X Version 1.8.0-rc 8069, I too now have see a bogus grid report being sent. I answered a CQ by W3ARO . He sent me a report, a Tx2 message, “K1HTV W3ARO OE28”, a bogus grid number, apparently mis-formated by the software version that he was using. . I had switched back to non-contest mode, and turned auto sequence OFF and sent him “W3ARO K1HTV -05”. He responded with an apparent free form text message of “K1HTV W3ARO R FN20” which is a properly formatted Tx3 message. Apparently, seeing that I was sending a dB report, he switched to the non-contest format and we completed the QSO. So, the only bogus grid message that he sent appears to be the Tx2 message. 73, Rich - K1HTV-- 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-X compatibility bugs?
While operating in this weekend's ARRL VHF contest using FT8, two major problems have appeared. 1) Not all stations are using the CONTEST MODE (File, Settings, Advanced tab). As a result, stations using differing "Contest mode" check box settings can not complete FT8 QSOs. The reports being received are not being interpreted as valid exchanges. This results in endless repeats and no completed FT8 contest QSOs. 2) Some stations are reporting receiving bogus 4 character grid squares. I just received an email from a local contester concerning confusing reports being received during the VHF contest using FT8 on 6M. He writes: = = = "Rich, I am puzzled by the unexpected OF10, OF11, OE39, OE39 initial FT8 exchanges some stations (you, K3AJ, N2NT, W3IP, WA3VNV) were sending. Some resulted in puzzled receivers re-sending the R report several times. Where is this explained." = = = I've sent him a reply, asking what version of WSJT-X he is using. If an older version, there may be a compatibility problem. Another local, whom II believe is using Build 1.7.1 r8072, reports decoding a few stations sending bogus grid reports. I have switched from the development builds and have been shaking down " v1.8.0-rc2 8069" but so far I have seen no such bogus grids yet in what I have decoded. I'll report more as I get more input from the guys. 73, Rich - K1HTV-- 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] Unchecked Disable Tx after 73 not working?
Jim & Team programmers, I can understand the "QSO machine" reasoning, but why is the "Disable Tx after 73" box even there? With the box unchecked, the "Enable Tx" box changes from red to gray and no further transmissions are made until manually enabled again, as is expected. One would think, logically, that if the box is CHECKED instead, that this disabling action would NOT take place,. But, we know that a QSO machine feature is NOT desired, so why does the box even exist? Instead, what happens when the "Disable Tx after 73" box is UNCHECKED is that a long series of Tx5 "73" messages is sent at the end of a QSO. They continue to be sent until they are manually stopped. I see no benefit of the box even being there, unless I'm missing something as to what it is supposed to do. Why not hard code the disabling of further transmissions after a Tx5 (73) message is sent and eliminate the "Disable Tx after 73" check box completely? 73, Rich - K1HTV 4,200+ FT8 Q's in 133 countries with <75W = = = Date: Thu, 7 Sep 2017 21:42:35 -0400 From: James Shaver To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] Unchecked Disable Tx after 73 not working? That's normal - user interaction to start another QSO is required to prevent "QSO machines" Jim S. N2ADV On 9/7/2017 7:49 PM, Rich - K1HTV wrote: Using 1.8.0-rC2 r8069 Under Settings, General tab, under 'Behavior', ?the "Disable TX after 73" unchecked. However, ?when the Tx5 (73) message is sent, the log QSO box comes up as it should, but the "Enable Tx" goes from red to gray. This disables further transmissions until the "Enable Tx" button is clicked gain. Shouldn't the system continue on to Tx6, and send the CQ message in the next transmit sequence ? Has this feature been eliminated or maybe I am misunderstanding what the check box is supposed to do? 73, Rich - K1HTV-- 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] Unchecked Disable Tx after 73 not working?
Using 1.8.0-rC2 r8069 Under Settings, General tab, under 'Behavior', the "Disable TX after 73" unchecked. However, when the Tx5 (73) message is sent, the log QSO box comes up as it should, but the "Enable Tx" goes from red to gray. This disables further transmissions until the "Enable Tx" button is clicked gain. Shouldn't the system continue on to Tx6, and send the CQ message in the next transmit sequence ? Has this feature been eliminated or maybe I am misunderstanding what the check box is supposed to do? 73, Rich - K1HTV -- 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] 4 periods before band is displayed
When the box for "Blank line between decoding periods" at the File/Settings/General tab is checked, while using the FT8 mode, is there any reason why four 15 second segments must pass before the band is displayed on the right side of the line? Was the original intent to wait for one 60 second period for JT65 before decoded data was forwarded to PSKReporter to avoid wrong band reports? Instead of 60 seconds before the band is displayed while using and of the 15 second sequence modes, why not skip only one 15 second sequence, then display the band at the right side of the dashed line. 73, Rich - K1HTV-- 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] 8056 (correction)
Jim, A correction: The first line in my response should read "What you state about skipping the grid message and starting with the Tx2 (calls and report) message is NOT the case, at least with the present R-8055 build that I'm using. " That feature does NOT exist in r8055. 73, Rich - K1HTV = = = Message: 1 Date: Fri, 1 Sep 2017 09:50:05 -0400 (EDT) From: Rich - K1HTV mailto:k1...@comcast.net > To: n2...@windstream.net mailto:n2...@windstream.net , WSJT mailto:wsjt-devel@lists.sourceforge.net > Subject: Re: [wsjt-devel] 8056 Message-ID: <880004648.137269.1504273806...@connect.xfinity.com mailto:880004648.137269.1504273806...@connect.xfinity.com > Content-Type: text/plain; charset="utf-8" Jim, What you state about skipping the grid message and starting with the Tx2 (calls and report) message is the case, at least with the present R-8055 build that I'm using. When a station is initially called with the Tx2 message, what is received in reply is a Tx3 (calls plus R-report) message. A high percentage of the almost 4,000 FT8 QSOs that I have made in the past 2 months have been made starting with the Tx2 message. You will find stations starting with the TX2 message in order to work callers at a faster pace. Skipping the grid and saving 15 seconds , as is often being done, is very important, especially when conditions are marginal. Sending a grid square is not a requirement for a QSO to be valid. Send, receiving and confirming the reception of those reports is required. I hope that the 'feature' which you described of getting the message sequence 'back on track' does NOT become part of future builds and eventually the new RC release, which should be out soon. 73, Rich - K1HTV-- 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] 8056
Jim, What you state about skipping the grid message and starting with the Tx2 (calls and report) message is the case, at least with the present R-8055 build that I'm using. When a station is initially called with the Tx2 message, what is received in reply is a Tx3 (calls plus R-report) message. A high percentage of the almost 4,000 FT8 QSOs that I have made in the past 2 months have been made starting with the Tx2 message. You will find stations starting with the TX2 message in order to work callers at a faster pace. Skipping the grid and saving 15 seconds , as is often being done, is very important, especially when conditions are marginal. Sending a grid square is not a requirement for a QSO to be valid. Send, receiving and confirming the reception of those reports is required. I hope that the 'feature' which you described of getting the message sequence 'back on track' does NOT become part of future builds and eventually the new RC release, which should be out soon. 73, Rich - K1HTV PS: 123/98 FT8 DXCC countries worked/confirmed so far = = = Message: 1 Date: Fri, 1 Sep 2017 08:23:07 -0400 From: James Shaver mailto:n2...@windstream.net > To: wsjt-devel@lists.sourceforge.net mailto:wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] 8056 Message-ID: <728d54e4-33bc-9d93-742f-615a05ae4...@windstream.net mailto:728d54e4-33bc-9d93-742f-615a05ae4...@windstream.net > Content-Type: text/plain; charset="windows-1252"; Format="flowed" This was done early on to make sure people followed the sequence - if someone decided to get creative and skip a step, the software is smart enough to get them back on track.? Not sure why skipping the grid and saving 15 seconds is so desired. Jim S. N2ADV - On 9/1/2017 8:19 AM, Erik - wrote: > After calling CQ, if a respondent skips the grid and sends dB report, > the software does not send a R+dB report. Instead it sends a dB report. > > An example: > > I double-clicked on JA4DNC who had answered with -12 but I sent him > -21 instead R-21. This then caused a R+dB report to come back to me > instead of 73. > > Erik EI4KF. > > > -- > -- 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] Wrong country name displayed
Using R8035, on FT8, with the "Show DXCC entity and worked before status" box CHECKED, certain free form CQs messages result in the wrong country name being displayed on the right side of the line in the "Band Activity" column. Examples: CQ USA EA5SW Ukraine CQ ASIA K4MMPakistan CQ N4ERC EM11 Puerto Rico (why would an N4 callsign be interpreted as a KP4?) I thought that free form messages were not supposed to trigger the display of a country name because of the possibility of improper interpretation of the letters following the CQ characters. 73, Rich - K1HTV-- 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] TX freqs change while xmttg
Using R3035, in FT8, with the "Allow Tx frequency changes while transmitting" box UNCHECKED, I am still able to change the TX frequency by Shift-clicking on a different frequency on the waterfall. 73, Rich - K1HTV -- 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] 20 M FT8 freqs for DXpeditions? (long)
Ned- AA7A, Thanks for your insightful response to my post. We agree that new chunks of spectrum need to be identified and used on each band. On 20M that may mean using a segment above 14.115 MHz. Also, the use of FT8 operation can only be successful if calling stations spread out, but as you mentioned, not all transceivers have super wide receive capabilities. But almost all DO have mechanical SPLIT capability, which also could be used. Stations calling the DX from +100 Hz to +2.2 KHz higher than his TX frequency do this software split with a mouse click. But.. SPLIT can also be done with the caller using his transceiver's mechanical SPLIT capability OR by using his transceiver's XIT feature. A DX station transmitting on 14070.2 KHz could easily call "CQ14116 VK9MA" or "UP14KHZ VK9MA" and listen up there. This would force users to do a mechanical transceiver SPLIT. The DX would NOT respond to anyone in the 14.074-076 range. Callers will eventually get the message that the DX is listening UPreally UP :-). This info, of course, would be published in advance. Longer CQ messages may require a software change, but there is a feature used when doing MSK144 split operations. That is, check the box below the "T/R 15 s" box and type in the 3 digit QSX frequency. This will embed the QSX frequency into the CQ message. As mentioned in one of my earlier posts, if the DX decides to stay withing the 14.074-076 segment to work stations, allowing the software to force his TX frequency to QSY to the caller's TX frequency can have positive results with less QRM being received by the calling station. This will be so because the caller hopefully has selected his TX frequency to be on a clear spot on his waterfall display. This should result in fewer repeats by the DX station to the caller being worked. Either way, staying withingthe present 20M FT8 segment or doing a big split, the DX station, after making a number of contacts on one TX frequency may have to move to another one to avoid DQRM. More thoughts/discussion on the SPLIT topic? 73, Rich - K1HTV = = = > On August 20, 2017 at 12:18 PM Ned wrote: > > > Rich, > > I would like to add some perspective of what might happen when what is > called a "Top Ten" DXpedition (a DXCC entity that is in the Top Ten slots in > published need lists...examples being Bouvet and Baker Island that will be > QRV early next year) takes place on RTTY (or any digitial) mode. Having been > the "RTTY guy" on both VP8STI and VP8SGI last year (both on the Top Ten at > that time), the pileups are hard to describe. RTTY operation on these two > DXpeditions was confined to 2 bands, basically, in order to prevent issues > that arise in the use of Clublog Leaderboard. So the DXpedition leadership > opted to limit RTTY to two bands (30 and 15 meters) in order to maximize the > number of ATNOs (All Time New Ones) on the digital modes. As a result, the > pileups were huge and stayed huge until we left both islands. > > When I called CQ the very first day on South Sandwich Island (VP8STI), > the pileup was 30 KHz wide and hundreds deep. I have been in many RTTY > contests and other DXpeditions (27 so far), but I had never experienced > anything like this before. Using MTTY from within N1MM, the logging > application for the DXPedition, it was virtually impossible at times to find > complete calls in the pile. Over half of the time, I had to work QSOs in the > same manner as one does on CW where I would type in a partial call and fix it > when the station would send their report. There seemed to be few chances for > me to use a mouse to pick a call out of an area on the computer screen. My > hands were literally glued to the keyboard to make QSOs at a high rate. I > manually spread the pile by trying to randomly pick calls across the breadth > of the pile to prevent "tailending". I could never pick out one call in a > tailend pile. So, while I was sending my QSL/QRZ message, I literally spun > the dial of the receiver either up or down to a new frequency to work the > next station. After doing this a while, everyone in the pile stopped trying > to tail end and the rates settled into the best that could be done. FT8 is > perfect for doing this, BTW. > > The only real tool in the hands of the DXpedition operator is to spread > the pile until calls could be copied and making it easy for the DXpedition > team operator to briskly sweep the spreadout pile to find calls. What Rich is > suggesting below is spot on. FT8 operation at a Top Ten DXpedition might only > be possible if the operator can make QSOs at a good rate, otherwise they will > go back to RTTY. Rate is king. My fear is that the piles might get so deep
[wsjt-devel] 20 M FT8 freqs for DXpeditions?
Additional 20 M FT8 frequencies for DXpeditions & general DX use The question has been posed as to the best frequencies for DXpeditions while operating the FT8 mode. Lets focus on 20 Meters, which will probably be the most heavily used DX band as we approach the bottom of the solar cycle. >From the IARU Region 1,2 & 3 Bandplan documents: IARU Region 1: 14 060 – 14 070 (200 Hz BW) CW, 14 060 kHz – QRP Centre of Activity 14 070 – 14 089 (500 Hz BW) - Narrow band modes – digimodes 14 089 – 14 099 (500 Hz BW) -Narrow band modes - digimodes automatically controlled data stations (unattended) 14 099 – 14 101 - IBP, exclusively for beacons 14 101 – 14 112 (2700 Hz BW) - All modes – digimodes, automatically controlled data stations (unattended) 14 112 – 14 125 (2700 Hz BW) All modes * * * * ** IARU Region 2: 14060-14090 (500Hz BW) - ALL MODES, DIGIMODES 14100.5-14125 (2700Hz BW) - ALL MODES, FAST DIGIMODES, AUTOMATIC IARU Region 3: Considering the dramatic increase in data mode usage on the 20 meter band, it is recommended that the sub-band for these classes of signals be 14.070 MHz to 14.112 MHz (with +/- 500 Hz at 14.100 MHz for beacons), and within that data sub-band the current practices of traditional data modes may continue up to 14.095 MHz with 14.095 to 14.112 MHz being reserved for other data modes including Packet. - - - - - - - In IARU Regions 1 & 2, both indicate ALL modes up to 14.125 MHz. Only in Region 3 are the digital modes recommended between 14.070 and 14.112 MHz. For major DXpeditions in Regions 1 & 2 is there any reason why frequencies above 14.112 MHz can't be used for the FT8 mode by DXpeditions or for FT8 DXing in general? It has been less that 2 months since WSJT-X software with the FT8 mode has been made available to the general Ham population. But already the frequency range between 14074.2 and 14076.4 KHz is very often packed with hundreds of stations simultaniously using that small segment. And the congestion will only get worse in the months to come, especially when DXpeditions start using the new digital mode. I would strongly suggest that serious consideration be given for the use the FT8 mode on 20 Meter frequencies between 14.112 and 14.125 MHz. 73, Rich - K1HTV-- 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] DXpeditions - FT8, Split or not to split
DXpeditions - FT8, Split or not to split Having a great amount of success DXing on HF (363 countries, 7 band triple DXCC, HR, etc) running low power, and having already worked over 2800 QSOs in 117 DXCC countries on FT8 with 50-75 Watts, I believe that I have a pretty good insight of what does and does not work when it comes to working DX in general and working FT8 DX in particular. It has been suggested that a DXpedition remain on one transmit frequency while operating the FT8 mode and work split, listening over a wide range of frequencies. If you are a DXer who has been around for a while, you probably have suffered from the effects of DQRM (Deliberate QRM). It wouldn't take much for a few frustrated DQRMers to double click on the DXpedition's fixed FT8 frequency and transmit garbage messages. They would make it next to impossible for many callers to decode the DXpedition's FT8 transmissions. Then there is the case of newbie FT8 ops click on the line of a caller, causing the newbie to transmit during the same TX cycle as the DXpedition. I see it happening nowI will see it again and again as even more new ops show up on FT8 to work a new DXCC entity on a digital mode. Because of this, I strongly recommend that future DXpeditions' FT8 operators consider the following: 1) Check the "Lock Tx=Rx" box 2) UNCHECK the "Call 1st" box. 3) Check the "Auto Seq" box With the "Lock Tx=Rx" box checked, when the DX clicks on the line of a caller, he would QSY and call on the caller's relatively quiet (to the caller's ears) TX frequency. Callers would try to pick a transmit frequency which appears to be quiet during his station's receive cycle. That means when the DX station replies to a caller, the caller would have a much better chance of decoding the DX. This moving target would completely foil DQRMers ability to cause QRM to the DXpedition. Since the caller is decoding the entire passband, the DX station's transmissions should be copied most of the time, no matter which frequency the DXpedition transmits on. Unchecking the "Call 1st" box would allow the DX station to call anyone he wants, the strongest, the weakest, or callers being copied over a difficult propagation path during a very short opening to that area. With the "Auto Seq" box checked, the software would sequence through the QSO steps, but only after the DXpedition op started the process manually by selecting the station he wants to answer next. I'll comment on the best frequencies to use in my next post. 73, Rich - K1HTV www.qrz.com/db/k1HTV-- 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] Wrong country
Thanks Bill for the software fix for this issue and for all that you do as part of the WSJT-X Development team. 73, Rich - K1HTV PS I'm now up to 116 DX countries worked on FT8 with low power. FT8 is GREAT! = = = From: Bill Somerville mailto:g4...@classdesign.com > To: wsjt-devel@lists.sourceforge.net mailto:wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] Wrong countrty Message-ID: <15d89051-9919-0064-b419-20e89abda...@classdesign.com mailto:15d89051-9919-0064-b419-20e89abda...@classdesign.com > Content-Type: text/plain; charset=utf-8; format=flowed On 16/08/2017 04:47, Rich - K1HTV wrote: While using FT8 I noticed this anomaly. 031330 -14 0.1 1769 ~ CQ E51 W3BTX !S. Cook Is. With the "Show DXCC entity and worked before status" box under the " General" tab checked, instead of W3BTX being flagged as U.S.A. it used the E51 prefix in the line and erroneously marked the country as South … Hi Rich, thanks for reporting this issue. The problem is two fold, firstly is not a standard form message and secondly the WSJT-X handling of extracting the callsign from CQ and other similar general call messages was not discriminating enough. I have made a change for the next release that will not make the above mistake, nor will it recognize the above message as a general call in standard format so no attempt will be made to tag it with a DXCC entity name. Other valid standard form messages such as "CQ VT G4WJS IO91" will be correctly tagged with the DXCC entity. 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] Wrong countrty
While using FT8 I noticed this anomaly. 031330 -14 0.1 1769 ~ CQ E51 W3BTX !S. Cook Is. With the "Show DXCC entity and worked before status" box under the " General" tab checked, instead of W3BTX being flagged as U.S.A. it used the E51 prefix in the line and erroneously marked the country as South Cook Island. This occurred using v1.7.1-devel r8026 build. 73, Rich - K1HTV-- 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] Auto seq while answering split
Ron, As long as your signal frequency is within plus or minus 50 Hz of the station you are calling, the red "Enable Tx" will be disabled and go grey when you decode the station you called replying to someone else. However, when your signal is 51 Hz or more either side of the stations frequency, you will continue transmitting during your TX sequence. When your transmitting frequency is outside the decoding window for the nominal 47 Hz wide signal, the QRM problem to the decoder is greatly reduced. Operating more than 50 Hz away from a station that you are calling will increase your chances of being decoded by that station. The majority of stations calling a DX station are probably operating zero beat right on the DX station's frequency and as a result the DX will probably not decode any of them. Running split with the "Lock Tx=Rx" box UNCHECKED for the most part, I've been able to work 111 DXCC countries in the 4+ weeks that I've been running FT8 on the HF bands with low power (50 to 80 Watts). Just double click on the DX station callsign, find a quiet frequency, then Shift-click on it and your chances of working the DX will greatly increase. 73, Rich - K1HTV -- From: Ron Gibson mailto:ve3...@sympatico.ca > To: wsjt-devel@lists.sourceforge.net mailto:wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] Auto seq while answering split Message-ID: <190ab13b-642f-459c-80a6-6d7f090b2...@sympatico.ca mailto:190ab13b-642f-459c-80a6-6d7f090b2...@sympatico.ca > Content-Type: text/plain; charset=utf-8; format=flowed Even though I fear that I'll be criticized for reporting a 'known' defect, I would like to report that when I answer a CQ and I'm using split, if the calling station responds to another caller r8018 does not disable TX. If no split it works as it should. 73 de Ron VE3CGR / CG3CGR-- 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] 15 vs 30 sec Fast Graph header
While running MSK144 with 15 second sequencing for Perseids meteor scatter operation this morning, I noticed that instead of the Fast Graph header reading 0-15 it reads 0-30 seconds. Would it be possible for the time header to change based on the length of the chosen 15 or 30 second sequence? 73, Rich - K1HTV PS - The Perseids meteors were flying this morning. Looks like a good shower this year with the peak coming within the next 24 hours.-- 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] Why wipe Tx6 message?
Mike, Tnx for responding to this request. Until the modification gets into the version downloaded by the masses, this feature won't be able to be used by most. I don't believe that this weekend's crew doing the OJ0 (Market Reef) DXpedition are building their WSJT-X software and will be using the present RC1 version. Thanks for the changed code. Hope that it can permanently be implemented in the final release for all to use. 73, Rich - K1HTV -- Message: 1 Date: Fri, 11 Aug 2017 11:13:00 + (UTC) From: Black Michael mailto:mdblac...@yahoo.com > To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net > Subject: Re: [wsjt-devel] Why wipe Tx6 message? Message-ID: <1301556709.1708692.1502449980...@mail.yahoo.com mailto:1301556709.1708692.1502449980...@mail.yahoo.com > Content-Type: text/plain; charset="utf-8" Seems to me we just need to fill TX 6 when it's empty and leave it alone after that. ?It never changes under normal ops. ?So when you put in your custom CQ it never gets touched again. This simple patch sets TX6 only if it's empty for modes other than JT6 and QRA64, This should get you going for the weekend I think.-- 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] Why wipe Tx6 message?
Bill, Yes, I know that the Tx5 messages can easily be stored and retrieved. But in R8021 and other builds, when I click on a call of a station replying to my CQ, the special message stored in TX5 gets wiped out. That means every time I want to again use that special message I need to go the Tx5 drop down menu, find it and select it AGAIN. In the case of future DXpeditions using FT8, of which I'm sure there will be many, having to pull down a special message such as "CQ P5AA SPLT" or "CQ P5AA UP" after every QSO will be a real inconvenience and a pain. Again, what is needed is a CQ message box that can be frozen without having to reprogram it after each QSO. Many DXers use special CQ messages such as "CQ DX call Grid" or CQ NA call Grid". As the program works now, after each DX QSO they need to re-populate the CQ box. Why can't one of the boxes be frozen is again my question. 73, Rich - K1HTV = = = Date: Fri, 11 Aug 2017 00:47:54 +0100 From: Bill Somerville mailto:g4...@classdesign.com > To: wsjt-devel@lists.sourceforge.net mailto:wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] Why wipe Tx6 message? Message-ID: mailto:a494f2b1-2be6-915e-94ac-1fc57b1a2...@classdesign.com > Content-Type: text/plain; charset=utf-8; format=flowed On 11/08/2017 00:40, Rich - K1HTV wrote: The first FT8 DXpedition using FT8 will occur this weekend as OH2BR & OH2JR operate from Market Reef as OJ0BR & OJ0JR. In responding to an email from Martti, OH2BR, I suggested that since he would not be able to copy anything from multiple stations calling on the same frequency, that he run split. I… HI Rich, non-standard messages can be added to the free text macros, just enter them into Tx5 (or Free text on tab 2) and hit ENTER, they will be save on the macros list and can be recalled with a couple of mouse clicks. On tab 2 they do not get overwritten either. 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] Why wipe Tx6 message?
The first FT8 DXpedition using FT8 will occur this weekend as OH2BR & OH2JR operate from Market Reef as OJ0BR & OJ0JR. In responding to an email from Martti, OH2BR, I suggested that since he would not be able to copy anything from multiple stations calling on the same frequency, that he run split. I suggested he program a CQ message "CQ OJ0BR UP" or CQ OJ0BR SPLT". However, this Tx6 message would only work for one CQ. When a station was answered, clicking on it would erase the Tx6 message. He would have to type in the special CQ message over and over to direct stations to call on another frequency. Is there any reason why the TX6 message couldn't be left alone when clicking on a station answering a CQ message and NOT be changed to the stock "CQ call Grid" Tx6 message? 73, Rich - K1HTV -- 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] Quicker FT8 QSOs
Although Alex's idea of speeding up DXpedition QSOs using is a great one, how would the caller's software recognize that the 73 was directed to his station? Neither the caller just worked or DX station's call would be contained in the "73" line which starts a QSO with the next station. It appears that, as it is now done for CW QSOs with DXpeditions, it would require manual intervention by the station being worked to stop further transmissions after the "73" message was received. However, might I suggest the following idea: All callers would start with the "Tx2" message (Calls and report). During each of the DXpedition station's 15 sequences, it would respond with, for example: "W3LPL +30 VK9MMM RR73" Next, many callers call VK9MMM and hearing K1JT, VK9MMM would respond with: "K1JT +20 VK9MMM RR73" more callers call VK9MMM and hearing VE3NEA he responds with: "VE3NEA +10 VK9MMM RR73" Etc, etc, etc. until the pileup is worked. As long as there is a never ending line of callers, the DXpedition could maintain a maximum QSO rate of 120 per hour. The caller's software, recognizing both his and the DXpedition's call signs plus the "RR73" would stop further transmissions, as no more would be required. What say WSJT-X software specialists? Can do? 73, Rich - K1HTV PS - In less than a month, I've worked 102 DXCC countries using FT8 and 50 Watts. FT8 IS GREAT!!! = = = Date: Tue, 8 Aug 2017 15:17:39 -0400 From: Alex, VE3NEA mailto:alsh...@dxatlas.com To: wsjt-devel@lists.sourceforge.net mailto:wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] WSJT on DXpedition Message-ID: mailto:e3238a4d-de01-870f-4757-419937eff...@dxatlas.com > Content-Type: text/plain; charset=utf-8; format=flowed FT8 differs from the traditional modes in one important way: multiple signal decoding. This opens a possibility to significantly increase the speed of a pileup QSO by using a shortened QSO sequence. Here is one possibility that would increase the QSO rate up to 120/hour: CQ VK9MMM QH72 VK9MMM VE3NEA FN03, VK9MMM K1JT FN20, VK9MMM W3LPL FM19 --- W3LPL VK9MMM +30 VK9MM W3LPL -20 --- 73 NOW K1JT +20 VK9MM K1JT -20 --- 73 NOW VE3NEA +10 VK9MM VE3NEA -20 --- 73 CQ VK9MMM QH72 ... This would require a new message, "73 NOW...", in addition to already defined "CQ...", "CQ DX...", etc. Another message, "73 CQ...", would also save some redundant transmissions by confirming the current QSO and requesting new calls at the same time. 73 Alex VE3NEA 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] FT8 "Tx Even/1st" label ambiguity
Bill, There is no confusion as to what are considered even and odd minute numbers. But as long as I have been doing meteor scatter (since the mid 60's), here in the States, for 15 second sequence M/S schedules, we have always considered each minute to be broken into 4 sequences. The first and third 15 second periods are called ODD and the 2nd and 4th periods are called EVEN. Your way of reasoning 'even' and 'odd', when referring to 15 second periods, assumes that the even periods begin at the 00, 15, 30 & 45 second marks. Others may reason that the first period starts at second number 01 and not second number 00. Have European meteor scatter enthusiasts always considered the first 15 second period of each minute to be odd or even? I believe that my suggestion of changing the present FT8 screen's "Tx even/1st" description to "1st & 3rd 15 second sequence" or an abbreviated version of "1st & 3rd 15 sec seq" will make the meaning of the check box very clear as to eliminate the present ambiguity. 73, Rich - K1HTV = = = Date: Fri, 4 Aug 2017 18:59:40 +0100 From: Bill Somerville mailto:g4...@classdesign.com > To: wsjt-devel@lists.sourceforge.net mailto:wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] FT8 "Tx Even/1st" label ambiguity Message-ID: <15936bbf-e02c-0491-420c-19b944bf1...@classdesign.com mailto:15936bbf-e02c-0491-420c-19b944bf1...@classdesign.com > Content-Type: text/plain; charset="utf-8"; Format="flowed" On 04/08/2017 18:52, Rich - K1HTV wrote: > On the FT8 screen, there is an ambiguity as to meaning "Tx even/1st". > A number of folks new to the mode have expressed some confusion as to > their meanings. > Hi Rich, I don't understand. 0 and 30 are even numbers, 15 and 45 are odd. If anything the 60s T/R periods should cause confusion, but there minutes 1, 3, 5, ... are odd, minutes 0, 2, 4, 6, ... are even. Time uses zero based indexing (well apart from months but they are strange in all respects!), so the 15s T/R periods are the zeroth, first, second, third. 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] FT8 "Tx Even/1st" label ambiguity
On the FT8 screen, there is an ambiguity as to meaning "Tx even/1st". A number of folks new to the mode have expressed some confusion as to their meanings. With 15 second sequencing, "Tx even" can be interpreted as meaning transmit on the even sequences, that is, the 2nd and 4th 15 second sequence. With 15 second sequencing, "1st" can be interpreted as transmit on the first, and subsequently, on the 3rd sequence. The two meanings, as related to 15 second sequencing, are at odds. Why not, for the FT8 screen, change that check box definition to: "1st & 3rd 15 second sequence" or an abbreviated "1st & 3rd 15 sec seq" ? 73, Rich - K1HTV-- 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] Remove "Lock Tx=Rx" QSY 'feature'?
Bill, Jim, et al, As we all know, a double click on a CQer's callsign results in both the TX and RX frequency changing to the CQer's frequency, even with the "Lock Tx=Rx" unchecked. However, with the box unchecked, if a user clicks on a different frequency to call CQ, only the RX frequency and the green bracket change. To change the TX frequency one must hold the 'Shift' key... but then only the TX frequency and the red bracket change. Not many know that to move both TX & RX freqs requires holding the "Ctrl"key down while clicking on the desired TX/RX frequency. That is why most folks keep the TX=RX box checked, because it is easier. But as Jim mentioned, doing so pulls the station you just worked back to your frequency, resulting in possible QRM to you. Maybe the answer with FT8 would be to remove the feature of pulling the other station to your frequency and have him stay on his original TX frequency. A good reason for him to stay there is because: 1) You were copying him well there. 2) In all likelihood, he was copying you better on your frequency rather that through multiple callers on his own frequency. I can see that with modes where a narrow 'Tol' is used that the calling station to be on or very near to your TX frequency. But with FT8, where almost all users want the the entire frequency range decoded, I don't think that it is desirable to have a calling station moved away from his original operating frequency to a different one simply because he had the "Locked Tx=Rx" box checked. What is gained by this? If the box was completely eliminated then double clicking on a call sign would move the TX & RX freqs to the CQer's frequency. After this is done, those who want to call off frequency can use one of a number of available keyboard shortcuts. 73, Rich - K1HTV = = = On 04/08/2017 02:22, James Shaver (N2ADV) wrote: I had a FT8 QSO with W7PSK earlier (thanks!) where I was calling CQ, he responded to me, we went through the sequence, he sent his 73 and then moved off to call CQ elsewhere on the band. Unfortunately, my 73 pulled his TX back to where I was causing him to accidentally start calling CQ where he had … Hi Jim, I can reproduce that behaviour if I have him with "Lock Tx=Rx" checked. The more use cases I test with auto-sequencing the more I am growing to dislike "Lock Tx=Rx". I will see if I can work out how to stop this sort of thing happening. 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] WSJT-X Shortcut list
Mike, Duhhh, so its under HELP. What a novel idea :-). So far I've made 1009 FT8 QSOs and you would think that I would explore the menus more to learn more about this great program. Nope, I'm too busy using WSJT-X to read all the doco. Thanks. 73, Rich - K1HTV = = = Date: Thu, 27 Jul 2017 19:52:50 + (UTC) From: Black Michael mailto:mdblac...@yahoo.com > To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net > Subject: Re: [wsjt-devel] Disabling "Enable TX" only works with "TX1" Message-ID: <1220099253.558097.1501185170...@mail.yahoo.com mailto:1220099253.558097.1501185170...@mail.yahoo.com > Content-Type: text/plain; charset="utf-8" Shortcut keys are under Help/Keyboard Shortcuts and F3 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] More on disabling TX when not answered
Using R7965, I noticed that if I answer a station's CQ and my TX frequency is more than 10 Hz away from his frequency, if he comes back to another station, my "Enable Tx" is NOT turned off. The result is that I continue to call as the station that called CQ as he is working another station. I must manually stop my transmissions. I can see that if I am more than 50 Hz away, I probably am not causing any problems to the CQer. However, if my frequency is within +/- 50 Hz of the CQer's frequency I could be causing enough QRM to prevent him from decoding the station he is trying to work. Wouldn't it be better that if the CQer responds to another station, that my TX be disabled only if my TX frequency was LESS than +/- 50 Hz from the CQer? 73, Rich - K1HTV-- 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] Band indicator on separating lines
Using R7965, I have Settings/General/Display "Blank line between decoding periods" checked. When the band is changed using the band pull down menu, my K3 changes bands properly and the proper meter band is properly displayed on the right side of each line of dashes in the "Band Activity" column. However, when the band is changed on the K3 via the radio's 'Band" up/down buttons, the name of the band being decoded does not appear on the far right side of the separating dashed lines until FOUR 15 second sequencing periods go by. Is this normal? 73, Rich - K1HTV -- 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] Disabling "Enable TX" only works with "TX1"
Bill, OK, so the key to starting with the TX2 message is to double click on the round bullet to the left of TX1 until the message text is greyed out. Then when I click on the CQing station's call, the TX1 message is skipped and the TX2 message is transmitted...got it. By doing this, now when a station called does NOT come back to my call, even if I use the TX2 message, the red "Enable Tx" button goes grey and my further calls to that station are stopped. Thanks. BTW, I've been reading the WSJT - Revision 7960: guide at: /branches/wsjtx/doc/user_guide/en But I haven't yet found where all of the various shortcut keys are defined. 73, Rich - K1HTV = = = Hi Rich, how are you selecting Tx2 to reply to a CQ call? If you are doing so by clicking the buttons next to it then WSJT-X will assume you know what you are doing and are already in a QSO. To use Tx2 to reply to CQ or QRZ calls you can double-click either of the buttons next to the Tx1 message to disable it, it will be greyed out to show that and Tx2 will be automatically used to reply to make initial calls to stations when you double click a decode. 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] Disabling "Enable TX" only works with "TX1"
Using R7956, Tom is correct in that if the station you called answers another station, the "Enable TX" is stopped. But it is only true if you use the "Tx1" message to make the call. If the TX1 (Calls & Grid) message is skipped and the call is made by using TX2 (Calls and report), if the station called comes back to another station, the "Enable TX" remains red and calling continues on subsequent sequences until the "Halt Tx" button is clicked. I believe that no matter which TX message is being used, "Enable Tx" should be turned off automatically if the station I called is in the process of working another station. 73, Rich - K1HTV = = = Date: Wed, 26 Jul 2017 15:38:18 -0500 From: Tom-KQ5S mailto:kq5s...@gmail.com > To: WSJT-Dev mailto:wsjt-devel@lists.sourceforge.net > Subject: [wsjt-devel] 7956 - Stop Transmitting when Another Station Answers a CQ Message-ID: mailto:CABBJzNijFxppHxbmPZZohYFmmfcnHPHx4tf2=1-25cqjp5k...@mail.gmail.com > Content-Type: text/plain; charset="utf-8" Really like how the program will now stop transmitting if another station beats you answering a CQ call. 73, Tom - KQ5S-- 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-X: How to handle using RR73 as a final
I wouldn't worry about anyone ever being active in grid RR73. It is a water grid in the Russian Arctic region. $100 to the first guy to work a legitimate maritime mobile station on FT8 from grid RR73 :-). Its a non-problem. 73, Rich - K1HTV > On July 20, 2017 at 12:29 PM Bill Somerville wrote: > > > On 20/07/2017 17:27, Bill Turner wrote: > > How about R-73 to avoid confusion with grids RR-73? > > Hi Bill, > > that defeats the purpose of RR73, it is because it is a valid grid that > two complete callsigns can be sent with it as a standard message. You > suggestion would require a free text message with a 13 character (inc. > spaces) size limitation. > > 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-X: How to handle using RR73 as a final
G4WJS. Bill, Regarding the use of "RR73", I believe that it should be formalized as an option to the present "73" TX5 message. Let's look at this senario regarding when a QSO is assumed to be complete: Station #1 sends Station #2 a report. Station #2 sends either "RRR" or "RR73" because he has received Station #1's "RR-report". At this point Station #2 believes the QSO is complete because of the rogers he has heard in the "RRR" or "RR-report" which has been received. But Station #1 still needs to have confirmed that his "RRR" or "RR73" report has been received. This confirmation in the mind of Station#1 is realized if: 1) An "RRR" or "RR73" message is received from #2. 2) He copies Station #2 that he was working immediately calling CQ or responding to another station. In either of these two cases, the contact can be assumed to be complete. There would be no need for station #2 to continue sending either "73" or a repeat of "RR73". I believe that if either TX5 messages ("73" or optional "RR73") is sent, it should only be sent only once, then the TX disabled, if this option is checked. However..if Station #1 does NOT hear Station #2 either calling "CQ" or another station, then there will be a question in his mind of the QSO being complete. This can happen under rapidly changing propagation conditions, as happens on 50 MHz. In that case, I would assume that Station #1 would continue sending his "RR-report" in hopes that Station #2 would see that Station #1 still needed a confirmation. If Station #2 saw this, he would have to click "TX Enable" and send another "73" or "RR73". Thanks for the coding that you have been doing to make the WSJT-X suite of modes the success that they have become. 73, Rich - K1HTV = = = Date: Thu, 20 Jul 2017 13:18:01 +0100 From: Bill Somerville mailto:g4...@classdesign.com > To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net > Subject: [wsjt-devel] WSJT-X: How to handle using RR73 as a final message Message-ID: <83d72269-18c6-a0ee-1f35-f19987dc1...@classdesign.com mailto:83d72269-18c6-a0ee-1f35-f19987dc1...@classdesign.com > Content-Type: text/plain; charset=utf-8; format=flowed Hi All, we are looking at changing the WSJT-X logic such that a grid message of the form: " RR73" is treated as a sign off message. This has several implications and I need some clarification so that I can adjust the code. For now I will put aside any potential issues for holders of compound callsigns as I have not analysed the impact for them yet. The first change is already in place, sending such an RR73 message is treated the same as sending a standard 73 message or any free text message containing the word "73". This means that, if prompt to log after 73 is set the log QSO window will be popped up, and if "Settings->General->Behavior->Disable Tx after 73" is checked, auto transmit will be disabled and the next message to be sent will be moved on to Tx6 (CQ message). This part is straightforward. I propose to add a check box option to "Settings->General->Behavior" along the lines of "Use RR73 in place of RRR", when checked this would generate the above RR73 message for the Tx4 (RRR) message, thus formalizing the usage of RR73 as a final QSO message. So now the questions. If we have disabled auto Tx and switched the next message to Tx6/CQ, how do we proceed if no "73" message is received from ones QSO partner. Listening on the bands it seems that sending an RR73 message has some special significance in that it is always assumed to be received by ones QSO partner. This may be reasonable in propagation such that any subsequent messages can be taken by ones QSO partner to mean that the QSO is indeed complete even if the RR73 message was never decoded. For example if you have called a station calling CQ, received a report, sent a R+report and then get no decode from them in the next period; then the next decode from the other station is a CQ call or them giving a report to a different station or even calling another station on a different frequency, then are we safe to assume that our QSO was complete and there is no requirement to repeat the R+report message (the normal action if an RRR message is not decoded) or even send a 73 message ourselves? BTW this does beg the question of how a station running a frequency completes their last QSO on a band, do we take silence to be an indication that a missed RR73 decode was in fact sent. The above is fairly easy to implement in that, if an RR73 message is received from ones QSO partner ones next message will be set to Tx5/73 (note not RR73) and if prompt to log is checked the log QSO window will pop up. Al
[wsjt-devel] Add "FT8 Contest Mode" option
In the recent CQ VHF contest I used both MSK144 and FT8 for making many (110) digital contacts. The MSK144 mode already has a checkbox under File/Settings/Advanced for "MSK144 Contest Mode" which allowed the transmission of grid square reports. There presently is no such option for FT8. I believe that with the most certain heavy usage of FT8 in future VHF contests, it would be a good idea to also make an "FT8 Contest Mode" option available. Thanks for your consideration of this for future releases of WSJT-X. 73, Rich - K1HTV -- 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] Rovers and FT8
Tim, You are right, as I thump my forehead :-). ! The problem is there, but the ones that have the problem are us folks that work the rovers or other stations with the slash bar. However as was mentioned, this issue is already being addressed an will be resolved in the R2 release of 1.8 in the near future. 73, Rich - K1HTV > On July 18, 2017 at 7:07 PM Tim Goeppinger wrote: > > Rich, > > The problem is that as a rover, the people I contact have to be the ones > who have to be on their toes with the mouse clicks, as N6RMJ was for me. > There is nothing I can do on my end. > 73, > Tim N6GP > > > --------- > From: Rich - K1HTV > To: tim...@yahoo.com; WSJT > Sent: Tuesday, July 18, 2017 2:34 PM > Subject: Rovers and FT8 > > Tim, > I believe that since the "/R" is eliminated from the exchanges, the > original "CALL/R" which a station responds to does not match the "CALL" w/o > the "/R" which is sent in subsequent steps. Since there isn't a match, it > won't automatically proceed to the next step in the sequence. Until/Unless > this can be fixed, the answer is to manually step through the steps, which > means you will have to always be on your toes with a quick mouse button > trigger finger to successfully complete each QSO. I believe that this holds > true for any complex station call with a slant bar in it. > > 73, > Rich - K1HTV > > > > -- 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] Rovers and FT8
Tim, I believe that since the "/R" is eliminated from the exchanges, the original "CALL/R" which a station responds to does not match the "CALL" w/o the "/R" which is sent in subsequent steps. Since there isn't a match, it won't automatically proceed to the next step in the sequence. Until/Unless this can be fixed, the answer is to manually step through the steps, which means you will have to always be on your toes with a quick mouse button trigger finger to successfully complete each QSO. I believe that this holds true for any complex station call with a slant bar in it. 73, Rich - K1HTV -- 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] FT8 for the visually impaired
Joe and the WSJT-X software development team, First, congrats on the superb job you all have done in the creation of the new FT8 mode. It works great! In 5 days, while running 50 Watts, a triband yagi and wire antenna, I've managed to work 62 countries using FT8, including some nice catches such as Bahrain, Iraq, Armenia, Japan, Gabon on 20M and multiple VK's on 20M & 40M . I wish that 6 Meter propagation to DX lands would improve so we can exercise the mode under multi-hop conditions on the Magic Band. Its been fun, but, the main reason for this note is a request for you all to consider. One of my fellow DXer friends, with 355 countries confirmed and on the DXCC Honor Roll, is interested in using the new FT8 mode but is visually impaired. I wonder if there might be a way to make FT8 available to him and other blind Radio operators? Some additional features would need to be incorporated, such as: - Shortcut keys for various required functions (TX Enable, TX disable, TX6-CQ, Monitor ON, etc.) - If voice output of alpha numeric WAV files is not possible, maybe an ASCII output stream could be fed to a second COM port to feed an external text-to-voice reader. - UP/Down function keys to control pointing to lines in the "Band Activity" window to be voiced. - A key to select a chosen line which would then populate the message box and activate TX Enable. - Voice the characters of the line being transmitted so the blind op would know the progress of the QSO. - Although an ALT-Q will manually log a QSO, it would be helpful is there was an automatic logging of a completed QSO data into an ADIF file for easy uploading to LOTW. I know that it is important to get solid WSJT-X code for release. But, once this has been done, it would be great if the WSJT-X team could make the necessary additions so visually impaired Hams could use the new FT8 mode. Thanks in advance for your consideration of this request to help our fellow blind Radio Amateurs join in the fun of this new digital mode. 73, Rich - K1HTV-- 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] FT8 and "Call 1st"
Gordon, I believe that is that way because once you disable Auto Seq it will continue sending your last message over and over and not go to the next step to disable TX. The answer is that if you want to send a free test TX5 message, populate the message box and turn off Auto Sequence. Then proceed the old fashion, JT65 way, of clicking on the message you want to be sent next until the QSO is complete. 73, Rich - K1HTV = = = Send wsjt-devel mailing list submissions to Date: Wed, 12 Jul 2017 12:38:16 +0100 From: Gordon Higgins mailto:g3pxt1...@gmail.com > To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net > Subject: Re: [wsjt-devel] FT8 and "Call 1st" Message-ID: mailto:cadbfavh2ztxabpkqueucsavj4pg45ct-jrfsl_zyk-zudak...@mail.gmail.com > Content-Type: text/plain; charset="utf-8" ? why in auto seqence will it not send free text tx5 ft8 ? -- 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] Disable TX if called stn answers other
I agree with Ross, N4RP in the software automatically halting your transmission if the station you called came back to another station. The problem is that by the time 'wetware' gets info from eballware which has to scan the screen to see if another is calling, and then tell fingerware to determine where eyeware says the disable TX button is...by that time you have interfered with the QSO in progress. For that reason, having the WSJT-X software halt your calling the station that answered someone else, I believe that the suggested feature be incorporated into future releases. 73, Rich - K1HTV PS - I'm finding FT8 to be great for DXing. In the past 2 days with 50W on HF I've already worked 25 countries, the best DX being Australia, Japan, Armenia and a contact with a rare one, Iraq. = = = Date: Wed, 12 Jul 2017 07:15:31 -0400 From: James Shaver (N2ADV) mailto:n2...@windstream.net To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net > Subject: Re: [wsjt-devel] FT8 and "Call 1st" Message-ID: mailto:f60d4286-935e-4897-ba37-17cf76847...@windstream.net > Content-Type: text/plain; charset=utf-8 That's built into the wetware (brain matter) of the person controlling the program 😊 > On Jul 11, 2017, at 10:22 PM, Ross Primrose mailto:n...@n4rp.com > wrote: > > One feature I'd like to see is if you answer a CQ, and the station comes > back to someone else, halt tx... > > 73, Ross N4RP > -- 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