Re: [wsjt-devel] Bug Report

[David Tiller via wsjt-devel]

Jason,

This sounds like a textbook example of RFI getting into your computer or USB 
cable. I had a similar issue on 80m and found that a few well-placed ferrites 
on my USB cable fixed the issue.

Search for "FT8 RFI" for other folks advice.

To verify, try transmitting into a dummy load or at _very_ low power. If it 
doesn't happen, you've proven it's due to RFI.


> On May 9, 2022, at 10:25 AM, W2JDM via wsjt-devel 
>  wrote:
> 
>  
> WSJTX Version: 2.5.4
> OS – Mac Monterey 12.3.1
> Radio – Yaesu 991A
> SiliconLabs Driver – 6.0.2 for Mac
>  
> When tuned to 40m (and only 40m), using FT8, the software loses CAT control 
> shortly after transmitting.  The symptoms are that it will hold the transmit 
> too long and eventually show ORANGE status in WSJTX.  It will reset and 
> reconnect, but not after losing the QSO due to timing issues.  This occurs 
> each and every time I transmit on 40m, including when using TUNE.  I want to 
> emphasize that it seems to ONLY occur on 40m and not any other band.  I use 
> other software that also has CAT control over the 991A and it works as 
> designed.
>  
> I have also changed the mode to FT4 and 40m behaves normally.  It seems 
> isolated to only when using FT8 and 40m.
>  
> Please let me know if you need any additional details.
>  
> 73
> Jason – W2JDM
>  
> ___
> 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] want to avoid duplicate/redundant effort: any work done towards integrating HackRF into WSJT-X?

[David Tiller via wsjt-devel]

If your use case is compatible with soapysdr, I’d suggest adding support for 
that; it supports a lot of SDRs. 

Are you also going to try to implement sdr audio? That’s a different kettle of 
fish. 

> On Feb 13, 2022, at 18:00, William Smith via wsjt-devel 
>  wrote:
> 
> Looks like it’s _not_ in Hamlib, which is probably where you want to add it, 
> so wsjt and others will pick it up.
> 
> https://hamlib.github.io
> 
> 73, Willie N1JBJ
> 
> 
>> On Feb 13, 2022, at 5:35 PM, Lillian Kish via wsjt-devel 
>>  wrote:
>> 
>> I want to add direct rig control for the HackRF SDR into WSJT.
>> 
>> Before I go and reinvent the wheel, i want to ask if any work has been done 
>> on this before? 
>> 
>> Thanks!
>> 
>> 
>> ___
>> 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] Additional info on WSJT-X arrow size discrepancy

[David Tiller via wsjt-devel]

Very interesting. I have these font-y lines in my .ini file. I take it the 
first is for astronomical data, the second for the RX lists, and the last for 
the rest of the UI. 

Now that I know where I can manually revert things, I'll try a few fonts.

Thanks!

[Astro]
font="Courier,18,-1,5,50,0,0,0,0,0"

[Configuration]
DecodedTextFont="Courier,10,-1,5,50,0,0,0,0,0"
Font=".Lucida Grande UI,13,-1,5,50,0,0,0,0,0"


> On Jan 15, 2022, at 3:30 PM, Alex Lelievre via wsjt-devel 
>  wrote:
> 
> Hi David,
> 
> I think that the font panel doesn’t show the font when .AppleSystemUIFont is 
> the selected font.  You can look inside the WSJT-X.ini file to see what font 
> you have selected.  Offhand, I have it set to 12 point.   The ini file is in 
> ~/Library/Preferences/WSJT-X.ini.
> 
> alex K6LOT
> 
> 
>> On Jan 15, 2022, at 5:08 AM, David Tiller via wsjt-devel 
>>  wrote:
>> 
>> Alex,
>> 
>> Thanks again for the reply - I must be an idiot; I searched for a font 
>> chooser in WSJT-X before I went on the OS font wild goose chase. I didn't 
>> even see that!
>> 
>> Interestingly, when I click on 'Font', it shows the following - note that no 
>> Family is selected (I scrolled all the way down - nada)!!! Do you know what 
>> it's supposed to be, or at least what you have selected for a font?
>> 
>> 73, K4DET
>> 
>> 
>> 
>>> On Jan 14, 2022, at 9:53 PM, Alex Lelievre via wsjt-devel 
>>>  wrote:
>>> 
>>> Hi David,
>>> 
>>> You want to take a look at the font for WSJT-X, I was thinking perhaps you 
>>> changed it in order to reproduce this bug.
>>> 
>>> Here’s where to look (in the Preferences for WSJT-X):
>>> 
>>> 
>>> 
>>> alex K6LOT
>>> 
>>>> On Jan 14, 2022, at 6:13 PM, David Tiller via wsjt-devel 
>>>>  wrote:
>>>> 
>>>> Alex,
>>>> 
>>>> Thanks for the reply. 
>>>> 
>>>> I'm not sure where in OSX 10.13.6 to look, but according to this page ( 
>>>> https://apple.stackexchange.com/questions/12661/whats-the-font-in-mac-os-xs-gui
>>>>  ) the default font is San Francisco. I don't think I've changed it.
>>>> 
>>>> I cannot find SanFrancisco listed anywhere in the choices available to 
>>>> TextEdit, but I do see a lot of files named SF*.otf in 
>>>> /System/Library/Fonts which I assume are San Francisco OpenType font 
>>>> files. I also see SF OpenType fonts listed in SystemInformation/Fonts with 
>>>> many in the family "System Font" - all mention SanFrancisco in the 
>>>> Copyright.
>>>> 
>>>> Lucida Grande displays the two arrows with different sizes.
>>>> 
>>>> If you'd like to take this offline from the group, email me at mycall @ 
>>>> arrl . net.
>>>> 
>>>> Thanks!
>>>> 
>>>> 
>>>> 
>>>>> On Jan 14, 2022, at 2:58 PM, Alex Lelievre via wsjt-devel 
>>>>>  wrote:
>>>>> 
>>>>> Hi David,
>>>>> 
>>>>> What font do you have your UI set to?  That could have some effect.
>>>>> 
>>>>> alex K6LOT
>>>>> 
>>>>>> On Jan 14, 2022, at 11:00 AM, David Tiller via wsjt-devel 
>>>>>>  wrote:
>>>>>> 
>>>>>> Dear devs,
>>>>>> 
>>>>>> I know this is a very minor issue, but I'd like to pass on some 
>>>>>> additional info I've found.
>>>>>> 
>>>>>> The issue is this: Using WSJT-X 2.5.4 under OSX 10.13.6, the arrows on 
>>>>>> the 'Set TX freq to RX freq' and 'Set RX freq to TX freq' buttons are 
>>>>>> not the same size.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> As you can see, the up-arrow button is much larger than the down-arrow, 
>>>>>> even though the arrow glyph itself seems smaller.
>>>>>> 
>>>>>> I found the definitions of the buttons 'pbT2R' and 'pbR2T' in 
>>>>>> https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/widgets/mainwindow.ui
>>>>>>  - the definitions are identical except that on my Mac, the UTF-8 
>>>>>> characters used to represent the arrows are not rendering to the same 
>>>>>> size. The misrendering shows on the page at SF in chrome and Safari as 
>>>>>> well as if

Re: [wsjt-devel] Additional info on WSJT-X arrow size discrepancy

[David Tiller via wsjt-devel]

Alex,

Thanks for the reply. 

I'm not sure where in OSX 10.13.6 to look, but according to this page ( 
https://apple.stackexchange.com/questions/12661/whats-the-font-in-mac-os-xs-gui 
<https://apple.stackexchange.com/questions/12661/whats-the-font-in-mac-os-xs-gui>
 ) the default font is San Francisco. I don't think I've changed it.

I cannot find SanFrancisco listed anywhere in the choices available to 
TextEdit, but I do see a lot of files named SF*.otf in /System/Library/Fonts 
which I assume are San Francisco OpenType font files. I also see SF OpenType 
fonts listed in SystemInformation/Fonts with many in the family "System Font" - 
all mention SanFrancisco in the Copyright.

Lucida Grande displays the two arrows with different sizes.

If you'd like to take this offline from the group, email me at mycall @ arrl . 
net.

Thanks!



> On Jan 14, 2022, at 2:58 PM, Alex Lelievre via wsjt-devel 
>  wrote:
> 
> Hi David,
> 
> What font do you have your UI set to?  That could have some effect.
> 
> alex K6LOT
> 
>> On Jan 14, 2022, at 11:00 AM, David Tiller via wsjt-devel 
>> mailto:wsjt-devel@lists.sourceforge.net>> 
>> wrote:
>> 
>> Dear devs,
>> 
>> I know this is a very minor issue, but I'd like to pass on some additional 
>> info I've found.
>> 
>> The issue is this: Using WSJT-X 2.5.4 under OSX 10.13.6, the arrows on the 
>> 'Set TX freq to RX freq' and 'Set RX freq to TX freq' buttons are not the 
>> same size.
>> 
>> 
>> 
>> As you can see, the up-arrow button is much larger than the down-arrow, even 
>> though the arrow glyph itself seems smaller.
>> 
>> I found the definitions of the buttons 'pbT2R' and 'pbR2T' in 
>> https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/widgets/mainwindow.ui 
>> <https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/widgets/mainwindow.ui> 
>> - the definitions are identical except that on my Mac, the UTF-8 characters 
>> used to represent the arrows are not rendering to the same size. The 
>> misrendering shows on the page at SF in chrome and Safari as well as if you 
>> cut-and-paste into a unicode-aware editor (TextEdit, Pages, etc).
>> 
>> I also noted that when the text from the above page (rendered in chrome) is 
>> pasted into TextEdit, the font used for the majority of the text is 
>> Courier/Regular/14. The font for the up-arrow character switches to Courier 
>> New/Regular/14. The down-arrow, however, does NOT seem to trigger a switch 
>> to Courier New/Regular 14, rather it shows as 'Fixed/14' with no typeface 
>> chosen. If I force the down-arrow font to Courier New/Regular/14, the glyph 
>> changes to the same size as the up arrow. I cannot force the down-arrow font 
>> to Courier/Regular/14 - it will not accept that, as if the glyph is not in 
>> that font.
>> 
>> Something is afoot with font handling on OSX. I tried a few other fonts in 
>> TextEdit:
>> 
>> Fonts that render the arrows with different sizes: American Typewriter, 
>> Avenir, Courier, Bank Gothic, Baskerville, Bodoni, Cochin, Copperplate, etc
>> 
>> Fonts that render the arrows with the same size: Andale Mono, Arial, 
>> Chalkboard, Comic Sans, Courier New, Times New Roman, etc
>> 
>> Unfortunately the other up- and down-arrows in the unicode space (23F6, 
>> 23F7, 2BC5, 2BC6) are in miscellaneous pages that are seemingly not present 
>> in many fonts. 
>> 
>> Image clip of definition of the SMALL UP ARROW:
>> 
>> 
>> 
>> Image clip of definition of the LARGE DOWN ARROW:
>> 
>> 
>> 
>> Thanks for reading this far!
>> 
>> 73, K4DET
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net <mailto: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 2.5.2 cosmetic issue

[David Tiller via wsjt-devel]

All,

I've been running WSJT-X 2.5.2 under OSX 10.13.6 and have noticed that the 
up-pointing arrow for setting the TX freq is abnormally large.

It doesn't seem related to the size of the main window or whether or not it (or 
the down arrow) has been clicked.

Thanks and 73 - K4DET

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

Re: [wsjt-devel] Message Bit to Request Other Station to QSY to your Frequency

[David Tiller]

> On Jul 8, 2021, at 1:21 PM, Gary McDuffie  wrote:
> 
> I find a few of them won’t bother to respond until I’m within a few hundred 
> hertz of them.

You hit the nail on the head with this comment. I think there are still 
operators that insist on using narrow filters and are therefore deaf to callers 
outside their tiny passband. It's annoying to have to jump into the inevitable 
pileup on/near their TX frequency only to be swamped by KW-class stations. 

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

[wsjt-devel] Q65 and split mode - did I miss something?

[David Tiller]

Dear WSJTX authors,

I just tried Q65 with 2.4.0 final (OSX 10.13.6), and so far, so good. I tried 
using split mode with my IC 756PRO and didn't get the same results as I get on 
the other modes; i.e. for TX frequencies below 1500 Hz the TX VFO does NOT 
'drop down' in frequency to ensure the audio going into the radio is >= 1500 
Hz. 

Example that works as expected with FT8:

Split set to 'rig', RX VFO 50.313. When I choose TX freq 500, the TX VFO 
immediately switches to 50.312. 

Example that doesn't work as expected with Q65:

Split set to 'rig', RX VFO 50.275. When I choose any TX frequency, the TX VFO 
_stays_ on 50.275.

If I missed something in the user's guide or quick start guide, please feel 
free to chastise me.

Thanks in advance, K4DET

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

Re: [wsjt-devel] Feature request: Rx level input slider

[David Tiller]

You wrote:

“Tx slider seems unnecessary because every radio (correct me if wrong) allows a 
Tx or drive level reduction on the radio itself).”

That is very much not the case. Many rigs require a different drive level per 
band, something that WSJTX handles perfectly.


> On Mar 14, 2021, at 12:25, David Schmocker  wrote:
> 
> Tx slider seems unnecessary because every radio (correct me if wrong) allows 
> a Tx or drive level reduction on the radio itself).



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

Re: [wsjt-devel] RC2 Report on MacOS 10.14.6 Mojave - Q65_Sync

[David Tiller]

John,

~/Library is usually a hidden directory in the finder. I made a symlink to it 
called 'libr' that I use to get to it via the finder. You can see the Library 
directory in terminal, so if you want to cp the file from a terminal session, 
you can.

To create a symbolic link, in terminal type:

ln -s Library libr

Once created, you can see libr in finder and click into it.

73 de K4DET

> On Mar 6, 2021, at 9:36 AM, John Stengrevics  wrote:
> 
> Hi Bill,
> 
> I can’t find the ~/Library/Preferences/ directory in which to put the file.  
> Can you provide a bit more detail on how I can locate it?  Sorry.
> 
> John
> WA1EAZ
> 
>> On Mar 6, 2021, at 9:20 AM, Bill Somerville > > wrote:
>> 
>> Hi John,
>> 
>> so I can see what is happening put the attached file into the WSJT-X 
>> configuration files directory (~/Library/Preferences/ on macOS), restart 
>> WSJT-X, run a minimal test to demonstrate the issue, then quit WSJT-X (do 
>> not turn off the rig until WSJT-X has exited). There will be a new file on 
>> your Desktop called WSJT-X_RigControl.log, send me that file for analysis 
>> please (g4wjs  classdesign  com)?
>> 
>> Once you have sent me the log file delete the wsjtx_log_config.ini and 
>> WSJT-X_RigControl.log files to resume normal operation.
>> 
>> 73
>> Bill
>> G4WJS.
>> 
>> On 06/03/2021 14:13, John Stengrevics wrote:
>>> Bill,
>>> 
>>> I have CAT selected and it does connect when I click on Test.
>>> 
>>> John (G4KLA) had asked what driver I was using.  I replied that the driver 
>>> had not changed.  It has always been  /dev/cu.usbserial-A503XYAO.
>>> 
>>> John
>>> WA1EAZ
>>> 
 On Mar 6, 2021, at 9:07 AM, Bill Somerville >>> > wrote:
 
 Hi John,
 
 which option do you have checked for "Preferences->Radio->PTT Method"?
 
 73
 Bill
 G4WJS.
 
 On 06/03/2021 14:03, John Stengrevics wrote:
> Hi Bill,
> 
> I just tried to use Q65 with “Cumulative" selected as you suggested.  
> However, the problem is still there as described below.  I have to shut 
> down my transceiver (Elecraft K3S) to get it to stop transmitting.
> 
> Thanks,
> 
> John
> WA1EAZ
> 
>> On Mar 6, 2021, at 8:44 AM, Bill Somerville > > wrote:
>> 
>> Hi John,
>> 
>> I am not sure as I have not investigated this issue yet. It is easy 
>> enough to check, select "Cumulative" for the 2D spectrum display, 
>> restart WSJT-X, and see if the iusse goes away.
>> 
>> 73
>> Bill
>> G4WJS.
>> 
>> On 06/03/2021 13:25, John Stengrevics wrote:
>>> Hi Bill,
>>> 
>>> Will this fix solve the problem I reported yesterday with OS Big Sur?  
>>> I’ll repost below in case you didn’t see it.
>>> 
>>> Thanks,
>>> 
>>> John
>>> WA1EAZ
>>> 
>>> Repost - some additions in red:  
>>> 
>>> John & Joe,
>>> 
>>> I had been using the previous version successfully on a MacBook Pro 
>>> (Intel not M1) OS Big Sur 11.2.2.
>>> 
>>> Today, I downloaded Mac version 2.4.0-rc2.  
>>> 
>>> When running Q65, T/R = 30 seconds, Submode A, the program continues to 
>>> transmit after the 30 second period is complete for 60 seconds total.  
>>> However, it does not seem to drive my amplifier after 30 seconds. [PTT 
>>> is activated for the second 30 seconds, but no audio to drive the amp.] 
>>>  I have since tried FT8 on WSJT-X and can confirm that it works as 
>>> usual.  Thus, the problem seems to be isolated to Q65.
>>> 
>>> I did follow the instructions in the Readme file.  
>>> 
>>> If there is a file I can send you, please let me know.
>>> 
>>> I would appreciate any suggestions you can provide.
>>> 
>>> Best 73,
>>> 
>>> John
>>> WA1EAZ
>>> 
 On Mar 6, 2021, at 5:55 AM, Bill Somerville >>> > wrote:
 
 Hi Dave and Kevin,
 
 we have finally tracked down the cause of this crash, thanks for your 
 patience it was not so easy to track down. It is repaired for the next 
 release, for now if you do not use of the Q65_Sync Wide Graph 
 synchronization plot the crash will be avoided. Note this is not a Mac 
 specific issue although it does seem to have the most severe effects 
 on that platform.
 
 73
 Bill
 G4WJS.
 
 On 06/03/2021 03:59, David Schmocker wrote:
> Hello all,
> 
> A second report that mirrors this one:WSJT-X 2.4.0rc2
> 
> OS 10.14.6,  Mac Mini
> 
> Mode Q65,Waterfall Q65_ Sync selected and slow to let go of PTT 
> line to K3S radio (even after Tx period).   (when I go into Radio 
> Panel, the Test PTT Red bar stays on, won't easily release).

Re: [wsjt-devel] Rc4 Tx levels will cause future QRM problems

[David Tiller]

No wheel, only Mac touchpad (wheel emulation w/ 2 finger slide stinks).  No 
easy page up/down either. 

> On Feb 15, 2021, at 11:24, Larry B. via wsjt-devel 
>  wrote:
> 
> Or the wheel on your mouse.
> 
> 73 -- Larry -- W1DYJ
> 
>  
> From: Bill Somerville
> Sent: Monday, February 15, 2021 10:01
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] Rc4 Tx levels will cause future QRM problems
>  
> Hi David,
>  
> you can already do that by selecting the slider and using the up and down 
> arrow keys. Page up and down for 1 dB increments.
>  
> 73
> Bill
> G4WJS.
>  
>> On 15/02/2021 14:58, David Tiller wrote:
>> You wrote: "How about adding a small "dB' box right under the "Pwr" label"
>> 
>> If you add that (and I hope you do), please make it a spinner box so we can 
>> adjust it with up/down arrows by preferably 0.1 dB increments. 
>> 
>>> On Feb 15, 2021, at 9:35 AM, Rich - K1HTV mailto:k1...@comcast.net wrote:
>>> 
>>> I noticed that while running WSJT-X v2.4.0-rc1, the original WSJT-X "Pwr" 
>>> control setting produced excessive AGC levels on my K3 transceiver. TX 
>>> levels are over 5 dB higher with WSJT-X Version 2.4.0-rc1 than with 
>>> previous versions.
>>> 
>>> Unless a software change is made so TX audio levels match those of previous 
>>> versions of WSJT-X, I'm afraid that we all will be hearing more kazoo 
>>> sounds on the FT8 & FT4 frequencies and will be seeing more and more 
>>> spurious signals on our Wide Graph screens.
>>> 
>>> "Pwr" slider idea:
>>> Would it be possible to change the way to read the "Pwr" slider setting dB 
>>> level?  Presently, users must move the slider setting in order to check the 
>>> dB level,We should be able to read the setting without having to change it.
>>> 
>>> How about adding a small "dB' box right under the "Pwr" label  I think that 
>>> would make more sense than the way it is now. Can this change be 
>>> implemented?
>>> 
>>> 73,
>>> Rich - K1HTV
>  
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> 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] Rc4 Tx levels will cause future QRM problems

[David Tiller]

Bill,

Selecting the slider often changes it, at least on a Mac, so you have no idea 
what the original setting was. Having a way to adjust it without having to be a 
touchpad ninja would help.


> On Feb 15, 2021, at 10:01 AM, Bill Somerville  wrote:
> 
> Hi David,
> 
> you can already do that by selecting the slider and using the up and down 
> arrow keys. Page up and down for 1 dB increments.
> 
> 73
> Bill
> G4WJS.
> 
> On 15/02/2021 14:58, David Tiller wrote:
>> You wrote: "How about adding a small "dB' box right under the "Pwr" label"
>> 
>> If you add that (and I hope you do), please make it a spinner box so we can 
>> adjust it with up/down arrows by preferably 0.1 dB increments. 
>> 
>>> On Feb 15, 2021, at 9:35 AM, Rich - K1HTV  
>>> <mailto:k1...@comcast.net> wrote:
>>> 
>>> I noticed that while running WSJT-X v2.4.0-rc1, the original WSJT-X "Pwr" 
>>> control setting produced excessive AGC levels on my K3 transceiver. TX 
>>> levels are over 5 dB higher with WSJT-X Version 2.4.0-rc1 than with 
>>> previous versions.
>>> 
>>> Unless a software change is made so TX audio levels match those of previous 
>>> versions of WSJT-X, I'm afraid that we all will be hearing more kazoo 
>>> sounds on the FT8 & FT4 frequencies and will be seeing more and more 
>>> spurious signals on our Wide Graph screens.
>>> 
>>> "Pwr" slider idea:
>>> Would it be possible to change the way to read the "Pwr" slider setting dB 
>>> level?  Presently, users must move the slider setting in order to check the 
>>> dB level,We should be able to read the setting without having to change it.
>>> 
>>> How about adding a small "dB' box right under the "Pwr" label  I think that 
>>> would make more sense than the way it is now. Can this change be 
>>> implemented?
>>> 
>>> 73,
>>> Rich - K1HTV
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

Re: [wsjt-devel] Rc4 Tx levels will cause future QRM problems

[David Tiller]

Bill,

I don't know about anyone else's setup, but my max power, no ALC power slider 
values are radically different per band. There is no one analog drive level 
adjustment on my interface (RigExpert Standard) that'll give reasonable power 
levels on all bands. My rig is a 756PRO, BTW.

> On Feb 15, 2021, at 10:05 AM, Bill Somerville  wrote:
> 
> On 15/02/2021 14:35, Rich - K1HTV wrote:
>> I noticed that while running WSJT-X v2.4.0-rc1, the original WSJT-X "Pwr" 
>> control setting produced excessive AGC levels on my K3 transceiver. TX 
>> levels are over 5 dB higher with WSJT-X Version 2.4.0-rc1 than with previous 
>> versions.
>> 
>> Unless a software change is made so TX audio levels match those of previous 
>> versions of WSJT-X, I'm afraid that we all will be hearing more kazoo sounds 
>> on the FT8 & FT4 frequencies and will be seeing more and more spurious 
>> signals on our Wide Graph screens.
>> 
>> "Pwr" slider idea:
>> Would it be possible to change the way to read the "Pwr" slider setting dB 
>> level?  Presently, users must move the slider setting in order to check the 
>> dB level,We should be able to read the setting without having to change it.
>> 
>> How about adding a small "dB' box right under the "Pwr" label  I think that 
>> would make more sense than the way it is now. Can this change be implemented?
>> 
>> 73,
>> Rich - K1HTV
> 
> Rich,
> 
> everyone should be setting their equipment used with WSJT-X to give maximum 
> clean output when the Pwr slider is at the top (0dB attenuation).
> 
> The output levels have not changed, have you checked your setup, particularly 
> the master sound card output level and the per application mixer level fro 
> WSJT-X?
> 
> See https://wsjtx.groups.io/g/main/message/13890 for a recipe for setting Tx 
> audio levels correctly.
> 
> 73
> Bill
> G4WJS.
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



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

Re: [wsjt-devel] Rc4 Tx levels will cause future QRM problems

[David Tiller]

You wrote: "How about adding a small "dB' box right under the "Pwr" label"

If you add that (and I hope you do), please make it a spinner box so we can 
adjust it with up/down arrows by preferably 0.1 dB increments. 

> On Feb 15, 2021, at 9:35 AM, Rich - K1HTV  wrote:
> 
> I noticed that while running WSJT-X v2.4.0-rc1, the original WSJT-X "Pwr" 
> control setting produced excessive AGC levels on my K3 transceiver. TX levels 
> are over 5 dB higher with WSJT-X Version 2.4.0-rc1 than with previous 
> versions.
> 
> Unless a software change is made so TX audio levels match those of previous 
> versions of WSJT-X, I'm afraid that we all will be hearing more kazoo sounds 
> on the FT8 & FT4 frequencies and will be seeing more and more spurious 
> signals on our Wide Graph screens.
> 
> "Pwr" slider idea:
> Would it be possible to change the way to read the "Pwr" slider setting dB 
> level?  Presently, users must move the slider setting in order to check the 
> dB level,We should be able to read the setting without having to change it.
> 
> How about adding a small "dB' box right under the "Pwr" label  I think that 
> would make more sense than the way it is now. Can this change be implemented?
> 
> 73,
> Rich - K1HTV
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



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

Re: [wsjt-devel] TS-450S

[David Tiller]

Also, the CP2012 is not 5v tolerant. 
https://www.sparkfun.com/datasheets/IC/cp2102.pdf

> On Feb 8, 2021, at 3:33 PM, Black Michael via wsjt-devel 
>  wrote:
> 
> Hmmm..that's 4-wire...so ground, tx, rx, and 5V and wouldn't work with 
> hardware flow control.
> 
> Mike W9MDB
> 
> 
> 
> 
> On Monday, February 8, 2021, 01:33:11 PM CST, August Treubig 
>  wrote:
> 
> 
> A din 6 pin and this will work fine.
> 
> https://www.adafruit.com/product/954 
> 
> No magic.  Just a bit of soldering.
> Aug
> AG5AT 
> 
> Sent from my iPad
> 
>> On Feb 8, 2021, at 1:02 PM, Bill Somerville  wrote:
>> 
> 
>> 
> 
> Hi Mike,
> 
> there are several third-party replacements for the now unavailable IF-232C 
> module that is needed on this and other early Kenwood rigs. Most faithfully 
> replicate the original IF-232C, some may not. The manual is almost certainly 
> correct, the reporter, if he is correct, almost certainly has a non-standard 
> IF-232C replacement.
> 
> 73
> Bill
> G4WJS.
> 
> On 08/02/2021 18:17, Black Michael via wsjt-devel wrote:
>> The dude said "manual is wrong".
>> 
>> Trying to get more information on serial cable to see if that's the cause.
>> 
>> Old thread noticed a difference between cable types on a 450.  Might have to 
>> do with RTS/CTS wiring differences and whether the cable supports hardware 
>> flow control.
>> 
>> https://wsprnet.org/drupal/node/1307 
>> 
>> Mike W9MDB
>> 
>> 
>> On Monday, February 8, 2021, 12:06:48 PM CST, Bill Somerville 
>>   wrote:
>> 
>> 
>> On 08/02/2021 17:45, Black Michael via wsjt-devel wrote:
>> 
>> > Anybody with a TS-450S out there that is available for some testing?
>> >
>> > I've got somebody claiming it needs 1 stop bit and XONXOFF handshake 
>> > which I've never heard before and 2 stop bits and HARDWARE handshake 
>> > is the default setup and has been for years.
>> >
>> > Mike W9MDB
>> 
>> Mike,
>> 
>> 
>> according to the TS-450S/TS-690S CAT programming manual it is full 
>> duplex 4800 baud 8N2 with RTS/CTS flow control using TTL signal levels. 
>> I would be very surprised if that information was incorrect!
>> 
>> 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

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

