Re: [wsjt-devel] Release Candidate WSJT-X 2.7.0-rc1
This also affected the IC-7610, but the new file fixed the problem. 73's George - WB5JJJ HoIP - 100105 On Fri, May 12, 2023 at 2:43 PM Black Michael via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > Try this dll please > > https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0 > > Mike W9MDB > > > > > > > > > On Friday, May 12, 2023 at 12:37:02 PM CDT, Gerald Smith via wsjt-devel < > wsjt-devel@lists.sourceforge.net> wrote: > > > > > > Hi Mike, > > Thanks for the link. > > Well, I placed the dll file in this directory C:\WSJT\wsjtx\bin, and > rebooted the computer, but I am still getting the error. > > So, then I tried re-installing 2.7.0-rc1, and rebooting the computer > again, I still have the error. > > Sorry. > > 73 de WA3ZSC - Jerry > > > On 5/12/2023 13:07, Black Michael via wsjt-devel wrote: > > Direct link > > > > https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=1 > > > > Mike W9MDB > > > > > > > > > > > > > > > > > > On Friday, May 12, 2023 at 12:01:57 PM CDT, Black Michael via wsjt-devel< > wsjt-devel@lists.sourceforge.net> wrote: > > > > > > > > > > > > Please try this DLL > > > > https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0 > > > > Mike W9MDB > > > > > > > > > > > > > > > > > > > > On Friday, May 12, 2023 at 11:55:54 AM CDT, Gerald Smith via wsjt-devel< > wsjt-devel@lists.sourceforge.net> wrote: > > > > > > > > > > > > > > Hi Joe, > > > > Sorry, but I get this error with WSJT-X 2.7.0-rc1. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Radio IC-7700, interface - Timewave Navigator. > > > > WSJT-X 2.6.1 works fine though thought that I should let you know. > > > > 73 de WA3ZSC - Jerry > > > > > > > > > > > > > > > > > > On 5/12/2023 11:20, Joe Taylor via wsjt-devel wrote: > > > > > >> We are pleased to announce that Release Candidate WSJT-X 2.7.0-rc1 is > >> ready for download by beta testers. > >> > >> > >> > >> > >> ___ > >> 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 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 mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib Beta Testing Group needed
This also affected the IC-7610, but the new file fixed the problem. 73's George - WB5JJJ HoIP - 100105 On Sat, May 13, 2023 at 3:29 AM Tom M0LTE via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > Hey Uwe > > While manual testing could probably never be eliminated in the case of > hamlib, has there been any consideration of creating test harnesses to > remove/reduce the need for manual testing? > > It strikes me that there could be potential to capture test cases from > manual testing with real rigs, then at least there would be regression > tests. Future bug fixes could have test cases added to prevent further > regression, again without requiring physical radios and manual testing. > > Apologies if I am not the first to ask this question. > > Kind regards > Tom M0LTE > > On Sat, 13 May 2023 at 08:11, Uwe, DG2YCB via wsjt-devel < > wsjt-devel@lists.sourceforge.net> wrote: > >> Dear WSJT-X users, >> >> Please allow me to summarize again here on this email reflector a topic >> that is very important to me and to all of us. My original post was on >> https://groups.io/g/wsjtgroup, so maybe it's best if you join the >> discussion there. >> >> Despite great personal commitment of the hamlib developers it has >> unfortunately happened very often that immediately after a new WSJT-X >> release serious problems with one or another hamlib rig driver become >> apparent. If something like this happens over and over again, it shows that >> there is a *systematic* error somewhere. In my opinion this is due to >> the fact that *too few* users try the current development versions of >> hamlib, so that errors are detected *too late*. Keep in mind that hamlib >> drivers often change as they evolve. >> >> So I* would like to ask you all that enough OMs act as hamlib bata >> tester in the future.* For those who own one of the rigs below and work >> on Windows, just do the following every 2, 3 or 4 weeks: >> >>1. Download the daily updated libhamlib-4.dll file available on >>https://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll. >>2. Copy the file to the bin folder of your WSJT-X installation (i.e. >>usually c:\WSJT\wsjtx\bin). Rename the existing libhamlib-4.dll file >>beforehand so you can use it again later. >>3. Start WSJT-X (or the respective variant), connect your rig via >>hamlib (i.e. *not* via OmniRig, HRD, DXLabSuite, etc.) and check if >>the CAT control runs properly. >>4. If anything is not working properly, please contact Mike W9MDB via >>direct email, so he or his team can fix the bug in time. >>5. If everything works fine, keep the new libhamlib-4.dll file, >>otherwise delete it and rename the previously used one. >>6. In the future I would like to contact you before a new WSJT-X or >>wsjt-x_improved release to be able to choose a bug free hamlib version. >> >> In my opinion, at least the following rigs need to be tested regularly >> regarding hamlib: >> >>- Yaesu: FT-991, FT-101, FT-847 >>- Kenwood: which models? >>- Icom: IC-7300, IC-9100, IC-9700, IC-705 >>- Elecraft: KX3, what else? >>- FlexRadio: which models? >>- Anything else? >> >> *Now, the most important thing is that **one of you* * organizes it*. I >> can't do it myself because of time constraints, and Mike W9MDB is also >> overloaded with work. >> >> For example, what about the people who have stood out so intensively in >> the last few days with posts about something trivial? Wouldn't one of you >> like to take over and invest your energy there? *Seriously: Who?* *Y* >> *ou are now requested! * >> I mean, what needs to be done is evident: >> >>1. Create a list of commonly used rig models. >>2. Find beta testers for each of these models and assign >>responsibilities. >>3. Get an overview of the status quo and summarize the results >>clearly. >> >> Something like this can be done e.g. with a simple Excel file: >> >> >> >> >> It's sad enough that obviously, the hamlib development team can't do >> something so essential themselves. But *this definitely has to come now*, >> because we can't get the next frustration after every new WSJT-X release. >> Makes no sense! >> >> So, again: >> >> *Who of you will take this in hand and organize such a systematic beta >> testing? *I do not want to see one more "stupid" post as long as this >> problem is not solved, hi, hi! >> >> 73 de Uwe, DG2YCB >> ___ >> 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] Feature request down the road
I used FT4 over the RU weekend contest when RTTY dropped down and found it fun -- EXCEPT for one thing. It kept calling a station that was only calling CQ and very seldom answering any calls when Best S+P was activated. I had no way to ignore this station (and others) except to turn off Best S+P for a while. Could a feature like what JTAlert has, be added to temporarily ignore selected calls until a restart of the program. It would solve a lot of Best S+P attempts that are really unwanted? I find that JTA feature most useful to stop announcing over and over a wanted whatever that I'm not interested in at the moment. But that does not effect WSJTx and FT4 Best S+P operations. Along the same line, could a lower signal limit be added to keep Best S+P from calling a station that is -24 and probably is not hearing me at all? Also very helpful. Thanks for a great program. 73's George - WB5JJJ 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] TX Freq lockout
Interesting. I had only put in a Tx freq below 1000 to see if it was allowed and it stuck. But if I put in something under 200, as soon as I click outside the Tx box, it goes back to whatever was in there above 1000. Never did an Enable TX since it was not normal to do so. Just tried it and yes, it does shift up to something over 1000. I see, the range 200-1000 displays a bit differently than under 200. 73's George - WB5JJJ 4 On Mon, Nov 16, 2020 at 12:31 AM 5p1kzx Michael <5p1...@gmail.com> wrote: > Hi George > > It's already there. If you are in Hound Mode and try to call FOX under > 1000 wsjt-x will move the TX over 1000 by it self. If one get a rpt from > the DXP wsjt-x will automatic jump to one of the DXP TX Slots and give your > rpt for max 3 times if no RR73 is received wsjt-x will jump to somewhere > between 600-1000 and keep sending rpt until it get RR73 or TX-Watch Dog > will be triggered. > > JTDX is working a bit different. With JTDX in Hound or HoundFC Mode one > can still TX Even/Odd and whereever you want too. If only in Hound Mode > (not HoundFC) JTDX will keep the same TX-slot during the QSO. > > One can water the horse but not force it to drink > > 73 de Michael 5p1kzx > > > Den 16-11-2020 kl. 06:46 skrev WB5JJJ: > > This was meant for HOUND mode only. If they are not using HOUND, then > they should not be calling the DXP when he's operating in F/H mode. > Defeats the purpose of F/H and only confuses the issue. > > 73's > George - WB5JJJ > > > 4 > > > On Sun, Nov 15, 2020 at 11:32 PM Reino Talarmo > wrote: > >> Hi George, >> >> There is a minor problem with your lockout proposal as that operator may >> not have used HOUND mode at all! >> >> 73, Reino OH3mA >> >> >> >> *From:* WB5JJJ [mailto:wb5...@gmail.com] >> *Sent:* 16. marraskuuta 2020 0:45 >> *To:* WSJT software development >> *Subject:* [wsjt-devel] TX Freq lockout >> >> >> >> With the 7Q7 being the first major DXP since early in the year, there are >> a lot of "new" hams to F/H that don't read the information available. They >> are hoping to "cut in line" by TXing initially below 1000, and even on the >> DXP calling frequency, with their R-xx report. This causes tons of QRM and >> bad feelings toward these LID's. >> >> >> >> Can we get a Tx lockout to the selector, so entering anything below 1000 >> (similar to selecting 100) on the HOUND side of things will, at least stop >> this in its tracks and still allow the FOX to move the HOUND to 300-900 for >> the R-xx report? Also perhaps lockout Tx3 as well. These items would sure >> help educate those users very quickly on procedures for the mode. >> >> >> >> Just as a comical observation, the other day I watched a guy call and >> call with his R-xx report on the DXP calling frequency. I never saw him >> above 1000 calling with his grid square. Someone "became" the FOX (to me a >> +05 vs a -17) and gave him a signal report to get rid of him. Illegal, >> without a doubt, but it worked. I suspect that in the future, he will >> continue the same method since it "worked" once. Now he's looking for a >> QSL -- good luck on that one. >> >> >> >> 73's >> >> George - WB5JJJ >> >> >> >> >> >> 4 >> ___ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> > > > ___ > wsjt-devel mailing > listwsjt-devel@lists.sourceforge.nethttps://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
Re: [wsjt-devel] Wish-Dream: Button to toggle between Normal- & Hound-Mode
I would like to see when in the Hound mode, clicking on the red box would revert to normal FT8. I use configurations to do the switching between them and those are just 2 clicks away and no hunting for the proper place to click. Plus with the configurations for DXP, I have all the frequencies they tend to use and they don't clutter up my main FT8/FT4 frequency selectors. 73's George - WB5JJJ 4 On Mon, Nov 16, 2020 at 4:16 AM Dieter Dippel wrote: > Dear WSJT-X Developer-Team, > my main interest for 40 years plus is "DXing" in all modes. For FT8/FT4 > I'm using WSJT-X now for some years. > > Since FOX-/Hound-Mode became more and more favourite, one of my wishes > (dreams) is a Button on the Screen to toggle (switch) between > Normal-Mode and Hound-Mode. > > Maybe I don't know how improve it, but for me it's always very complex > (cumbersome) to move to > 1st => File > 2nd => Settings > 3rd => Advanced > 4th => Special Operating Activity > 5th => Hound-Mode > ... well, and the same procedure to switch back to "Normal-Mode" ... > > The Button could be placed on the same position as the ***RED*** White > *** Hound *** is located as soon as you are starting the Hound-Mode. > > If this doesen't make sense in your opinion, it would be great if you > can discuss about a ***Keyboard-Shortcut***to make it much more > comfortable ;-)) > > 73 es good luck to all of you de Dieter, DF4RD > > > > > > > > ___ > 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
Re: [wsjt-devel] TX Freq lockout
This was meant for HOUND mode only. If they are not using HOUND, then they should not be calling the DXP when he's operating in F/H mode. Defeats the purpose of F/H and only confuses the issue. 73's George - WB5JJJ 4 On Sun, Nov 15, 2020 at 11:32 PM Reino Talarmo wrote: > Hi George, > > There is a minor problem with your lockout proposal as that operator may > not have used HOUND mode at all! > > 73, Reino OH3mA > > > > *From:* WB5JJJ [mailto:wb5...@gmail.com] > *Sent:* 16. marraskuuta 2020 0:45 > *To:* WSJT software development > *Subject:* [wsjt-devel] TX Freq lockout > > > > With the 7Q7 being the first major DXP since early in the year, there are > a lot of "new" hams to F/H that don't read the information available. They > are hoping to "cut in line" by TXing initially below 1000, and even on the > DXP calling frequency, with their R-xx report. This causes tons of QRM and > bad feelings toward these LID's. > > > > Can we get a Tx lockout to the selector, so entering anything below 1000 > (similar to selecting 100) on the HOUND side of things will, at least stop > this in its tracks and still allow the FOX to move the HOUND to 300-900 for > the R-xx report? Also perhaps lockout Tx3 as well. These items would sure > help educate those users very quickly on procedures for the mode. > > > > Just as a comical observation, the other day I watched a guy call and call > with his R-xx report on the DXP calling frequency. I never saw him above > 1000 calling with his grid square. Someone "became" the FOX (to me a +05 > vs a -17) and gave him a signal report to get rid of him. Illegal, without > a doubt, but it worked. I suspect that in the future, he will continue the > same method since it "worked" once. Now he's looking for a QSL -- good > luck on that one. > > > > 73's > > George - WB5JJJ > > > > > > 4 > ___ > 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] TX Freq lockout
With the 7Q7 being the first major DXP since early in the year, there are a lot of "new" hams to F/H that don't read the information available. They are hoping to "cut in line" by TXing initially below 1000, and even on the DXP calling frequency, with their R-xx report. This causes tons of QRM and bad feelings toward these LID's. Can we get a Tx lockout to the selector, so entering anything below 1000 (similar to selecting 100) on the HOUND side of things will, at least stop this in its tracks and still allow the FOX to move the HOUND to 300-900 for the R-xx report? Also perhaps lockout Tx3 as well. These items would sure help educate those users very quickly on procedures for the mode. Just as a comical observation, the other day I watched a guy call and call with his R-xx report on the DXP calling frequency. I never saw him above 1000 calling with his grid square. Someone "became" the FOX (to me a +05 vs a -17) and gave him a signal report to get rid of him. Illegal, without a doubt, but it worked. I suspect that in the future, he will continue the same method since it "worked" once. Now he's looking for a QSL -- good luck on that one. 73's George - WB5JJJ 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Call 1st unchecked ignored
After unchecking Call 1st, it's sometimes still active for the first couple of CQ calls and populates everything and responds to an unwanted CQ. Eventually, it does as requested, but then after a slot change, it again answers even though unchecked. -- George - WB5JJJ 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Call 1st anomaly
I've noticed in rc1 that when i UNCHECK Call 1st it continues to connect to the 1st caller for a couple of CQ cycles and then ignores all incoming requests as expected. -- George - WB5JJJ 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Interesting new Band Activity operation
Just installed v2.2.0 rc1 and found that the Band Activity window has a "new normal" that I find awkward. After the first decode period at 11.8s, the window works exactly as before, but at the conconsulsion of ALL decodes at ~15s, it resets the display to show only those last decoded. You must scroll up to see the original (larger) list of decodes. Temporary solution under Settings is to uncheck "Start new period decodes at top". Now you have a continuous flow of decodes (old way). I really enjoyed the start new decodes with the overflow off the bottom of the BA window, a much smaller list typically. I have part of the monitor display real estate taken up by JTAlert with just 3 lines of decodes, docked above WSJTx. -- George - WB5JJJ 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Clicking on Fox call
I've been caught many times when I click on the Fox call in the line such as: X0XXX RR73; Y0XXX -10, where it populates the DX Call of RR73 and Generates Std Msgs for RR73 as well. Before I catch it, I'm off to the pileup transmitting RR73 WB5JJJ EM35. Embarrassing moment at the worst. Habits are so hard to break. Can this be corrected to properly populate information with the Fox's call sign? Everything else seems to work properly. Very smooth operations. -- George - WB5JJJ 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] v2.1.1 64bit monitor placement problem
I just installed the v2.1.1 64b version to test the monitor placement memory across 3 monitors. It still does not work. The main window is off to the right of my right most monitor and the WF is on the main monitor. After repositioning and resizing on the middle and left monitor, all is good till I shut down and restart the program when everything returns to the previously described placements. Nothing was remembered at all. Uninstalled all mentions of WSJTx and rebooted. Installed v2.1.1 64 bit and same as above. Installed 32b version over 64b and all sizes were wrong. Restored to the screens to the proper monitors / sizes and then shutdown and restarted the program and all was again good. This has been an ongoing problem for me since the 64 bit was introduced. The 64b just does not write to the ini file the window placements. -- George - WB5JJJ 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] /150 Compound Calls
Don: We have tested CQ HPM callsign gridsq and it seems to work as a "directed call". Maybe this will be adopted once folks figure out /150 won't work in FT8/FT4. On Wed, Aug 28, 2019 at 1:09 PM Don AA5AU wrote: > In anticipation of seeing callsigns with /150 added for the ARRL sponsored > Hiram Percy Maxim Birthday Celebration, how will this affect FT4 & FT8 > operations and especially the upcoming WW Digi Contest? > > I see this in the WSJT-X online help file "Compound callsigns like > xx/K1ABC or K1ABC/x and special event callsigns like YW18FIFA are supported > for normal QSOs but not for contest-style messages." > > I don't see where we recommended not using non-standard in WW-DIGI. > > Thanks, > Don AA5AU > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George - WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJTx jumping to EU mode and others - Suggestion
I have seen the top screen with everything turned on, and there is so little space to ADD anything else to it. Each spot is used by one mode or another, but of course, not all at the same time, so it looks like wasted space. Agreed, the time box and others could be reduced somewhat to give a few extra pixels to work with. But overall, its a city block full of urban development, either in use or future planning. So here's a shot in the dark to consider. For instance, if you are in HOUND mode and the red box is at the bottom center of the screen, maybe you could just click this box and the HOUND mode would be immediately turned off. Similar on the EU mode and others that might pop up or you forget to disable them in your haste to work the rare DX on normal mode. Of course, you would have to drill down in the menus to reactivate them, but it would not take any more screen real estate to enable the box to be clicked to quickly return to normal operation for the mode you are using. Just a thought. I'm sure there is probably a "no way" reason for this not to be considered with the underlying code, but still asking (for a friend - hihi). George - WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Decode issue in Hound mode
I've seen discussions on this issue, but I had never experienced it until last night. So I thought I would add to the thread my experience last night in case something new might be brought to light in my observations. Last night a friend and I were on the phone and 160m chashing TO5M in F/H mode. For a couple of hours he was in and out and everything was fine. But after a while, my waterfall just went blank and nothing was being decoded. About the same time my friend experienced the same thing. We both restarted WSTJx to no avail. I use a Configuration setup and he just manually selects Hound mode. Still nothing. I used my Configuration and went to normal FT8 and was now seeing WF activity and decodes again. Switching back to the DXP Configuration, the WF was again blank. Back to the normal Configuration, everything was working, so I turned on Hound mode there and decoding was just fine. I went to my DXP Configuration, the WF again went blank and decodes stopped. I ended up going back to the Normal Configuration and selecting Hound and all was good for the rest of the unsuccessful session. BTW, neither one of us worked the TO5M last night. But we did spend about 3 hours on the phone solving all the worlds problems. That is, until his wife called him to bed. So ended a great QSO. George - WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Tx1 Anomaly
I'm sure you will figure it out. We all have faith in your efforts as always. On Sat, Jul 20, 2019 at 5:55 PM Bill Somerville wrote: > Hi George, > > thanks for that. It seems we have a logic error somewhere when exiting NA > VHF Contest mode. I'll see if I can track down the issue. > > 73 > Bill > G4WJS. > > On 20/07/2019 23:39, WB5JJJ wrote: > > Tried that, no joy, that just grays out the dialog box and restores as > always. It's jjst the Tx1 button itself stays grayed out and disabled to > clicks. So far, only a restart will enable it. > > On Sat, Jul 20, 2019 at 5:34 PM Bill Somerville > wrote: > >> On 20/07/2019 23:02, WB5JJJ wrote: >> >> Was working the NA VHF Contest mode just now and when I returned to >> normal FT8, the Tx1 button was grayed out. Had to use the Next button to >> make a call. Shutting down WSTJx and restarting cleared the problem. >> >> Running v2.1.0 32bit version >> Win 10 Pro 8Gb i5 processor >> >> George - WB5JJJ >> >> Hi George, >> >> double-clicking the Tx1 button or the button in the "Next" column to its >> left will toggle the inclusion of Tx1 messages in auto sequencing. >> >> 73 >> Bill >> G4WJS. >> > > ___ > 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
Re: [wsjt-devel] Tx1 Anomaly
Tried that, no joy, that just grays out the dialog box and restores as always. It's jjst the Tx1 button itself stays grayed out and disabled to clicks. So far, only a restart will enable it. On Sat, Jul 20, 2019 at 5:34 PM Bill Somerville wrote: > On 20/07/2019 23:02, WB5JJJ wrote: > > Was working the NA VHF Contest mode just now and when I returned to normal > FT8, the Tx1 button was grayed out. Had to use the Next button to make a > call. Shutting down WSTJx and restarting cleared the problem. > > Running v2.1.0 32bit version > Win 10 Pro 8Gb i5 processor > > George - WB5JJJ > > Hi George, > > double-clicking the Tx1 button or the button in the "Next" column to its > left will toggle the inclusion of Tx1 messages in auto sequencing. > > 73 > Bill > G4WJS. > ___ > 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] Tx1 Anomaly
Was working the NA VHF Contest mode just now and when I returned to normal FT8, the Tx1 button was grayed out. Had to use the Next button to make a call. Shutting down WSTJx and restarting cleared the problem. Running v2.1.0 32bit version Win 10 Pro 8Gb i5 processor George - WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] v2.1.0 GA 64 bit problems
I uninstalled all previous versions of WSTJx, OpenSSL 32bit and deleted the "extra" folders I created when running the rc's and rebooted the computer before installing the 64bit version and found the following: 1) on EVERY start the screen locations on monitor #2 and #3 are NOT remembered. It always wants to start everything on Monitor #1 instead. I moved, resized the screens, shut WSJTx down and restarted the program. Again all screens were the wrong size, wrong place and even the main screen was off the side of my main #1 monitor. 2) found that the Win32OpenSSL_Light-1_1_1c.exe was still required even with the 64bit WSJTx install. 3) the frequency selector drop down always shows up for an instant on the #1 screen before relocating to the #2 screen where the main program is located, and the frequency information is still truncated. I uninstalled the 64bit version, rebooted the computer and installed the 32bit version and it remembered my program locations on screen #2 and #3 as always. Went back to the start and reinstalled 64bit version and again the locations were no longer remember. Other than these problems, the 64bit seems to work very nicely. WB5JJJ - George ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Anomaly with rc7
I was running rc7 in normal mode FT8 during FD since it did not shut down as expected. After I completed a contact and then started calling CQ, with Call 1st UNCHECKED, about every 3rd or 4th CQ call, a connection was made to one of those calling me and the contact ensued without me selecting anything. The rest of the time, my side did nothing on it's own. I had Call 1st unchecked since I was a 1D and did not really want to be contacted by another D station for no points. This way I could select the other classes that needed me for points, or so I thought. Just a heads up to the team to check this out. Also, on occasion I noticed that when my report from the other station was -11, the Log QSO showed +11 instead. This happened occasionally with other negative reports as well, but seemed to be more frequent with -11 than the others. George - WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Time sync and other FT8 comments after FD 2019
First off, I much prefer SSB phone to FT8, but with the current band conditions, I find FT8 a great stop gap measure and certainly glad it's available, otherwise my rigs would be collecting dust and cat fur. FT8 will probably be a cyclic operational mode as band conditions improve, but it's big draw is to the new ham just getting into the black hole spending of the Amateur Radio hobby. As for time sync, overall, I saw very few stations that were over 1.0s out of sync. A couple drifted wildly from 1.0s to 2.4s (or more), but that was all. 99% of the stations I copied were closer to 0.5s or less, so folks overall seem to be getting the message on time syncing. But some of the most frequent offenders I saw, were probably the actual in-the-field FD operations, as to be expected, but easily this is easily corrected. But as long as they could score a contact, that was all that mattered. However for those that don't have a good time sync, a bright red DT column, of numbers, should give them a clue that something just might be wrong on their side. JTAlert already does this, but many don't use it and it takes a few seconds to display as it's appropriately a lower priority item. And for FD ops, it's just another piece in the hodge-podge of programs needed to run to make sure everything is scored properly, and that most consider as unnecessary. One problem I did have frequently was with "Call 1st" UNCHECKED, I was still getting connected to one of the stations in the queue of calls responding to my normal CQ call. This happened more times than I could count and it should not have happened at all. It would typically happen right after a completed contact and on the next CQ call. Most of the time it was OK, but occasionally it was another "1D" station. I had to halt the transmission and clear the information before starting to call CQ again. Another situation I had was with other "xD" stations calling me. As a "1D" myself, it was slightly annoying for me. If course my CQ does not give anybody a clue as to my class, so they respond. Many don't even know the "D to D" points rule anyway. Fortunately, I usually had other stations calling at the same time that were not a "D" to choose from. One guy that I ignored time after time sent "QSO IS A QSO", which is true if you just want a QSO. He can call me ANYTIME I'm not involved in an event and I'll gladly work him. However, it would be really informative to everyone involved if the grid square was replaced with the ARRL Class such as "1E WPA" or in my case "1D AR" for FD operations. I know it's too long and has a space, but something might be done to communicate this sort of information during a CQ call. Maybe "1DAR", "1EPA" or "3ADX" would work out since the grid info is not shown the the Log QSO window anyway. Just a thought. WB5JJJ - George ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Field Day time problem
The latest JTAlert has this feature. You can set several DT error time limits to be highlighted in red in the WSJTx Band Activity window of the drifting station's DT. If a station sees lots of red in the DT column, hopefully they would take notice and figure out they are out of sync. WB5JJJ - George On Sun, Jun 23, 2019 at 2:09 PM Gary Hinson wrote: > Instead of “Your clock is off” (which, to some, may mean “Your clock is > turned off”) I suggest “Your clock is wrong” or better still the > action-oriented “Check your clock”. > > > > And the proposed 3 out of 5 decodes being more than half a second wrong > risks triggering the message far too often when the band is busy, > especially during events such as field day and DXpeditions when a greater > proportion of ops are probably using temporary setups without atomic clock > references. I think a statistical test would be more appropriate, although > I’m not sure which one (ask a statistician!). > > > > Another approach would be simply to highlight DT values that are more > than, say, 1 second wrong in the decode panes (e.g. with red or orange > backgrounds for minus and plus DT values), and leave the ops to notice the > slew of reds or oranges and figure out what’s going on. This has the > advantage that, if we are reasonably sure of our own clocks, we might > notice and maybe send a message to other stations whose DT values are > highlighted. > > > > 73 > > Gary ZL2iFB > > > > *From:* Black Michael via wsjt-devel > *Sent:* 24 June 2019 00:27 > *To:* WSJT Software Development > *Cc:* Black Michael > *Subject:* [wsjt-devel] Field Day time problem > > > > I've seen about 2 dozen clubs doing Field Day where their clocks are off. > > > > We need to provide an indication in WSJT-X when clocks are off like this. > > > > With concurrence I can do a patch for thismy idea is this. > > > > At least 5 decodes where 60% or more > 0.5 seconds is an indication of bad > timing. > > A message would be put in the Rx Frequency window "Your clock is off...see > help". With appropriate references in the Help to search "your clock is > off" and time solutions. > > > > This doesn't cover the case where their clock is way off as they won't see > any decodes. The only solution for that would be doing a time query from a > known source and I don't think we want to go that route. > > > > de Mike W9MDB > > > > > ___ > 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] rc7 and Call 1st - Yes, it's still active
Field Day Configuration. Still checking out rc7 since it hasn't locked out so far. So why not run with it? For some reason in FT8 and calling CQ, even though Call 1st is UNCHECKED, about every other sequence an automatic response will be generated to a random station calling me. Sometimes this is OK, but since I'm working as 1D another "D" station is not valid for points. As it stands, I hover over the ESC key constantly to cancel a "D" contact from completing. George - WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Initial thoughts on FT8 and FD
I’ve noticed that rc7 32b is still fully functional after several restarts to check, even in FT4. Oops. Of course it may stop at any time. Also had to turn Call 1st off (operating 1D) because of all the “D”’s calling me. My CQ does not indicate my class so everybody is clueless unless they also watch the left window all the time. Perhaps drop the grid in FD mode and put in the Class letter. Even better, don’t allow a “D” to auto connect to another "D" calling CQ when Call 1st is active. That would speed thing up for sure. I'm sure bullets are now flying my way to punch holes in my suggestion, but I'll duck out of the way as best I can and just go with the flow. WB5JJJ - George ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Request: Please widen frequency menu
Good to hear. Will wait for the 64b GA and see how it shakes out with screen size and locations. George - WB5JJJ On Wed, Jun 12, 2019 at 12:36 PM Joe Taylor wrote: > On 6/12/2019 12:22 PM, WB5JJJ wrote: > > Mine is the 32-bit. I tried the 64 bit but it always came up with no > > window sizes remember and sometimes even come up on wrong screen/size or > > even completely off the screen so I went back to 32b. > > This is true ONLY if you switch back and forth between win32 and win64 > builds. If you stick with one version it will remember window positions > and sizes. > > -- 73, Joe, K1JT > > > ___ > 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
Re: [wsjt-devel] RC7 - STOPPED FUNCTIONING.
This version (according to the opening splash screen) is also timed, but it waited until 1800 UCT and the contest start. I was running rc7 for about 5 or 6 hours today and even into the contest. All was good till I decided to shut it down and restart rc7. As EXPECTED, it died per notice. Went to v2.0.1 and kept going. It will be back on Sunday (8th after 0300 UTC) until Field Day weekend when it will die again. Final death blow for rc7 is 21 July. But a new rc will be out by then. Read and head. 73's George - WB5JJJ On Sat, Jun 8, 2019 at 5:59 PM ZL3GAV wrote: > Hello > > > > Software rc-7 closes down when you click OK on the splash screen. Tried > reinstalling, no success. Release version works correctly. > > > > I am running Windows 10 Pro 64 ver 1903, on Dell Inspiron i7. > > > > The earlier release candidate was time-bombed for 8 June. It happens to be > 9 June in New Zealand, coincidence? > > > > 73 > > > > > > Gavin > > *ZL3GAV* > > > > *visit my website *https://ZL3GAV.com <https://zl3gav.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] rc7 64b multi monitor problem
I have a 3 monitor setup and all the 32bit versions have always remembered WSJTx window positions once set from start to start as well as all configuration and version changes. Just loaded the 64bit version. It always starts up with the windows off the right edge of the right monitor. I have to drag everything back to the left and center monitors. Sizes are remembered but the locations are NOT remembered once set. LEFT #3 monitor - HRD Rig Control and WSJTx Waterfall half size on top (focus) CENTER #2 monitor - Main WSJTx window with JTAlert and Macros side bar RIGHT #1 (default) monitor - HRD LogBook and everything else I might use System setup: Windows 10 Pro 1809 64bit 8Gb RAM Dell 1708FP 1280x1024 ATI Radeon HD 2400 XT Dual monitor card - stretch across RIGHT and CENTER displays NVIDIA GeForce GT 710 signal monitor card - LEFT monitor WB5JJJ - George ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Cannot download RC6
It had multiple bugs and was removed for fixing. On Mon, Jun 3, 2019 at 12:47 AM Tom Ramberg via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > Clicking on the download link for RC5 produces this reactio (Similar for > both 32- and 64-bits versions): > Not Found > > The requested URL /pulsar/K1JT/wsjtx-2.1.0-rc6-win64.exe was not found on > this server. > -- > Apache/2.2.15 (Scientific Linux) Server at physics.princeton.edu Port 80 > > ___ > 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
Re: [wsjt-devel] Proposed FT8 Frequencies for ARRL Field Day
As previously stated the unique format for exchanges of FD messages would cause extreme frustration for those that don't know what's going on. Thus the migration to other frequencies is a very logical decision which should be supported by both sides. As Gary said, there is a large group that could care less about FD ops. Just listen to them on the voice segments. At least in voice, you have the option to quickly give the proper response and move on. This is not so easy, on purpose, with FT8 and future FT4 ops. I have created a CONFIGURATION that is for "other" uses such as DXPeditions and rare DX. I have all of those special frequencies in these configurations. With a couple of mouse clicks, I can get in or out of any configuration and some even come up in F/H mode automatically. When done, the same procedure returns me to normal FT8. WB5JJJ - George On Thu, May 30, 2019 at 8:16 PM Gary wrote: > Let’s not, please. Not everyone wants to participate in Field Day. The > suggested frequencies that Tim provided look good to me. > > > > 73 de Gary – W9BS > > > > *From:* Matthew Miller [mailto:mmill...@mail.umw.edu] > *Sent:* Thursday, May 30, 2019 8:48 PM > *To:* 'WSJT software development' > *Subject:* Re: [wsjt-devel] Proposed FT8 Frequencies for ARRL Field Day > > > > Why not just use the normal expected FT8 frequencies for FT8? > > > > -Matt/KK4NDE > > > > *From:* Tim Goeppinger via wsjt-devel [mailto: > wsjt-devel@lists.sourceforge.net] > *Sent:* Thursday, May 30, 2019 2:17 PM > *To:* wsjt-devel@lists.sourceforge.net > *Cc:* Tim Goeppinger > *Subject:* [wsjt-devel] Proposed FT8 Frequencies for ARRL Field Day > > > > I would like to finalize my list of Field Day frequencies, before I > publish them in the "FT8 For Field Day" > > group on Facebook, and elsewhere. 7080 seemed good during our first > practice. These freqs were selected based on the fact that RTTY usage in > FD is almost non-existent. Any major problems with these? > > > > 1840 > 3580 > 7080 > 14080 > 21080 > 28080 > 50318 > 144174 > > > > Tim N6GP > ___ > 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] Suggested keyboard shortcut
I find myself wanting to turn on/off the "Start new period decodes at top" depending on the Band Activity traffic at the time. Sometimes there is only one or two decodes, so a full history is beneficial. While at other times a band is so busy that this feature is a necessity. Still the list sometimes overflows the almost full screen view it my WSJTx BA window. I would like to see a keyboard shortcut to check/uncheck this box on the fly. I know, it's only a couple mouse clicks away, but this might be a very convenient shortcut to add. George - WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Serialization of Delta Time in Decode Message Type
If enough users start "nudging" their time one way or the other, the whole reason for external time sync is defeated. It will chasing your tail from the get go. Just sync periodically and forget those that don't/can't. It's not worth the problems it will cause to the normal users that do it right. On Tue, May 14, 2019 at 4:42 PM Derek Turner via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > I was thinking about adding a feature to my FT8/4 Assistant program to > display in a histogram the delta times from the last minute's worth of > decodes and maybe eventually to enable the user to nudge the PC clock > backwards or forwards by a few milliseconds. > > This may or may not be a good idea but my problem is that so far I have > not been able to convert the UDP decode message time offset back to > anything resembling the DT column in the WSJT-X Band Activity window and I > would very much appreciate some help. > > In the specification the Delta Time is described as a float serialised as > a Double. When I examine the eight bytes following the SNR bytes I see a > consistent correlation between the Band Activity DT and the pattern of > bytes. > > So I know I am looking in the right place, which is the eight bytes > starting at (zero base) byte 32 . Here is a screen shot from an Excel > worksheet where I compare samples of the Band Activity DT with their Decode > byte array bytes:- > > [image: Inline image] > > I have several issues here that I do not understand :- > > 1. The pattern of bytes for negative and positive Delta Times are > identical so the sign is lost. > 2. Between SNR and Delta Frequency there are nine bytes, not the eight I > expected for a Double. Byte 40 appears to be surplus. > 3. DT 0 is suspiciously all zeros when DT 0.1 seems to be a very large > number. > 4. Bytes 33 and 34 are identical. > > Please can somebody make sense of this for me. > > 73 de G4SWY Derek +++ > > > > > ___ > 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
Re: [wsjt-devel] Expiration Date on Software
If the program on startup finds a valid Internet connection, then check for an update automatically. If one is available, download it, or at least supply a link to the file, and THEN allow the user to install (or delete) it as they feel. Make it keep bugging the user on startup of WSJTx until the update is done. Most software I use has this kind of feature. If the Internet is not available, allow the software to run as always, but put up a warning that suggests the user check the website for an update. This notice could happen on a weekly or even monthly schedule, or until the Internet is restored. Or they could then use another computer with Internet access, to download the software and install it on the one without Internet. As was found with v1.9.1 expiring, many users downloaded it way back or maybe had someone else install it for them and don't have a clue where to check for updates. An update link in the About box would be very helpful for those that forget where it came from. WB5JJJ - George On Fri, May 10, 2019 at 6:59 AM Onno Benschop wrote: > Backwards compatibility is a thing ... > > Also, if the new version of the software knows how to decode an older > encoding, you already have an implied version number. > > It's not like this takes eons to decode, nothing wrong with trying several > times, newest version first, next version next and so on. > -- > finger painting on glass is an inexact art - apologies for any errors in > this scra^Hibble > > ()/)/)() ..ASCII for Onno.. > > On Fri., 10 May 2019, 16:11 Reino Talarmo, > wrote: > >> Hi Onno, >> >> >A better idea is to include a protocol version number in the QSO >> information, that way both sides have a chance to alert the operator. >> >> >> >> A nice idea, but that information needs to be sent using the lower layer >> of the previous protocol version…. >> >> 73, Reino, oh3ma >> ___ >> 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] FT4 mock contest
For me it was pretty much a less than expected experience. I started out on the suggested frequency and when it got so crowded and I had very little success, I moved up 2 as suggested. Clearer but no better. I believe I followed the instructions to the letter and was expecting much better results. I gave up after about 20 minutes with just 5 contacts completed. I watched several very strong stations to my location call CQ for many, many cycles with folks trying to work them, myself included without success. It was like they had their receivers off. Their times were well below the 0.5 limits. Once in a while, they would make a connection. Don't know if they were clueless about the operation or conditions just that one-way. Several times after calling one of these CQing stations for several cycles, I gave up and tried another one with much the same results. They just kept calling CQ. I was not the only one calling them and in several instances, I did copy others trying as well on all different offsets, but they didn't respond to any. To test things out, I dropped down to the normal FT4 40m frequency and was able to immediately work several contacts as expected. Don't know what the difference was, but there was something. WB5JJJ - George ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] S+P operation
Trying new features with FT4 and noticed that when S+P is active during non-CQ (receive only) operation, it will pounce on stations using directed calls such as CQ DX WB5JJJ EM35. In a contest situation, which FT4 is designed for, this would be fine since there will not be any directed CQ's typically. So, should this option not be shown on the main UI unless a contest is selected since it can cause frustration to some operators that don't want to be bothered by local stations pouncing on their directed CQ? Judging from some comments, it appears that FT4 may be the new norm for those seeking their first WAS, DXCC and not just contests. WB5JJJ - George ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Logging button placement
My vote is with Steve on restoring consistent button positions as well, even though I can easily read and locate the OK button. It does take extra time plus "muscle memory" is of no value in this, especially with the 6 second turn around now. Streamlining the process should be paramount. My reasoning: In the early days of WSJTx, there was no integration with HRD LB for logging of FT8, MSK144 or whatever mode contacts. I solved this with an auto-bot program where a double mouse click on a shortcut would start the automatic process to find the WSJTx log adi file and import it into HRD LB in a matter of seconds with no further interaction on my part. It worked great since there was not any other option except doing it manually every time. The way I set up the program was using XY positions, which worked. But as WSJTx evolved, I periodically had to make subtle changes to these locations. I took the easy road, even though the program would look for changes in color text or background and even text itself. Of course all of that is now in the past as both WSJTx and JTAlert take care of logging to HRD LB instantly. The program has long since been abandoned. So, the randomness of the OK and CANCEL are a moot point as I'm sure the auto-bot technology is even better today than several years ago. Putting the burden on the masses to attempt to defeat those few that try to automate the process is virtually impossible. WB5JJJ - George ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bugies in 2.1.0
My vote is with Steve on restoring consistent button positions as well, even though I can easily read and locate the OK button. It does take extra time and "muscle memory" is of no value in this, especially with the 6 second turn around now. Streamlining the process should be paramount. My reasoning: In the early days of WSJTx, there was no integration with HRD LB for logging of FT8, MSK144 or whatever mode contacts. I solved this with an auto-bot program where a double mouse click on a shortcut would start the automatic process to find the WSJTx log adi file and import it into HRD LB in a matter of seconds with no further interaction on my part. It worked great since there was not any other option except doing it manually every time. The way I set up the program was using XY positions, which worked. But as WSJTx evolved, I periodically had to make subtle changes to these locations. I took the easy road, even though the program would look for changes in color text or background and even text itself. Of course all of that is now in the past as both WSJTx and JTAlert take care of logging to HRD LB instantly. The program has long since been abandoned. So, the randomness of the OK and CANCEL are a moot point as I'm sure the auto-bot technology is even better today than several years ago. Putting the burden on the masses to attempt to defeat those few that try to automate the process is virtually impossible. WB5JJJ - George On Tue, Apr 30, 2019 at 9:15 AM Steve Huston wrote: > On Tue, Apr 30, 2019 at 3:01 AM Christoph Berg wrote: > > Re: Bill Somerville 2019-04-29 < > af407b47-deae-ab9a-bf8e-5d638b1bf...@classdesign.com> > > > not disagreeing but there are reasons for this that I can't reveal. > Let's > > > just say it is to deter LIDs. Sorry. > > If the idea is to make people think before logging, I'd say this > > feature will merely induce stress that makes them focus on the > > buttons, and even less on the actual log. > > If the idea is to defeat automated operation, there are lots of tools > > that can identify and click buttons in GUI applications. > > https://stackoverflow.com/questions/4129430/qt-automated-testing > > Please don't put that burden on everyone. Or at least be open and > > reveal the reasoning. > > No, simply don't put this burden on people. UIs are a standard for a > reason. This will not deter automation at all, it will simply make > the people doing the automation either use smarter automation tools > instead of "click this many pixels in from the right and this many > pixels up from the bottom" to "click the button labeled 'OK', 'Ok', > 'ok', 'Enter', 'Log', etc" > > What this will do, and already has done based on some of the emails > I've read here, is cause people to click the wrong button because it > was literally there 45 seconds ago and miss logging a contact. Or > they will look into the code, find the part that does this, and remove > or disable it. > > I realize it may not be up for a vote, but I vote an extremely strong > no on this one. > > -- > > Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci > Princeton University |ICBM Address: 40.346344 -74.652242 > 345 Lewis Library |"On my ship, the Rocinante, wheeling through > Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, > (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' > > > ___ > 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
Re: [wsjt-devel] Bugies in 2.1.0
I agree. I've hit CANCEL a couple of times instead of OK. Habit, Habit, Habit. George On Mon, Apr 29, 2019 at 4:29 PM Christoph Berg wrote: > Re: Bill Somerville 2019-04-29 < > ddfd6e65-ec40-be34-c364-f44e43ca9...@classdesign.com> > > > Manual log qso, has Ok and Cancel buttons at least 4 different > positions > > > within different qsos > > This is intentional. Is it causing you insurmountable problems? > > Very annoying. There are styleguides that suggest putting the OK and > cancel buttons in certain places when using a toolkit so each app > behaves the same. Please follow them. > > https://doc.qt.io/archives/qq/qq19-buttons.html > > Christoph > > > ___ > 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
Re: [wsjt-devel] End of life for rc5 could create a problem
Oh crap, I was so hoping it would all be over. Life goes on. Thanks again. So far all is pretty good and stable. George On Mon, Apr 29, 2019 at 4:15 PM Bill Somerville wrote: > On 29/04/2019 22:02, WB5JJJ wrote: > > For those that run rc5 till it expires and then try to run v2.0.1 instead > of updating to rc6 (or whatever), there needs to be a means to reset the > FT4 token in the registry when the program dies on startup or you won't be > able to run previous GA's unless you install a new rc first and change the > mode within the program. > > Food for thought for the developers. > > WB5JJJ - George > > George, > > nothing is stored in the Windows registry by WSJT-X. The inability to > start the 2.0.1 version when FT4 mode has been selected in v2.1.0 is a > defect that will be fixed in a bug fix release of v2.0.1 before the > expiration date of v2.1.0 RC5. Also it is trivial to change the selected > mode in the settings file so the World will not end after all. > > 73 > Bill > G4WJS. > ___ > 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] End of life for rc5 could create a problem
For those that run rc5 till it expires and then try to run v2.0.1 instead of updating to rc6 (or whatever), there needs to be a means to reset the FT4 token in the registry when the program dies on startup or you won't be able to run previous GA's unless you install a new rc first and change the mode within the program. Food for thought for the developers. WB5JJJ - George ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] v2.0.1 now crashes
Thanks Bill. I created an "FT4 Test" configuration in rc5 with all the parameters as suggested. When I switched configurations in rc5 from "FT4 Test" to "Normal FT8" and closed rc5, then restarted v2.0.1 all is now just fine and it's been running a few of minutes. Something to remember till v2.1.0 GA. Otherwise, both versions seem to function normally now. George On Mon, Apr 29, 2019 at 3:05 PM Bill Somerville wrote: > On 29/04/2019 20:56, WB5JJJ wrote: > > I installed v2.1.0 rc5 in a separate directory as I've done with the rc's > before and it runs just fine. HOWEVER, if I exit rc5 and restart v2.0.1, > it CRASHES within 5 seconds. > > I uninstalled all instances of WSTJx and rebooted my machine. Reinstalled > v2.0.1 and it still crashes after a few seconds. Something is just not > right with the rc5 install that appears to have corrupted the other > installs. > > WB5JJJ - George > > Hi George, > > try starting the v2.1.0 version and setting the mode to something other > than FT4 before returning to an older version. > > 73 > Bill > G4WJS. > ___ > 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] v2.0.1 now crashes
I installed v2.1.0 rc5 in a separate directory as I've done with the rc's before and it runs just fine. HOWEVER, if I exit rc5 and restart v2.0.1, it CRASHES within 5 seconds. I uninstalled all instances of WSTJx and rebooted my machine. Reinstalled v2.0.1 and it still crashes after a few seconds. Something is just not right with the rc5 install that appears to have corrupted the other installs. WB5JJJ - George ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Suggestion for Additional Checkbox
F/H is not something you would normally select on a frequent basis, so a check box cluttering the main screen is not necessary. As previously suggested setting a Configuration for that mode (and others) are just 2 clicks away and totally customizable. This procedure is outlined in the User Manual. It's simple and effective. WB5JJJ - George On Sat, Apr 20, 2019 at 7:44 PM Frank Kirschner wrote: > Good idea. I'm not familiar enough with the program to have thought of > that. Thanks. > > 73, > Frank > KF6E > > On Sat, Apr 20, 2019 at 6:16 PM N3SL wrote: > >> Just a suggestion - works for me: Create a F/H "configuration" and >> toggle to it. Two mouse clicks. >> >> On Sat, Apr 20, 2019 at 4:50 PM Frank Kirschner < >> frank.kirsch...@gmail.com> wrote: >> >>> Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is >>> room for several more checkboxes. One I would suggest is Fox/Hound mode. I >>> would also suggest this automatically set Split to either Rig or Fake It, >>> which could be selected somewhere else. >>> >>> If the menus are turned off, it takes a while to turn them on and >>> navigate to the correct spot to set fox/hound and split mode. This >>> sometimes is long enough to miss a weak one. A checkbox would not only make >>> it faster, but it would encourage using that mode for those who are still >>> learning FT8 operation. >>> >>> 73, >>> Frank >>> KF6E >>> ___ >>> 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] People are rude - sometimes uninformed
The other day, I was trying to work the Z81D on 20m FT8. After calling till I was blue in the face, he finally responded to me. I got his report, but I never heard from him again because a +14 signal from the East Coast started calling him on the DX stations frequency and on the DX stations time slot. He must have called for 10 minutes before his Watchdog Timer timed out. Then was back at it again. I was so mad, I just went back to SSB to cool off and had a couple of nice QSO's there. Later I saw this fellow join one of the FT8 groups and ask for instruction on how to operate FT8. Said he was a 30 year ham and just got into the digital world. The majority of responses were to RTFM, as expected. Whatever happened to STOP, LOOK and LISTEN before leaping into something new? BTW, I did log the contact just in case, since it was an ATNO for me on any band/mode. Maybe the DX did the same. WB5JJJ - George ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X RX Window not in chronological order
I concur as this has been an ongoing issue for some time. They RX window is not properly sorted which can lead to confusion. On Tue, Feb 26, 2019 at 12:45 PM Bill wrote: > Thanks for the response Frank. I guess its possible that I never noticed > it but I sure can't remember seeing it before. I have almost 10K FT8 QSOs > and today is the first time that has jumped out at me. I always focus on > that the last line of the RX window. The really weird thing is that the > ALL.TXT file reflects the correct information (as far as I can tell) but > its different than what is displayed real time in the RX window. > > I'm using the Mac version on a relatively fast computer. > > Oh well > > Bill - AK6A > > On Tue, Feb 26, 2019 at 10:32 AM Frank Kirschner < > frank.kirsch...@gmail.com> wrote: > >> I think you just noticed it. I've been seeing that since version 1.9. I >> use Windows 7. I never thought much about it, looking at several lines to >> figure out which one was the last one sent. >> >> 73, >> >> Frank >> >> KF6E >> >> On Tue, Feb 26, 2019, 13:18 Bill wrote: >> >>> I recently upgraded to version 2.0.1 and noticed an issue I haven't seen >>> before. It appears that the entries in the RX window are not always in >>> chronological order with the intermixed TX lines. I've been in the habit of >>> always looking at the last line of the RX display to see what I am >>> transmitting out and who I am answering, especially when multiple people >>> are calling me. Now it appears that I am seeing RX decodes showing up after >>> my TX line is displayed. This threw me off thinking my transmit wasn't >>> enabled and I was still decoding but that wasn't the case. >>> >>> During my troubleshooting I looked at the information in the ALL.txt >>> file to try to see what was happening and discovered the timestamps inside >>> the ALL.TXT file were different from the times shown in the RX window. >>> ALL.TXT times appear to be correct but the RX window did not correlate with >>> the times recorded there. Do the displayed records "round up" the time? >>> >>> I am not sure what files can be attached to these posts so if this >>> problem is of interest to the developers I can provide a copy of my ALL.TXT >>> file and screen shoots showing the RX display issue. >>> >>> I've been using all versions and RCs of WSJT-X for ever the past year >>> and never noticed this before. >>> >>> Bill - AK6A >>> >>> ___ >>> 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 mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.0.1 display problem
I also noticed the blank BA display. Seems to have happened about an hour after no activity on my part. But the missing entries are above the display. Just scroll up and they are there. Erase did solve the problem as I already gave that a try. Otherwise, I love the period display. Cleans up the BA window a bunch. George - WB5JJJ On Tue, Feb 26, 2019 at 8:15 AM Bill Somerville wrote: > On 26/02/2019 07:56, Karza wrote: > > Hello developers, > > > > I found a problem with the "Start new period decodes from top" feature: > > > > After some time ( a couple of hours or so ) new decodes are not > > shown in the "Band Activity" pane any more. > > > > WSJT-X still decodes OK, and new decodes are recorded to ALL.TXT. > > ( Actually, new decodes are also written to Band Activity but they > > can only be seen by scrolling the pane upwards. ) > > > > Erasing Band Activity restores normal operation again ( for some time ). > > > > Running WSJT-X 2.0.1 ( complided from sources ) on XUbuntu 18.04.1 LTS > > > > 73 de Kari ohgqc > > > Hi Kari, > > thanks for the issue report. I suspect some nasty interaction with the > logic to limit the total number of decodes stored in the Band Activity > window. For now I suggest you erase the Band Activity window now and > again to avoid this issue. > > 73 > Bill > G4WJS. > > > > ___ > 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
Re: [wsjt-devel] PJ4P Operation
Once I saw what they were doing, I ignored them 100%. But so many don't realize they are defeating the purpose of FT8 and an unwritten "Code of Conduct" like a certain Belize station does all the time. George - WB5JJJ On Wed, Jan 23, 2019 at 5:29 PM Gary McDuffie wrote: > > > > On Jan 23, 2019, at 13:34, John Zantek wrote: > > > > Has anyone observed the FT8 operation of the PJ4P expedition team? > Maybe I’m missing something obvious, but…. > > > > It LOOKS they’re operating as a Fox, but on the conventional FT8 > frequencies. > > Saw the same thing this afternoon. I think it was on 17m. > > > Their transmissions are varying between < 500Hz and > 1000Hz. > > In my case, they were ~200-300 > > > I know this isn’t a Developer issue, but I trust the folks on his list. > I’m after PJ4 on 160M, but wasted an entire evening last night trying to > figure out how to work them. > > I wouldn’t waste my time trying to work them, since they aren’t “playing > by the rules”, i.e. using the software the way it was intended, on the > frequencies it was intended for. Working them just reinforces the fact > that they can do it and people will still QSO them, so why change. > > Gary - AG0N > > ___ > 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
Re: [wsjt-devel] Short Tx inhibits decode...
I've noticed that as well. Been this way for many versions back. Once the Tx cycle has been initiated (i.e. odd or even Tx has started), and if you then click Halt Tx, the radio will go to receive, the WF will show the signals, but none are decoded for the aborted Tx cycle. At the start of the next cycle, all is normal. WB5JJJ - George On Thu, Jan 17, 2019 at 3:01 PM Paul Kube wrote: > > If I cancel my own transmission right at the beginning of a cycle, I see > no decodes at all for that cycle. > > For example, say I'm CQing on even cycles. After a couple, I decide I want > to stop CQing if I don't get any replies, so I hit Halt Tx as soon as I see > the list of decodes from a just-finished odd cycle. Maybe I am transmitting > for a second or two into the adjacent even cycle; but there are never any > decodes from it at all even when lots of signals are present in the > waterfall. > > Naively, it seems to me that this doesn't need to happen. I often see FT8 > decodes for stations that start late -- as much as 4 seconds late -- in a > cycle. So why does missing the first second or two prevent decoding > anything? > > If this could be changed, it would be nice. A few of those wasted 15 > seconds add up! > > Thanks, and 73, > > Paul K6PO > > > > > ___ > 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
Re: [wsjt-devel] F/H demo at local hamfest
I have had many helpful comments since my post both on forum and direct messages. Thanks to all, I have F/H working "over the air" using no RF at all. My test "Fox" is a desktop computer in the den and my "Hounds" are a couple of laptops on a kitchen counter. Even with all the household noises, washer, scanner, and furnace, the decodes work perfectly. And I'm not pumping out full audio either. Matter of fact, it's amazing how little audio is required, so it's quiet comfortable on the ears. With Fox at 300 and the Hounds at 1500 and 1800, they work great. Then when the Fox clicks on them, they go to 310 and 370, or there about, to finish the contact. We already have at least 5 laptops that will be used in this F/H demo and hopefully we can show the inner workings of the Fox and why things work the way they do. We will also try to make contact in "normal" FT8 mode to show why this doesn't work. Also calling below 1000 will be shown. At least they can see what the Fox sees via a large flat screen TV. Will have users just enter their call in WSJTx and change nothing else as it's of no matter for the demo. That way, they will recognize their own call on the laptop in front of them or the Fox view on the big screen. Again, thanks for the points to the right direction. George - WB5JJJ On Thu, Jan 3, 2019 at 7:22 AM Bill Barrett wrote: > I scotch tape the ear buds to the microphone on a pair of Apple ear buds > plugged into the PC. > Then set up a fox instance and several hound instances on the same PC. > Any number of different scenarios can then be demonstrated. > > 73; W2PKY > > > On Wed, Jan 2, 2019 at 9:57 PM Gene Marsh via wsjt-devel < > wsjt-devel@lists.sourceforge.net> wrote: > >> That’s BRILLIANT! >> >> 73 de W8NET Miles / “Gene” >> Secretary, Portage County Amateur Radio Service (PCARS) >> >> On Jan 2, 2019, at 9:22 PM, Gary Hinson wrote: >> >> Hi George, >> >> >> >> Another approach is to use AUDIO instead of RF for your demo. No radios >> needed, just laptops. Deliberately route the FT8 audio output to the >> loudspeaker and use the microphone for audio input. In a typical meeting >> room, there is generally enough audio level for decoding, above the usual >> hubbub of excited hams. [An interesting point that! FT8 handles weak >> sigs and QRM very nicely.] >> >> I’ve run a workshop like that. The first part of the session involves >> getting the software installed, running and configured on all the >> attendees’ laptops, with appropriate audio & station settings and accurate >> clocks. Ideally that should be a separate pre-session, with competent >> helpers on hand to deal with the inevitable issues … or maybe a set of >> ‘loaner’ laptops pre-configured. >> >> The second part gets everyone at least receiving and decoding FT8, and >> hopefully most of them transmitting too, making QSOs within the room. >> >> The third part moves into fox-n-hounds, contesting and whatever, for >> those who have the stamina and interest! >> >> 73 GL >> Gary ZL2iFB >> >> >> >> >> >> *From:* WB5JJJ >> *Sent:* 03 January 2019 12:10 >> *To:* WSJT software development >> *Subject:* [wsjt-devel] F/H demo at local hamfest >> >> >> >> I have been asked to set up a F/H demo for our hamfest in March. I'm >> thinking run the power all the way down on some rigs set up around the room >> and transmitting into dummy loads on a very discrete frequency so as to not >> get people too excited elsewhere. This way the local hams could actually >> see what is going on with the Fox and maybe understand the operation a bit >> better. >> >> >> >> Since none of us here are experienced "Foxes", some guidance in this area >> would be really great. I know RTFM and I have done that, but experience is >> a better teacher, in my view. So, does anyone have a step by step guide on >> how to set up the Fox and what to expect on the Fox side during this demo? >> >> >> >> Help would be greatly appreciated to those that are in the know on this >> subject. >> >> >> >> Please answer off list. I'm good on QRZ. >> >> >> >> Thanks. >> >> George - WB5JJJ >> >> ___ >> 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 mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] F/H demo at local hamfest
I have been asked to set up a F/H demo for our hamfest in March. I'm thinking run the power all the way down on some rigs set up around the room and transmitting into dummy loads on a very discrete frequency so as to not get people too excited elsewhere. This way the local hams could actually see what is going on with the Fox and maybe understand the operation a bit better. Since none of us here are experienced "Foxes", some guidance in this area would be really great. I know RTFM and I have done that, but experience is a better teacher, in my view. So, does anyone have a step by step guide on how to set up the Fox and what to expect on the Fox side during this demo? Help would be greatly appreciated to those that are in the know on this subject. Please answer off list. I'm good on QRZ. Thanks. George - WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Interesting feature. Bug can be reproduced
All you need to do is to TAB or CLICK ANYWHERE outside the TX6 dialog box and they will change to Upper Case during the Enable Tx cycle. The same thing happens if you enter lower case in the DX Call or DX Grid boxes. However, Tx5 does automatically take lower case keystrokes and enter as upper case. On Sun, Dec 23, 2018 at 2:04 PM Saku wrote: > Tested this again with rigctld -r 1 (dummy) > > 1) Start wsjt-x > 2) Place cursor to TX6 edit box between CQ and YOURCALL > 3) Write 2 letters with low case (e.x. na) > 4) Enable TX > 5) When TX fires, letters will change to upcase (ex. NA). That is ok. > 6) During TX period, or during following RX period wipe letters away > (ex. NA) replace with 2 low case letters (ex. oc). Keep TX enabled. > 7) Next TX period will transmit those letters and cq in angle brackets > and space replaced with _ (ex. ) > 8) During TX period, or during following RX period wipe letters away > (ex. oc) replace with 2 upcase letters (ex. EU) > 9) Next TX period will send CQ EU in upcase. That is ok. > 10) During TX period, or during following RX period wipe letters away (ex. > EU) replace with 2 low case letters (ex. af) > 11) Next TX period will transmit first used low case letters and cq in > angle brackets and space replaced with _ (ex. ) again. > > Repeat this what ever low case letters you like. Result is always the > first low case letters pair you used in CQ. > Stop wsjt-x. > On next start it does not remember them any more, but this can be > reproduced. It will remember the first low case letter pair you now use. > Until the end of program run. > > > Conclusion: > > Converting to upcase works only in first time (TX enabled pressed). If TX > is kept enabled all the time while editing TX6 upcase conversion does not > happen again. > With low case letters it generates some kind of CQ hash code (?) that it > will remember until the end of program. > > > -- > Saku > OH1KH > > > Saku kirjoitti 23.12.2018 klo 16.10: > > > While keeping cursor at TX6 box (before my call) I did change directed cq > between JA and AS. > All went ok if I had CAPS on (shift pressed). > > Few times I missed shift and wrote "ja" instead of "JA". Results can be > seen below. > Typing "as" or "AS" did not make any difference. > > When I started to test this I did not get it happen any more () May be > related to time of period when this "ja" is typed (?) > Or otherwise full TX period must be waited before new change. > > If stopping TX and try to change "ja" and "JA" and restart TX it does not > make any difference. > That was the way I tried to quick test it more. > > > v2.0.0 (x64.rpm) Fedora 28 > > -- > Saku > OH1KH > > > > ___ > wsjt-devel mailing > listwsjt-devel@lists.sourceforge.nethttps://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
Re: [wsjt-devel] Suggestion Hold TX Freq sticky
I did and Laurie said the same thing. I gave it a try just now and it DOES work. I guess there was just a glitch in my configurations when the FT8 RU was in progress. That was the last time I did a configuration change. That weekend, I had to restart JTAlert every time I went back to normal FT8. On Mon, Dec 17, 2018 at 11:31 AM Bill Somerville wrote: > On 17/12/2018 17:19, WB5JJJ wrote: > > If I do a configuration change, I have to stop and restart JTAlert as > > it doesn't connect again automatically to the new configuration. > > Hi George, > > that's not right, several versions ago changes were made to the WSJT-X > UDP protocol and to JTAlert to make configuration switching seamless. > Have you raised this issue on the JTAlert support forum? > > 73 > Bill > G4WJS. > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Suggestion Hold TX Freq sticky
Sorry. It seems to be working now. I just tried it. However, it did not function properly when I tried the FT8 Round Up a couple weekend back. This could have just been a glitch that day in my computer. Thanks. On Mon, Dec 17, 2018 at 2:25 PM Laurie, VK3AMA <_vk3a...@vkdxer.net> wrote: > > On 18/12/2018 4:19 am, WB5JJJ wrote: > > If I do a configuration change, I have to stop and restart JTAlert as > > it doesn't connect again automatically to the new configuration. > > That's OK when I go to DXP configuration since I will probably stay > > there for several hours. > > That should not be the case. > > JTAlert will automatically detect changes in WSJT-X when it changes > config and automatically readjusts itself ensuring docking and UDP > traffic monitoring for that WSJT-X instance continue. This has been > inplace since JTAlert version 2.10.0 (21-JUL-2017). There have been no > reports since then that this is not working. > > de Laurie VK3AMA > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Suggestion Hold TX Freq sticky
No, I haven't. It's not that big of a deal to me when I go to/from DXP. It's just become habit, like checking the Hold box when going from MSK144 to FT8 - most times. On Mon, Dec 17, 2018 at 11:31 AM Bill Somerville wrote: > On 17/12/2018 17:19, WB5JJJ wrote: > > If I do a configuration change, I have to stop and restart JTAlert as > > it doesn't connect again automatically to the new configuration. > > Hi George, > > that's not right, several versions ago changes were made to the WSJT-X > UDP protocol and to JTAlert to make configuration switching seamless. > Have you raised this issue on the JTAlert support forum? > > 73 > Bill > G4WJS. > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Suggestion Hold TX Freq sticky
Yes, I do that for DXP and such that require several changes. But just to
change modes, there is a drop down for that already that's just 2 clicks
and everything continues along just fine. Plus the Auto Seq and Call 1st
are sticky already.
If I do a configuration change, I have to stop and restart JTAlert as it
doesn't connect again automatically to the new configuration. That's OK
when I go to DXP configuration since I will probably stay there for several
hours.
On Mon, Dec 17, 2018 at 11:07 AM Bill Somerville
wrote:
> On 17/12/2018 15:21, WB5JJJ wrote:
>
> As I change from MSK144 to FT8, the vast majority of the time I forget to
> check the Hold Tx Freq box until I've moved off my clear spot.
>
> Could this box be made a sticky for either choice?
>
> Hi George,
>
> one easy option is to create a separate configuration for each mode
> ("Menu->Configurations"). it is normally easier to switch configurations
> (two mouse clicks) than to switch modes (two mouse clicks plus several more
> to change other options and settings necessary for the new mode and
> intended use).
>
> 73
> Bill
> G4WJS.
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
George Cotton, WB5JJJ
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Suggestion Hold TX Freq sticky
A single left mouse click in the box does the same and keeps the frequency in place. Also, the Auto Seq and Call 1st are sticky, so why not Hold Tx Freq? That's my question. On Mon, Dec 17, 2018 at 10:57 AM Bramax wrote: > Can I suggest, if you move the TX frequency with check automatically the Hold TX Freq box? > > Just my 2 cents. :) > > Maurizio I2NOY > > > Il 17/12/2018 16:21, WB5JJJ ha scritto: > > As I change from MSK144 to FT8, the vast majority of the time I forget > > to check the Hold Tx Freq box until I've moved off my clear spot. > > > > Could this box be made a sticky for either choice? > > > > -- > > George Cotton, WB5JJJ > > > > > > > > ___ > > 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 > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Suggestion Hold TX Freq sticky
As I change from MSK144 to FT8, the vast majority of the time I forget to check the Hold Tx Freq box until I've moved off my clear spot. Could this box be made a sticky for either choice? -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Problem - WSJT-X decoding poorly.
The biggest problem I see is that you are WAY behind the curve on software. The current version is v2.0.0 GA and all previous versions are deemed obsolete and incompatible with v2. I suggest you update as soon as you can and once you do, you will see more decodes as the decoders in v2 have been vastly improved. George - WB5JJJ On Wed, Dec 12, 2018 at 8:25 AM Bob Seaboldt wrote: > Program version - wsjt-x v1.9.0-rc4 > > Operating system - linux - Debian GNU/Linux 8 (jessie) 64-bit > > System - 2G ram, 1.66GHz (dual), SSD HD 240G (acer aspire one) > > Radio - TS2000 with SignaLink USB (Through ACC port) > > Concise description of the problem - It seems that wsjt-x is unable to > decode FT8, especially signals with high amplitude. When I first had the > system running, I was able to decode all signals (in fact I was very > impressed). Now, after about a week, it has stopped decoding properly. I > am using NTS time utility and the clock seems to be spot on, certainly > within 2 seconds. I have changed the audio level out of the SignaLink from > 10 to 80 (on wsjtx - it was running well at about 30 to 50) with no change. > I have also tried adjusting the audio level out of the TS2000 (menu 50C) > again with no change. > > Exact sequence of steps required to reproduce the problem - Problem has > been persistent for 2 days now. If I see a signal calling CQ (usually a > weaker signal), then I can work them. If I call CQ and I see a station > attempting to reply, then I likely will not see the decode. Just > monitoring I will see several signals on the waterfall (lets say 5), but > only a few will decode (lets say 1). it seems to be louder signals that > are affected. > > - NS0V > > ___ > 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] Suggestion - Progress Bar
As with most transceivers, Green is for Receive. So is the progress bar. Why is it not Red for Transmit instead of Green? Would make it stand out a bit more than the yellow box on the lower left of the screen. -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Power Levl for logging
Power changes have not been transferred to HRD LB since mid september. But Comments were posting to LB last weekend during the 10m contest. On my system the power and comments have been retained all along. On Mon, Dec 10, 2018 at 2:07 PM Bill Somerville wrote: > On 10/12/2018 20:01, dgb wrote: > > If one wishes, you can change the default power level. I WSJT-x File, > > Open Log Directory, you will find a file named WSJT-X.ini. Close > > WSJT-X and edit that file and do a ctrl F for TxPower= and change it > > to what you want. > > > > Of course when and if you change power level again you'll have to go > > thru the same thing. > > > > Hv Fun ... 73 Dwight NS9I > > Hi Dwight, > > please double-check that is making it into your station log? > > 73 > Bill > G4WJS. > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bug Report
Initially in the Colors window, all text was shown as BLACK and the backgrounds were as before (RC's). However, in use, since some were now "unset", they where white on color in my implementation. I only use a small subset (6) of the choices and that is what was causing my white text. By changing those to black, all is working as desired. If someone has everything checked, then they will reap the benefits, but I don't need that much information. If I need/want more I can always "unset" the foreground colors. I was seeing one thing in the setup, but a different display in operation. The documentation did not fully explain this as it apparently assumes everybody will use all the options, so that's what threw me. All is good now - happy camper. On Mon, Dec 10, 2018 at 9:49 AM Bill Somerville wrote: > On 10/12/2018 15:39, WB5JJJ wrote: > > I see the logic, but the way I have mine setup, I only checked My Call, > Transmitted Message, New DXCC, New Call on Band, New Call and CQ in Message > in that order. With my logic, such highlights as New Call or New Call on > Band are always white on blue - impossible to read. The rest are > unchecked. > > OM, > > none of the default highlighting colour options use white for foreground > text, I don't see how you could end up with white on any background unless > you changed it to that yourself? > > 73 > Bill > G4WJS. > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bug Report
I see the logic, but the way I have mine setup, I only checked My Call, Transmitted Message, New DXCC, New Call on Band, New Call and CQ in Message in that order. With my logic, such highlights as New Call or New Call on Band are always white on blue - impossible to read. The rest are unchecked. On Mon, Dec 10, 2018 at 9:29 AM Bill Somerville wrote: > On 10/12/2018 15:18, WB5JJJ wrote: > > Yes, we all see this. But those that have f/g marked "unset" will be > > WHITE and should be changed as the text may disappear. > > OM, > > that is not quite right. The ones that unset are useful as that colour > (foreground or background) is still available for lower priority > highlighting types. Setting them would be throwing away the ability to > highlight two different types per decode. > > Please review the User Guide: > > http://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.0.0.html#COLORS > > 73 > Bill > G4WJS. > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bug Report
Yes, we all see this. But those that have f/g marked "unset" will be WHITE and should be changed as the text may disappear. On Mon, Dec 10, 2018 at 9:16 AM CT1EKD wrote: > > Hi > Just instaled version 2 > At version 2 I'm see this when choose colors. > it it just me or we all see it? > I attached a picture .. > > Pedro - ct1ekd > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Calling CQ then selecting dB
He's flying kinda blind by using Tab 2 apparently. Should be using Tab 1 for most information and better understanding of Auto Seq operations. On Sun, Dec 9, 2018 at 3:14 PM Gary McDuffie wrote: > > > > On Dec 9, 2018, at 10:33, SKI W4PPC wrote: > > > > When calling CQ and a station sends their call sign plus grid, I select > dB button and the system replies to the station I had contact with > previously...only until I select the caller's call sign in the Band > Activity window the reply then is to the caller who answered my > CQ...attached jpg. > > Are you double clicking on the incoming call in the left screen? If you > do, it should automatically populate the report and other boxes with the > correct data/callsign. It should also switch to the correct outgoing text > box and step through them when it is time, assuming you have auto-sequence > checked. > > Gary - AG0N > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 2.0 RC5
Still times where there are few users of v2. But it's building by the day. Been on RC's since the start and I'm contacting more and more new calls all the time. Some times are better than others. 20m during the day, 40m evenings and 80m at night. Even 160m occasionally when I can get the antenna to tune. There are tens of thousands on v1.9.1 or earlier and around 2,500 on v2. Hopefully that will change after the Grid Chase is over the end of the month and the full release version comes out on Monday. Hang in there. George On Fri, Dec 7, 2018 at 7:22 PM Unni Tharakkal wrote: > I tried different selections and procedures still I am not able to resolve > my RX decoding on RC 5.00. Request help > I synchronized the system clock also > System is ACER with Win 10 and Dig. interface is a BY product Link 3. > 1.9.1 version was working ok. > > VU2TE > Unni > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Frequency selection dropdown truncated
I prefer your chopped off info as mine cuts out the middle. So 7.078 (or 74) would be 7.07...(40m). Kinda makes it difficult to remember what you have. It has been reported and maybe a fix in v2 release. On Fri, Dec 7, 2018 at 9:38 AM Greg M0NZO wrote: > Hi all > > I’ve just installed WSJT-X v2.0.0-rc5 under a default Raspbian 9.6 > installation. Everything appears to be working fine, except for the > dropdown list for frequency selection is truncated (please see attached > screenshot). Is this a bug? > > 73 > Greg M0NZO <http://m0nzo.uk> > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Frequency selector dropdown
Excellent thought Eric, but not the case here. I have 3 monitors. None are zoomed in but using the default sizes for the 1280 x 1024 for my monitors. #1 has HRD Logbook and web sites via Google, #2 is WSJTx and JTAlert with JTAlert taking top and right side of WSTJx. Even stopping those programs and taking WSJTx to full screen doesn't change the dropdown even after a restart of WSJTx in full screen mode. #3 monitor has HRD Rig Control with the WSJTx Waterfall taking the bottom 2/3rds of the window. George On Wed, Dec 5, 2018 at 11:29 AM Eric Lundstrom wrote: > As a Windows application developer, I have observed the sizing issue > described here when the Windows display settings are set to, say, 125% of > normal. Not all widgets used in the application resize themselves and the > result is truncated text in the widget. There are probably other causes for > this condition, but this is an easy one to check. > > Eric > -- > *From:* Dave J Barnes > *Sent:* Wednesday, December 5, 2018 09:11 > *To:* wsjt-devel@lists.sourceforge.net > *Subject:* Re: [wsjt-devel] Frequency selector dropdown > > Bill, > > It looks like a Qt bug to me. > > I had deleted all of the UHF and above frequencies from the frequency > list. That is why the combo box list was too narrow. > > I added a 10 GHz frequency back to the frequency list. Now the combo > box list is wide enough for everything but the 10 GHz entry. > > HTH > > djb > > > > ___ > 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 > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Frequency selector dropdown
No. 99.9% repeatable on restart. Very occasionally on a configuration change, it will be wide enough, but the next time I use the drop down, it's back to narrow. I think this has been through all the RC's for v2. Kept thinking it would be fixed, but not yet for me, at least. Running RC5 on Win 10 Pro with 12Gb RAM and i5 processor. On Wed, Dec 5, 2018 at 8:41 AM Bill Somerville wrote: > On 05/12/2018 14:30, WB5JJJ wrote: > > This dialog box needs to be automatically sized based on data and font. > I've learned to live with it, but this would be a welcome adjustment to the > display. > > Hi George, > > it should sort itself out if you exit WSJT-X and restart. Is that not > happening? > > 73 > Bill > G4WJS. > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Frequency selector dropdown
As you can see from the attached image, this is what I am dealing with. I had to increase the font and decoded text sizes to make them easier for me to read. This dropdown "most" of the time does not show the complete frequency. But on a rare occasion all information is displayed. Makes it kinda hard to select frequencies when more than one per band are listed. The Font is Consolas - Bold - 11 The Decoded Text Font is Consolas - Bold 15 This dialog box needs to be automatically sized based on data and font. I've learned to live with it, but this would be a welcome adjustment to the display. 73's -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] what is rtty mode?
It seems that after each test of the FT8 RU, I am one of "These guys". Not used to having switched operational modes, so I'll send our 4 or 5 CQ RU's before I realize that I'm not calling RUssia or doing the RU. A quick configuration selection change fixes everything. Senior moment(s) are more frequently of late. Way too much going on in today's world to remember all the little details. Oh my.. 73's - George On Wed, Dec 5, 2018 at 7:56 AM Joe Taylor wrote: > Dave -- > > On 12/1/2018 2:07 PM, Dale Wheeler via wsjt-devel wrote: > > Using win 10 > > Running ver. 2.0 rc5 > > > > I have received the same pop-up 3 times. It asks if I want to RTTY > > contest mode (see attached picture). I looked but don't understand the > > documentation. Am I doing something wrong or is this a bug? > > Your screen shot shows that you have decoded several messages of tyhe > form "CQ RU ...", the CQ message used in the FT8 Roundup, ARRL RTTY > Roundup, and similar contests. > > From the Quick Start Guide to WSJT-X 2.0, page 5: > > "Casual operators who decode a contest-type message formatted for ARRL > Field Day or ARRL RTTY Roundup will be prompted to check the relevant > box so that they can transmit the required exchanges." > > These guys just forgot to change their CQ message. Just click OK and > ignore the message box. > > -- 73, Joe, K1JT > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] UTC time in contest log page
Jim: Today, I went back to my first saved FT8-RU test contest and the Contest Log compared to my actual HRD LB spot on as did the one from this weekend. As stated to Bill, my Windows 10 Pro clock is set to display 24hr (HH:MM:SS) using Windows clock settings, and I use T-Clock to actually display the clock, in LOCAL 24H TIME, on the right of the Task Bar in LARGE numbers that I can easily see. I'm set to US Central Standard Time with automatic DST and the Windows Time Service is disabled. BKT is used to sync time once an hour and that keeps my DT within +0.3 seconds on average. I seldom see a negative DT. This is how my computer has been set for years, even way before FT8. Nothing was changed, but I tried setting the sync as far back as 6 hours and was still with the current 2.5 second window. So my computer clock is really stable. I've had zero problems with RC4 or RC5 except for a couple of the discovered "bugs" that were fixed in RC5. My color highlights seem to be working perfectly in RC5 as I've cross checked them with JTA and my HRD LB on many occasions. All these logging problems are perplexing until it was realized most were caused by using Tab 2 instead of Tab 1. I have no clue how anyone knows what is happening with Tab 2 until it prints on the screen. A very confusing GUI there for sure. My JTA panel only shows stations that are calling CQ, are new to me on the current band and are LoTW users in the past year. During the contest, I had as many as 10 (of my 12 slots) with new stations in them. Typically, it's 3-5. Even with the highlight fixes due in the GA next week, I'll probably still use JTA as it's more concise and easier to read at a glance. WSJTx sent each and every FT8 RU contact to the Contact Log and directly to HRD LB without dropping any data at all. Everything agrees 100% with no manual intervention by me. I do edit some European QTH's in HRD LB when they have their Postal Code in front of their city name since it makes my LB look kinda funny. George ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] UTC time in contest log page
Bill: My computer is set for Central Time USA and not UTC. The Contest Log has always shown the correct UTC since the first RU test. On Mon, Dec 3, 2018 at 11:34 AM Bill Somerville wrote: > On 03/12/2018 17:18, WB5JJJ wrote: > > Explain me this. My UCT was correctly logged in the Contest Log from the > get go. 24 hour and all. My Win10 system was already set for 24 hour > display and I use a program called T-Clock to display the time in the lower > right Task Bar spot replacing the dinky Windows clock and sync my time > every hour. This program gives me a nice modifiable time clock HH:MM:SS in > 24h mode as well as a realistic "Big Ben" chiming function on computers > other than the one in the Ham Shack. Could this be the reason my UCT was > correct? BTW, this clock shows the LOCAL time, not UTC. I still need that > to know what time it is here. HiHi. > > 73's - George > > Hi George, > > your change to the regional default in Windows to show times in 24hr > format explains the display in the contest log page. The next release > overrides the system setting and always displays 24hr format with seconds > showing. > > I can't explain your log not displaying (erroneously) in local time, > perhaps the time zone setting on your computer is UTC? > > 73 > Bill > G4WJS. > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] UTC time in contest log page
Bill: Explain me this. My UCT was correctly logged in the Contest Log from the get go. 24 hour and all. My Win10 system was already set for 24 hour display and I use a program called T-Clock to display the time in the lower right Task Bar spot replacing the dinky Windows clock and sync my time every hour. This program gives me a nice modifiable time clock HH:MM:SS in 24h mode as well as a realistic "Big Ben" chiming function on computers other than the one in the Ham Shack. Could this be the reason my UCT was correct? BTW, this clock shows the LOCAL time, not UTC. I still need that to know what time it is here. HiHi. 73's - George On Mon, Dec 3, 2018 at 11:08 AM Bill Somerville wrote: > On 03/12/2018 03:59, Rich Zwirko - K1HTV wrote: > > I noticed during the FT8 RU that the log page, although in UTC, is not > > in the 24 hour format but uses the 12 hour plus AM or PM. Who uses UTC > > in 12 AM/PM format? Almost all Ham logs are in 24 hour format, right? > > > > 73, > > Rich - K1HTV > > Hi Rich, > > already fixed for the next release, displayed date and time in the > COntest Log window were in the local time zone and with the PC's > regional display format which in "English (United States)" is 12hr > AM/PM. Underlying data is correctly stored in UTC. > > 73 > Bill > G4WJS. > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] 100% success for me
Joe and list: I was only able to devote a hour or so here and there on Saturday, and on Sunday I was out of town all day. I was able to log 63 stations, many of which were 1st timers for me, so v2 and the contest brought lots of new calls to the air, at least for the contest. So many signals in the WF that it looked like normal 20m, except they were all running v2 RC5 this time. I had absolutely no problems with WSJTX RC5, JTAlert and HRD LB. The Contest Log was a perfect performer. Times were in UTC and correct in all respects. All exchanges were handed off from WSJTX to HRD Logbook without error. HRD LB of course did a QRZ lookup and found all personal data and the listed Grid Square. And, of course, I was using TAB 1 which give the most detail of system operations. Looking forward to v2 GA and increased users. -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Tab 2 - never used
Tab 2 is something I never have used (other than early on testing) and find it useless in my operation. With Tab 1, I can see EXACTLY what is about to be transmitted and I have full control over what is next or what I want to send NOW. No surprises or guesswork required, especially with the full TX text always shown right there. I'm sure there are users that live and die by Tab 2 because of it's simplicity and in that light, maybe it should stay for those folks. But for me, I find it of no value in normal operation of WSTJX. -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Tab 2
Bill: As you requested, I have never used Tab 2. One vote to remove it. Tab 1 has all the information as to what is going on during a contact with no thinking required. I have NOT had the UTC/Local time stamp issue. My Contest Log has the correct 24 hour UTC for every entry and I'm set to Central Time in my automatic MS time keeping offset. Enjoyed reading your all-inclusive review of problems/solutions and fixes in one place, great work putting that together. Thanks. Windows 10 Pro 64 bit here and all aspects of WSJTx-RC5 have worked perfectly. I for one, have not had a single problem with the Contest Logger, so never had a reason to "edit" it for any reason. Everything is logging to HRD LB directly without a glitch - and I DO check every entry while waiting on next contact. Even though most contacts do not include a Grid Square along with all other personal information, HRD LB does get the 6 digit GS with the query of QRZ upon adding the entry. Of course this field is "0" characters in the WSJTX log file. This could cause a problem for some that use the adi file as the import to their logger. The size may not allow the GS to be edited in their logger to a 4 or 6 character count since space was not allocated by the adi file import. Bottom Line - the program requires absolutely no interaction from me for proper logging. I do edit the HRD LB entry when some European stations have their Postal Code in front of their QTH information, so I do delete that. (Future note to coders to fix this if possible, could be a problem as there are several variations being seen). 73's -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] New Stations (2)
JT Alert is telling me that there are between 5 and 10 new stations calling CQ on each time slot to on 14.130 with the RU Test Contest. Now if these guys would just stay on v2 after the test, it would be awesome. -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] not decoding ru
Check your time sync. Decoding 20-30 per pass here in Arkansas on 14.130. On Sat, Dec 1, 2018 at 1:31 PM David Pickard wrote: > I have v2-rc5 installed. Worked several stations yesterday on FT8. I am > currently on 14.130 and hear lots of FT8 signals and see them on the > waterfall but am showing very few decodes. I moved up 2khz and heard lots > of signals but no decodes. > -- > *David NM5Z* > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] New stations on RU today
A multitude of ANTO's (stateside) on 14.130 for the Round Up. Looks like a lot of guys have made the jump to RC5 at least for this test contest. WF looks better than 14.074 since everybody is v2 here today. -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] what is rtty mode?
These stations with 5xx numbers should NOT be operating on the standard FT8 frequencies. They are operating as RTTY Round Up, but that starts on 14.130 and up to 14.150 and similar on other bands. On Sat, Dec 1, 2018 at 1:12 PM Dale Wheeler via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > Using win 10 > Running ver. 2.0 rc5 > > I have received the same pop-up 3 times. It asks if I want to RTTY contest > mode (see attached picture). I looked but don't understand the > documentation. Am I doing something wrong or is this a bug? > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Graphic confusion ;-)
Allan: Easy fix. Just ignore the dialog boxes and just follow the arrow indications. Works as displayed perfectly On Sat, Dec 1, 2018 at 9:06 AM wrote: > Neil, > > > > Well, that’s exactly how I would like to have it, but it’s not how it > works here. When moving from A to B – the arrow should point from A to B. > My arrows are apparently opposite (see attached photo). Set RX frequency to > TX frequency on my version ( rc5 737d2f) is the right hand button – and the > arrow points down (towards the RX frequency). Have I missed something here? > > > > Allan, OZ5XN. > > > > *Fra:* Neil Zampella [mailto:ne...@techie.com] > *Sendt:* 1. december 2018 13:09 > *Til:* wsjt-devel@lists.sourceforge.net > *Emne:* Re: [wsjt-devel] Graphic confusion ;-) > > > > Allan, > > I'm not sure what you're saying, are you talking about V5?.The arrow > to move the RX freq to TX points up (away) from the RX to the TX, and vice > versa. How is that confusing? Most people love that change. > > Neil, KN3ILZ > > On 12/1/2018 5:05 AM, m...@oz5xn.dk wrote: > > Just a single confusing graphic detail that might be corrected: On the two > buttons for moving TX / RX to the same frequency, the arrows turn > illogically (remains from 1.9 and earlier). The arrows should turn opposite > so they point to what you do, i.e. that "Set RX frequency to TX frequency" > points from RX to TX. It took me some time to get used to making things > "wrong" to get the right result. :-) > > > > Thank you for continuing the great work! :-) > > 73, Allan > > > > > > > > [image: Billede fjernet af afsender.] > <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> > > Virus-free. www.avg.com > <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X rc5 error reports
Allen, you can change the LoTW text color by right-click on the color selection. However, if you change it to black, all indications will be black. This item should be left unchecked as the vast majority of FT8 users are LoTW users. The better option was in RC3 which had that to show - check for NOT LoTW user, which made a lot more sense to most. I am also seeing multiple attempted responses not decoding as well on signals that should be perfectly copy-able and no QRM detected. 73's On Fri, Nov 30, 2018 at 9:09 AM wrote: > Hi guys, > > Error reports V2 rc5 737d2f. > Logging: I’m prompted to log even if ”Log automatically” is ticked and > “Prompt me…” unticked. > Answering CQ : Double click on a CQ call doesn’t react in JT65 or JT 9 > mode – but works in JT9+JT65 mode. > > Finally it’s my impression that some of my QSO counterparts have decoding > problems as exchange of reports in many cases needed to be repeated > more/several times even if signal levels were good (see attached example). > I have given up some QSO’s after 6-7 retransmissions of signal reports even > if signal levels were good. But I don’t know which versions my counterparts > were using or if there could be other reasons. > > > > Suggestions from my wish list: > > Black is much easier readable than red text so I would much prefer black > text for yes to LoTW. > > I miss the possibility for a sound notification when own call are decoded > (like from JTalert “calling you”) and another sound for “any call decoded”. > That would be very useful not least for MSK 144, where CQ often is > transmitted over a longer time before any response but also when monitoring > “dead” bands (e.g. 6 and 10 meters). Notifications could be just a beep, > ding or a user selectable wav file. > > > > 73, Allan 5P9R/OZ5XN > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] LoTW / No LoTW
It's not the colour, but the usefulness of the option. So, it's UNCHECKED. Problem sorta solved. On Wed, Nov 28, 2018 at 9:39 AM Bill Somerville wrote: > On 28/11/2018 15:27, Lee. KX4TT via wsjt-devel wrote: > > It also does not work well with the green highlighting for those who are > color-blind; People with either protanomaly or deuteranomaly may have > problems in this case. The result for red lettering on a green background > can be two indistinct non-contrasting grays………..I would actually > suggest not using red at all for this. > > > > > > 73 de Lee KX4TT > > Lee, > > the colour is user configurable. > > 73 > Bill > G4WJS. > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Odd occurance
I've noticed on RC5 that when I call CQ and a station answers, I have to send their signal report at least twice before things move along. In checking with the other station if they have JTAlert messaging on, they do have their Auto Seq on, and are sending their Rxx information as normal. I'm just not decoding it even though they show up in the WF more or less the same signal display as when they responded to my CQ and no obvious QRM. This happens with all signals levels. This does not happen for all responses, but enough that it got me wondering. -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Yet another RC5 colors issue
Prob uncheck LoTW User highlight or change it to see if that's the problem. On Tue, Nov 27, 2018 at 8:00 PM Paul Kube wrote: > This issue involves foreground color, not background color: > > In Settings > Colors: > > >1. Click Reset Highlighting, and confirm >2. Uncheck all boxes in the Decode Highlighting list >3. Right click CQ in message, Foreground Color, pick something other >than black, e.g. red; click OK >4. Check only boxes for New Call on Band, and CQ in message >5. Note that New Call on Band and CQ in message have different >background AND foreground colors. >6. Click OK > > Now one would expect decodes for New Call on Band, and CQ in message, > would have different background AND foreground colors. > > However: background colors are indeed different, but foreground colors are > the same, e.g. red. > > WSJT-X v2.0.0-rc5 > Windows 10 Pro x64 Build 17134 > > Thanks, > > Paul K6PO > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RC5 problem with new grids on the band?
I'm finding the Grid part is almost always showing a new grid even though that station/grid has been worked numerous times. I just unchecked the Grid and Grid on Band as I've found them inaccurate. I can go the the wstjx_log.adi and find the call/grid/band/mode logged correctly, but still showing as "new". Also unchecked the ITU, CQ and Continent selections. Don't like the LoTW showing users, I preferred it when it was the opposite, as it made the non users stand out, so It's unchecked as well. On Mon, Nov 26, 2018 at 7:30 PM Don Hill AA5AU wrote: > I did a color reset on RC5 startup (also had to disable contest mode as > WSJT-X started in contest mode.) and read the new Quick Start Guide. Then > all CQ decodes from stations I have already worked on the band showed they > were all new grids on the band. This seems to not be working since all of > the stations calling CQ at the time were already in my log on that band > except one which showed as a new call on the band. > > I did work a station that was calling CQ (showing as a new grid on the band > despite being in the log on that band already) and after the contact was > logged, the station called CQ again and the call highlighted green as it is > supposed to. So not sure what to make of it. My wsjtx_log.adi is an export > of all 21,376 FT8 contacts from my DXKeeper log. > > Could the fact that the ADIF is from DXKeeper be the problem? I've been > using the DXKeeper export for many months now and it's always worked. I > have > to use the DXKeeper export in order to keep the logs correct for both > instances of WSJT-X I run (two radios). > > Yes, I did restart the program a few times. > > Is this is a bug? Or am I doing something wrong? > > Don AA5AU > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 2RSC3 > 2RSC4 decoding disappeared FT8
Ken, if you would read the Quick Start Guide or the Release Notes, all is explained. Your operation is 100% normal once you understand operation. On Mon, Nov 26, 2018 at 5:32 PM Ken Myers wrote: > Just tried RC5 - Same problem. > > On Tue, 27 Nov 2018 at 09:15, Ken Myers wrote: > >> Hi >> I have been successfully been using RSC3 then changing to RSC4 there was >> no decode of waterfall content. FT8 mode. >> >> 2 installations - >> 1 MSSurface Win10 up to date, 2 radios (FT991a & FTdx3000 both USB) - >> non decode, >> 2 HP Allinone with FT897/Singnalink. - non decode, >> (both setups using HRD (up to date) for CAT control) >> >> For all: >> 1.9.1 works great >> 2.0 RC3 works great >> 2.0 RC4 good waterfall (therefore good audio present) - NO decode. >> >> uninstalling/reinstalling forward and back through versions gives the >> same result. >> >> i have concluded: >> 1 I must be holding my mouth wrong - OR >> 2 I have missed a new setting. >> 3 When I have been looking/testing RC4, no RC4 (77 bit) transmissions. >> Not sure here as I have been especially been looking top band. >> >> 2 probably!! >> >> In the words of the rich young ruler to Jesus - "What must I do to be >> saved?" >> >> The other problem is occasionally the FT897 does not let go of transmit >> after sending. >> Solved by closing WSJTX. Have tried 2 soundcards, Signalink and >> Rigblaster P, - persistent intermittent. MIGHT be my aging FT897 - >> haven't ruled that out. >> >> Great Program Great work. >> >> Thanks >> -- >> Cheers >> >> Ken Myers >> VK4GC >> >> Sunnybank Hills QLD AUS >> M +61 414 487 004 >> >> > > -- > Cheers > > Ken Myers > > Sunnybank Hills QLD AUS > M +61 414 487 004 > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] strategy for release of version 2.0 of WSJT-X
Also remove v1.9.1 from the downloads as well. Will create a "black marked" for the file, but at least the casual downloader will get the current file. On Sat, Nov 24, 2018 at 7:12 AM Mike wrote: > I agree, we need to start telling people. May I make a suggestion as to > the WSJT-X web page itself? I just went there to check before I spoke. > There is no "BIG RED NOTICE" there to warn people that the new version is > not going to decode FT8 from the older version. Wouldn't it be a good idea > to but a big red notice right at the top - right now - so people hunting > for an answer will see it as the *first thing they notice* if they go > there - at the TOP - in *BOLD*? > > Mike N5INP > > On Fri, Nov 23, 2018 at 11:46 PM Peter Sumner wrote: > >> Hello to the Dev team, >> with the impeding release of version 2.0 'gold' in December I have >> started to put threads into some of the more active local forums in VK to >> alert those who may not know that a new MAJOR update of WSJT-X is coming >> and that FT8 and MSK modes will be changing. I have requested that each >> reader of the thread to consult the version 2.0 document on the WSTJ web >> site to stay in touch with developing news. >> >> I would guess the DEV team are busy with the finishing touches and tests >> of version 2.0 and may not have a fully formed release strategy in mind but >> thought I should ask is there more that can be done by us non dev Ham's on >> your behalf to help out ? >> >> Regards, >> Peter, vk5pj >> ___ >> 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 > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Follow up on Log QSO error
In checking the wsjtx_log.adi file, I found the state was saved wrongly. WB3LGC FM29 FT8 +08 +15 20181120 221515 20181120 221615 20m 14.076130 WB5JJJ EM35kg 80 LJ81HM -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Log QSO anomoly
I just logged a contact in Delaware. If you notice the lower right Rcvd box has unknown information. The 2nd part LJ81HM showed up as the state when sent to HRD LB. This looks like a grid square, but if so, it's in the middle of the ocean off Mogadishu, Somalia. Pirates location for sure. Did not see anything unusual on his QRZ page except that his QRZ grid square is a storage rental facility in an industrial area of the city. Never seen this before. -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] RTTY RU Test - Contest Log
Overall perfect operation. No crashes with WSJTx or JTAlert combination with HRD LB logged from WSTJx directly. Win 10 Pro w/plenty of SSD RAM and system memory. All current versions. Problems: 1) Time logged as local not UTC (already noted by many others) 2) Entry sequence (left column) 1-9 ok, but what should be 10 was just a 1 and the column can not be adjust to show additional digits. -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Font size vs dialog box sizes.
I have set my font to a larger size for easy readability without my reader glasses. This causes all text boxes to lose a lot of their information as the font is larger but the text box is not dynamic and does not change size. The one area that does bug me is the dropdown for frequency selection, it cuts off critical numbers after the decimal point, but does show the band. So it will be displaying all choices like "14.07...(20m)" which is helpful, but somewhat useless as I have to figure out which one of several identical listings is the one I want. Yes, they are in order, but it's still trial and error to see which one the radio displays. This is especially confusing when I've loaded the saved and updated DXPedition setup configuration with multiple frequencies in each band and I don't remember what they are. However, sometimes this dropdown box is wide enough to see the full information which is really nice, but mostly it's smaller. -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Erratic decodes in RC4
Over the time I've used RC4, I've noticed a recurring theme. This is sporadic at best, but still happens a couple times a day. I'm calling CQ above 2000 on the band. I see a signal in the WF on my Tx frequency that should decode, but it doesn't. My first thought is that it's someone not running RC4 or has Always Transmit 77bit unchecked in an earlier RC. So I send 77-Bit TX/RX in Tx5 (free text) box. Still the station keeps on trying (I assume). I move up or down 50 or 100 and I'm followed by this same station. Now, I know he's copying me or trying to QRM me since he can't copy me. Then one of two things happen, 1) the station does a JTAlert chat box saying he's running RC4 as well or, 2) all of the sudden he shows up in my Rx Freq side saying he's running RC4 and the contact continues. It's like his response to my CQ might be corrupted on his end, but when he goes free text, that sets things right. I change nothing on my end except for the frequency change. His signal pattern in the WF has not changed much at all, but why was I not decoding him and then all at once, things are OK? It's not the path as the WF, even though not perfect by a long shot, shows a similar signal pattern from him all along. Our reports were in -12 as received by me and -09 as received on his end. -- George Cotton, WB5JJJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] 5 minute mouse timeout
This 5 minute mouse timeout is not a problem for me (most of the time) as my WD timer is usually set for 5 minutes. But occasionally the mouse timer hits before the WD timer does and no alert is issued our sounded (JTA setting). With all the negative comments about this timer, and no comments one way or the other from the developers on retaining this useless feature or removing it, I'm left in a quandary as to their thought processes on this to begin with. I for one, see no need in it at all. If somebody wants to run without human intervention for and hour at full power and blow out their PA's, that's their problem, not mine. I know of no other feature on any radio or software that protects us from ourselves, except for the band edge lockouts on many newer radios, which saved my bacon many times when chasing DX as a Technician or General class licensee. George -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] New release RC-4 not decoding anything.
If you read the release notes, support for legacy FT8 has been removed. Only 77bit operation is available. On Tue, Nov 13, 2018 at 9:36 AM Bob via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > Just downloaded the new Beta RC4 and no signals are showing decoded. > Answer? > > > > Bob > > AA7CT > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RC3 & Strong Signals
The other option was perhaps it was a true FT8 signal, but running the legacy mode, maybe overmodulated or excessive hum on their transmission. Try unchecking the receive ONLY 77bit and see if you can decode it then. If you can, don't forget to uncheck the ALWAYS transmit 77bit to work them. On Tue, Oct 23, 2018 at 11:05 AM Jordan Sherer wrote: > Interesting. Could be, but I don't think this instance was exactly this. > FT8Call (JS8Call now) doesn't use an every other tx cycle when calling CQ, > so it seems that this was indeed an FT8 signal. They called every other > cycle for about 2 minutes on the same frequency until I was able to decode > the responding station to their CQs (which I couldn't decode). > > Any other thoughts? Any other reason for a really strong station to fail > decoding? > > Best, > Jordan > > On Tue, Oct 23, 2018 at 11:50 AM WB5JJJ wrote: > >> If you are on the 77bit frequencies on 40 or 20, then the most likely >> culprit is you are seeing the non-conforming FT8Call (now JS8Call) >> signals. They are totally incompatible with the standard FT8 either old >> school or RC3 77bit. I see these all the time and are usually very strong >> when compared to the rest of the real FT8 signals. Also, the decode you >> were able to see was probably a real FT8 encoded signal at about the same >> frequency. >> >> Most likely there is nothing wrong with your setup, it's just rogue >> signals that "look" like FT8. In reality, there are very few 77bit signals >> right now as the bulk of the testing has already been carried out some >> weeks back. Exception is MSK144, which is only 77bit in RC3, I still see >> some users there early in the morning on 6m. And remember the DXPeditions >> are still using v1.9.1 as RC3 is a beta and not in wide usage as of yet. >> >> On Tue, Oct 23, 2018 at 10:12 AM Jordan Sherer >> wrote: >> >>> Hi Folks, >>> >>> Testing out RC3 today and 77-bit FT8 I found some very strong signals in >>> the band that were troublesome to decode. >>> >>> Now, I'm fairly fluent in FT8 and I keep my Elecraft station configured >>> properly. NTP for time synchronization (ony a few ms divergence), AGC Off, >>> RF gain/ATTN set so the in-app audio meter sits at ~30dB. >>> >>> Most signals are perfect. But this one today eluded me. It decoded once >>> at +10dB with a time delta less than 0.3. Then, subsequent cycles did not >>> decode. >>> >>> It seems like the decoder might have been getting a bad sync. Curious if >>> this might just be a case of that station over-driving their transmit audio >>> or if something else might be afoul? Perhaps there's drift involved here >>> too? I've seen this happen with strong signals on 1.9 as well, so I know >>> its not entirely related to RC3, but do know that 2.0 changed the >>> synchronization scheme so am curious to dig in deeper. >>> >>> I know y'all are busy so what's likely the best way to diagnose this >>> myself to help y'all out? >>> >>> Best, >>> Jordan >>> ___ >>> wsjt-devel mailing list >>> wsjt-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >>> >> >> >> -- >> George Cotton, WB5JJJ >> PO Box 1025 >> Russellville, AR 72811 >> >> 479.968.7737 Home >> 479.857.7737 Cell >> >> DMR K5CS (Local Repeater) - 310515, CC1, TS2 >> DMR Arkansas - 3105 >> >> 4 >> ___ >> 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 > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RC3 & Strong Signals
If you are on the 77bit frequencies on 40 or 20, then the most likely culprit is you are seeing the non-conforming FT8Call (now JS8Call) signals. They are totally incompatible with the standard FT8 either old school or RC3 77bit. I see these all the time and are usually very strong when compared to the rest of the real FT8 signals. Also, the decode you were able to see was probably a real FT8 encoded signal at about the same frequency. Most likely there is nothing wrong with your setup, it's just rogue signals that "look" like FT8. In reality, there are very few 77bit signals right now as the bulk of the testing has already been carried out some weeks back. Exception is MSK144, which is only 77bit in RC3, I still see some users there early in the morning on 6m. And remember the DXPeditions are still using v1.9.1 as RC3 is a beta and not in wide usage as of yet. On Tue, Oct 23, 2018 at 10:12 AM Jordan Sherer wrote: > Hi Folks, > > Testing out RC3 today and 77-bit FT8 I found some very strong signals in > the band that were troublesome to decode. > > Now, I'm fairly fluent in FT8 and I keep my Elecraft station configured > properly. NTP for time synchronization (ony a few ms divergence), AGC Off, > RF gain/ATTN set so the in-app audio meter sits at ~30dB. > > Most signals are perfect. But this one today eluded me. It decoded once > at +10dB with a time delta less than 0.3. Then, subsequent cycles did not > decode. > > It seems like the decoder might have been getting a bad sync. Curious if > this might just be a case of that station over-driving their transmit audio > or if something else might be afoul? Perhaps there's drift involved here > too? I've seen this happen with strong signals on 1.9 as well, so I know > its not entirely related to RC3, but do know that 2.0 changed the > synchronization scheme so am curious to dig in deeper. > > I know y'all are busy so what's likely the best way to diagnose this > myself to help y'all out? > > Best, > Jordan > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] No decode rc3 in FH on x64 Ubuntu 18.10
As stated by Joe Taylor, RC3 is NOT designed for DXP until the full release. It uses 77 bit and none of the DXP are using that mode since it is still in beta. VP6D specifically stated NOT to use RC3 and use v1.9.1 for this exact reason. On Tue, Oct 23, 2018 at 4:39 AM David Spoelstra wrote: > Ubuntu 18.10 > WSJT-X V2.0.0-rc3 > > In normal mode everything decodes ok. Switch to FH mode and there is no > decode even though waterfall shows strong signals. Switch back to normal > mode and everything decodes. > > Switch back to 1.9.1 and both modes decode ok. > > Switch back to rc3 and same decode problem in FH mode. > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VP6D on wrong time slot
If you try CTL-E or Shift-E, it will toggle the time slot even when grayed out. This should have been removed in F/H mode, but was not. On Mon, Oct 22, 2018 at 10:12 AM jarmo wrote: > Mon, 22 Oct 2018 09:36:05 -0500 > "Ted Gisske" kirjoitti: > > > He is using V1.9.1. You are likely using V2.0 RCx. Reinstall V1.9.1 > > and all will be well. > > I have 1.9.1 and impossible work hound, tx even.. > > Jarmo, oh1mrr > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VP6D on wrong time slot
Those options should have been removed for the F/H mode. Perhaps, they triggered this by accident. On Mon, Oct 22, 2018 at 9:41 AM Sam W2JDB via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > Ctrl-E - Turns on TX Even > Shift-E - Turns off TX Even > > good luck > > Sam W2JDB > > > > -Original Message- > From: WB5JJJ > To: wsjt-devel > Sent: Mon, Oct 22, 2018 10:32 am > Subject: Re: [wsjt-devel] VP6D on wrong time slot > > Yes, you are correct. > > I think what we are seeing is a glitch in the software on their end, which > was an occurrence even I experienced where I was not able to UNCHECK the > EVEN box as it was grayed out. Restarting WSJTx solved the problem and > it's never returned. But how are so many guys transmitting on the EVEN > time slot? They must be using v1.8.x which, if I remember, would allow > choosing time slot. What's funny, is all the guys transmitting on ODD with > no chance of being heard by VP6D. > > Time to move on to another frequency and let this run it's course. > > On Mon, Oct 22, 2018 at 9:22 AM Jay Hainline wrote: > > I am seeing this too George as of 1415z on 14090. I remember where this > could happened in an earlier version but thought it had been fixed. > > Jay KA9CFD > > > > Sent from my U.S.Cellular© Smartphone > > Original message > From: WB5JJJ > Date: 10/22/18 09:01 (GMT-06:00) > To: wsjt-devel@lists.sourceforge.net > Subject: [wsjt-devel] VP6D on wrong time slot > > Right now on 20m (14.090) VP6D is transmitting on the ODD time slot. > About half of the callers are on EVEN and the others on ODD. How is the > happening? He's using DX Fox according to what I'm seeing from him. > > -- > George Cotton, WB5JJJ > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > > -- > George Cotton, WB5JJJ > PO Box 1025 > Russellville, AR 72811 > > 479.968.7737 Home > 479.857.7737 Cell > > DMR K5CS (Local Repeater) - 310515, CC1, TS2 > DMR Arkansas - 3105 > > 4 > ___ > 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 > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VP6D on wrong time slot
Nope. They said they were using v1.9.1 and that's what I'm running. The option to transmit on EVEN is grayed out since v1.9.0 rc2 ( I just reloaded all previous versions to see ). In v1.8.x, the F/H option is not there yet. I see there is a code that allows CTRL-E and SHIFT-E to switch time slots. This should have been disabled in F/H mode. On Mon, Oct 22, 2018 at 9:39 AM Ted Gisske wrote: > He is using V1.9.1. You are likely using V2.0 RCx. Reinstall V1.9.1 and > all will be well. > > 73, > > Ted > > K9IMM > > > > *From:* WB5JJJ [mailto:wb5...@gmail.com] > *Sent:* Monday, October 22, 2018 9:02 AM > *To:* wsjt-devel@lists.sourceforge.net > *Subject:* [wsjt-devel] VP6D on wrong time slot > > > > Right now on 20m (14.090) VP6D is transmitting on the ODD time slot. > About half of the callers are on EVEN and the others on ODD. How is the > happening? He's using DX Fox according to what I'm seeing from him. > > > -- > > George Cotton, WB5JJJ > > > > > > > <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> > > Virus-free. www.avg.com > <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
