Re: [wsjt-devel] FT8 frequency in VK

[Takehiko Tsutsumi]

Hi all,

As I sent on June 30, FT8 default frequency on 80m should be 3.573MHz 
for JA.


Please consider to change.

Regards,

take

de JA5AEA

On 7/1/2017 2:10 PM, David wrote:
HI...i would suggest that 14.078 where JT9 would be might be a better 
frequency for FT8 than 14.079.in VK I know other ops would get 
curious as to what they are seeing and may be come interested in 
learning about FT8


73 David VK4BDJ



-- 


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 notes

[Steven Franke]

Hi Joe, Bill, and all,

I thought you’d be interested in seeing an encouraging result from our tests 
the other day. Hopefully, a screenshot will be attached to this, showing two 
receive cycles that I recorded while you both (Joe and Bill) were deliberately 
transmitting CQs on nearly the same frequency during one of our 20m tests.

Joe was transmitting on 1500 Hz offset, and Bill was at 1512 Hz. With a few 
minor tweaks (mainly, just lowering the sync threshold) the decoder is able to 
decode these overlapping signals without even using subtraction. Nice!

Steve, k9an

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

[David]

Just had a contact with VK6KXW on FT8 his sig  -14 and mine 
-13.works well


73 DAVID VK4BDJ


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

[wsjt-devel] FT8 frequency in VK

[David]

HI...i would suggest that 14.078 where JT9 would be might be a better 
frequency for FT8 than 14.079.in VK I know other ops would get 
curious as to what they are seeing and may be come interested in 
learning about FT8


73 David VK4BDJ



--
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: Important, [please read if you use an external PA with WSJT-X

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Friday, June 30, 2017 9:31 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X: Important, [please read if you use an 
external PA with WSJT-X

HI Dave,

comments in line below.

On 01/07/2017 01:50, Dave AA6YQ wrote:


AA6YQ comments below

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Friday, June 30, 2017 8:33 PM
To: WSJT software development
Subject: [wsjt-devel] WSJT-X: Important, [please read if you use an 
external PA with WSJT-X


snip<

 There is  a notable exception to  this in that DX  Lab Suite 
Commander
 does not give us a way of knowing when CAT commands have actually 
been
 completed.


You've never asked for this capability, Bill.

   This combined  with  the way  that  Commander spaces  CAT
 commands, rather  than being paced  by the rig's CAT responses, 
means
 that delays of more than 1 second are likely.

I have asked for a way of knowing when commands have been processed a couple of 
times. I was led to believe it was not practical for Commander to deliver that 
information.

>>>Commander could be readily extended to send a message each time a command is 
>>>issued to the transceiver. No application can reliably inform you when a 
>>>command sent to a transceiver has been fully processed by that transceiver, 
>>>because no transceiver makes that information available. One can know that 
>>>some aspect of a command has been executed -- for example, the transceiver's 
>>>reported state has changed from RX to TX -- but that doesn't mean that the 
>>>"transmit" command has been fully processed; for example, there's no 
>>>guarantee that RF is yet being emitted.

For this particular case what is really needed is a way of knowing when a 
sequence of TCP/IP commands ending with a Tx directive have been actioned. By 
actioned I mean that if RTS or DTR  or some other hard wired PTT is employed 
then it has been asserted or if a CAT PTT command is used then the rig has 
responded that it has accepted that command.

>>>You have the ability to monitor a transceiver's RX/TX state -- as reported 
>>>by the transceiver. Only Icom, TenTec, and some old Yaesu radios provide 
>>>explicit "command accepted" responses, but a "command accepted" response 
>>>does not necessarily mean "command successfully executed". 

That could be boiled down to a simple TCP/IP poll of the PTT state so long as 
it reflected the above.

The word "pacing" implies a steady and 
consistent speed, which is exactly what Commander provides. Commander users can 
specify

the rate at which CAT commands are executed, thereby establishing an 
appropriate balance between responsiveness and CPU consumption.

I understand that is the way you have chosen to implement CAT and it is not 
unreasonable but every other implementation seems to use the rig's responses to 
determine if a command has been completed and that also limits resource usage 
but lets the rig itself pace the progress.

Obviously, either way, state that need to be read from the rig may be polled at 
some regular interval but for example OmniRig manages to do that at a very high 
rate without CPU load issues. Regardless of polling for state, here we are 
talking about state setting commands which IMHO need no pacing 

>>>There are several transceivers that cannot accept state-setting commands 
>>>without pacing. The FT-450, for example. The Elecraft K3 requires a 500 ms 
>>>delay after a band change, to cite another example.

and it is safe to assume that an ACK response from the rig is sufficient to 
proceed to the next (the Kenwood style protocol does complicate that a little 
due to the absence of an ACK response but that can be worked around if 
required).

>>>Kenwood, Elecraft, and recent Yeasu transceivers do not provide ACK 
>>>responses. As pointed out above, the ACK responses from Icom transceivers 
>>>mean "command accepted", not "command processed"; Icom transceivers  send an 
>>>ACK to indicate that a command was received without a CI-V bus collision, 
>>>and thus need not be re-sent.

Bottom line is that even if we can get a confirmation of PTT set after a few 
other commands, taking a second or more to complete the commands is problematic 
with data mode protocols that need fit into a 15s period, completion 
transmitter and audio sequencing, a 13s data transmission, time to decode and 
some thinking time for the operator to decide the next response. The only 
current safe way to do this with Commander with some rigs is to add a delay of 
1 one more seconds (1.3s in my case with an IC-756) after sending commands to 
Commander and before generating a

[wsjt-devel] FT8 testing

[David]

Hi Joe and Billhave d/l and compiled r7755 and am trialing it on 
14.079 havent had any replies as yet but seems to be working well on 
Linux Mint 18.1 64bit will keep testing and giving reports to this group


73 David VK4BDJ




--
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: Important, [please read if you use an external PA with WSJT-X

[Neil Zampella]

Bill,

I've been using DX Commander with my KX3, and prior to that IC-715 for 4 
or 5 years.   I really would not want to give that up as it fully 
integrates with the rest of the DXLab suite. Is there anything that 
Dave can do to adjust Commander ??


Neil, KN3ILZ


On 6/30/2017 8:32 PM, Bill Somerville wrote:

Hi All,

along with the new FT8 mode we reduced the built in delay between PTT 
and audio starting. It was such that audio started at the beginning of 
the next second. This meant that PTT was asserted soon after the 
beginning of a transmit period and audio started at the beginning of 
the next second (second 1). This was recently reduced to the start of 
the next 1/2 second (0.5s into the Tx period) for the FT8 mode. The 
change was made to allow a bit more decoding and thinking time at the 
end of an Rx period.


The change above has revealed some deficiencies in the timing of the 
start of Tx audio when CAT commands are executed before PTT is 
asserted. Here is the commentary on a change I have just committed 
(r7756) that tries to fix that:


Smarter Tx sequencing that allows for CAT processing latency

When using  split operating and/or rig  mode setting there is a delay
before PTT  is asserted  while the CAT  commands are processed. There
will even be  a small delay if  CAT is only used for  PTT. This 
change
waits for these  commands to be completed before starting  the 
user Tx

delay specified in the settings.

There is  a notable exception to  this in that DX  Lab Suite 
Commander
does not give us a way of knowing when CAT commands have actually 
been
completed.   This combined  with  the way  that  Commander spaces  
CAT

commands, rather  than being paced  by the rig's CAT responses, means
that delays of more than 1 second are likely. As most rigs suffer 
some
sort of ALC overshoot when PTT is asserted with audio already 
present,
it is strongly recommended not to use  the DX Lab Suite Commander 
as a
rig control proxy if your rig may  suffer ALC overshoot and you 
use an
external PA. Please note that using a typical RF power meter to 
detect

ALC  overshoots is  unwise  as  they are  rarely  fast enough. It  is
probably wise to assume that all rigs suffer ALC overshoot since 
it is

very difficult to design an ALC loop that avoids it.

This change  also increases  the range of  the 
"Settings->Advanced->Tx

Delay" spin box to 0s up to 2s.

73
Bill
G4WJS.






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

Re: [wsjt-devel] FT8 notes

[Neil Zampella]

FWIW ... there has been at least >> 4 << different code releases today 
alone.  I ran the JTSDK build at 3:00 EDT and built v7752.   At 8:50 EDT 
or so, I built v7756.  The updates are flying as fast as the development 
team can test and update. This is one of the reasons why the development 
team actively discourages making local builds available.If someone 
downloads a build r7752, then has an issue, they come here with it, and 
the team has to ask questions about what revision was being used because 
invariably that information is missing. Then they come to find out 
that the issue was fixed in r7756.  If they were building on their own, 
they would have had the new version already.


Frankly, downloading and installing JTSDK is a snap if you just follow 
the directions as listed on the download page.Respect the developers 
wishes.


Neil, KN3ILZ


On 6/30/2017 4:29 PM, Dani EA4GPZ wrote:

El 30/06/17 a las 19:06, Joe Taylor escribió:


Anyone is welcome to build WSJT-X from source code, and use the results
on the air.  But please DO NOT post your pre-built binaries for others
to download.  This causes needless support problems for us.  We have no
way of knowing exactly what you did.  And if all you post is some sort
of binary, you're violating our GPL license.

Hi Joe,

I don't want to get into an argument here, and I understand the reason
for frowning upon people posting pre-built binaries, but I just wanted
to clarify the statement about the GPL license.

I'm not a lawyer, so I might not be 100% correct on this, but, as far as
I know, you can redistribute binaries for GPL software without the
accompanying source code. However, you should be ready to provide the
source code _if_ you are asked to do so by whoever got your binary. No
need to send any source code if you're not asked to do so. Also, if the
code you have compiled is available online (say, from the WSJT SVN) and
you have not modified it (as it is the case with pre-built binaries of
the SVN trunk), it might be enough to point the user to the location of
the source online.

73,

Dani EA4GPZ.






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

[Dan Malcolm]

Seems to work well David. Thanks.  Now we just need to get eQSL on board.
There Forum is down at the moment.  I'll try tomorrow.

 

From: David Tiller [mailto:dtil...@captechconsulting.com] 
Sent: Friday, June 30, 2017 8:05 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] K4SHQ FT8 Notes

 

In TSQL, under preferences there's a tab called "ADIF Modes". In there you
can add an FT8  --> DATA mapping. 

 

Here's mine:

 



--

David Tiller

Sr. Architect/Lead Consultant | CapTech

(804) 304-0638 | dtil...@captechconsulting.com
 

 

 

 

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





Thanks David. Log4OM does indeed use TQSL under the hood.  Just where in
TQSL do enter FT8-->DATA?

BTW I have found that QRZ will accept FT8.

 

From: David Tiller [ 
mailto:dtil...@captechconsulting.com] 
Sent: Friday, June 30, 2017 7:47 PM
To: WSJT software development < 
wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] K4SHQ FT8 Notes

 

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

 

 

 

On Jun 30, 2017, at 8:37 PM, Dan Malcolm < 
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://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] FT8: Potential new mode for fast QSOs

[David Tiller]

Joe wrote: "Three extra bits are available in the message payload, with uses 
yet to be defined."

I know his original post was meant for FT8, but if there are any spare bits 
available in any of the modes with variable length transmissions (fast JT 
modes, MSK, etc), then I'd like to see them dedicated to indicate the length of 
transmission. In other words, if I hear a CQ in any of those modes, WSJT-X can 
automatically choose the correct duration for the reply. In fact, one side 
could change durations mis-QSO (up for poor condx, down for good condx) and the 
other side would pick it up and adapt.

Perhaps we could:
1) Settle on discrete values as it is now (5, 10, 15, 30) which would require 2 
bits
2) allow for n * 5 second values for greater granularity (would need 3 bits to 
get 30 secs)
3) perhaps something esoteric like 5 * 2^n seconds (2 bits gives you 5, 10, 20, 
and 40 secs).
4) use some other mechanism to indicate the duration, like a specific start 
tone on the packet.


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



On Jun 29, 2017, at 11:33 AM, Joe Taylor  wrote:

> Three extra bits are available in the message payload, with uses yet to be 
> defined. 


--
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: Important, [please read if you use an external PA with WSJT-X

[Bill Somerville]

HI Dave,

comments in line below.

On 01/07/2017 01:50, Dave AA6YQ wrote:

AA6YQ comments below

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Friday, June 30, 2017 8:33 PM
To: WSJT software development
Subject: [wsjt-devel] WSJT-X: Important, [please read if you use an external PA 
with WSJT-X


snip<

  There is  a notable exception to  this in that DX  Lab Suite Commander
  does not give us a way of knowing when CAT commands have actually been
  completed.


You've never asked for this capability, Bill.

This combined  with  the way  that  Commander spaces  CAT
  commands, rather  than being paced  by the rig's CAT responses, means
  that delays of more than 1 second are likely.
I have asked for a way of knowing when commands have been processed a 
couple of times. I was led to believe it was not practical for Commander 
to deliver that information. For this particular case what is really 
needed is a way of knowing when a sequence of TCP/IP commands ending 
with a Tx directive have been actioned. By actioned I mean that if RTS 
or DTR  or some other hard wired PTT is employed then it has been 
asserted or if a CAT PTT command is used then the rig has responded that 
it has accepted that command.


That could be boiled down to a simple TCP/IP poll of the PTT state so 
long as it reflected the above.



The word "pacing" implies a steady and consistent speed, which is exactly what 
Commander provides. Commander users can specify

the rate at which CAT commands are executed, thereby establishing an 
appropriate balance between responsiveness and CPU consumption.


I understand that is the way you have chosen to implement CAT and it is 
not unreasonable but every other implementation seems to use the rig's 
responses to determine if a command has been completed and that also 
limits resource usage but lets the rig itself pace the progress. 
Obviously, either way, state that need to be read from the rig may be 
polled at some regular interval but for example OmniRig manages to do 
that at a very high rate without CPU load issues. Regardless of polling 
for state, here we are talking about state setting commands which IMHO 
need no pacing and it is safe to assume that an ACK response from the 
rig is sufficient to proceed to the next (the Kenwood style protocol 
does complicate that a little due to the absence of an ACK response but 
that can be worked around if required).


Bottom line is that even if we can get a confirmation of PTT set after a 
few other commands, taking a second or more to complete the commands is 
problematic with data mode protocols that need fit into a 15s period, 
completion transmitter and audio sequencing, a 13s data transmission, 
time to decode and some thinking time for the operator to decide the 
next response. The only current safe way to do this with Commander with 
some rigs is to add a delay of 1 one more seconds (1.3s in my case with 
an IC-756) after sending commands to Commander and before generating any 
audio. Not leaving that delay would probably break my recently repaired 
PA and and violate my 400W maximum licensed power by a factor of 3 at 
the beginning of every transmission.


73
Bill
G4WJS.

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

Re: [wsjt-devel] K4SHQ FT8 Notes

[Dan Malcolm]

Thanks David.  Got that done and in the process found there is an updated
TQSL 2.3.1.

 

From: David Tiller [mailto:dtil...@captechconsulting.com] 
Sent: Friday, June 30, 2017 8:05 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] K4SHQ FT8 Notes

 

In TSQL, under preferences there's a tab called "ADIF Modes". In there you
can add an FT8  --> DATA mapping. 

 

Here's mine:

 



--

David Tiller

Sr. Architect/Lead Consultant | CapTech

(804) 304-0638 | dtil...@captechconsulting.com
 

 

 

 

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





Thanks David. Log4OM does indeed use TQSL under the hood.  Just where in
TQSL do enter FT8-->DATA?

BTW I have found that QRZ will accept FT8.

 

From: David Tiller [ 
mailto:dtil...@captechconsulting.com] 
Sent: Friday, June 30, 2017 7:47 PM
To: WSJT software development < 
wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] K4SHQ FT8 Notes

 

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

 

 

 

On Jun 30, 2017, at 8:37 PM, Dan Malcolm < 
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://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] K4SHQ FT8 Notes

[David Tiller]

In TSQL, under preferences there's a tab called "ADIF Modes". In there you can 
add an FT8  --> DATA mapping.

Here's mine:

[cid:B5BAD66A-7A6F-4192-AAF1-990E851F62B5]
--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com



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

Thanks David. Log4OM does indeed use TQSL under the hood.  Just where in TQSL 
do enter FT8-->DATA?
BTW I have found that QRZ will accept FT8.

From: David Tiller [mailto:dtil...@captechconsulting.com]
Sent: Friday, June 30, 2017 7:47 PM
To: WSJT software development 
mailto:wsjt-devel@lists.sourceforge.net>>
Subject: Re: [wsjt-devel] K4SHQ FT8 Notes

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



On Jun 30, 2017, at 8:37 PM, Dan Malcolm 
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://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] WSJT-X: Important, [please read if you use an external PA with WSJT-X

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Friday, June 30, 2017 8:33 PM
To: WSJT software development
Subject: [wsjt-devel] WSJT-X: Important, [please read if you use an external PA 
with WSJT-X

>snip<

 There is  a notable exception to  this in that DX  Lab Suite Commander
 does not give us a way of knowing when CAT commands have actually been
 completed.

>>>You've never asked for this capability, Bill.

   This combined  with  the way  that  Commander spaces  CAT
 commands, rather  than being paced  by the rig's CAT responses, means
 that delays of more than 1 second are likely.

>>>The word "pacing" implies a steady and consistent speed, which is exactly 
>>>what Commander provides. Commander users can specify
the rate at which CAT commands are executed, thereby establishing an 
appropriate balance between responsiveness and CPU consumption.

73,

Dave, AA6YQ


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

[Dan Malcolm]

Thanks David. Log4OM does indeed use TQSL under the hood.  Just where in
TQSL do enter FT8-->DATA?

BTW I have found that QRZ will accept FT8.

 

From: David Tiller [mailto:dtil...@captechconsulting.com] 
Sent: Friday, June 30, 2017 7:47 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] K4SHQ FT8 Notes

 

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
 

 

 

 

On Jun 30, 2017, at 8:37 PM, Dan Malcolm 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://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] Distortion report

[James Shaver (N2ADV)]

Without knowing more about your receive setup, there is no way to tell just 
based on your screen shot that what is happening is on the transmitting 
stations side. 

> On Jun 30, 2017, at 6:40 PM, Pino Zollo  wrote:
> 
> I miss a way to notify a distortion on the emitted signal.
> 
> e.g. see the attached image with 4 or more decoding spectra.
> 
> I have seen other types of distortions:
> 
> 2nd an 3rd harmonics all decoding
> 
> 2n and 3rd harmonic do not decode because the spectrum is X2 or X3 wide.
> 
> A shadow spectrum on the left side of the principal one which partially
> covers the main one (possibly due to tubes linear amplifier)
> 
> 
> 
> 
> Can we think to a single digit number to tell it to the other station ?
> 
> 
> Best 73
> 
> Pino ZP4KFX
> 
> --
> 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



On Jun 30, 2017, at 8:37 PM, Dan Malcolm 
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://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] K4SHQ FT8 Notes

[Dan Malcolm]

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://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X: Important, [please read if you use an external PA with WSJT-X

[Bill Somerville]

Hi All,

along with the new FT8 mode we reduced the built in delay between PTT 
and audio starting. It was such that audio started at the beginning of 
the next second. This meant that PTT was asserted soon after the 
beginning of a transmit period and audio started at the beginning of the 
next second (second 1). This was recently reduced to the start of the 
next 1/2 second (0.5s into the Tx period) for the FT8 mode. The change 
was made to allow a bit more decoding and thinking time at the end of an 
Rx period.


The change above has revealed some deficiencies in the timing of the 
start of Tx audio when CAT commands are executed before PTT is asserted. 
Here is the commentary on a change I have just committed (r7756) that 
tries to fix that:


Smarter Tx sequencing that allows for CAT processing latency

When using  split operating and/or rig  mode setting there is a delay
before PTT  is asserted  while the CAT  commands are processed. There
will even be  a small delay if  CAT is only used for  PTT. This change
waits for these  commands to be completed before starting  the user Tx
delay specified in the settings.

There is  a notable exception to  this in that DX  Lab Suite Commander
does not give us a way of knowing when CAT commands have actually been
completed.   This combined  with  the way  that  Commander spaces  CAT
commands, rather  than being paced  by the rig's CAT responses, means
that delays of more than 1 second are likely. As most rigs suffer some
sort of ALC overshoot when PTT is asserted with audio already present,
it is strongly recommended not to use  the DX Lab Suite Commander as a
rig control proxy if your rig may  suffer ALC overshoot and you use an
external PA. Please note that using a typical RF power meter to detect
ALC  overshoots is  unwise  as  they are  rarely  fast enough. It  is
probably wise to assume that all rigs suffer ALC overshoot since it is
very difficult to design an ALC loop that avoids it.

This change  also increases  the range of  the "Settings->Advanced->Tx
Delay" spin box to 0s up to 2s.

73
Bill
G4WJS.


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

[wsjt-devel] FT8: Three extra bits are available

[Palle Preben-Hansen, OZ1RH]

FT8 sounds promising. Joe wrote:
*Three extra bits are available in the message payload, with uses yet to
be **defined.  We have in mind special message formats that might be used
in **contests, and the like.  Your considered suggestions for use of these
bits **are very welcome!*


   1. VHF contests in Europe needs the full 6 digit WWL locator like JO55
   *ul*. A QTH locator has always had 6 digits (or more for microwave),
   using only 4 digits comes from eme and has spread to HF
   2. Many contests needs a report and a serial number like 59*001* and
   even sometimes a 4 digit serial number 59*1001* when more than 1.000
   QSO's has been worked in the contest
   3. Sometimes a state/area/membership/IOTA number or similar free text
   needs to be transmitted. Most contest exchanges can be found in the N1MM
   contest program https://n1mm.hamdocs.com


73, Palle, OZ1RH.
www.oz1rh.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] Build 7754 notes

[Richard Lamont]

On 30/06/17 23:20, Richard Lamont wrote:

> FT8 spots received by me don't seem to be appearing on PSK reporter.

As others have noted, this is fixed in r7755.

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

[wsjt-devel] Build 7754 notes

[Richard Lamont]

Hi all,

First post to this list.

The arrival of FT8 finally gave me the push I needed to get off my lazy
butt and build WSJT-X from source for the first time, on Ubuntu 16.04.

Took a bit of trial and error to find the right options to persuade
JTSDK to download 7754, and it built first time.

It all seems to be working OK.

Very nice to see the full 16-bit dynamic range now on the 'thermometer'
- something I've been asking for. Thank you.

FT8 spots received by me don't seem to be appearing on PSK reporter.

It's staggering how quickly this mode has caught on in just one day. So
far I've seen six simultaneous decodes. Anyone beat this, on 14.079?

22 -12  0.6 1266 ~  KB3MOW N4EFS -11
22 -12  0.9  747 ~  PA9CC N2ADV 73
22 -11 -0.2  993 ~  K7TN KC4SIT R-18
22 -14  0.9 1090 ~  CT1GVN KM4MDT -09
22 -18  0.1 1395 ~  G7OED G4NRT R-14
22 -13  0.3 1696 ~  CQ A92AA LL56 ~Bahrain


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

Re: [wsjt-devel] Linux JTSDK build problem.

[Greg Beam]

Hello All,

Just to completeness; I've not used Ubuntu 14.04 in some time. I fired it
up; did a quick package update; rebuilt Hamlib3, then WSJT-X r7755. No
errors or warnings of consequence to end-users. Currently monitoring 20m
FT8.

I am working with Llyod offline to get his issue resolved.

73's
Greg, KI7MT

-Original Message-
From: Richard Bown [mailto:rich...@g8jvm.com] 
Sent: Friday, June 30, 2017 4:20 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] Linux JTSDK build problem.

Hi
Builds OK on linux Mint 18.1 64 bit ,which uses the same libs as ubuntu
16.04


On Fri, 30 Jun 2017 16:10:06 -0600
"Greg Beam"  wrote:

> Hi Llyod,
> 
> You can contact me off-line to keep the traffic on the mailing-dist 
> down a bit.
> 
> Couple question to answer in the offline email:
> * What Linux distro are you using?
> * How did you install JTSDK-Nix?
> 
> 73's
> Greg, KI7MT
> 
> -Original Message-
> From: Lloyd Kirk [mailto:ll...@gcis.biz]
> Sent: Friday, June 30, 2017 3:08 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: [wsjt-devel] Linux JTSDK build problem.
> 
> Hello,
> Can someone contact me perhaps directly if needed to answer a couple 
> of questions? I had JTSDK 2.0.21 installed on ubuntu 14.04  and it was 
> working but would not update the devel wsjtx to current, so I removed 
> it and re-installed. I have built hamlib, when I try to build the 
> latest devel of wsjtx it complains it cant find hamlib. I am sure I 
> must have missed something in the re-install. It has no problems 
> building the other programs i.e wspr, just not wsjtx.
> 
> Lloyd Kirk
> WB5HUP
> 
> --
> --
> --
> 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



--
--
Best wishes /73
Richard Bown

Email : rich...@g8jvm.com
HTTP  :  http://www.g8jvm.com
nil carborundum a illegitemis

##
Ham Call: G8JVM . QRV: 50-432 MHz + Microwave 23 cms 140W, 13 cms 100W &
3cms 5W Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W QRV VHF
6mtrs 200W, 4 mtrs 150W, 2mtrs 400W, 70cms 200W
OS: Linux Mint 18.1  x86_64 on a Dell Inspiron N5030 laptop

## 



--
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] Distortion report

[Pino Zollo]

I miss a way to notify a distortion on the emitted signal.

e.g. see the attached image with 4 or more decoding spectra.

I have seen other types of distortions:

2nd an 3rd harmonics all decoding

2n and 3rd harmonic do not decode because the spectrum is X2 or X3 wide.

A shadow spectrum on the left side of the principal one which partially
covers the main one (possibly due to tubes linear amplifier)




Can we think to a single digit number to tell it to the other station ?


Best 73

Pino ZP4KFX
--
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 to Pskreporter

[Alessandro Gorobey via wsjt-devel]

Thanks JOE!

r7755 reports OK
--
73
Sandro
IW3RAB

Il 30/06/2017 18:01, Alessandro Gorobey via wsjt-devel ha scritto:

Hi all,

tomorrow I try RX in the new mode and seem to be simple fantastic!!
I do some local QSO for practice on autosequence.

If try to search in pskreporter all QSO in 24h on any band any callsign 
mode=FT8 it report only 1 QSO.


Is this wanted?

Thank you all for the new gift 




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

Re: [wsjt-devel] WSJT - Devel - Versioning scheme.

[Joe Taylor]

Hi Edfel,

Thanks for your comments.  We tend not to increment our version number 
until we're ready (or nearly ready) to make an official release.  This 
will likely be very soon!

-- Joe, K1JT

On 6/30/2017 6:00 PM, Edfel Rivera wrote:

Hi:

Just an observation.  FT8 mode addressed an answer to a 'issue' among 
JT65 and users regarding long time for QSO. I want to congratulate the 
WSJTX development team.  Thats why I prefer to stick with the 'source'  
and not try forks!


IMO, WSJTX versioning should move some numbers up to reflect both 
program stability and functionality.  NOT sure if it should be 1.7.2 but 
IMO it should not be 1.7.1.  Personal view there are enough 
functionality for 1.8.0 but that just my point of view.


Thanks you!!!

Edfel
KP4AJ



--
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] Linux JTSDK build problem.

[Richard Bown]

Hi
Builds OK on linux Mint 18.1 64 bit ,which uses the same libs as ubuntu 16.04


On Fri, 30 Jun 2017 16:10:06 -0600
"Greg Beam"  wrote:

> Hi Llyod,
> 
> You can contact me off-line to keep the traffic on the mailing-dist down a
> bit.
> 
> Couple question to answer in the offline email:
> * What Linux distro are you using?
> * How did you install JTSDK-Nix?
> 
> 73's
> Greg, KI7MT
> 
> -Original Message-
> From: Lloyd Kirk [mailto:ll...@gcis.biz] 
> Sent: Friday, June 30, 2017 3:08 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: [wsjt-devel] Linux JTSDK build problem.
> 
> Hello,
> Can someone contact me perhaps directly if needed to answer a couple of
> questions? I had JTSDK 2.0.21 installed on ubuntu 14.04  and it was working
> but would not update the devel wsjtx to current, so I removed it and
> re-installed. I have built hamlib, when I try to build the latest devel of
> wsjtx it complains it cant find hamlib. I am sure I must have missed
> something in the re-install. It has no problems building the other programs
> i.e wspr, just not wsjtx.
> 
> Lloyd Kirk
> WB5HUP
> 
> 
> --
> 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



-- 
-- 
Best wishes /73 
Richard Bown

Email : rich...@g8jvm.com
HTTP  :  http://www.g8jvm.com
nil carborundum a illegitemis
##
Ham Call: G8JVM . QRV: 50-432 MHz + Microwave 23 cms 140W, 13 cms 100W & 3cms 5W
Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W
QRV VHF 6mtrs 200W, 4 mtrs 150W, 2mtrs 400W, 70cms 200W
OS: Linux Mint 18.1  x86_64 on a Dell Inspiron N5030 laptop
##
 


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

[Robert Nobis]

Hi Joe,

That is a great approach. For some other products the developers seem to want 
the average user to debug the software for them, and they release multiple 
versions of their product over a very short period of time. The net result is 
there are a lot of very unstable products floating  around.

WSJT-X is a great product and the latest “release version" is very stable.

Thank you.


Bob Nobis 
n7...@nobis.net


> On Jun 30, 2017, at 14:48, Joe Taylor  wrote:
> 
> Hi Dani,
> 
> Thanks for your comments.
> 
> As far as I am concerned, a more important reason than possible licensing 
> issues is the simple fact that when  we deem a development version ready (or 
> nearly ready) for general use, we post "official" installation packages.
> 
> Until that time, we're in something more like an "early testing" stage. Yes, 
> we can use some tests FROM PEOPLE WHO SEND US REPORTS.  But we're not yet 
> ready to support and encourage widespread use.  That will come, soon enough!
> 
>   -- Joe, K1JT
> 
> On 6/30/2017 4:29 PM, Dani EA4GPZ wrote:
>> El 30/06/17 a las 19:06, Joe Taylor escribió:
>>> Anyone is welcome to build WSJT-X from source code, and use the results
>>> on the air.  But please DO NOT post your pre-built binaries for others
>>> to download.  This causes needless support problems for us.  We have no
>>> way of knowing exactly what you did.  And if all you post is some sort
>>> of binary, you're violating our GPL license.
>> Hi Joe,
>> I don't want to get into an argument here, and I understand the reason
>> for frowning upon people posting pre-built binaries, but I just wanted
>> to clarify the statement about the GPL license.
>> I'm not a lawyer, so I might not be 100% correct on this, but, as far as
>> I know, you can redistribute binaries for GPL software without the
>> accompanying source code. However, you should be ready to provide the
>> source code _if_ you are asked to do so by whoever got your binary. No
>> need to send any source code if you're not asked to do so. Also, if the
>> code you have compiled is available online (say, from the WSJT SVN) and
>> you have not modified it (as it is the case with pre-built binaries of
>> the SVN trunk), it might be enough to point the user to the location of
>> the source online.
>> 73,
>> Dani EA4GPZ.
>> --
>> 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] Linux JTSDK build problem.

[Greg Beam]

Hi Llyod,

You can contact me off-line to keep the traffic on the mailing-dist down a
bit.

Couple question to answer in the offline email:
* What Linux distro are you using?
* How did you install JTSDK-Nix?

73's
Greg, KI7MT

-Original Message-
From: Lloyd Kirk [mailto:ll...@gcis.biz] 
Sent: Friday, June 30, 2017 3:08 PM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Linux JTSDK build problem.

Hello,
Can someone contact me perhaps directly if needed to answer a couple of
questions? I had JTSDK 2.0.21 installed on ubuntu 14.04  and it was working
but would not update the devel wsjtx to current, so I removed it and
re-installed. I have built hamlib, when I try to build the latest devel of
wsjtx it complains it cant find hamlib. I am sure I must have missed
something in the re-install. It has no problems building the other programs
i.e wspr, just not wsjtx.

Lloyd Kirk
WB5HUP


--
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] WSJT - Devel - Versioning scheme.

[Edfel Rivera]

Hi:

Just an observation.  FT8 mode addressed an answer to a 'issue' among JT65
and users regarding long time for QSO. I want to congratulate the WSJTX
development team.  Thats why I prefer to stick with the 'source'  and not
try forks!

IMO, WSJTX versioning should move some numbers up to reflect both program
stability and functionality.  NOT sure if it should be 1.7.2 but IMO it
should not be 1.7.1.  Personal view there are enough functionality for
1.8.0 but that just my point of view.

Thanks you!!!

Edfel
KP4AJ
--
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 signal reports

[Joe Taylor]

We are well aware that displayed values of S/N are unreliable.  This 
will be fixed soon.


-- Joe, K1JT

On 6/30/2017 5:28 PM, Adrian Fabry wrote:

Hi all,

I saw also this problem.

For example, two signals, one very strong @ 806Hz -15 dB and one weak 
@1254 Hz  -17dB:


The wav file attached.

73 ady YO2NAA



*From:*wsjtgr...@yahoogroups.com [mailto:wsjtgr...@yahoogroups.com] *On 
Behalf Of *bruno@libero.it [wsjtgroup]

*Sent:* Friday, June 30, 2017 6:24 PM
*To:* wsjtgr...@yahoogroups.com
*Subject:* [wsjtgroup] FT8 signal reports




Just made some  QSOs on 20 and 6m with new mode.

Very fast, no relaxation allowed ;-(

Must be ready with finger and eyes.

Despite strong S-meter signals ( and on the waterfall of course)

I gave  a -18 -17 signal report ( given from the program) ,

so I think that the "reporting" system should be revised.

Very fine mode, anyway, congrats!

Best 73

Bruno i3rgh

-

i-qrp nr.555





__,_._,___



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

[Joe Taylor]

Hi Dani,

Thanks for your comments.

As far as I am concerned, a more important reason than possible 
licensing issues is the simple fact that when  we deem a development 
version ready (or nearly ready) for general use, we post "official" 
installation packages.


Until that time, we're in something more like an "early testing" stage. 
Yes, we can use some tests FROM PEOPLE WHO SEND US REPORTS.  But we're 
not yet ready to support and encourage widespread use.  That will come, 
soon enough!


-- Joe, K1JT

On 6/30/2017 4:29 PM, Dani EA4GPZ wrote:

El 30/06/17 a las 19:06, Joe Taylor escribió:


Anyone is welcome to build WSJT-X from source code, and use the results
on the air.  But please DO NOT post your pre-built binaries for others
to download.  This causes needless support problems for us.  We have no
way of knowing exactly what you did.  And if all you post is some sort
of binary, you're violating our GPL license.


Hi Joe,

I don't want to get into an argument here, and I understand the reason
for frowning upon people posting pre-built binaries, but I just wanted
to clarify the statement about the GPL license.

I'm not a lawyer, so I might not be 100% correct on this, but, as far as
I know, you can redistribute binaries for GPL software without the
accompanying source code. However, you should be ready to provide the
source code _if_ you are asked to do so by whoever got your binary. No
need to send any source code if you're not asked to do so. Also, if the
code you have compiled is available online (say, from the WSJT SVN) and
you have not modified it (as it is the case with pre-built binaries of
the SVN trunk), it might be enough to point the user to the location of
the source online.

73,

Dani EA4GPZ.


--
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] Linux JTSDK build problem.

[Lloyd Kirk]

Hello,
Can someone contact me perhaps directly if needed to answer a couple of 
questions? I had JTSDK 2.0.21 installed on ubuntu 14.04  and it was 
working but would not update the devel wsjtx to current, so I removed it 
and re-installed. I have built hamlib, when I try to build the latest 
devel of wsjtx it complains it cant find hamlib. I am sure I must have 
missed something in the re-install. It has no problems building the 
other programs i.e wspr, just not wsjtx.


Lloyd Kirk
WB5HUP

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

[Dani EA4GPZ]

El 30/06/17 a las 19:06, Joe Taylor escribió:

> Anyone is welcome to build WSJT-X from source code, and use the results
> on the air.  But please DO NOT post your pre-built binaries for others
> to download.  This causes needless support problems for us.  We have no
> way of knowing exactly what you did.  And if all you post is some sort
> of binary, you're violating our GPL license.

Hi Joe,

I don't want to get into an argument here, and I understand the reason
for frowning upon people posting pre-built binaries, but I just wanted
to clarify the statement about the GPL license.

I'm not a lawyer, so I might not be 100% correct on this, but, as far as
I know, you can redistribute binaries for GPL software without the
accompanying source code. However, you should be ready to provide the
source code _if_ you are asked to do so by whoever got your binary. No
need to send any source code if you're not asked to do so. Also, if the
code you have compiled is available online (say, from the WSJT SVN) and
you have not modified it (as it is the case with pre-built binaries of
the SVN trunk), it might be enough to point the user to the location of
the source online.

73,

Dani EA4GPZ.


--
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] IMPORTANT: JTAlert users testing FT8 must upgrade JTAlert or turn off spotting to HamSpots

[Laurie, VK3AMA]

Yesterday a link to a new JTAlert was posted to the group.
That version corrected the posting or FT8 spots to HamSpots as T10.

Please upgrade your JTAlert install with this version...
http://dnl.HamApps.com/Testing/HamApps_JTAlert_2.9.9_build_0001_Setup.exe

There are around 30 users that are posting the wrong mode spots because 
they haven't upgraded JTAlert.
I have been periodically running SQL queries against the HamSpots 
database to correct these spots, but that has become tiresome!


de Laurie VK3AMA

--
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 - build 7752 and rig control

[Black Michael via wsjt-devel]

To me leaving split completely out of the name is going to prompt questions of 
"why did my rig go into split mode".
It actually does a frequency split just like all splits do.  It's just that 
WSJT-X then adjusts the audio to maintain the reception offset during transmit 
instead of you having to tell the other person you shifted.  It's another use 
for split modenot a non-split mode thing.  Can't say I know any other 
software doing it but it's still really a split frequency operation.  Split has 
always meant split carrier...just that the audio typically shifts with it.
de Mike W9MDB

  From: Dan Malcolm 
 To: 'WSJT software development'  
 Sent: Friday, June 30, 2017 12:37 PM
 Subject: Re: [wsjt-devel] FT8 - build 7752 and rig control
   
I'd like to weigh in on the "what to call it" discussion.  Not that I have 
anything really better, but since we already have a well understood "split 
mode", called this a split confuses one function with another.  Can we say 
something like "Audio Purity Offset"?

I have not used it before I'm willing to give it a try.  I let you know what my 
Apache 100D thinks about it.

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: Friday, June 30, 2017 11:21 AM
To: WSJT software development ; George J 
Molnar 
Subject: Re: [wsjt-devel] FT8 - build 7752 and rig control

Hi George,

> Still feel like the way this is being implemented is counter-intuitive 
> for most operators. After your explanation, I get it. That said, I’ve 
> made 10,000 JT-mode QSOs and it never occurred to me when I saw this. 
> I think we might see a fair number of folks fall into the same 
> confusion that I felt. It’s made more difficult since it’s not 
> standardized across the platform.

The WSJT-X User Guide includes the following text in Section 4.2:

"Split Operation: Significant advantages result from using Split mode (separate 
VFOs for Rx and Tx) if your radio supports it. If it does not, WSJT-X can 
emulate such behavior. Either method will result in a cleaner transmitted 
signal, by keeping the Tx audio always in the range 1500 to
2000 Hz so that audio harmonics cannot pass through the Tx sideband filter. 
Select Rig to use the radio’s Split mode, or Fake It to have WSJT-X adjust the 
VFO frequency as needed, when T/R switching occurs. 
Choose None if you do not wish to use split operation."

I'm not sure what we could write that would be any more clear.

I have no idea what you mean by "it’s not standardized across the platform".

> Not sure what the solution is. For me, I will probably just build a 
> configuration that prevents split for FT8, since my Flex is pretty 
> flat across the passband and no audio card is involved.

Why do you need any "solution"?  Solution to what problem? For FT8, or for any 
other mode??

    -- 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 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] Unable to Access Configuration (F2) 7754

[Black Michael via wsjt-devel]

As of right now the function keys won't work menu's when the menu is disabled.
It should be possible to intercept the key and do it anyways.
Since I made the CTLR-M patch I'll take a look at still processing functions 
keys when menu is disabled.
de MIke W9MDB 

  From: Edfel Rivera 
 To: WSJT software development  
 Sent: Friday, June 30, 2017 1:56 PM
 Subject: Re: [wsjt-devel] Unable to Access Configuration (F2) 7754
   
Hi Joe:

CNTRl+M did the trick. However, Should F2 work even when MENU is disabled with 
CNTRL-M?  I just get confused when not able to access MENU.

Thanks again!

Edfel

On Fri, Jun 30, 2017 at 4:43 PM, Joe Taylor  wrote:

Hit F3 to see a list of keyboard shortcuts, and look at the entry for
CTRL+M.

On 6/30/2017 2:40 PM, Edfel Rivera wrote:

Hi:

I am not sure what I did but I am not able to access configuration.  Also, can 
not change band.  I tried building new but no fix.

Previously used 1.7.1 with out any problem.

Thanks.

Edfel
KP4AJ


-- -- --
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.n et
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.n et
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] FT8 - build 7752 and rig control

[Black Michael via wsjt-devel]

eQSL is unlikely to put FT8 or JT10 on until the ADIF specs are updated to 
reflect it.I've posted the request to the ADIF group.
de Mike W9MDB


  From: Gordon Higgins 
 To: WSJT software development  
 Sent: Friday, June 30, 2017 1:07 PM
 Subject: Re: [wsjt-devel] FT8 - build 7752 and rig control
   
have been using FT8 today on 20m  18 qso in log 14dxcc eqsl will not exept mode 
?
 like mode very quick no faults exept eqsl 

On 30 June 2017 at 18:55, Dan Malcolm  wrote:

FYI.  I just tried the “split” mode in WSJT-X for an FT8 QSO.  My Apache 100D 
seems to like it just fine. From: Black Michael via wsjt-devel 
[mailto:wsjt-devel@lists. sourceforge.net] 
Sent: Friday, June 30, 2017 12:04 PM
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] FT8 - build 7752 and rig control What if we just 
named that box "Audio Split Operation" and improve the tooltips? Tooltip on 
groupbox: Special split ops for cleaner audio -- see help fileTooltip on None: 
No splitTooltip on Rig:  Use rig split capabilityTooltip on FakeIt:Split occurs 
on VFOA during transmit  Might have to improve the help a bit to explain these 
things better. de Mike W9MDB From: George J Molnar 
To: WSJT software development  
Sent: Friday, June 30, 2017 11:40 AM
Subject: Re: [wsjt-devel] FT8 - build 7752 and rig control (Sorry Joe - posted 
this to you instead of the group - apologies for the double message) Hi Joe, I 
was just about to send an “amen” to Mike’s comments - he hit it on the head.  
The nut here seems to be with the use of the term “split.” It implies two 
different frequencies are being used for the contact. This threw me, and 
probably some others. We also use the “split” terminology to describe MSK144’s 
use of "CQ nnn” to indicate a true split between calling and operating 
frequency. That makes plenty of sense, but isn’t what we’re doing for FT8, for 
example.  As for “needing” a “solution.” it’s really neither a need, nor a 
solution. I don’t want to see my dial frequency move without explicit command 
by me. Personal preference, really. It’s not wrong either way, so technically 
doesn’t need a solution. Just a preference that I suspect others may share. 
Having CAT enabled for PTT and proper logging is very desirable, though, so I 
don’t want to disable it. BTW, the manual is an excellent guide. I fear that 
most don’t read it line by line, or even at all. We can’t count on the very 
clear text (and it is) making it to all users before they get frustrated or 
vent their feelings on-line. The more we can make intuitive and transparent, 
the better for everyone. /opinion George J MolnarNevada, USA
KF2T  @GJMolnar   -- -- 
--
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] Unable to Access Configuration (F2) 7754

[Edfel Rivera]

Hi Joe:

CNTRl+M did the trick. However, Should F2 work even when MENU is disabled
with CNTRL-M?  I just get confused when not able to access MENU.

Thanks again!

Edfel

On Fri, Jun 30, 2017 at 4:43 PM, Joe Taylor  wrote:

> Hit F3 to see a list of keyboard shortcuts, and look at the entry for
> CTRL+M.
>
>
> On 6/30/2017 2:40 PM, Edfel Rivera wrote:
>
>> Hi:
>>
>> I am not sure what I did but I am not able to access configuration.
>> Also, can not change band.  I tried building new but no fix.
>>
>> Previously used 1.7.1 with out any problem.
>>
>> Thanks.
>>
>> Edfel
>> KP4AJ
>>
>>
>> 
>> --
>> 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] Unable to Access Configuration (F2) 7754

[Joe Taylor]

Hit F3 to see a list of keyboard shortcuts, and look at the entry for
CTRL+M.

On 6/30/2017 2:40 PM, Edfel Rivera wrote:

Hi:

I am not sure what I did but I am not able to access configuration.  
Also, can not change band.  I tried building new but no fix.


Previously used 1.7.1 with out any problem.

Thanks.

Edfel
KP4AJ


--
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] Unable to Access Configuration (F2) 7754

[Edfel Rivera]

Hi:

I am not sure what I did but I am not able to access configuration.  Also,
can not change band.  I tried building new but no fix.

Previously used 1.7.1 with out any problem.

Thanks.

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

[wsjt-devel] FT8 *.wav files available

[Adrian Fabry]

Hi All,

 

FT8 working nice here, a big thanks to Joe and Steve.

I have collected about 150 FT8 wav files from 20m and 6m (tropo, MS, ES).
Some of them no decode, maybe useful to analyze.

S/N from -19 to +2dB.

 

https://www.dropbox.com/sh/busdna76pjavht7/AAAXLDcC1sOfarmeLWsMU5vBa?dl=0

 

 

73 Ady YO2NAA

 

  

 

--
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] Hamlib error

[Rune Berg]

Hello!

I am trying to connect my IC 7000 to the WSJT-X, but I only get the message:
"hamlib error: Communication bus error while getting current frequency"

Can you help?

I have downloaded the latest version of your program; v.1.7.0 r7405 and
I have Windows 10 on my computer. 

Hope you can help me, as I would love to use your program... 

Thanks in advance,

73s de LA5RPA, Rune
(Am subscribing to this list!!!)

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

[David Tiller]

Builds removed.

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



On Jun 30, 2017, at 1:06 PM, Joe Taylor  wrote:

> David, Jay, and others --
> 
> We have been through this here before.
> 
> Anyone is welcome to build WSJT-X from source code, and use the results on 
> the air.  But please DO NOT post your pre-built binaries for others to 
> download.  This causes needless support problems for us.  We have no way of 
> knowing exactly what you did.  And if all you post is some sort of binary, 
> you're violating our GPL license.
> 
> Soon enough, when desirable new features have been added to the program, we 
> build and post "release candidate" installation packages that everyone can 
> use.  Such a time is not far off.
> 
> In the meantime, please "build your own", or be patient.
> 
>   -- Joe, K1JT
> 
> On 6/30/2017 12:40 PM, Jay Hainline wrote:
>> Just some food for thought.
>> Some of these development builds could be compiled into a exe install
>> package once in a while and made available from the sourceforge site or
>> maybe a link from the WSJT home page or wsjtx.net for those who want to try
>> the new mode but are intimidated at installing JTSDK and building their own.
>> If you make it available from an "official" site, maybe it will discourage
>> 3rd party users of doing it on their own.
>> 73 Jay KA9CFD
>> -Original Message-
>> From: David Tiller [mailto:dtil...@captechconsulting.com]
>> Sent: June 30, 2017 14:57
>> To: WSJT software development 
>> Subject: Re: [wsjt-devel] FT8 notes
>> All,
>> Since Joe mentioned revision 7754, I unofficially built it for OSX 10.9+ and
>> uploaded it here:
>> https://drive.google.com/open?id=0B4DphHV_ItCZbjZDdmt2NnR2cHc
>> If you're a macOS user, I'll try to keep recent builds in the same directory
>> (if that's ok w/ Joe, et al, re: unofficial builds).
>> --
>> David Tiller
>> Sr. Architect/Lead Consultant | CapTech
>> (804) 304-0638 | dtil...@captechconsulting.com
>> On Jun 30, 2017, at 10:45 AM, Joe Taylor  wrote:
>>> Hi Steve,
>>> 
>>> Yes, 40 iterations for bp.
>>> 
>>> With norder=2 hardwired for everything I still get 574 good decodes.  So
>> at least in jt9.exe, with no attempt to move nfqso around, using norder=3
>> produces no more decodes.
>>> 
>>> Here are the timer results with norder=2:
>>> 
>>> Name Time  Frac dTime dFracCalls
>>> --
>>> jt933.832  1.00 0.691  0.021
>>>  read_wav   0.164  0.00 0.164  0.0027404
>>>  decft832.977  0.97 0.055  0.00  527
>>>   sync8 4.148  0.12 4.148  0.12  527
>>>   ft8b 28.773  0.85 0.090  0.00 2821
>>>bpd174   1.641  0.05 1.641  0.05 2821
>>>osd174  27.043  0.8027.043  0.80 2210
>>> --
>>>33.832  1.00
>>> 
>>> -- Joe
>>> 
>>> On 6/30/2017 10:34 AM, Steven Franke wrote:
 Joe,
 Were these results obtained with 40 iterations for bp and norder = 3 for
>> signals at or within 10 Hz of nfqso? If so, it might be interesting to see
>> how the numbers would change if you dropped back to norder=2 for all
>> signals.
 Steve
> On Jun 30, 2017, at 9:25 AM, Joe Taylor  wrote:
> 
> Hi all,
> 
> Thanks for a busy ~20 hours of many people testing FT8.  I now have
>> accumulated a directory with 527 *.wav files, each of which has at least one
>> visible FT8 signal.  The files were recorded at K1JT at either 14.079 or
>> 50.313 MHz.
> 
> Running the r7753 stand-alone slow-mode decoder jt9[.exe] on this
>> collection of files produces 574 valid decodes and 0 false decodes with
>> total execution time 39.8 s.  The average time to process a 15 s Rx sequence
>> on this machine (Core i7-6700 @ 3.4 GHz) is thus 39.8/527 = 0.076 s.  Not
>> bad!
> 
> Here's the detailed execution-time breakdown from timer.out:
> 
> Name Time  Frac dTime dFracCalls
> --
> jt939.828  1.00 0.734  0.021
>  read_wav   0.121  0.00 0.121  0.0027404
>  decft838.973  0.98 0.133  0.00  527
>   sync8 4.191  0.11 4.191  0.11  527
>   ft8b 34.648  0.87 0.051  0.00 2821
>bpd174   1.480  0.04 1.480  0.04 2821
>osd174  33.117  0.8333.117  0.83 2210
> --
>39.828  1.00
> 
> Note that 83% of the execution time is spent in routine osd174, 11% in
>> sync8, and 4% in bpd174 (a contraction for subroutine name bpdecode174).
> 
> It turns out that only 14 of the 574 decode

[wsjt-devel] Keyboard Shortcut for TX EVEN/1ST

[John Roberts]

Hi,

 

Will you please consider adding two keyboard shortcuts to set the "Tx
even/1st" checkbox? Please don't make a single shortcut that toggles the
checkbox. Instead make one for explicitly setting "even" or "1st/odd".

 

Thank you,
John

 

 

 

--
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 - build 7752 and rig control

[Gordon Higgins]

have been using FT8 today on 20m  18 qso in log 14dxcc eqsl will not exept
mode ?
 like mode very quick no faults exept eqsl

On 30 June 2017 at 18:55, Dan Malcolm  wrote:

> FYI.  I just tried the “split” mode in WSJT-X for an FT8 QSO.  My Apache
> 100D seems to like it just fine.
>
>
>
> *From:* Black Michael via wsjt-devel [mailto:wsjt-devel@lists.
> sourceforge.net]
> *Sent:* Friday, June 30, 2017 12:04 PM
> *To:* WSJT software development 
> *Cc:* Black Michael 
>
> *Subject:* Re: [wsjt-devel] FT8 - build 7752 and rig control
>
>
>
> What if we just named that box "Audio Split Operation" and improve the
> tooltips?
>
>
>
> Tooltip on groupbox: Special split ops for cleaner audio -- see help file
>
> Tooltip on None: No split
>
> Tooltip on Rig:  Use rig split capability
>
> Tooltip on FakeIt:Split occurs on VFOA during transmit
>
>
>
> Might have to improve the help a bit to explain these things better.
>
>
>
> de Mike W9MDB
>
>
> --
>
> *From:* George J Molnar 
> *To:* WSJT software development 
> *Sent:* Friday, June 30, 2017 11:40 AM
> *Subject:* Re: [wsjt-devel] FT8 - build 7752 and rig control
>
>
>
> (Sorry Joe - posted this to you instead of the group - apologies for the
> double message)
>
>
>
> Hi Joe,
>
>
>
> I was just about to send an “amen” to Mike’s comments - he hit it on the
> head.
>
>
>
> The nut here seems to be with the use of the term “split.” It implies two
> different frequencies are being used for the contact. This threw me, and
> probably some others.
>
>
>
> We also use the “split” terminology to describe MSK144’s use of "CQ nnn”
> to indicate a true split between calling and operating frequency. That
> makes plenty of sense, but isn’t what we’re doing for FT8, for example.
>
>
>
> As for “needing” a “solution.” it’s really neither a need, nor a solution.
> I don’t want to see my dial frequency move without explicit command by me.
> Personal preference, really. It’s not wrong either way, so technically
> doesn’t need a solution. Just a preference that I suspect others may share.
> Having CAT enabled for PTT and proper logging is very desirable, though, so
> I don’t want to disable it.
>
>
>
> BTW, the manual is an excellent guide. I fear that most don’t read it line
> by line, or even at all. We can’t count on the very clear text (and it is)
> making it to all users before they get frustrated or vent their feelings
> on-line. The more we can make intuitive and transparent, the better for
> everyone.
>
>
>
> /opinion
>
>
>
> *George J Molnar*
>
> Nevada, USA
> KF2T  @GJMolnar
>
>
>
>
>
>
>
> 
> --
> 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] FT8 - build 7752 and rig control

[Dan Malcolm]

FYI.  I just tried the “split” mode in WSJT-X for an FT8 QSO.  My Apache 100D 
seems to like it just fine.

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Friday, June 30, 2017 12:04 PM
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] FT8 - build 7752 and rig control

 

What if we just named that box "Audio Split Operation" and improve the tooltips?

 

Tooltip on groupbox: Special split ops for cleaner audio -- see help file

Tooltip on None: No split

Tooltip on Rig:  Use rig split capability

Tooltip on FakeIt:Split occurs on VFOA during transmit 

 

Might have to improve the help a bit to explain these things better.

 

de Mike W9MDB

 

  _  

From: George J Molnar mailto:geo...@molnar.com> >
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> > 
Sent: Friday, June 30, 2017 11:40 AM
Subject: Re: [wsjt-devel] FT8 - build 7752 and rig control

 

(Sorry Joe - posted this to you instead of the group - apologies for the double 
message)

 

Hi Joe,

 

I was just about to send an “amen” to Mike’s comments - he hit it on the head. 

 

The nut here seems to be with the use of the term “split.” It implies two 
different frequencies are being used for the contact. This threw me, and 
probably some others.

 

We also use the “split” terminology to describe MSK144’s use of "CQ nnn” to 
indicate a true split between calling and operating frequency. That makes 
plenty of sense, but isn’t what we’re doing for FT8, for example. 

 

As for “needing” a “solution.” it’s really neither a need, nor a solution. I 
don’t want to see my dial frequency move without explicit command by me. 
Personal preference, really. It’s not wrong either way, so technically doesn’t 
need a solution. Just a preference that I suspect others may share. Having CAT 
enabled for PTT and proper logging is very desirable, though, so I don’t want 
to disable it.

 

BTW, the manual is an excellent guide. I fear that most don’t read it line by 
line, or even at all. We can’t count on the very clear text (and it is) making 
it to all users before they get frustrated or vent their feelings on-line. The 
more we can make intuitive and transparent, the better for everyone.

 

/opinion

 

George J Molnar

Nevada, USA
KF2T  @GJMolnar

 

 

 

--
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 - build 7752 and rig control

[Dan Malcolm]

I'd like to weigh in on the "what to call it" discussion.  Not that I have 
anything really better, but since we already have a well understood "split 
mode", called this a split confuses one function with another.  Can we say 
something like "Audio Purity Offset"?

I have not used it before I'm willing to give it a try.  I let you know what my 
Apache 100D thinks about it.

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: Friday, June 30, 2017 11:21 AM
To: WSJT software development ; George J 
Molnar 
Subject: Re: [wsjt-devel] FT8 - build 7752 and rig control

Hi George,

> Still feel like the way this is being implemented is counter-intuitive 
> for most operators. After your explanation, I get it. That said, I’ve 
> made 10,000 JT-mode QSOs and it never occurred to me when I saw this. 
> I think we might see a fair number of folks fall into the same 
> confusion that I felt. It’s made more difficult since it’s not 
> standardized across the platform.

The WSJT-X User Guide includes the following text in Section 4.2:

"Split Operation: Significant advantages result from using Split mode (separate 
VFOs for Rx and Tx) if your radio supports it. If it does not, WSJT-X can 
emulate such behavior. Either method will result in a cleaner transmitted 
signal, by keeping the Tx audio always in the range 1500 to
2000 Hz so that audio harmonics cannot pass through the Tx sideband filter. 
Select Rig to use the radio’s Split mode, or Fake It to have WSJT-X adjust the 
VFO frequency as needed, when T/R switching occurs. 
Choose None if you do not wish to use split operation."

I'm not sure what we could write that would be any more clear.

I have no idea what you mean by "it’s not standardized across the platform".

> Not sure what the solution is. For me, I will probably just build a 
> configuration that prevents split for FT8, since my Flex is pretty 
> flat across the passband and no audio card is involved.

Why do you need any "solution"?  Solution to what problem? For FT8, or for any 
other mode??

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

[Joe Taylor]

David, Jay, and others --

We have been through this here before.

Anyone is welcome to build WSJT-X from source code, and use the results 
on the air.  But please DO NOT post your pre-built binaries for others 
to download.  This causes needless support problems for us.  We have no 
way of knowing exactly what you did.  And if all you post is some sort 
of binary, you're violating our GPL license.


Soon enough, when desirable new features have been added to the program, 
we build and post "release candidate" installation packages that 
everyone can use.  Such a time is not far off.


In the meantime, please "build your own", or be patient.

-- Joe, K1JT

On 6/30/2017 12:40 PM, Jay Hainline wrote:

Just some food for thought.

Some of these development builds could be compiled into a exe install
package once in a while and made available from the sourceforge site or
maybe a link from the WSJT home page or wsjtx.net for those who want to try
the new mode but are intimidated at installing JTSDK and building their own.
If you make it available from an "official" site, maybe it will discourage
3rd party users of doing it on their own.

73 Jay KA9CFD

-Original Message-
From: David Tiller [mailto:dtil...@captechconsulting.com]
Sent: June 30, 2017 14:57
To: WSJT software development 
Subject: Re: [wsjt-devel] FT8 notes

All,

Since Joe mentioned revision 7754, I unofficially built it for OSX 10.9+ and
uploaded it here:
https://drive.google.com/open?id=0B4DphHV_ItCZbjZDdmt2NnR2cHc

If you're a macOS user, I'll try to keep recent builds in the same directory
(if that's ok w/ Joe, et al, re: unofficial builds).

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



On Jun 30, 2017, at 10:45 AM, Joe Taylor  wrote:


Hi Steve,

Yes, 40 iterations for bp.

With norder=2 hardwired for everything I still get 574 good decodes.  So

at least in jt9.exe, with no attempt to move nfqso around, using norder=3
produces no more decodes.


Here are the timer results with norder=2:

Name Time  Frac dTime dFracCalls
--
jt933.832  1.00 0.691  0.021
  read_wav   0.164  0.00 0.164  0.0027404
  decft832.977  0.97 0.055  0.00  527
   sync8 4.148  0.12 4.148  0.12  527
   ft8b 28.773  0.85 0.090  0.00 2821
bpd174   1.641  0.05 1.641  0.05 2821
osd174  27.043  0.8027.043  0.80 2210
--
33.832  1.00

-- Joe

On 6/30/2017 10:34 AM, Steven Franke wrote:

Joe,
Were these results obtained with 40 iterations for bp and norder = 3 for

signals at or within 10 Hz of nfqso? If so, it might be interesting to see
how the numbers would change if you dropped back to norder=2 for all
signals.

Steve

On Jun 30, 2017, at 9:25 AM, Joe Taylor  wrote:

Hi all,

Thanks for a busy ~20 hours of many people testing FT8.  I now have

accumulated a directory with 527 *.wav files, each of which has at least one
visible FT8 signal.  The files were recorded at K1JT at either 14.079 or
50.313 MHz.


Running the r7753 stand-alone slow-mode decoder jt9[.exe] on this

collection of files produces 574 valid decodes and 0 false decodes with
total execution time 39.8 s.  The average time to process a 15 s Rx sequence
on this machine (Core i7-6700 @ 3.4 GHz) is thus 39.8/527 = 0.076 s.  Not
bad!


Here's the detailed execution-time breakdown from timer.out:

Name Time  Frac dTime dFracCalls
--
jt939.828  1.00 0.734  0.021
  read_wav   0.121  0.00 0.121  0.0027404
  decft838.973  0.98 0.133  0.00  527
   sync8 4.191  0.11 4.191  0.11  527
   ft8b 34.648  0.87 0.051  0.00 2821
bpd174   1.480  0.04 1.480  0.04 2821
osd174  33.117  0.8333.117  0.83 2210
--
39.828  1.00

Note that 83% of the execution time is spent in routine osd174, 11% in

sync8, and 4% in bpd174 (a contraction for subroutine name bpdecode174).


It turns out that only 14 of the 574 decodes were produced by osd174,

the "ordered statistics" decoder.  The rest came from bpd174.  With osd174
deactivated, timer.out looks like this:


Name Time  Frac dTime dFracCalls
--
jt9 6.641  1.00 0.891  0.131
  read_wav   0.168  0.03 0.168  0.0327404
  decft8 5.582  0.84 0.094  0.01  527
   sync8 3.887  0.59 3.887  0.59  527
   ft8b  1.602  0.24 0

Re: [wsjt-devel] FT8 - build 7752 and rig control

[Black Michael via wsjt-devel]

What if we just named that box "Audio Split Operation" and improve the tooltips?
Tooltip on groupbox: Special split ops for cleaner audio -- see help 
fileTooltip on None: No splitTooltip on Rig:  Use rig split capabilityTooltip 
on FakeIt:Split occurs on VFOA during transmit 
Might have to improve the help a bit to explain these things better.
de Mike W9MDB

  From: George J Molnar 
 To: WSJT software development  
 Sent: Friday, June 30, 2017 11:40 AM
 Subject: Re: [wsjt-devel] FT8 - build 7752 and rig control
   
(Sorry Joe - posted this to you instead of the group - apologies for the double 
message)
Hi Joe,
I was just about to send an “amen” to Mike’s comments - he hit it on the head. 
The nut here seems to be with the use of the term “split.” It implies two 
different frequencies are being used for the contact. This threw me, and 
probably some others.
We also use the “split” terminology to describe MSK144’s use of "CQ nnn” to 
indicate a true split between calling and operating frequency. That makes 
plenty of sense, but isn’t what we’re doing for FT8, for example. 
As for “needing” a “solution.” it’s really neither a need, nor a solution. I 
don’t want to see my dial frequency move without explicit command by me. 
Personal preference, really. It’s not wrong either way, so technically doesn’t 
need a solution. Just a preference that I suspect others may share. Having CAT 
enabled for PTT and proper logging is very desirable, though, so I don’t want 
to disable it.
BTW, the manual is an excellent guide. I fear that most don’t read it line by 
line, or even at all. We can’t count on the very clear text (and it is) making 
it to all users before they get frustrated or vent their feelings on-line. The 
more we can make intuitive and transparent, the better for everyone.
/opinion
George J MolnarNevada, USA
KF2T  @GJMolnar



--
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 - build 7752 and rig control

[Joe Taylor]

Hi George,

On 6/30/2017 12:38 PM, George J Molnar wrote:
The nut here seems to be with the use of the term “split.” It implies 
two different frequencies are being used for the contact. This threw me, 
and probably some others.


Yes, I understood what you took to be the meaning of "split".

The quoted text from the User Guide clearly states how "split" is being 
used there, and it does not mean two different frequencies are being 
used for the contact.


We also use the “split” terminology to describe MSK144’s use of "CQ nnn” 
to indicate a true split between calling and operating frequency. That 
makes plenty of sense, but isn’t what we’re doing for FT8, for example.


As for “needing” a “solution.” it’s really neither a need, nor a 
solution. I don’t want to see my dial frequency move without explicit 
command by me. 


Then set "Split operation" to "None".

-- Joe, K1JT

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

Re: [wsjt-devel] FT8 notes

[Jay Hainline]

Just some food for thought. 

Some of these development builds could be compiled into a exe install
package once in a while and made available from the sourceforge site or
maybe a link from the WSJT home page or wsjtx.net for those who want to try
the new mode but are intimidated at installing JTSDK and building their own.
If you make it available from an "official" site, maybe it will discourage
3rd party users of doing it on their own.

73 Jay KA9CFD

-Original Message-
From: David Tiller [mailto:dtil...@captechconsulting.com] 
Sent: June 30, 2017 14:57
To: WSJT software development 
Subject: Re: [wsjt-devel] FT8 notes

All,

Since Joe mentioned revision 7754, I unofficially built it for OSX 10.9+ and
uploaded it here:
https://drive.google.com/open?id=0B4DphHV_ItCZbjZDdmt2NnR2cHc

If you're a macOS user, I'll try to keep recent builds in the same directory
(if that's ok w/ Joe, et al, re: unofficial builds).

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



On Jun 30, 2017, at 10:45 AM, Joe Taylor  wrote:

> Hi Steve,
> 
> Yes, 40 iterations for bp.
> 
> With norder=2 hardwired for everything I still get 574 good decodes.  So
at least in jt9.exe, with no attempt to move nfqso around, using norder=3
produces no more decodes.
> 
> Here are the timer results with norder=2:
> 
> Name Time  Frac dTime dFracCalls
> --
> jt933.832  1.00 0.691  0.021
>  read_wav   0.164  0.00 0.164  0.0027404
>  decft832.977  0.97 0.055  0.00  527
>   sync8 4.148  0.12 4.148  0.12  527
>   ft8b 28.773  0.85 0.090  0.00 2821
>bpd174   1.641  0.05 1.641  0.05 2821
>osd174  27.043  0.8027.043  0.80 2210
> --
>33.832  1.00
> 
>   -- Joe
> 
> On 6/30/2017 10:34 AM, Steven Franke wrote:
>> Joe,
>> Were these results obtained with 40 iterations for bp and norder = 3 for
signals at or within 10 Hz of nfqso? If so, it might be interesting to see
how the numbers would change if you dropped back to norder=2 for all
signals.
>> Steve
>>> On Jun 30, 2017, at 9:25 AM, Joe Taylor  wrote:
>>> 
>>> Hi all,
>>> 
>>> Thanks for a busy ~20 hours of many people testing FT8.  I now have
accumulated a directory with 527 *.wav files, each of which has at least one
visible FT8 signal.  The files were recorded at K1JT at either 14.079 or
50.313 MHz.
>>> 
>>> Running the r7753 stand-alone slow-mode decoder jt9[.exe] on this
collection of files produces 574 valid decodes and 0 false decodes with
total execution time 39.8 s.  The average time to process a 15 s Rx sequence
on this machine (Core i7-6700 @ 3.4 GHz) is thus 39.8/527 = 0.076 s.  Not
bad!
>>> 
>>> Here's the detailed execution-time breakdown from timer.out:
>>> 
>>> Name Time  Frac dTime dFracCalls
>>> --
>>> jt939.828  1.00 0.734  0.021
>>>  read_wav   0.121  0.00 0.121  0.0027404
>>>  decft838.973  0.98 0.133  0.00  527
>>>   sync8 4.191  0.11 4.191  0.11  527
>>>   ft8b 34.648  0.87 0.051  0.00 2821
>>>bpd174   1.480  0.04 1.480  0.04 2821
>>>osd174  33.117  0.8333.117  0.83 2210
>>> --
>>>39.828  1.00
>>> 
>>> Note that 83% of the execution time is spent in routine osd174, 11% in
sync8, and 4% in bpd174 (a contraction for subroutine name bpdecode174).
>>> 
>>> It turns out that only 14 of the 574 decodes were produced by osd174,
the "ordered statistics" decoder.  The rest came from bpd174.  With osd174
deactivated, timer.out looks like this:
>>> 
>>> Name Time  Frac dTime dFracCalls
>>> --
>>> jt9 6.641  1.00 0.891  0.131
>>>  read_wav   0.168  0.03 0.168  0.0327404
>>>  decft8 5.582  0.84 0.094  0.01  527
>>>   sync8 3.887  0.59 3.887  0.59  527
>>>   ft8b  1.602  0.24 0.109  0.02 2821
>>>bpd174   1.492  0.22 1.492  0.22 2821
>>>osd174   0.000  0.00 0.000  0.00 2210
>>> --
>>> 6.641  1.00
>>> 
>>> Now the average execution time for a 15 s Rx sequence is just 13 ms!
>>> 
>>> We need to keep decoding time very short -- say, well under 1 s -- so
that auto-sequencing, if not the human operator, can select proper responses
to received messages.  Fortunately, we already have good baseline
performance

Re: [wsjt-devel] FT8 - build 7752 and rig control

[George J Molnar]

(Sorry Joe - posted this to you instead of the group - apologies for the double 
message)

Hi Joe,

I was just about to send an “amen” to Mike’s comments - he hit it on the head. 

The nut here seems to be with the use of the term “split.” It implies two 
different frequencies are being used for the contact. This threw me, and 
probably some others.

We also use the “split” terminology to describe MSK144’s use of "CQ nnn” to 
indicate a true split between calling and operating frequency. That makes 
plenty of sense, but isn’t what we’re doing for FT8, for example. 

As for “needing” a “solution.” it’s really neither a need, nor a solution. I 
don’t want to see my dial frequency move without explicit command by me. 
Personal preference, really. It’s not wrong either way, so technically doesn’t 
need a solution. Just a preference that I suspect others may share. Having CAT 
enabled for PTT and proper logging is very desirable, though, so I don’t want 
to disable it.

BTW, the manual is an excellent guide. I fear that most don’t read it line by 
line, or even at all. We can’t count on the very clear text (and it is) making 
it to all users before they get frustrated or vent their feelings on-line. The 
more we can make intuitive and transparent, the better for everyone.

/opinion

George J Molnar
Nevada, USA
KF2T  @GJMolnar




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

[David Tiller]

All,

Since Joe mentioned revision 7754, I unofficially built it for OSX 10.9+ and 
uploaded it here: https://drive.google.com/open?id=0B4DphHV_ItCZbjZDdmt2NnR2cHc

If you're a macOS user, I'll try to keep recent builds in the same directory 
(if that's ok w/ Joe, et al, re: unofficial builds).

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



On Jun 30, 2017, at 10:45 AM, Joe Taylor  wrote:

> Hi Steve,
> 
> Yes, 40 iterations for bp.
> 
> With norder=2 hardwired for everything I still get 574 good decodes.  So at 
> least in jt9.exe, with no attempt to move nfqso around, using norder=3 
> produces no more decodes.
> 
> Here are the timer results with norder=2:
> 
> Name Time  Frac dTime dFracCalls
> --
> jt933.832  1.00 0.691  0.021
>  read_wav   0.164  0.00 0.164  0.0027404
>  decft832.977  0.97 0.055  0.00  527
>   sync8 4.148  0.12 4.148  0.12  527
>   ft8b 28.773  0.85 0.090  0.00 2821
>bpd174   1.641  0.05 1.641  0.05 2821
>osd174  27.043  0.8027.043  0.80 2210
> --
>33.832  1.00
> 
>   -- Joe
> 
> On 6/30/2017 10:34 AM, Steven Franke wrote:
>> Joe,
>> Were these results obtained with 40 iterations for bp and norder = 3 for 
>> signals at or within 10 Hz of nfqso? If so, it might be interesting to see 
>> how the numbers would change if you dropped back to norder=2 for all signals.
>> Steve
>>> On Jun 30, 2017, at 9:25 AM, Joe Taylor  wrote:
>>> 
>>> Hi all,
>>> 
>>> Thanks for a busy ~20 hours of many people testing FT8.  I now have 
>>> accumulated a directory with 527 *.wav files, each of which has at least 
>>> one visible FT8 signal.  The files were recorded at K1JT at either 14.079 
>>> or 50.313 MHz.
>>> 
>>> Running the r7753 stand-alone slow-mode decoder jt9[.exe] on this 
>>> collection of files produces 574 valid decodes and 0 false decodes with 
>>> total execution time 39.8 s.  The average time to process a 15 s Rx 
>>> sequence on this machine (Core i7-6700 @ 3.4 GHz) is thus 39.8/527 = 0.076 
>>> s.  Not bad!
>>> 
>>> Here's the detailed execution-time breakdown from timer.out:
>>> 
>>> Name Time  Frac dTime dFracCalls
>>> --
>>> jt939.828  1.00 0.734  0.021
>>>  read_wav   0.121  0.00 0.121  0.0027404
>>>  decft838.973  0.98 0.133  0.00  527
>>>   sync8 4.191  0.11 4.191  0.11  527
>>>   ft8b 34.648  0.87 0.051  0.00 2821
>>>bpd174   1.480  0.04 1.480  0.04 2821
>>>osd174  33.117  0.8333.117  0.83 2210
>>> --
>>>39.828  1.00
>>> 
>>> Note that 83% of the execution time is spent in routine osd174, 11% in 
>>> sync8, and 4% in bpd174 (a contraction for subroutine name bpdecode174).
>>> 
>>> It turns out that only 14 of the 574 decodes were produced by osd174, the 
>>> "ordered statistics" decoder.  The rest came from bpd174.  With osd174 
>>> deactivated, timer.out looks like this:
>>> 
>>> Name Time  Frac dTime dFracCalls
>>> --
>>> jt9 6.641  1.00 0.891  0.131
>>>  read_wav   0.168  0.03 0.168  0.0327404
>>>  decft8 5.582  0.84 0.094  0.01  527
>>>   sync8 3.887  0.59 3.887  0.59  527
>>>   ft8b  1.602  0.24 0.109  0.02 2821
>>>bpd174   1.492  0.22 1.492  0.22 2821
>>>osd174   0.000  0.00 0.000  0.00 2210
>>> --
>>> 6.641  1.00
>>> 
>>> Now the average execution time for a 15 s Rx sequence is just 13 ms!
>>> 
>>> We need to keep decoding time very short -- say, well under 1 s -- so that 
>>> auto-sequencing, if not the human operator, can select proper responses to 
>>> received messages.  Fortunately, we already have good baseline performance 
>>> -- and we have a number of "knobs" to play with.
>>> 
>>> -- Joe, K1JT
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> --
>>

Re: [wsjt-devel] FT8 - build 7752 and rig control

[Black Michael via wsjt-devel]

What rig are you having split problems with?I'm always interested in fixing 
hamlib problems like that.
de Mike W9MDB

  From: Jordan Sherer 
 To: WSJT software development  
 Sent: Friday, June 30, 2017 11:30 AM
 Subject: Re: [wsjt-devel] FT8 - build 7752 and rig control
   
Thanks Bill, 
Yep. This was the issue. It looks like my rig doesn't like custom offsets for 
split mode over CAT. Haven't researched it much yet. But, swapping over to 
"Fake It" worked like a charm, no issue.
Thanks again!
Best,JordanKN4CRD
On Fri, Jun 30, 2017 at 10:45 AM, Bill Somerville  wrote:

On 30/06/2017 15:37, Jordan Sherer wrote:

Jumping in here since it's sort of relevant to the discussion.

One oddity I found this morning while operating split:

0. I load up WSJTX on 20m
1. I have enabled FT8 mode with rig ctl split
2. VFO is at 14.079.000, transmit offset at 800Hz
3. Tx cycle correctly adjusts split to 14.078.500
4. I move to JT65 on 20m
5. VFO is at 14.076.000, transmit offset at 800Hz
6. Tx cycle incorrectly adjusted the VFO split frequency to 14.078.500 (as if 
it was still in FT8 mode)

I'm assuming this is probably a just small bug with the split offset not 
resetting when switching from FT8 to JT65 in this build. Are you, or anybody 
else able to reproduce?


Hi Jordan,

if your Tx DF is 800Hz then your Tx VFO should be at 1kHz below the Rx VFO, 
i.e. in this case .078 . If that is not happening then you may have an issue 
with your CAT interfacing. Please check the adjustment of your Tx VFO by 
CTRL+clicking on the waterfall within each visible 500Hz section.

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.n et
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] qra64 indent patch

[Black Michael via wsjt-devel]

More recent gcc versions now detect indentation inconsistencies.
A minor fix for qra64.c

https://www.dropbox.com/s/n67v5kg1tltj1fv/qra64_patch.txt?dl=1


I'd recommend developers get into the habit of ALWAYS adding bracesI found 
one error in hamlib due to this and this patch "fixes" what is really a 
non-problem in qra64.c but was unintended flow logic.
Nate recently updated the astylrc in hamlib/scripts to automagically add braces 
if anybody is interested in doing this once-and-for-all.

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

Re: [wsjt-devel] FT8 - build 7752 and rig control

[Jordan Sherer]

Thanks Bill,

Yep. This was the issue. It looks like my rig doesn't like custom offsets
for split mode over CAT. Haven't researched it much yet. But, swapping over
to "Fake It" worked like a charm, no issue.

Thanks again!

Best,
Jordan
KN4CRD

On Fri, Jun 30, 2017 at 10:45 AM, Bill Somerville 
wrote:

> On 30/06/2017 15:37, Jordan Sherer wrote:
>
>> Jumping in here since it's sort of relevant to the discussion.
>>
>> One oddity I found this morning while operating split:
>>
>> 0. I load up WSJTX on 20m
>> 1. I have enabled FT8 mode with rig ctl split
>> 2. VFO is at 14.079.000, transmit offset at 800Hz
>> 3. Tx cycle correctly adjusts split to 14.078.500
>> 4. I move to JT65 on 20m
>> 5. VFO is at 14.076.000, transmit offset at 800Hz
>> 6. Tx cycle incorrectly adjusted the VFO split frequency to 14.078.500
>> (as if it was still in FT8 mode)
>>
>> I'm assuming this is probably a just small bug with the split offset not
>> resetting when switching from FT8 to JT65 in this build. Are you, or
>> anybody else able to reproduce?
>>
>> Hi Jordan,
>
> if your Tx DF is 800Hz then your Tx VFO should be at 1kHz below the Rx
> VFO, i.e. in this case .078 . If that is not happening then you may have an
> issue with your CAT interfacing. Please check the adjustment of your Tx VFO
> by CTRL+clicking on the waterfall within each visible 500Hz section.
>
> 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] FT8 - build 7752 and rig control

[Joe Taylor]

Hi George,

Still feel like the way this is being implemented is counter-intuitive 
for most operators. After your explanation, I get it. That said, I’ve 
made 10,000 JT-mode QSOs and it never occurred to me when I saw this. I 
think we might see a fair number of folks fall into the same confusion 
that I felt. It’s made more difficult since it’s not standardized across 
the platform.


The WSJT-X User Guide includes the following text in Section 4.2:

"Split Operation: Significant advantages result from using Split mode 
(separate VFOs for Rx and Tx) if your radio supports it. If it does not, 
WSJT-X can emulate such behavior. Either method will result in a cleaner 
transmitted signal, by keeping the Tx audio always in the range 1500 to 
2000 Hz so that audio harmonics cannot pass through the Tx sideband 
filter. Select Rig to use the radio’s Split mode, or Fake It to have 
WSJT-X adjust the VFO frequency as needed, when T/R switching occurs. 
Choose None if you do not wish to use split operation."


I'm not sure what we could write that would be any more clear.

I have no idea what you mean by "it’s not standardized across the platform".

Not sure what the solution is. For me, I will probably just build a 
configuration that prevents split for FT8, since my Flex is pretty flat 
across the passband and no audio card is involved.


Why do you need any "solution"?  Solution to what problem? For FT8, or 
for any other mode??


-- Joe, K1JT

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

Re: [wsjt-devel] FT8 - build 7752 and rig control

[Black Michael via wsjt-devel]

Can you can think of a better thing to call it?  I agree that for newbies it's 
not intuitive as there have been quite a few who have questioned what it's for.
Did you read the help and find it inadequate?  We either need to name it 
something other than split (maybe call it purity or some such thing) or improve 
the help file.   Problem with the help file is too many don't read it.So naming 
it something different might improved things.
The one confusing thing would be that it does put your rig in split mode (for 
most rigs).  So that would probably prompt a bunch more questions.
de Mike W9MDB


  From: George J Molnar 
 To: WSJT software development  
 Sent: Friday, June 30, 2017 11:09 AM
 Subject: Re: [wsjt-devel] FT8 - build 7752 and rig control
   
Thanks, Mike and Bill, for the clarification.
Still feel like the way this is being implemented is counter-intuitive for most 
operators. After your explanation, I get it. That said, I’ve made 10,000 
JT-mode QSOs and it never occurred to me when I saw this. I think we might see 
a fair number of folks fall into the same confusion that I felt. It’s made more 
difficult since it’s not standardized across the platform. 

Not sure what the solution is. For me, I will probably just build a 
configuration that prevents split for FT8, since my Flex is pretty flat across 
the passband and no audio card is involved. 
George J MolnarNevada, USA
KF2T  @GJMolnar




--
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 - build 7752 and rig control

[Charles Suckling]

Hi George

 

Simple solution here is to select rig as 'none' and tune manually.  

 

Just had my first QSO on 20m.  All looks very good.

 

73

 

Charlie

 

  _  

From: George J Molnar [mailto:geo...@molnar.com] 
Sent: 30 June 2017 17:08
To: WSJT software development
Subject: Re: [wsjt-devel] FT8 - build 7752 and rig control

 

Thanks, Mike and Bill, for the clarification.

 

Still feel like the way this is being implemented is counter-intuitive for
most operators. After your explanation, I get it. That said, I've made
10,000 JT-mode QSOs and it never occurred to me when I saw this. I think we
might see a fair number of folks fall into the same confusion that I felt.
It's made more difficult since it's not standardized across the platform. 

 

 

Not sure what the solution is. For me, I will probably just build a
configuration that prevents split for FT8, since my Flex is pretty flat
across the passband and no audio card is involved. 

 

George J Molnar

Nevada, USA
KF2T  @GJMolnar

 

 

 

 

--
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 - build 7752 and rig control

[George J Molnar]

Thanks, Mike and Bill, for the clarification.

Still feel like the way this is being implemented is counter-intuitive for most 
operators. After your explanation, I get it. That said, I’ve made 10,000 
JT-mode QSOs and it never occurred to me when I saw this. I think we might see 
a fair number of folks fall into the same confusion that I felt. It’s made more 
difficult since it’s not standardized across the platform. 


Not sure what the solution is. For me, I will probably just build a 
configuration that prevents split for FT8, since my Flex is pretty flat across 
the passband and no audio card is involved. 

George J Molnar
Nevada, USA
KF2T  @GJMolnar





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

[wsjt-devel] FT8 to Pskreporter

[Alessandro Gorobey via wsjt-devel]

Hi all,

tomorrow I try RX in the new mode and seem to be simple fantastic!!
I do some local QSO for practice on autosequence.

If try to search in pskreporter all QSO in 24h on any band any callsign 
mode=FT8 it report only 1 QSO.


Is this wanted?

Thank you all for the new gift 

--
73
Sandro
IW3RAB

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

[Steven Franke]

Joe,

OK. 

osd can only be successful if it is given candidates. I’m noticing now that the 
current sync threshold is high enough where bp probably doesn’t fail all that 
often. In any case, more candidates fed to osd would only increase the fraction 
of time spent in that routine. It doesn’t seem likely that osd is going to be 
able to pull it’s weight. I’m fine if you want to just remove the call to osd 
all together, at least for now.

Steve


> On Jun 30, 2017, at 9:45 AM, Joe Taylor  wrote:
> 
> Hi Steve,
> 
> Yes, 40 iterations for bp.
> 
> With norder=2 hardwired for everything I still get 574 good decodes.  So at 
> least in jt9.exe, with no attempt to move nfqso around, using norder=3 
> produces no more decodes.
> 
> Here are the timer results with norder=2:
> 
> Name Time  Frac dTime dFracCalls
> --
> jt933.832  1.00 0.691  0.021
>  read_wav   0.164  0.00 0.164  0.0027404
>  decft832.977  0.97 0.055  0.00  527
>   sync8 4.148  0.12 4.148  0.12  527
>   ft8b 28.773  0.85 0.090  0.00 2821
>bpd174   1.641  0.05 1.641  0.05 2821
>osd174  27.043  0.8027.043  0.80 2210
> --
>33.832  1.00
> 
>   -- Joe
> 
> On 6/30/2017 10:34 AM, Steven Franke wrote:
>> Joe,
>> Were these results obtained with 40 iterations for bp and norder = 3 for 
>> signals at or within 10 Hz of nfqso? If so, it might be interesting to see 
>> how the numbers would change if you dropped back to norder=2 for all signals.
>> Steve
>>> On Jun 30, 2017, at 9:25 AM, Joe Taylor  wrote:
>>> 
>>> Hi all,
>>> 
>>> Thanks for a busy ~20 hours of many people testing FT8.  I now have 
>>> accumulated a directory with 527 *.wav files, each of which has at least 
>>> one visible FT8 signal.  The files were recorded at K1JT at either 14.079 
>>> or 50.313 MHz.
>>> 
>>> Running the r7753 stand-alone slow-mode decoder jt9[.exe] on this 
>>> collection of files produces 574 valid decodes and 0 false decodes with 
>>> total execution time 39.8 s.  The average time to process a 15 s Rx 
>>> sequence on this machine (Core i7-6700 @ 3.4 GHz) is thus 39.8/527 = 0.076 
>>> s.  Not bad!
>>> 
>>> Here's the detailed execution-time breakdown from timer.out:
>>> 
>>> Name Time  Frac dTime dFracCalls
>>> --
>>> jt939.828  1.00 0.734  0.021
>>>  read_wav   0.121  0.00 0.121  0.0027404
>>>  decft838.973  0.98 0.133  0.00  527
>>>   sync8 4.191  0.11 4.191  0.11  527
>>>   ft8b 34.648  0.87 0.051  0.00 2821
>>>bpd174   1.480  0.04 1.480  0.04 2821
>>>osd174  33.117  0.8333.117  0.83 2210
>>> --
>>>39.828  1.00
>>> 
>>> Note that 83% of the execution time is spent in routine osd174, 11% in 
>>> sync8, and 4% in bpd174 (a contraction for subroutine name bpdecode174).
>>> 
>>> It turns out that only 14 of the 574 decodes were produced by osd174, the 
>>> "ordered statistics" decoder.  The rest came from bpd174.  With osd174 
>>> deactivated, timer.out looks like this:
>>> 
>>> Name Time  Frac dTime dFracCalls
>>> --
>>> jt9 6.641  1.00 0.891  0.131
>>>  read_wav   0.168  0.03 0.168  0.0327404
>>>  decft8 5.582  0.84 0.094  0.01  527
>>>   sync8 3.887  0.59 3.887  0.59  527
>>>   ft8b  1.602  0.24 0.109  0.02 2821
>>>bpd174   1.492  0.22 1.492  0.22 2821
>>>osd174   0.000  0.00 0.000  0.00 2210
>>> --
>>> 6.641  1.00
>>> 
>>> Now the average execution time for a 15 s Rx sequence is just 13 ms!
>>> 
>>> We need to keep decoding time very short -- say, well under 1 s -- so that 
>>> auto-sequencing, if not the human operator, can select proper responses to 
>>> received messages.  Fortunately, we already have good baseline performance 
>>> -- and we have a number of "knobs" to play with.
>>> 
>>> -- Joe, K1JT
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> -

Re: [wsjt-devel] FT8 - build 7752 and rig control

[Bill Somerville]

On 30/06/2017 15:37, Jordan Sherer wrote:

Jumping in here since it's sort of relevant to the discussion.

One oddity I found this morning while operating split:

0. I load up WSJTX on 20m
1. I have enabled FT8 mode with rig ctl split
2. VFO is at 14.079.000, transmit offset at 800Hz
3. Tx cycle correctly adjusts split to 14.078.500
4. I move to JT65 on 20m
5. VFO is at 14.076.000, transmit offset at 800Hz
6. Tx cycle incorrectly adjusted the VFO split frequency to 14.078.500 
(as if it was still in FT8 mode)


I'm assuming this is probably a just small bug with the split offset 
not resetting when switching from FT8 to JT65 in this build. Are you, 
or anybody else able to reproduce?



Hi Jordan,

if your Tx DF is 800Hz then your Tx VFO should be at 1kHz below the Rx 
VFO, i.e. in this case .078 . If that is not happening then you may have 
an issue with your CAT interfacing. Please check the adjustment of your 
Tx VFO by CTRL+clicking on the waterfall within each visible 500Hz section.


73
Bill
G4WJS.


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

Re: [wsjt-devel] FT8 notes

[Joe Taylor]

Hi Steve,

Yes, 40 iterations for bp.

With norder=2 hardwired for everything I still get 574 good decodes.  So 
at least in jt9.exe, with no attempt to move nfqso around, using 
norder=3 produces no more decodes.


Here are the timer results with norder=2:

 Name Time  Frac dTime dFracCalls
--
 jt933.832  1.00 0.691  0.021
  read_wav   0.164  0.00 0.164  0.0027404
  decft832.977  0.97 0.055  0.00  527
   sync8 4.148  0.12 4.148  0.12  527
   ft8b 28.773  0.85 0.090  0.00 2821
bpd174   1.641  0.05 1.641  0.05 2821
osd174  27.043  0.8027.043  0.80 2210
--
33.832  1.00

-- Joe

On 6/30/2017 10:34 AM, Steven Franke wrote:

Joe,
Were these results obtained with 40 iterations for bp and norder = 3 for 
signals at or within 10 Hz of nfqso? If so, it might be interesting to see how 
the numbers would change if you dropped back to norder=2 for all signals.
Steve


On Jun 30, 2017, at 9:25 AM, Joe Taylor  wrote:

Hi all,

Thanks for a busy ~20 hours of many people testing FT8.  I now have accumulated 
a directory with 527 *.wav files, each of which has at least one visible FT8 
signal.  The files were recorded at K1JT at either 14.079 or 50.313 MHz.

Running the r7753 stand-alone slow-mode decoder jt9[.exe] on this collection of 
files produces 574 valid decodes and 0 false decodes with total execution time 
39.8 s.  The average time to process a 15 s Rx sequence on this machine (Core 
i7-6700 @ 3.4 GHz) is thus 39.8/527 = 0.076 s.  Not bad!

Here's the detailed execution-time breakdown from timer.out:

Name Time  Frac dTime dFracCalls
--
jt939.828  1.00 0.734  0.021
  read_wav   0.121  0.00 0.121  0.0027404
  decft838.973  0.98 0.133  0.00  527
   sync8 4.191  0.11 4.191  0.11  527
   ft8b 34.648  0.87 0.051  0.00 2821
bpd174   1.480  0.04 1.480  0.04 2821
osd174  33.117  0.8333.117  0.83 2210
--
39.828  1.00

Note that 83% of the execution time is spent in routine osd174, 11% in sync8, 
and 4% in bpd174 (a contraction for subroutine name bpdecode174).

It turns out that only 14 of the 574 decodes were produced by osd174, the "ordered 
statistics" decoder.  The rest came from bpd174.  With osd174 deactivated, timer.out 
looks like this:

Name Time  Frac dTime dFracCalls
--
jt9 6.641  1.00 0.891  0.131
  read_wav   0.168  0.03 0.168  0.0327404
  decft8 5.582  0.84 0.094  0.01  527
   sync8 3.887  0.59 3.887  0.59  527
   ft8b  1.602  0.24 0.109  0.02 2821
bpd174   1.492  0.22 1.492  0.22 2821
osd174   0.000  0.00 0.000  0.00 2210
--
 6.641  1.00

Now the average execution time for a 15 s Rx sequence is just 13 ms!

We need to keep decoding time very short -- say, well under 1 s -- so that 
auto-sequencing, if not the human operator, can select proper responses to received 
messages.  Fortunately, we already have good baseline performance -- and we have a number 
of "knobs" to play with.

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

[Bill Somerville]

HI Joe & Steve,

one quick win might be to implement a more CPU intensive decode at the 
Rx DF +/- a few Hertz when clicking the "Decode" button or double 
clicking the waterfall. I believe most of the logic to drive this is 
already in place.


73
Bill
G4WJS.

On 30/06/2017 15:34, Steven Franke wrote:

Joe,
Were these results obtained with 40 iterations for bp and norder = 3 for 
signals at or within 10 Hz of nfqso? If so, it might be interesting to see how 
the numbers would change if you dropped back to norder=2 for all signals.
Steve


On Jun 30, 2017, at 9:25 AM, Joe Taylor  wrote:

Hi all,

Thanks for a busy ~20 hours of many people testing FT8.  I now have accumulated 
a directory with 527 *.wav files, each of which has at least one visible FT8 
signal.  The files were recorded at K1JT at either 14.079 or 50.313 MHz.

Running the r7753 stand-alone slow-mode decoder jt9[.exe] on this collection of 
files produces 574 valid decodes and 0 false decodes with total execution time 
39.8 s.  The average time to process a 15 s Rx sequence on this machine (Core 
i7-6700 @ 3.4 GHz) is thus 39.8/527 = 0.076 s.  Not bad!

Here's the detailed execution-time breakdown from timer.out:

Name Time  Frac dTime dFracCalls
--
jt939.828  1.00 0.734  0.021
  read_wav   0.121  0.00 0.121  0.0027404
  decft838.973  0.98 0.133  0.00  527
   sync8 4.191  0.11 4.191  0.11  527
   ft8b 34.648  0.87 0.051  0.00 2821
bpd174   1.480  0.04 1.480  0.04 2821
osd174  33.117  0.8333.117  0.83 2210
--
39.828  1.00

Note that 83% of the execution time is spent in routine osd174, 11% in sync8, 
and 4% in bpd174 (a contraction for subroutine name bpdecode174).

It turns out that only 14 of the 574 decodes were produced by osd174, the "ordered 
statistics" decoder.  The rest came from bpd174.  With osd174 deactivated, timer.out 
looks like this:

Name Time  Frac dTime dFracCalls
--
jt9 6.641  1.00 0.891  0.131
  read_wav   0.168  0.03 0.168  0.0327404
  decft8 5.582  0.84 0.094  0.01  527
   sync8 3.887  0.59 3.887  0.59  527
   ft8b  1.602  0.24 0.109  0.02 2821
bpd174   1.492  0.22 1.492  0.22 2821
osd174   0.000  0.00 0.000  0.00 2210
--
 6.641  1.00

Now the average execution time for a 15 s Rx sequence is just 13 ms!

We need to keep decoding time very short -- say, well under 1 s -- so that 
auto-sequencing, if not the human operator, can select proper responses to received 
messages.  Fortunately, we already have good baseline performance -- and we have a number 
of "knobs" to play with.

-- Joe, K1JT



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

Re: [wsjt-devel] FT8 - build 7752 and rig control

[Jordan Sherer]

Jumping in here since it's sort of relevant to the discussion.

One oddity I found this morning while operating split:

0. I load up WSJTX on 20m
1. I have enabled FT8 mode with rig ctl split
2. VFO is at 14.079.000, transmit offset at 800Hz
3. Tx cycle correctly adjusts split to 14.078.500
4. I move to JT65 on 20m
5. VFO is at 14.076.000, transmit offset at 800Hz
6. Tx cycle incorrectly adjusted the VFO split frequency to 14.078.500 (as
if it was still in FT8 mode)

I'm assuming this is probably a just small bug with the split offset not
resetting when switching from FT8 to JT65 in this build. Are you, or
anybody else able to reproduce?

73
Jordan
KN4CRD

On Fri, Jun 30, 2017 at 10:28 AM, Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> You misunderstand how split works with WSJT-X.  It's not like the split
> you're used to on other modes.
> Technically, it is "split" as two your transmit/receive are different.
>
> But nobody even knows you're doing split but you.  WSJT-X adjusts the
> audio on the carrier to stay at your offset.
>
> Soe.g.
>
> 14076 when you have offset 1200 would normally generate tones starting at
> 1200Hz.
> But turn on split and 14076 will become 14075.5 and the tones will
> generated at 1700Hz to maintain the same offset to everybody receiving you.
>
> So your transmitted signal looks no different to the outside world.
>
> de Mike W9MDB
>
>
>
> --
> *From:* George J Molnar 
> *To:* WSJT software development 
> *Sent:* Friday, June 30, 2017 9:23 AM
> *Subject:* Re: [wsjt-devel] FT8 - build 7752 and rig control
>
> Good morning/afternoon, Bill.
>
> Don’t think anything is going wrong. Clearly, it’s working the way it’s
> written.
>
> My concern is that, in a crowded band situation, as stations spread out,
> having the software automatically “split” TX and RX in the name of spectral
> purity could lead to unintended interference to stations operating perhaps
> several hundred Hertz away. In an environment where there’s only one QSO in
> progress, this is pretty much a non-issue, but when the passband fills,
> working with non-identical TX and RX tones might lead to an effective
> 2-times congestion.
>
> Practice appears to be in most circles (particularly on HF) for both
> stations to use the same DF. That seems to be what most people expect.
> Calling off DF can lead to click-chasing where stations ping each other
> around the passband, leading to even more confusion.
>
> Again, not saying this is the fault of the software, and keeping the tones
> clean and well-centered is a good thing. Just don’t think it will work well
> for the average operator under normal circumstances. I’d vote for the
> software not to automatically make changes to operator settings like DF,
> etc.
>
> Thanks for all the amazing work you guys are doing….
>
> 73
>  Geo
>
> *George J Molnar*
> Nevada, USA
> KF2T  @GJMolnar
>
>
>
>
>
> On Jun 30, 2017, at 7:08 AM, Bill Somerville 
> wrote:
>
> Hi George,
>
> please explain in detail what you think is going wrong? The behaviour Erik
> described is normal and correct behaviour and allows you to transmit at
> *any* DF plus it helps to keep your transmit signal as clean as possible.
>
> 73
> Bill
> G4WJS.
>
> On 30/06/2017 14:12, George J Molnar wrote:
>
> I see the same, and suggest it not be continued as the normal behavior. In
> a multi signal environment, it will likely lead to confusion.
>
> Using a configuration for FT8 that turns off split capability is a
> workaround for now, it seems.
>
> George J Molnar, KF2T
> Nevada, USA
>
>
> On Jun 30, 2017, at 2:01 AM, Bill Somerville 
> wrote:
>
> On 30/06/2017 08:18, Erik Icket wrote:
>
> I successfully operate latest build 7752, and in the last 12 hours, I was
> able to copy on 14079 the following stations :
>
> OE1MWW, F1ABL, CT1FBK, I3VJW, KB3MOW, AK1P, VA3VF, K9AN, K4DET, WB4KDI
>
>
> There is however one anomaly with my rig control (ICOM 7100 in SPLIT mode)
> :
>
> When I PTT with an RX frequency of 14.079.000, the TX occurs on 14.078.500
> Note that the TX and RX spinners are on 1200 Hz as well as the green and
> red brackets on the wide graph.
> The same happens on any other band (6m ..), whereby the TX is 500 Hz below
> the RX frequency
>
> Has anyone else observed this ?
>
> Hi Erik,
> this is normal and correct behaviour if you have "Settings->Radio->Split
> Operating" set and have selected a Tx DF between 1000Hz and 1499Hz. Other
> Tx DF values will select different Tx dial frequencies to optimize your
> signal quality and Tx sub-band coverage.
> 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/listin

Re: [wsjt-devel] FT8 - build 7752 and rig control

[Bill Somerville]

On 30/06/2017 15:25, Bill Somerville wrote:
one of us is misunderstanding the situation. There is no "split" of 
the on-air signals, stations using split are transmitting exactly 
where the red cursor is placed on the waterfall which is exactly the 
rig's dial frequency plus the Rx DF.


Sorry, I mistyped. I meant:

"stations using split are transmitting exactly where the red cursor is 
placed on the waterfall which is exactly the rig's dial frequency plus 
the Tx DF."


Just to clarify further, the use of split on the rig is solely to 
facilitate keeping the audio tones going into the rig above 1500Hz so 
that any harmonics that are generated by overdrive or other mis-match of 
audio levels will get greatly attenuated by the rig's SSB filter LP cut 
off around 2700Hz.


This technique also allows an operator with a wide Rx bandwidth to 
transmit anywhere in that passband.


The actuality is not bandwidth being wasted but more users per USB dial 
frequency, i.e. just the opposite. Having many stations on the same dial 
frequency also facilitates mass spotting to services like pskreporter 
and hamspots so that openings can be quickly detected.


73
Bill
G4WJS.


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

Re: [wsjt-devel] FT8 notes

[Steven Franke]

Joe,
Were these results obtained with 40 iterations for bp and norder = 3 for 
signals at or within 10 Hz of nfqso? If so, it might be interesting to see how 
the numbers would change if you dropped back to norder=2 for all signals. 
Steve

> On Jun 30, 2017, at 9:25 AM, Joe Taylor  wrote:
> 
> Hi all,
> 
> Thanks for a busy ~20 hours of many people testing FT8.  I now have 
> accumulated a directory with 527 *.wav files, each of which has at least one 
> visible FT8 signal.  The files were recorded at K1JT at either 14.079 or 
> 50.313 MHz.
> 
> Running the r7753 stand-alone slow-mode decoder jt9[.exe] on this collection 
> of files produces 574 valid decodes and 0 false decodes with total execution 
> time 39.8 s.  The average time to process a 15 s Rx sequence on this machine 
> (Core i7-6700 @ 3.4 GHz) is thus 39.8/527 = 0.076 s.  Not bad!
> 
> Here's the detailed execution-time breakdown from timer.out:
> 
> Name Time  Frac dTime dFracCalls
> --
> jt939.828  1.00 0.734  0.021
>  read_wav   0.121  0.00 0.121  0.0027404
>  decft838.973  0.98 0.133  0.00  527
>   sync8 4.191  0.11 4.191  0.11  527
>   ft8b 34.648  0.87 0.051  0.00 2821
>bpd174   1.480  0.04 1.480  0.04 2821
>osd174  33.117  0.8333.117  0.83 2210
> --
>39.828  1.00
> 
> Note that 83% of the execution time is spent in routine osd174, 11% in sync8, 
> and 4% in bpd174 (a contraction for subroutine name bpdecode174).
> 
> It turns out that only 14 of the 574 decodes were produced by osd174, the 
> "ordered statistics" decoder.  The rest came from bpd174.  With osd174 
> deactivated, timer.out looks like this:
> 
> Name Time  Frac dTime dFracCalls
> --
> jt9 6.641  1.00 0.891  0.131
>  read_wav   0.168  0.03 0.168  0.0327404
>  decft8 5.582  0.84 0.094  0.01  527
>   sync8 3.887  0.59 3.887  0.59  527
>   ft8b  1.602  0.24 0.109  0.02 2821
>bpd174   1.492  0.22 1.492  0.22 2821
>osd174   0.000  0.00 0.000  0.00 2210
> --
> 6.641  1.00
> 
> Now the average execution time for a 15 s Rx sequence is just 13 ms!
> 
> We need to keep decoding time very short -- say, well under 1 s -- so that 
> auto-sequencing, if not the human operator, can select proper responses to 
> received messages.  Fortunately, we already have good baseline performance -- 
> and we have a number of "knobs" to play with.
> 
>   -- 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 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] msk144sd.f90 problem?

[Steven Franke]

Mike,

msk144sd is just a development routine - it is not used in WSJT-X.

Steve

> On Jun 30, 2017, at 8:15 AM, Black Michael via wsjt-devel 
>  wrote:
> 
> Looking at some of the compilation warningstframe pops out as 
> uninitialized...and appears to not be used at all.
> 
> Line 136 of lib/msk144sd.f90
> 
> 
>if(ndecodesuccess .gt. 0) then
>   tdec=tsec+xmc(iavg)*tframe
>   fest=fo+(fest-fc)/32.0
> 
> If I understand FORTRAN default values then tframe=1 so has no effect here.
> The MSK144 guru needs to see if this is the desired effect.
> 
> de Mike W9MDB
>  
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
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 - build 7752 and rig control

[Black Michael via wsjt-devel]

You misunderstand how split works with WSJT-X.  It's not like the split you're 
used to on other modes.Technically, it is "split" as two your transmit/receive 
are different.
But nobody even knows you're doing split but you.  WSJT-X adjusts the audio on 
the carrier to stay at your offset.
Soe.g.
14076 when you have offset 1200 would normally generate tones starting at 
1200Hz.But turn on split and 14076 will become 14075.5 and the tones will 
generated at 1700Hz to maintain the same offset to everybody receiving you.
So your transmitted signal looks no different to the outside world.
de Mike W9MDB


  From: George J Molnar 
 To: WSJT software development  
 Sent: Friday, June 30, 2017 9:23 AM
 Subject: Re: [wsjt-devel] FT8 - build 7752 and rig control
   
Good morning/afternoon, Bill.
Don’t think anything is going wrong. Clearly, it’s working the way it’s written.
My concern is that, in a crowded band situation, as stations spread out, having 
the software automatically “split” TX and RX in the name of spectral purity 
could lead to unintended interference to stations operating perhaps several 
hundred Hertz away. In an environment where there’s only one QSO in progress, 
this is pretty much a non-issue, but when the passband fills, working with 
non-identical TX and RX tones might lead to an effective 2-times congestion.
Practice appears to be in most circles (particularly on HF) for both stations 
to use the same DF. That seems to be what most people expect. Calling off DF 
can lead to click-chasing where stations ping each other around the passband, 
leading to even more confusion.
Again, not saying this is the fault of the software, and keeping the tones 
clean and well-centered is a good thing. Just don’t think it will work well for 
the average operator under normal circumstances. I’d vote for the software not 
to automatically make changes to operator settings like DF, etc. 
Thanks for all the amazing work you guys are doing….
73 Geo
George J MolnarNevada, USA
KF2T  @GJMolnar





On Jun 30, 2017, at 7:08 AM, Bill Somerville  wrote:
 
 Hi George,
 
 please explain in detail what you think is going wrong? The behaviour Erik 
described is normal and correct behaviour and allows you to transmit at *any* 
DF plus it helps to keep your transmit signal as clean as possible.
 
 73
 Bill
 G4WJS.
 
 On 30/06/2017 14:12, George J Molnar wrote:
  
I see the same, and suggest it not be continued as the normal behavior. In a 
multi signal environment, it will likely lead to confusion.  
  Using a configuration for FT8 that turns off split capability is a workaround 
for now, it seems.
 
 George J Molnar, KF2T  Nevada, USA
 

 On Jun 30, 2017, at 2:01 AM, Bill Somerville  wrote:
 
  
  

On 30/06/2017 08:18, Erik Icket wrote:
  
I successfully operate latest build 7752, and in the last 12 hours, I was able 
to copy on 14079 the following stations :  OE1MWW, F1ABL, CT1FBK, I3VJW, 
KB3MOW, AK1P, VA3VF, K9AN, K4DET, WB4KDI    There is however one anomaly with 
my rig control (ICOM 7100 in SPLIT mode) :  When I PTT with an RX frequency of 
14.079.000, the TX occurs on 14.078.500Note that the TX and RX spinners are on 
1200 Hz as well as the green and red brackets on the wide graph.The same 
happens on any other band (6m ..), whereby the TX is 500 Hz below the RX 
frequency  Has anyone else observed this ? 
Hi Erik,this is normal and correct behaviour if you have 
"Settings->Radio->Split Operating" set and have selected a Tx DF between 1000Hz 
and 1499Hz. Other Tx DF values will select different Tx dial frequencies to  
optimize your signal quality and Tx sub-band coverage.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


   --
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 - build 7752 and rig control

[Bill Somerville]

On 30/06/2017 15:21, George J Molnar wrote:

Good morning/afternoon, Bill.

Don’t think anything is going wrong. Clearly, it’s working the way 
it’s written.


My concern is that, in a crowded band situation, as stations spread 
out, having the software automatically “split” TX and RX in the name 
of spectral purity could lead to unintended interference to stations 
operating perhaps several hundred Hertz away. In an environment where 
there’s only one QSO in progress, this is pretty much a non-issue, but 
when the passband fills, working with non-identical TX and RX tones 
might lead to an effective 2-times congestion.


Practice appears to be in most circles (particularly on HF) for both 
stations to use the same DF. That seems to be what most people expect. 
Calling off DF can lead to click-chasing where stations ping each 
other around the passband, leading to even more confusion.


Again, not saying this is the fault of the software, and keeping the 
tones clean and well-centered is a good thing. Just don’t think it 
will work well for the average operator under normal circumstances. 
I’d vote for the software not to automatically make changes to 
operator settings like DF, etc.


Thanks for all the amazing work you guys are doing….

73
 Geo

*George J Molnar*
Nevada, USA
KF2T  @GJMolnar


Hi George,

one of us is misunderstanding the situation. There is no "split" of the 
on-air signals, stations using split are transmitting exactly where the 
red cursor is placed on the waterfall which is exactly the rig's dial 
frequency plus the Rx DF.


73
Bill
G4WJS.

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

[wsjt-devel] FT8 notes

[Joe Taylor]

Hi all,

Thanks for a busy ~20 hours of many people testing FT8.  I now have 
accumulated a directory with 527 *.wav files, each of which has at least 
one visible FT8 signal.  The files were recorded at K1JT at either 
14.079 or 50.313 MHz.


Running the r7753 stand-alone slow-mode decoder jt9[.exe] on this 
collection of files produces 574 valid decodes and 0 false decodes with 
total execution time 39.8 s.  The average time to process a 15 s Rx 
sequence on this machine (Core i7-6700 @ 3.4 GHz) is thus 39.8/527 = 
0.076 s.  Not bad!


Here's the detailed execution-time breakdown from timer.out:

 Name Time  Frac dTime dFracCalls
--
 jt939.828  1.00 0.734  0.021
  read_wav   0.121  0.00 0.121  0.0027404
  decft838.973  0.98 0.133  0.00  527
   sync8 4.191  0.11 4.191  0.11  527
   ft8b 34.648  0.87 0.051  0.00 2821
bpd174   1.480  0.04 1.480  0.04 2821
osd174  33.117  0.8333.117  0.83 2210
--
39.828  1.00

Note that 83% of the execution time is spent in routine osd174, 11% in 
sync8, and 4% in bpd174 (a contraction for subroutine name bpdecode174).


It turns out that only 14 of the 574 decodes were produced by osd174, 
the "ordered statistics" decoder.  The rest came from bpd174.  With 
osd174 deactivated, timer.out looks like this:


 Name Time  Frac dTime dFracCalls
--
 jt9 6.641  1.00 0.891  0.131
  read_wav   0.168  0.03 0.168  0.0327404
  decft8 5.582  0.84 0.094  0.01  527
   sync8 3.887  0.59 3.887  0.59  527
   ft8b  1.602  0.24 0.109  0.02 2821
bpd174   1.492  0.22 1.492  0.22 2821
osd174   0.000  0.00 0.000  0.00 2210
--
 6.641  1.00

Now the average execution time for a 15 s Rx sequence is just 13 ms!

We need to keep decoding time very short -- say, well under 1 s -- so 
that auto-sequencing, if not the human operator, can select proper 
responses to received messages.  Fortunately, we already have good 
baseline performance -- and we have a number of "knobs" to play with.


-- Joe, K1JT

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

Re: [wsjt-devel] FT8 - build 7752 and rig control

[George J Molnar]

Good morning/afternoon, Bill.

Don’t think anything is going wrong. Clearly, it’s working the way it’s written.

My concern is that, in a crowded band situation, as stations spread out, having 
the software automatically “split” TX and RX in the name of spectral purity 
could lead to unintended interference to stations operating perhaps several 
hundred Hertz away. In an environment where there’s only one QSO in progress, 
this is pretty much a non-issue, but when the passband fills, working with 
non-identical TX and RX tones might lead to an effective 2-times congestion.

Practice appears to be in most circles (particularly on HF) for both stations 
to use the same DF. That seems to be what most people expect. Calling off DF 
can lead to click-chasing where stations ping each other around the passband, 
leading to even more confusion.

Again, not saying this is the fault of the software, and keeping the tones 
clean and well-centered is a good thing. Just don’t think it will work well for 
the average operator under normal circumstances. I’d vote for the software not 
to automatically make changes to operator settings like DF, etc. 

Thanks for all the amazing work you guys are doing….

73
 Geo

George J Molnar
Nevada, USA
KF2T  @GJMolnar





> On Jun 30, 2017, at 7:08 AM, Bill Somerville  wrote:
> 
> Hi George,
> 
> please explain in detail what you think is going wrong? The behaviour Erik 
> described is normal and correct behaviour and allows you to transmit at *any* 
> DF plus it helps to keep your transmit signal as clean as possible.
> 
> 73
> Bill
> G4WJS.
> 
> On 30/06/2017 14:12, George J Molnar wrote:
>> I see the same, and suggest it not be continued as the normal behavior. In a 
>> multi signal environment, it will likely lead to confusion. 
>> 
>> Using a configuration for FT8 that turns off split capability is a 
>> workaround for now, it seems.
>> 
>> George J Molnar, KF2T 
>> Nevada, USA
>> 
>> 
>> On Jun 30, 2017, at 2:01 AM, Bill Somerville > > wrote:
>> 
>>> On 30/06/2017 08:18, Erik Icket wrote:
 I successfully operate latest build 7752, and in the last 12 hours, I was 
 able to copy on 14079 the following stations :
 
  
 
 OE1MWW, F1ABL, CT1FBK, I3VJW, KB3MOW, AK1P, VA3VF, K9AN, K4DET, WB4KDI
 
  
 
  
 
 There is however one anomaly with my rig control (ICOM 7100 in SPLIT mode) 
 :
 
  
 
 When I PTT with an RX frequency of 14.079.000, the TX occurs on 14.078.500
 
 Note that the TX and RX spinners are on 1200 Hz as well as the green and 
 red brackets on the wide graph.
 
 The same happens on any other band (6m ..), whereby the TX is 500 Hz below 
 the RX frequency
 
  
 
 Has anyone else observed this ?
 
>>> Hi Erik,
>>> 
>>> this is normal and correct behaviour if you have "Settings->Radio->Split 
>>> Operating" set and have selected a Tx DF between 1000Hz and 1499Hz. Other 
>>> Tx DF values will select different Tx dial frequencies to optimize your 
>>> signal quality and Tx sub-band coverage.
>>> 
>>> 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] FT8 - build 7752 and rig control

[Bill Somerville]

Hi George,

please explain in detail what you think is going wrong? The behaviour 
Erik described is normal and correct behaviour and allows you to 
transmit at *any* DF plus it helps to keep your transmit signal as clean 
as possible.


73
Bill
G4WJS.

On 30/06/2017 14:12, George J Molnar wrote:
I see the same, and suggest it not be continued as the normal 
behavior. In a multi signal environment, it will likely lead to 
confusion.


Using a configuration for FT8 that turns off split capability is a 
workaround for now, it seems.


George J Molnar, KF2T
Nevada, USA


On Jun 30, 2017, at 2:01 AM, Bill Somerville > wrote:



On 30/06/2017 08:18, Erik Icket wrote:


I successfully operate latest build 7752, and in the last 12 hours, 
I was able to copy on 14079 the following stations :


OE1MWW, F1ABL, CT1FBK, I3VJW, KB3MOW, AK1P, VA3VF, K9AN, K4DET, WB4KDI

There is however one anomaly with my rig control (ICOM 7100 in SPLIT 
mode) :


When I PTT with an RX frequency of 14.079.000, the TX occurs on 
14.078.500


Note that the TX and RX spinners are on 1200 Hz as well as the green 
and red brackets on the wide graph.


The same happens on any other band (6m ..), whereby the TX is 500 Hz 
below the RX frequency


Has anyone else observed this ?


Hi Erik,

this is normal and correct behaviour if you have 
"Settings->Radio->Split Operating" set and have selected a Tx DF 
between 1000Hz and 1499Hz. Other Tx DF values will select different 
Tx dial frequencies to optimize your signal quality and Tx sub-band 
coverage.


73
Bill
G4WJS.



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

Re: [wsjt-devel] FT8: Potential new mode for fast QSOs

[John Nelson]

Hi Joe, Steve and Bill,

FT8 busy on 20m this afternoon.  r7752 operational on Mac OSX 10.11 without 
problems…

— John G4KLA
--
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] msk144sd.f90 problem?

[Joe Taylor]

Mike --

A large number of such "development routines" are presently listed in 
CMakeLists.txt and compiled in a standard CMake-driven build, but not 
actually used in wsjtx[.exe].  We're discussing, after all, the 
Development Branch.  In due course, "code cleanups" of the sort you 
suggest will be desirable.


-- Joe, K1JT

On 6/30/2017 9:35 AM, Black Michael via wsjt-devel wrote:

Perhaps we should remove it from the compile chain then?

de Mike W9MDB



*From:* Steven Franke 
*To:* Black Michael ; Joe Taylor 


*Sent:* Friday, June 30, 2017 8:28 AM
*Subject:* Re: [wsjt-devel] msk144sd.f90 problem?

Mike,

msk144sd is just a development routine - it is not used in WSJT-X.

Steve

 > On Jun 30, 2017, at 8:15 AM, Black Michael via wsjt-devel 
> wrote:

 >
 > Looking at some of the compilation warningstframe pops out as 
uninitialized...and appears to not be used at all.

 >
 > Line 136 of lib/msk144sd.f90
 >
 >
 >if(ndecodesuccess .gt. 0) then
 >  tdec=tsec+xmc(iavg)*tframe
 >  fest=fo+(fest-fc)/32.0
 >
 > If I understand FORTRAN default values then tframe=1 so has no effect 
here.

 > The MSK144 guru needs to see if this is the desired effect.
 >
 > de Mike W9MDB

 >
 > 
--

 > Check out the vibrant tech community on one of the world's most
 > engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot___

 > wsjt-devel mailing list
 > wsjt-devel@lists.sourceforge.net 


 > https://lists.sourceforge.net/lists/listinfo/wsjt-devel





--
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] msk144sd.f90 problem?

[Black Michael via wsjt-devel]

Perhaps we should remove it from the compile chain then?
de Mike W9MDB

  From: Steven Franke 
 To: Black Michael ; Joe Taylor 
 
 Sent: Friday, June 30, 2017 8:28 AM
 Subject: Re: [wsjt-devel] msk144sd.f90 problem?
   
Mike,

msk144sd is just a development routine - it is not used in WSJT-X.

Steve

> On Jun 30, 2017, at 8:15 AM, Black Michael via wsjt-devel 
>  wrote:
> 
> Looking at some of the compilation warningstframe pops out as 
> uninitialized...and appears to not be used at all.
> 
> Line 136 of lib/msk144sd.f90
> 
> 
>            if(ndecodesuccess .gt. 0) then
>              tdec=tsec+xmc(iavg)*tframe
>              fest=fo+(fest-fc)/32.0
> 
> If I understand FORTRAN default values then tframe=1 so has no effect here.
> The MSK144 guru needs to see if this is the desired effect.
> 
> de Mike W9MDB
>  
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


   --
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] msk144sd.f90 problem?

[Black Michael via wsjt-devel]

Looking at some of the compilation warningstframe pops out as 
uninitialized...and appears to not be used at all.
Line 136 of lib/msk144sd.f90

           if(ndecodesuccess .gt. 0) then              
tdec=tsec+xmc(iavg)*tframe              fest=fo+(fest-fc)/32.0
If I understand FORTRAN default values then tframe=1 so has no effect here.The 
MSK144 guru needs to see if this is the desired effect.
de Mike W9MDB --
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 - build 7752 and rig control

[George J Molnar]

I see the same, and suggest it not be continued as the normal behavior. In a 
multi signal environment, it will likely lead to confusion. 

Using a configuration for FT8 that turns off split capability is a workaround 
for now, it seems.

George J Molnar, KF2T 
Nevada, USA


> On Jun 30, 2017, at 2:01 AM, Bill Somerville  wrote:
> 
>> On 30/06/2017 08:18, Erik Icket wrote:
>> I successfully operate latest build 7752, and in the last 12 hours, I was 
>> able to copy on 14079 the following stations :
>> 
>>  
>> 
>> OE1MWW, F1ABL, CT1FBK, I3VJW, KB3MOW, AK1P, VA3VF, K9AN, K4DET, WB4KDI
>> 
>>  
>> 
>>  
>> 
>> There is however one anomaly with my rig control (ICOM 7100 in SPLIT mode) :
>> 
>>  
>> 
>> When I PTT with an RX frequency of 14.079.000, the TX occurs on 14.078.500
>> 
>> Note that the TX and RX spinners are on 1200 Hz as well as the green and red 
>> brackets on the wide graph.
>> 
>> The same happens on any other band (6m ..), whereby the TX is 500 Hz below 
>> the RX frequency
>> 
>>  
>> 
>> Has anyone else observed this ?
>> 
> Hi Erik,
> 
> this is normal and correct behaviour if you have "Settings->Radio->Split 
> Operating" set and have selected a Tx DF between 1000Hz and 1499Hz. Other Tx 
> DF values will select different Tx dial frequencies to optimize your signal 
> quality and Tx sub-band coverage.
> 
> 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] FT8 Notes

[pjsg-wsjt]

One FT8 record in pskreporter (RA9HO heard by I3RGH). Hopefully the 
first of many!


Congratulations.

Philip

On 29/06/2017 21:58, Tim Carlson wrote:

I just made my first FT8 QSO with WB4KDI as well.  I agree - very cool.

-Tim - KD0GYG

On Jun 29, 2017, at 6:43 PM, C. Gary Rogers > wrote:


Just made first FT8 QSO with WB4KDI…Way cool!!!…73 Gary

On Jun 29, 2017, at 7:56 PM, Dave 'Doc' Corio > wrote:


Managed 5 or 6 QSOs with the new mode so far. Two things I notice:

1. Even when the cursor on the wide graph is directly on a FT8 
signal it does not decode to the received window unless the text 
includes my call sign. Not major, but took a bit to realize why I 
wasn't "decoding".


2. Your must be VERY fast to answer a call with the short 
decode-to-transmit time! The quick QSOs are amazing, but with only a 
second or so to decide to answer or not really captures your attention!


Thanks, Devs!
73 - Dave - KB3MOW



--
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] WSJTX crash using FT8 on Ubuntu Linux 16.04 LTS

[Jordan Sherer]

Hey Bill,

Deps are up to date and there are no dist upgrades available. I restarted
the app and haven't had another issue yet...just an empty band here. I'll
let you know if I find a reproducible test case.

73
Jordan
KN4CRD

On Fri, Jun 30, 2017 at 8:12 AM, Bill Somerville 
wrote:

> On 30/06/2017 13:06, Jordan Sherer wrote:
>
>> I'm a new comer to the wsjt-devel list. Software engineer by day. Ham by
>> night.
>>
>> I was able to get a build of WSJTX r7752 running on my Ubuntu box this
>> morning. I tried calling a few CQs on 20m a few minutes ago and had a
>> segfault. Attached is a copy of the core dump.
>>
>> Happy to help debug in any way. Let me know!
>>
>
> Hi Jordan,
>
> thanks for the crash report. Looks like some memory corruption. Is it
> repeatable? Have you tried an "sudo apt get update ; sudo apt get
> dist-upgrade" then rebuild?
>
> I will try an Ubuntu 16.04 build this afternoon and see if I can reproduce
> it.
>
> 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] WSJTX crash using FT8 on Ubuntu Linux 16.04 LTS

[Bill Somerville]

On 30/06/2017 13:06, Jordan Sherer wrote:
I'm a new comer to the wsjt-devel list. Software engineer by day. Ham 
by night.


I was able to get a build of WSJTX r7752 running on my Ubuntu box this 
morning. I tried calling a few CQs on 20m a few minutes ago and had a 
segfault. Attached is a copy of the core dump.


Happy to help debug in any way. Let me know!


Hi Jordan,

thanks for the crash report. Looks like some memory corruption. Is it 
repeatable? Have you tried an "sudo apt get update ; sudo apt get 
dist-upgrade" then rebuild?


I will try an Ubuntu 16.04 build this afternoon and see if I can 
reproduce it.


73
Bill
G4WJS.


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

[wsjt-devel] WSJTX crash using FT8 on Ubuntu Linux 16.04 LTS

[Jordan Sherer]

Howdy All!

I'm a new comer to the wsjt-devel list. Software engineer by day. Ham by
night.

I was able to get a build of WSJTX r7752 running on my Ubuntu box this
morning. I tried calling a few CQs on 20m a few minutes ago and had a
segfault. Attached is a copy of the core dump.

Happy to help debug in any way. Let me know!

Best,
Jordan
KN4CRD
*** Error in `./wsjtx': malloc(): smallbin double linked list corrupted: 
0x05582990 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fb30c0997e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x82651)[0x7fb30c0a4651]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7fb30c0a6184]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN10QArrayData8allocateEmmm6QFlagsINS_16AllocationOptionEE+0xa8)[0x7fb30d49de28]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN10QByteArray11fromRawDataEPKci+0x34)[0x7fb30d4a50f4]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(+0x28e487)[0x7fb30d685487]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN7QObject7connectEPKS_PKcS1_S3_N2Qt14ConnectionTypeE+0x202)[0x7fb30d6b22a2]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN11QTextStreamC1EP9QIODevice+0x85)[0x7fb30d5c3625]
./wsjtx[0x4cfa8e]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN11QMetaObject8activateEP7QObjectiiPPv+0x66f)[0x7fb30d6abbaf]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN6QTimer10timerEventEP11QTimerEvent+0x28)[0x7fb30d6b85c8]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN7QObject5eventEP6QEvent+0xa3)[0x7fb30d6acbb3]
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0x8c)[0x7fb30e0ca05c]
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x256)[0x7fb30e0cf516]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0xdb)[0x7fb30d67d38b]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN14QTimerInfoList14activateTimersEv+0x52d)[0x7fb30d6d25ed]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2dbaf1)[0x7fb30d6d2af1]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x2a7)[0x7fb30b6f5197]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4a3f0)[0x7fb30b6f53f0]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c)[0x7fb30b6f549c]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x5f)[0x7fb30d6d37cf]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x10a)[0x7fb30d67ab4a]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x9c)[0x7fb30d682bec]
./wsjtx[0x442a04]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fb30c042830]
./wsjtx(_start+0x29)[0x4441c9]
=== Memory map: 
0040-006b5000 r-xp  08:01 3832200
/home/jordan/Development/third-party/wsjtx-prefix/build/wsjtx
008b4000-008bf000 r--p 002b4000 08:01 3832200
/home/jordan/Development/third-party/wsjtx-prefix/build/wsjtx
008bf000-008c6000 rw-p 002bf000 08:01 3832200
/home/jordan/Development/third-party/wsjtx-prefix/build/wsjtx
008c6000-03189000 rw-p  00:00 0
048f1000-05b56000 rw-p  00:00 0  [heap]
7fb2a000-7fb2b400 r--s  00:14 9  
/dev/shm/pulse-shm-1489714241
7fb2b400-7fb2b4021000 rw-p  00:00 0
7fb2b4021000-7fb2b800 ---p  00:00 0
7fb2b800-7fb2b8806000 rw-p  00:00 0
7fb2b8806000-7fb2bc00 ---p  00:00 0
7fb2bc00-7fb2bc021000 rw-p  00:00 0
7fb2bc021000-7fb2c000 ---p  00:00 0
7fb2c1393000-7fb2c15e8000 rw-s  00:05 5013516
/SYSV (deleted)
7fb2c15e8000-7fb2c19c9000 rw-s  00:05 4882433
/SYSV (deleted)
7fb2c19c9000-7fb2c1d5e000 rw-p  00:00 0
7fb2c1e21000-7fb2c1e71000 rw-s  00:05 5177359
/SYSV (deleted)
7fb2c1e71000-7fb2c1e7c000 r-xp  08:01 5113368
/lib/x86_64-linux-gnu/libnss_nis-2.23.so
7fb2c1e7c000-7fb2c207b000 ---p b000 08:01 5113368
/lib/x86_64-linux-gnu/libnss_nis-2.23.so
7fb2c207b000-7fb2c207c000 r--p a000 08:01 5113368
/lib/x86_64-linux-gnu/libnss_nis-2.23.so
7fb2c207c000-7fb2c207d000 rw-p b000 08:01 5113368
/lib/x86_64-linux-gnu/libnss_nis-2.23.so
7fb2c207d000-7fb2c2085000 r-xp  08:01 5114230
/lib/x86_64-linux-gnu/libnss_compat-2.23.so
7fb2c2085000-7fb2c2284000 ---p 8000 08:01 5114230
/lib/x86_64-linux-gnu/libnss_compat-2.23.so
7fb2c2284000-7fb2c2285000 r--p 7000 08:01 5114230
/lib/x86_64-linux-gnu/libnss_compat-2.23.so
7fb2c2285000-7fb2c2286000 rw-p 8000 08:01 5114230
/lib/x86_64-linux-gnu/libnss_compat-2.23.so
7fb2c2286000-7fb2c22e8000 r--p  08:01 380

Re: [wsjt-devel] FT8 - build 7752 and rig control

[Bill Somerville]

On 30/06/2017 08:18, Erik Icket wrote:


I successfully operate latest build 7752, and in the last 12 hours, I 
was able to copy on 14079 the following stations :


OE1MWW, F1ABL, CT1FBK, I3VJW, KB3MOW, AK1P, VA3VF, K9AN, K4DET, WB4KDI

There is however one anomaly with my rig control (ICOM 7100 in SPLIT 
mode) :


When I PTT with an RX frequency of 14.079.000, the TX occurs on 14.078.500

Note that the TX and RX spinners are on 1200 Hz as well as the green 
and red brackets on the wide graph.


The same happens on any other band (6m ..), whereby the TX is 500 Hz 
below the RX frequency


Has anyone else observed this ?


Hi Erik,

this is normal and correct behaviour if you have "Settings->Radio->Split 
Operating" set and have selected a Tx DF between 1000Hz and 1499Hz. 
Other Tx DF values will select different Tx dial frequencies to optimize 
your signal quality and Tx sub-band coverage.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Request to Change FrequencyList.cpp

[Bill Somerville]

On 30/06/2017 02:29, Takehiko Tsutsumi wrote:


Would you change the section of FrequencyList.cpp on 80m to be 
operable for JA stations as follow?


{357, Modes::JT65},
{3572000, Modes::JT9},
{3573000, Modes::FT8},
{3572600, Modes::WSPR},

Current frequencies are used for Government Use and are not allocated 
for Radio Amateur Service in Japan for more than a half century and it 
will be pessimistic to be operative in near future. Instead, the 
proposed frequency allocation meets Japanese regulation, meet IARU R1 
&2 frequency charts and allow JA stations to be operable, i.e. 6kHz 
down except WSPR.


I know it it absolutely inconvenient for the rest of the world WSJT-X 
users who have been accustomed to the current frequency allocation for 
a couple of years.


However, it is a fact for JA stations to be kept out on 80m access 
(for ever) without asking to this change.


I hope everyone in this group are generous enough to accept this 
change request but welcome any concerns or conditions to accept.



Hi Take san,

I am currently gathering information for revised suggested working 
frequencies, thanks for your input. This will be rolled out alongside a 
capability to set different working frequency suggestions per IARU 
region. I understand that your local band plan does not allow any 
operation between 3575kHz and 3599kHz. For now, as I think is already 
happening, those outside JA that wish to work JA stations can either add 
or amend the WSJT-X suggested working frequencies table as you suggest 
above.


I will add these changes to the new suggested working frequencies, at 
least for region 3. If there are no other clashes in other regions I 
will try and convince all users that a change for all on 80m is best. As 
far as I can see there is no high level band plan restriction for the 
frequencies used on 80m in Japan in all three regions, it will take more 
time to ensure that no other data modes are using those sub-bands globally.


73
Bill
G4WJS.

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

Re: [wsjt-devel] FT8: Potential new mode for fast QSOs

[Bill Somerville]

On 30/06/2017 02:24, Roger Rehr W3SZ wrote:
Bill G4WJS had given a warning on June 9 to "Beware if building from 
development sources" with revisions later than r7703, due to some 
transmission modulation issues.


Given the recommendations for us to try JT8 and the great enthusiasm 
being shown for it by users now running r7750 or later, is it safe to 
assume that that warning has been lifted?


I looked for an email rescinding the warning but couldn't find one.

Or is the current recommendation that we run r7750 or later version 
for JT8 BUT r7703 or earlier for other modes?


Hi Roger,

Steve, K9AN, fixed an issue with MSK144 modulation at r7732 
(https://sourceforge.net/p/wsjt/wsjt/7732/) which fixed the outstanding 
problem as far as I know.


73
Bill
G4WJS.


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

Re: [wsjt-devel] FT8: Potential new mode for fast QSOs

[Fábián Tamás László]

...build went like a breeze, just did an svn co and followed 
instructions in INSTALL. (Revision 7752)


I might be able to try the new mode tonight around 2230 UTC

Cheers,

Tamas HA5FTL

2017-06-29 20:47 keltezéssel, Tamás Fábián írta:
I'm going to try and compile it on Ubuntu 17.04 "zesty" (Linux 
4.10.0-26-generic x86-64) at next weekend.


If someone happens to be faster, and can send me a binary, I'll surely 
be on the air ;)


Cheers,

Tamas HA5FTL

2017-06-29 20:32 GMT+02:00 George J Molnar >:


Compiled and run without incident on Mac OS 10.12.6 (beta).
Monitored signal quality seems good.

No contacts… yet!


*George J Molnar*
Nevada, USA
KF2T  @GJMolnar






--
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] FT8 - build 7752 and rig control

[Erik Icket]

I successfully operate latest build 7752, and in the last 12 hours, I was
able to copy on 14079 the following stations :

 

OE1MWW, F1ABL, CT1FBK, I3VJW, KB3MOW, AK1P, VA3VF, K9AN, K4DET, WB4KDI

 

 

There is however one anomaly with my rig control (ICOM 7100 in SPLIT mode) :

 

When I PTT with an RX frequency of 14.079.000, the TX occurs on 14.078.500

Note that the TX and RX spinners are on 1200 Hz as well as the green and red
brackets on the wide graph.

The same happens on any other band (6m ..), whereby the TX is 500 Hz below
the RX frequency

 

Has anyone else observed this ?

 

73's from ON4PB,

Erik

 

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