Re: [wsjt-devel] wsjtx v2.3-rc4 TX6 oddity

[David Tiller]

I have seen the same behavior and haven't been able to nail down what triggers 
it either.

> On Jan 30, 2021, at 8:08 AM, Alan Groups  wrote:
> 
> I changed the text message in Tx6 by adding a call prefix  so it became "CQ 
> JA..."
> 
> Worked OK until I tried to change it back to just "CQ" - then the change 
> wouldn't stick.  It kept reverting to "CQ JA" several times, but eventually 
> it did hold.
> 
> Not sure what happened, but I may have been a bit quick and initially changed 
> it at the tail end of a TX slot.  Haven't been able to replicate it in 
> subsequent testing but just mentioning it as something clearly got tangled up.
> 
> In trying to replicate that I also managed to transmit "CQ J..." when the 
> code obviously read the message while I was in the middle of typing JA!
> 
> Incidentally while I was being received in JA no QSO resulted from the above 
> messing about - band opening closed!
> 
> Hope that helps.
> 
> Alan G0TLK
> 
> 
> 
> ___
> 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] Release Candidate: WSJT-X 2.3.0-rc1

[David Tiller]

Bill,

Thanks for the thoughtful and informative reply.

In the US, the regs https://www.law.cornell.edu/cfr/text/47/97.119 
<https://www.law.cornell.edu/cfr/text/47/97.119> state (** emphasis added **):

§ 97.119 Station identification.
(a) Each amateur station, except a space station or telecommand station, must 
transmit its assigned call sign on its transmitting channel at the end of each 
communication, ** and at least every 10 minutes during a communication**, for 
the purpose of clearly making the source of the transmissions from the station 
known to those receiving the transmissions. No station may transmit 
unidentified communications or signals, or transmit as the station call sign, 
any call sign not authorized to the station.

(b) The call sign must be transmitted with an emission authorized for the 
transmitting channel in one of the following ways:

(1) By a CW emission. When keyed by an automatic device used only for 
identification, the speed must not exceed 20 words per minute;

(2) By a phone emission in the English language. Use of a phonetic alphabet as 
an aid for correct station identification is encouraged;

(3) By a RTTY emission using a specified digital code when all or part of the 
communications are transmitted by a RTTY or data emission;

(4) By an image emission conforming to the applicable transmission standards, 
either color or monochrome, of § 73.682(a) of the FCC Rules when all or part of 
the communications are transmitted in the same image emission

b(1) is what I suggested. 

b(3) is applicable, but naturally you'd have to use some 'specified digital 
code' in addition to the signal you're trying to ID. RTTY would be way too wide 
- maybe a faster narrowband mode? It would be funny to ID a slow FST4 
transmission with a simultaneous fast FST4 transmission down-band. 

b(2) and b(4) are not applicable unless you want an unholy mess.

> On Sep 28, 2020, at 10:24 AM, Bill Somerville  wrote:
> 
> Hi David,
> 
> I am not sure of the exact FCC regulations. Here I believe sending a callsign 
> at the start and end of a QSO may be sufficient.
> 
> The callsign is effectively spread throughout the message, the nature of the 
> FEC parity bits is that each contributes to a set of received bits that *may* 
> be used to extract the message, those received bits may or may not include 
> the originally source encoded callsign. It is incorrect to state that the 
> parity bits are a repetition of any part of the original message, at least 
> not as any form of direct copy. this is the nature of parity bits when there 
> are more than one of them. As single parity bit can only be used to detect 
> certain types of errors like single bit errors, with more than one parity bit 
> greater than single bit errors can be detected, and missing (erased) bits can 
> be reconstructed.
> 
> All the standard messages contain the transmitting station callsign or a hash 
> code of it that can be mapped back to the callsign if it has been recently 
> received in full. Think of that like me identifying as WJS for brevity in an 
> ongoing QSO, a not uncommon practice which may or may not be construed as 
> proper identification.
> 
> For reference the relevant condition of the UK licence is this:
> 13 Identification
> 13(1) The Licensee, or, if this Licence is a Full Licence, then any other 
> authorised person
> who uses the Radio Equipment, shall ensure that:
> (a) the station is clearly identifiable at all times;
> (b) the Callsign is transmitted as frequently as is practicable during 
> transmissions, unless
> the specific requirements of Note (g) to the Notes to Schedule 1 of this 
> Licence apply;
> and
> (c) the Callsign is given in voice or other appropriate format consistent 
> with the mode of
> operation.
> The reference to Note (g) refers to this text which only applies when using 
> the 5MHz band:
> (vii) Where the Licensee intends to operate within a “net” (a network), the
> Licensee shall observe the following requirements in relation to the
> transmission of his or her Callsign:
> (a) The Licensee shall transmit the station Callsign when he
> first joins the net and on leaving it;
> (b) subject to sub-clause (c) below, whilst participating in the
> net, the Licensee shall not be required to transmit the
> station Callsign when making contact with other
> participants;
> (c) where the Licensee’s transmissions have been other than
> in speech mode for at least fifteen minutes, the Licensee
> shall transmit his call sign when next he transmits speech.
> 
> 73
> Bill
> G4WJS.
> 
> On 28/09/2020 14:41, David Tiller wrote:
>> Thanks, Joe, K1JT, Steve, K9AN, and Bill, G4WJS for all your hard work and 
>> these new modes.
>> 
>> I don't want to be a stick in the mud and I am not trying t

Re: [wsjt-devel] Release Candidate: WSJT-X 2.3.0-rc1

[David Tiller]

Thanks, Joe, K1JT, Steve, K9AN, and Bill, G4WJS for all your hard work and 
these new modes.

I don't want to be a stick in the mud and I am not trying to stir the pot, but 
is there any issue with modes that transmit for >= 10 minutes and the US 
requirement to ID at least every 10 minutes?  

I don't think part 97.119 addresses IDs that take longer than 10 minutes. 

I admit I don't fully understand all of the details of the transmitted data in 
FT4/FST4, so if I'm off-base, please forgive me (and kindly correct me!). If 
the FEC employed spreads the callsign bits out over the message, then my 
analysis is incorrect from the git-go.

For FST4, if the message bits are symbol-encoded and transmitted in the order 
as shown in the QEX Article on FT4 [See QEX 2020 Jul/Aug, page 7] and assuming 
the sender's callsign is sent as the second c28 call, it looks like in most 
cases the sending callsign is within the first 57 bits of the 77 bit raw 
message.  That means that 57/77 = 74% of the raw message has to be transmitted 
before the sender's callsign is transmitted. That means the longest 
transmission that gets the sender's call in at/under 10 minutes is about 13.5 
minutes or 810 seconds.

If I have the callsigns backwards, then the sender's call is sent first in most 
cases. That makes the longest transmission more like 27.5 minutes, but then the 
last 17.5 minutes of the transmission are unidentified (barring FEC repetition 
of the callsign bits). That means the longest tx in this case would be 20 
minutes - The first 10 are identified in the message and the last 10 would be 
identified by an explicit ID by the operator.

I know this won't be a popular idea, but adding a low power CW ident at a 
standard (low, perhaps sub 100 Hz) frequency in addition to the transmitted 
signal every 10 minutes would unquestionably address this. Remember that the 
requirement is for each station to ID, not to ensure that the ID doesn't clash 
with other ID transmissions. If every FST4 signal over 10 minutes id'ed via CW 
on VFO + 50 Hz, say, that would be sufficient to satisfy 97.119.

Ideas/comments?

Again, I'm just asking the question, please don't shoot the messenger.

> 

> On Sep 27, 2020, at 4:23 PM, Joe Taylor  wrote:
> 
> The first public candidate release of WSJT-X 2.3.0 is now available for 
> download and use by beta testers.  This release is your first chance to
> try two new modes designed especially for use on the LF and MF bands, and to 
> provide feedback to the WSJT Development Team.  The new modes are:
> 
> - FST4, for 2-way QSOs.  Options for sequence lengths from 15 seconds
>   to 30 minutes, with threshold sensitivities from -20.7 to -43.2 dB in
>   a 2500 Hz reference bandwidth.
> 
> - FST4W, for WSPR-like transmissions.  Sequence lengths from 2 minutes
>   to 30 minutes, threshold sensitivities from -32.8 to -44.8 dB.
> 
> FST4-60 is about 1.7 dB more sensitive than JT9, largely because it uses 
> multi-symbol block detection where appropriate. With AP decoding in FST4 the 
> advantage can be as much as 4.7 dB. Additional sensitivity details with 
> respect to path Doppler spread are illustrated in the following graph 
> comparing JT9 and FST4-60:
> https://physics.princeton.edu/pulsar/k1jt/jt9_vs_fst4.pdf
> 
> FST4W-120 is about 1.4 dB more sensitive than WSPR, and FST4W submodes with 
> longer transmissions have proportionally better sensitivity. Decoding 
> probabilities are plotted as a function of SNR on the additive white Gaussian 
> noise (AWGN) channel for WSPR and all FST4W submodes here: 
> https://physics.princeton.edu/pulsar/k1jt/wspr_vs_fst4w.pdf
> 
> Tests over the past several months have shown FST4 and FST4W frequently 
> spanning intercontinental distances on the 2200 m and 630 m bands. Further 
> details and operating hints can be found in the "Quick-Start Guide to FST4 
> and FST4W":
> 
> https://physics.princeton.edu/pulsar/k1jt/FST4_Quick_Start.pdf
> 
> We strongly recommend that users of JT9 and WSPR on the LF and MF bands 
> should migrate to the more sensitive modes FST4 and FST4W.
> 
> 
> Links to installation packages for Windows, Linux, and Macintosh are 
> available here:
> http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
> Scroll down to find "Candidate release:  WSJT-X 2.3.0-rc1".
> 
> You can also download the packages from our SourceForge site:
> https://sourceforge.net/projects/wsjt/files/
> It may take a short time for the SourceForge site to be updated.
> 
> WSJT-X is licensed under the terms of Version 3 of the GNU General Public 
> License (GPL).  Development of this software is a cooperative project to 
> which many amateur radio operators have contributed.  If you use our code, 
> please have the courtesy to let us know about it.  If you find bugs or make 
> improvements to the code, please report them to us in a timely fashion.
> 
> We hope you will enjoy using this beta release of WSJT-X 2.3.0.  Please 
> report bugs by following instructions found here 

Re: [wsjt-devel] FST4/W

[David Tiller]

FA said: "But IIRC the OP asked for a description of the protocols, i.e. a 
design document ..."

On the WSJT-X homepage, https://physics.princeton.edu/pulsar/K1JT 
 under references, there are various 
links to to just that sort of thing:

Protocol design docs for:

FT4/FT8: https://physics.princeton.edu/pulsar/K1JT/FT4_FT8_QEX.pdf 


MSK144: https://physics.princeton.edu/pulsar/K1JT/MSK144_Protocol_QEX.pdf 


JT65: http://physics.princeton.edu/pulsar/K1JT/JT65.pdf 


JT65's Reed Solomon decoder: 
https://physics.princeton.edu/pulsar/K1JT/FrankeTaylor_QEX_2016.pdf 


The original WSJT: 
http://physics.princeton.edu/pulsar/K1JT/WSJT_QST_Dec2001.pdf 
 (almost 20 
years ago!)

I'm not sure it could've been any easier to find. 


> On Aug 27, 2020, at 12:44 PM, James Shaver  wrote:
> 
> “Code-parrots” is totally being added to my lexicon going forward lol 
> 
> 
> 73,
> N2ADV
> 
>> On Aug 27, 2020, at 11:36 AM, Fons Adriaensen  wrote:
>> 
>> On Thu, Aug 27, 2020 at 12:01:53PM +0100, Bill Somerville wrote:
>> 
>>> you are ignoring those that would take the unfinished work in progress,
>>> despite protocols not being finalized, and copy the code parrot fashion into
>>> their so-called derivative products, which they then release as "complete"
>>> before the original authors have even made a public release. All this
>>> despite being politely asked not to do just that until the protocols are
>>> fixed.
>> 
>> That is indeed a problem with most open source software, it has hit me
>> as well as developer of audio-related applications.
>> 
>> But IIRC the OP asked for a description of the protocols, i.e. a design
>> document, not for ready-to-use code. Surely such documentation does exist,
>> and I doubt very much it would help the code-parrots who probably don't
>> even understand the basics.
>> 
>> Ciao,
>> 
>> -- 
>> FA
>> 
>> 
>> 
>> ___
>> 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] Rig verification

[David Tiller]

Ok, that’s what I thought. The PROII has those commands, of course. :-)

So other than those things, Hamlib works fine w/ the PRO, but I’ll do the 
rigctl exhaustive test anyway. 

> On Jul 18, 2020, at 10:50, Marco Calistri  wrote:
> 
> Il 16/07/20 01:11, Black Michael via wsjt-devel ha scritto:
> 
> Hi,
> 
> I'm using this:
> 
> 1021  Yaesu FT-100 20200323.0 Beta RIG_MODEL_FT100
> 
> And as we can see is still a Beta version.
> 
> It's working okay with WSJT-X but may be it can be enhanced.
> 
> Many thanks!
> -- 
> 
> 73 de Marco, PY1ZRJ (former IK5BCU)
> 
> 
> ___
> 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] Rig verification

[David Tiller]

All,

I tested my IC-756PRO (no suffix) as described in the original email. All 
worked as expected _except_ for setting the Data/PKT mode and the filter widths.

Observations: 

MODE SETUP:

1) Expected behavior: If I have the radio in USB-DATA mode initially, 
setting the mode to None does not change the mode on either VFO.

2) Unexpected behavior: If I have the radio in USB-DATA mode initially, 
setting the mode to USB _or_ Data/Pkt changes the mode in both VFOs to plain 
"USB".

FILTER WIDTH

1) Expected behavior: If I have the filters set to 3 kHz, choosing None as 
the mode leaves the both VFO's filters at 3 kHz.

2) Semi-expected behavior: If I have the filters on both VFOs set to 3 kHz, 
choosing USB as the mode leaves the RX VFO filter at 3 kHz but changes the TX 
VFO filter to 2.4 kHz on the first transmission (not really an issue unless the 
TX bandwidth is also effected).

3) Unexpected behavior: If I have the filters on both VFOs set to 3 kHz, 
choosing Data/Pkt as the mode changes the filter width of the RX VFO to 2.4 kHz 
immediately and the width of the TX VFO to 2.4 kHz on the first transmission 
(and sets the mode on both to plain USB, see above).

4) Unexpected behavior: If I have the filters on both VFOs set to 700Hz or 
2.4 kHz, choosing USB as the mode sets the TX VFO filter to 2.4 kHz and leaves 
the RX VFO at its previous value instead of the more useful 3 kHz. (similar to 
#2, above).


Perhaps related, the "Transmit audio source" is grayed out, although the 756PRO 
does have a rear audio connector. The selection for this is driven by the mode  
- as the manual states, "Microphone signals are muted when data mode is 
selected."

I looked at the CIV commands and didn't see one that explicitly mentioned 
setting data mode or the filter widths for the 756PRO without a suffix (the 
PROII does, g), so fixing these might not be possible. Perhaps graying out 
the data/pkt option would be helpful to not lull us with false hope :-)



> Hi All,
> further to Mike's request, here is a small test plan that should exercise the 
> full extent of WSJT-X's use of Hamlib. I should point out that WSJT-X only 
> uses a very small subset of the capabilities of Hamlib, but nevertheless they 
> are fundamental functions like frequency setting, frequency quering, PTT, 
> etc.. Clearly these tests do not apply to any rigs that Mike Lists which do 
> not have SSB capability.
> In WSJT-X "Settings->Radio" select the following options (you should note any 
> changed settings so you can return to your usual setup):
> 
> Mode: Data/PKT if your rig has a USB-DATA mode or equivalent, otherwise USB.
> Split Operating: Rig.
> PTT Method: CAT if your rig supports PTT via a CAT command, unless your PTT 
> hardware must use DTR or RTS.
> Then do the following tests:
> 
> In FT8 mode Shift+click on the Wide Graph waterfall at least 500 Hz away from 
> the currently indicated Tx offset (the red goalpost indicator on the 
> frequency graticule).
> Prepare you rig to be safe for transmit (dummy load or low power, etc.), 
> click the "Tune" button, check Tx is working with power output, click "Tune" 
> again to cease transmitting.
> Report any error messages, on Windows you can copy the full text of any error 
> message pop-up box by hitting Ctrl+C (don't try and select any text) when it 
> shows, the text is copied to the Windows clipboard.
> 73
> Bill
> G4WJS.
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

Re: [wsjt-devel] Wide Graph during TX

[David Tiller]

I agree that the signal was strong, but there was another signal a little later 
that was also under 1000 Hz and was several dB stronger. Its fundamental was 
not extra wide and it did not have the associated harmonics. 

The signal shown also suffered from a huge burst of white noise as the 
transmission started. 

Re: ALC not being the cause. It has been my experience working with stations to 
improve poor quality signals that reducing the AF drive usually fixes the 
‘close in’ harmonics. 



> On Jun 7, 2020, at 13:55, Black Michael via wsjt-devel 
>  wrote:
> 
> That's actually just a very strong signal so you can see the side lobes of 
> the FFT that are always there but usually in the noise.
> It's quite possible the harmonics you see is from your received signal 
> clipping given how intense that one is.
> 
> Mike W9MDB
> 
> 
> 
> 
> 
> On Sunday, June 7, 2020, 11:04:09 AM CDT, Bill Somerville 
>  wrote:
> 
> 
> David,
> 
> that sort of distortion can only happen in the base band audio domain, ALC 
> and other RF applications can't cause close in harmonics like that.
> 
> 73
> Bill
> G4WJS.
> 
>> On 07/06/2020 16:34, David Tiller wrote:
>> To add to what Rick said,
>> 
>> Even for radios that have a monitor function, the audio you'd get back would 
>> likely be 'clean' as it's probably echoed way before ALC and other 
>> processing have made the TX'ed signal nasty. Here's an example that I heard 
>> just this morning that probably would've sounded fine on the monitor, but 
>> look at what was transmitted:
>> 
>> 
>> 
>> 
>> 
>>> On Jun 7, 2020, at 11:22 AM, Rick Drexel  wrote:
>>> 
>>> 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 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] trouble keying PTT with com port RTS or DTS

[David Tiller]

FYI team, I also reported an issue with PTT with RC1 that does not seem to be 
solved in RC2. I believe the issue was the initialization of the cat state for 
rigs that cannot be queried.

The command I was previously asked to run returns '0' each time, so it seems to 
be something else. 

dtiller$ ./Applications/wsjtx.app/Contents/MacOS/rigctl-wsjtx -p 
/dev/cu.usbserial-141201 -P RTS -v -Z t pause 1 t pause 1 t
2020-05-25:16:35:56.919181: rigctl, Hamlib 4.0~git May 23 2020 23:00:09
2020-05-25:16:35:56.919533: Report bugs to 


2020-05-25:16:35:56.919552: rig_init called
2020-05-25:16:35:56.919580: initrigs4_dummy: _init called
2020-05-25:16:35:56.919596: rig_register called
2020-05-25:16:35:56.919602: rig_register: rig_register (1)
2020-05-25:16:35:56.919614: rig_register called
2020-05-25:16:35:56.919620: rig_register: rig_register (2)
2020-05-25:16:35:56.919626: rig_register called
2020-05-25:16:35:56.919632: rig_register: rig_register (4)
2020-05-25:16:35:56.919638: rig_register called
2020-05-25:16:35:56.919676: rig_register: rig_register (5)
2020-05-25:16:35:56.919717: dummy_init called
2020-05-25:16:35:56.919749: rig_passband_normal called
2020-05-25:16:35:56.919757: rig_passband_normal called
2020-05-25:16:35:56.919774: rig_open called
2020-05-25:16:35:56.919794: port_open called
2020-05-25:16:35:56.919802: ser_open called
2020-05-25:16:35:56.922284: ser_set_dtr called
2020-05-25:16:35:56.922296: ser_set_dtr: DTR=0
2020-05-25:16:35:56.922332: ser_set_rts called
2020-05-25:16:35:56.922339: ser_set_rts: RTS=0
2020-05-25:16:35:56.922354: ser_close called
2020-05-25:16:35:56.922360: ser_close: no options for fd to restore
2020-05-25:16:35:56.923688: dummy_open called
2020-05-25:16:35:56.948756: rig_get_vfo called
2020-05-25:16:35:56.948788: elapsed_ms: start = 0,0
2020-05-25:16:35:56.948812: rig_get_vfo: cache check age=100ms
2020-05-25:16:35:56.948821: rig_get_vfo: cache miss age=100ms
2020-05-25:16:35:56.968886: dummy_get_vfo called: VFOA
2020-05-25:16:35:56.968917: elapsed_ms: start = 0,0
2020-05-25:16:35:56.968930: elapsed_ms: after gettime, start = 
1590424556,968927000
2020-05-25:16:35:56.968953: rig_set_parm called
2020-05-25:16:35:56.968964: rig_has_set_parm called
2020-05-25:16:35:56.968980: rig_setting2idx called
2020-05-25:16:35:56.968992: rig_strparm called
2020-05-25:16:35:56.969009: rig_strparm called
2020-05-25:16:35:56.969018: dummy_set_parm called: SCREENSAVER 0
Opened rig model 1, 'Dummy'
2020-05-25:16:35:56.969152: Backend version: 20200503.0, Status: Stable
2020-05-25:16:35:56.969176: rigctl_parse: called, interactive=0
2020-05-25:16:35:56.969204: rigctl_parse: debug1
2020-05-25:16:35:56.969217: rigctl_parse: debug5
2020-05-25:16:35:56.969228: rigctl_parse: debug10
2020-05-25:16:35:56.969244: rigctl_parse: vfo_mode=0
2020-05-25:16:35:56.969266: rig_get_ptt called
2020-05-25:16:35:56.969320: elapsed_ms: start = 0,0
2020-05-25:16:35:56.969339: rig_get_ptt: cache check age=100ms
2020-05-25:16:35:56.969357: rig_get_ptt: cache miss age=100ms
2020-05-25:16:35:56.991473: dummy_get_ptt called
2020-05-25:16:35:56.991570: elapsed_ms: start = 0,0
2020-05-25:16:35:56.991630: elapsed_ms: after gettime, start = 
1590424556,991627000
0
2020-05-25:16:35:56.991650: rigctl_parse: retcode=0
2020-05-25:16:35:56.991668: rigctl_parse: called, interactive=0
2020-05-25:16:35:56.991723: rigctl_parse: debug1
2020-05-25:16:35:56.991738: rigctl_parse: debug3
2020-05-25:16:35:56.991754: rigctl_parse: debug5
2020-05-25:16:35:56.991775: rigctl_parse: debug10
2020-05-25:16:35:56.991785: rigctl_parse: vfo_mode=0
2020-05-25:16:35:57.996817: rigctl_parse: retcode=0
2020-05-25:16:35:57.996849: rigctl_parse: called, interactive=0
2020-05-25:16:35:57.996856: rigctl_parse: debug1
2020-05-25:16:35:57.996861: rigctl_parse: debug5
2020-05-25:16:35:57.996866: rigctl_parse: debug10
2020-05-25:16:35:57.996871: rigctl_parse: vfo_mode=0
2020-05-25:16:35:57.996878: rig_get_ptt called
2020-05-25:16:35:57.996884: elapsed_ms: start = 1590424556,991627000
2020-05-25:16:35:57.996893: elapsed_ms: elapsed_secs=1005.26
2020-05-25:16:35:57.996900: rig_get_ptt: cache check age=1005ms
2020-05-25:16:35:57.996905: rig_get_ptt: cache miss age=1005ms
2020-05-25:16:35:58.016952: dummy_get_ptt called
2020-05-25:16:35:58.016982: elapsed_ms: start = 0,0
2020-05-25:16:35:58.016992: elapsed_ms: after gettime, start = 
1590424558,1699
0
2020-05-25:16:35:58.017007: rigctl_parse: retcode=0
2020-05-25:16:35:58.017016: rigctl_parse: called, interactive=0
2020-05-25:16:35:58.017027: rigctl_parse: debug1
2020-05-25:16:35:58.017036: rigctl_parse: debug3
2020-05-25:16:35:58.017044: rigctl_parse: debug5
2020-05-25:16:35:58.017052: rigctl_parse: debug10
2020-05-25:16:35:58.017061: rigctl_parse: vfo_mode=0
2020-05-25:16:35:59.021154: rigctl_parse: retcode=0
2020-05-25:16:35:59.021194: rigctl_parse: called, interactive=0
2020-05-25:16:35:59.021212: rigctl_parse: debug1
2020-05-25:16:35:59.021226: rigctl_parse: debug5

Re: [wsjt-devel] 2.2.0 RC1 Issues

[David Tiller]

Mike,

I gave it a go. I assume the 'master' branch is the one you want - I saw your 
commits :-)

I installed it in a local dir, not in /usr or /opt:

./configure --prefix=/Users/dtiller/hamlib-master-prefix 
--exec-prefix=/Users/dtiller/hamlib-master-eprefix

Here's the output:

WITH CACHE SET TO 0

dtiller$ ./rigctl -p /dev/cu.usbserial-141201 -P RTS -v -Z 
--set-conf=cache_timeout=0 t pause 1 t pause 1 t
2020-05-13:13:26:24.829615: rigctl, Hamlib 4.0~git May 13 2020 09:24:59
2020-05-13:13:26:24.829961: Report bugs to 


2020-05-13:13:26:24.829997: rig_init called
2020-05-13:13:26:24.830020: initrigs4_dummy: _init called
2020-05-13:13:26:24.830034: rig_register called
2020-05-13:13:26:24.830040: rig_register: rig_register (1)
2020-05-13:13:26:24.830051: rig_register called
2020-05-13:13:26:24.830057: rig_register: rig_register (2)
2020-05-13:13:26:24.830063: rig_register called
2020-05-13:13:26:24.830069: rig_register: rig_register (4)
2020-05-13:13:26:24.830075: rig_register called
2020-05-13:13:26:24.830081: rig_register: rig_register (5)
2020-05-13:13:26:24.830111: dummy_init called
2020-05-13:13:26:24.830142: rig_passband_normal called
2020-05-13:13:26:24.830148: rig_passband_normal called
2020-05-13:13:26:24.830166: rig_token_lookup called
2020-05-13:13:26:24.830172: rig_confparam_lookup called
2020-05-13:13:26:24.830182: rig_set_conf called
2020-05-13:13:26:24.830188: rig_confparam_lookup called
2020-05-13:13:26:24.830195: rig_set_conf: cache_timeout='0'
2020-05-13:13:26:24.830206: rig_set_cache_timeout_ms: called selection=0, ms=0
2020-05-13:13:26:24.830216: rig_open called
2020-05-13:13:26:24.830236: port_open called
2020-05-13:13:26:24.830244: ser_open called
2020-05-13:13:26:24.833249: ser_set_dtr called
2020-05-13:13:26:24.833262: ser_set_dtr: DTR=0
2020-05-13:13:26:24.833315: ser_set_rts called
2020-05-13:13:26:24.833322: ser_set_rts: RTS=0
2020-05-13:13:26:24.88: ser_close called
2020-05-13:13:26:24.833344: ser_close: no options for fd to restore
2020-05-13:13:26:24.835134: dummy_open called
2020-05-13:13:26:24.857629: rig_get_vfo called
2020-05-13:13:26:24.857666: elapsed_ms: start = 0,0
2020-05-13:13:26:24.857685: rig_get_vfo: cache check age=100ms
2020-05-13:13:26:24.857699: rig_get_vfo: cache miss age=100ms
2020-05-13:13:26:24.882744: dummy_get_vfo called: VFOA
2020-05-13:13:26:24.882764: elapsed_ms: start = 0,0
2020-05-13:13:26:24.882774: elapsed_ms: after gettime, start = 
1589376384,882772000
2020-05-13:13:26:24.882813: rig_set_parm called
2020-05-13:13:26:24.882826: rig_has_set_parm called
2020-05-13:13:26:24.882865: rig_setting2idx called
2020-05-13:13:26:24.882880: rig_strparm called
2020-05-13:13:26:24.882887: rig_strparm called
2020-05-13:13:26:24.882892: dummy_set_parm called: SCREENSAVER 0
Opened rig model 1, 'Dummy'
2020-05-13:13:26:24.882920: Backend version: 20200503.0, Status: Stable
2020-05-13:13:26:24.882928: rigctl_parse: called, interactive=0
2020-05-13:13:26:24.882939: rigctl_parse: debug1
2020-05-13:13:26:24.882945: rigctl_parse: debug5
2020-05-13:13:26:24.882950: rigctl_parse: debug10
2020-05-13:13:26:24.882958: rigctl_parse: vfo_mode=0
2020-05-13:13:26:24.882970: rig_get_ptt called
2020-05-13:13:26:24.882977: elapsed_ms: start = 0,0
2020-05-13:13:26:24.882983: rig_get_ptt: cache check age=100ms
2020-05-13:13:26:24.882989: rig_get_ptt: cache miss age=100ms
2020-05-13:13:26:24.907898: dummy_get_ptt called
2020-05-13:13:26:24.907924: elapsed_ms: start = 0,0
2020-05-13:13:26:24.907940: elapsed_ms: after gettime, start = 
1589376384,907937000
0
2020-05-13:13:26:24.907974: rigctl_parse: retcode=0
2020-05-13:13:26:24.907984: rigctl_parse: called, interactive=0
2020-05-13:13:26:24.908031: rigctl_parse: debug1
2020-05-13:13:26:24.908038: rigctl_parse: debug3
2020-05-13:13:26:24.908044: rigctl_parse: debug5
2020-05-13:13:26:24.908049: rigctl_parse: debug10
2020-05-13:13:26:24.908055: rigctl_parse: vfo_mode=0
2020-05-13:13:26:25.912536: rigctl_parse: retcode=0
2020-05-13:13:26:25.912560: rigctl_parse: called, interactive=0
2020-05-13:13:26:25.912568: rigctl_parse: debug1
2020-05-13:13:26:25.912574: rigctl_parse: debug5
2020-05-13:13:26:25.912580: rigctl_parse: debug10
2020-05-13:13:26:25.912586: rigctl_parse: vfo_mode=0
2020-05-13:13:26:25.912594: rig_get_ptt called
2020-05-13:13:26:25.912601: elapsed_ms: start = 1589376384,907937000
2020-05-13:13:26:25.912613: elapsed_ms: elapsed_secs=1004.67
2020-05-13:13:26:25.912623: rig_get_ptt: cache check age=1004ms
2020-05-13:13:26:25.912632: rig_get_ptt: cache miss age=1004ms
2020-05-13:13:26:25.936449: dummy_get_ptt called
2020-05-13:13:26:25.936474: elapsed_ms: start = 0,0
2020-05-13:13:26:25.936483: elapsed_ms: after gettime, start = 
1589376385,936481000
0
2020-05-13:13:26:25.936494: rigctl_parse: retcode=0
2020-05-13:13:26:25.936500: rigctl_parse: called, interactive=0
2020-05-13:13:26:25.936509: rigctl_parse: debug1
2020-05-13:13:26:25.936517: rigctl_parse: debug3
2020-05-13:13:26:25.936525: 

Re: [wsjt-devel] 2.2.0 RC1 Issues

[David Tiller]

:07.102453: rig_set_conf: cache_timeout='0'
2020-05-13:12:18:07.102464: rig_set_cache_timeout_ms: called selection=0, ms=0
2020-05-13:12:18:07.102473: rig_open called
2020-05-13:12:18:07.102489: port_open called
2020-05-13:12:18:07.102497: serial_open called
2020-05-13:12:18:07.102534: serial_open: OPEN before
2020-05-13:12:18:07.102575: serial_open: OPEN after
2020-05-13:12:18:07.102596: serial_open: Unable to open /dev/ttyS0 - No such 
file or directory
2020-05-13:12:18:07.303786: main: error opening rig, try#1
2020-05-13:12:18:07.303832: rig_open called
2020-05-13:12:18:07.303846: port_open called
2020-05-13:12:18:07.303858: serial_open called
2020-05-13:12:18:07.303868: serial_open: OPEN before
2020-05-13:12:18:07.303932: serial_open: OPEN after
2020-05-13:12:18:07.303944: serial_open: Unable to open /dev/ttyS0 - No such 
file or directory
2020-05-13:12:18:07.506575: main: error opening rig, try#2
2020-05-13:12:18:07.506649: rig_open called
2020-05-13:12:18:07.506668: port_open called
2020-05-13:12:18:07.506681: serial_open called
2020-05-13:12:18:07.506692: serial_open: OPEN before
2020-05-13:12:18:07.506751: serial_open: OPEN after
2020-05-13:12:18:07.506764: serial_open: Unable to open /dev/ttyS0 - No such 
file or directory
2020-05-13:12:18:07.707636: main: error opening rig, try#3
2020-05-13:12:18:07.707671: rig_open called
2020-05-13:12:18:07.707686: port_open called
2020-05-13:12:18:07.707698: serial_open called
2020-05-13:12:18:07.707708: serial_open: OPEN before
2020-05-13:12:18:07.707770: serial_open: OPEN after
2020-05-13:12:18:07.707783: serial_open: Unable to open /dev/ttyS0 - No such 
file or directory
2020-05-13:12:18:07.907907: main: error opening rig, try#4
2020-05-13:12:18:07.907942: rig_open called
2020-05-13:12:18:07.908000: port_open called
2020-05-13:12:18:07.908012: serial_open called
2020-05-13:12:18:07.908023: serial_open: OPEN before
2020-05-13:12:18:07.908084: serial_open: OPEN after
2020-05-13:12:18:07.908097: serial_open: Unable to open /dev/ttyS0 - No such 
file or directory
2020-05-13:12:18:08.111903: main: error opening rig, try#5
rig_open: error = IO error 
dtiller:~ dtiller$

> On May 13, 2020, at 8:13 AM, Bill Somerville  wrote:
> 
> On 13/05/2020 12:37, David Tiller wrote:
>> Bill,
>> 
>> Thanks for the speedy reply!
>> 
>> I see that the command specifies a rig - like I said, I only use the given 
>> serial port for PTT, not for CAT commands. I'm not sure if that changes 
>> anything.
>> The CAT port is /dev/cu.usbserial-141200, but I set the rig to None most of 
>> the time. I tried it with '-s 19200' also, but it didn't change anything.
>> 
> Hi David,
> 
> apologies, my bad. Your second invocation without the '-m 3027' option is 
> what I needed, thanks for working that out.
> 
> The trace output is useful. Please try Mike's suggestion, if that works we 
> can provide a workaround for WSJT-X.
> 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] 2.2.0 RC1 Issues

[David Tiller]

Dear devs,

I began using the latest release candidate today and love the early decodes, 
but I noticed a few things that seemed to be not working reliably under OSX.

My Setup: OSX 10.13.6, Icom 756PRO, and a RigExpert Standard. This setup works 
flawlessly with 2.1.2.

1) 2.20-RC1 does not remember the last band used on startup. It often starts on 
160m and ends up on  2m, sometimes changing it while the RC banner is showing.
2) PTT on TX is intermittent, as is the 'tune' function. Note that I do NOT use 
CAT control of the rig from WSJT-X (or anything else when testing this).
3) Testing PTT sometimes works. The button turns red by itself and only 
actually keys the radio occasionally.

Going into the Preferences/Radio menu tab immediately after startup gives me a 
red Test PTT button. With 2.1.2 I get a white button, as expected. See image, 
below.


I've made a video of the issues that can be downloaded from this folder link:

https://drive.google.com/open?id=1lRJIQFGZifH67zHoJUmajqDJiRrp43te

In case the listserv eats the link, it's:
h t t p s:// drive_google_com / open ? id= 1lRJIQFGZifH67zHoJUmajqDJiRrp43te

sub '.' for '_' and remove spaces.

Thanks to all the devs for all their hard work!


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

Re: [wsjt-devel] Problem with radio's audio input

[David Tiller]

And to add to that, on my Mac if I get the 'no audio' situation, I can click 
Halt TX and then enable TX and I'll get audio immediately.

It sounds like the waveform isn't getting generated for some reason and default 
zeros are being 'sent'.


From: Claude Frantz 
Sent: Thursday, December 5, 2019 1:56 AM
To: wsjt-devel@lists.sourceforge.net 
Subject: Re: [wsjt-devel] Problem with radio's audio input

On 12/2/19 12:22 PM, Claude Frantz wrote:

> This problem of occasional no audio output has been reported here by
> various users, included myself. I have encountered it while running with
> Windows XP and using Linux, on different hardware. I cannot remember
> that an valuable diagnostic has been reported about the reasons of these
> sporadic recurrences.

Just an additional information here. When this "no audio output" occurs,
it's present during the whole duration of the TX period. When the TX
switches on, there is no audio signal present. I have never encountered
a situation where the audio signal was present at the beginning of the
TX period and has dropped later, during the same TX period.

I'm still waiting for recommendations concerning a possible diagnostic
procedure which could help to debug this ugly bug.

Best wishes,
Claude (DJ0OT)


___
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.1 GA release

[David Tiller]

I’m also getting the same error on my Mac when I try to use the same Icom 756 
PRO settings that work under 2.1.0.

Im running OS X 10.13.6.

On Nov 25, 2019, at 17:29, Gene H mailto:ghin...@gmail.com>> 
wrote:


Same here with Windows 10 computer and IC-7610 radio. Always worked correctly 
before this version 2.1.1.



My Windows 7 computer worked correctly.

K5PA/Gene

On 11/25/2019 2:41 PM, Jon Anhold wrote:
I'm not sure why yet, but when I upgrade to 2.1.1, I get the following error on 
startup:



73 de KM8V

On Mon, Nov 25, 2019 at 1:43 PM Joe Taylor 
mailto:j...@princeton.edu>> wrote:
The WSJT Development Group is pleased to announce the general
availability (GA) release of WSJT-X Version 2.1.1.

WSJT-X 2.1.1 is a bug-fix release that addresses regressions in the
v2.1.0.  The new version executes properly on Macintosh machines running
macOS 10.15 (Catalina).

A list of program changes since WSJT-X 2.1.0 can be found in the
cumulative Release Notes:
http://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt

Upgrading from earlier versions of WSJT-X should be seamless.  There is
no need to uninstall a previous version or move any files.

Links to installation packages for Windows, Linux, and Macintosh are
available here:
http://physics.princeton.edu/pulsar/k1jt/wsjtx.html

You can also download the packages from our SourceForge site:
https://sourceforge.net/projects/wsjt/files/
It may take a short time for the SourceForge site to be updated.

WSJT-X is licensed under the terms of Version 3 of the GNU General
Public License (GPL).  Development of this software is a cooperative
project to which many amateur radio operators have contributed.  If you
use our code, please have the courtesy to let us know about it.  If you
find bugs or make improvements to the code, please report them to us in
a timely fashion.

We hope you will enjoy using WSJT-X Version 2.1.1.

  -- 73, Joe, K1JT, for the WSJT Development Group


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



This body part will be downloaded on demand.



This body part will be downloaded on demand.

--
Gene Hinkle
9109 Topridge Drive, Austin, TX 78750
e-mail to Gene:  ghin...@gmail.com
cell phone or text messaging:  (512) 413-9251
--






___
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] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[David Tiller]

I’m no expert on Fox/hound, but could you use an audio file (either ‘played’ 
via the wsjtx menu item or via a virtual audio cable) to simulate the hounds? 
You could create as many hounds as you like in whatever state you need to 
reproduce the issue.

On Nov 18, 2019, at 06:46, Grant VK5GR 
mailto:vk5gr.ra...@gmail.com>> wrote:

Dave,

To prove the fix you would probably need about 8-10 hounds in fact to see the 
behaviour properly and confirm it is no longer doing it.

Having said that, I am sure I can round up some willing test volunteers across 
VK and work with you on the testing if that would help.

Regards
Grant VK5GR


From: Dave Slotter, W3DJS [mailto:slotter+w3...@gmail.com]
Sent: Monday, 18 November 2019 6:34 AM
To: WSJT software development
Subject: Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator 
enhancement request

I agree that these are reasonable requests. If Bill et al cannot find time to 
address, as a software engineer who has actually modified the WSJT-X code to 
fix an Enable button defect, I'd be willing to fix these unwanted Fox mode 
behaviors.

BUT... (There's always a but, isn't there?) I'd need 2-3 Hounds to test the 
Enable button fix.

-Dave
 W3DJS
___
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] wsprnet abandoned

[David Tiller]

You can get a feel for the content by downloading the CSV files from here: 
http://wsprnet.org/drupal/downloads

I use them to populate my site at http://k4det.net/wsprmap

--
David Tiller
SENIOR MANAGER
O  /  804.355.0511
E  /  dtil...@captechconsulting.com
captechconsulting.com<http://www.captechconsulting.com/>


From: Black Michael via wsjt-devel 
Sent: Thursday, October 10, 2019 9:47 AM
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] wsprnet abandoned

According to http://wsprnet.org/drupal/wsprnet/stats the 7-day moving average 
looks to be 1.4M spots per day.

de MIke W9MDB




On Thursday, October 10, 2019, 08:43:48 AM CDT, Philip Gladstone 
 wrote:


How much traffic does WSPRNET get? How many spots are reported on a daily 
basis? I'm trying to figure out if supporting all that traffic in pskreporter 
would kill it

On Thu, Oct 10, 2019 at 4:59 AM Benjamin Bänziger 
mailto:helios.sola...@gmx.ch>> wrote:
Hi,

This is probably not the right place for this issue, but all other
options didn't get attention unfortunately.

Over the past months and years, wsprnet got continuously slower, as more
and more people used the service.
Since a few months, wsprnet got unreachable for minutes multiple times a
day. It is common that database requests time out.

wsprnet does also regularly lose wspr spots, because it is overloaded.
Since a week now, the map on wsprnet.org<http://wsprnet.org> doesnt work 
anymore.
The official wsprnet e-mail is refusing e-mails since at least one year(!)


Over the past months, there have been countless complaints in the
wsprnet forum. And also countless offers to help to resolve this issue,
also offers for donations.
Yet nobody seems to take action.


I ask you to please find somebody who takes care of 
wsprnet.org<http://wsprnet.org>. WSPR is
the best mode I've seen in ham radio for exploring propagation. It would
be very sad to see it go down like this.
wsprnet is a very important part of the WSPR mode.


Thanks.
73


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto: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] FT8 ghost signals

[David Tiller]

The ones at 710, 830, and 950 are exactly 120 Hz apart - 2x the US line 
frequency. The 350 and is 6x60 Hz away from 710 (and exact multiples of 120 Hz 
from all of the others as well).

You've got 950 Hz (the presumed fundamental), 950 - 120, 950 - 240, and 950 - 
600. Missing would be the subharmonics between 350 and 710 Hz (.

The second pair are almost 360 Hz apart. It sounds like there's some AC mixing 
going on.
--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Jul 13, 2019, at 2:29 PM, Bill Barrett 
mailto:w2pky...@gmail.com>> wrote:

Hello Reino-

190708_22401550.313 Rx FT8-24  0.3  350 WC4H W4I R-13
190708_22401550.313 Rx FT8-12  0.3  710 WC4H W4I R-13
190708_22401550.313 Rx FT8 -7  0.3  830 WC4H W4I R-13
190708_22401550.313 Rx FT8 17  0.3  950 WC4H W4I R-13

190708_22404550.313 Rx FT8-24  0.3  350 WC4H W4I 73
190708_22404550.313 Rx FT8-14  0.3  709 WC4H W4I 73

Thanks for the tip.
Here is the episode.

Bill W2PKY



On Sat, Jul 13, 2019 at 1:46 PM Reino Talarmo 
mailto:reino.tala...@kolumbus.fi>> wrote:
Bill,
Do you happen to have an ALL.TXT on that situation? If so what was the 
frequency difference between those sub-harmonics?
73, Reino oh3ma
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto: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] FT8 ghost signals

[David Tiller]

-70 Hz at 50.313 MHz is a relative velocity of about -209 m/s or -468 mph.  
That's in the ballpark for a jet aircraft.

On Jul 7, 2019, at 10:19, Rich Zwirko - K1HTV 
mailto:k1...@comcast.net>> wrote:

Reino,
 Yes, the main stronger FT8 signal is the one heard directly. The Doppler 
shifted signals, reflected from the direction of a strong Es cloud, are usually 
between 40 and over 100 Hz lower, with the average of around -70 Hz.
73,
Rich - K1HTV

= = =

From: Reino Talarmo 
mailto:reino.tala...@kolumbus.fi>>
To: "'WSJT software development'" 
mailto:wsjt-devel@lists.sourceforge.net>>
Cc:
Bcc:
Date: Sun, 7 Jul 2019 11:10:57 +0300
Subject: Re: [wsjt-devel] FT8 ghost signals
Hi All,
Perhaps this a wrong forum, but still I like to ask how you explain ghost 
signals with varying frequency offset? Do you have both a direct signal and an 
ES reflection from a moving cloud?
73, Reino oh3ma
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 ghost signals

[David Tiller]

 Since the transmitted and received frequencies are known, another reality 
check would be to calculate the velocity of the presumed moving Doppler target. 
If it's outside the max operating speed of normal jet aircraft, it's probably 
not one. Note that you can't say the same about speeds below minimum 
controllable airspeed - closure angles can make any speed appear to be from 0 
(90 degrees from transmitter) to the actual speed (head on).

On Jul 7, 2019, at 10:03, DX Jami via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:

Rich,

I hear what you say about the Doppler effect, and I recall our conversations on 
HF about it.  I do not challenge the theory and facts behind the Doppler 
effect, but I believe there is more to the propagational phenomena we attribute 
to the Doppler effect.  Being one who often challenges conventional wisdom ... 
here is a question I have been pondering.  For hams, we consider the Doppler 
effect of radio wave bouncing off airplanes, and this causes unique radio 
conditions.  My question is since the number of airline-only [excluding 
worldwide military and private] flights increased from 23.8 [2004] to 39.4 
[2019 to-date] MILLION why do we not experience more Doppler effect situations 
on ham radio?  Another data point in that equation is the number of commercial 
[only] flights per day in the US ... which is about 87,000.

I recall us talking about the unique sound of the Doppler effect, and sometime 
attribute it to my/our proximity to Dulles International Airport.  I am very 
close to the take-off and landing approaches to Dulles, and I am even closer to 
those of Manassas International which has a lot of private & business traffic.  
So my chances of being affected by Doppler should be greater.  However, I have 
not experienced a proportional increase of Doppler related conditions.  What's 
going on?  Why do we not have more "Doppler propagation instances ... or do we 
and just not realize it?"

BTW - sorry for this being somewhat outside the scope of WSJT-X.

Ciao,
Danny
AH6FX/W4
Nokesville, Virginia

On Sunday, July 7, 2019, 5:31:38 AM EDT, Martin Davies G0HDB 
mailto:marting0...@gmail.com>> wrote:


On 6 Jul 2019 at 16:06, Rich Zwirko - K1HTV wrote:

> Here in the Mid-Atlantic, a number of 6 Meter FT8 DXers have observed
> backscatter signals that appear as a 2nd or even a 3rd signal on the WSJT-X
> Wide Graph window. The Doppler shifted frequency is usually lower than the
> direct signal. In addition to the directly received FT8 signal appearing on
> the waterfall display, at times both direct signal as well as one or more
> of the reflected backscatter Doppler shifted signals can be decoded. The DF
> between the main and ghost signals is usually between 40 and 130 Hz. The
> average appears to be around negative 70 Hz.
>
> When these ghost signals are observed, they are usually noted on multi-KW
> FT8 signals produced by stations in the Mid-Atlantic region that are
> beaming towards highly ionization Es regions. These extra waterfall signals
> can last a few minutes then quickly disappear. I have not observed them
> when there is no Es opening. They don't appear to be the result of signals
> being reflected off aircraft.

Hi Rich, why do you believe the 'ghost' signals that are being observed aren't 
caused by
reflections off aircraft?

I very regularly see, and FT8 will decode, a second and sometimes even a third 
signal from
nearby stations that are within a few miles of my QTH; on my waterfall I can 
see the direct
signal and also the secondary signal(s) that almost always have a clearly 
discernible slant on
them, indicating that the cause of the secondary signal is Doppler shift from a 
moving object.

In my experience the secondary signal(s) can be either higher or lower in 
frequency, by some
indeterminate amount, than the direct signal so they're not artefacts resulting 
from 50/60Hz
power-line modulation of the FT8 audio signal, and the +ve or -ve offset of the 
secondary
signal(s) from the direct signal will presumably indicate the direction of 
travel of the moving
point of reflection.

IMO there's no almost doubt that such 'ghost' signals are caused by reflections 
off aircraft; I
suppose it's theoretically possible that a very fast-moving cloud of Es 
ionisation could cause
the same effect but I would guess that such clouds don't move at similar speeds 
to aircraft!

---
Martin, G0HDB


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus




___
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] "Invalid QSO Data" caused by S+P

[David Tiller]

I just had an instance of the 'invalid QSO data' popup, but mine was caused by 
the "Best S+P" mode pouncing on a non-RTTY Roundup CQ caller.

Would it be possible to limit the S+P mode to only those in the contest when a 
particular contest is selected? That is, when I'm in RTTY RU mode, only 
consider CQ RU messages?

Thanks - I'm having a ball w/ FT4!

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>

___
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-rc6

[David Tiller]

I see the same Mac behavior here.
--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Jun 2, 2019, at 7:20 PM, V. Scott Moore via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:

Mac version runs fine with one hiccup.

Made one contact (the only one I could decode) in FT4 with normal double click 
from the RX frequency list - works perfectly and logged perfectly.

When switching CONFIGURATIONS between FT8 and FT4 (or vise versa) program 
crashes.
Upon restarting the program the CONFIGURATION change has been made.

I for one can live with that one.

I have saved the crash report for a switch from FT8 to FT4.  If needed i can 
send to whoever wants it off list.

TNX
Scott - W1SSN

On Jun 2, 2019, at 19:08, Bill Somerville 
mailto:g4...@classdesign.com>> wrote:

Thanks Mike,

once I have sorted out the Omni-Rig issues I will get started on building some 
RC7 packages.

73
Bill
G4WJS.

On 03/06/2019 00:03, Black Michael via wsjt-devel wrote:
Yes...Windows 10 32-bit

Mike




On Sunday, June 2, 2019, 5:56:37 PM CDT, Bill Somerville 
<mailto:g4...@classdesign.com> wrote:


Thanks Mike,

I can't reproduce it here on Windows so I am uncertain the fix is good for 
Windows. Did you build and test with that patch on Windows?

73
Bill
G4WJS.



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

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto: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] FT4 mock contest

[David Tiller]

Joe,


Do you think rc6 for Mac users will be available by the mock contest date(s)?


Thanks!


--

David Tiller | Senior Manager



[http://www.captechconsulting.com/siggen/logo.png]<http://www.captechconsulting.com/>

[http://www.captechconsulting.com/siggen/Dkblue_Facebook.png]<http://www.facebook.com/CapTechCareers>
 [http://www.captechconsulting.com/siggen/Dkblue_Twitter.png] 
<http://www.twitter.com/CapTechListens>  
[http://www.captechconsulting.com/siggen/Dkblue_LinkedIn.png] 
<http://www.linkedin.com/company/captech-ventures>  
[http://www.captechconsulting.com/siggen/Dkblue_StackOverflow.png] 
<http://www.stackoverflow.com/jobs/companies/captech-consulting>  
[http://www.captechconsulting.com/siggen/Dkblue_YouTube.png] 
<http://www.youtube.com/user/CapTechConsulting>  
[http://www.captechconsulting.com/siggen/Dkblue_Instagram.png] 
<https://www.instagram.com/lifeatcaptech/>
2018 Best Firms to Work For #2 in Information Technology



From: Joe Taylor 
Sent: Monday, May 6, 2019 10:45 AM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] FT4 mock contest

One-hour "practice contest" sessions will be held this week and next
week using the FT4 mode and the ARRL RTTY Roundup rules.

Thursday, May 9, -0100 UTC (Wednesday evening, May 8, NA time)
Tuesday,  May 14 -0100 UTC (Monday evening, May 13, NA time)

Dial frequency 7.090 (and higher, in 2 kHz increments, if too much QRM).
  Everyone works everyone.

To participate you must use WSJT-X 2.1.0-rc5.  Installation packages for
Windows and Linux can be found near the bottom of this web page:
https://physics.princeton.edu/pulsar/k1jt/wsjtx.html

Note that this Release Candidate ("RC5") is a beta-test version.  A full
release of WSJT-X 2.1 is targeted for release in July 2019.

Be sure to read "The FT4 Protocol for Digital Contesting." Links to this
document in ten languages are available on the WSJT-X web page:
http://physics.princeton.edu/pulsar/k1jt/wsjtx.html .  Also, be sure to
read the updated list of known issues and workarounds:
http://physics.princeton.edu/pulsar/k1jt/Reported_bugs.txt


IMPORTANT INSTRUCTIONS FOR THE MOCK CONTEST:

1. On the *Settings | Advanced* tab, check the *Special operating
activity* and *ARRL RTTY Roundup* options.  In the field labeled "Exch"
enter the 2- or 3-letter abbreviation for your state or province
(US/Canadian stations) or DX if you are not in the US or Canada.

2. Make sure that 7.090 appears in your drop-down frequency list for FT4
mode.  Navigate to *File | Settings | Frequencies*, right-click on the
frequencies table, select *Insert*, then *IARU Region = All*, *Mode =
FT4*, and enter *Frequency = 7.090*.

3. Go to *File | Open log directory* and rename your ADIF log
wsjt_log.adi to something like wsjtx_log.adi.bak, so as to start the
mock contest with an empty log.  Also select *File | Reset Cabrillo
log*.  Remember to restore your original ADIF log after the mock contest.

4. Go to *File | Reporting* and check *Log automatically (contesting
only)* and *Clear DX call and grid after logging*.

5. Go to *File | Settings | Colors* and check these boxes (reading top
to bottom):

X  My call in message
X  New DXCC
X  New Call on Band
X  CQ in message
X  Transmitted message

6. Do not use a compound or nonstandard callsign in this event.

Post your results and comments here so we can all learn from an actual
FT4 contest-like experience.

If you are not already subscribed, you may wish to join the email list
wsjt-devel:
https://sourceforge.net/p/wsjt/mailman
That list is the best way to communicate directly with the WSJT
Development Group.

 -- 73, Joe, K1JT (for the WSJT Development Group)


___
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] FT4 Crashed

[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<mailto: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<mailto: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] Possible bug in WSJTX 2.1.0-RC5 Log-Qso

[David Tiller]

Perhaps add a graphic checkmark and 'X' to the buttons in addition to red/green?


--

David Tiller | Senior Manager
dtil...@captechconsulting.com
o 804.355.0511

[http://www.captechconsulting.com/siggen/logo.png]<http://www.captechconsulting.com/>

[http://www.captechconsulting.com/siggen/Dkblue_Facebook.png]<http://www.facebook.com/CapTechCareers>
 [http://www.captechconsulting.com/siggen/Dkblue_Twitter.png] 
<http://www.twitter.com/CapTechListens>  
[http://www.captechconsulting.com/siggen/Dkblue_LinkedIn.png] 
<http://www.linkedin.com/company/captech-ventures>  
[http://www.captechconsulting.com/siggen/Dkblue_StackOverflow.png] 
<http://www.stackoverflow.com/jobs/companies/captech-consulting>  
[http://www.captechconsulting.com/siggen/Dkblue_YouTube.png] 
<http://www.youtube.com/user/CapTechConsulting>  
[http://www.captechconsulting.com/siggen/Dkblue_Instagram.png] 
<https://www.instagram.com/lifeatcaptech/>
2018 Best Firms to Work For #2 in Information Technology



From: Bill Somerville 
Sent: Tuesday, April 30, 2019 9:17 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Possible bug in WSJTX 2.1.0-RC5 Log-Qso

On 30/04/2019 14:09, Tom Ramberg via wsjt-devel wrote:
As for colour blindness, red and green are the absolute worst alternatives for 
us that are affected. (10% of male population).

73 de Tom OH6VDA
Sendt fra min iPad Air 2

Hi Tom,

I agree but I have not come across a pair of colours that widely imply stop/go, 
bad/good, reject/accept, ... conceptually and that are visible to those with 
red-green colour blindness. Any suggestions?

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 2.1.0-rc5

[David Tiller]

To avoid the OS X crash, manually enter a fake 3 character grid and then the 
call of the other station. At that point everything works as expected (generate 
msgs, etc). 

> On Apr 29, 2019, at 20:00, Dan Malcolm  wrote:
> 
> Voicemeeter Banana
> 
> __
> Dan – K4SHQ
> 
> 
> -Original Message-
> From: Bill Somerville [mailto:g4...@classdesign.com] 
> Sent: Monday, April 29, 2019 4:52 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] WSJT-X 2.1.0-rc5
> 
>> On 29/04/2019 22:43, Dan Malcolm wrote:
>> Just installed WSJT-X 2.1.0 RC5 x64 on my Win10 x64 machine.  Tx works and 
>> seems to be OK, but something rerouted audio from VMB to my system speakers. 
>>  No audio received by WSJT-X (either in RC5 or 2.0.2 ) , but I can sure hear 
>> the caterwauling in the speakers.  The best I can tell, Win10's wonderful 
>> audio routing system (App volume and device preferences) is set correctly.  
>> FWIW I am running VMB 2.0.4.7.
>> 
>> Prior to installing RC5 everything was working fine.
>> 
>> __
>> Dan – K4SHQ
> 
> Hi Dan,
> 
> what is VMB?
> 
> 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

[David Tiller]

I also see a crash. In my case I'm not using FT4 - this is in FT8 mode. If I 
double-click on a CQ-ing station to work them, I get the following stack trace 
(Full trace attached):

VM Regions Near 0:
-->
__TEXT 00010268-000102b48000 [ 4896K] r-x/rwx 
SM=COW  /Users/USER/*/wsjtx.app/Contents/MacOS/wsjtx

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libgfortran.5.dylib   0x000107e432da _gfortran_concat_string + 
23
1   org.k1jt.wsjtx 0x0001027c2c3d azdist_ + 93
2   org.k1jt.wsjtx 0x0001026e7cd5 
MainWindow::on_dxGridEntry_textChanged(QString const&) + 389
3   org.k1jt.wsjtx 0x0001026f7a72 
MainWindow::qt_metacall(QMetaObject::Call, int, void**) + 82
4   org.qt-project.QtCore 0x000107958bfd 
QMetaObject::activate(QObject*, int, int, void**) + 1773
5   org.qt-project.QtWidgets   0x000106b59684 0x106a05000 + 1394308
6   org.qt-project.QtCore 0x00010795914c 
QMetaObject::activate(QObject*, int, int, void**) + 3132
7   org.qt-project.QtWidgets   0x000106b5b186 
QWidgetLineControl::finishChange(int, bool, bool) + 614
8   org.qt-project.QtWidgets   0x000106b5c31a 
QWidgetLineControl::internalSetText(QString const&, int, bool) + 570
9   org.qt-project.QtWidgets   0x000106b53cef 0x106a05000 + 1371375
10  org.k1jt.wsjtx 0x00010273269a 
MainWindow::processMessage(DecodedText const&, QFlags) + 
13658
11  org.k1jt.wsjtx 0x0001026d5a54 
MainWindow::doubleClickOnCall(QFlags) + 820
12  org.k1jt.wsjtx 0x0001026d5d0c 
MainWindow::doubleClickOnCall2(QFlags) + 76
13  org.qt-project.QtCore 0x000107958dbb 
QMetaObject::activate(QObject*, int, int, void**) + 2219
14  org.k1jt.wsjtx 0x000102697b5e 
DisplayText::mouseDoubleClickEvent(QMouseEvent*) + 62
15  org.qt-project.QtWidgets   0x000106a51612 QWidget::event(QEvent*) + 
466
16  org.qt-project.QtWidgets   0x000106af8fdd QFrame::event(QEvent*) + 
45
17  org.qt-project.QtCore 0x0001079281a4 
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) + 148
18  org.qt-project.QtWidgets   0x000106a158d8 
QApplicationPrivate::notify_helper(QObject*, QEvent*) + 248
19  org.qt-project.QtWidgets   0x000106a18748 
QApplication::notify(QObject*, QEvent*) + 7336
20  org.k1jt.wsjtx 0x00010278feb2 (anonymous 
namespace)::ExceptionCatchingApplication::notify(QObject*, QEvent*) + 18
21  org.qt-project.QtCore 0x000107927ef4 
QCoreApplication::notifyInternal2(QObject*, QEvent*) + 212
22  org.qt-project.QtWidgets   0x000106a16210 
QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, 
QWidget**, QPointer&, bool, bool) + 896
23  org.qt-project.QtWidgets   0x000106a70aae 0x106a05000 + 441006
24  org.qt-project.QtWidgets   0x000106a6f795 0x106a05000 + 436117
25  org.qt-project.QtWidgets   0x000106a158ed 
QApplicationPrivate::notify_helper(QObject*, QEvent*) + 269
26  org.qt-project.QtWidgets   0x000106a16cf2 
QApplication::notify(QObject*, QEvent*) + 594

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Apr 29, 2019, at 3:34 PM, George J. Molnar 
mailto:geo...@molnar.tv>> wrote:

Bill, this may help…

After the initial MacOS crash,


 I have been able to reproduce the crash in MacOS by entering a 4-character 
grid. Upon typing the 4th character, the app crashes. A callsign alone doesn’t 
crash it, even if Generate Standard Messages is clicked. Imagine this would 
support the app crashing on double click to reply, as that populates the grid 
field, too.

Geo/KF2T



On Apr 29, 2019, at 3:20 PM, Bill Somerville 
mailto:g4...@classdesign.com>> wrote:

On 29/04/2019 20:14, Gary Rogers wrote:

I’m unable to get the new version to work with Mac OS, will not open and get an 
immediate crash notification

Gary KO3F


Hi Gary,

if the crash report looks like the one reported by Michael above then thanks 
for the issue report, we are looking into it. The dump would contain a stack 
trace starting like this:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libgfortran.5.dylib 0x000113d622da 
_gfortran_concat_string + 23
1   org.k1jt.wsjtx  0x00010e6e0c3d azdist_ + 93
2   org.k1jt.wsjtx  0x00010e605cd5 
MainWindow::on_dxGridEntry_textChanged(QString const&) + 389
3   org.k1jt.wsjtx  0x00010e615a72 
MainWindow::qt_metacall(QMetaObject::Call, int, void**) + 82


If it is a different crash then please provide the crash report details.

73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.ne

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

[David Tiller]

I also see the mode reverting to FT8.

Following the instructions, I set the mode to FT4. I then go into the frequency 
settings and reset them. When I exit that screen, the mode has been reset to 
FT8.

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Apr 29, 2019, at 3:26 PM, Alois Windpassinger 
mailto:alois.windpassin...@gmail.com>> wrote:

hi Gary,
here the same trouble with Mac-OS High Sierra...program crashes and is sending 
a report to Apple...hi
 gl 73 de Alois, dl8rbl

Am Mo., 29. Apr. 2019 um 21:18 Uhr schrieb Gary Rogers 
mailto:cgaryrogers...@gmail.com>>:
I’m unable to get the new version to work with Mac OS, will not open and get an 
immediate crash notification

Gary KO3F

> On Apr 29, 2019, at 3:08 PM, Bill Somerville 
> mailto:g4...@classdesign.com>> wrote:
>
> On 29/04/2019 20:05, James Shaver wrote:
>> Hey Bill - I’ll click on the mode menu, select “FT4” and the mode will 
>> remain in FT8 mode until I close WSJTX down and reopen it.
>>
>> 73,
>>
>> Jim S.
>> N2ADV
>
> Hi Jim,
>
> that seems unlikely. Are you sure you are not looking at the configuration 
> name, perhaps you have a configuration selected on that machine called "FT8".
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



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


--
Alois Windpassinger
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto: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] JT9 FT8 arecord csdr sox and redpitaya

[David Tiller]

You could also generate the filename with:


... -t wav `date +%y%m%d_%H%M%S`.wav


Note that those are back-ticks, not single quotes.


David Tiller | Senior Manager



[http://www.captechconsulting.com/siggen/logo.png]<http://www.captechconsulting.com/>

[http://www.captechconsulting.com/siggen/Dkblue_Facebook.png]<http://www.facebook.com/CapTechCareers>
 [http://www.captechconsulting.com/siggen/Dkblue_Twitter.png] 
<http://www.twitter.com/CapTechListens>  
[http://www.captechconsulting.com/siggen/Dkblue_LinkedIn.png] 
<http://www.linkedin.com/company/captech-ventures>  
[http://www.captechconsulting.com/siggen/Dkblue_StackOverflow.png] 
<http://www.stackoverflow.com/jobs/companies/captech-consulting>  
[http://www.captechconsulting.com/siggen/Dkblue_YouTube.png] 
<http://www.youtube.com/user/CapTechConsulting>  
[http://www.captechconsulting.com/siggen/Dkblue_Instagram.png] 
<https://www.instagram.com/lifeatcaptech/>
2018 Best Firms to Work For #2 in Information Technology



From: Steven Franke via wsjt-devel 
Sent: Thursday, February 28, 2019 8:03 AM
To: WSJT software development
Cc: Steven Franke
Subject: Re: [wsjt-devel] JT9 FT8 arecord csdr sox and redpitaya

Hi Olivier,

I think that the problem is that your wav filename is not in the expected 
format. Try changing from “FT8.wav” to, say, “00_01.wav”.

73 Steve k9an
> arecord_adv -d 15 -q -t raw -f S16_LE -r384000 -c2 -D dsnoop:lp4,1 -F0 
> --period-size=1024 -B0 --buffer-size=4096 | csdr convert_s16_f  | csdr 
> shift_addition_cc `python -c "print float(3568600-3573000)/384000"` | csdr 
> fir_decimate_cc 8 0.05 HAMMING | csdr bandpass_fir_fft_cc 0 0.1 0.05 | csdr 
> realpart_cf | csdr gain_ff 20 | csdr convert_f_s16 | sox -q -t raw -b 16 -e 
> signed -c 1 -r 48000 - -t wav FT8.wav
>
> but when i try to decode with:
>
> At line 188 of file /home/bill/wsjtx-prefix/src/lib/jt9.f90
> Fortran runtime error: Substring out of bounds: lower bound (-1) of 'infile' 
> is less than one
>
> Error termination. Backtrace:
> #0  0x7f46d681f31a
> #1  0x7f46d681fec5
> #2  0x7f46d6820297
> #3  0x5654003b0ceb
> #4  0x5654003ae99e
> #5  0x7f46d58c6b96
> #6  0x5654003aea99
> #7  0x
>
>
> But when i try with other sample in wsjtx sample, it work great:
>
> jt9 --ft8 181201_180245.wav
> 180245   0  0.1  232 ~  K8RGI W6BQ 73
> 180245 -21  0.2  325 ~  CQ RU K1BAA DM03
> 180245  -4  0.0  446 ~  CQ RU W7BOB DN14
> 180245  16  0.1  600 ~  KV4ZY NX8G 539 OH
> 180245  13  0.2  652 ~  KV7J WD9HSY 529 IL
> 180245   3  0.5  786 ~  N8HRZ W7CD 73
> 180245 -16  0.1  841 ~  W7PP AF4T 539 TN
> 180245  -2  0.1 1000 ~  XE1MEX N0UX 559 CO
> 180245   4  0.6 1151 ~  KC8YDS KF6CRW R 559 ID
> 180245 -19  0.1 1442 ~  K1JT 9A2JK RR73
> 180245 -15  0.3 1719 ~  W3RGA KJ7G 529 WA
> 180245  -9  0.1 1799 ~  N9CIF KE0PX DM67
> 180245  12  0.1 1879 ~  W3RGA KM6JD RR73
> 180245  -5  0.1 1980 ~  CQ RU NT2A FN20
> 180245   9  0.2 2189 ~  N9LF WV4P R 529 TN
> 180245   4  0.2 2454 ~  WB3LGC AA5AU R 529 LA
>0  16
>
> have you somme idea?
>
>
>
> ___
> 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] Puzzling behaviour in packets sent to pskreporter

[David Tiller]

The fact that the two signals are almost exactly 120Hz apart indicates that 
60Hz power noise is mixing with the audio somewhere on the signal path.

Since it sounds like multiple people are hearing ghosts from that one station, 
my bet would be that the problem is with the transmitted audio.

On Jan 20, 2019, at 23:12, Mike Lewis 
mailto:k7...@hotmail.com>> wrote:

Hi Philip

One possibility is multiple decodes from extra strong signal and likely an 
overdriven transmitter.  That +13 next to a -15 is a good indicator that the 
-15 is a splatter kind of signal.  I have seen some with 3 or 4 decodes, all 
within a few hundred hertz.

I also get it when I have multiple laptops on the same radio line out cable or 
multiple WSJT-X instances running on the same computer. The monitor-only 
instances decoded during the transmit period and are reporting out.  In my case 
it was +18 though usually without sidebands here. After seeing this I now turn 
off PSK reporter in the monitor instances, as well as in JTAlert for those 
instances.   If you search for K7MDL spots in the last week I have been 
experimenting using my sub receiver with a 2nd instance of WSJT-X and JTAlert. 
You will likely find some odd 6M spots matching my transmissions on the low 
bands.

Additionally, since the 2nd and 3rd+ instances are not connected to the radio, 
they do not change band info, so more than once I had the wrong band reported 
for the spots it did make.  Now I try to make it a routing to disable spotting 
for non-rig connected instances.


  *   Mike K7MDL

From: Philip Gladstone 
mailto:pjsg-w...@nospam.gladstonefamily.net>>
Sent: Sunday, January 20, 2019 22:34
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Puzzling behaviour in packets sent to pskreporter

I notice that I am getting a bunch of duplicates in the packets (as seen in the 
raw packet captures) being sent to pskreporter. For example:

WE6Z reported seeing KG7VOR twice at Jan 21, 2019 03:03:29. The only 
differences were:

One entry had Frequency 1841279 with snr -15
Another had Frequency 1841400 with snr of 13

In fact there were 9 spots of KG7VOR in the same packet (at five difference 
timestamps).

This is not limited to a few cases, but it appears a fair amount.

At the same time, I'm getting comments from people that not all of their spots 
are being reported -- so I'm wondering if this duplication is actually a 
symptom of something more serious

Puzzled

Philip
___
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] Operation below 200 Hz

[David Tiller]

Jeff,


I saw the same behavior in the RTTY roundup - the tx freq would not dip below 
200 Hz no matter what I tried. I had the min freq set to 100 Hz so I removed 
that but it didn't help.


--

David Tiller | Senior Manager
dtil...@captechconsulting.com
o 804.355.0511

[http://www.captechconsulting.com/siggen/logo.png]<http://www.captechconsulting.com/>

[http://www.captechconsulting.com/siggen/Dkblue_Facebook.png]<http://www.facebook.com/CapTechCareers>
 [http://www.captechconsulting.com/siggen/Dkblue_Twitter.png] 
<http://www.twitter.com/CapTechListens>  
[http://www.captechconsulting.com/siggen/Dkblue_LinkedIn.png] 
<http://www.linkedin.com/company/captech-ventures>  
[http://www.captechconsulting.com/siggen/Dkblue_StackOverflow.png] 
<http://www.stackoverflow.com/jobs/companies/captech-consulting>  
[http://www.captechconsulting.com/siggen/Dkblue_YouTube.png] 
<http://www.youtube.com/user/CapTechConsulting>  
[http://www.captechconsulting.com/siggen/Dkblue_Instagram.png] 
<https://www.instagram.com/lifeatcaptech/>
2018 Best Firms to Work For #2 in Information Technology



From: jeff millar 
Sent: Wednesday, January 16, 2019 6:41 AM
To: WSJT Group; WSJT software development
Subject: [wsjt-devel] Operation below 200 Hz

There was a station operating on a reported frequency of 68 Hz.  It showed up 
on the waterfall at that location.  I have my Rx passband set to cover those 
low frequencies.

The green frequency marker was placed on 200 Hz.  When I tried to shift-click 
to his frequency, the Tx would only go as low as 200 Hz.

How did that operator set the Tx frequency to 68 Hz?

We worked, no problem.  But the display doesn't match the operation.

Any recommendations for this situation?

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

Re: [wsjt-devel] Mac Mini (late 2014) Problem with 1.9 and 2.0 with Mojave 10.14.2

[David Tiller]

My values are exactly the same as yours except for that last one, so if the 
config tests don't solve your issue you might give changing that to 8192 a 
shot. 

> On Dec 20, 2018, at 23:01, David Tiller  wrote:
> 
> 
>> kern.sysv.shmall: 8129
> 
> For what it's worth, that value looks like a typo - it probably ought to be 
> 8192, a power of 2. 
> 
> 
>> On Dec 20, 2018, at 20:13, Jim Kennedy  wrote:
>> 
>> kern.sysv.shmall: 8129
> 
> 
> ___
> 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] Mac Mini (late 2014) Problem with 1.9 and 2.0 with Mojave 10.14.2

[David Tiller]

> kern.sysv.shmall: 8129

For what it's worth, that value looks like a typo - it probably ought to be 
8192, a power of 2. 


> On Dec 20, 2018, at 20:13, Jim Kennedy  wrote:
> 
> kern.sysv.shmall: 8129


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

Re: [wsjt-devel] On my wish list: Notification sounds.

[David Tiller]

Allan,

I never intended my comment as a personal dig blaming you for sending voice - I 
apologize!

Here's an example of what I mean: 
https://drive.google.com/open?id=1ZRdqkwo3UM-Swk9Ofat6GNcRkOcKa35f

This was recoded on 7076 kHz on June 8th, 2017. About 11 secs in you hear a 
digital voice saying "CQ". Sometimes that's accompanied by "New XXX" where XXX 
is country/grid/etc.

I've also heard a few audio chats with grandkids, etc. :-)


--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Dec 7, 2018, at 2:10 PM, Allan mailto:al...@nelsson.net>> 
wrote:

David,

You have never heard me (and actually I have never heard others!). Of course an 
alternative sound output should be used for that. It’s in general always a good 
idea to disable Windows system- and ALL other sounds when running digital 
modes. Actually I can easily run WSJT-X and at the same time be on Skype. I’m 
using the USB audio codec with my 7300 and Realtek for e.g. Skype and JTAlert. 
Never had any problems.

73, Allan


Fra: David Tiller [mailto:dtil...@captechconsulting.com]
Sendt: 7. december 2018 17:22
Til: al...@nelsson.net<mailto:al...@nelsson.net>; WSJT software development
Emne: Re: [wsjt-devel] On my wish list: Notification sounds.

> And yes, I know that JTAlert can do it (I have earlier used this function 
> with great success)

It's so successful that I hear "CQ" spoken over the air on non-phone freqs at 
least 5 different times a week. It gets very old hearing that for hours at a 
time.

If the devs do decide to add sounds, please let's make sure that the alert 
sound interface is __never__ the same as the radio sound interface.

--
David Tiller | Senior Manager

dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>

o 804.355.0511


[http://www.captechconsulting.com/siggen/logo.png]<http://www.captechconsulting.com/>


[http://www.captechconsulting.com/siggen/Dkblue_Facebook.png]<http://www.facebook.com/CapTechCareers>
 [http://www.captechconsulting.com/siggen/Dkblue_Twitter.png] 
<http://www.twitter.com/CapTechListens>  
[http://www.captechconsulting.com/siggen/Dkblue_LinkedIn.png] 
<http://www.linkedin.com/company/captech-ventures>  
[http://www.captechconsulting.com/siggen/Dkblue_StackOverflow.png] 
<http://www.stackoverflow.com/jobs/companies/captech-consulting>  
[http://www.captechconsulting.com/siggen/Dkblue_YouTube.png] 
<http://www.youtube.com/user/CapTechConsulting>  
[http://www.captechconsulting.com/siggen/Dkblue_Instagram.png] 
<https://www.instagram.com/lifeatcaptech/>

2018 Best Firms to Work For #2 in Information Technology



From: m...@oz5xn.dk<mailto:m...@oz5xn.dk> mailto:m...@oz5xn.dk>>
Sent: Friday, December 7, 2018 9:51 AM
To: wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
Subject: [wsjt-devel] On my wish list: Notification sounds.

Am I really the only one there would love to have notification / alarm sounds? 
I really miss the possibility for a sound when own call sign is decoded. This 
is very useful when calling CQ with long time between responses. Another sound 
for any call decoded is useful e.g. when monitoring MSK 144 under low activity 
and poor conditions. Sounds could be a beep, ding or a user defined wav file.
And yes, I know that JTAlert can do it (I have earlier used this function with 
great success), but after the new great color markings for B4 etc. became 
included in WSJT-X, it’s not any longer necessary for me to use JTAlert (except 
for the sounds). I’m running remote controlled for most of the winter time and 
wish to minimize the remote set-up software. Please consider implementation of 
such a feature in a future version. Thanks for your efforts and fantastic work!

Vy 73 de 5P9R/OZ5XN, Allan

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

Re: [wsjt-devel] On my wish list: Notification sounds.

[David Tiller]

> And yes, I know that JTAlert can do it (I have earlier used this function 
> with great success)


It's so successful that I hear "CQ" spoken over the air on non-phone freqs at 
least 5 different times a week. It gets very old hearing that for hours at a 
time.


If the devs do decide to add sounds, please let's make sure that the alert 
sound interface is __never__ the same as the radio sound interface.


--

David Tiller | Senior Manager
dtil...@captechconsulting.com
o 804.355.0511

[http://www.captechconsulting.com/siggen/logo.png]<http://www.captechconsulting.com/>

[http://www.captechconsulting.com/siggen/Dkblue_Facebook.png]<http://www.facebook.com/CapTechCareers>
 [http://www.captechconsulting.com/siggen/Dkblue_Twitter.png] 
<http://www.twitter.com/CapTechListens>  
[http://www.captechconsulting.com/siggen/Dkblue_LinkedIn.png] 
<http://www.linkedin.com/company/captech-ventures>  
[http://www.captechconsulting.com/siggen/Dkblue_StackOverflow.png] 
<http://www.stackoverflow.com/jobs/companies/captech-consulting>  
[http://www.captechconsulting.com/siggen/Dkblue_YouTube.png] 
<http://www.youtube.com/user/CapTechConsulting>  
[http://www.captechconsulting.com/siggen/Dkblue_Instagram.png] 
<https://www.instagram.com/lifeatcaptech/>
2018 Best Firms to Work For #2 in Information Technology



From: m...@oz5xn.dk 
Sent: Friday, December 7, 2018 9:51 AM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] On my wish list: Notification sounds.


Am I really the only one there would love to have notification / alarm sounds? 
I really miss the possibility for a sound when own call sign is decoded. This 
is very useful when calling CQ with long time between responses. Another sound 
for any call decoded is useful e.g. when monitoring MSK 144 under low activity 
and poor conditions. Sounds could be a beep, ding or a user defined wav file.

And yes, I know that JTAlert can do it (I have earlier used this function with 
great success), but after the new great color markings for B4 etc. became 
included in WSJT-X, it’s not any longer necessary for me to use JTAlert (except 
for the sounds). I’m running remote controlled for most of the winter time and 
wish to minimize the remote set-up software. Please consider implementation of 
such a feature in a future version. Thanks for your efforts and fantastic work!



Vy 73 de 5P9R/OZ5XN, Allan


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

Re: [wsjt-devel] WSJT-X v2.0.0 RC3 LotW Users Data File errors

[David Tiller]

> LOTW and EQSL status are provided by JTAlertX ...

... which does not run under Linux or OSX. There is JT-Bridge for OSX, however.

I agree with letting the user download the file from the ARRL if they wish, on 
their schedule.

Interestingly, chrome was seemingly able to download the file via HTTP as was 
command-line curl (the --proto forces HTTP only):

curl -o lotw.csv --proto =http http://lotw.arrl.org/lotw-user-activity.csv

--
David Tiller
Sr. Architect/Lead Consultant | CapTech



On Oct 17, 2018, at 3:51 PM, David Fisher 
mailto:dsfis...@outlook.com>> wrote:

LOTW and EQSL status are provided by JTAlertX

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

Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol

[David Tiller]

Your example of pskreporter and hamspots are not involved in and do not 
facilitate QSOs - they only collect metadata of QSOs. Any attempt to involve 
the internet with the completion of QSOs will probably be rejected by the ham 
community.

If you want ham radio to rely on the internet, get yourself a chat client and 
hang up your mic.

On Sep 9, 2018, at 14:34, Игорь Ч via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:

Hello Robin,
.
That is correct, it also can be considered as moving costs of power amplifiers 
and antenna systems to the server/software.
At the moment we have approximately 65k FT8 users and there should be simple 
control layer protocol, costs may be similar to keeping 
pskreporter.info and hamspots.net 
at 24x7 operation.
.
73 Igor UA3DJY


Date: Sun, 9 Sep 2018 01:32:20 +0100
From: "G8DQX (WSJT developers on SF)" 
mailto:wsjtde...@gape.me.uk>>
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol
Message-ID: 
mailto:cdad522e-acfc-16b7-53f2-766fbad16...@gape.me.uk>>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Igor,

you forgot to mention that HLR & VLR technology is a *network* artefact,
generally to be found in mobile telecommunications networks. The
application to the Amateur Radio Service, where there are a large number
of stations but *no* over-arching network control is very unclear.

For a public telecommunications network HLRs and VLRs, more accurately
their interfaces, are defined by standards developing organisations
(SDOs) such as 3GPP, paid for by network operators, and usually
developed by network manufacturers. These things are not cheap, and they
require continual maintenance and end-of-life replacement!

What did you really have in mind?

Robin, G8DQX

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

Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol

[David Tiller]

Amen, George. Ham radio is about _radio_, not the internet.

On Sep 8, 2018, at 19:13, George J Molnar 
mailto:geo...@molnar.com>> wrote:

While it probably is a remote possibility that the WSJT-X team is contemplating 
adding internet-based linkages, I want to agree with N2ADV and emphatically say 
“no!” to any ham radio communications protocol that relies on anything but ham 
radio to work effectively.

Even in this day of skimmers and spotting networks, automatic rotators, and 
auto-sequenced contacts, the contact itself is still a radio contact, and 
should remain so in its entirety.


George J Molnar
Arlington, Virginia, USA
KF2T   -   FM18lv






On Sep 8, 2018, at 6:38 PM, James Shaver 
mailto:kd2...@gmail.com>> wrote:

Yes but my previous question about Internet usage still stands: When I am 
sitting in a park or out on a snowmobile trail with my KX3 and my laptop using 
a GPS for time sync since there’s no cell reception there, anything that relies 
on the Internet will be basically useless to me.  Why would we aim to exclude a 
growing number of such users like me?  Perhaps I’m misunderstanding.

Jim S.
N2ADV

___
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] A strange signal seen on the air

[David Tiller]

Claude,

That sounds a lot like a dirty FT8 signal that has second (and possibly higher) 
harmonics. 

I have a screenshot of a signal with seven (yes 7) higher order harmonics. 

> On Jul 31, 2018, at 06:07, Claude Frantz  wrote:
> 
> Hi All,
> 
> Sometimes, I have seen a strange signal on the air, in the usual FT8
> "sub band". There are 8 tones in a bandwidth of 100 Hz and a TX duration
> of 15 s. Is this a CLOVER signal or anything else ?
> 
> Best wishes,
> Claude (DJ0OT)
> 
> --
> 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

--
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] Tuning in Hound mode

[David Tiller]

The 'tune' button will help with tuning, but not ID-ing. At least in the US 
(and maybe also in Canada), it's always legal to ID using CW regardless of the 
mode used for comms - you could use your key/keyer to ID, or have a preset in 
your rig that fires off your callsign.

There is/was a CW ID option in 'normal' FT8 mode but I don't know if that is 
intended to work w/ F mode.

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Jul 3, 2018, at 2:13 PM, August Treubig 
mailto:atreu...@sbcglobal.net>> wrote:

There is a Tune button on the far right

Sent from my iPad

On Jul 3, 2018, at 12:25 PM, Mark Spencer 
mailto:netsyn...@gmail.com>> wrote:

Hi:
I've enjoyed watching the pile ups over the last few days while using hound 
mode.   Thanks to the development team for this mode.


I don't spend much time on HF and when I do I typically use a vertical antenna 
fed with an auto tuner.   So when changing bands I need to feed RF into the 
auto tuner so will tune.   To be legal I need to Identify when I transmit.

In normal mode it is easy to simply transmit my call via a free message.

This doesn't seem to be possible without switching out of hound mode.   Not a 
huge issue but perhaps in the future a simple way to send ones call could be 
provided while in Hound Mode ?  I realize I can send the TX one message but I 
don't like calling the DX station if I can't hear them.

Switching to "message set number 2" on the main screen while in hound mode and 
manually selecting a free message still results in the TX one message being 
sent.

(The free message option is not available in "message set number 1")

73

Mark Spencer
VE7AFZ
netsyn...@gmail.com<mailto:netsyn...@gmail.com>



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
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] What happens when Hound does not receive RR73?

[David Tiller]

At least with this current dxpedition, I suggest you at least tentatively log 
contacts as soon as you have received a report from the fox and have sent yours.

I had been trying to contact KH1/KH7Z on 20m but the only success I had were 2 
'busted' sequences. I never saw a RR73 for either of them but lo and behold 
both tries were logged on their side.

On Jul 2, 2018, at 15:49, Joshua B Nass 
mailto:josh.n...@gmail.com>> wrote:

I let it run six attempts then I stop it.  Since the RR73 is incoming from the 
Fox and I have all the details I need for entry into my log, I log it, then 
wait for the Club Log verification.  If I am in the fox log on the that band I 
will upload my log.

On Mon, Jul 2, 2018 at 3:07 AM, Charles Suckling 
mailto:char...@sucklingfamily.free-online.co.uk>>
 wrote:
Hi All

20m conditions were a bit better today and I finally managed to work Baker with 
100W, lots of feeder loss and a sloping dipole.

The problem I had was, after receiving my report from KH7Z, I failed to receive 
RR73.  Thanks to Bill’s advice to start over again (TX1 message), on the 4th 
QSO attempt (this time with G4KGC in the shack)  I finally got my RR73.  Within 
about 5 sequences they came back again with a report again, and QSO attempts 
proceeded normally.

Decoding was reasonably reliable at the time.  It seems  they did not receive 
my TX3 message, hence did not send RR73, rather than me not decoding the RR73.

What became apparent was that under these circumstances my TX freq was shifted 
three times, then stuck on the final frequency and transmissions would have 
continued at infinitum:

I guess this is what is expected as the User guide para 14 says:



Here is an example of one of the failed attempts:


083545 Tx 3056 ~ KH7Z G3WDG IO92

083630 -13 -0.5 390 ~ G3WDG KH7Z -15

083645 Tx 390 ~ KH7Z G3WDG R-13

083700 -16 -0.6 389 ~ G3WDG KH7Z -15

083715 Tx 389 ~ KH7Z G3WDG R-16

083730 -14 -0.6 330 ~ G3WDG KH7Z -15

083745 Tx 330 ~ KH7Z G3WDG R-14

083815 Tx 630 ~ KH7Z G3WDG R-14

083845 Tx 630 ~ KH7Z G3WDG R-14

083915 Tx 630 ~ KH7Z G3WDG R-14

083945 Tx 630 ~ KH7Z G3WDG R-14

084015 Tx 630 ~ KH7Z G3WDG R-14
084045 Tx 630 ~ KH7Z G3WDG R-14

After moving to 630 it stayed there and continued transmitting until I 
intervened, thinking that the QSO had failed and I was unnecessarily causing 
QRM.

Should I have waited longer for Fox to respond?

In the situation where hounds to not receive their  RR73,  presumably  a wall 
of QRM below 1000 develops for Fox making it more difficult for QSOs to 
complete?  I saw other stations in the same fix as I was, repeating their TX3 
messages for many periods.

73

Charlie






[Avast logo] 


This email has been checked for viruses by Avast antivirus software.
www.avast.com



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
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
--
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] OSX 10.13.5 and WSJTX-1.9.x leaves mystery box on screen

[David Tiller]

Dear devs,

I recently upgraded my Mac to OSX 10.13.5 and started noticing a strange 
behavior when starting WSJTX-1.9.x (the two may not be related).

When I start WSJTX-1.9.0 or 1.9.1, I get a small textbox popup that reads in 
part "Transmit digital gain" - the rest gets cut off. This box pops up on 
startup wherever my cursor happens to be (inside or outside the main app 
window). After a second or so the text disappears, leaving the shadowed box.

I uploaded a screenshot here: https://imgur.com/a/VVVNYJv

As you can see, I have a shortcut on the tak bar that I use to start the app 
(near the left center, right below the 'q' in "Auto seq"). The box hiding part 
of the task bar is the one in question. It contained the above "Transmit 
digital gain" text momentarily. The box cannot be moved, and it disappears 
immediately when I quit wsjtx. This happens regardless of whether the app is 
started from the clicking in the taskbar or the finder or from using 'open 
wsjtx-1.9.1.app' from a terminal window.

This does not happen with 1.8. Could this be a Qt version difference?

The only reference to that text that I could find was in the file 
mainwindow.cpp:

void MainWindow::on_outAttenuation_valueChanged (int a)
{
  QString tt_str;
  qreal dBAttn {a / 10.};   // slider interpreted as dB / 100
  if (m_tune && m_config.pwrBandTuneMemory()) {
tt_str = tr ("Tune digital gain ");
  } else {
tt_str = tr ("Transmit digital gain ");
  }
  tt_str += (a ? QString::number (-dBAttn, 'f', 1) : "0") + "dB";
  if (!m_block_pwr_tooltip) {
QToolTip::showText (QCursor::pos (), tt_str, ui->outAttenuation);
  }

Any ideas?

Thanks and 73 de K4DET


--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Decouple Contest checkbox?

[David Tiller]

Rich,


I agree it should be decoupled, but disagree that a button that's used at most 
twice a year deserves a spot on the main screen. It should be in settings along 
with other rarely-used options.


--

David Tiller | Senior Manager
dtil...@captechconsulting.com
c 804.304.0638 / o 804.355.0511

[http://www.captechconsulting.com/siggen/logo.png]<http://www.captechconsulting.com/>

[http://www.captechconsulting.com/siggen/Dkblue_Facebook.png]<http://www.facebook.com/CapTechCareers>
 [http://www.captechconsulting.com/siggen/Dkblue_Twitter.png] 
<http://www.twitter.com/CapTechListens>  
[http://www.captechconsulting.com/siggen/Dkblue_LinkedIn.png] 
<http://www.linkedin.com/company/captech-ventures>  
[http://www.captechconsulting.com/siggen/Dkblue_StackOverflow.png] 
<http://www.stackoverflow.com/jobs/companies/captech-consulting>  
[http://www.captechconsulting.com/siggen/Dkblue_YouTube.png] 
<http://www.youtube.com/user/CapTechConsulting>  
[http://www.captechconsulting.com/siggen/Dkblue_Instagram.png] 
<https://www.instagram.com/lifeatcaptech/>
Best Firms 2016 #2 in Information Technology



From: Rich - K1HTV 
Sent: Tuesday, June 12, 2018 11:59 AM
To: WSJT
Subject: [wsjt-devel] Decouple Contest checkbox?


Is there any reason why the WSJT-X "NA VHF Contest" checkbox cannot be 
decoupled from the "Enable VHF/UHF/Microwave Features" check box under the 
"General" settings tab? One of the most frequent questions asked on contest 
club reflectors, prior to and during the recent ARRL VHF Contest, related to 
how to find the "NA VHF Contest" box.


If that check box is always available on the main screen, when an alert message 
about having to be in the VHF Contest mode pops up, it would be less 
complicated for all to activate it. This is especially important for the newer 
or more casual FT8 ops who haven't yet read the manual.


A number of post-VHF contest emails, specifically mentioned the problem of 
trying to complete contest QSOs with casual FT8 ops who called w/o activating 
the "NA VHF Contest" box, which probably didn't even appear on their main 
WSJT-X screen.


73,
Rich - K1HTV
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug Report: Version 1.9.1

[David Tiller]

John,

The easiest way to eliminate RFI as the culprit is to transmit with either your 
power level at zero or into a well-matched dummy load with a short, shielded 
cable (or both at the same time).

If the problem happens with no RF out, you're correct that it's not RFI.

The next step is to eliminate CAT control - run without CAT and use RS-232 PTT.

If you still suspect WSJT-X, try running PSK31 or another digital mode. If that 
works and WSJT-X doesn't, you're right again.

My bet (if not RFI) would be a crappy Vista driver. I've had the exact same 
symptoms, and it was RF. Judicious application of split toroids on every wire 
within reach fixed my issue.

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Jun 6, 2018, at 4:48 PM, John C. Westmoreland, P.E. 
mailto:j...@westmorelandengineering.com>> 
wrote:

Jim,

OK - so the claim I'm reading here is Hamlib is 1000% bug-free regarding 
Vista-64?  I'm very skeptical about that; the most obvious issue and nothing 
mentioned thus
far obviates this.

I'm looking into the obvious first.  If my rig was so poorly configured; how in 
the world did I make a contact with Argentina?

And, I've made a lot of other contacts.  Including Virginia, North Carolina, 
New York, and North Dakota not to mention Japan.  And Arizona, and California, 
and
Oregon, and Washington...

Since the thread running WSJT-X can't be killed; I'm looking into that first; 
and the cause of that.

The next obvious step for me is to make builds myself and look into the source 
code.

73's,
John
AJ6BC


On Wed, Jun 6, 2018 at 12:59 PM, Jim Brown 
mailto:k...@audiosystemsgroup.com>> wrote:
On 6/6/2018 12:36 PM, John C. Westmoreland, P.E. wrote:
That's an interesting hypothesis.  Since USB is differential signaling - it has 
some noise immunity; but I will definitely check into this.

Hum/buzz gets into our systems as a result of failure to implement proper 
bonding between interconnected equipment, combined with improper termination of 
shields within equipment by their designers. Study my tutorial on this, which 
goes through both circuit analysis of the problem and details good engineering 
practice.

http://k9yc.com/GroundingAndAudio.pdf

Or study N0AX's new ARRL book on the topic, which was inspired by my tutorial, 
and to which I made many contributions.

73, Jim K9YC


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! 
http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
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] More on Difficulties to get WSJT-X to accept UDP type 4 message from server

[David Tiller]

In addition to what Laurie said, this part of your reply looks like ASCII where 
the QTime field should be:  4c4f47474552

"adbccbda000200040006

---> 4c4f47474552 = LOGGER

0451ba68ffef3fd9a6a700017e000f4b31564b20463642484b204a4e32340000"


--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Mar 22, 2018, at 5:28 PM, Laurie, VK3AMA 
<_vk3a...@vkdxer.net<mailto:vk3a...@vkdxer.net>> wrote:



On 23/03/2018 7:27 AM, F6BHK wrote:
I have digged deeper in my problem:

a) Network infra: The server uses a multicast group. There is no router between 
the WSJT-X client and the server; only a switch. I have verified with tcpdump 
on both sides that the packet are seen by both camps.

b) I have written a quick PHP client that I have plugged on the same network as 
the server and the WSJT-X client. The server and the PHP client establish a 2 
way dialog with no pain. The WSJT-X client stays deaf. However it speaks as 
expected.

For example, I receive this DECODE message from WSJT-X:

2018/03/22 20:07:59 server.php - Received 66 bytes from remote IP: 
192.168.60.53:63580
2018/03/22 20:07:59 server.php magic binary : [adbccbda]
2018/03/22 20:07:59 server.php schema binary : [0002]
2018/03/22 20:07:59 server.php type of message binary : [0002]
2018/03/22 20:07:59 server.php DECODE id : [0006: WSJT-X]
2018/03/22 20:07:59 server.php DECODE new : [01]
2018/03/22 20:08:00 server.php DECODE time : [72465000 -> 20:07:45]
2018/03/22 20:08:00 server.php DECODE snr : [ffef -> 0010 -> -17]
2018/03/22 20:08:00 server.php DECODE delta time : [3fd9a000 -> 
0.4000596046]
2018/03/22 20:08:00 server.php DECODE delta : [1703 Hz]
2018/03/22 20:08:00 server.php DECODE mode : [0001: ~]
2018/03/22 20:08:00 server.php DECODE message : [000c: CQ K1VK FN42]
2018/03/22 20:08:00 server.php DECODE Low confidence : [00]
2018/03/22 20:08:00 server.php DECODE Off air : [00]

The server asks WSJT-X to initiate a response with this message:

2018/03/22 20:08:29 server.php SEND TO WSJT-X id : [00064c4f47474552 size: 
0006]
2018/03/22 20:08:29 server.php SEND TO WSJT-X time : [0451ba68 -> 0451ba68 -> 
20:07:45]
2018/03/22 20:08:29 server.php SEND TO WSJT-X snr : [ffef -> -17]
2018/03/22 20:08:29 server.php SEND TO WSJT-X deltatime : [3fd9a000 -> 
0.4000596046]
2018/03/22 20:08:29 server.php SEND TO WSJT-X delta : [06a7 -> 1703 Hz]
2018/03/22 20:08:29 server.php SEND TO WSJT-X mode : [00017e]
2018/03/22 20:08:29 server.php SEND TO WSJT-X message : 
[000f4b31564b20463642484b204a4e3234 -> len: 000F -> K1VK F6BHK JN24]
2018/03/22 20:08:29 server.php SEND TO WSJT-X lowconfidence : [00]
2018/03/22 20:08:29 server.php SEND TO WSJT-X modifiers : [00]
2018/03/22 20:08:29 server.php SEND TO WSJT-X frame : 
[adbccbda0002000400064c4f474745520451ba68ffef3fd9a6a700017e000f4b31564b20463642484b204a4e3234]
2018/03/22 20:08:29 server.php SEND TO WSJT-X frame envoyee : [68 bytes, 
239.73.0.0:2237 UDP: 68]

WSJT-X ignore the message. But the PHP client decodes it no worries:

client.php - FRAME 09 --
client.php - Received 68 bytes from remote IP: 192.168.60.162:2237
client.php magic binary : [adbccbda]
client.php schema binary : [0002]
client.php type of message binary : [0004]
client.php id : [LOGGER]
client.php time : [72465000 -> 20:07:45]
client.php DECODE snr : [ffef -> 0010 -> -17]
client.php DECODE delta time : [3fd9a000 -> 0.4000596046]
client.php DECODE delta : [1703 Hz]
client.php DECODE mode : [0001: ~]
client.php DECODE message : [000f: K1VK F6BHK JN24]
client.php DECODE Low confidence : [00]
client.php DECODE modifiers : [00]

I have read in MessageNetwork.hpp the the id must be the Target unique id. I 
tried with the WSJT-X client id and with something else to no avail.

I have noted a difference between the mode from DECODE message (the letter ~) 
and the mode from the STATUS message (plain text FT8). None of them awake 
WSJT-X client.

I must say that I could use some help from here! I really am at a loss to 
understand what goes on here.

Any taker ?

Cheers

Serge



On 21/03/2018 19:22, F6BHK wrote:
Good Evening


While I am able to received and decode all the messages that come out of WSJT-X 
via UDP, I have some difficulties to get WSJT-X client to accept the server 
type 4 messages.

I have checked in the settings all 3checkboxes "Accept UDP requests", "Notify 
on accepted UDP request", "Accepted UDP requests restores windows" in the hope 
to get some feedback from the client.

I was expecting some updates on the client window with some of the data 
contained in the UDP message I send and an acknowledgement 

Re: [wsjt-devel] Frequency Labels Suggestion

[David Tiller]

 > If the future actual fox/hound dxpedition modes are going to be on 
 > non-standard frequencies like the

> recent test was, it would be good if we could add a label to the frequencies 
> so that we don't get confused

> after we capture the fox and go back to regular mode.


How about a separate list for normal ops vs fox/hound ops?


David Tiller | Senior Manager
dtil...@captechconsulting.com
c 804.304.0638 / o 804.355.0511

[http://www.captechconsulting.com/siggen/logo.png]<http://www.captechconsulting.com/>

[http://www.captechconsulting.com/siggen/Dkblue_Facebook.png]<http://www.facebook.com/CapTechCareers>
 [http://www.captechconsulting.com/siggen/Dkblue_Twitter.png] 
<http://www.twitter.com/CapTechListens>  
[http://www.captechconsulting.com/siggen/Dkblue_LinkedIn.png] 
<http://www.linkedin.com/company/captech-ventures>  
[http://www.captechconsulting.com/siggen/Dkblue_StackOverflow.png] 
<http://www.stackoverflow.com/jobs/companies/captech-consulting>  
[http://www.captechconsulting.com/siggen/Dkblue_YouTube.png] 
<http://www.youtube.com/user/CapTechConsulting>  
[http://www.captechconsulting.com/siggen/Dkblue_Instagram.png] 
<https://www.instagram.com/lifeatcaptech/>
Best Firms 2016 #2 in Information Technology



From: Kirk Crawford <k...@kirkanddonna.com>
Sent: Friday, March 9, 2018 1:22 PM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Frequency Labels Suggestion

If the future actual fox/hound dxpedition modes are going to be on non-standard 
frequencies like the recent test was, it would be good if we could add a label 
to the frequencies so that we don't get confused after we capture the fox and 
go back to regular mode.  I personally deleted the frequencies I had entered 
for the open fox/hound test afterwards because then I had two 20m and 40m etc 
in my drop down menu.  If we had a label that showed up in that menu as well, 
we could distinguish the frequencies easier than just the number.

Kirk
KK6KC


--
Kirk Crawford
k...@kirkanddonna.com<mailto:k...@kirkanddonna.com>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] PSK Reporter ANTENNA

[David Tiller]

Interestingly there's an article in the Feb QST about this very subject written 
by Steve Ford, WB8IMY. The article's title? "Antenna Reporting with WSJT-X".


If you're a member you can access the article online.



From: Gary McDuffie 
Sent: Thursday, January 25, 2018 8:02 AM
To: sv1...@yahoo.com; WSJT software development
Subject: Re: [wsjt-devel] PSK Reporter ANTENNA



> On Jan 25, 2018, at 1:03 AM, Dennis Drakopoulos via wsjt-devel 
>  wrote:
>
> I believe it would be beneficial for all if WSJT software development team 
> could add as a feature, to allow the user to provision antenna information 
> field on the spots being uploaded to PSK REPORTER project.

I’ve never seen antenna information given by pskreporter.  Do they even have 
that provision?

Gary - AG0N
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
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] NA VHF Contest mode

[David Tiller]

Just a thought, but maybe the devs could only enable that checkbox and 
functionality if the user's grid is outside the "antipodal region" where NA 
calls are mapped. 

> On Dec 19, 2017, at 20:53, Peter Sumner  wrote:
> 
> Hi Dev team,
>since the inclusion of "NA VHF Contest mode" in WSJT a lot of VK and I 
> believe also ZL operators get to see a popup from WSJT-X that wants them to 
> enable "Contest Mode?".  I have spoke directly to many that have experienced 
> this and a lot of them have just stopped using WSJT-X in favor of the MSHV 
> software to avoid the error.
> 
> All those I have asked about this assure me they do not have the tick in the 
> contest mode option but we still see this from WSJT-X during normal 
> operations on MSK144 & FT8 (screen grab attached)
> 
> Could an option be included in WSJT-X that forcibly disables the popup / mode 
> or some way for us to be rid of this?  In many case the pop up box gets 
> missed on a PC with a busy desktop and the OP wonders why WSJT-X has stopped 
> responding.
> 
> If there is any extra testing needed to chase this down,, I am happy to 
> provide as much detail as I can muster.
> 
> Regards,
> Peter Sumner, VK5PJ from down under
> 
> 
> 
> 
> --
> 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

--
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] dual transmit

[David Tiller]

Mike,

I see this sort of overmodulation all the time. In fact I can hear it most of 
the time (it sounds nasty) even when there are 20 or so signals. Note that the 
harmonics are at n-times the frequency of the fundamental, and they're n-times 
wider. This is the result of the modulating audio signal being hideously 
distorted somewhere along the chain. I sometimes see only odd harmonics 
(flat-topping into square waves) or all harmonics ( I've seen up to 7th with 
someone txing down near 300Hz.

On Dec 11, 2017, at 14:22, Black Michael via wsjt-devel 
> 
wrote:

Several people have reported seeing thisI saw it yesterday too for the 1st 
time.
I don't think it's overmodulation otherwise we should see it more often.

de Mike W9MD B



On Monday, December 11, 2017, 1:17:27 PM CST, Daniel Ekman 
> wrote:


This is a example of some sort of overmodulation, I think, causing the tones to 
spread out in four additional groups without decode. I don't really know what 
is causing this, but as Jerry says it's not all strong signals that look like 
this. Tried answering and that worked quite well. Running TS590S with built in 
USB soundcard/serial. The next time I see this I will try to put the main 
signal outside the passband and see if the other parts are still visible.


--
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
--
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
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Another Compound Callsign Problem

[David Tiller]

Interesting. I just worked 4O4A on 80m FT8 and it proceeded perfectly. I'm 
using 1.8 final.

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Dec 4, 2017, at 9:04 PM, Morris Wideman via wsjt-devel 
<wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:

Another call that really fouls up WSJT-X is 4O4A see attached picture of what 
the TX boxes have in them. I turned off auto-seq typed in correct response to 
send. Hopefully he copied but it took several re-sends
73 wa4mit Morris

On Monday, December 4, 2017, 5:36:00 PM CST, Libor Holous OK2ZO 
<ok...@email.cz<mailto:ok...@email.cz>> wrote:


Dear Scott..

Look.. As I said, experienced smart operator will get the call correctly..
The others can repair it in their logs anytime later. It's not your problem. 
The system is setup this way, so if you can't get standard call, you must use 
compound and count with it.
Lets see the example, not only for you or Gary...

On your side, I'd not use automatic reply 1st. Sit to some QRG, best lower one 
300-500Hz, switch fixed QRG on.
Tx6 CQ UP TI5/W7RI
Tx5 DE TI7/W7RI EJ79 - to include square for square hunters.
Tx4 switch to RR73

In Settings - set Doubleclick enable TX.. Open logging dialog automaticaly.

And lets go for QSO as automat works..
CQ UP...

Who replies with Tx1:
TI7/W7RI OK2ZO
OK2ZO W7RI -01
W7RI OK2ZO R-02
OK2ZO W7RI RR73 ... opens logging dialog - logging QSO
W7RI OK2ZO 73 ... during receiving this, double clicking to another station of 
your choice, or you can let continue the automat with DE TI5/W7RI EJ79

One minute or 1.5 minute on ideal state..

Who replies with Tx2:
W7RI OK2ZO -10
OK2ZO W7RI R-03
W7RI OK2ZO RR73
DE TI5/W7RI EJ79 ... logging dialog, clicking save, quickly double clicking 
next in list or wait until Tx5 is complete and waiting for new callers.

45s or 1.25 min for QSO.

You miss Grid here, but if it's not important for you? (BTW, you get it from 
LotW when confirmed).
If sb. calls you with Tx1 like:
W7RI OK2ZO JN89
you can bet, he's got wrong call. Then you can click on Tx5 or Tx6 or just 
reply to another caller and let Tx5 go during that period. If is not an idiot? 
- return to first paragraph of this mail..

--
According my previous "question", my experience with lots of stations from 
NA/SA is bad. They prefer US wide open window against Central EU, especialy on 
upper bands. If they work EU, than here is band closed already and they work 
West EU or BigGuns only. And it's not only on FT8 of course.. In US? - EU is 
not interesting - rather ragchewing within US, right when opening to us..
Thats from my experience... I can't have some beams and towers in the town. 
Vertical on the roof is a miracle for me and luxury, the others can't have.

I'm not a big gun, but also with just a little bullet you can hit, if you know 
howto...
I thank so much to all authors of such wonderful mode, which helps me aiming 
much better..

73s.

Libor

PS.. I do apologise for probable errors in my English..



Odesláno ze zařízení Samsung


 Původní zpráva 
Od: Scott Bidstrup <sc...@bidstrup.com<mailto:sc...@bidstrup.com>>
Datum: 04.12.17 21:52 (GMT+01:00)
Komu: wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
Předmět: Re: [wsjt-devel] Another Compound Callsign Problem

On 04/12/2017 12:57 p.m., Libor Holous OK2ZO wrote:
> Experienced users will quickly know, you are from Costa Rica.. Just send
> time to time CQ and standard 73 message with full call..

Libor, I understand what you are saying, but the reality is that a lot
of fellows in the States, when they sit down for a session, will simply
glance at the band activity window and not connect up my abbreviated
call and my full callsign, because it may not appear on their list of
decodes.  If my full callsign, from a CQ or 73 message doesn't appear in
the band activity window, they will not appreciate that I am a DX station.

I do, in fact, call CQ frequently - mostly so my full callsign gets out
there, and also because it makes starting an autosequence more sure.
But when I'm working a pileup, as I am most of the time, I can go for
quite a few QSOs - ten or fifteen minutes - with the software never
sending a CQ, but simply replying to the first decode that pops up after
my last 73 message, and Call 1st then sends to the standard messages.
When that happens, I do not send a complete callsign at all until the
next 73 message, (and technically, that's not legal under the rules here
- we are supposed to transmit the full, unabbreviated call signs of ours
and the other station's call, during the first and last transmissions in
a QSO and "frequently" in between). And it also means my full callsign
is transmitted far less frequently, as it appears only in the 73
messages I send.  If the ot

Re: [wsjt-devel] DXPedition System Clock Sync

[David Tiller]

David wrote:

"A knob could adjust WSJT-X’s notion of the time of day to “zero beat” the DX 
station, both in RX and TX so you can communicate, regardless of how far off 
the DX station’s clock may be."

There's no need for anything as programmatically complex or real estate hogging 
as a knob - a simple checkbox either on the config page (to set the time track 
option for all stations attempted) or next to the call sign box (to enable time 
track for the current station only) would enable the program to use the DX 
station's delta-T as your adjusted time value. 

Again, all of these solutions presuppose that an internal delta-T value is used 
for framing timing as opposed to the actual wall clock time. 

> On Nov 12, 2017, at 16:17, David Fisher  wrote:
> 
> As I see it WSJT-X could do the same.  A knob could adjust WSJT-X’s notion of 
> the time of day to “zero beat” the DX station, both in RX and TX so you can 
> communicate, regardless of how far off the DX station’s clock may be.
--
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] DXPedition System Clock Sync

[David Tiller]

Bill N6WS wrote:

> the purpose of FT8 and any other WSJT operating mode is to communicate. 

Of course you're correct, the purpose is to communicate, and to do that with 
any of the time-synced modes we have to have a reference. This subject, IMHO, 
is the most important usability item for the success of these modes; see my 
previous comments, below. I addressed these concerns to this list back on July 
23rd and offered up 3 solutions, none of which were warmly greeted:

--QUOTE--

"I was pondering this very subject this morning. 

Perhaps for the very tightly time-constrained modes a simple computation 
comparing the received delta-T's of all received signals could be made. If 
everyone else's clocks seem consistently wrong, maybe it's you!
An indication of that made by turning the time readout red, perhaps, or by 
having an option to allow that derived time offset to be used to correct the 
clock time. 

A bit more convoluted solution would be to have a new 'time set' mode that DSPs 
one of the WWV signals. We're dsp and radio nerds, right? :-)

A simple C/C++ ntp client could also be included either as an ancillary program 
that could be exec'd or built in to the GUI. There are some that are quite 
simple - less than 100 lines of code. They're crude, yes, but we're not looking 
for sub-mS precision here."

--END QUOTE--

The reply I received from Bill G4WJS on the list was not enthusiastic about 
needing/wanting a time sync option and in fact relegated it to the realm of the 
absurd:

> Hi David,
> 
> there are many such set up issues that could be detected but we have to set 
> the boundaries of where one application manages. I certainly think time 
> accuracy is in the operating system domain or maybe a third-party utility and 
> not the responsibility of WSJT-X. Another out of domain example might be 
> seeing all signals are weak and suggesting that an aerial may not be 
> connected or maybe even to go and purchase a bigger one! Time sync is part of 
> building a station these days and as important as transmitting a clean signal 
> or many of the other things operators are responsible for when undertaking 
> this hobby.

My direct reply was (in part, Bill's quotes from above in blue, indented):

--QUOTE--

> 
> Time sync is part of building a station these days and as important as 
> transmitting a clean signal or many of the other things operators are 
> responsible for when undertaking this hobby.

Only with the advent of the WSJT modes has good timekeeping been even remotely 
important. No other Amateur two way mode, digital or otherwise, is tied to the 
clock. 

> I certainly think time accuracy is in the operating system domain or maybe a 
> third-party utility and not the responsibility of WSJT-X.

Since WSJT depends on such accurate timekeeping, wouldn't you want your program 
to guard against such a debilitating error? The program is essentially useless 
without an accurate clock, yet it's not in its purview to make sure that an 
accurate idea of the time is known? That would be like a browser not telling 
the user that the internet is not accessible.

Consider this - frequency accuracy is in no way required by any of the WSJT 
modes - as long as you can hear a signal, you can decode it and reply to it, 
regardless of what my dial says. Why, then, is there a dedicated mode, along 
with a special frequency category to perform such exquisitely accurate 
frequency calibration?

I think you'll agree that there have been many questions asked on the lists 
that fall under the category of 'set your clock'. I'm sure you also see signals 
on the air that are horribly off in time, causing QRM, frustration, and 
probably causing new users of the program to abandon the mode/program. I posit 
that having a way to set the time accurately (or at least warn the user that 
their clock is woefully off) is much more important and actually much more 
fundamental to the proper operation of WSJT-X than frequency accuracy.

I think it would help usability (and it certainly wouldn't hurt) to have a 
startup option to check the system time against the NTP pool and use that 
offset when deciding when to tx/rx - as I said, I saw a C++ example that was < 
100 lines (see URL, below).  Since we already know the users grid square, we 
can easily map the closest regional NTP server for best accuracy. There are 
algorithms to eliminate network hop delay, and supposedly you can get very good 
accuracy 
-->https://en.wikipedia.org/wiki/Network_Time_Protocol#Clock_synchronization_algorithm


NTP Client Example: 
http://www.mydailyhacks.org/2014/11/14/get-the-ntp-time-in-c-programm-via-a-simple-socket/

--END QUOTE--

Those are my two cents. Your mileage may vary.

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | dtil...@captechconsulting.com



On Nov 11, 2017, at 7:54 PM, Bill Shell <n...@n6ws.com> wrote:

> Sc

Re: [wsjt-devel] DXPedition System Clock Sync

[David Tiller]

You wrote:


Not sure what it might take to support clock changes across various OS’s now 
using WSJT-X.

The app doesn't have to actually set the clock. If the app were modified to 
keep track of a delta time value and use that for timing decisions, the actual 
clock state is irrelevant.

The delta could be set by any of the aforementioned techniques.

On Nov 11, 2017, at 11:37, George J Molnar 
> wrote:

Sounds like a perfect idea for a stand-alone application.

Not sure what it might take to support clock changes across various OS’s now 
using WSJT-X.



George J Molnar
KF2T, Nevada, USA







On Nov 11, 2017, at 8:32 AM, Ria Jairam 
> wrote:

That is an excellent idea.

A clock sync feature using WWV, WWVB, JJY, YVTO, CHU, DCF etc would
help those who don't have the ability to sync clock over the Internet.

73
Ria, N2RJ

On Sat, Nov 11, 2017 at 11:23 AM, Scott Bidstrup 
> wrote:
On 11/11/2017 09:26 a.m., Bill Shell N6WS wrote:

Hello,

While using FT8 in a DXPedition setting, there may be conditions where
there is no reliable timing source for syncing of the system clock.


Bill,

When my Internet here in Costa Rica has been down, I've been able to sync my
system clock adequately closely by using WWV and using the Windows clock set
feature to set the clock, by simply setting to the next minute and then
clicking the Apply button as the time comes around to zero seconds.  After
doing it a few times, you can nearly always get the hang of it and get it
within a second or so.  Close enough that I've gotten by.  It's a nuisance
and takes a bit of practice, but it can be done in a pinch.  And it's gotten
me back on the air many times.

Per your request, though, I envision a clock set feature whereby you would
set the receiver to zero-beat WWV, and call a special clock set routine that
would look for the top-of-the-minute tone at the right audio frequency and
at approximately the top of the minute.  When it sees the tone appear at the
right frequency, and at about the right time, it sets the system clock
accordingly.  In my professional work, before the advent of the Internet, I
used hardware clocks based on such a system, and they seem to have worked
reasonably well most (though not all) of the time.

That would only work, however, in parts of the world where WWV is available.
When I lived in Africa many years ago, however, WWV was rarely audible, but
there was a different time signal that I could hear, a digital signal of
some sort, and I have no idea where it originated from (EU maybe?) or what
the protocol was.  Something that uses that or other protocols might be
useful in those regions.

Scott Bidstrup
TI3/W7RI



--
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

--
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

--
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
--
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] DXPedition System Clock Sync

[David Tiller]

I actually started writing a gnu radio block to do WWV time decoding with the 
goal of adding a new mode to wsjtx, and had a little success. I'm not 
experienced enough in DSP to make it perfect. I did get decodable bits, however.

If any DSP experts would be willing to give me some pointers, I'll start 
working on it again.

On Nov 11, 2017, at 11:37, George J Molnar 
> wrote:

Sounds like a perfect idea for a stand-alone application.

Not sure what it might take to support clock changes across various OS’s now 
using WSJT-X.



George J Molnar
KF2T, Nevada, USA







On Nov 11, 2017, at 8:32 AM, Ria Jairam 
> wrote:

That is an excellent idea.

A clock sync feature using WWV, WWVB, JJY, YVTO, CHU, DCF etc would
help those who don't have the ability to sync clock over the Internet.

73
Ria, N2RJ

On Sat, Nov 11, 2017 at 11:23 AM, Scott Bidstrup 
> wrote:
On 11/11/2017 09:26 a.m., Bill Shell N6WS wrote:

Hello,

While using FT8 in a DXPedition setting, there may be conditions where
there is no reliable timing source for syncing of the system clock.


Bill,

When my Internet here in Costa Rica has been down, I've been able to sync my
system clock adequately closely by using WWV and using the Windows clock set
feature to set the clock, by simply setting to the next minute and then
clicking the Apply button as the time comes around to zero seconds.  After
doing it a few times, you can nearly always get the hang of it and get it
within a second or so.  Close enough that I've gotten by.  It's a nuisance
and takes a bit of practice, but it can be done in a pinch.  And it's gotten
me back on the air many times.

Per your request, though, I envision a clock set feature whereby you would
set the receiver to zero-beat WWV, and call a special clock set routine that
would look for the top-of-the-minute tone at the right audio frequency and
at approximately the top of the minute.  When it sees the tone appear at the
right frequency, and at about the right time, it sets the system clock
accordingly.  In my professional work, before the advent of the Internet, I
used hardware clocks based on such a system, and they seem to have worked
reasonably well most (though not all) of the time.

That would only work, however, in parts of the world where WWV is available.
When I lived in Africa many years ago, however, WWV was rarely audible, but
there was a different time signal that I could hear, a digital signal of
some sort, and I have no idea where it originated from (EU maybe?) or what
the protocol was.  Something that uses that or other protocols might be
useful in those regions.

Scott Bidstrup
TI3/W7RI



--
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

--
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

--
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
--
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] False Frequency reports

[David Tiller]

Andrew,

Thanks for the clear explanation of the problem. 


As I and others have said, CAT control is not a guarantee of perfect spots. 
Changing bands at the wrong instant can still generate bad info (even 
accidentally pressing the wrong button on your rig can do that). Similarly, 
impossible/wildly inaccurate decodes do happen, and those (AFAIK) also get 
reported.

As I've said, relying on raw data to draw conclusions is not a good idea, and 
the pskreporter maps are representations of raw data. 

Here's an example of how PSKReporter could curate their data to make it more 
accurate.

Here's a link to a randomly-chosen example of a bad report from your dataset 
that you mentioned. It involves LU5VV reporting AC9NJ on 6m at 2017-10-26 
01:40:15Z at offset 496 Hz. --> 
https://drive.google.com/open?id=0B4DphHV_ItCZazNKUlI5aUN5WHc

I then searched for reports of others hearing AC9NJ on any band(s), and found 
that at least one other station heard the same report as LU5VV, except on the 
correct band (and similar offset of 508 Hz). Here's the link --> 
https://drive.google.com/open?id=0B4DphHV_ItCZNU1sdTgzQmtVUkU

When conflicting reports are received (note that they'd all be received in the 
same transmission 'slot'), the singleton report should be discarded. If there 
are many reports that conflict, throw them _all_ out.

Simple data cleansing by pskreporter would yield better information for _all_ 
of the users, including those that may later access the historical database - 
it's better that bad spots never get into the database in the first place, 
regardless of their source. 
--

David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | dtil...@captechconsulting.com



On Oct 26, 2017, at 6:52 PM, Andrew Martin <vk...@bigpond.com> wrote:

> Hi,
> 
> To illustrate exactly what the problem is have a look at PSK reporter for
> the last 24 hours, use 6m, LU5VV FT8 and 24 hours. 
> 
> This type of false reporting makes the 6M usage difficult because of the
> rare propagation on 6m of long distance contacts. It only takes one set of
> false reports like the above to make PSK reporter almost useless for 6M long
> distance propagation surveilence.
> 
> Maybe false reports do not matter so much for lower frequencies as there are
> so many reports.
> 
> All I was asking was for a click box to the right of the frequency box to
> ckick when the CAT is not connected to confirm the frequency.
> 
> Andrew
> VK3OE.
> 
> -Original Message-
> From: David Tiller [mailto:dtil...@captechconsulting.com] 
> Sent: Friday, 27 October 2017 09:21
> To: WSJT software development <wsjt-devel@lists.sourceforge.net>
> Subject: Re: [wsjt-devel] False Frequency reports
> 
> 
>> In passing one might note that CAT control is not a panacea against bad
> reports.
> 
> Exactly! The data is never going to be perfect - there are enough intrinsic
> bad decodes even on the correct freq that get reported up. 
> 
> As any careful data consumer knows, you must clean and curate any dataset
> you use. That includes weeding out spots that appear once on band A but are
> matched by multiple simultaneous  spots on band B.
> 
>> On Oct 26, 2017, at 17:52, G8DQX (WSJT developers on SF)
> <wsjtde...@gape.me.uk> wrote:
>> 
>> In passing one might note that CAT control is not a panacea against bad
> reports.
> 
> 
> --
> 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
> 
> 
> --
> 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


--
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] False Frequency reports

[David Tiller]

> In passing one might note that CAT control is not a panacea against bad 
> reports.

Exactly! The data is never going to be perfect - there are enough intrinsic bad 
decodes even on the correct freq that get reported up. 

As any careful data consumer knows, you must clean and curate any dataset you 
use. That includes weeding out spots that appear once on band A but are matched 
by multiple simultaneous  spots on band B.

> On Oct 26, 2017, at 17:52, G8DQX (WSJT developers on SF) 
>  wrote:
> 
> In passing one might note that CAT control is not a panacea against bad 
> reports.

--
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] False Frequency reports

[David Tiller]

> IMHO the errors cause more of a problem ...


What exact "problem" does a small number of inaccurate spots create? By your 
own data, the number of non-CAT users is small, hence the number of inaccurate 
spots is proportionally small - who is harmed by a small number of inaccurate 
data points? We're not doing a drug trial here.


David Tiller | Senior Manager
dtil...@captechconsulting.com
c 804.304.0638 / o 804.355.0511

[http://www.captechconsulting.com/siggen/logo.png]<http://www.captechconsulting.com/>

[http://www.captechconsulting.com/siggen/Dkblue_Facebook.png]<http://www.facebook.com/CapTechCareers>
 [http://www.captechconsulting.com/siggen/Dkblue_Twitter.png] 
<http://www.twitter.com/CapTechListens>  
[http://www.captechconsulting.com/siggen/Dkblue_LinkedIn.png] 
<http://www.linkedin.com/company/captech-ventures>  
[http://www.captechconsulting.com/siggen/Dkblue_StackOverflow.png] 
<http://www.stackoverflow.com/jobs/companies/captech-consulting>  
[http://www.captechconsulting.com/siggen/Dkblue_YouTube.png] 
<http://www.youtube.com/user/CapTechConsulting>  
[http://www.captechconsulting.com/siggen/Dkblue_Instagram.png] 
<https://www.instagram.com/lifeatcaptech/>
Best Firms 2016 #2 in Information Technology



From: David Tiller <dtil...@captechconsulting.com>
Sent: Thursday, October 26, 2017 12:54 PM
To: Black Michael; WSJT software development
Subject: Re: [wsjt-devel] False Frequency reports


Do you really want to preclude those of us that choose to not use CAT control 
from reporting spots? That seems like a bit of an extreme solution for such a 
small problem.


I would think the benefit of having more spots would help the whole community 
more than the harm done by a few misplaced spots.


It seems to me the data collector should be curating the spots in the first 
place, only accepting those that are reported by more than 1 station. That's a 
real solution that doesn't alienate a good bit of the ham population.


--

David Tiller | Senior Manager
dtil...@captechconsulting.com
c 804.304.0638 / o 804.355.0511

[http://www.captechconsulting.com/siggen/logo.png]<http://www.captechconsulting.com/>

[http://www.captechconsulting.com/siggen/Dkblue_Facebook.png]<http://www.facebook.com/CapTechCareers>
 [http://www.captechconsulting.com/siggen/Dkblue_Twitter.png] 
<http://www.twitter.com/CapTechListens>  
[http://www.captechconsulting.com/siggen/Dkblue_LinkedIn.png] 
<http://www.linkedin.com/company/captech-ventures>  
[http://www.captechconsulting.com/siggen/Dkblue_StackOverflow.png] 
<http://www.stackoverflow.com/jobs/companies/captech-consulting>  
[http://www.captechconsulting.com/siggen/Dkblue_YouTube.png] 
<http://www.youtube.com/user/CapTechConsulting>  
[http://www.captechconsulting.com/siggen/Dkblue_Instagram.png] 
<https://www.instagram.com/lifeatcaptech/>
Best Firms 2016 #2 in Information Technology



From: Black Michael via wsjt-devel <wsjt-devel@lists.sourceforge.net>
Sent: Thursday, October 26, 2017 12:46 PM
To: WSJT software development
Cc: Black Michael
Subject: Re: [wsjt-devel] False Frequency reports

Here's a one-liner that should prevent psk reports if the rig is "None".

https://www.dropbox.com/s/zb920h4s0puibyn/oktopost.patch?dl=1


de Mike W9MDB


On Thursday, October 26, 2017, 3:32:44 AM CDT, Hasan al-Basri 
<hbasri.schie...@gmail.com> wrote:


If that was fixed, I missed it! It would be wonderful if that's the case. I'll 
have to watch for it. Tnx tip

73, N0AN

Hasan

On Wed, Oct 25, 2017 at 9:17 PM, Gary McDuffie 
<mcduf...@ag0n.net<mailto:mcduf...@ag0n.net>> wrote:


> On Oct 25, 2017, at 7:51 PM, Hasan al-Basri 
> <hbasri.schie...@gmail.com<mailto:hbasri.schie...@gmail.com>> wrote:
>
> A radio connection does not prevent false reports from being sent to pskr. If 
> one switches frequencies at just the right time, the report will be wrong, 
> even if cat control is being used.

I thought that was corrected in an earlier version.  Reports stop for a brief 
time after changing frequencies???

I still think disabling pskreporter reports being sent when not using working 
CAT is a simple fix.

Gary - AG0N
-- -- --
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
__ _
wsjt-devel mailing list
wsjt-devel@lists.sourceforge. net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/ 
lists/listinfo/wsjt-devel<https://lists.sourceforge.net/lists/listinfo/wsjt-devel>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slas

Re: [wsjt-devel] False Frequency reports

[David Tiller]

Do you really want to preclude those of us that choose to not use CAT control 
from reporting spots? That seems like a bit of an extreme solution for such a 
small problem.


I would think the benefit of having more spots would help the whole community 
more than the harm done by a few misplaced spots.


It seems to me the data collector should be curating the spots in the first 
place, only accepting those that are reported by more than 1 station. That's a 
real solution that doesn't alienate a good bit of the ham population.


--

David Tiller | Senior Manager
dtil...@captechconsulting.com
c 804.304.0638 / o 804.355.0511

[http://www.captechconsulting.com/siggen/logo.png]<http://www.captechconsulting.com/>

[http://www.captechconsulting.com/siggen/Dkblue_Facebook.png]<http://www.facebook.com/CapTechCareers>
 [http://www.captechconsulting.com/siggen/Dkblue_Twitter.png] 
<http://www.twitter.com/CapTechListens>  
[http://www.captechconsulting.com/siggen/Dkblue_LinkedIn.png] 
<http://www.linkedin.com/company/captech-ventures>  
[http://www.captechconsulting.com/siggen/Dkblue_StackOverflow.png] 
<http://www.stackoverflow.com/jobs/companies/captech-consulting>  
[http://www.captechconsulting.com/siggen/Dkblue_YouTube.png] 
<http://www.youtube.com/user/CapTechConsulting>  
[http://www.captechconsulting.com/siggen/Dkblue_Instagram.png] 
<https://www.instagram.com/lifeatcaptech/>
Best Firms 2016 #2 in Information Technology



From: Black Michael via wsjt-devel <wsjt-devel@lists.sourceforge.net>
Sent: Thursday, October 26, 2017 12:46 PM
To: WSJT software development
Cc: Black Michael
Subject: Re: [wsjt-devel] False Frequency reports

Here's a one-liner that should prevent psk reports if the rig is "None".

https://www.dropbox.com/s/zb920h4s0puibyn/oktopost.patch?dl=1


de Mike W9MDB


On Thursday, October 26, 2017, 3:32:44 AM CDT, Hasan al-Basri 
<hbasri.schie...@gmail.com> wrote:


If that was fixed, I missed it! It would be wonderful if that's the case. I'll 
have to watch for it. Tnx tip

73, N0AN

Hasan

On Wed, Oct 25, 2017 at 9:17 PM, Gary McDuffie 
<mcduf...@ag0n.net<mailto:mcduf...@ag0n.net>> wrote:


> On Oct 25, 2017, at 7:51 PM, Hasan al-Basri 
> <hbasri.schie...@gmail.com<mailto:hbasri.schie...@gmail.com>> wrote:
>
> A radio connection does not prevent false reports from being sent to pskr. If 
> one switches frequencies at just the right time, the report will be wrong, 
> even if cat control is being used.

I thought that was corrected in an earlier version.  Reports stop for a brief 
time after changing frequencies???

I still think disabling pskreporter reports being sent when not using working 
CAT is a simple fix.

Gary - AG0N
-- -- --
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
__ _
wsjt-devel mailing list
wsjt-devel@lists.sourceforge. net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/ 
lists/listinfo/wsjt-devel<https://lists.sourceforge.net/lists/listinfo/wsjt-devel>

--
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<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X Version 1.8.0, Release Candidate 3

[David Tiller]

Joe and other devs,

I just got this crash from RC3 running under MacOS 10.9.5. 

The crash report is here (text file): 
https://drive.google.com/file/d/0B4DphHV_ItCZcFBCWXRNaDBJZ1U

I had been running MSK144 for a few hours on 6m and switched to FT8. The crash 
happened a few seconds after the switch, perhaps at the first decode cycle.

I thought you might like to know.

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | dtil...@captechconsulting.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Experimental changes in r8146

[David Tiller]

Re David Fisher's suggestion - we've all been concentrating on double clicking 
and leaving our friend the single click out of the conversation.

Usual behavior for clicking is for a single click to do X, and double clicking 
do X plus some related function Y.

Perhaps single clicking could set the call,grid,and rx freq but not the tx freq 
or enable tx. Double clicking could do the above plus set the tx freq and 
enable tx as is the current double click behavior.

This is consistent with expected single/double click behavior and adds a 
'pounce' feature that I think would be a good addition.

On Oct 1, 2017, at 20:08, David Fisher 
> wrote:


Hello everyone



You guys haven’t heard from me before – I’m David Fisher, NX6D.  I’ve been 
watching this reflector for a couple of weeks, building and testing the program 
as the versions roll out.  I have hundreds of FT8 QSOs in my log and am close 
to a multi-band WAS in FT8.  I’m also an “alpha tester” for Flex Radio and 
volunteer in other capacities with them.



I’d like to suggest that WSJT-X find a way to deal with the following scenario:



Monitoring a band, with JTAlertX running, I see a station in a QSO with another 
station.  JTAlertX flags it for me because it is located in a state I want for 
WAS.  Frequently the station I want to contact is replying to a third station’s 
CQ.  I’d like to double click the station in the left (or right) window and 
have WSJT-X set the Call, Grid (if available), and RX frequency, but not set TX 
Enable.  This will get me set up to contact the station while monitoring the 
QSO without adding QRM to it by having my transmitter pop up, even for a 
moment.  It would allow me to scroll the left window back, find the station, 
select it without being concerned if it is transmitting or receiving at the 
moment I double click it.



Experimenting with R8150, I see that if I set my TX frequency to something, and 
set the TX Hold option, then it doesn’t move when I double click the station I 
want.  That’s part of what I’d like to have.  I’ll have plenty of time to 
position it to some location so that I can start my contact with the desired 
station as a split operation.



The real issue is the TX Enable.  I’d like to avoid having it set on the double 
click so I can pick the right time in the other QSO to send my message, on a 
split frequency.



Thanks for listening and 73



Dave Fisher / NX6D




From: Joe Taylor >
Sent: Saturday, September 30, 2017 11:00:33 AM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Experimental changes in r8146

Hi all,

Changes in program behavior can be confusing, so I apologize for some
recent instability in GUI operational behavior.  Code revision r8146 is
yet another attempt to get it right -- or as near "right" as possible --
while supporting both simplex and split-frequency default operating styles.

The following is the commit message for r8146:

##
Another try at optimizing the GUI for simplex and split behavior.
Details below:

1. Checkbox "Double-click on call sets Tx and Rx freqs" has been removed
from the Settings -> General tab.

2. Checkbox "Lock Tx Freq" on main window is relabled "Hold Tx Freq".

3. Behavior now defaults to the "simplex" behavior in use up to code
revision r8123.  In particular, double-clicking on decoded mesages
that do not contain your own call moves both Rx and Tx frequencies.
If the first callsign is your own call, only Rx freq moves.

4. If "Hold Tx Freq" is checked, double-clicking on decoded messages
moves the Rx frequency; Tx frequency is moved only if CTRL was held
down.

5. Clicking on the waterfall moves Rx and Tx frequencies as before:
Rx only on a simple click, Tx only on SHIFT-click, and both on
CTRL-click.  This happens even if "Hold Tx Freq" is checked (which
is why this box is no longer labeled "Lock Tx Freq").
##

If I have not made mistakes, this arrangement should provide full
backward compatibility and also easy assertion of a mode that keeps your
Tx frequency fixed until you explicitly change it.

If you can build r8146 for yourself and try it on the air, please post
your comments here.

-- 73, Joe, K1JT

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
Check out 

Re: [wsjt-devel] UDP Port

[David Tiller]

Steve,

Since WSJT-X uses UDP, there is a chance that you can get more than 1 listener 
to receive all UDP packets. According to this article, if all clients bind to 
the port using SO_REUSEPORT (and possibly SO_REUSEADDR), all listeners will 
receive all datagrams. You may have to convince the author of JTAlert to also 
make this change if it's not already set.

https://stackoverflow.com/questions/4364434/let-two-udp-servers-listen-on-the-same-port

Alternatively, you could write a simple listener that repeats all packets heard 
on several ports.

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Sep 10, 2017, at 7:11 PM, Steve Nance 
<sna...@charter.net<mailto:sna...@charter.net>> wrote:

Is there any way without hacking the code to enable a second UDP port? I'm 
writing a little C# windows app and need to read the UDP messages, but still 
want to keep JTAlert running.

73, Steve K5FR


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://slashdot.org/>! 
http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
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] 15 vs 30 sec Fast Graph header

[David Tiller]

Rich,


I reported the same issue on July 9th here: 
https://sourceforge.net/p/wsjt/mailman/message/35935125/


I followed up with more info a day later (since there was a flurry of other 
bugs being reported):  https://sourceforge.net/p/wsjt/mailman/message/35938038/


Between us there should be enough info to narrow the issue down.



From: Rich - K1HTV 
Sent: Friday, August 11, 2017 11:13 AM
To: WSJT
Subject: [wsjt-devel] 15 vs 30 sec Fast Graph header


While running MSK144 with 15 second sequencing for Perseids meteor scatter 
operation this morning, I noticed that instead of the Fast Graph header reading 
0-15 it reads 0-30 seconds. Would it be possible for the time header to change 
based on the length of the chosen 15 or 30 second sequence?


73,

Rich - K1HTV


PS - The Perseids meteors were flying this morning. Looks like a good shower 
this year with the peak coming within the next 24 hours.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Devel Build 7934 - Problems decoding

[David Tiller]

I was pondering this very subject this morning.

Perhaps for the very tightly time-constrained modes a simple computation 
comparing the received delta-T's of all received signals could be made. If 
everyone else's clocks seem consistently wrong, maybe it's you!
An indication of that made by turning the time readout red, perhaps, or by 
having an option to allow that derived time offset to be used to correct the 
clock time.

A bit more convoluted solution would be to have a new 'time set' mode that DSPs 
one of the WWV signals. We're dsp and radio nerds, right? :-)

A simple C/C++ ntp client could also be included either as an ancillary program 
that could be exec'd or built in to the GUI. There are some that are quite 
simple - less than 100 lines of code. They're crude, yes, but we're not looking 
for sub-mS precision here.

On Jul 23, 2017, at 06:06, Bill Somerville 
> wrote:

On 23/07/2017 07:48, Mark Turner via wsjt-devel wrote:
± 1.5s shouldn't present a problem to anyone, even, just about, for people 
(e.g. some dxp) that rely on crude GPS NMEA serial data time synchronisation.

In the (unlikely?) event that an even shorter DT window is ever considered, I'd 
like to request that a small range of DT adjustment be made available - 
similar, but perhaps of a smaller magnitude/finer resolution, to JT65's Dsec 
setting in WSJT10 (not available in WSJT-X?). Other than using NMEA data, 
another scenario where *really* tight timing requirements will cause a problem 
is in the use of remote radios where the client software is running at the 
remote, not the radio end; obviously there's an inherent, known, and fixed 
delay in such a system that can be of the order of 100's of ms.

Regards, Mark

Hi Mark,

all understood. It is clear that FT8 with 15s T/R periods and very short 
inter-message gaps has reached the limit of both human response time and 
reduced sensitivity that would be acceptable for weak signal amateur radio 
operation. I suspect that tighter time synchronization requirements will not be 
expected. Everything works against the human speed operator as the limits of 
timing are approached, clearly the computer can do much better if it only has 
mundane algorithmic work to do but at some point this has to be about the human 
getting enjoyment from a hobby!

Achieving +/- 1.5 second clock accuracy is possible with simple aural 
comparison and manual update from an on-air time source if necessary. The real 
problem is the appalling time inaccuracy of PC systems unless they are helped 
by on line time servers, even worse because Microsoft fell that a time update 
is only necessary once per few days.

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
--
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] A non-technical reason to remove/relocate the audio slider

[David Tiller]

Michael,

It doesn't have to remain a gigantic slider - it could be a simple dB spinbox 
like the other controls on the graph window. That would actually free up space 
on the main window where all the real fun happens.
--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Jul 19, 2017, at 4:30 PM, Black Michael via wsjt-devel 
<wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:

I agree the placement is misleading...but there really isn't a better place to 
put it without some judicious rearranging.
Would need to figure out what to do with the CAT indicator for example.
Or maybe sticking it under the Date/Time might work.
Just not a lot of room to work with.

de Mike W9MDB




From: "Laurie, VK3AMA" <_vk3a...@vkdxer.net<mailto:vk3a...@vkdxer.net>>
To: WSJT software development 
<wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>>
Sent: Wednesday, July 19, 2017 3:22 PM
Subject: [wsjt-devel] A non-technical reason to remove/relocate the audio slider

Having the slider immediately adjacent to the level indicator,
regardless of its true function, implies to an uneducated user (hasn't
read the manual or understood group postings) that the two are
associated. It is how most GUIs are presented.

A problem I see all too often, is some users experiencing difficulties
or think there is a defect with their software will post their
questions/findings to non-related Internet forums, QRZ and eHam are the
big ones, looking for answers and support. They don't post to the
correct support group/forum. I see this often with WSJT-X, JTAlert and
JTDX. The usual result is an incorrect or incomplete answer from a user
based on their experience or the perception of how the software works,
often wrong. It is not uncommon to see a long running thread of
exchanges between users exchanging (and reinforcing) the misinformation.
Unless someone comes along and corrects the record, this misinformation
tends to be propagated through Internet searches and word-of-mouth.

None of us like our software being incorrectly maligned due to
misinformation.

IMHO, leaving the slider adjacent to the level meter will lead to an
ongoing public perception among some users that the software is broken.
Especially after a General Release (look at the numerous threads posted
since the 1.8.0-rc1 was posted, people don't read or research old
messages). New users encountering these uncorrected public defect
reports via an Internet search will likely perceive there is a problem
with the software.

That's my 2cents.

de Laurie VK3AMA



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! 
http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
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] Ver 1.8 RC1 audio in slider problem

[David Tiller]

Using flatten for me results in a very angry red and yellow mess. I run my 
input signal fairly hot, though. Around 60dB or so. It seems that flatten can't 
handle high input levels.


David Tiller | Senior Manager
dtil...@captechconsulting.com
c 804.304.0638 / o 804.355.0511

[http://www.captechconsulting.com/siggen/logo.png]<http://www.captechconsulting.com/>

[http://www.captechconsulting.com/siggen/Dkblue_Facebook.png]<http://www.facebook.com/CapTechCareers>
 [http://www.captechconsulting.com/siggen/Dkblue_Twitter.png] 
<http://www.twitter.com/CapTechListens>  
[http://www.captechconsulting.com/siggen/Dkblue_LinkedIn.png] 
<http://www.linkedin.com/company/captech-ventures>  
[http://www.captechconsulting.com/siggen/Dkblue_StackOverflow.png] 
<http://www.stackoverflow.com/jobs/companies/captech-consulting>  
[http://www.captechconsulting.com/siggen/Dkblue_YouTube.png] 
<http://www.youtube.com/user/CapTechConsulting>  
[http://www.captechconsulting.com/siggen/Dkblue_Instagram.png] 
<https://www.instagram.com/lifeatcaptech/>
Best Firms 2016 #2 in Information Technology



From: Black Michael via wsjt-devel <wsjt-devel@lists.sourceforge.net>
Sent: Wednesday, July 19, 2017 11:20 AM
To: WSJT software development
Cc: Black Michael
Subject: Re: [wsjt-devel] Ver 1.8 RC1 audio in slider problem

The "Flatten" option on the waterfall solves that problem too.
But not for the fast graph.
Are you using the fast graph or is there some reason not to use Flatten for you?

de Mike W9MDB



From: George J Molnar <geo...@molnar.com>
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Sent: Wednesday, July 19, 2017 10:15 AM
Subject: Re: [wsjt-devel] Ver 1.8 RC1 audio in slider problem

Vote for retention of the slider. Switching bands often calls for readjusting 
the waterfall, and the slider is a convenient, easy to understand tool.

I wouldn't mind moving it away from the thermometer, to clarify the proper 
function. It isn't really difficult to grasp, though!

George J Molnar, KF2T
Nevada, USA


On Jul 19, 2017, at 8:49 AM, Dan Malcolm 
<dan.malcol...@gmail.com<mailto:dan.malcol...@gmail.com>> wrote:

Mike, Bill,
FWIW I’d like to keep the slider.  I like the idea of encouraging users to read 
the manual.

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
Sent: Tuesday, July 18, 2017 10:37 PM
To: WSJT software development 
<wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>>
Cc: Black Michael <mdblac...@yahoo.com<mailto:mdblac...@yahoo.com>>
Subject: Re: [wsjt-devel] Ver 1.8 RC1 audio in slider problem

There were those that still wanted the waterfall adjustment for the fast graph 
handy so leaving it as an option would be the only solution.

I submitted some tooltip changes a while ago to make it pretty much 
in-your-face on the meter tooltip.
Then we need to spice up the documentation so be more in-your-face too.  
"Transceiver setup" as an index title is not intuitive but hopefully most know 
how to use search for keywords.  I tried to see if you could put a hyperlink in 
a tool tip but appears not.  Though about doing a ctrl-click on the meter or 
such to bring up the relevant section in the manual then put the ctrl-click 
info in the tooltip.

de Mike W9MDB


From: Bill Somerville <g4...@classdesign.com<mailto:g4...@classdesign.com>>
To: wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
Sent: Tuesday, July 18, 2017 5:54 PM
Subject: Re: [wsjt-devel] Ver 1.8 RC1 audio in slider problem

On 18/07/2017 23:32, Black Michael via wsjt-devel wrote:
I'd say the vast majority have no use for the slider anymore.
So let's hide it by default and have an enable checkbox in the config.

I'll do that patch if you think that's acceptable...we'll still end up with 
"what happened to..." but se la vie...
Hi Mike,
if you are going to do a patch then remove the slider altogether, that is 
probably the best option. It is of limited value and will always be 
misunderstood by many who don't understand the underlying realities of digital 
samples. Unfortunately the result may well be that those who miss the slider 
will revert to using the operating system sliders which are effectively the 
same thing and equally pointless (even harmful at extreme settings) as the 
WSJT-X slider.

73
Bill
G4WJS.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://slashdot.org/>! 
http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinf

Re: [wsjt-devel] FT8 for the visually impaired

[David Tiller]

Rich,

It might be better for your visually-impaired friend to have someone develop a 
'sister app' that interfaces with WSJT-X via the existing UDP interface. That 
way any existing visual aides could be leveraged without having to add support 
in the base application.

Just a thought.

On Jul 14, 2017, at 19:58, Rich - K1HTV 
> wrote:


Joe and the WSJT-X software development team,

   First, congrats on the superb job you all have done in the creation of the 
new FT8 mode. It works great! In 5 days, while running 50 Watts, a triband yagi 
and wire antenna, I've managed to  work 62 countries using FT8,  including some 
nice catches such as Bahrain, Iraq, Armenia, Japan, Gabon on 20M  and multiple 
VK's on 20M & 40M . I wish that 6 Meter propagation to DX lands would improve 
so we can exercise the mode under multi-hop conditions on the Magic Band.


Its been fun, but, the main reason for this note is a request for you all to 
consider.


One of my fellow DXer friends, with 355 countries confirmed and on the DXCC 
Honor Roll, is interested in using the new FT8 mode but is visually impaired. I 
wonder if there might be a way to make FT8 available to him and other blind 
Radio operators?


Some additional features would need to be incorporated, such as:

- Shortcut keys for various required functions (TX Enable, TX disable, TX6-CQ, 
Monitor ON, etc.)

- If voice output of alpha numeric WAV files is not possible, maybe an ASCII 
output stream could be fed to a second COM port to feed an external 
text-to-voice reader.

- UP/Down function keys to control pointing to lines in the "Band Activity" 
window to be voiced.

- A key to select a chosen line which would then populate the message box and 
activate TX Enable.

- Voice the characters of the line being transmitted so the blind op would know 
the progress of the QSO.

- Although an ALT-Q will manually log a QSO, it would be helpful is there was 
an automatic logging of a completed QSO data into an ADIF file for easy 
uploading to LOTW.


I know that it is important to get solid WSJT-X code for release. But,  once 
this has been done, it would be
great if the WSJT-X team could make the necessary additions so visually 
impaired Hams could use the new FT8 mode.


Thanks in advance for your consideration of this request to help our fellow 
blind Radio Amateurs join in the fun of this new digital mode.


73,
Rich - K1HTV

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
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] Possible bug in 7818 thru 7844

[David Tiller]

At least for me, using r7844 under macOS 10.9, my IARU region starts put at 
'Region 2' between app restarts. I do not use configurations, however.

[cid:2D5CB16F-AFBC-419E-83CE-85DF8080DE8A]

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Jul 10, 2017, at 8:57 PM, Gary McDuffie 
<mcduf...@ag0n.net<mailto:mcduf...@ag0n.net>> wrote:


On Jul 10, 2017, at 6:53 PM, Gary McDuffie 
<mcduf...@ag0n.net<mailto:mcduf...@ag0n.net>> wrote:

It isn’t that I can’t see it, Bill.  It’s that it I change it to region 2, 
close the program or change configurations, then come back to the one I 
changed, and it is back at ALL again.  My change isn’t sticking.

Sorry Bill.  I misread your response.  New computer has pretty small screen and 
I thought you said you couldn’t SEE the IARU setting.  Ignore my bad eyes.  :(

Gary- AG0N
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
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] Possible bug in 7818 thru 7844

[David Tiller]

Dear dev team,

FYI, this bug still exists in r7844, and happens any time you switch into 
MSK144 mode from FT8, JT4, JT9, JT9+JT65, JT65, or QRA64. ISCAT and WSPR seem 
ok. It sounds like the 'over' time isn't getting initialized when entering 
MSK144 mode.

Screenshots here: https://drive.google.com/open?id=0B4DphHV_ItCZWUlWdmtpdUtkWlU

Thanks!

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Jul 8, 2017, at 8:51 PM, David Tiller 
<dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>> wrote:

Dear dev team,

Given this sequence of events in 7818:

1) Put WSJT-X in MSK144 mode with 15 second 'overs'
2) switch to JT65+JT9 mode
3) Shut down WSJT-X with JT65+JT9 as the mode in use
4) Start WSJT-X - all appears normal.
5) Switch to MSK144.

I see the following behaviors:

A) It switches to the fast graph but still shows a 30 sec wide graph
B) It continues to execute 30 second transmission/reception 'overs' even though 
the MSK144 time control shows 15 sec
C) If you change the MSK144 time away from 15 sec (either up or down) and back 
to 15, it corrects the graph and starts doing 15 second overs as expected.

If the attached pictures get chopped off, you can view them here: 
https://drive.google.com/open?id=0B4DphHV_ItCZWUlWdmtpdUtkWlU

After switching to MSK144 from JT65+JT9 - note that the graph is 30 secs wide 
and the transmissions are 30 secs even though the time control is set at 15 
secs. (Pic inline or Screenshot 1.png at the above URL)






After changing 'over' time away from and back to 15 secs (Pic inline or 
Screenshot 2.png at the above URL)






Thanks, guys!

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! 
http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
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] Little request - 1.7.1 gain slider

[David Tiller]

I second this - I run my soundcard digital input gain on 0dB, and have adjusted 
the _analog_ pot on my adapter to satisfy all my other programs. WSJT-X sees 
about 63dB all the time, but it decodes well.


--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Jul 8, 2017, at 11:43 AM, Black Michael via wsjt-devel 
<wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:

I think you'll find you can set your audio level to give 50-60dB on the WSJT-X 
meter and other software will work just fine and you'll never have to adjust 
audio.
WSJT-X wants 30dB minimum but higher values work just fine in the vast majority 
of cases.
Not that the meter value is about 10dB below peak values so 50dB actually gives 
you about 30dB of head room and not 40dB as one would suspect.

And messing with the mic levels is doing the wrong thing...you want 0dB on that 
regardless of what software you are running.

de Mike W9MDB



From: James Shaver (N2ADV) <n2...@windstream.net<mailto:n2...@windstream.net>>
To: WSJT software development 
<wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>>
Sent: Saturday, July 8, 2017 10:39 AM
Subject: Re: [wsjt-devel] Little request - 1.7.1 gain slider

If that slider could be mapped to act like a mic volume control to adjust the 
incoming audio up or down similar to the "pwr" slider on the opposite side 
adjusts the outgoing audio volume that would do the trick

73 and thanks for responding!

Jim S.
N2ADV

> On Jul 8, 2017, at 11:20 AM, Bill Somerville 
> <g4...@classdesign.com<mailto:g4...@classdesign.com>> wrote:
>
>> On 08/07/2017 16:16, James Shaver (N2ADV) wrote:
>> I know that the digital gain slider functionality was deliberately updated 
>> but rather than changing it or removing it, can it just become an actual 
>> audio input adjustment rather than digital gain?
>
> Hi Jim,
>
> how do you propose that to be implemented?
>
> 73
> Bill
> G4WJS.
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org<http://Slashdot.org>! 
> http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! 
http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8: IMPORTANT NOTICE

[David Tiller]

Joe and the dev team,

Excellent work! The new-and-improved FT8 is working well. I'm using 7812 on a 
Mac.

One thing I'm seeing, however: I'm getting double decodes when I'm in a QSO. 
For instance:

[cid:25421FA7-3F32-40AC-9BD3-18D564FDDAC7]

Is it just me?

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Jul 7, 2017, at 7:53 PM, Joe Taylor 
<j...@princeton.edu<mailto:j...@princeton.edu>> wrote:

To:  Users of FT8
From:WSJT Development Team
Subject: IMPORTANT NOTICE ABOUT FT8

If you are building WSJT-X for yourself from source code, you may now upgrade 
to r7812 and recompile. You will then have access to the latest version of FT8 
plus some new features for setting default operating frequencies by mode and 
IARU region.  The program built in this way will be called WSJT-X v1.7.1 r7812.

Note that essentially the same program will soon be packaged for wider 
distribution as as "WSJT-X Version 1.8.0-rc1" (release candidate 1), see below).

Remember that FT8 in code revisions 7812 are higher is NOT COMPATIBLE with that 
in 7782 and earlier.  To use FT8 you must upgrade to r7812.
If you see FT8 signals that do not decode, they may be using the obsolete 
protocol.

About the Default Working Frequencies
=

FT8 will likely be popular with MF and HF users as well as the VHF multi-hop 
sporadic-E DXers it was designed for.  After consultation with the user 
community, we have reworked the suggested operating frequency defaults to 
include FT8.  This was not easy on every relevant band; where possible, we have 
suggested a 2 kHz range for exclusive FT8 use. (Exclusivity is important, as 
the T/R period is 15 s which will not mix well with mode that use one-minute 
sequences.)

In general the FT8 frequencies are set 2kHz below the current JT65 allocation.  
This should allow operation using a normal SSB filter width without too much 
interference from strong JT65 signals up the band.  On some bands that has not 
been possible since JT65 sits at the lowest usable narrow band data mode 
frequency, when considering all international band plans.

For the 660 m and 2200 m  bands we have not assigned separate frequencies for 
JT65/JT9/FT8, and just expect users to coordinate themselves.  The numbers of 
active operators will probably be low enough that this will not cause issues.

For 160 m we assume that the JT65 and JT9 sub-bands can be squeezed to
1 kHz each, and FT8 can sit above using up to another 1 kHz.

Previous 80 m use of JT modes has done a disservice to JA operators, who have 
no privileges on the current WSPR/JT65/JT9 allocations.  To correct this we 
have moved the allocations to a part of the band where JAs can operate.  
Obviously this change will impact other non-WSJT-X users, so for now we suggest 
that if you intend to operate on 80 m JT65/JT9/WSPR then you manually change 
the working frequencies in WSJT-X ("Settings->Frequencies") back to the old 
allocations until a general availability release of WSJT-X v1.8.0 is published. 
This will allow time for other software teams to coordinate with us.

The old allocations are:

JT65 3.567 MHz
JT9  3.578 MHz
WSPR 3.5926 MHz

For 6 m we understand that the IARU Region 1 band plan is not to the liking of 
DX chasers around the world and largely ignored by Region 1 users.  However we 
cannot reasonably continue to set working frequency suggestions that drive 
traffic to parts of the band that are not supposed to be used for narrow band 
data modes.  The v1.8.0 release will allow Region-specific working frequencies 
as well as globally coordinated ones.  Consequently we have set the Region 1 
working frequencies roughly in line with the band plan.  If you do not like the 
allocations then do not complain to us, but complain to your Region 1 band 
coordinator along with reasons why you think it should change.  The proposed 
Region 1 working frequencies are usable globally wherever 6m data mode 
operation is permitted so we have set them as global rather than Region 1 
specific.  Region 2 and 3 operators will have both local and global frequencies 
offered.

Other changes are in line with current usage.


Finally, if you are waiting for pre-built installation packages:

We plan to post a release candidate for WSJT-X v1.8.0-rc1 configured for 
Windows, Linux, and OS X very soon -- probably early next week.  Thanks for 
your patience!

   -- 73, Joe, K1JT (for the WSJT Development Team)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
ht

Re: [wsjt-devel] FT8: CW ID not a good idea

[David Tiller]

Joe and Richard,

I see where the confusion is coming from. I meant to say that one could send 
the CW id across a whole 15 sec data 'over', NOT alongside each data packet 
burst. Sorry about the confusion.

The word "PARIS" is considered a standard CW 'word', and consists of 52 dit 
times, if my numbers are right. The speed limit for automatic ID (according to 
97.119(b)(1)) is 20 WPM, so that means the limit is approximately 52 * 20 dit 
times/minute, or 52 * 5 = 260 dit times in 15 secs. That's just short of 5 
'PARIS' words, due to the inter-word gaps. 

The longest Morse letters are J, Q, and Y - they each have 3 dahs and 1 dit, 
taking up 13 dit times each. Zero is the longest number with 27 dit times. A 
call with two digits and 4 letters can be at most 118 dit times long, which 
leaves plenty of room for a '/' and a suffix. 

At 20 WPM, as Joe said, that would create a CW id approximately 20 Hz wide. 

As Joe also said, Part 97.119(a)(4) also seems to indicate that data 
transmissions can be identified in the 'specifed code' as long as it's 
published (see 97.309(a)(4)), so there is not real need for the CW id, but it 
is nice to have since it's offered in the other modes.


97.119   Station identification.

(a) Each amateur station, except a space station or telecommand station, must 
transmit its assigned call sign on its transmitting channel at the end of each 
communication, and at least every 10 minutes during a communication, for the 
purpose of clearly making the source of the transmissions from the station 
known to those receiving the transmissions. No station may transmit 
unidentified communications or signals, or transmit as the station call sign, 
any call sign not authorized to the station.

(b) The call sign must be transmitted with an emission authorized for the 
transmitting channel in one of the following ways:

(1) By a CW emission. When keyed by an automatic device used only for 
identification, the speed must not exceed 20 words per minute;

...

(4) By an image emission conforming to the applicable transmission standards, 
either color or monochrome, of §73.682(a) of the FCC Rules when all or part of 
the communications are transmitted in the same image emission

...

97.309   RTTY and data emission codes.

(a) Where authorized by §§97.305(c) and 97.307(f) of the part, an amateur 
station may transmit a RTTY or data emission using the following specified 
digital codes:

...

(4) An amateur station transmitting a RTTY or data emission using a digital 
code specified in this paragraph may use any technique whose technical 
characteristics have been documented publicly, such as CLOVER, G-TOR, or 
PacTOR, for the purpose of facilitating communications.


--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | dtil...@captechconsulting.com



On Jul 5, 2017, at 6:49 PM, Joe Taylor <j...@princeton.edu> wrote:

> Hi all,
> 
>> If you knew you had to send an ID with a packet, could you not reduce the 
>> amplitude of the whole data packet by a db or so and re-allocate that power 
>> to the CW ID? It certainly doesn't have to be loud, much like repeaters do 
>> id-under-voice. That way the FT8 signal taken by itself would still be 
>> constant envelope, and the CW id could be sent way down at FDial+100Hz. If 
>> the OOK nature of CW is the issue, you could always treat it as FSK using 1 
>> Hz and 100Hz. The 1Hz component would get chopped out in the radio, leaving 
>> the ID and FT8 signal.
> 
> Such a scheme would NOT produce a constant envelope signal.  Sending the CW 
> ID at a frequency offset by 100 Hz, or using FSK for the CW, would make the 
> signal much wider than an FT8 signal.
> 
>> the classification of the speed of sending morse is weird anyway.
>> definition of a word  definition of a character 
> 
> Morse code speeds are conventionally defined in a very precise way. See, for 
> example, http://www.kent-engineers.com/codespeed.htm .
> 
> The width of the main spectral lobe of a CW signal in Hz is roughly equal to 
> the speed in WPM.  Fairly strong secondary lobes occur at multiples of this 
> number.  Sending the CW ID at (say) 100 WPM, in order to squeze it into a 15 
> s Tx interval, would make the CW ID much wider than an FT8 signal.
> 
> Most likely we will implement CW ID as a separate, dedicated transmission 
> when the T/R sequence length is less than 30 s.
> 
> NB: Since June 15, 1983 FCC does NOT require US amateurs to use a CWID with 
> data modes.
> 
>   -- 73, Joe, K1JT
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> __

Re: [wsjt-devel] FT8: CW ID not a good idea

[David Tiller]

If you knew you had to send an ID with a packet, could you not reduce the 
amplitude of the whole data packet by a db or so and re-allocate that power to 
the CW ID? It certainly doesn't have to be loud, much like repeaters do 
id-under-voice. That way the FT8 signal taken by itself would still be constant 
envelope, and the CW id could be sent way down at FDial+100Hz. If the OOK 
nature of CW is the issue, you could always treat it as FSK using 1 Hz and 
100Hz. The 1Hz component would get chopped out in the radio, leaving the ID and 
FT8 signal.


--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | dtil...@captechconsulting.com



On Jul 5, 2017, at 5:29 PM, Richard Lamont <rich...@lamont.me.uk> wrote:

> On 05/07/17 22:10, David Tiller wrote:
> 
>> Any chance of having the CW id run concurrently with a data packet, perhaps 
>> at fDial + 100 Hz or so? It'd meet the id requirement without interfering 
>> with QSOs.
> 
> Doing it concurrently wouldn't be compatible with FT8 being a 'constant
> envelope' mode.
> 
> 73,
> Richard G4DYA
> 
> --
> 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


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8: CW ID not a good idea

[David Tiller]

Any chance of having the CW id run concurrently with a data packet, perhaps at 
fDial + 100 Hz or so? It'd meet the id requirement without interfering with 
QSOs. 

> On Jul 5, 2017, at 14:42, Gary McDuffie  wrote:
> 
> 
>> On Jul 4, 2017, at 12:56 PM, Steve Huston  wrote:
>> 
>> I did notice that having "CW ID after 73" turned on didn't work well
>> in that mode - I would get W2 out before it would change to the next
>> part of the sequence and stop.  I unchecked it for now.
> 
> Since it takes 13.4 something seconds just to send the data package out one 
> time, that only leaves about 1.5 seconds for your ID, not including turnover 
> time.  Just turn it off.  If the period were extended to finish the ID, you 
> would not decode the other station on the next turnover because you would 
> miss quite a bit of the early part of the data from him.
> 
> At least that is my understanding of the facts.  Someone please correct me if 
> I’m wrong.  New to the group.
> 
> Gary-AG0N
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
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] K4SHQ FT8 Notes

[David Tiller]

Re: the second part of item #2: You still can’t upload to eQSL or LoTW with FT8.

If Log4OM is anything like the macOS software I use, it actually uses TSQL 
under the covers to do the digital signing and upload. At least in my case, if 
you add the FT8 --> DATA mapping in TSQL, the upload works.

Might be worth a try.

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Jun 30, 2017, at 8:37 PM, Dan Malcolm 
<dan.malcol...@gmail.com<mailto:dan.malcol...@gmail.com>> wrote:

1.   Log4OM can be made to accept FT8 as a mode.  But while it accepts it 
as a mode, RST reports are set ‘59’.
2.   Reference #1 above. Making Log4OM accept FT8 is trivial but moot.  You 
still can’t upload to eQSL or LoTW with FT8.
3.   Log4OM also does not auto upload to eQSL when the mode is FT8.
4.   In order to capture the RST values I include them in my JTAlert-X “QSL 
Message” text window using Laurie’s replaceable tokens.  Check the JTAlert Help 
file under Logging in the “Comments and QSL Message Text Substitutions” section.

All short comings and disconnects will probably be resolved in time as FT8 
moves into its own.  Again congrats to the devel team.  This is exciting.

I am running an Apache ANAN 100D.  There has been discussion of what to call 
the “split” mode.  I didn’t understand WSJT’s use of it until it was explained 
on this forum just recently.  Now I do understand and approve.  My rig likes it 
just fine but I understand other rigs do not.  I do think we need another name 
for it so as not to confuse WSJT “split” with the other “split”.  I offered 
“Audio Purity Offset”, but will be happy with whatever the devel team decides.

Since FT8 is still beta, it is too soon to approach the on line logbooks about 
allowing FT8.  But that time is approaching.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://slashdot.org/>! 
http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
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] Some People!

[David Tiller]

It's not the fork that irritates me, it's the appropriation of the JT moniker 
for the code base and presumptive JT10 mode. Using someone's initials on a 
product conveys some level of approval or support that does not necessarily 
exist and using it on a new mode implies a 'better' or later release of an 
existing official mode. None of these conditions, IMHO, exist.

If I were JT I would insist on a name change on copyright and/or trademark 
grounds.

On Apr 23, 2017, at 13:13, Guy > 
wrote:

Hi Bill,

You cannot be part of the open source community and then complain that somebody 
borrows your code and then forks it. The JTDX project publishes their source 
code and is doing nothing wrong IMHO.

If the WSJT-X team are getting hot under the collar about this, maybe a much 
more restrictive licence would mollify them?

73 de Guy G4DWV 4X1LT

From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: 22 April 2017 00:30
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Some People!

On 22/04/2017 00:21, Laurie, VK3AMA wrote:
Saw this posted on the JTDX Yahoo group.

"JTDX outperforms WSJT-X, especially with overlapping signals. Also, JTDX is 
more sensitive"

Hi Laurie,

that may well be true but only at the cost of more false decodes, using more 
CPU resources than users with low spec machines might have or by applying a 
customized message analyser to filter out possible false decodes that 
potentially hides some valid decodes. Also there's nothing there for Mac users, 
EME users, VHF, UHF or Microwave users either.

Bottom line is that there would be no JTDX without WSJT-X. Same applies to 
JT65-HF, that would not be there if there had not been WSJT to steal 
functionality from.

There is no such thing as a free lunch.

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
--
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] USB audio output problem on Mac El Capitan

[David Tiller]

Ben,

I also use a MacBook Pro, and had similar symptoms. Mine turned out to be RF 
resetting the USB bus.

Try running the sfw with the ptt disconnected from the radio and see if it 
still misbehaves.

On Feb 5, 2017, at 12:30, Ben McKeown 
> wrote:

I'm really enjoying working JT65 and JT9, but I'm having a bit of a problem 
that is making very frustrating to have good QSOs. I'm running a SignaLink USB 
connected to my MacBook Pro. Consistently after several transmissions the 
WSJT-X software starts playing audio out of my internal speakers rather than 
through the USB output.If I restart the software it usually picks back up using 
the USB audio output but by that point I'm out of synch with the other station.

I've also noticed that when this happens the waterfall graph stops showing new 
data.

I'm running the latest version of WSJT-X (1.7.0).

OS Version: OS X El Capitan (10.11.6)
Hardware: MacBook Pro (15-inch, Late 2011)

I'd appreciate any help you can give.

Cheers,
Ben
KB3WYS
--
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
--
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] Feature request - noise blanker DSP filter?

[David Tiller]

All,

I'm currently suffering thru S9 arc noise at my QTH on 30m - 6m, but I figured 
I'd try to decode some MSK144 this evening - it should be able to cut thru the 
noise, right?

I forgot I had the noise blanker on (Icom 756 PRO), and I got decodes left and 
right. When I turn it off, though, I get no decodes at all. I figured if an 
old, tired DSP rig like the 750 PRO could do some DSP voodoo to zap the noise, 
WSJT-X could add it as either a standard filter or as an option.

What do you guys think?

I can provide WAV files of the noisy and noise-blanked signals.


--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ALL.txt idea

[David Tiller]

_I_ personally do not use ALL.txt or any other artifact of WSJT-X, but I do use 
WSJT-X often and am a software engineer that would rather err on the side of 
KISS than a monolithic app with more and more library dependencies. Emitting 
CSV isn't too much extra effort to add to WSJT-X, but adding a vendor-specific 
database library is, IMHO.

If the rows are not 'consistently formatted' enough for CSV, then they're 
likely unsuitable for a structured relational DB as well.

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Nov 7, 2016, at 4:12 PM, Black Michael 
<mdblac...@yahoo.com<mailto:mdblac...@yahoo.com>> wrote:

Would be more true if the records were consistently formatted...but they aren't.

What would you use a database for?

de Mike W9MDB

____
From: David Tiller 
<dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>>
To: WSJT software development 
<wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>>
Sent: Monday, November 7, 2016 3:08 PM
Subject: Re: [wsjt-devel] ALL.txt idea

I think Dan's idea of using comma- or tab-separated fields is a nice compromise 
between locking users into a particular database format (regardless of how 
ubiquitous) and unstructured rows.

CSV can be imported/parsed/chunked/scattered/gathered 100 ways to Sunday.
--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Nov 7, 2016, at 4:01 PM, Dan Malcolm 
<dmalcol...@mchsi.com<mailto:dmalcol...@mchsi.com>> wrote:

> I too use ALL.TXT.  But I believe a move towards some DB functionality could
> be made use comma or tab delimited fields (CSV file) instead of a space.
> The resulting text file could easily be imported into any DB management
> system that I am familiar with.  I don't believe it would add much to the
> code.
>
> Just my $.02 worth.
>
> _
> Dan Malcolm CFI/II
> K4SHQ
>
>
> -Original Message-
> From: Greg Beam [mailto:ki7m...@gmail.com<mailto:ki7m...@gmail.com>]
> Sent: Monday, November 07, 2016 10:00 AM
> To: Black Michael <mdblac...@yahoo.com<mailto:mdblac...@yahoo.com>>; WSJT 
> software development
> <wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>>
> Subject: Re: [wsjt-devel] ALL.txt idea
>
> Hi Mike,
>
> I am not sure if the ALL.txt discussion has come up before (probably has at
> some point), but certainly CALL3.txt has made the rounds several times. I
> was able to get CALL3 Database functionality working with SQLite for WSJT,
> and have a stand alone application for WSPR to process millions of spots the
> archives produce monthly, however, it does add a level of complexity to the
> application that may be more than is needed for minimal operation.
>
> It's hard to dismiss the simplicity of flat text files. On the other hand,
> having data in tables lends itself to many positive benefits. For example,
> the queries in this thread would be a fairly simple SQL query rather than
> requiring a Black Belt in command-line foo to extract it.
> Not to mention, the SQL language is cross-platform, and generally, no
> additional tools are required, but many exit at the users option.
>
> I am not suggesting that WSJT-X integrate post processing tools, rather, I
> am merely suggesting that the data could be stored in a different format (
> DB tables) that allows easy access by third party developers or primary
> users, in a more structured manner.
>
>
> 73's
> Greg, KI7MT
>
> On 11/7/2016 7:18 AM, Black Michael wrote:
>> I wouldn't be inclined to add database support when the most common
>> operations are achievable with the existing ALL.TXT.  Haven't we
>> discussed this before?  Somebody said something about putting the
>> messages in an sqlite database as I recall and had implemented something.
>> Though I'm sure we could make it portable it's adding a fair bit of
>> new stuff and overhead for doing this simple task.  Right now my logic
>> is about 100 lines of code and can pick up non-standard end-of-qso
>> messages to some degree right now.
>>
>> Is there some other function desirable from a database that would
>> justify it?  I can see where adding a field for "Rx Frequency" window
>> message presence would help in processing QSOs.  Non-standard QSO
>> messages would be an SQL challenge.
>>
>>
>> de Mike W9MDB
>>
>>
>>
>> --
>> --
>> *From:* Greg Beam <k

Re: [wsjt-devel] ALL.txt idea

[David Tiller]

I think Dan's idea of using comma- or tab-separated fields is a nice compromise 
between locking users into a particular database format (regardless of how 
ubiquitous) and unstructured rows.

CSV can be imported/parsed/chunked/scattered/gathered 100 ways to Sunday.
--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | dtil...@captechconsulting.com



On Nov 7, 2016, at 4:01 PM, Dan Malcolm <dmalcol...@mchsi.com> wrote:

> I too use ALL.TXT.  But I believe a move towards some DB functionality could
> be made use comma or tab delimited fields (CSV file) instead of a space.
> The resulting text file could easily be imported into any DB management
> system that I am familiar with.  I don't believe it would add much to the
> code.
> 
> Just my $.02 worth.
> 
> _
> Dan Malcolm CFI/II
> K4SHQ
> 
> 
> -Original Message-
> From: Greg Beam [mailto:ki7m...@gmail.com] 
> Sent: Monday, November 07, 2016 10:00 AM
> To: Black Michael <mdblac...@yahoo.com>; WSJT software development
> <wsjt-devel@lists.sourceforge.net>
> Subject: Re: [wsjt-devel] ALL.txt idea
> 
> Hi Mike,
> 
> I am not sure if the ALL.txt discussion has come up before (probably has at
> some point), but certainly CALL3.txt has made the rounds several times. I
> was able to get CALL3 Database functionality working with SQLite for WSJT,
> and have a stand alone application for WSPR to process millions of spots the
> archives produce monthly, however, it does add a level of complexity to the
> application that may be more than is needed for minimal operation.
> 
> It's hard to dismiss the simplicity of flat text files. On the other hand,
> having data in tables lends itself to many positive benefits. For example,
> the queries in this thread would be a fairly simple SQL query rather than
> requiring a Black Belt in command-line foo to extract it. 
> Not to mention, the SQL language is cross-platform, and generally, no
> additional tools are required, but many exit at the users option.
> 
> I am not suggesting that WSJT-X integrate post processing tools, rather, I
> am merely suggesting that the data could be stored in a different format (
> DB tables) that allows easy access by third party developers or primary
> users, in a more structured manner.
> 
> 
> 73's
> Greg, KI7MT
> 
> On 11/7/2016 7:18 AM, Black Michael wrote:
>> I wouldn't be inclined to add database support when the most common 
>> operations are achievable with the existing ALL.TXT.  Haven't we 
>> discussed this before?  Somebody said something about putting the 
>> messages in an sqlite database as I recall and had implemented something.
>> Though I'm sure we could make it portable it's adding a fair bit of 
>> new stuff and overhead for doing this simple task.  Right now my logic 
>> is about 100 lines of code and can pick up non-standard end-of-qso 
>> messages to some degree right now.
>> 
>> Is there some other function desirable from a database that would 
>> justify it?  I can see where adding a field for "Rx Frequency" window 
>> message presence would help in processing QSOs.  Non-standard QSO 
>> messages would be an SQL challenge.
>> 
>> 
>> de Mike W9MDB
>> 
>> 
>> 
>> --
>> --
>> *From:* Greg Beam <ki7m...@gmail.com>
>> *To:* Black Michael <mdblac...@yahoo.com>; WSJT software development 
>> <wsjt-devel@lists.sourceforge.net>
>> *Sent:* Monday, November 7, 2016 12:37 AM
>> *Subject:* Re: [wsjt-devel] ALL.txt idea
>> 
>> Hi Mike,
>> 
>> This is another email I just pulled out of the spam box. No wonder I 
>> was missing the other half of the conversation.
>> 
>> Ive been thinking about these text files for some time now. There has 
>> to be a better way than exercising command-line foo to get the data 
>> folks need. Not that I mind the command line, I spend most of my time 
>> there, but that's not very helpful to the masses.
>> 
>> There seems to be allot of different uses for CALL3.txt and the 
>> ALL.txt files. I keep circling back to database tables and I've played 
>> with the CALL.txt file a bit with WSJT, but the Qt / C++ deal with 
>> WSJT-X I've not gotten through yet.
>> 
>> Maybe if we sit down and try to capture most or at least some of the 
>> requirements, we could start kicking around some DB integration design 
>> concepts.
>> 
>> 73's
>> Greg, KI7MT
>> 
>> 
>> On 11/6/2016 11:03 AM, Black Michael wrote:
>>> Pretty simplewhen, for examp

Re: [wsjt-devel] ALL.txt idea

[David Tiller]

Michael,


My suggestion would be to follow the Unix design philosophy - do one thing, and 
do it well. I vote for any of the ALL.TXT searching/manipulation/modification 
be handled in a separate utility that's decoupled from the WSJT-X codebase.


--

David Tiller | Senior Manager
dtil...@captechconsulting.com
c 804.304.0638 / o 804.355.0511

[http://www.captechconsulting.com/siggen/logo.png]<http://www.captechconsulting.com/>

[http://www.captechconsulting.com/siggen/Dkblue_Facebook.png]<http://www.facebook.com/CapTechCareers>
 [http://www.captechconsulting.com/siggen/Dkblue_Twitter.png] 
<http://www.twitter.com/CapTechListens>  
[http://www.captechconsulting.com/siggen/Dkblue_LinkedIn.png] 
<http://www.linkedin.com/company/captech-ventures>  
[http://www.captechconsulting.com/siggen/Dkblue_StackOverflow.png] 
<http://www.stackoverflow.com/jobs/companies/captech-consulting>  
[http://www.captechconsulting.com/siggen/Dkblue_YouTube.png] 
<http://www.youtube.com/user/CapTechConsulting>  
[http://www.captechconsulting.com/siggen/Dkblue_Instagram.png] 
<https://www.instagram.com/lifeatcaptech/>
Best Firms 2016 #2 in Information Technology



From: Black Michael <mdblac...@yahoo.com>
Sent: Monday, November 7, 2016 9:18 AM
To: Greg Beam; WSJT software development
Subject: Re: [wsjt-devel] ALL.txt idea

I wouldn't be inclined to add database support when the most common operations 
are achievable with the existing ALL.TXT.  Haven't we discussed this before?  
Somebody said something about putting the messages in an sqlite database as I 
recall and had implemented something.
Though I'm sure we could make it portable it's adding a fair bit of new stuff 
and overhead for doing this simple task.  Right now my logic is about 100 lines 
of code and can pick up non-standard end-of-qso messages to some degree right 
now.

Is there some other function desirable from a database that would justify it?  
I can see where adding a field for "Rx Frequency" window message presence would 
help in processing QSOs.  Non-standard QSO messages would be an SQL challenge.


de Mike W9MDB




From: Greg Beam <ki7m...@gmail.com>
To: Black Michael <mdblac...@yahoo.com>; WSJT software development 
<wsjt-devel@lists.sourceforge.net>
Sent: Monday, November 7, 2016 12:37 AM
Subject: Re: [wsjt-devel] ALL.txt idea

Hi Mike,

This is another email I just pulled out of the spam box. No wonder I was
missing the other half of the conversation.

Ive been thinking about these text files for some time now. There has to
be a better way than exercising command-line foo to get the data folks
need. Not that I mind the command line, I spend most of my time there,
but that's not very helpful to the masses.

There seems to be allot of different uses for CALL3.txt and the ALL.txt
files. I keep circling back to database tables and I've played with the
CALL.txt file a bit with WSJT, but the Qt / C++ deal with WSJT-X I've
not gotten through yet.

Maybe if we sit down and try to capture most or at least some of the
requirements, we could start kicking around some DB integration design
concepts.

73's
Greg, KI7MT


On 11/6/2016 11:03 AM, Black Michael wrote:
> Pretty simplewhen, for example, on eQSL, you get a mismatched QSL
> you can look at your messages to see if they got it wrong or you did.
> And you can submit the evidence to them so they can correct or you
> correct your own.
>
> I've also used it when noticing in JTAlert that a band isn't
> confirmed...I can look them up and see the evidence again and either
> correct my log or ask them to correct theirs.
>
> With LOTW you don't have that luxury.since there's no visibility of
> mismatched QSOs
>
> And yes...this is a WSJT Dev list item as I'm proposing submitting a
> patch to make this easy for everyone instead of just those with grep,
> EMACS, or whatever they may be currently using.
>
> de Mike W9MDB
>
>
> 
> *From:* Greg Beam <ki7m...@gmail.com<mailto:ki7m...@gmail.com>>
> *To:* WSJT software development 
> <wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>>
> *Sent:* Sunday, November 6, 2016 11:40 AM
> *Subject:* Re: [wsjt-devel] ALL.txt idea
>
> Hello All,
>
> I'm not sure this is a WSJT Dev list item, and, I arrived late to the
> party on this is seems, but:
>
> What is the end goal here? What are you trying accomplish with the
> ALL.txt file?
>
> 73's
> Greg, KI7MT
>
>
> On 11/6/2016 10:05 AM, Claude Frantz wrote:
>> On 11/05/2016 03:42 PM, Black Michael wrote:
>>
>> Hi Michael,
>>
>>> And how are you doing that?  I wrote a program so all I have to do is
>>> "qsos dj0ot&q

Re: [wsjt-devel] r 7265 Lock Tx=Rx issue for 'Enable VHF/UHF/Microwave features'

[David Tiller]

Allan,

You wrote:
After editing and saving the .ini file and confirming that indeed the edit has 
taken place, closing WSJT-X and restarting and immediately viewing the .ini 
file again, it has returned to LockTxFreq=true.  All of this is in JT65 or JT9 
modes.

Did you edit the ini file while wsjt-x was running? If you did that probably 
explains why the setting kept reverting.  I bet the program rewrites that file 
on quit.

On Nov 6, 2016, at 20:13, Allan Downie 
> wrote:

fter editing and saving the .ini file and confirming that indeed the edit has 
taken place, closing WSJT-X and restarting and immediately viewing the .ini 
file again, it has returned to LockTxFreq=true.  All of this is in JT65 or JT9 
modes.
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Fw: Power memory patch

[David Tiller]

Joe,


I for one am in favor of the change. My transceiver apparently has slightly 
different gain or ALC sensitivity on each band, and not having to fiddle with 
the power out slider would be welcome.


--

David Tiller | Senior Manager
dtil...@captechconsulting.com
c 804.304.0638 / o 804.355.0511

[http://www.captechconsulting.com/siggen/logo.png]<http://www.captechconsulting.com/>

[http://www.captechconsulting.com/siggen/Dkblue_Facebook.png]<http://www.facebook.com/CapTechCareers>
 [http://www.captechconsulting.com/siggen/Dkblue_Twitter.png] 
<http://www.twitter.com/CapTechListens>  
[http://www.captechconsulting.com/siggen/Dkblue_LinkedIn.png] 
<http://www.linkedin.com/company/captech-ventures>  
[http://www.captechconsulting.com/siggen/Dkblue_StackOverflow.png] 
<http://www.stackoverflow.com/jobs/companies/captech-consulting>  
[http://www.captechconsulting.com/siggen/Dkblue_YouTube.png] 
<http://www.youtube.com/user/CapTechConsulting>  
[http://www.captechconsulting.com/siggen/Dkblue_Instagram.png] 
<https://www.instagram.com/lifeatcaptech/>
Best Firms 2016 #2 in Information Technology



From: Joe Taylor <j...@princeton.edu>
Sent: Tuesday, October 25, 2016 2:59 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Fw: Power memory patch

Mike --

Could you explain the rationale behind this suggested feature?

Why might I want WSJT-X to remember particular power output settings on
a band-by-band basis?

Why would I (in general) want to adjust my power output by using the
slider on the WSJT-X screen, rather than by making an adjustment on the
transceiver itself?

To what fraction of our users might such a feature be important?  (I
have seen no clamor in favor of it.)

-- Joe, K1JT

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Enhancement Suggestion - Coloring the "progress bar" to reflect Odd/Even sequence.

[David Tiller]

Or perhaps have it advance left to right on even sequences and right to left on 
odd?

> On Oct 16, 2016, at 17:02, Björn Ekelund  wrote:
> 
> Brilliant idea
> 
> 2016-10-16 22:25 GMT+02:00 Keith Laaks :
>> Hi All,
>> 
>> I find that when listening for stations, I often need to go glance at the 
>> clock to see where we are at that moment with regards to odd/even sequencing.
>> 
>> The "progress bar" at the bottom right is a very convenient real-time 
>> visualization of the time lapsed/remaining during the current sequence.
>> It would be even more convenient if the color could indicate whether we are 
>> now in “odd/2nd (orange)” or “even/1st (blue)” sequence.
>> 
>> Comments?
>> 
>> Thanks
>> 
>> Keith
>> ZS6TW
>> 
>> 
>> --
>> 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
> 
> --
> 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

--
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] Possible issues w/ WSJT-X 1.7 r7072

[David Tiller]

All,

First let me thank all of you for your hard work on this program!

I noticed the following on r7072 (Running under OSX 10.9.5):

1) Given a constant audio level input with the JT65 level adjusted to 30 dB, I 
see the correct 30dB audio reading using JT9, JT65, JT9+JT65, JT4, QRA64, and 
WSPR2. Switching to ISCAT, JTMSK or MSK144 results in a 5dB drop in the 
reported signal level.

2) I don't use the hamlib rig control (I set it to 'None'). In modes ISCAT, 
JTMSK, MSK144, and QRA64 I am unable to change the band dropdown by hand. All 
the other modes allow it.

Thanks again!

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



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

Re: [wsjt-devel] OSX - WSJT-X UDP interface -- help from Apple Mac folks -pse!

[David Tiller]

That's very odd. Are you 100% sure that the UDP host is 127.0.0.1 and port is 
2237 in wsjt-X? It sounds like it's not sending anything. I don't have any of 
the checkboxes checked.

You can install wireshark to verify exactly what's on the localhost network.

I also use JT-Bridge to connect wsjt-X to MacLoggerDX - it receives the UDP 
messages. You might try that - you may have to point it at an empty file so it 
thinks there's a MacLoggerDX database around.

On Aug 20, 2016, at 13:28, Dan - VA3MA <va...@me.com<mailto:va...@me.com>> 
wrote:

David
I can communicate between a ump server and client that i programmed - both ways!

But I cannot get your or my program to revfrom  ?? -just sits there at that 
statement !


73
Dan VA3MA


On Aug 20, 2016, at 11:11 AM, David Tiller 
<dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>> wrote:

Dan,

Does a test program that sends UDP data running on the same Mac trigger the 
recv?

Alternatively, check to see if the osx firewall and/or antivirus is blocking 
you.

On Aug 19, 2016, at 22:43, Dan - VA3MA <va...@me.com<mailto:va...@me.com>> 
wrote:

Hi
I've written a small Python program to fetch the UDP data sent by WSJT-X on 
localhost port 2237.
It is listed below
It can get a socket connection to WSJT-X but it then just sits waiting to 
receive.
I've tried everything I know of the get it to receive - even running as root.
But nothing - it just sits waiting for some data at statement  [sock.recv(1024)]

Would appreciate any thoughts and suggestions to get this working on OSX El Cap.
( the same program runs fine under Windows! - as Bill G4WJS as shown me)


here is the program

>>> from socket import socket, AF_INET, SOCK_DGRAM
>>> sock = socket (AF_INET, SOCK_DGRAM)
>>> sock.bind (('127.0.0.1', 2237, ))
>>> while True:
... sock.recv(1024)
...


Thanks & 73
Dan VA3MA



--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto: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] OSX - WSJT-X UDP interface -- help from Apple Mac folks -pse!

[David Tiller]

Dan,

I'm running OSX 10.9.5 and python 2.7.1. Your test program also didn't work 
here. For whatever reason, this one does:

from socket import socket, AF_INET, SOCK_DGRAM
sock = socket (AF_INET, SOCK_DGRAM)
sock.bind (('127.0.0.1', 2237))
while True:
data, addr = sock.recvfrom(1024)
print data


--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com<mailto:dtil...@captechconsulting.com>



On Aug 19, 2016, at 10:41 PM, Dan - VA3MA <va...@me.com<mailto:va...@me.com>> 
wrote:

Hi
I’ve written a small Python program to fetch the UDP data sent by WSJT-X on 
localhost port 2237.
It is listed below
It can get a socket connection to WSJT-X but it then just sits waiting to 
receive.
I’ve tried everything I know of the get it to receive - even running as root.
But nothing - it just sits waiting for some data at statement  [sock.recv(1024)]

Would appreciate any thoughts and suggestions to get this working on OSX El Cap.
( the same program runs fine under Windows! - as Bill G4WJS as shown me)


here is the program

>>> from socket import socket, AF_INET, SOCK_DGRAM
>>> sock = socket (AF_INET, SOCK_DGRAM)
>>> sock.bind (('127.0.0.1', 2237, ))
>>> while True:
... sock.recv(1024)
...


Thanks & 73
Dan VA3MA



--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto: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] OSX - WSJT-X UDP interface -- help from Apple Mac folks -pse!

[David Tiller]

Dan,

Does a test program that sends UDP data running on the same Mac trigger the 
recv?

Alternatively, check to see if the osx firewall and/or antivirus is blocking 
you.

On Aug 19, 2016, at 22:43, Dan - VA3MA > 
wrote:

Hi
I've written a small Python program to fetch the UDP data sent by WSJT-X on 
localhost port 2237.
It is listed below
It can get a socket connection to WSJT-X but it then just sits waiting to 
receive.
I've tried everything I know of the get it to receive - even running as root.
But nothing - it just sits waiting for some data at statement  [sock.recv(1024)]

Would appreciate any thoughts and suggestions to get this working on OSX El Cap.
( the same program runs fine under Windows! - as Bill G4WJS as shown me)


here is the program

>>> from socket import socket, AF_INET, SOCK_DGRAM
>>> sock = socket (AF_INET, SOCK_DGRAM)
>>> sock.bind (('127.0.0.1', 2237, ))
>>> while True:
... sock.recv(1024)
...


Thanks & 73
Dan VA3MA



--
___
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] Mac Problem

[David Tiller]

John,

I had the same issue on my Mac and it turned out to be RF getting into the USB 
controller via the external rig controller/sound card. I fixed my issue by 
putting a bunch of mix 31 ferrites on my feed line. I did the research at 
fair-rite.com and bought them from 
Newark.com.

I didn't see this issue with my prior MacBook Pro, so I can only assume that 
the newer ones are more RF sensitive.

Good luck!

On Apr 16, 2016, at 11:25, John Nelson 
> wrote:

I have (another) Mac user running OSX 10.11 with an audio problem reported as 
follows:

-
I need some help with this problem that has crept up on my WSJT-X installation. 
 I'm using a Kenwood TS-590S with a Macbook Pro under system 10.11.5.  The 
issue I'm having is that in the middle of a QSO, the software switches from the 
radio USB sound I/O to the internal microphone and speakers.  I'm able to 
re-create this problem by just launching the software and hitting the TUNE 
button 2 or 3 times in a row.  The only way to recover is either re-select the 
USB Audio CODEC on both input and output or re-launch the program.

He adds:  "There are documented issues with USB audio devices in general and OS 
X 10.11 that
supposedly got resolved in 10.11.4.  Also worth pointing out that this happen 
on both JT-65 and WSPR modes."
-
An earlier report was with an Icom rig.   Bill has mentioned that these 
problems as probably OSX 10.11 related.   I run OSX 10.11 and have not seen 
this problem and cannot provoke it.

I have suggested using a ferrite core on the USB line in case of RFI but 
without apparent success.  In any case, RF power is very low - 5 watts or less.

Has anyone any suggestions?  Are these reported elsewhere?

- John G4KLA
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel