Re: [wsjt-devel] Issue installing 2.1.0rc5

2019-05-01 Thread Tom Melvin
Hi OMOne of the main Mac maintainer’s lives in the UK - it is 4:30am here just now, you posting 4 hours ago - just after midnight local time.It can take a while for some posts to be answered, the Dev team are all volunteers and do need sleep :-)By the way have you checked the ‘Known Issues’ list:http://physics.princeton.edu/pulsar/k1jt/Reported_bugs.txt(see item 2 - it may help) - not saying it is what you are reporting but it may be easier to switch back to GA until a new Mac build is done.RegardsTom
--73’sTomGM8MJV (IO85)

On 2 May 2019, at 03:44, false via wsjt-devel  wrote: Hi, folks, hoping to get some help with this issue. I searched the 
Yahoo group archives and then sent this request to the group ~4 hours 
ago, have not received a response yet.  I renamed my old 
installation and installed the rc5 version;  the install process 
produced no errors but when I try to start the app, the below messages 
appear in Console. There are ~30 variations on the first message 
regarding varios frameworks when I initially attempt to start the app 
(after which the second message 
appears), any attempts to start the app again after the first attempt 
results only in the third error message. I have deleted the installation
 and reinstalled, with the same results. Any ideas? The 2.0 installation
 still functions... Mac Mini 2.3GHz i7 16GB running El Capitan (10.11.6)
 5/1/19 2:20:44.830 PM CoreServicesUIAgent[70277]: error -1 while 
removing quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtWidgets.framework/Versions/Current
 5/1/19 2:20:44.887 PM com.apple.xpc.launchd[1]: 
(com.apple.xpc.launchd.oneshot.0x10bf.wsjtx[71512]) Service exited 
with abnormal code: 1 5/1/19 2:28:40.539 PM com.apple.xpc.launchd[1]: (org.k1jt.wsjtx.307232[71588]) Service exited with abnormal code: 1I'm attaching the full error message output as a text file.


5/1/19 2:20:44.817 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtCore.framework/QtCore
5/1/19 2:20:44.817 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtCore.framework/Resources
5/1/19 2:20:44.817 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtCore.framework/Versions/Current
5/1/19 2:20:44.818 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtDBus.framework/QtDBus
5/1/19 2:20:44.818 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtDBus.framework/Resources
5/1/19 2:20:44.818 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtDBus.framework/Versions/Current
5/1/19 2:20:44.819 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtGui.framework/QtGui
5/1/19 2:20:44.819 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtGui.framework/Resources
5/1/19 2:20:44.819 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtGui.framework/Versions/Current
5/1/19 2:20:44.820 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtMultimedia.framework/QtMultimedia
5/1/19 2:20:44.820 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtMultimedia.framework/Resources
5/1/19 2:20:44.821 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtMultimedia.framework/Versions/Current
5/1/19 2:20:44.821 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtNetwork.framework/QtNetwork
5/1/19 2:20:44.821 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtNetwork.framework/Resources
5/1/19 2:20:44.822 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtNetwork.framework/Versions/Current
5/1/19 2:20:44.822 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtPrintSupport.framework/QtPrintSupport
5/1/19 2:20:44.823 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtPrintSupport.framework/Resources
5/1/19 2:20:44.823 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/A

[wsjt-devel] Issue installing 2.1.0rc5

2019-05-01 Thread false via wsjt-devel
 
Hi, folks, hoping to get some help with this issue. I searched the Yahoo group 
archives and then sent this request to the group ~4 hours ago, have not 
received a response yet. 

 I renamed my old installation and installed the rc5 version; the install 
process produced no errors but when I try to start the app, the below messages 
appear in Console. There are ~30 variations on the first message regarding 
varios frameworks when I initially attempt to start the app (after which the 
second message appears), any attempts to start the app again after the first 
attempt results only in the third error message. I have deleted the 
installation and reinstalled, with the same results. Any ideas? The 2.0 
installation still functions...

 Mac Mini 2.3GHz i7 16GB running El Capitan (10.11.6)

 5/1/19 2:20:44.830 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtWidgets.framework/Versions/Current

 5/1/19 2:20:44.887 PM com.apple.xpc.launchd[1]: 
(com.apple.xpc.launchd.oneshot.0x10bf.wsjtx[71512]) Service exited with 
abnormal code: 1

 5/1/19 2:28:40.539 PM com.apple.xpc.launchd[1]: (org.k1jt.wsjtx.307232[71588]) 
Service exited with abnormal code: 1
I'm attaching the full error message output as a text file.




5/1/19 2:20:44.817 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtCore.framework/QtCore
5/1/19 2:20:44.817 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtCore.framework/Resources
5/1/19 2:20:44.817 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtCore.framework/Versions/Current
5/1/19 2:20:44.818 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtDBus.framework/QtDBus
5/1/19 2:20:44.818 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtDBus.framework/Resources
5/1/19 2:20:44.818 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtDBus.framework/Versions/Current
5/1/19 2:20:44.819 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtGui.framework/QtGui
5/1/19 2:20:44.819 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtGui.framework/Resources
5/1/19 2:20:44.819 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtGui.framework/Versions/Current
5/1/19 2:20:44.820 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtMultimedia.framework/QtMultimedia
5/1/19 2:20:44.820 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtMultimedia.framework/Resources
5/1/19 2:20:44.821 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtMultimedia.framework/Versions/Current
5/1/19 2:20:44.821 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtNetwork.framework/QtNetwork
5/1/19 2:20:44.821 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtNetwork.framework/Resources
5/1/19 2:20:44.822 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtNetwork.framework/Versions/Current
5/1/19 2:20:44.822 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtPrintSupport.framework/QtPrintSupport
5/1/19 2:20:44.823 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtPrintSupport.framework/Resources
5/1/19 2:20:44.823 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtPrintSupport.framework/Versions/Current
5/1/19 2:20:44.824 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtSerialPort.framework/QtSerialPort
5/1/19 2:20:44.824 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtSerialPort.framework/Resources
5/1/19 2:20:44.825 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtSerialPort.framework/

Re: [wsjt-devel] Log QSO Window -> OK and Cancel buttons oddbehavior -CRACKED

2019-05-01 Thread rjai...@gmail.com
Apart from ADA stuff it simply isn't working for blind hams. Besides, the
autobots have gotten advanced now to the point where they are simply
modifying source code and bypassing all manual input.

Not sure what can be done other than maybe invalidate awards from automated
robot cheating.

Ria
N2RJ

On Wed, 1 May 2019 at 14:22, Mark James  wrote:

> Note: I think this post is appropriate on this list because it involves an
> important software development issue.
>
> I'm not going to comment on the details of the interface, but I think it
> is worth pointing out that a software interface that requires using a mouse
> to click a button is in violation of the US Americans with Disabilities
> Act. Under the ADA you must provide a keyboard option.
>
> While a free, open-source program might not face any specific penalty
> here, but not being ADA-compliant at least in theory could result in the
> software not being allowed to be used in schools, colleges, or any public
> institution.
>
> Besides, being ADA complaint is just the right thing to do.
>
> Frankly I think any attempt to make it harder to use macros will result in
> flunking the accessibility goal.
>
>
> 
>  Virus-free.
> www.avg.com
> 
> <#m_-883129225528624055_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Wed, May 1, 2019 at 12:22 AM Aaron Jones  wrote:
>
>> Dev Team,
>>
>> I'm sure everyone's burned out on the OK/Cancel BUTTon discussion but
>> since it was such a hot "button" topic (LOL) I thought I'd give cracking it
>> a try.  I'm very impressed that the window and button are as elusive to
>> automation as they are, nice programming.  Here's what I found:
>>
>>- You cannot use "Alt-O" to focus on the OK button
>>- You cannot Tab through the fields to the OK button, it only sets
>>focus on the cancel and then back around to the beginning field
>>- Using a macro tool I could not focus the Log QSO window, it somehow
>>was at the top of all windows and I couldn't "read" it using two different
>>macro tools (not to be named)
>>
>> Things I could do:
>>
>>- Using a freely available macro tool I noticed I COULD query for
>>open windows title bars and verify "log qso" existed
>>- I could screenshot the OK button using a screenshot tool
>>- Using a  freely available macro toolI was able to search the screen
>>for "image" of the button and specify a location to focus on, in this case
>>the upper left hand where the window always pops up for me, OR if I wanted
>>I probably could have moved it using the information from finding it was
>>available
>>- Once found the macro software focused the mouse on the coordinates
>>of the "image" of the "OK button" and VOILA! I was able to "click OK"
>>
>> To test it I put the six line macro script loop (two of those lines were
>> the loop itself) and ran it while I QSO'd with three different stations in
>> the matter of a couple of minutes, each time the script was able to find
>> and click the OK button wherever it landed on the LOG QSO screen.
>>
>>  I spent about an hour fanagling with it and found two different ways to
>> do it (the other way was to watch my WSJT-X computer via remote desktop or
>> similar VNC and do the same "image find" dance and click remotely - this
>> would probably be better because the scripting computer would have no need
>> to worry or knowledge of the Z-index of the Log QSO window, it would see
>> the entire screen as an image and just find the OK button regardless of
>> other windows handle considerations.
>>
>> *So  - my point is not to be a pain and hack this or explain how to do it
>> but rather to postulate*, other than annoying normal users what does
>> this really accomplish other than screw up the unwary button clicker when
>> the OK / Cancel switch and they are too focused on the next QSO to notice
>> they just nuked their first DX entry to Antarctica and missed out on
>> finalizing their DXCC award?  Or screwing up the visually impaired or late
>> night impaired operator?
>>
>> If I had a vote I'd not punish the law abiding citizen and the 99% for
>> the 1% abusers of automation.
>>
>> PS. IF you need a video of my macro I'll be glad to post it but won't to
>> the group as that would make it far easier than it already is to circumvent
>> this precaution.
>>
>> AG7GK
>>
>> Aaron
>>
>> 73
>>
>>
>> ___
>> 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 

[wsjt-devel] 2.1.0-rc5 OK logging button problematic for blind hams

2019-05-01 Thread rjai...@gmail.com
I was helping a blind ham set up WSJT-X 2.1.0-rc5 today and it was
apparent that this new arrangement to thwart robots simply isn't
working for blind hams who rely upon screen readers and other
accessibility technologies. There is no way for his screen reader
software to focus on OK.

Any help with this would be appreciated.

73
Ria, N2RJ


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] FT4 Crashed

2019-05-01 Thread David Tiller
For what it's worth, I was able to decode the audio files with the OSX version 
of wsjtx-2.1.0-rc5.

[cid:40FF19D9-3F6C-4C35-8218-570FE70C1877]
--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com



On May 1, 2019, at 7:45 PM, David Bean (KC2WUF) via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:

Got the below crash report after decoding the following:

190501_23244214.080 Rx FT4  9  0.2  382 W2DLL NP3F +12
190501_23244214.080 Rx FT4 15 -0.1 1340 N9OJC N6QQ RR73
190501_23244214.080 Rx FT4  5 -0.1 1687 CU3CC W6JH R-01
190501_23244214.080 Rx FT4 -8 -0.1 2270 KG4IYS KI6DY 73
190501_23244214.080 Rx FT4 17  0.3 2538 CQ W2OR EL99
190501_23244814.080 Tx FT4  0  0.0 2538 W2OR KC2WUF FN20
190501_23245414.080 Rx FT4  2 -0.0 1686 CU3CC W6JH R+01
190501_23245414.080 Rx FT4 18  0.3 2538 KC2WUF W2OR +16
<= Crash took place here =>
190501_23250014.080 Tx FT4  0  0.0 2538 W2OR KC2WUF R+18
190501_23251214.080 Tx FT4  0  0.0 2538 W2OR KC2WUF R+18

The dialog box popped up after decoding time: 232454 segment and I began 
sending my report (over and over until I closed the error dialog box), but no 
further decoding took place. I am attaching the .wav files for 232442, 232454 
and 232506 (recorded, but no decodes took place).

My system is:
O/S: 64-bit Windows 10 Home (Version 1803 (OS Build 17134.706))
CPU: AMD A6-7310 with Radeon R4 Graphics 2.00 GHz
Memory: 8.00 GB

73 David KC2WUF

Data from error dialog box:

Running: C:\WSJT\wsjtx_beta2\bin\jt9 -s "WSJT-X - FT4" -w 1 -m 3 -e 
C:\WSJT\wsjtx_beta2\bin -a "C:\Users\dude8\AppData\Local\WSJT-X - FT4" -t 
"C:\Users\dude8\AppData\Local\Temp\WSJT-X - FT4"
At line 41 of file C:\Users\bill\src\k1jt\wsjtx\lib\ft4\ft4_downsample.f90
Fortran runtime error: Index '-2147483648' of dimension 1 of array 'cx' below 
lower bound of 0

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0 0x
#1 0x
#2 0x
#3 0x
#4 0x
#5 0x
#6 0x
#7 0x
#8 0x
#9 0x
#10 0x
#11 0x
#12 0x
#13 0x


<190501_232442.wav><190501_232454.wav><190501_232506.wav>___
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] Another observed drawback - audio input level

2019-05-01 Thread Bill Somerville

On 02/05/2019 00:05, Gary Kohtala - K7EK via wsjt-devel wrote:
We are talking about RX audio. I use a SignaLink USB, not the on board 
sound system,
and am experiencing the problem. Interestingly, when I execute another 
program called
MARS-ALE, it somehow forces the RX audio to 0.0 db. Not sure how N2CKH 
did that but perhaps

it would be a possibility in WSJT-X at some point.

Best regards,

Gary, K7EK

Radcliff, KY (EM77at)


Hi Gary,

it is possible to determine the 0 dB point by querying a whole bunch of 
MS proprietary APIs to get the extents and step size for the driver 
level control but it is a PITA. Since we use Qt (QAudioInput) to manage 
the input audio stream we only have a basic control that goes from zero 
to one with no information about how that maps to gain or attenuation - 
so we don't use that.


The fix in Qt is small and was completed quickly when I spoke to the 
developer who made the change that caused the level resetting issue. We 
will wait for the fix to flow through to a release. It is in for Qt 
5.12.4 which is due in May. Until then you always have the option to use 
the 32-bit build of WSJT-X.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Another observed drawback - audio input level

2019-05-01 Thread Gary Kohtala - K7EK via wsjt-devel
 Hasan,
We are talking about RX audio. I use a SignaLink USB, not the on board sound 
system,and am experiencing the problem. Interestingly, when I execute another 
program calledMARS-ALE, it somehow forces the RX audio to 0.0 db. Not sure how 
N2CKH did that but perhapsit would be a possibility in WSJT-X at some point.
Best regards,
Gary, K7EK
Radcliff, KY (EM77at)
---
On Tuesday, April 30, 2019, 5:47:04 PM EDT, Hasan al-Basri 
 wrote:  
 
 I am also using an external usb sound dongle (the $5 variety from Amazon). I 
am not seeing any of the noted audio issues with the 64 bit version.
I have set the audio once, gone back and forth, started, stopped the program, 
changed configs. I don't see it. I assumed it was because it was not the 
motherboard sound card. Now I gather from Bill that it is because it has no 
level setting.
BTW, I assume we are talking about transmit level setting, not rx?
73, N0ANHasan

On Tue, Apr 30, 2019 at 3:35 PM Bill Somerville  wrote:

On 30/04/2019 21:03, Neil Zampella wrote:
>
> FWIW .. Mike recommended a few years ago at least that you change the 
> properties from showing a PERCENTAGE to a dB level. I have mine set to 
> 0 dB on the properties, and have not see the issues others are seeing 
> with the 64 bit version.
>
> I am using an external USB soundcard with the system (Sound Blaster 
> xFi) which may be the reason I'm not seeing the issues, but I'm 
> thinking its more the property setting.
>
> Neil, KN3iLZ
>
Hi Neil,

the issue is universal for all sound cards, including virtual devices 
like loopback services. For some devices 100% level is 0dB, i.e. they 
have no gain ahead of the ADC (or no ADC if they are a virtual device) 
apart from the mic. boost stage which is not affected by this issue.

So for those using digital audio loopback devices and sound cards with 
no front end gain adjustment, there is no real problem assuming 0dB is 
compatible with the audio level being sampled. The real issue is where a 
sound card has gain ahead of the ADC because we cannot detect that and 
it will be set to maximum unconditionally on restart.

The Qt fix that is in the pipeline will revert to not changing the 
existing gain settings when an audio input stream is opened.

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] WSJT-X 2.1.0-rc5

2019-05-01 Thread Bill Somerville

On 01/05/2019 21:09, Christoph Berg wrote:

If that doesn't help then I can send you an instrumented version of WSJT-X
to track the CAT communication in detail, or explain how to enable that in
your own build.

I guess it's WSJT_TRACE_CAT && WSJT_TRACE_CAT_POLLS? I can try that
tomorrow.


Hi Christoph,

setting those options ON will work for a  debug configuration build. To 
get the trace working in a release configuration build you need 
WSJT_QDEBUG_IN_RELEASE=ON, and you can have the debug trace redirected 
to a file by setting WSJT_QDEBUG_TO_FILE=ON (the trace will be appended 
to /tmp/WSJT-X_trace.log). Another option that can help is 
WSJT_HAMLIB_VERBOSE_TRACE=ON , set that and you will get the equivalent 
of -v for the Hamlib trace.


73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] WSJT-X 2.0.0 , 2.0.1 and 2.1.0 rc5 problem working JT65&JT9 with /P in callsign

2019-05-01 Thread Haris SV1GRB
Hello to all.

I have already sent a similar message in the groups.io list but I thought
mentioning the problem also at the official development list.

When my station's callsign has /P in it, it is impossible to operate in
JT65 and JT9. This behavior exists in WSJT-X 2.0.0. , 2.0.1. and 2.1.0 rc5.
The old 1.9.1 was working OK.

There is a problem with the transmitted messages.
Whatever message is selected, the same Tx1 message "*his call* SV1GRB/P" is
transmitted.
For example:
Trying to work the station CT3HF.
After transmitting "CT3HF SV1GRB/P" (correctly without the grid because of
the compound call use) and the other station responds with the report, I
have the same message "CT3HF SV1GRB/P" transmitted on the next cycle,
instead of "CT3HF SV1GRB R-15" for example, despite the fact that the
correct message is selected in time for transmission.

Note that the Generated Std Msgs fields are populated with the correct
messages but the first (Tx1) message is always transmitted.

FT8 works just fine with /P in callsign. This behavior exists only in JT65
and JT9 modes.


Thanks in advance,
73
Haris
SV1GRB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] WSJT-X 2.1.0-rc5

2019-05-01 Thread Christoph Berg
Re: Bill Somerville 2019-04-30 

> I don't recall if the Icom IC-706 Mk0 can accept CAT commands while
> transmitting, I doubt it as it has pretty primitive CAT control. Make sure
> that you have "Settings->General->Allow Tx frequency changes while
> transmitting" unchecked. You can also try simplifying the CAT communications
> by selecting "Settings->Radio->Mode->None", you would then set the rig to
> USB manually.

Hi Bill,

changing frequency while transmitting works, so that doesn't seem to
be the problem. CAT works generally, it just fails sometimes in random
places so I think the cause is more like wsjtx issuing too many
commands too fast, or not waiting long enough for a retry.

Rarely, there seems to be a burst of rx/tx switches happening very
fast for half a second. (Much less frequent than the "normal"
communication failures.)

> If that doesn't help then I can send you an instrumented version of WSJT-X
> to track the CAT communication in detail, or explain how to enable that in
> your own build.

I guess it's WSJT_TRACE_CAT && WSJT_TRACE_CAT_POLLS? I can try that
tomorrow.

Thanks,
Christoph


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Log QSO Window -> OK and Cancel buttons oddbehavior -CRACKED

2019-05-01 Thread Mark James
Note: I think this post is appropriate on this list because it involves an
important software development issue.

I'm not going to comment on the details of the interface, but I think it is
worth pointing out that a software interface that requires using a mouse to
click a button is in violation of the US Americans with Disabilities Act.
Under the ADA you must provide a keyboard option.

While a free, open-source program might not face any specific penalty here,
but not being ADA-compliant at least in theory could result in the software
not being allowed to be used in schools, colleges, or any public
institution.

Besides, being ADA complaint is just the right thing to do.

Frankly I think any attempt to make it harder to use macros will result in
flunking the accessibility goal.


Virus-free.
www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, May 1, 2019 at 12:22 AM Aaron Jones  wrote:

> Dev Team,
>
> I'm sure everyone's burned out on the OK/Cancel BUTTon discussion but
> since it was such a hot "button" topic (LOL) I thought I'd give cracking it
> a try.  I'm very impressed that the window and button are as elusive to
> automation as they are, nice programming.  Here's what I found:
>
>- You cannot use "Alt-O" to focus on the OK button
>- You cannot Tab through the fields to the OK button, it only sets
>focus on the cancel and then back around to the beginning field
>- Using a macro tool I could not focus the Log QSO window, it somehow
>was at the top of all windows and I couldn't "read" it using two different
>macro tools (not to be named)
>
> Things I could do:
>
>- Using a freely available macro tool I noticed I COULD query for open
>windows title bars and verify "log qso" existed
>- I could screenshot the OK button using a screenshot tool
>- Using a  freely available macro toolI was able to search the screen
>for "image" of the button and specify a location to focus on, in this case
>the upper left hand where the window always pops up for me, OR if I wanted
>I probably could have moved it using the information from finding it was
>available
>- Once found the macro software focused the mouse on the coordinates
>of the "image" of the "OK button" and VOILA! I was able to "click OK"
>
> To test it I put the six line macro script loop (two of those lines were
> the loop itself) and ran it while I QSO'd with three different stations in
> the matter of a couple of minutes, each time the script was able to find
> and click the OK button wherever it landed on the LOG QSO screen.
>
>  I spent about an hour fanagling with it and found two different ways to
> do it (the other way was to watch my WSJT-X computer via remote desktop or
> similar VNC and do the same "image find" dance and click remotely - this
> would probably be better because the scripting computer would have no need
> to worry or knowledge of the Z-index of the Log QSO window, it would see
> the entire screen as an image and just find the OK button regardless of
> other windows handle considerations.
>
> *So  - my point is not to be a pain and hack this or explain how to do it
> but rather to postulate*, other than annoying normal users what does this
> really accomplish other than screw up the unwary button clicker when the OK
> / Cancel switch and they are too focused on the next QSO to notice they
> just nuked their first DX entry to Antarctica and missed out on finalizing
> their DXCC award?  Or screwing up the visually impaired or late night
> impaired operator?
>
> If I had a vote I'd not punish the law abiding citizen and the 99% for the
> 1% abusers of automation.
>
> PS. IF you need a video of my macro I'll be glad to post it but won't to
> the group as that would make it far easier than it already is to circumvent
> this precaution.
>
> AG7GK
>
> Aaron
>
> 73
>
>
> ___
> 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] Mode Menu frequencies FT8 to FT4 OK but FT4 to FT8 Not...

2019-05-01 Thread Edfel Rivera
Hi All:

Noticed when changing MODE to FT4 frequency changes accordingly for each
band.  However, IF change back from FT4 to FT8 from MODE menu, frequency
stays (incorrectly) at the FT4 frequency.

73'

Edfel
KP4AJ
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Bug Reports

2019-05-01 Thread Joe Taylor

To: Beta-Testers of WSJT-X 2.1.0-rc5

Thanks for your help in improving the quality of WSJT-X.  Before sending 
bug reports to this email reflector, please check the list of known bugs 
posted here:


http://physics.princeton.edu/pulsar/k1jt/Reported_bugs.txt

-- 73, Joe, K1JT


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Abruption

2019-05-01 Thread Edfel Rivera
Hi:

I reported something related when station report with contest mode reply,
if your are not in contest mode WSJTX suggest you (popup window) to setup
contest mode.  However, if you are not interested in operating contest mode
at that moment (just making QSO's) it disrupts the calling station
operation.  In principle, IMO the software should not do anything based on
a responding station "response". But that is my perspective. It could even
bu used maliciously in some (sick) cases.

73'

Edfel
KP4AJ


On Wed, May 1, 2019 at 8:41 AM Jari A  wrote:

> [image: image.png]
>
> [image: image.png]
>
>
>
>
> I was at normal FT4 CQ play, had several qsos, then M0IEP return with EU
> contest mode and while I change to contest mode on the run, occasion ended
> with crash. *.wav suppose to be available if needed.
> Windows 7 Pro, 64-bit
>
> Best regards,
>
> :Jari / oh2fqv
>
> ---
> 190501_12273014.080 Tx FT4  0  0.0 1081 CQ OH2FQV
> KP20
> 190501_12273614.080 Rx FT4  3  0.2  621 N0FW US2MA 73
> 190501_12273614.080 Rx FT4 -1 -0.4  939 CQ CT7AIX IM59
> 190501_12273614.080 Rx FT4  9 -0.1 1081 OH2FQV M0IEP 539 0001
> 190501_12273614.080 Rx FT4 13  0.0 1479 OZ5AGJ N4YDU +04
> 190501_12273614.080 Rx FT4 20  0.0 1817 OH6MR JR4OZR 73
> 190501_12274214.080 Tx FT4  0  0.0 1081 CQ OH2FQV
> KP20
> 190501_12274814.080 Rx FT4  7 -0.1 1081 OH2FQV M0IEP 539 0001
> 190501_12274814.080 Rx FT4 12  0.1 1479 OZ5AGJ N4YDU RR73
> 190501_12274814.080 Rx FT4 19  0.0 1818 UX0ZAB JR4OZR -11
> 190501_12275414.080 Tx FT4  0  0.0 1081 M0IEP OH2FQV
> R+09
> 190501_12280014.080 Rx FT4 -1 -0.2 1081 OH2FQV M0IEP 539 0001
> 190501_12280014.080 Rx FT4 11  0.0 1817 UX0ZAB JR4OZR -11
> 190501_12280614.080 Tx FT4  0  0.0 1081 M0IEP OH2FQV
> R+07
> 190501_12280614.080 Tx FT4  0  0.0 1081 M0IEP OH2FQV
> R-01
> 190501_12281514.080 Tx FT8  0  0.0 1081 M0IEP R 550001
> KP20MF
> 190501_12283014.080 Tx FT4  0  0.0 1081 M0IEP R 550001
> KP20MF
> 190501_12283614.080 Rx FT4  3  0.2  621 R1CAV US2MA 73
> 190501_12283614.080 Rx FT4  5 -0.2  799 CQ M6OZR IO92
> 190501_12283614.080 Rx FT4 -6 -0.0 1005 OZ5AGJ IT9CIL -03
> 190501_12283614.080 Rx FT4 -4 -0.3 1188 N0FW UT0HB R-05
> 190501_12283614.080 Rx FT4  3  0.1 1479 CQ N4YDU FM06
> 190501_12283614.080 Rx FT4 14  0.0 1817 RV9WF JR4OZR R-06
> 190501_12283614.080 Rx FT4 15 -0.1 1890 UT4UQ PC5W RR73
> 190501_12283614.080 Rx FT4  4 -0.1 2391 SP8MTA HL5BLI -09
> 190501_12284214.080 Tx FT4  0  0.0 1081 M0IEP R 550001
> KP20MF
> 190501_12284814.080 Rx FT4 -1 -0.1  799 OH6MR M6OZR R-03
> 190501_12284814.080 Rx FT4 11 -0.2 1080 OH2FQV M0IEP RR73
> 190501_12284814.080 Rx FT4 -8  0.2 1344 N0FW YO7LGI KN14
> 190501_12284814.080 Rx FT4 10  0.1 1479 CQ N4YDU FM06
> 190501_12284814.080 Rx FT4  7 -0.1 2391 SP8MTA HL5BLI -09
> 190501_12284814.080 Rx FT4 -5 -0.4 2537 F5SGS CT7AIX -13
> 190501_12285414.080 Tx FT4  0  0.0 1081 M0IEP OH2FQV
> 73
>
>
>
> I was at normal FT4 CQ play, had several qsos, then M0IEP return with EU
> contest mode and while I change to contest mode on the run, occasion ended
> with crash.
> Windows 7 Pro, 64-bit
> ---
> 190501_12273014.080 Tx FT4  0  0.0 1081 CQ OH2FQV
> KP20
> 190501_12273614.080 Rx FT4  3  0.2  621 N0FW US2MA 73
> 190501_12273614.080 Rx FT4 -1 -0.4  939 CQ CT7AIX IM59
> 190501_12273614.080 Rx FT4  9 -0.1 1081 OH2FQV M0IEP 539 0001
> 190501_12273614.080 Rx FT4 13  0.0 1479 OZ5AGJ N4YDU +04
> 190501_12273614.080 Rx FT4 20  0.0 1817 OH6MR JR4OZR 73
> 190501_12274214.080 Tx FT4  0  0.0 1081 CQ OH2FQV
> KP20
> 190501_12274814.080 Rx FT4  7 -0.1 1081 OH2FQV M0IEP 539 0001
> 190501_12274814.080 Rx FT4 12  0.1 1479 OZ5AGJ N4YDU RR73
> 190501_12274814.080 Rx FT4 19  0.0 1818 UX0ZAB JR4OZR -11
> 190501_12275414.080 Tx FT4  0  0.0 1081 M0IEP OH2FQV
> R+09
> 190501_12280014.080 Rx FT4 -1 -0.2 1081 OH2FQV M0IEP 539 0001
> 190501_12280014.080 Rx FT4 11  0.0 1817 UX0ZAB JR4OZR -11
> 190501_12280614.080 Tx FT4  0  0.0 1081 M0IEP OH2FQV
> R+07
> 190501_12280614.080 Tx FT4  0  0.0 1081 M0IEP OH2FQV
> R-01
> 190501_12281514.080 Tx FT8  0  0.0 1081 M0IEP R 550001
> KP20MF
> 190501_12283014.080 Tx FT4  0  0.0 1081 M0IEP R 550001
> KP20MF
> 190501_12283614.080 Rx FT4  3  0.2  621 R1CAV US2MA 73
> 190501_12283614.080 Rx FT4  5 -0.2  799 CQ M6OZR IO92
> 190501_12283614.080 Rx FT4 -6 -0.0 1005 OZ5AGJ IT9CIL -03
> 190501_12283614.080 Rx FT4 -4 -0.3 1188 N0FW UT0HB R-05
> 190501_12283614.080 Rx FT4  3  0.1 1479 CQ N4YDU FM06
> 190501_12283614.080 Rx FT4 14  0.0 1817 RV9WF JR4OZR R-06
> 190501_12283614.080 Rx FT4 15 -0.1 1890 UT4UQ PC5W RR73
> 190501_12283614.080

Re: [wsjt-devel] WSJT-X rc5 Subprocess error

2019-05-01 Thread Black Michael via wsjt-devel
I just had it happen -- here's the screenshot and the links for the 141918 and 
141924 wav files.  Either it crashed at the end of 141918 or before any decodes 
appeared from 141924.Running: C:\WSJT\wsjtx\bin\jt9 -s WSJT-X -w 1 -m 3 -e 
C:\WSJT\wsjtx\bin -a C:\Users\mdbla\AppData\Local\WSJT-X -t 
C:\Users\mdbla\AppData\Local\Temp\WSJT-XAt line 41 of file 
C:\Users\bill\src\k1jt\wsjtx\lib\ft4\ft4_downsample.f90Fortran runtime error: 
Index '-2147483648' of dimension 1 of array 'cx' below lower bound of 0
I believe this happened after coming out of the Settings and WSJT-X switched 
back to FT8 mode and I had to change it back to FT4.

They both decode fine from the command line and from WSJT-X 
now.C:\Users\mike\AppData\Local\WSJT-X\save>\WSJT\wsjtx\bin\jt9 -w 1 --ft4 -d 3 
190501_141918.wav141918   1  0.4  803 +  CQ K7M DM44141918   5  0.3 1596 +  
F4HUN N3PLM FN20   0   2
C:\Users\mike\AppData\Local\WSJT-X\save>\WSJT\wsjtx\bin\jt9 -w 1 --ft4 -d 3 
190501_141924.wav141924   6  0.1 1527 +  YO8RAA N4RJ EM91141924   1  0.2 2017 + 
 XE2MAM N4ZJW EM91141924  -6  0.2 2130 +  MM0VPY AB5XS EM12   0 
  3
https://www.dropbox.com/s/p3r9t0182q1744m/190501_141918.wav?dl=1
https://www.dropbox.com/s/fxc9wcytiheytzq/190501_141924.wav?dl=1

de Mike W9MDB







 

On Wednesday, May 1, 2019, 8:49:44 AM CDT, K2DBK-WSJT 
 wrote:  
 
 
I experienced the error as well, and the good news is that I had Save All 
turned on.

  

The bad news is that I didn’t note exactly what time this happened so I don’t 
know which file to send you. I looked through all the files from yesterday 
looking for a gap in the timestamps but I must have restarted within a minute 
and there are no gaps at all to help point me to the correct file. Is there any 
possible way I can figure out which file to send?

  

(I also realized that I’ve had Save All checked for a very long time; I’ve got 
about 360,000 captures taking up about 120GB.) 

  

From: Bill Somerville  
Sent: Tuesday, April 30, 2019 11:52 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X rc5 Subprocess error

  

Hi Ron,

  

assuming it is the same defect, which is likely, we have the message details. 
We are now looking for .WAV file that will reproduce the crash. Having 
"Menu->Save->Save All" checked is always wise when testing release candidates 
since the saved .WAV files can be very valuable for tracking down decoder 
crashes and verifying that we have fixed them.

  

73
Bill
G4WJS.

  

On 30/04/2019 16:47, Ron Koenig wrote:


I was unable to copy the text before it closed the window, happened several 
times on 80M  Flex 6600 

  

On Tue, 30 Apr 2019 at 10:43, Rich Zwirko - K1HTV  wrote:


While WSJT-X decoding FT4 stations on 14.080 MHz, the following error message 
was received:

“Subprocess error

Sunprocess failed with exit code 2”

Details of the failure:

Running: C:\wsjtx5\bin\jt9 -s WSJT-X -w 1 -m 3 -e C:\wsjtx5\bin -a 
C:\Users\k1htv\AppData\Local\WSJT-X -t C:\Users\k1htv\AppData\Local\Temp\WSJT-X

At line 41 of file C:\Users\bill\src\k1jt\wsjtx\lib\ft4\ft4_downsample.f90

Fortran runtime error: Index '-2147483648' of dimension 1 of array 'cx' below 
lower bound of 0

 

Error termination. Backtrace:

 

Could not print backtrace: libbacktrace could not find executable to open

#0 0x

#1 0x

#2 0x

#3 0x

#4 0x

#5 0x

#6 0x

#7 0x

#8 0x

#9 0x

#10 0x

#11 0x

#12 0x

#13 0x

 

 = = = =

73,

Rich - K1HTV



  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Another observed drawback - audio input level

2019-05-01 Thread Joe, LB1HI

a quotation from sourceforge  .

Windows users will discover that WSJT-X v2.1.0 has been made available
as a 64-bit MS Windows build for 64-bit versions of Windows since Vista.
This veraion has one known defect. The audio input device level will be
reset to 100% when WSJT-X is started, when the input audio device is
changed, and when switching to a new configuration. This is a Qt
framework defect that we have reported and is being fixed in a future
release; until then users should take care to set the device audio level
back to 0dB or lower depending on requirements. Note that many sound
cards and chips have real gain ahead of the ADC, as much as 14dB, which
will be turned to the maximum due to this defect and is usually
undesirable when using WSJT-X.

Despite this annoying defect, we recommend the 64-bit version of WSJT-X
on MS Windows as it has significant advantages in decoding speed.

-- 73 from Joe, K1JT; Steve, K9AN; and Bill, G4WJS.

On 30/04/2019 14:43, Black Michael via wsjt-devel wrote:
Are you guys looking at the dB level in the audio management panel?  
Or the % level?

WSJT-X does not touch the audio so it has to be Windows doing it.

Recording audio should be at 0dB.

de Mike W9MDB




On Tuesday, April 30, 2019, 6:55:30 AM CDT, kf8my--- via wsjt-devel 
 wrote:



It also does it in Win7, audio sound recording to max on restart.
Mike/kf8my



-Original Message-
From: Joe, LB1HI 
To: wsjt-devel 
Sent: Tue, Apr 30, 2019 6:46 am
Subject: [wsjt-devel] Another observed drawback - audio input level

Hi,
Another observed  drawback is that after each WSJT-X restart, previously
pre-set audio (Win 10 64 bit) signal input level of the sound card
changes. It changes spontaneously. It changes to a maximum  - 100% of
the  level setting range.

73`s Joe



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Waterfall with FT4

2019-05-01 Thread Joe, LB1HI

Hi,
 Even with the setting NAvg=1 the distance between the lines separating 
the period is "quite small".

But first, the technical functionality of the software is a priority.
In the future, when it will work as it should. It would be nice to have 
"cosmetic" treatments for visual appearance and ergonomics.


73`s, Joe

On 01/05/2019 15:23, Black Michael via wsjt-devel wrote:

Would be nice if the waterfall settings were by-mode.
In particular the short FT4 sequences require NAvg=1 to see the time 
stamps where that NAvg is too fast for FT8.


So a by-mode remembrance of at least the NAvg would be handy.

de Mike W9MDB




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Call Sign Lookup Feature?

2019-05-01 Thread Bill Somerville

On 01/05/2019 14:40, Jack S. Phogbound wrote:


Has anyone concepted an XML Call Sign lookup feature that would 
memorize the user name/password of the subscriber,


then perform the XML lookup and return the ‘Name” and possible the 
grid square to the logging window?


I frequently do the cut/paste from a browser window and this is 
fraught with pain as it takes me a longer time to do this


when my fingers and mouse do not cooperate.

Mitch Baum – AE2A


Hi Mitch,

most logging applications and related tools, like JTAlert, can do this 
using various services like QRZ.COM, hamQTH, etc.


73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] WSJT-X rc5 Subprocess error

2019-05-01 Thread Bill Somerville

Hi OM,

thanks for that issue report and good news that you have "Save All" 
enabled. You can narrow down the offending .WAV file quickly by playing 
back one that you are sure is earlier then hitting SHIFT+F6 which will 
start playing back subsequent .WAV files automatically. Watch the file 
names on the lower left status bar and you will have a better idea just 
before teh crash happens. You can then home right in on it by replaying 
the file you noted a d stepping on one file at a time with the F6 key. 
Double check you have the correct .WAV file and send it to us, either as 
a Cloud storage link (Dropbox, Google Drive , MS OneDrive, etc. whatever 
you have) or send the file to me directly.


You may want to click "Menu->File->Delete all *.wav & *.c2 files in 
SaveDir" after you have dispatched the offending file to us, hi hi.


73
Bill
G4WJS.

On 01/05/2019 14:46, K2DBK-WSJT wrote:


I experienced the error as well, and the good news is that I had Save 
All turned on.


The bad news is that I didn’t note exactly what time this happened so 
I don’t know which file to send you. I looked through all the files 
from yesterday looking for a gap in the timestamps but I must have 
restarted within a minute and there are no gaps at all to help point 
me to the correct file. Is there any possible way I can figure out 
which file to send?


(I also realized that I’ve had Save All checked for a very long time; 
I’ve got about 360,000 captures taking up about 120GB.)


*From:*Bill Somerville 
*Sent:* Tuesday, April 30, 2019 11:52 AM
*To:* wsjt-devel@lists.sourceforge.net
*Subject:* Re: [wsjt-devel] WSJT-X rc5 Subprocess error

Hi Ron,

assuming it is the same defect, which is likely, we have the message 
details. We are now looking for .WAV file that will reproduce the 
crash. Having "Menu->Save->Save All" checked is always wise when 
testing release candidates since the saved .WAV files can be very 
valuable for tracking down decoder crashes and verifying that we have 
fixed them.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Call Sign Lookup Feature?

2019-05-01 Thread Jack S. Phogbound
Has anyone concepted an XML Call Sign lookup feature that would
memorize the user name/password of the subscriber,

then perform the XML lookup and return the 'Name" and possible the
grid square to the logging window?

I frequently do the cut/paste from a browser window and this is
fraught with pain as it takes me a longer time to do this

when my fingers and mouse do not cooperate.

 

Mitch Baum - AE2A

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] WSJT-X rc5 Subprocess error

2019-05-01 Thread K2DBK-WSJT
I experienced the error as well, and the good news is that I had Save All 
turned on.

 

The bad news is that I didn’t note exactly what time this happened so I don’t 
know which file to send you. I looked through all the files from yesterday 
looking for a gap in the timestamps but I must have restarted within a minute 
and there are no gaps at all to help point me to the correct file. Is there any 
possible way I can figure out which file to send?

 

(I also realized that I’ve had Save All checked for a very long time; I’ve got 
about 360,000 captures taking up about 120GB.) 

 

From: Bill Somerville  
Sent: Tuesday, April 30, 2019 11:52 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X rc5 Subprocess error

 

Hi Ron,

 

assuming it is the same defect, which is likely, we have the message details. 
We are now looking for .WAV file that will reproduce the crash. Having 
"Menu->Save->Save All" checked is always wise when testing release candidates 
since the saved .WAV files can be very valuable for tracking down decoder 
crashes and verifying that we have fixed them.

 

73
Bill
G4WJS.

 

On 30/04/2019 16:47, Ron Koenig wrote:

I was unable to copy the text before it closed the window, happened several 
times on 80M  Flex 6600 

 

On Tue, 30 Apr 2019 at 10:43, Rich Zwirko - K1HTV mailto:k1...@comcast.net> > wrote:

While WSJT-X decoding FT4 stations on 14.080 MHz, the following error message 
was received:

“Subprocess error

Sunprocess failed with exit code 2”

Details of the failure:

Running: C:\wsjtx5\bin\jt9 -s WSJT-X -w 1 -m 3 -e C:\wsjtx5\bin -a 
C:\Users\k1htv\AppData\Local\WSJT-X -t C:\Users\k1htv\AppData\Local\Temp\WSJT-X

At line 41 of file C:\Users\bill\src\k1jt\wsjtx\lib\ft4\ft4_downsample.f90

Fortran runtime error: Index '-2147483648' of dimension 1 of array 'cx' below 
lower bound of 0

 

Error termination. Backtrace:

 

Could not print backtrace: libbacktrace could not find executable to open

#0 0x

#1 0x

#2 0x

#3 0x

#4 0x

#5 0x

#6 0x

#7 0x

#8 0x

#9 0x

#10 0x

#11 0x

#12 0x

#13 0x

 

 = = = =

73,

Rich - K1HTV

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] [HL2WA] Request of 80m band review for FT4 frequency - 160m comments

2019-05-01 Thread Grant VK5GR
George, Kyu and others,

 

160m is a right PITA actually because the band plan structure there varies 
wildly by region and many countries have restrictions on what they can access.

 

The digital segment for 160 in at least region 2 and 3 (Americas and 
Asia/Pacific) is actually 1800-1810kHz! Many countries in the Asia Pacific also 
do not have access to the whole band also (HL has 25kHz, JA is not much better, 
VK only has 75kHz etc). In region 1, the band doesn’t even start until 1810kHz 
in many countries. So what to do?

 

Originally I had been researching pushing IARU to assign 1810kHz as an FT8 
watering hole globally. The problem is that Japanese operators can strictly 
only use CW on that band segment. Short of convincing the Japanese equivalent 
of OFCOM/FCC/ACMA to allow JA hams digital modes above 1810kHz that was not 
going to work. For sure there would be some CW resistance to an 1810kHz digital 
signal channel as well. Mind you, in Region 3 there is a lot of resistance to 
going any higher than 1840 as well (at 75kHz there isn’t enough room for what 
we do have today) and going below 1836kHz will certainly eat into the more 
popular section of the CW band (which apart from contests appears to be 
1815-1835kHz). I don’t think it fair to push into what is active prime CW 
territory.

 

Is there a good solution for 160m you might ask? Probably not. Is there some 
sort of case for a regional based approach? Yes. If we can push IARU to raise 
the digital segment up to say 1816kHz (from the current 1800-1810)  in exchange 
perhaps for FT8 QSYing away from 1840kHz completely – is that something to 
consider? 

 

For example, say 1810kHz for FT8 and 1813kHz for FT4, and on 160m (only) allow 
the FT8 frequency to be shared with F/H activity (or perhaps F/H FT8 stays on 
1840?) Is that something that might work? It would maximise the number of 
countries that could access a harmonised single 160m channel (excluding for now 
JA – perhaps they can lobby their regulator?). 

 

Failing that, again consider my earlier comments on 40m about JT65 and JT9  
sharing, in this case on 1836 and put FT4 on 1838 – noting that locks the HL 
and JA  amateurs out of the band? Going near 1815-1830 will cause significant 
anger from the CW community for sure. 1810-1815 – will too but hopefully less 
so.

 

For discussion – not an easy one to solve.

 

Regards,

Grant VK5GR

 

 

 

From: George J. Molnar [mailto:geo...@molnar.tv] 
Sent: Wednesday, 1 May 2019 10:52 PM
To: WSJT software development
Subject: Re: [wsjt-devel] [HL2WA] Request of 80m band review for FT4 frequency

 

The bottom 25 kHz of each band generally are used pretty heavily for CW DX, 
with DXpeditions often in the xx30 to xx40 range. I would encourage keeping 
away from that space to avoid conflict.

 

Geo/KF2T

 

 





On May 1, 2019, at 8:36 AM, 이동규  wrote:

 

Hi, Bill (G4WJS)

 

Thank you for your kind and quick email reply.

 

About 80m band FT4 frequency 3.523MHz and I think Korean DX members are very 
positive.

 

We will respond to your opinions in a short period of time by collecting 
opinions from Korean HAMs.

In addition, we request a review to be able to assign the 60m Band to 1.822 KHz 
or another frequency( ex) 1819 , 1820)  from 1.800 to 1.825 MHz.

 

de HL2WA ( KYU )

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Waterfall with FT4

2019-05-01 Thread Bill Somerville

On 01/05/2019 14:23, Black Michael via wsjt-devel wrote:

Would be nice if the waterfall settings were by-mode.
In particular the short FT4 sequences require NAvg=1 to see the time 
stamps where that NAvg is too fast for FT8.


So a by-mode remembrance of at least the NAvg would be handy.

de Mike W9MDB


Hi Mike,

as with most other settings queries, the best way to deal with this is 
to use a separate configuration for FT4 mode.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Waterfall with FT4

2019-05-01 Thread Black Michael via wsjt-devel
Would be nice if the waterfall settings were by-mode.In particular the short 
FT4 sequences require NAvg=1 to see the time stamps where that NAvg is too fast 
for FT8.
So a by-mode remembrance of at least the NAvg would be handy.
de Mike W9MDB

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] [HL2WA] Request of 80m band review for FT4 frequency

2019-05-01 Thread George J. Molnar
The bottom 25 kHz of each band generally are used pretty heavily for CW DX, 
with DXpeditions often in the xx30 to xx40 range. I would encourage keeping 
away from that space to avoid conflict.

Geo/KF2T



> On May 1, 2019, at 8:36 AM, 이동규  wrote:
> 
> Hi, Bill (G4WJS)
>  
> Thank you for your kind and quick email reply.
> 
> About 80m band FT4 frequency 3.523MHz and I think Korean DX members are very 
> positive.
> 
> We will respond to your opinions in a short period of time by collecting 
> opinions from Korean HAMs.
> In addition, we request a review to be able to assign the 60m Band to 1.822 
> KHz or another frequency( ex) 1819 , 1820)  from 1.800 to 1.825 MHz.
>  
> de HL2WA ( KYU )

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] [HL2WA] Request of 80m band review for FT4 frequency

2019-05-01 Thread 이동규
Hi, Bill (G4WJS)
 
Thank you for your kind and quick email reply.

About 80m band FT4 frequency 3.523MHz and I think Korean DX members are very 
positive.

We will respond to your opinions in a short period of time by collecting 
opinions from Korean HAMs.
In addition, we request a review to be able to assign the 60m Band to 1.822 KHz 
or another frequency( ex) 1819 , 1820)  from 1.800 to 1.825 MHz.
 
de HL2WA ( KYU )
 
http://qrz.com/db/hl2wa
--
Without haste , Without waste~~!!
 
-Original Message-
From: "Bill Somerville"
To: "이동규"; ; 
; ;
Cc:
Sent: 2019-05-01 (수) 19:19:43 (GMT+09:00)
Subject: Re: [HL2WA] Request of 80m band review for FT4 frequency
 
On 01/05/2019 08:53, 이동규 wrote:

I applaud your wonderful new communication modes FT8, FT4 ... great 
development. And, thank you very much.
 
For Korea (HL), the operating frequency range of 80m Band is 3.500 ~ 3.550MHz 
according to Korean Radio Law.
 
When selecting the FT4 frequency, please request to select 3.547MHz or 3.523MHz.
If set to 3.567MHz as per the basic plan, no Korean HAM can be used.

Once again, I am deeply grateful for your new mode development.

de HL2WA (KYU) 
 
http://qrz.com/db/hl2wa
--
Without haste , Without waste~~!!

Hi KYU,
thanks for you suggestions. We strive to suggest working frequencies which are 
globally coordinated, in IARU regions 1 and 2 the band plans mandate CW only 
below 3570 kHz so it is not possible use frequencies below that worldwide. We 
do have a capability in WSJT-X to set IARU region specific working frequencies 
and for 80m we currently propose 3570 kHz as it is suitable for JA operators 
being within their licensed allocation. Looking at the HL band plan it seems 
that 3523 kHz is better than 3547 kHz because it is within the 3520 - 3525 kHz 
digital modes section. I note that 3525 kHz is designated as an emergency 
communications frequency, I assume this is LSB, will that cause issues if we 
suggest 3523 kHz USB for FT4 operation?
73
Bill
G4WJS.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Abruption

2019-05-01 Thread Jari A
[image: image.png]

[image: image.png]




I was at normal FT4 CQ play, had several qsos, then M0IEP return with EU
contest mode and while I change to contest mode on the run, occasion ended
with crash. *.wav suppose to be available if needed.
Windows 7 Pro, 64-bit

Best regards,

:Jari / oh2fqv

---
190501_12273014.080 Tx FT4  0  0.0 1081 CQ OH2FQV
KP20
190501_12273614.080 Rx FT4  3  0.2  621 N0FW US2MA 73
190501_12273614.080 Rx FT4 -1 -0.4  939 CQ CT7AIX IM59
190501_12273614.080 Rx FT4  9 -0.1 1081 OH2FQV M0IEP 539 0001
190501_12273614.080 Rx FT4 13  0.0 1479 OZ5AGJ N4YDU +04
190501_12273614.080 Rx FT4 20  0.0 1817 OH6MR JR4OZR 73
190501_12274214.080 Tx FT4  0  0.0 1081 CQ OH2FQV
KP20
190501_12274814.080 Rx FT4  7 -0.1 1081 OH2FQV M0IEP 539 0001
190501_12274814.080 Rx FT4 12  0.1 1479 OZ5AGJ N4YDU RR73
190501_12274814.080 Rx FT4 19  0.0 1818 UX0ZAB JR4OZR -11
190501_12275414.080 Tx FT4  0  0.0 1081 M0IEP OH2FQV
R+09
190501_12280014.080 Rx FT4 -1 -0.2 1081 OH2FQV M0IEP 539 0001
190501_12280014.080 Rx FT4 11  0.0 1817 UX0ZAB JR4OZR -11
190501_12280614.080 Tx FT4  0  0.0 1081 M0IEP OH2FQV
R+07
190501_12280614.080 Tx FT4  0  0.0 1081 M0IEP OH2FQV
R-01
190501_12281514.080 Tx FT8  0  0.0 1081 M0IEP R 550001
KP20MF
190501_12283014.080 Tx FT4  0  0.0 1081 M0IEP R 550001
KP20MF
190501_12283614.080 Rx FT4  3  0.2  621 R1CAV US2MA 73
190501_12283614.080 Rx FT4  5 -0.2  799 CQ M6OZR IO92
190501_12283614.080 Rx FT4 -6 -0.0 1005 OZ5AGJ IT9CIL -03
190501_12283614.080 Rx FT4 -4 -0.3 1188 N0FW UT0HB R-05
190501_12283614.080 Rx FT4  3  0.1 1479 CQ N4YDU FM06
190501_12283614.080 Rx FT4 14  0.0 1817 RV9WF JR4OZR R-06
190501_12283614.080 Rx FT4 15 -0.1 1890 UT4UQ PC5W RR73
190501_12283614.080 Rx FT4  4 -0.1 2391 SP8MTA HL5BLI -09
190501_12284214.080 Tx FT4  0  0.0 1081 M0IEP R 550001
KP20MF
190501_12284814.080 Rx FT4 -1 -0.1  799 OH6MR M6OZR R-03
190501_12284814.080 Rx FT4 11 -0.2 1080 OH2FQV M0IEP RR73
190501_12284814.080 Rx FT4 -8  0.2 1344 N0FW YO7LGI KN14
190501_12284814.080 Rx FT4 10  0.1 1479 CQ N4YDU FM06
190501_12284814.080 Rx FT4  7 -0.1 2391 SP8MTA HL5BLI -09
190501_12284814.080 Rx FT4 -5 -0.4 2537 F5SGS CT7AIX -13
190501_12285414.080 Tx FT4  0  0.0 1081 M0IEP OH2FQV
73



I was at normal FT4 CQ play, had several qsos, then M0IEP return with EU
contest mode and while I change to contest mode on the run, occasion ended
with crash.
Windows 7 Pro, 64-bit
---
190501_12273014.080 Tx FT4  0  0.0 1081 CQ OH2FQV
KP20
190501_12273614.080 Rx FT4  3  0.2  621 N0FW US2MA 73
190501_12273614.080 Rx FT4 -1 -0.4  939 CQ CT7AIX IM59
190501_12273614.080 Rx FT4  9 -0.1 1081 OH2FQV M0IEP 539 0001
190501_12273614.080 Rx FT4 13  0.0 1479 OZ5AGJ N4YDU +04
190501_12273614.080 Rx FT4 20  0.0 1817 OH6MR JR4OZR 73
190501_12274214.080 Tx FT4  0  0.0 1081 CQ OH2FQV
KP20
190501_12274814.080 Rx FT4  7 -0.1 1081 OH2FQV M0IEP 539 0001
190501_12274814.080 Rx FT4 12  0.1 1479 OZ5AGJ N4YDU RR73
190501_12274814.080 Rx FT4 19  0.0 1818 UX0ZAB JR4OZR -11
190501_12275414.080 Tx FT4  0  0.0 1081 M0IEP OH2FQV
R+09
190501_12280014.080 Rx FT4 -1 -0.2 1081 OH2FQV M0IEP 539 0001
190501_12280014.080 Rx FT4 11  0.0 1817 UX0ZAB JR4OZR -11
190501_12280614.080 Tx FT4  0  0.0 1081 M0IEP OH2FQV
R+07
190501_12280614.080 Tx FT4  0  0.0 1081 M0IEP OH2FQV
R-01
190501_12281514.080 Tx FT8  0  0.0 1081 M0IEP R 550001
KP20MF
190501_12283014.080 Tx FT4  0  0.0 1081 M0IEP R 550001
KP20MF
190501_12283614.080 Rx FT4  3  0.2  621 R1CAV US2MA 73
190501_12283614.080 Rx FT4  5 -0.2  799 CQ M6OZR IO92
190501_12283614.080 Rx FT4 -6 -0.0 1005 OZ5AGJ IT9CIL -03
190501_12283614.080 Rx FT4 -4 -0.3 1188 N0FW UT0HB R-05
190501_12283614.080 Rx FT4  3  0.1 1479 CQ N4YDU FM06
190501_12283614.080 Rx FT4 14  0.0 1817 RV9WF JR4OZR R-06
190501_12283614.080 Rx FT4 15 -0.1 1890 UT4UQ PC5W RR73
190501_12283614.080 Rx FT4  4 -0.1 2391 SP8MTA HL5BLI -09
190501_12284214.080 Tx FT4  0  0.0 1081 M0IEP R 550001
KP20MF
190501_12284814.080 Rx FT4 -1 -0.1  799 OH6MR M6OZR R-03
190501_12284814.080 Rx FT4 11 -0.2 1080 OH2FQV M0IEP RR73
190501_12284814.080 Rx FT4 -8  0.2 1344 N0FW YO7LGI KN14
190501_12284814.080 Rx FT4 10  0.1 1479 CQ N4YDU FM06
190501_12284814.080 Rx FT4  7 -0.1 2391 SP8MTA HL5BLI -09
190501_12284814.080 Rx FT4 -5 -0.4 2537 F5SGS CT7AIX -13
190501_12285414.080 Tx FT4  0  0.0 1081 M0IEP OH2FQV
73
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] ft4 input level

2019-05-01 Thread Bill Somerville

On 01/05/2019 12:45, Zeljko Draskovic wrote:

Dear developers,

Thanks for giving us such a useful piece of software

I am experiencing bug with 2.1.0-rc5. If I start program in FT4 mode 
(last used) or on first change to FT4 input level on computer/USB 
codec input go to 100 which results in input overload (red bar). My 
usual input level is 20


HP Omen 15
Windows 10 Pro
Icom IC-7300  with single USB cable

If there is anything else you need, please let me know

Best regards,

Zeljko 4O6ZD


Hi Zeljko,

please re-read the release announcement for WSJT-X v2.1.0 RC5, 
particularly the last two paragraphs.


https://sourceforge.net/p/wsjt/mailman/message/36652916/

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] ft4 input level

2019-05-01 Thread Zeljko Draskovic
Dear developers,

Thanks for giving us such a useful piece of software

I am experiencing bug with 2.1.0-rc5. If I start program in FT4 mode (last
used) or on first change to FT4 input level on computer/USB codec input go
to 100 which results in input overload (red bar). My usual input level is 20

HP Omen 15
Windows 10 Pro
Icom IC-7300  with single USB cable

If there is anything else you need, please let me know

Best regards,

Zeljko 4O6ZD
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Mac OS crash when opening

2019-05-01 Thread Jorge Correia
Hello

I think this is a problem know by de devop team, I only want to testified
that problem occurred with Mojave 10.14.4 and with High Sierra 10.13.6

The wsjtx-2.0.1 is still working fine.

Looking forward and anxious to try FT4 on my macs :-)

Thanks and good work

73 - Jorge - CT7AKW
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] [HL2WA] Request of 80m band review for FT4 frequency

2019-05-01 Thread Bill Somerville

On 01/05/2019 08:53, 이동규 wrote:


*I applaud your wonderful new communication modes FT8, FT4 ... great 
development. And, thank you very much.*


*For Korea (HL), the operating frequency range of 80m Band is 3.500 ~ 
3.550MHz according to Korean Radio Law.*


*When selecting the FT4 frequency, please request to select 3.547MHz 
or 3.523MHz.*


*If set to 3.567MHz as per the basic plan, no Korean HAM can be used.*

*
*

*Once again, I am deeply grateful for your new mode development.*

*
*

*de HL2WA (KYU)*

http://qrz.com/db/hl2wa
--
Without haste , Without waste~~!!


Hi KYU,

thanks for you suggestions. We strive to suggest working frequencies 
which are globally coordinated, in IARU regions 1 and 2 the band plans 
mandate CW only below 3570 kHz so it is not possible use frequencies 
below that worldwide. We do have a capability in WSJT-X to set IARU 
region specific working frequencies and for 80m we currently propose 
3570 kHz as it is suitable for JA operators being within their licensed 
allocation. Looking at the HL band plan it seems that 3523 kHz is better 
than 3547 kHz because it is within the 3520 - 3525 kHz digital modes 
section. I note that 3525 kHz is designated as an emergency 
communications frequency, I assume this is LSB, will that cause issues 
if we suggest 3523 kHz USB for FT4 operation?


73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel