Re: [wsjt-devel] Button sizes not correct
Mark / Laurie This effect is not present in Linux Mint. (1920x1080 screen, font Noto Sans Bold Italic 12) However, looking at the code in the Qt development environment this clipping effect can be seen. These buttons all have a minimum width of 32 and the default font size is 12. Otherwise the size policy for these buttons is the same as for the Tx 1-6 buttons. With a button width of 32 the max font size for no clipping is 9. With font size of 12 the minimum button width is ~48. You can change the font size in Settings | General | Font. Reducing it will help, but it will affect the entire window and I suspect you may have tried that already and found it unacceptable. It might also be worthwhile checking that the font you have selected actually exists on your machine and is not being substituted, which can cause weird effects. You could just run the app with a larger width. At some point the buttons will expand. As a last resort, there is an easy code fix for this. Just go into the mainWindow.ui and change houndButton | minimumSize | Width. Setting it to 0 (on all six buttons) allows the application to scale the button width in accordance with the combined sizing policies. However changing just the houndButton from 32 to 48 is sufficient and doesn't introduce any other sizing effects. Recalculate the md5 checksum. Recompile and voila. HTH Regards Rick (GM4JIB) On 31/08/2023 23:15, Mark Galbraith via wsjt-devel wrote: Not sure what’s happening here, but my guess would be that the screen resolution may be off, but I was seeing this on other computers as well. My computer is a Microsoft Surfacebook 2, with a screen resolution of 3240 x 2160. I was also seeing the same thing on my other computer with a 32” ultra widescreen resolution of 2560 x 1080. I’m also seeing this on v2.6.1 and v2.7.0-rc2. Is there a setting I need to adjust, or is this something that requires a program change to fix? 73 -.. . / -- .- .-. -.- / -. --... -.-- -.. DE MARK N7YD ___ 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] Unable to create shared memory segment in 2.7.0-rc1
Hi
I have the same situation.
Running Linux Mint 20.3 and wsjtx2.7.0-rc1 built from source.
The Optimising Decoder FFT dialog only pops up (intentionally) if the
fail to mem_qmap dialog is on the screen for some time although it's
less than the 15 seconds stated in the code comments, more like 1.5. So
not related to the issue.
Dismissing both dialogs allows wsjtx to run normally (as far as I can
see) on linux.
I did a bit of diagnostics. The code is at widgets | mainwindow.cpp
lines 472 -47 9. I used the default config and a clone of the default
config both unchanged.
//AttachorcreateamemorysegmenttobesharedwithQMAP.
intmemSize=4096;
if(!mem_qmap.attach()){
if(!mem_qmap.create(memSize)){
MessageBox::information_message(this,
"Unabletocreatesharedmemorysegmentmem_qmap.");
}
}
This code runs when wsjtx is first instantiated, before any app windows
appear. It creates the shared memory segment and links the app to it OK.
Normal operation proceeds. When the Op changes to another configuration
the code is run again and _wsjtx is still attached_.
(mem_qmap.isAttached returns true). Consequently mem_qmap.attach fails
and the code tries to create the shared memory segment again which also
fails because the previous shared memory segment and key still exist.
Hence the dialog
Should mem_qmap and it's key have been disposed of when wsjtx terminated
as the configuration was changed? Perhaps it would be better to test
whether the shared memory segment exists and is attached or not rather
than just attempting to attach it.
My reading of the situation is that both dialogs can safely be dismissed
and wsjtx will run OK since the shared memory segment is attached.
73s
Rick (GM4JIB)
On 01/06/2023 17:14, Erik Icket via wsjt-devel wrote:
Dear developers,
When switching to a predefined configuration, an information dialog pops up
with the message 'Unable to create shared memory segment mem-qmap',
followed by another modal message a few secs later 'Optimizing FFTs for your
CPU. Please be patient ...'
After that, the program does not respond anymore. Aborting the program and
restarting brings back the original config.
73's Erik
ON4PB
___
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] wsjtx-2.7.0-rc1 and hamlib
I'm experimenting with rigctld in vb.net Will this work for windows also: For rigctld add this "-v -Z >log.txt 2>&1" ?? 73 Rick N2AMG -Original Message- From: Black Michael via wsjt-devel Sent: Tuesday, May 23, 2023 10:34 AM To: WSJT software development Cc: Black Michael ; Josh Rovero Subject: Re: [wsjt-devel] wsjtx-2.7.0-rc1 and hamlib So I need a debug file from rigtctld and from WSJT_X. For rigctld add this "-v -Z >log.txt 2>&1" And for WSJT-X please place this file as described below https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0 C:\Users\[username]\AppData\Local\WSJT-X The WSJT-X_Rigcontrol.log file will be in the same location For Linux put it in ~/.config The WSJT-X_Rigcontrol.log file will be here: ~/.local/share/WSJT-X For MacOS put it in /Users/[username]/Library/Preferences Restart WSJT-X and duplicate the problem. Shut down WSJT-X Then send me the WSJT-X_RigControl.log file Mike W9MDB On Tuesday, May 23, 2023 at 08:11:02 AM CDT, Josh Rovero via wsjt-devel wrote: Since installing 2.7.0-rc1 (built from source), I have observed the following behavior on Fedora Core 38, 64-bit, hamlib 4.5.4. Yaesu FT-950, tty/USB0 for serial, and Signalink USB sound card. PTT method is CAT. Everything worked normally in FC37 and wsjtx-2.6.1. "Test CAT" does not turn green, but WSPR band-hopping works. Changing frequency at the radio results in changing frequency in the WSJT-X window. So there is serial communication "Test PTT" works. So there is serial communication.. "Enable TX" button is reset (unset) on each band hopping band change, whether or not "tune" is selected in the WSPR band-hopping schedule. "Enable TX" followed by "Tune" transmits as expected, but the second press of "Tune" to stop tuning turns off both "Tune" and "Enable Tx" buttons. Output of rigctl seems pretty normal with the same serial parameters. -- P.J. "Josh" Rovero http://www.roveroresearch.org Ham Radio: KK1D ___ 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 -- This email has been checked for viruses by Avast antivirus software. www.avast.com ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] YBDXPI Contest Performance
N1MM is using the TCP connection using the DXLabs API. When the TCP connection is lost it is because WSJT has crashed and the TCP connection has been broken. The radio TCP connection has been tested with the Debug file that Mike has provided but no results of an issue is found in the log file. 73 Rick N2AMG -Original Message- From: Joe Taylor via wsjt-devel Sent: Monday, October 24, 2022 12:15 PM To: WSJT software development Cc: Joe Taylor Subject: Re: [wsjt-devel] YBDXPI Contest Performance Hi Dennis, Thanks for your helpful report. I guess it's not yet perfectly clear whether using the hamlib4.dll from v2.5.4 helped, or whether you were just lucky for the last 7 hours of the contest. In any event, it seems that there must be some kind of negotiation issue between N1MM+ and WSJT-X. Somehow we need to isolate this problem and see what can be done to make the negotiation more forgiving of delays, or whatever, and not simply shut down the channel. -- Joe, K1JT On 10/24/2022 8:54 AM, Dennis W1UE via wsjt-devel wrote: > I started the contest using 2.6.0RC4. I operate with WSJT in > conjunction with N1MM+, using the DX Lab Suite Commander to a > K30/Mini, through a Remote Rig unit to the remote transmitting site. > I used SO1V mode for this > contest- no SO2R. The combination worked perfectly for about 6 hours, > then the WSJT-X for EW1 just "disappeared" with the TCP error from > N1MM+. I opened Task Manager, killed the orphan JT process, and was > back on the air- for maybe 15 minutes, when it happened again. This > time I Restarted the computer, started up again, and within 30 minutes > it happened again. > > Remembering a conversation i had with Joe K1jt a while ago, I then > substituted the 2.5.4 hamlib4.dll for the 2.6.0 dll, restarted the > computer, and started operating again. It lasted about 30 minutes, > and the same error again. I deleted the orphan JT9 process and > started up again. That was the end of the errors- it never happened > again for the next 7 hours of operation. > > In his write-up on 3830, Ty, K3MM, also tried 2.6.0rc4 to start the > contest. Within an hour of the start, he had his WSJT-X EW2 window > just disappear. Rather than fight it, he went back to 2.5.4 and had > no more "disappearances" the rest of the contest (about 27 hours). > > I typically use 100w or less in contests, but did use 800-1000w for > this contest. I saw no difference in "disappearances" between the two > power categories. > > Thanks to all for their work in supporting WSJT-X. Its truly a great > program! > > Dennis w1UE > > > > > > ___ > 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] WSJT-x Stopping
Sorry I am coming to the party a little late in response to these emails.. Spent the last 2 weeks camped along the Moose River in the middle Adirondack Mtns of NY Trout Fishing.(My 2nd love after radio.) It is truly amazing how the fish population has returned over the last 15 years after being almost wiped out totally by acid rain. In N1MM we use same TCP connection as DXLabs does using the DXLabs Radio API. For Radio #1 we use TCP port 52002 and UDP port 2237 For Radio #2 we use TCP port 52004 and UDP port 2239 When setting up the connection for Radio#2 we have the user setup in the second instance of WSJTX to set the Network Server window to be 127.0.0.1:52004 so that the correct settings will be used. I along with Mike have had Dennis run the log output for the radio config and each time when WSJT goes away nothing special is written into that log. The error report and the Radio TCP Error window are produced because the TCP connection from WSJTX has been dropped. This is just the warning to the user that something has happened. I personally have not experienced this issue as I am only setup here to run SO1R so I am only using one instance at all times. I'm not sure what other information you might need but will answer anything sent my way. 73 Rick N2AMG ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-2.6.0-rc2
Hi Jarmo, I compiled from sources too. Worked OK for me Check your install. Rick (GM4JIB) On 23/07/2022 08:15, jarmo via wsjt-devel wrote: Don't know, if anyone else have this, but compiled wsjtx from wsjtx-2.6.0-rc2.tgz. Still, when starting wsjtx I get wsjtx-2.6.0-rc1??? What I'm missing??? Jarmo, oh1mrr ___ 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-devel Digest, Vol 94, Issue 28
-Original Message- From: wsjt-devel-requ...@lists.sourceforge.net [mailto:wsjt-devel-requ...@lists.sourceforge.net] Sent: Tuesday, December 14, 2021 12:13 To: wsjt-devel@lists.sourceforge.net Subject: wsjt-devel Digest, Vol 94, Issue 28 Send wsjt-devel mailing list submissions to wsjt-devel@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/wsjt-devel or, via email, send a message with subject or body 'help' to wsjt-devel-requ...@lists.sourceforge.net You can reach the person managing the list at wsjt-devel-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than "Re: Contents of wsjt-devel digest..." Today's Topics: 1. Re: Again problems with ic7300/rigctld/wsjtx (Black Michael) 2. Re: Again problems with ic7300/rigctld/wsjtx (Kari Sillanm?ki) -- Message: 1 Date: Tue, 14 Dec 2021 16:11:15 + (UTC) From: Black Michael To: Kari Sillanm?ki via wsjt-devel Subject: Re: [wsjt-devel] Again problems with ic7300/rigctld/wsjtx Message-ID: <532903903.1060202.1639498275...@mail.yahoo.com> Content-Type: text/plain; charset="utf-8" Get the latest hamlib from here...IC-7300 behavior (and other Icoms) should all be good now. https://github.com/Hamlib/Hamlib.git Mike W9MDB On Tuesday, December 14, 2021, 10:09:11 AM CST, Kari Sillanm?ki via wsjt-devel wrote: Hi, I did some tests as well... On 14.12.2021 12.19, Saku via wsjt-devel wrote: > Today I upgraded Fedora 34 to version 35. I'm still at "Ubuntu 18.04.6 LTS" > As expected the self compiled wsjtx did not start any more. Mine does ;) > So I run my "doall.sh" script that: > >? ?- pulls Hamlib from >? ?? [remote "origin"] >? ?? ?url = https://github.com/Hamlib/Hamlib.git >? ?- compiles and installs it >? ?? ?[saku@hamtpad .git]$ rigctld --version >? ?? ?rigctl Hamlib 4.5~git ti joulu 14 05:12:29 2021 + SHA=16cf19 I pulled hamlib from git://git.code.sf.net/u/bsomervi/ and compiled. The resulting rigctld vesion is: rigctl Hamlib 4.4~git to marras 25 22:02:50 2021 + SHA=7349a0 > >? ?- pulls wsjtx from >? ?? [remote "origin"] >? ?? ?url = https://git.code.sf.net/p/wsjt/wsjtx >? ?- compiles and installs it >? ?? ?Wsjtx version 2.5.2 I downloaded the snapshot commit 69f9ec from SourceForge and compiled it. The resulting WSJT-X version is 2.5.3. >? ?Rig is icom ic7300. So is mine. >? ?rigctld is "pre started" with crontab script: >? ?? ?/usr/local/bin/rigctld?? -m 3073 -r /dev/icom7300 -t 4532 -s 19200? > -C auto_power_on=0 --vfo?? & Tested starting "./rigctld-wsjtx -r /dev/ttyUSB0 -m 3073 -s 19200" > It seems that again ic7300 is broken with latest hamlib source. With my setup above nearly everything works OK when using Split=Fake-it. Split=Rig still has the old problem where mode is not set to USB-D if WFO-B is not on USB-D already. 73's de Kari, oh2gqc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- next part -- An HTML attachment was scrubbed... -- Message: 2 Date: Tue, 14 Dec 2021 20:12:26 +0200 From: Kari Sillanm?ki To: Black Michael via wsjt-devel Subject: Re: [wsjt-devel] Again problems with ic7300/rigctld/wsjtx Message-ID: <3c534566-9325-80bf-b2cd-ef3cd91fb...@gmail.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" Hi Mike, On 14.12.2021 18.11, Black Michael via wsjt-devel wrote: > Get the latest hamlib from here...IC-7300 behavior (and other Icoms) > should all be good now. No change. Everything else seems to be working except the VFO-B mode is not set to USB-D when Rig=Split and VFO-B's mode is not USB-D initially. 'Kari, oh2gqc Here's the log: rigctld.c(579) Startup: ./rigctld -r /dev/ttyUSB0 -m 3073 -s 19200 -v rigctld Hamlib 4.5~git ti joulu 14 15:06:29 2021 + SHA=7ea9eb Report bugs to rig_check_rig_caps: p1=0x7f0f13864d60, p2=0x7f0f1386b2e0, rig_model=0x7f0f13864d60, macro_name=0x7f0f1386b2e0 rig.c(356):rig_check_rig_caps return(0) initrigs4_icom: _init called rig_register called rig_register: rig_register (3055) register.c(225):rig_register return(0) rig_register called rig_register: rig_register (3085) register.c(225):rig_register return(0) rig_register called rig_register: rig_register (3009) register.c(225):rig_register return(0) rig_register called rig_register: rig_register (3010) register.c(225):rig_register return(0) rig_register called rig_register: rig_register (3011) register.c(225):rig_register return(0) rig_register called rig_register: rig_register (3013) register.c(225):rig_register return(0) rig_register called rig_register: rig_register (3014) register.c(225):rig_register return(0) rig_register called rig_register: rig_register (3015)
Re: [wsjt-devel] WSJT-X and Windows CMAKE Versions > 3.14.4
Guys, please take this offline. You’re trying to litigate a disagreement via email, and failing. Just stop. If it’s important, try talking on the phone, skype, facetime, or zoom. Thanks. Rick KK6WHJ *** > On Aug 22, 2020, at 4:35 PM, Stephen VK3SIR wrote: > > Bill, > > Instead you choose to write long rants about the incompetence of the WSJT-X > development team.. > > Long “rants” … People also said that of Washington, Adams, Franklin and > Jefferson’s speeches and dispatches (and I am not in their league)…. > > I asked for assistance time and time again on the issue that prompted this > threads. > > The patches you have are V 3.17 – and that has been around for some time ago. > Instead I and those working on supporting and learning have apparently been > left to “hang out to dry”. The old expression “give ’em enough rope and they > will hang themselves” … Yet this is not a visionary approach in a community > that is craving learning and advancement. > > I completely REJECT that near slander that you have put forward that I am > questioning Core Developers Team Members’ Competence. > ‘ ...___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Wide Graph during TX
My bad. I was thinking of the Wide Graph window. What is the purpose of Wide Graph progress? I don't think I have it enabled. Rick From: Andy Durbin Sent: Sunday, June 7, 2020 12:51 PM To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] Wide Graph during TX "The Wide Graph pauses because nothing is received for processing." No, you are mistaken. Wide Graph progress has nothing to do with signal reception. Secondly, my TS-590S provides feedback of the audio modulation. It is not based on RF. Some rigs, e.g some Flex, do provide TX monitoring at the RF level. However, it doesn't matter how the rig implements TX monitoring. The fact remains that many rigs do provide the ability to monitor the TX signal while transmitting and this signal can usually be provided on the same audio channel that provides WSJT-X the audio signal while receiving. Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Wide Graph during TX
Andy, Before starting a transmission, the Transmit / Receive relay kicks in and disables the receiver section and enables the transmitter section. That protects the receiver from the 1 or more watts of output generated by the transmitter. The receiver section is generally designed for microwatts of input. The Wide Graph pauses because nothing is received for processing. I've thought about using a second radio but it would have to be miles away from my QTH. 73, Rick WK1P From: Andy Durbin Sent: Sunday, June 7, 2020 9:42 AM To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] Wide Graph during TX Wide Graph has always been frozen during TX for JT-65, JT-9, and JT65. It's been that way since the earliest versions of WSJT-X, but why? If Wide Graph continued to run during TX it would/could allow monitoring of TX audio for rigs that have that capability. Perhaps if people could see the shit they are sometimes transmitting they would do something to fix their signals. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] unsubscribe
On Tue, May 5, 2020 at 10:24 AM Joe Taylor wrote: > Hi all, > > This message is to let you know of some important WSJT-X development > plans. We plan to make a first candidate release of WSJT-X 2.2.0 next > Monday, May 10. > > WSJT-X 2.2.0-rc1 will be a beta-quality release candidate providing a > number of new features and capabilities. These include: > >- Improvements to the decoders for five modes: > >FT4: Corrected bugs that prevented AP decoding and/or multi-pass >decoding in some circumstances. The algorithm for AP >decoding has been improved and extended. > >FT8: Decoding is now spread over three intervals. The first >starts at t = 11.8 s into an Rx sequence and typically yields >around 85% of the possible decodes for the sequence. You >therefore see most decodes much earlier than before. A second >processing step starts at 13.5 s, and the final one at 14.7 s. >Overall decoding yield on crowded bands is improved by 10% or >more. (Systems with receive latency greater than 0.2 s will see >smaller improvements, but will still see many decodes earlier >than before.) > >JT4: Formatting and display of Averaged and Deep Search decodes >has been cleaned up and made consistent with other modes. JT4 >remains the digital mode of choice for EME and other extreme >weak-signal work on microwave bands. > >JT65: Many improvements for Averaged and Deep Search decodes and >their display to the user. These improvements are particularly >important for EME on VHF and UHF bands. > >WSPR: Significant improvements have been made to the WSPR >decoder's sensitivity, its ability to cope with many signals in >a crowded sub-band, and its rate of undetected false decodes. >We now use up to three decoding passes. Passes 1 and 2 use >noncoherent demodulation of single symbols and allow for >frequency drifts up to ±4 Hz in a transmission. Pass 3 assumes >no drift and does coherent block detection of up to three >symbols. It also applies bit-by-bit normalization of the >single-symbol bit metrics, a technique that has proven helpful >for signals corrupted by artifacts of the subtraction of >stronger signals and also for LF/MF signals heavily contaminated >by lightning transients. With these improvements the number of >decodes in a crowded WSPR sub-band typically increases by 10 to >15%. > > - New format for "EU VHF Contest" Tx2 and Tx3 messages > >When "EU VHF Contest" is selected, the Tx2 and Tx3 messages >(those conveying signal report, serial number, and 6-character >locator) now use hashcodes for both callsigns. This change is >NOT backward compatible with earlier versions of _WSJT-X_, so >all users of EU VHF Contest messages should be sure to upgrade >to versiion 2.2.0. > > - Accessibility > >Keyboard shortcuts have been added as an aid to accessibility: >Alt+R sets Tx4 message to RR73, Ctrl+R sets it to RRR. > >As an aid for partial color-blindness, the "inverted goal posts" >marking Rx frequency on the Wide Graph's frequency scale are now >rendered in a darker shade of green. > > - Minor enhancements and bug fixes > >"Save None" now writes no .wav files to disk, even temporarily. > >An explicit entry for "WW Digi Contest" has been added to >"Special operating activities" on the "Settings | Advanced" tab. > >Contest mode FT4 now always uses RR73 for the Tx4 message. > >The Status bar now displays the number of decodes found in the >most recent Rx sequence. > > Release candidate WSJT-X 2.2.0-rc1 will be available for beta-testing > for one month starting on May 10, 2020. We currently plan a General > Availability (GA) release of WSJT-X 2.2.0 on June 1, 2020. > > For those looking even farther ahead: We are well along in the > development of two new modes designed for the LF and MF bands. One > mode is for WSPR-like activity and one for making 2-way QSOs. Both > use Low-density Parity Check (LDPC) codes, 4-GFSK modulation, and > two-minute T/R sequences. The QSO mode reaches threshold SNR > sensitivity around -31 dB on the AWGN channel, and the WSPR-like mode > better than -32 dB. > > With best wishes, > > -- Joe, K1JT, Steve, K9AN, and 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] unsubscribe
please unsubscribe me from this email list.
On Thu, Apr 23, 2020 at 3:10 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:
> Don't have any more details than the error message of invalid
> configuration.
>
> I've seen it on my system too once in a while but never repeatable of
> course.
>
> I think it may have to do with WSJT-X opening a 2nd connection without
> closing the 1st connection as I saw some of that in recent debug logs.
>
> I do notice that do_start does not ensure that the rig is closed
>
> int HamlibTransceiver::do_start ()
> {
> TRACE_CAT ("HamlibTransceiver",
> QString::fromLatin1 (rig_->caps->mfg_name).trimmed ()
> << QString::fromLatin1 (rig_->caps->model_name).trimmed ());
>
> error_check (rig_open (rig_.data ()), tr ("opening connection to rig"));
>
>
> Mike
>
>
>
>
>
>
>
> On Thursday, April 23, 2020, 02:40:48 PM CDT, Bill Somerville <
> g4...@classdesign.com> wrote:
>
>
> On 23/04/2020 20:15, Black Michael via wsjt-devel wrote:
> > And sometimes doing retry will give a configuration error too which
> > requires a restart of WSJT-X...also undesirable.
> >
> > Mike
>
> Hi Mike,
>
> that's the first report of that, can you supply more details please?
>
>
> 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
>
Virus-free.
www.avast.com
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Crash report
Hi Jari, That’s useful information. Especially if it can be reproduced. It says that the DLL named Qt5Core caused an EXCEPTION_ACCESS_VIOLATION. (Exception Code: c005) Simply put, it tried to access a memory address it did not have permission to read or write. But that’s not helpful. The crash should have created a memory dump file, .DMP, that could be used to debug it. If I remember, there should be a line of text with a path to the dump file. The crash occurred in the Qt libary code so it might be a known bug. It also could be caused by wsjtx passing in an invalid pointer to the Qt5Core code. Makes me wish I had my Windows Mobile debugging setup. Rick/WK1P From: Jari A Sent: Friday, August 16, 2019 5:36:07 AM To: WSJT software development Subject: [wsjt-devel] Crash report Win 7 pro 64 bit; WSJT-X started and being MSK144, - 50.280 Change manually qrg on radio to 50.313 and got FT8 signal to waterfall. Changing mode to FT8 from MSK144, cause crash. Shut WSJT-X and restart, got again signal from rx, change mode to FT8 and crash. Wait till rx signal end, restart WSJT-X, change mode to FT8 and all was fine. Problem signature: Problem Event Name: APPCRASH Application Name: wsjtx.exe Application Version: 0.0.0.0 Application Timestamp: 5d2a83ec Fault Module Name: Qt5Core.dll Fault Module Version: 5.12.4.0 Fault Module Timestamp: 5d0204a7 Exception Code: c005 Exception Offset: 001e8507 OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1035 Additional Information 1: 486f Additional Information 2: 486f0dae17f2ae9969ab02f5f36da8e9 Additional Information 3: a1db Additional Information 4: a1dbf885406e2ee4382d67208ad5cb6f Regards, :Jari / oh2fqv ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Can WSTJ-X tell me if I am running V2.1.0 32-bit vs 64-bit?
Is there a WSJT-X menu, window, or command which will show if the currently running WSJT-X is the 32-bit executable or the 64-bit executable? ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT Audio Input Loss
Bill, Disabling the USB power down on timeout was a good idea but no luck in solving the issue. I don't use a screen saver because I sometimes run my C++ code for days. Windows System for Linux (WSL) built HamLib but not WSJT-X. I'm going to try to spend some time getting it to build wsjtx. 73, Rick, WK1P From: Bill Somerville Sent: Monday, July 8, 2019 6:39 PM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] WSJT Audio Input Loss On 08/07/2019 21:57, Rick Drexel wrote: I started up WSJT-X on 10 meters this morning and expected to find it running when I got back home. After all, there was no activity and therefore nothing to decode. Nope, Wide Graph was frozen just as if I'd been monitoring a contest. WSJT-X was the only app running all day. I started it at 1000 UTC and it quit around 1135 UTC. It failed after 1.5 hours. Another random data point. Which doesn't rule out the Race Condition possibility given the 4 core/8 thread CPU it's running on. Just curious. How does WSJT-X make use of an Internet browser??? Hi Rick, have you disabled power saving options on your USB hubs? Some monitor drivers cause issues with audio streams when they go into screen save mode. WSJT-X doesn't use any web browser although if you request the online help to open it will tell the operating system to open the relevant URL however it feels it should, which is normally by passing it to the default web browser, open the application if necessary. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT Audio Input Loss
Band conditions being what they are, I started up WSJT-X on 10 meters this morning and expected to find it running when I got back home. After all, there was no activity and therefore nothing to decode. Nope, Wide Graph was frozen just as if I'd been monitoring a contest. WSJT-X was the only app running all day. I started it at 1000 UTC and it quit around 1135 UTC. It failed after 1.5 hours. Another random data point. Which doesn't rule out the Race Condition possibility given the 4 core/8 thread CPU it's running on. Just curious. How does WSJT-X make use of an Internet browser??? Rick From: Black Michael Sent: Saturday, July 6, 2019 5:57 PM To: WSJT software development; pe...@ni6e.com; Rick Drexel Subject: Re: [wsjt-devel] WSJT Audio Input Loss We've heard a few people say IE has caused audio problems. But...for the main testwhat happens if you run no browser at all? And how often does it fail? de Mike W9MDB On Saturday, July 6, 2019, 04:48:26 PM CDT, Rick Drexel wrote: The rig is an Icom IC-7100 connected by a USB cable directly to a Windows 10 64-bit desktop machine with 32 GB RAM. No sound card needed but I do have to check Settings to make sure WSJT-X Audio Tab hasn’t changed after a forced restart. I use Firefox or IE to open PskReporter to see what’s been reported by WSJT-X during the monitoring period. Rick WK1P From: Black Michael via wsjt-devel Sent: Saturday, July 6, 2019 3:35:43 PM To: pe...@ni6e.com; WSJT software development Cc: Black Michael Subject: Re: [wsjt-devel] WSJT Audio Input Loss What web browser do you use? There aren't a lot of these report so it doesn't seem like this is a common problem otherwise we'd hear more about it5. There has to be something in common. So what does your audio path look like? Rig, sound card, USB Hub?, PC model. de Mike W9MDB On Saturday, July 6, 2019, 02:32:27 PM CDT, Rick Drexel wrote: Your observations match those I have seen for about a year. I've tried to find a common set of circumstances that always cause the failure but have had no luck. I use WSJT-X in FT8 receive mode and PSKREPORTER to check band performance over a long time period. After a random amount of time, WSJT-X come to a halt. Specifically the Wide Graph Display and the Band Activity Display stop updating. The UTC in the Wide Graph Display no longer matches the UTC in the bottom left portion of the Main window. There is no correlation between the activity on the band and the time it takes to hang. Rarely does it not hang. As a software developer this has all the hallmarks of a race condition failure. Two (or more) threads update a shared resource without using a LOCK, UPDATE, UNLOCK sequence. During a thread context swap one of the threads reads the value, loses control to another thread that updates the value, then the first thread gets scheduled and writes back its stale value. The result is undefined behavior. Most of the time there is no conflict. Even under a heavy load. Then it fails unexpectedly. This makes it extremely difficult to debug. To recover I have to exit out of WSJT-X and restart it. This might not be the root cause but I would put it high on my list of the usual suspects. 73, Rick WK1P From: Peter Putnam Sent: Wednesday, July 3, 2019 3:06 PM To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] WSJT Audio Input Loss Greetings, I have been using WSJT-X quite successfully for several years during June VHF Contests. I experienced a failure of the WSJT program to accept received audio input after several hours of proper operation during the recent Field Day exercise. I'll provide a brief outline and reply with more detail, should it be needed. My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The WSJT-X software version is 2.0.1 7ddcb7. My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX" program that interfaces various applications that wish to receive the audio stream. WSJT accepts the stream and displays results on the Wide Graph and a small audio signal-strength window. Activity proceeded normally for the first three hours of Field Day, until both the Wide Graph and the audio signal-strength stopped showing any incoming audio. I can't offer any help on what might have caused the problem. It was abrupt and seemingly unrelated to any other system actions. I am unable to reproduce the problem. Several operators spent several hours speculating about what a solution might be. Program restarts and computer re-boots (time-tested favorite of generations) changed nothing. The only useful clue was that the DAX audio output stream was present and could be re-directed to Fldigi, but not to WSJT-X. I was able to restore operation for a brief period by stopping WSJT, renaming WSJT.ini and restarting WSJT. That fix lasted for a
Re: [wsjt-devel] WSJT Audio Input Loss
The rig is an Icom IC-7100 connected by a USB cable directly to a Windows 10 64-bit desktop machine with 32 GB RAM. No sound card needed but I do have to check Settings to make sure WSJT-X Audio Tab hasn’t changed after a forced restart. I use Firefox or IE to open PskReporter to see what’s been reported by WSJT-X during the monitoring period. Rick WK1P From: Black Michael via wsjt-devel Sent: Saturday, July 6, 2019 3:35:43 PM To: pe...@ni6e.com; WSJT software development Cc: Black Michael Subject: Re: [wsjt-devel] WSJT Audio Input Loss What web browser do you use? There aren't a lot of these report so it doesn't seem like this is a common problem otherwise we'd hear more about it5. There has to be something in common. So what does your audio path look like? Rig, sound card, USB Hub?, PC model. de Mike W9MDB On Saturday, July 6, 2019, 02:32:27 PM CDT, Rick Drexel wrote: Your observations match those I have seen for about a year. I've tried to find a common set of circumstances that always cause the failure but have had no luck. I use WSJT-X in FT8 receive mode and PSKREPORTER to check band performance over a long time period. After a random amount of time, WSJT-X come to a halt. Specifically the Wide Graph Display and the Band Activity Display stop updating. The UTC in the Wide Graph Display no longer matches the UTC in the bottom left portion of the Main window. There is no correlation between the activity on the band and the time it takes to hang. Rarely does it not hang. As a software developer this has all the hallmarks of a race condition failure. Two (or more) threads update a shared resource without using a LOCK, UPDATE, UNLOCK sequence. During a thread context swap one of the threads reads the value, loses control to another thread that updates the value, then the first thread gets scheduled and writes back its stale value. The result is undefined behavior. Most of the time there is no conflict. Even under a heavy load. Then it fails unexpectedly. This makes it extremely difficult to debug. To recover I have to exit out of WSJT-X and restart it. This might not be the root cause but I would put it high on my list of the usual suspects. 73, Rick WK1P From: Peter Putnam Sent: Wednesday, July 3, 2019 3:06 PM To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] WSJT Audio Input Loss Greetings, I have been using WSJT-X quite successfully for several years during June VHF Contests. I experienced a failure of the WSJT program to accept received audio input after several hours of proper operation during the recent Field Day exercise. I'll provide a brief outline and reply with more detail, should it be needed. My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The WSJT-X software version is 2.0.1 7ddcb7. My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX" program that interfaces various applications that wish to receive the audio stream. WSJT accepts the stream and displays results on the Wide Graph and a small audio signal-strength window. Activity proceeded normally for the first three hours of Field Day, until both the Wide Graph and the audio signal-strength stopped showing any incoming audio. I can't offer any help on what might have caused the problem. It was abrupt and seemingly unrelated to any other system actions. I am unable to reproduce the problem. Several operators spent several hours speculating about what a solution might be. Program restarts and computer re-boots (time-tested favorite of generations) changed nothing. The only useful clue was that the DAX audio output stream was present and could be re-directed to Fldigi, but not to WSJT-X. I was able to restore operation for a brief period by stopping WSJT, renaming WSJT.ini and restarting WSJT. That fix lasted for a half hour. Repeating the procedure provided operation for the rest of Field Day. The two .ini files that were renamed are available for your inspection, along with the one that continued to function. Any suggestions you can offer to prevent a recurrence would be greatly appreciated. Regards, Peter NI6E ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7Cc8a88765c47b45e54e0208d6ffea13fc%7C84df9e7fe9f640afb435%7C1%7C0%7C63698175354267sdata=QIhhN8eBXU7WkgMKIK4WOGh%2BO2Zt6d3mRyQ5qFFV%2FGM%3Dreserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-devel=02%7C01%7C%7C028b11a517d4493b190808d702496ee4%7C84df9e7fe9f640afb435%7C1%7C0%7C636980386726425860=6R6u7cKiy5Rvb2kB4AM3H0Kqd5bTbc8AM0DazKU%2B5KI%3D=0> ___ wsjt-de
Re: [wsjt-devel] WSJT Audio Input Loss
Your observations match those I have seen for about a year. I've tried to find a common set of circumstances that always cause the failure but have had no luck. I use WSJT-X in FT8 receive mode and PSKREPORTER to check band performance over a long time period. After a random amount of time, WSJT-X come to a halt. Specifically the Wide Graph Display and the Band Activity Display stop updating. The UTC in the Wide Graph Display no longer matches the UTC in the bottom left portion of the Main window. There is no correlation between the activity on the band and the time it takes to hang. Rarely does it not hang. As a software developer this has all the hallmarks of a race condition failure. Two (or more) threads update a shared resource without using a LOCK, UPDATE, UNLOCK sequence. During a thread context swap one of the threads reads the value, loses control to another thread that updates the value, then the first thread gets scheduled and writes back its stale value. The result is undefined behavior. Most of the time there is no conflict. Even under a heavy load. Then it fails unexpectedly. This makes it extremely difficult to debug. To recover I have to exit out of WSJT-X and restart it. This might not be the root cause but I would put it high on my list of the usual suspects. 73, Rick WK1P From: Peter Putnam Sent: Wednesday, July 3, 2019 3:06 PM To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] WSJT Audio Input Loss Greetings, I have been using WSJT-X quite successfully for several years during June VHF Contests. I experienced a failure of the WSJT program to accept received audio input after several hours of proper operation during the recent Field Day exercise. I'll provide a brief outline and reply with more detail, should it be needed. My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The WSJT-X software version is 2.0.1 7ddcb7. My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX" program that interfaces various applications that wish to receive the audio stream. WSJT accepts the stream and displays results on the Wide Graph and a small audio signal-strength window. Activity proceeded normally for the first three hours of Field Day, until both the Wide Graph and the audio signal-strength stopped showing any incoming audio. I can't offer any help on what might have caused the problem. It was abrupt and seemingly unrelated to any other system actions. I am unable to reproduce the problem. Several operators spent several hours speculating about what a solution might be. Program restarts and computer re-boots (time-tested favorite of generations) changed nothing. The only useful clue was that the DAX audio output stream was present and could be re-directed to Fldigi, but not to WSJT-X. I was able to restore operation for a brief period by stopping WSJT, renaming WSJT.ini and restarting WSJT. That fix lasted for a half hour. Repeating the procedure provided operation for the rest of Field Day. The two .ini files that were renamed are available for your inspection, along with the one that continued to function. Any suggestions you can offer to prevent a recurrence would be greatly appreciated. Regards, Peter NI6E ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7Cc8a88765c47b45e54e0208d6ffea13fc%7C84df9e7fe9f640afb435%7C1%7C0%7C63698175354267sdata=QIhhN8eBXU7WkgMKIK4WOGh%2BO2Zt6d3mRyQ5qFFV%2FGM%3Dreserved=0 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X v2.0.0 Program Crash
Good morning all, Worked a station this morning and after receiving his 73, I went back to calling CQ. As normal, the Tx 5 window was still populated with his call: - W3OA NM3G 73 - I saw him sending additional 73 and RR73 messages, so I added TU to the end of the TX 5 message. Yes, I can count ... mostly. When I sent the revised message - W3OA NM3G 73 TU - The program shut down completely. Restarted just fine, but the abnormal termination was quite the surprise. I repeated this several times to ensure I captured the entire chain of events ... and adding that 14th character apparently created an unexpected condition. The radio did remain in transmit mode (easily fixed by manually switching back to RX), and WSJT-X restarted immediately without any fuss (no other instances were running). Here's the snippet of my all.txt: 40630 -3 4.1 1500 & NM3G W3OA R+06 190112_140645 Transmitting 50.26 MHz MSK144: W3OA NM3G RRR 140700 -7 2.9 1500 & NM3G W3OA 73 140700 -6 10.1 1500 & NM3G W3OA 73 190112_140715 Transmitting 50.26 MHz MSK144: W3OA NM3G 73 140730 -7 5.9 1500 & NM3G W3OA RR73 140730 -6 7.6 1500 & NM3G W3OA RR73 190112_140745 Transmitting 50.26 MHz MSK144: W3OA NM3G 73 190112_140815 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 190112_140845 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 190112_140915 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 140930 -6 10.0 1505 & NM3G W3OA RR73 140930 -3 10.9 1504 & NM3G W3OA RR73 190112_140945 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 190112_140945 Transmitting 50.26 MHz MSK144: W3OA NM3G 73 190112_141015 Transmitting 50.26 MHz MSK144: W3OA NM3G 73 190112_141115 Transmitting 50.26 MHz FT8: W3OA NM3G 73 190112_141145 Transmitting 50.26 MHz MSK144: W3OA NM3G 73 190112_141215 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 190112_141215 Transmitting 50.26 MHz MSK144: W3OA NM3G 73 190112_141245 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 190112_141330 Transmitting 50.26 MHz MSK144: W3OA NM3G 73 190112_141400 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 190112_141400 Transmitting 50.26 MHz MSK144: W3OA NM3G 73 190112_141430 Transmitting 50.26 MHz MSK144: W3OA NM3G 73 2019-01-12 14:14 50.26 MHz MSK144 So, I'll learn to count to 13 in the future to prevent this corner case ... just wanted to share what I found. Thanks and 73, Rick NM3G ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] strange non-qso
How does one unsubscribe from this list? I thought I had followed the right procedure, but I am still getting emails. Thanks! Rick, WW1ME Sent via the Samsung Galaxy S7, an AT 4G LTE smartphone Original message From: Dan Malcolm Date: 12/25/18 2:24 PM (GMT-05:00) To: 'WSJT software development' Subject: Re: [wsjt-devel] strange non-qso I understand Serge, but one way to find out is to see if you are in his logbook via QRZ. I agree it's difficult just looking at the QSO text, and I appreciate Bill's comment. I also agree with Bill that logging the QSO makes the most sense. __ Dan - K4SHQ -Original Message- From: F6BHK [mailto:f6...@f6bhk.org] Sent: Tuesday, December 25, 2018 10:29 AM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] strange non-qso Dan Thank you for your answer, however my questioning is on the software side, not on the call itself. With the following messages from WSJT-X, I feel - I can be wrong, but - I feel that I cannot decide whether the QSO is completed or not completed. See, the last message I read from the 4X station is not clear as to whether this message is for me or for someone else. 73 Serge On 25/12/2018 17:14, Dan Malcolm wrote: > A search of QRZ found 4X19HNY and there is a pointer to their live log > on that page. > > __ > Dan - K4SHQ > > -Original Message- > From: F6BHK [mailto:f6...@f6bhk.org] > Sent: Tuesday, December 25, 2018 9:30 AM > To: WSJT software development > Subject: [wsjt-devel] strange non-qso > > Merry Xmas to all! > > The following QSO seems to me "strange": > > 151630 -17 0.4 1694 ~ CQ 4X19HNY > 151646 Tx 1694 ~ <4X19HNY> F6BHK > 151715 Tx 1694 ~ <4X19HNY> F6BHK > 151730 -17 0.4 1694 ~ F6BHK <4X19HNY> -22 > 151745 Tx 1694 ~ <4X19HNY> F6BHK R-17 > 151815 Tx 1694 ~ <4X19HNY> F6BHK R-17 > 151800 -22 0.4 1693 ~ F6BHK <4X19HNY> -22 > 151816 Tx 1694 ~ <4X19HNY> F6BHK R-22 > 151845 Tx 1694 ~ <4X19HNY> F6BHK R-22 > 151900 -19 0.3 1693 ~ <...> 4X19HNY RR73 > 151915 -16 1.1 1694 ~ <4X19HNY> SQ2BNM -15 > > in the sense I am not able to be sure 4X19HNY has got my report. I > would have expected <...> being instead. > > 73 > > Serge > > -- 73, de Serge F6BHK, ex-VR2LL, G5BHT, FM5GC PUY SAINT MARTIN, 26 DROME, FRANCE JN24LP ___ 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-devel Digest, Vol 58, Issue 306
Good afternoon all, A rather simplistic solution might be to have your location (by callsign) identified in the city.dat file as "CHECK THE GRID". This would work for anyone that is roving (whether in the local geographical area, or across the Pacific). 73, Rick NM3G ... It was funny -- I recently worked someone on 160 who told me that he "soiled his adult diaper when he heard my AH6 call sign."? That pretty well sums up the call issue. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] What is this in WSJTX 2.0
Normal to see that. See the released manual, it will tell you all about it. > On December 16, 2018 at 3:18 PM rgui...@na5q.com wrote: > > > 230900 -13 -03 439 <…> WA5CHX > > > > Received several times tonight IN RX and TX Window. All else seems to be > working ok. > > > > Roland NA5Q > > ___ > 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] File not found SSL/TLS WSJT-X 2.0 release.
Seen several messages on the list on this and how to fix it. Well I run windows 10 and have downloaded the recommended file a couple times and installed it and I still get the message ever time I run 2.0. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X V2.0.0 Startup Item
Good evening all, I have noticed that the Windows installation of WSJT-X V2.0.0 does not have F Tol set to 200 out of the gate. I've seen several complaints that "It doesn't work". Of course, once F Tol is set to 200, it DOES work. Just a suggestion ... is it possible to set the default F Tol to 200 in the next release? (Insert comments about reading the manual, and so on). Thanks and 73 Rick ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Frequency issue when changing configurations, WSJT-X V2.0.0 GA
Good afternoon Bill, Happy to help out. Please let me know what I can do. 73 Rick thanks for the update. Glad you have a workaround. I do need to fix the original issue and I will get back to you soon if you don't mind helping out? ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-devel Digest, Vol 58, Issue 169
Good afternoon Bill, Fake It works correctly, since VFO B isn't at all involved. That will work. Not sure why I didn't try that! Thanks and 73, Rick Hi Rick, sounds like there is defect somewhere in that. What option do you have checked for "Settings->Radio->Split Operating"? ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-devel Digest, Vol 58, Issue 169
Good afternoon Bill, I've used both NONE and RIG. Did not try Fake It ... will try that now. 73, Rick Hi Rick, sounds like there is defect somewhere in that. What option do you have checked for "Settings->Radio->Split Operating"? ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Frequency issue when changing configurations WSJT-X V2.0.0 GA
Good afternoon all, When switching from FT8 to MSK144, neither VFO A or VFO B change frequency. If I go into the Settings tab, and then close (without any action), VFO A changes from 50.313 to 50.260. With or without Split enabled, VFO B remains on 50.313. When manually changing modes from MSK144 to FT8, both VFO A and VFO B switch to 50.313. When switching modes back, VFO A changes to 50.260, while VFO B remains on 50.313. This occurs whether I have split on or off on either or both modes. Shutting the program down and restarting does not set the correct frequency for MSK144 ... so the only way to ensure I'm not on the incorrect frequency is to manually change the frequency for VFO A and VFO B. I have eliminated all but region 2 frequencies in the frequencies tab, cloned the configurations, and deleted the original configuration (configurations were built under 1.9.1 or earlier). I deleted all configurations and restarted with fresh configurations. If I am in the MSK144 configuration and reselect the mode, VFO A resets to 50.260, while VFO B remains at 50.313. Rig is IC-9100, CAT enabled. Am I missing something? Thanks and 73, Rick ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] General issue : The RRR / 73 "loop"
Just did a test with RC4 in RTTY RU mode... -- 'Disable Tx after sending 73 is unchecked. Clicked 'Next' radio button for Tx5. Clicked 'Enable Tx' WSJT-X sent one Tx5 sequence, and left radio button and 'Enable Tx' unchanged At start of next Tx5 sequence, WSJT-X selected 'Next' radio button for 'Tx6' and turned off 'Enable Tx'. -- I expected WSJT-X to continue sending Tx5 until I click 'Enable Tx' to signal stop xmit at end of sequence, or 5 minute 'dead man' timer... Rick - K5GZR Date: Tue, 20 Nov 2018 08:53:13 -0800 From: Al Pawlowski To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] General issue : The RRR / 73 "loop" Message-ID: <78d58804-7dd7-435f-8756-e00d3f272...@almont.com> Content-Type: text/plain; charset="us-ascii" I forgot about that box and was reminded about it some weeks ago. In any case, it does not seem to work for me in rc3, and I think previously in rc2 - the box is unchecked yet tx is still disabled when I send a 73. Al Pawlowski, K6AVP ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] crash on attempt to log
Bill, Start WSJT-X with RU mode enabled. Then without doing anything else, click on Log QSO, then OK. WSJT-X aborts. no error messages. Rick - K5GZR ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Attempt to write log in RTTY contest mode causes WSJT-X to terminate
Trying to participate in RTTY RU test tonight with RC4 on Win 10 pro. Was able to complete a QSO normally. But when I clicked OK on the Log QSO popup, there was a pause, then WSJT-X terminated with no warning or error message. Same happens in Field Day mode. Works fine when not in RU or FD mode. Rick - K5GZR ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X RC4 Observations - Day One - One Hour Timeout
Good evening Bill, Thanks for the quick response. I've previously set all power saving settings to off or none. Thanks for the suggestion to check though. In addition, V1.9.1, RC2 and RC3 did not have this observed issue with the one-hour timeout ... which is why it surprised me and caught my attention. An addendum to the no-mouse-movement ... with the watchdog timer disabled and Auto Sequence NOT checked, the no-mouse timer does not disable TX, but with Auto Sequence checked, and watchdog timer disabled, it does. A suggestion regarding no-mouse timeout; please consider the following: If Operating Frequency is less than 50.000 MHz, OR CAT is not enabled, then enable mouse timer. This gives three operating conditions: 1. If you don't run CAT frequency control, you have the mouse timer 2. If you run CAT and you are below 6 meters, you have the mouse timer 3. If you run CAT and you are on 6 meters or above, you do NOT have the mouse timer. Again, the rational is that on 6 meters and above, ANY signal is a good signal, and most of the VHF/UHF operators are actively seeking contacts. I can understand the desire to reduce QRM on the HF bands by someone forgetting about leaving TX enabled and walking away. Tying the mouse timer to Enable VHF/UHFMicrowave features will only encourage operators to check this box and go back to HF, defeating the purpose. If the operator is not running CAT, then you must assume they may not be on VHF/UHF, and thus the mouse timer is activated. ANY operation below 6 meters means the mouse timer is activated ... which I believe is probably the intent of this feature. If you are on 6 meters or above, and you aren't running CAT ... you get the mouse timer as explained above (and yes, I _AM_ encouraging everyone to use CAT for correct frequency reporting). Again, this is from my 6 meter operating procedures. I realize a large portion of WSJT-X operation is now on HF ... and I think that's a good thing. I just ask you to weigh the VHF/UHF operations in your decision tree with regard to features. Again, keep up the great work. 73, Rick NM3G SNIP ===> ... what I get is a 1 hour timer that drops TX Enable with no notification window. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X RC4 Observations - Day One
Good evening all, I have found, like others, that the Auto Sequence check box is not persistent on closing and restarting the application. It is also not persistent when changing configuration settings. It is always OFF when starting the application, or when switching from MSK144 to FT8, and then back to MSK144. The five-minute mouse timer is a bad choice for VHF/UHF operations. I am responsible for my station's operation. I'm on 6 meters probing for openings (Es, Meteor Scatter, Aircraft Scatter, Tropo, and maybe some day TEP). I have set my watch dog timer to "Disabled" and found that I don't get the 5-minute mouse timer action ... what I get is a 1 hour timer that drops TX Enable with no notification window. While I'm sure there had been a lot of developer discussion regarding these timers, I'm not certain anyone has given the VHF/UHF operator any input or consideration in this matter. I have attached the appropriate portion of my all.txt file for your use. The last line is when I manually re-enabled my transmitter. I've read the release notes for RC4 and the transmit disable is discussed only as a bullet point. No mention of the 1-hour disable. I'll continue to wring thing out and report. Apparently not enough VHF/UHF operators have been vocal with their observations, or are mixed with the HF operator responses (lot of VHF/UHF guys also run HF, for what it's worth). Thanks for the efforts, and please continue. 73, Rick NM3G BTW ... The server at physics.princeton.edu is taking too long to respond. Think it got hammered by folks downloading RC4. ALL.TXT Fragment starts here = 181113_212700 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_212730 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_212800 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_212830 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_212900 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_212930 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213000 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213030 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213100 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213130 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213200 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213230 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213300 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213330 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213400 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213430 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213500 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213530 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213600 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213630 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213700 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213730 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213800 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213830 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213900 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_213930 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214000 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214030 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214100 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214130 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214200 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214230 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214300 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214330 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214400 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214430 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214500 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214530 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214600 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214630 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214700 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214730 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214800 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214830 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214900 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_214930 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_215000 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_215030 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_215100 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_215130 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_215200 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_215230 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_215300 Transmitting 50.26 MHz MSK144: CQ NM3G EM96 181113_215330 Transmitting 50.26 MHz MSK144: CQ
[wsjt-devel] RC3 HamLib Error
Good evening all, I have been chasing down an intermittent problem with RC3 as detailed below: Rig = IC9100 PTT = CAT Mode = MSK144 Win7 Pro Version 6.1 (Build 7601: Service Pack 1) Installed Physical Memory (RAM 16.0 GB Processor Intel(R) Core(TM) i7-6700K CPU @ 4.00 GHz, 4001 MHz, 4 Core(s), 8 Logical Processor(s) Symptoms: When calling CQ, program would randomly stop keying the radio (but the display would still show that it was commanding transmit. Then, when I went to shut down the application and restart, it would refuse to restart due to a stale lock file. wsjtx.exe*32 was still a running process (as was jt9.exe), and task manager would shut down jt9.exe but not wsjt.exe*32. I had to reboot the computer to clear the lock file and restart the application. Tonight, the application immediately brought up the Rig Control Error. While all the settings are unchanged, it will not respond to the Test CAT button, and the details on the Rig Control Error show: Hamlib error: IO error while opening connection to rig. The only way to recover from this error is to load WSJT-X v 1.9.1. All of the radio settings remain the same, but the communications between the application and the radio now work. Installed rc3 over top of 1.9.1 again, and now I have (for now) the ability to continue running RC3 and finding some additional corner cases. I have no additional applications loaded ... I did load one software package, and when I noticed this issue, uninstalled it and cleaned the registry, and then reinstalled RC3; but no change. While I suspect an issue with Hamlib, I can't be certain. If you need additional information, please let me know. As a postscript, while I was writing this message, the application (wsjtx v2.0 rc3) has once again locked up. I now have to reboot to clear the lock file again, as attempts to reinstall fail (can't terminate the wsjtx.exe*32 process, and installation fails with a multitude of QT*dll errors. 73, Rick NM3G ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] FT8 RU test - comments
That was fun! Worked 20 stations in 7 countries during the hour. Did not call CQ. all but 2 Qs were in response to other station's CQs. Running 100 watts to a dipole hanging from a pine tree at 30 feet. As noted in the doc, the contest log function is a work in progress, but. I was able to use the dupe function in N3FJP's RTTY Roundup contest program with the help of JTAlert. But a 'current contest' dupe function in WSJT-X would be high on my request list. Had some confusion when I was called by stations when I was not calling CQ. It is going to take some practice to be able to select the correct message for a reply in that situation. During the busiest part of the hour I was decoding as many as 30 stations per sequence, and many sequences with 15 stations calling CQ. But the segment was never overloaded with callers. One more comment about the 'work in progress' contest log function. Entries are added to the contest log only if it is open, and. I 'lost' several contest log entries (they were in the normal log files, so not really 'lost') because I went into settings to make a small change and when I returned from settings, WSJT-X closed the contest log window. and I worked several stations before I realized that the close had occurred. Thanks again to the development team! Rick - K5GZR ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X v 2.0.0-rc3 8a1244 - MSK144 CW ID
Good morning all, Running rc3 on MSK144 and have CW ID set to 0. No CW ID sent (which is correct), but transmitter is left keyed for the duration of the CW ID period every 10 minutes. Non-critical issue that can create confusion as to whether the application locked up in transmit mode. This action is contrary to the expectation of no CW ID set, no CW ID transmit time on. System information: Windows 7 Professional, SP1 (64-Bit OS); Intel i7-600K @4.00 GHz; 16.0 GB RAM. 73, Rick NM3G ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Red 'indicators' not showing on main window
Joe, Thanks for the quick response. I did leave out one fact, which is: In MSK144 mode, selection of ARRL Field Day or ARRL RTTY Roundup causes the message texts to change to the formats appropriate to those contests.(But it does not show the red 'flag' message.) So my note was really to report that WSJT-X is not consistent in its handling of the ARRL Field Day and ARRL RTTY Roundup in MSK144 mode. If it doesn't make sense to select those options, it doesn't make sense to allow them to be selected. If they are allowed, they should be handled consistently. Thanks, Rick - K5GZR --- Message: 2 Date: Thu, 18 Oct 2018 18:47:02 -0400 From: Joe Taylor To: WSJT software development Subject: Re: [wsjt-devel] Red 'indicators' not showing on main window in MSK144 mode when ARRL Field Day or ARRL RTTY Roundup selected Message-ID: Content-Type: text/plain; charset=windows-1252; format=flowed On 10/18/2018 6:36 PM, K5GZR - Rick wrote: > In FT8 mode, selection of any one of the ?Special operating activity? > options causes a red background ?flag? to appear on the WSJT-X main > window just to the right of the large date and time box, indicating > which activity has been selected. > > However, > > In MSK144 mode, the red background ?flag? appears only for NA VHF and > EU VHF, and not for ARRL Field Day and ARRL RTTY Roundup.?? If those > are valid ?special operating activities? for MSK144 mode, then the ?flags? > should be shown.? If the activities are not valid for MSK144 then they > should be either greyed out or omitted on the Settings-Advanced window. From the Quick-Start Guide to WSJT-X 2.0, top of page 10: "MSK144 cannot be used with the ARRL Field Day or ARRL RTTY Roundup message formats." This restriction is, of course, by design. MSK144 is forbidden at HF, so useless in the RTTY Roundup; and why would anyone want to use MSK144 for Field Day? -- 73, Joe, K1JT ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Red 'indicators' not showing on main window in MSK144 mode when ARRL Field Day or ARRL RTTY Roundup selected
In FT8 mode, selection of any one of the 'Special operating activity' options causes a red background 'flag' to appear on the WSJT-X main window just to the right of the large date and time box, indicating which activity has been selected. However, In MSK144 mode, the red background 'flag' appears only for NA VHF and EU VHF, and not for ARRL Field Day and ARRL RTTY Roundup. If those are valid 'special operating activities' for MSK144 mode, then the 'flags' should be shown. If the activities are not valid for MSK144 then they should be either greyed out or omitted on the Settings-Advanced window. Thanks, Rick - K5GZR ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] SSL handshake failed error - resolved
After downloading and installing "Win32 OpenSSL v1.0.2p Light", I no longer receive the 'SSL handshake failed' error, and the .CSV file was successfully downloaded into the WSJT-X log directory. Thanks Bill, Rick - K5GZR ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] RC3 LoTW file download SSL handshake failed error - libeay32.dll location
I'm receiving the SSL handshake failed error. where libeay32.dll shows the following: C:\Program files (x86)\Intel\iCLS Client\libeay32.dll C:\Program files\Intel\iCLS Client\libeay32.dll Windows 10 pro, Version 1803, build 17134.345 Rick - K5GZR ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] K5GZR test results
Good results in the RU test last night: 14 QSOs during the test hour, 9 QSOs prior to the test hour, including 6 QSOs with DX stations in 5 continents, all on 40 meters with 100 watts to 80/40 dipole at 35 feet. Almost all QSOs were responses to other station's CQs, with a couple of CQs from me thrown in to test. Lots of signals - decoding anywhere from 10 to 30 calls per sequence during the test. I used JTAlert to easily select stations which I had not worked before who were calling CQ. I have 'NO-OP'ed the color highlighting in WSJT by setting the highlight colors to white. Too many colors for my impaired color-vision to deal with. Noticed a DX station where I was not decoding a sequence number in their report. Contest-specific Sent and Rcvd reports were not being posted into the Log QSO popup window, so I entered them manually, and JTAlert posted them as expected into ACLog. The Cabrillo file has the contest-specific Sent and Rcvd reports. Noticed a couple of stations sending CQ RU RU call, instead of CQ RU call. I didn't make any 'split' calls. Always responded to CQ on the caller's DF. Inquiry/request/suggestion - Is there a way to make the auto-sequencer end a QSO with TX5 selected as 'next' instead of switching to TX6? Several times I needed to re-send TX5, but the sequencer had already selected TX6 as next and turned off Enable Tx. There is only a short amount of time to realize that the QSO partner is still sending TX4 and I need to send another TX5 and then select TX5 as 'next' then click Enable Tx. Lots of chances to make a mistake instead of just clicking Enable Tx. As has been suggested before, and responded to, it would be nice to be able to disable the 'New xxx' and 'LoTW' color highlighting and just keep the original 'CQ in message', 'my call in message', and 'transmitted message' highlighting. Thanks to the development team and last night's test participants. Rick - K5GZR ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] alerts and colors
Users should have the ability to activate/inactivate each of the alerts, in addition to having the ability to set the color for each of the alerts. Inactivating an alert (instead of the current work-around of changing an alert's color to white) avoids wasting CPU cycles on alerts that are not wanted by the user. Users should also be able to set the relative priority of the alerts based on their individual importance to the user. A priority of zero could be used to specify that an alert is to be inactivated. Thanks, Rick - K5GZR ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Some special operating activity options in MSK144 aren't triggering red indicator box on main window
WSJT-X v2.0.0 rc1 In FT8 mode, selecting any one of the 4 special operating activities causes a suitable color-highlighted message to appear on the WSJT-X main window. However, in MSK144 mode, a color-highlighted message appears only for the NA VHF Contest and EU VHF Contest activities. No color-highlighted message appears on the main window when the ARRL Field Day or ARRL RTTY Roundup activities are selected. Test QSOs using the various MSK144 special operating activities have been completed successfully. Thanks, Rick - K5GZR ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Plans for WSJT-X Version 2.0
Thank you sir. Always nice to see. Great software by a great team. Scotty W7PSK -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X v1.9.1 r8747 Split mode FT8 Observation
Good morning all, I've noticed the last few days some odd signal artifacts on FT8 operations above 1500 Hz, in that I will see a series of equally-spaced, low level, narrow pulses that descends approximately 500 Hz, then observe a proper FT8 transmission. So, I looked at my transceiver and saw that when going into transmit, the software would command VFO-B, VFO-A, VFO-B, then start the audio. I have the rig set for Split, and had Tx delay set to 0.1 seconds. To play it safe, I increased Tx delay to 0.2 seconds, and confirm the VFO is settled on VFO-B before I hear the transmit sequence start. I'm not sure why the VFO cycling is occurring, nor does it bother me. I'm not sure how each radio changes frequency, and whether any radios sweep as indicated above. It might be worthwhile to point out this potential issue, and recommend increasing Tx delay until you are sure the VFO is stable before the tone sequence starts. Thanks and 73, Rick NM3G -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] IC-7700 Serial Over LAN - The untold story (well, it WAS untold)
Good evening John, (BTW, I tried to respond to your posted e-mail address, and the entire internet sneezed. It's a mess I tell you) I used to explain to people that search engines such as Google could offer them some needed information much faster than asking a group of people on a news group. I should start doing that again. Enter the following search term into Google without the square brackets as shown in the next line [ ic-7700 serial over lan ] and then hit enter. My first hit was Icom IC7700 and Digital Modes via LAN <https://www.george-smart.co.uk/radio/icom_ic7700_and_digital_modes_via_lan/> By George Smart M1GEO ... the link is: https://www.george-smart.co.uk/radio/icom_ic7700_and_digital_modes_via_lan/ scroll past the Youtube Links (beware of cat videos), and the third item down is George's settings from the Icom Remote Utility screen. Take some time and read the entire article, and then, if you have questions, you MAY wish to communicate with George, as it appears he's already accomplished the goal you seek. Good luck with your interface quest, and for the snipping impaired, please note I only copied the relevant portion of the digest containing reference material for the answer at hand. 73 and Happy 4th of July Rick NM3G <<<<<< begin massive snipping campaign >>>>>>>> Message: 2 Date: Tue, 3 Jul 2018 12:52:09 -0700 From: "John Zantek" To: "'WSJT software development'" Subject: Re: [wsjt-devel] Icom IC-7700/RS-BA1/WSJT-X Message-ID:<003301d41307$5458edc0$fd0ac940$@zantek.net> Content-Type: text/plain; charset="utf-8" Tnx, Neil, and I agree that there are HW workarounds to accomplish the goal. I?m just still amazed that additional HW would be needed, given that the IC-7700 has a fully functional LAN port and firmware server. I?ve even found some Youtube videos ?claiming? that third party apps like FLDigi, etc., should work via the LAN (UDP 50001-50003) for both CAT and audio, but none have demonstrated it successfully. Quite maddening for a top level rig with built-in RTTY and PSK and manufacturer-supplied networking tools (Remote Utility app) and full remote capability, albeit only with their software. I can?t believe Icom is proprietary with its IP stack, as some say. <<<<<<<< snipping is complete - please return your trays and seat backs in the upright position >>>>>>> -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Icom and Yaesu CAT USB Interface
Good evening John, Please take a look at the article I wrote a while back regarding your own CAT interface for Icom and Yaesu radios: http://www.w4gso.org/wp-content/uploads/2015/01/feedline0408.pdf 73, Rick NM3G (formerly WB3EXR) > Message: 3 > Date: Tue, 3 Jul 2018 07:16:09 -0700 > From: "John Zantek" > To: "'WSJT software development'" > Subject: Re: [wsjt-devel] Icom IC-700/RS-BA1/WSJT-X > Message-ID: <01d412d8$6421a730$2c64f590$@zantek.net> > Content-Type: text/plain; charset="utf-8" > > You would think it?s that simple, but no. Icom?s required CT-17 level-converter, at $139, only works with an RS-232 connection on the PC. USB-9pin converters are evidently not supported. > > > > Very frustrating. This was a top of the line rig not too long ago. Built-in Ethernet. Built-in RTTY and PSK. > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Watchdog remaining time display
WSJT-X v1.9.0-rc4 r8658 - Windows 10 Not sure if this is by design or omission in FT8 hound mode: The WD:#m indicator is not properly displaying the remaining time in the hard-coded 2 minute hound transmit period. Instead, it starts at whatever timeout value the user has set for FT8, then counts down for two minutes. At the end of the hard-coded 2 minute period, Enable Tx is turned off for no apparent reason (unless you have carefully read and understand what is written in the manual, of course), with the WD:#m indicator still showing some non-zero time, and without displaying the red watchdog timeout message at the lower left corner of the window which appears in 'normal FT8' and other modes when a watchdog timeout occurs. Also not sure if this is by design or omission in FT8 'normal' mode: When I enable TX, the WD:#m display gets set to the watchdog timer limit I configured. If I then Halt TX, WSJT-X stops transmitting, but the watchdog timer display continues to count down to zero. Doesn't hurt anything, but it seems like it shouldn't be counting down unless Enable TX is active. Rick - K5GZR -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-devel Digest, Vol 44, Issue 20
Good morning Brendan, Great, glad to help. Enjoyed the chat. 73 Rick NM3G On 10/6/2017 9:27 PM, Brendan O'Neill wrote: Nice talking to you Rick. You had some great ideas and physically adjusting the tension of the 4 tabs that receive the center pin on the cable seems to have made a positive difference. I’ll keep using FT8 and other modes and report back in a few days with my findings… 73, Brendan KM4HRR -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-devel Digest, Vol 44, Issue 20
Good evening Brendan, Connect your IC-7300 into a dummy load and see if the fault occurs. If not, reconnect your antenna. Are you running your internal receive preamp? If so, turn it off, and turn the built-in attenuator ON. If the problem clears, I can walk you through the sequence of events. 73, Rick NM3G --- massive message pruning --- On 06/10/2017 03:19, Brendan O'Neill wrote: I am running RC-2 mostly trying to have with FT-8 and I am except ehn my IC-7300 reports SWR to infinity. This happens at seemingly random intervals at any power level and I am unable to reproduce it using any other mode. Any seen this or have any thoughts about this? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] PSK Reporting Errors
Good afternoon all, I'm seeing an ongoing (and growing) issue where the WSJT-X QRG is set to one band, yet the station is running on another band. An example is stations reporting 6-meter operation, yet are on one of the lower (HF) bands. In all cases, this appears to be caused by inattentive operators with CAT not enabled or not properly functioning. I'm not suggesting the Dev Team fix these operators (but hey, if you can ... ), rather I ask you please consider the following options for inclusion into WSJT-X: 1. Disable PSKReporter spotting when CAT is not enabled/functioning. 2. When CAT is not enabled/functioning, clear the reporting QRG (Set to 00.000 MHz) whenever TX4/TX5 is sent or Enable TX is disabled. This will require the non-CAT operator to reset the QRG after every contact. 3. Set the Reported QRG to the bottom of the indicated band (i.e. 10.100 MHz, 28.000 MHz, 50.000 MHz) REGARDLESS of the QRG window value if CAT is not enabled/functioning, and the operator has chosen to report to PSKReporter anyway. 4. Change reported mode to "No CAT" when CAT is not enabled/functioning and the operator has chosen to report to PSKReporter anyway. Option 1 is bound to generate a lot of grumbling. I don't want to increase the noise level for the Dev Team. Option 2 is bound to generate a lot of grumbling as well, but it will also still allow monitors to set and report an incorrect QRG. Option 3 will cause some confusion, but perhaps be a gentle teaching moment. In addition, should Philip decide to add a "Bottom of the band" filter option, those stations filling the map with incorrect reports are easily removed. Option 4 was intended as a joke, but the more I think about it ... it does solve a LOT of problems, while enabling everyone to continue operating as they have been. Spots will still be there when selecting "ALL Modes", or "No CAT mode), but will be transparent to those using WSJT-X and PSKReporter to study propagation on a mode-by-mode basis. Thanks to Joe and the Dev Team for all the hard work you've put into the continued development of WSJT-X. I certainly appreciate the hard work. Thanks also to Philip Gladstone for sharing his propagation study tools with the world. Humbly submitted for your due consideration. 73 Rick NM3G -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-devel Digest, Vol 43, Issue 12
Good afternoon Bill, Monitor off at startup is NOT checked. Monitor returns to last used frequency is NOT checked. Checking Monitor returns to last used frequency for each configuration does recall the last frequency used, however it does not recall the default frequency for the operating mode selected. Having the default frequency for each mode when changing configurations puts the application in a constant, known configuration ... which is what I understand is the purpose of having different configurations available. I can certainly make the necessary changes to the default configuration when changing modes (as happens during mixed propagation events on 6 meters), but wanted to give the configurations option a good test. As the GUI is (from what I've read and observed) being restarted, one would assume the same behavior from the GUI with regard to the correct frequency selection per mode would be identical from a cold start vs a configuration change. Again, this is not a complaint, just an observation of the application that does not appear to be consistent. For the development team, thanks for all your hard work. I certainly appreciate the challenges involved with WSJT-X. An odd side note, r8040 no longer responds as I previously described. I did not reboot the computer after installing r8040 over r8070 ... so I'm not sure what is going on. 73, Rick NM3G -- Message: 1 Date: Sat, 2 Sep 2017 16:53:41 +0100 From: Bill Somerville <g4...@classdesign.com> To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] Changing configuration will not set correct frequency Message-ID: <84494889-ea24-1541-9909-2952d9a47...@classdesign.com> Content-Type: text/plain; charset=utf-8; format=flowed On 02/09/2017 16:32, Rick wrote: When changing configurations (say from FT8 to MSK144), I've found that the frequency does not change unless you go and reselect the desired mode in the MODE drop down menu. Hi Rick, which of the options "Settings->General->Monitor off at startup" and "Settings->General->Monitor returns to last used frequency" do you have checked? These control what happens at startup which is what effectively happens when you switch to a new configuration. Obviously the settings in the configuration switched to are the pertinent ones. Note that there is a trade off here, either WSJT-X takes control and sets the frequency of your rig on startup or it remains passive and waits for you to select a band or mode. You have control of this behaviour with the above options. 73 Bill G4WJS. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Changing configuration will not set correct frequency
Good morning all, WSJT-X v1.1.8-rc2 r8069 When changing configurations (say from FT8 to MSK144), I've found that the frequency does not change unless you go and reselect the desired mode in the MODE drop down menu. Switching from MSK144, where the frequency tab is set for 50.260 MHz, I click on Configurations, select FT8, select Switch To. The GUI reinitializes, and the frequency is still 50.260 000, and the text is yellow on red background. Go to Mode, FT8 is selected, but reselect it anyway, and then the frequency (and the radio) are now correctly on 50.313 000. This also happens when switching from FT8 to MSK144; in order to get the application to apply the correct frequency, you need to reselect the already selected mode. I had built r8040, and thought this was quietly fixed, as I did not see this problem. I just reloaded r8040, and sure enough, the frequency responds correctly. I just built R8070 and the issue still exists. Thanks and 73, Rick NM3G -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] r7959 - Lookup function possible problem
Windows 10 R7959 Lookup of DX Grid works as designed if I double click on a line in Band Activity.. Finds the call in CALL3.TXT and displays the 6 digit grid. It also works as expected if the call is not in CALL3.TXT.It displays the 4 digit grid from the message in the DX Grid box. However, if I type a call in the DX Call box and click Lookup - it appears that the lookup is not operating as it used to. DX Grid, Az and path length are not being updated with the information from CALL3.TXT. Whatever values are in there from a previous call are left there, unchanged. If I clear out the DX Grid box and then click on Lookup, the information from CALL3.TXT is displayed as expected. Thanks, Rick - K5GZR -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] r7939 - FT8 - double click on msg in Band Activity with my call in it does not copy other station's call to DX Call
>On 25/07/2017 15:41, Bill Somerville wrote: >> On 25/07/2017 15:29, K5GZR - Rick wrote: >>> R7939 on Windows 10. >>> Mode is FT8 >>> My call is K5GZR >>> When I double click on the following msg in Band Activity: >>> 140330 -10 0.6 1672 ~ AJ4F W5TN EM00 >>> I get the expected result ? W5TN goes into DX Call box, >>> and standard messages are generated for W5TN and K5GZR >>> However, when I double click on the following msg in Band Activity: >>> 135215 -14 0.1 1203 ~ K5GZR KT5MR EL29 >>>nothing happens. KT5MR is not copied to the DX Call box, >>>and standard message are unchanged. >>> I went to File>Settings and changed My Call: from K5GZR to W5TN. >>> The result of the change is: >>> If I double click on the K5GZR KT5MR EL29, >>> I get the expected result ? KT5MR goes into the DX Call box, >>> and standard messages are generated for KT5MR and W5TN. >>> But, if I double click on the AJ4F W5TN EM00 msg, >>> nothing happens. >>> Is it a possible problem with R7939, or is it something I?m doing wrong? >>> Thanks, >>> Rick ? K5GZR >>> >> Hi Rick, >> >> it is definitely a defect. I may have a fix already from another issue >> report. I will try your example on it shortly. >> >HI Rick, > >I think r7943 in the development branch fixes this issue. > >73 >Bill >G4WJS. > Bill, I just built r7944 and it appears that the issue is indeed fixed. 73, Rick - K5GZR -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] r7939 - FT8 - double click on msg in Band Activity with my call in it does not copy other station's call to DX Call
R7939 on Windows 10. Mode is FT8 My call is K5GZR When I double click on the following msg in Band Activity: 140330 -10 0.6 1672 ~ AJ4F W5TN EM00 I get the expected result - W5TN goes into DX Call box, and standard messages are generated for W5TN and K5GZR However, when I double click on the following msg in Band Activity: 135215 -14 0.1 1203 ~ K5GZR KT5MR EL29 nothing happens. KT5MR is not copied to the DX Call box, and standard message are unchanged. I went to File>Settings and changed My Call: from K5GZR to W5TN. The result of the change is: If I double click on the K5GZR KT5MR EL29, I get the expected result - KT5MR goes into the DX Call box, and standard messages are generated for KT5MR and W5TN. But, if I double click on the AJ4F W5TN EM00 msg, nothing happens. Is it a possible problem with R7939, or is it something I'm doing wrong? Thanks, Rick - K5GZR -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] User guide edits, comments
Bill, I'm okay with how it is now. Just had to look twice and think about why it was showing OOB in red. Thanks, Rick Date: Thu, 13 Jul 2017 14:48:22 +0100 From: Bill Somerville <g4...@classdesign.com> To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] User guide edits, comments Message-ID: <17f70ad2-6b73-40c6-3862-2afdf76fa...@classdesign.com> Content-Type: text/plain; charset=windows-1252; format=flowed On 13/07/2017 14:34, K5GZR - Rick wrote: > And a comment about the ?OOB? value displayed in the ?band? window on > the main screen when the selected frequency is outside a ham band. I > have the WWV frequencies in the table for FreqCal mode, and ?OOB? > displays for all of them except 10 MHz, where it displays 30m, even > though 10 MHz is technically not within the 30 meter amateur band. I > can ignore the OOB indication, but it was a surprise the first time it > appeared. Maybe there could be a different text for this condition > in FreqCal mode since many of the reference stations will not be > within amateur bands. Hi Rick, I used the ADIF definitions of the amateur bands to set generic and global band names. They have 10MHz inside the 30m band. If you now of a better description of amateur band names that works for all and is in the public domain I will gladly use it. The frequency calibration mode could bypass this mechanism but it would be quite messy to do so. 73 Bill G4WJS. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] User guide edits, comments
Did a quick read of the updated User Guide, and. Section 1.1.New in Version 1.8: SWL option for third-partty (should be party) Section 4.6.Frequencies: Does not describe all of the options in the popup window that appears after alt-click on frequency list. delete, insert, load, etc. Section 12.1.Decoded Lines: Table is missing an entry for FT8. Table entry for MSK144 shows only one item of information but decoded messages have three items. And a comment about the 'OOB' value displayed in the 'band' window on the main screen when the selected frequency is outside a ham band. I have the WWV frequencies in the table for FreqCal mode, and 'OOB' displays for all of them except 10 MHz, where it displays 30m, even though 10 MHz is technically not within the 30 meter amateur band. I can ignore the OOB indication, but it was a surprise the first time it appeared. Maybe there could be a different text for this condition in FreqCal mode since many of the reference stations will not be within amateur bands. Thanks, Rick - K5GZR -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] IARU Region selection in Settings > General is not 'sticking'
Replying to Bill and Mike, R7847 installed using the official rc1 installer works as designed. I can select Region 2, exit WSJT-X, reenter WSJT-X, and the Region 2 setting is retained. I do not know the release numbers the other ops were using, nor can I confirm that either of them was in fact using 1.8.0-rc1. Hoping that Mike will be able to identify the source of the problem. Thanks, Rick - K5GZR -- Date: Wed, 12 Jul 2017 17:15:33 + (UTC) From: Black Michael <mdblac...@yahoo.com> To: WSJT software development <wsjt-devel@lists.sourceforge.net> Subject: Re: [wsjt-devel] IARU Region selection in Settings > General is not 'sticking' Message-ID: <1940879683.4033693.1499879733...@mail.yahoo.com> Content-Type: text/plain; charset="utf-8" I"m using 7857 and can duplicate the problem.The Region is being saved in the INI filebut resets to ALL on WSJT-X startup. Trying to debug now. de Mike W9MDB From: Bill Somerville <g4...@classdesign.com> To: wsjt-devel@lists.sourceforge.net Sent: Wednesday, July 12, 2017 11:07 AM Subject: Re: [wsjt-devel] IARU Region selection in Settings > General is not 'sticking' On 12/07/2017 16:00, K5GZR - Rick wrote: I?ve seen this situation discussed here before, and thought that it had been resolved, but? I can go to File > Settings > General and pick ?Region 2? from the IARU Region: dropdown list. However, if I exit WSJT-X, when I restart WSJT-X, I see that the IARU Region: value has been returned to ?All?. And, as expected, the same thing happens if I switch to another configuration and then switch back to the original configuration. My ?Region 2? selection value is not staying with the configuration. I just rebuilt Hamlib, and then built r7856 to confirm that the problem has not been resolved for me.?? OS is Windows 10. I have confirmed with 2 other operators that they are seeing this same situation with wsjtx-1.8.0-rc1-win32.exe and subsequent devel releases. Rick ? K5GZR Hi Rick, this has been reported by several users who are building from sources on multiple platforms. I have not yet discovered what the reason is and I cannot reproduce it myself. Yours is the first report, albeit third party, that the official release kit is suffering this problem. Can you try the official v1.8.0-rc1 installer and see if that also has the same problem please? 73 Bill G4WJS. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] IARU Region selection in Settings > General is not 'sticking'
I've seen this situation discussed here before, and thought that it had been resolved, but. I can go to File > Settings > General and pick 'Region 2' from the IARU Region: dropdown list. However, if I exit WSJT-X, when I restart WSJT-X, I see that the IARU Region: value has been returned to 'All'. And, as expected, the same thing happens if I switch to another configuration and then switch back to the original configuration. My 'Region 2' selection value is not staying with the configuration. I just rebuilt Hamlib, and then built r7856 to confirm that the problem has not been resolved for me. OS is Windows 10. I have confirmed with 2 other operators that they are seeing this same situation with wsjtx-1.8.0-rc1-win32.exe and subsequent devel releases. Rick - K5GZR -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Controlling the level of audio going into the sound card.
I have a RigblasterPRO getting constant level audio from one of the connectors on the back of my IC-746PRO. I bought a $4 inline headphone volume control on ebay, and have it in the line between the RigblasterPRO and my computer's sound card. I adjust the sound card input level slider to 0 dB, then adjust the inline volume control until the WSJT-X level meter shows 30 dB on normal 6 meter background noise. Works well for me. 73, Rick - K5GZR -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Inquiry about sending .wav files with failed
Date: Mon, 3 Jul 2017 20:14:39 +0100 From: Bill Somerville <g4...@classdesign.com> To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] Inquiry about sending .wav files with failed decodes to development team Message-ID: <1bf00903-804a-a94f-c5d7-391a7e848...@classdesign.com> Content-Type: text/plain; charset="windows-1252"; Format="flowed" On 03/07/2017 20:02, K5GZR - Rick wrote: > > I?m new to this list, wanting to send some .wav files with FT8 signals > which didn?t decode, even though their tracks on the waterfall looked > ?good?. I see some emails to the list with one or two .wav files > attached, but I have quite a few more than that. I put them into a > .zip archive and the .zip is 10 megabytes? probably too much for an > e-mail attachment. > > Should I just pick one or two and attach them to an email and send it > to the list? Or is it better to try to send more files, and if so is > there a ?normal? way to make them available to the developers, other > than attaching them to an e-mail? I don?t want to cause ?information > overload?. > > Thanks in advance, > > Rick ? K5GZR ? EL29gp > Hi Rick, providing a link to a cloud storage service where the files or archive have been uploaded is best. Dropbox, Google Drive etc. provide ample free storage. Best to try and categorize types of failures, if you can, and provide a file name that best demonstrates what you think should decode per category. You should be aware that users used to operating JT9 or JT65 may have over-optimistic expectations of FT8 sensitivity. The mode was designed to balance sensitivity, bandwidth and transmit period so as to carry the same information content as JT65 and JT9 in a multi-decoding environment, something has to give to achieve the roughly 1/4 as long transmissions and in this case it is both bandwidth (vs. JT9) and sensitivity. Currently around -21dB SNR with respect to a 2500Hz noise bandwidth is about the limit. Reported SNR estimates may not yet be accurate although they are being improved as the decoder is fine tuned. Examples of non-decodes are welcome but be prepared for a simple "You are expecting too much." response in some cases. 73 Bill G4WJS. * Thanks Bill, Couldn't figure out how to reply on the SourceForge site. Sorry about possible weird reply format. Thanks for your reply. Putting the files on a cloud site will work for me when I need to send files to the team at some time in the future. In this case, the weak signal sequences (S1 or lower) decoded, but the strong signal sequences (S5 to S6) from the same station did not decode. Both the weak and strong signal sequences had reasonably constant strengths throughout the sequences, with no fades and no MS pings. WSJT-X release was r. I'll continue to test and get a better idea of what 'should' decode and focus on situations where there is no decode where it looks like it 'should'. 73, Rick - K5GZR -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Inquiry about sending .wav files with failed decodes to development team
I'm new to this list, wanting to send some .wav files with FT8 signals which didn't decode, even though their tracks on the waterfall looked 'good'. I see some emails to the list with one or two .wav files attached, but I have quite a few more than that. I put them into a .zip archive and the .zip is 10 megabytes. probably too much for an e-mail attachment. Should I just pick one or two and attach them to an email and send it to the list? Or is it better to try to send more files, and if so is there a 'normal' way to make them available to the developers, other than attaching them to an e-mail? I don't want to cause 'information overload'. Thanks in advance, Rick - K5GZR - EL29gp -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSPR-X transmit intermittent
I am running WSPR-X v0.8 r3058 on a Windows 7 machine. Have noticed that after a couple of hours operation it fails to generate tone for the transmit cycle display goes red and indicates Transmitting but nil TX...continues to decode just fine. -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
