Re: [wsjt-devel] Ver 1.8 RC1 audio in slider problem

[Black Michael via wsjt-devel]

There were those that still wanted the waterfall adjustment for the fast graph 
handy so leaving it as an option would be the only solution.
I submitted some tooltip changes a while ago to make it pretty much 
in-your-face on the meter tooltip.Then we need to spice up the documentation so 
be more in-your-face too.  "Transceiver setup" as an index title is not 
intuitive but hopefully most know how to use search for keywords.  I tried to 
see if you could put a hyperlink in a tool tip but appears not.  Though about 
doing a ctrl-click on the meter or such to bring up the relevant section in the 
manual then put the ctrl-click info in the tooltip.
de Mike W9MDB
  From: Bill Somerville 
 To: wsjt-devel@lists.sourceforge.net 
 Sent: Tuesday, July 18, 2017 5:54 PM
 Subject: Re: [wsjt-devel] Ver 1.8 RC1 audio in slider problem
   
 On 18/07/2017 23:32, Black Michael via wsjt-devel wrote:
  
 I'd say the vast majority have no use for the slider anymore. So let's hide it 
by default and have an enable checkbox in the config. 
  I'll do that patch if you think that's acceptable...we'll still end up with 
"what happened to..." but se la vie...  
 Hi Mike, if you are going to do a patch then remove the slider altogether, 
that is probably the best option. It is of limited value and will always be 
misunderstood by many who don't understand the underlying realities of digital 
samples. Unfortunately the result may well be that those who miss the slider 
will revert to using the operating system sliders which are effectively the 
same thing and equally pointless (even harmful at extreme settings) as the 
WSJT-X slider.
  73
 Bill
 G4WJS.
  --
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://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] Rovers and FT8

[Sean Waite]

It's good to hear that this will be fixed soon, we'd like to run meteor
scatter on the rove in September

On Tue, Jul 18, 2017, 19:24 Rich - K1HTV  wrote:

> Tim,
> You are right, as I thump my forehead :-). ! The problem is there, but the
> ones that have the problem are us folks that work the rovers or other
> stations with the slash bar. However as was mentioned, this issue is
> already being addressed an will be resolved in the R2 release of 1.8 in the
> near future.
>
> 73,
> Rich - K1HTV
>
>
> On July 18, 2017 at 7:07 PM Tim Goeppinger  wrote:
>
> Rich,
>
> The problem is that as a rover, the people I contact have to be the ones
> who have to be on their toes with the mouse clicks, as N6RMJ was for me.
> There is nothing I can do on my end.
> 73,
> Tim N6GP
>
> --
> *From:* Rich - K1HTV 
> *To:* tim...@yahoo.com; WSJT 
> *Sent:* Tuesday, July 18, 2017 2:34 PM
> *Subject:* Rovers and FT8
>
> Tim,
>   I believe that since the "/R" is eliminated from the exchanges, the
> original "CALL/R" which a station responds to does not match the "CALL" w/o
> the "/R" which is sent in subsequent steps. Since there isn't a match, it
> won't automatically proceed to the next step in the sequence. Until/Unless
> this can be fixed, the answer is to manually step through the steps, which
> means you will have to always be on your toes with a quick mouse button
> trigger finger to successfully complete each QSO. I believe that this holds
> true for any complex station call with a slant bar in it.
>
> 73,
> Rich - K1HTV
>
>
>
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Ver 1.8 RC1 audio in slider problem

[Bill Somerville]

Hi Robin,

 comments in line below.

On 19/07/2017 01:24, G8DQX (WSJT developers on SF) wrote:


surely the operating system (OS) level sliders will affect the level 
of *both* the signal to be decoded and the level of the waterfall. The 
WSJT-X "gain" slider affects the waterfall and spectrum displays only, 
but does not interfere with the (digital) signal path to the decoder. 
That said, there is only an obvious effect if the *Flatten* option is 
*not* selected.


Yes the o/s sliders will adjust the level to the decoders. This is a bad 
thing that we cannot really avoid (in fact we can but it might cause 
even more controversy).


If one was starting with a clean sheet for the user interface (UI), 
the slider in question would be on the spectrum/waterfall display, 
along with the 4 other sliders that control the spectrum/waterfall 
display, and everything would be calibrated in dB for consistency and 
ease of setting up 


Which waterfall display? There is more than one. Having a master control 
on the main window does have merits. The problem is not the function of 
the slider but the many users that think it does something it never has 
done.


In short, leave the UI as it is now, for fear that turning over the 
stone one would feel compelled to fix the unpleasantness underneath—a 
non-trivial task.



What unpleasantness?

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

[G8DQX (WSJT developers on SF)]

Bill,

surely the operating system (OS) level sliders will affect the level of 
*both* the signal to be decoded and the level of the waterfall. The 
WSJT-X "gain" slider affects the waterfall and spectrum displays only, 
but does not interfere with the (digital) signal path to the decoder. 
That said, there is only an obvious effect if the *Flatten* option is 
*not* selected.


If one was starting with a clean sheet for the user interface (UI), the 
slider in question would be on the spectrum/waterfall display, along 
with the 4 other sliders that control the spectrum/waterfall display, 
and everything would be calibrated in dB for consistency and ease of 
setting up 


In short, leave the UI as it is now, for fear that turning over the 
stone one would feel compelled to fix the unpleasantness underneath—a 
non-trivial task.


HTH,

Robin, G8DQX


On 18/07/17 23:52, Bill Somerville wrote:


Hi Mike,

if you are going to do a patch then remove the slider altogether, that 
is probably the best option. It is of limited value and will always be 
misunderstood by many who don't understand the underlying realities of 
digital samples. Unfortunately the result may well be that those who 
miss the slider will revert to using the operating system sliders 
which are effectively the same thing and equally pointless (even 
harmful at extreme settings) as the WSJT-X slider.


73
Bill
G4WJS.



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

Re: [wsjt-devel] AutoSeq Question

[Bill Somerville]

On 19/07/2017 00:05, Tim Carlson wrote:

I don’t think its about what I consider complete, I’m concerned about what the 
software considers complete.  If sending an “RRR” completes the exchange, then 
I think one of two things should happen:

1.  The Auto Sequenced software should not repeat the RRR if no 73 is received, 
or
2.  The other end should automatically resend the 73 if an RRR is repeated.


Hi Tim,

option 1 is very propagation dependent, for example an MS QSO or a 
marginal EME QSO would almost certainly repeat the RRR message until a 
73 is received unless a back channel was in use to say thanks you can 
stop now.


option 2 makes more sense except what happens if the RRR is lost in QSB 
or QRM, resending the 73 message still makes sense if you are assuming 
that an RRR message was due. this is particularly the case with MS for 
example where blank periods are the norm.


The problem here is that ending a QSO is not deterministic unless both 
sides keep sending 73 messages until they get bored or some other 
subjective decision is made. Fortunately ending the QSO is not the same 
as both parties being able to log the QSO as complete. It is not 
possible to automate a non-deterministic process.


WSJT-X gives you two options at the extremes. Stop after one 73 message 
or keep sending 73 messages until the watchdog intervenes. Both can be 
overridden by the operator by clicking "Enable Tx" or "Halt Tx" 
respectively.


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] AutoSeq Question

[Tim Carlson]

Hi Bill,

I don’t think its about what I consider complete, I’m concerned about what the 
software considers complete.  If sending an “RRR” completes the exchange, then 
I think one of two things should happen:

1.  The Auto Sequenced software should not repeat the RRR if no 73 is received, 
or
2.  The other end should automatically resend the 73 if an RRR is repeated.

Everyone may have a different idea regarding what consists of a complete QSO, 
and as you stated, that may change by band, mode, etc. (casual QSOs, contests). 
 But from what I’m seeing on the air, most people are letting the software 
carry out the entire QSO, so I think the software should be consistent in 
ending an automated QSO gracefully, not leaving the software on the other side 
repeating an RRR call until the operator intervenes.

I’m really enjoying the FT8 mode and greatly appreciate the work of you and all 
the developers.  Thank you! 

-Tim KD0GYG



> On Jul 18, 2017, at 4:47 PM, Bill Somerville  wrote:
> 
> On 18/07/2017 23:18, Tim Carlson wrote:
>> I would expect that to be handled automatically.  Otherwise we should 
>> reliable the checkbox “Semi-Auto Seq”.
> 
> Hi Tim,
> 
> as I said, the QSO is complete for both parties when the RRR message has been 
> sent, the rest is dependent of the band the mode of propagation, the means 
> for stopping the QSO. Hard to fully automate without knowing what the 
> operator expects and intends.
> 
> If you consider the QSO incomplete until you have confirmation that your 73 
> message has been received then I suggest you should not look away from the 
> QSO messages until you know that has happened.
> 
> 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] Rovers and FT8

[Rich - K1HTV]

Tim,
You are right, as I thump my forehead :-). ! The problem is there, but the ones 
that have the problem are us folks that work the rovers or other stations with 
the slash bar. However as was mentioned, this issue is already being addressed 
an will be resolved in the R2 release of 1.8 in the near future.

73,
Rich - K1HTV


> On July 18, 2017 at 7:07 PM Tim Goeppinger  wrote:
> 
> Rich,
> 
> The problem is that as a rover, the people I contact have to be the ones 
> who have to be on their toes with the mouse clicks, as N6RMJ was for me.  
> There is nothing I can do on my end.
> 73,
> Tim N6GP
> 
> 
> -
> From: Rich - K1HTV 
> To: tim...@yahoo.com; WSJT 
> Sent: Tuesday, July 18, 2017 2:34 PM
> Subject: Rovers and FT8
> 
> Tim,
>   I believe that since the "/R" is eliminated from the exchanges, the 
> original "CALL/R" which a station responds to does not match the "CALL" w/o 
> the "/R" which is sent in subsequent steps. Since there isn't a match, it 
> won't automatically proceed to the next step in the sequence. Until/Unless 
> this can be fixed, the answer is to manually step through the steps, which 
> means you will have to always be on your toes with a quick mouse button 
> trigger finger to successfully complete each QSO. I believe that this holds 
> true for any complex station call with a slant bar in it.
> 
> 73,
> Rich - K1HTV
> 
> 
> 
> 
 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Rovers and FT8

[Tim Goeppinger via wsjt-devel]

Rich,
The problem is that as a rover, the people I contact have to be the ones who 
have to be on their toes with the mouse clicks, as N6RMJ was for me.  There is 
nothing I can do on my end.
73,Tim N6GP

  From: Rich - K1HTV 
 To: tim...@yahoo.com; WSJT  
 Sent: Tuesday, July 18, 2017 2:34 PM
 Subject: Rovers and FT8
   
 Tim,
  I believe that since the "/R" is eliminated from the exchanges, the original 
"CALL/R" which a station responds to does not match the "CALL" w/o the "/R" 
which is sent in subsequent steps. Since there isn't a match, it won't 
automatically proceed to the next step in the sequence. Until/Unless this can 
be fixed, the answer is to manually step through the steps, which means you 
will have to always be on your toes with a quick mouse button trigger finger to 
successfully complete each QSO. I believe that this holds true for any complex 
station call with a slant bar in it.
73,Rich - K1HTV
 

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

[wsjt-devel] Email traffic on wsjt-devel

[Joe Taylor]

Hi all,

From time to time it seems necessary to remind everyone of the two main 
purposes of this "wsjt-devel" email reflector:


1. To facilitate communication among those contributing to the 
development of WSJT and its sister programs.


2. To provide a forum for dedicated testers to convey well documented 
bug reports.  To be most useful, such reports should describe relevant 
parts of your system and should include sufficient information to enable 
one of us to reproduce the bug.  A step-by-step recipe that is sure to 
exhibit the bug is always best.


To avoid needless repetition, please make good use of the email archive 
tool at SourceForge:

https://sourceforge.net/p/wsjt/mailman/wsjt-devel/


A second email list known as "wsjtgroup" (wsjtgr...@yahoogroups.com) is 
the best place for these other purposes:


1. To request help in setting up your station, or configuring or using 
WSJT, MAP65, WSPR, and WSJT-X; and for other user-to-user communications.


2. To convey carefully thought out suggestions for possible program 
extensions or improvements.


We developers monitor the wsjtgroup list as well as this one, and when 
necessary we provide help there.  But someone else with the same 
equipment as yours may already have solved your problem, and that person 
should be your first source for help.


With best wishes to all,

-- 73, Joe, K1JT

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

Re: [wsjt-devel] FT8 Bug in AutoSequencing For Rovers Using Callsign/R

[Tim Goeppinger via wsjt-devel]

Bill,
I am glad to hear that you are already working on the complex callsign 
sequencing issue.
Many tnx & 73,
Tim N6GP
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Ver 1.8 RC1 audio in slider problem

[Bill Somerville]

On 18/07/2017 23:32, Black Michael via wsjt-devel wrote:

I'd say the vast majority have no use for the slider anymore.
So let's hide it by default and have an enable checkbox in the config.

I'll do that patch if you think that's acceptable...we'll still end up 
with "what happened to..." but se la vie...


Hi Mike,

if you are going to do a patch then remove the slider altogether, that 
is probably the best option. It is of limited value and will always be 
misunderstood by many who don't understand the underlying realities of 
digital samples. Unfortunately the result may well be that those who 
miss the slider will revert to using the operating system sliders which 
are effectively the same thing and equally pointless (even harmful at 
extreme settings) as the WSJT-X slider.


73
Bill
G4WJS.

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

Re: [wsjt-devel] TQSL's config.xml

[Greg Beam]

Hi Dan,

 

Yes, I understand. I stopped doing that sometime in the past, but couldn’t 
remember exactly “why”. Dave helped me understand it.

 

I don’t make nearly as many QSO’s as I did when contesting “a lot”. Now, 
resubmitting a few QSO’s to LoTW isn’t that big of a deal. Back when I was 
making 1000’s of QSO’s per week/weekend, I wouldn’t not entertain the thought 
of going back and fishing out resubmissions.

 

For now, I’m just waiting on LoTW to do their thing, then I’ll submit all the 
FT8 QSO’s. I did send a bunch to eQSL after somebody confirmed they were 
accepting them.

 

73’s

Greg, KI7MT

 

 

From: Dan Malcolm [mailto:dan.malcol...@gmail.com] 
Sent: Tuesday, July 18, 2017 4:28 PM
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] TQSL's config.xml

 

Greg,

My question was more for information than for a real intent.  I have already 
done the FT8 mapping, and it is working quit well

Dan-K4SHQ

 

From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Tuesday, July 18, 2017 12:00 PM
To: 'WSJT software development'  >
Subject: Re: [wsjt-devel] TQSL's config.xml

 

You could ask Rick M., Dave, or one of the other Trusted QSL developers, but, I 
would think that adjustments to the client-side will have little to no 
affect—other than mapping the mode to data—until the server-side model has been 
updated to accommodate the new mode. 

 

Even if the ADIF spec is released today, the backend work would still need to 
be done before correct mapping of FT8 QSO’s could be realized. I don’t know 
what the LoTW eng/test/production release process is, but I would suspect work 
has already begun adding changes to the server model based on the proposed ADIF 
changes. 

 

I don’t really understand the urgency here. All one must do is hold back their 
FT8 QSO’s until the LoTW server is ready to accept them (as FT8 QSO’s that is). 
This situation “is not new”, it happens with every new mode / sub-mode 
introduction.

 

73’s

Greg, KI7MT

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Tuesday, July 18, 2017 10:15 AM
To: WSJT software development  >
Cc: Black Michael  >
Subject: Re: [wsjt-devel] TQSL's config.xml

 

3.0.6 has not had finally approval yet.

eQSL is just implementing it early.

I doubt ARRL will ever touch a draft ADIF spec.

 

de Mike W9MDB

 

 

  _  

From: Dan Malcolm  >
To: wsjtx-devel  > 
Sent: Tuesday, July 18, 2017 11:05 AM
Subject: [wsjt-devel] TQSL's config.xml

 

A question for smarter people than me.

 

TQSL’s config.xml contains all the modes acceptable to TQSL.  Instead of 
mapping FT8->DATA in TQSL, could I accomplish something similar but more 
accurate by inserting a new XML coded line in config.xml?

Insert a line like: “FT8”

 

This might even be moot, since the new ADIF spec is out and includes FT8.  

* LoTW’s website shows config.xml’s latest iteration is v11.0.  No 
mention of which ADIF spec.

* ADIF.ORG’s website still shows v3.0.5 as the latest. 

* eQSL says it’s using ADIF spec 3.0.6.

 

It’s entirely possible that ARRL will update config.xml soon on its own.

 

Dan – K4SHQ

 

--
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] AutoSeq Question

[Bill Somerville]

On 18/07/2017 23:18, Tim Carlson wrote:

I would expect that to be handled automatically.  Otherwise we should reliable 
the checkbox “Semi-Auto Seq”.


Hi Tim,

as I said, the QSO is complete for both parties when the RRR message has 
been sent, the rest is dependent of the band the mode of propagation, 
the means for stopping the QSO. Hard to fully automate without knowing 
what the operator expects and intends.


If you consider the QSO incomplete until you have confirmation that your 
73 message has been received then I suggest you should not look away 
from the QSO messages until you know that has happened.


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

[Black Michael via wsjt-devel]

I'd say the vast majority have no use for the slider anymore.So let's hide it 
by default and have an enable checkbox in the config.
I'll do that patch if you think that's acceptable...we'll still end up with 
"what happened to..." but se la vie... 
de Mike W9MDB

  From: Bill Somerville 
 To: wsjt-devel@lists.sourceforge.net 
 Sent: Tuesday, July 18, 2017 4:46 PM
 Subject: Re: [wsjt-devel] Ver 1.8 RC1 audio in slider problem
   
 On 18/07/2017 22:20, W4LDE-Ron wrote:
  
I recently download and installed WSJT-x 1.8.0 RC1 (R7843) over my existing 
1.7.1 and have run all modes successfully but
 I have noticed that the audio in slider doesn't function at all in the this 
latest version.
 
 I operate WIN10 with all current updates.  To test this bug I loaded a fresh 
install of 1.7.1 on a different PC, a Sony laptop and the audio in
 slider works as expected.  I then set the audio in for 30db.
 
 I installed ver 1.8.0 RC-1 over the 1.7.0.  The audio in behaved the same as 
on the 1st install on a HP desk top.  Whats interesting is that the audio in 
setting
 is exactly as left by ver 1.7 but again the slider will not function.
 Hi Ron, as has been discussed here and on the Yahoo wsjtgroup support group 
several times, the change in behaviour between v1.7 and v1.8 is that the slider 
no longer adjusts the level of the thermometer indicator next to it, it still 
effects the gain of both horizontal and vertical waterfalls and the 2D spectrum 
below the vertical waterfall. It never has effected the digital audio level to 
the decoders. The decoupling from the level indicator was done to reinforce the 
fact that it has no bearing on decoding and never has. The level indicator has 
become a bit smarter in v1.8 as it covers 90 dB (with respect to an ADC count 
of one) and it is colour coded to indicate excessively high or low signal 
levels. 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] TQSL's config.xml

[Dan Malcolm]

Thanks Dave, I was already aware of that and have done it.  The question was 
more for information that real intent.

 

Dan – K4SHQ

 

From: Dave AA6YQ [mailto:aa...@ambersoft.com] 
Sent: Tuesday, July 18, 2017 12:21 PM
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] TQSL's config.xml

 

You can configure TQSL to automatically “map” FT8 QSOs to DATA now, which will 
enable LoTW to accept them. See

 

https://lotw.arrl.org/lotw-help/pref-adi/

 

 73,

 

   Dave, AA6YQ

 

 

 

From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Tuesday, July 18, 2017 1:00 PM
To: 'WSJT software development'
Subject: Re: [wsjt-devel] TQSL's config.xml

 

You could ask Rick M., Dave, or one of the other Trusted QSL developers, but, I 
would think that adjustments to the client-side will have little to no 
affect—other than mapping the mode to data—until the server-side model has been 
updated to accommodate the new mode. 

 

Even if the ADIF spec is released today, the backend work would still need to 
be done before correct mapping of FT8 QSO’s could be realized. I don’t know 
what the LoTW eng/test/production release process is, but I would suspect work 
has already begun adding changes to the server model based on the proposed ADIF 
changes. 

 

I don’t really understand the urgency here. All one must do is hold back their 
FT8 QSO’s until the LoTW server is ready to accept them (as FT8 QSO’s that is). 
This situation “is not new”, it happens with every new mode / sub-mode 
introduction.

 

73’s

Greg, KI7MT

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Tuesday, July 18, 2017 10:15 AM
To: WSJT software development  >
Cc: Black Michael  >
Subject: Re: [wsjt-devel] TQSL's config.xml

 

3.0.6 has not had finally approval yet.

eQSL is just implementing it early.

I doubt ARRL will ever touch a draft ADIF spec.

 

de Mike W9MDB

 

 

  _  

From: Dan Malcolm  >
To: wsjtx-devel  > 
Sent: Tuesday, July 18, 2017 11:05 AM
Subject: [wsjt-devel] TQSL's config.xml

 

A question for smarter people than me.

 

TQSL’s config.xml contains all the modes acceptable to TQSL.  Instead of 
mapping FT8->DATA in TQSL, could I accomplish something similar but more 
accurate by inserting a new XML coded line in config.xml?

Insert a line like: “FT8”

 

This might even be moot, since the new ADIF spec is out and includes FT8.  

* LoTW’s website shows config.xml’s latest iteration is v11.0.  No 
mention of which ADIF spec.

* ADIF.ORG’s website still shows v3.0.5 as the latest. 

* eQSL says it’s using ADIF spec 3.0.6.

 

It’s entirely possible that ARRL will update config.xml soon on its own.

 

Dan – K4SHQ

 

--
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] TQSL's config.xml

[Dan Malcolm]

Greg,

My question was more for information than for a real intent.  I have already 
done the FT8 mapping, and it is working quit well

Dan-K4SHQ

 

From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Tuesday, July 18, 2017 12:00 PM
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] TQSL's config.xml

 

You could ask Rick M., Dave, or one of the other Trusted QSL developers, but, I 
would think that adjustments to the client-side will have little to no 
affect—other than mapping the mode to data—until the server-side model has been 
updated to accommodate the new mode. 

 

Even if the ADIF spec is released today, the backend work would still need to 
be done before correct mapping of FT8 QSO’s could be realized. I don’t know 
what the LoTW eng/test/production release process is, but I would suspect work 
has already begun adding changes to the server model based on the proposed ADIF 
changes. 

 

I don’t really understand the urgency here. All one must do is hold back their 
FT8 QSO’s until the LoTW server is ready to accept them (as FT8 QSO’s that is). 
This situation “is not new”, it happens with every new mode / sub-mode 
introduction.

 

73’s

Greg, KI7MT

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Tuesday, July 18, 2017 10:15 AM
To: WSJT software development  >
Cc: Black Michael  >
Subject: Re: [wsjt-devel] TQSL's config.xml

 

3.0.6 has not had finally approval yet.

eQSL is just implementing it early.

I doubt ARRL will ever touch a draft ADIF spec.

 

de Mike W9MDB

 

 

  _  

From: Dan Malcolm  >
To: wsjtx-devel  > 
Sent: Tuesday, July 18, 2017 11:05 AM
Subject: [wsjt-devel] TQSL's config.xml

 

A question for smarter people than me.

 

TQSL’s config.xml contains all the modes acceptable to TQSL.  Instead of 
mapping FT8->DATA in TQSL, could I accomplish something similar but more 
accurate by inserting a new XML coded line in config.xml?

Insert a line like: “FT8”

 

This might even be moot, since the new ADIF spec is out and includes FT8.  

* LoTW’s website shows config.xml’s latest iteration is v11.0.  No 
mention of which ADIF spec.

* ADIF.ORG’s website still shows v3.0.5 as the latest. 

* eQSL says it’s using ADIF spec 3.0.6.

 

It’s entirely possible that ARRL will update config.xml soon on its own.

 

Dan – K4SHQ

 

--
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] AutoSeq Question

[Tim Carlson]

Except that, as I said in my original message, I’m usually in my log book at 
that point, or looking at their QRZ page, or looking at a map to see who I 
contacted and where.  So by the time I get switched back to WSJT-X and click 
“Enable Tx”, it’s too late for my message to be decoded on the other end.  So 
they end up sending a third “RRR”.

I guess it comes down to the definition of “Auto” in “Auto Seq”.  If the 
software on the other end is looking for my “73” to end the sequence, I would 
expect that to be handled automatically.  Otherwise we should reliable the 
checkbox “Semi-Auto Seq”.  :)

-Tim KD0GYG


> On Jul 18, 2017, at 4:10 PM, Bill Somerville  wrote:
> 
> On 18/07/2017 22:56, Tim Carlson wrote:
>> Not sure how it’s QRM to try to finish the Auto Seq.  If the other guy’s 
>> Auto Seq keeps sending “RRR”, why should’t I try to reply with another “73” 
>> to complete the sequence?  I only operate on HF at this point, and during 
>> the QSO, that frequency is only shared by two QSO partners, isn’t it?
> 
> Hi Tim,
> 
> if you see another RRR then it is simple to click "Enable Tx" to repeat your 
> 73 message. Either way the QSO is complete and both sides can log it. The 73 
> back to the station sending RRR is really on a courtesy. These days most 
> stations have no interest in receiving a 73 message on HF and move on as soon 
> as they have sent RRR or RR73.
> 
> I would agree using MS or other marginal propagation paths, sending a few 73 
> messages to tell the original caller that they can stop sending is useful but 
> on MS and other fast modes there is plenty of time to decide to click a 
> button to repeat a 73 message.
> 
> 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] AutoSeq Question

[Tim Carlson]

Thanks, Gary - I didn’t see that option and haven’t tried it.

-Tim KD0GYG
> On Jul 18, 2017, at 3:44 PM, Gary McDuffie  wrote:
> 
> 
>> On Jul 18, 2017, at 11:26 AM, Tim Carlson  wrote:
>> 
>> OK, I get it - if the other person sends RRR, then never sends a final 73, I 
>> would be stuck sending 73 “forever” (I assume the Tx watchdog would still 
>> apply).
> 
> If you don’t want it to quit sending 73, turn it off in the config.  It’s on 
> the first tab.
> 
>> How about keep the current logic, but if I receive another RRR (they didn’t 
>> get my final 73), automatically send another 73, but keep Auto Tx disabled.
> 
> Why not let us have the ability to send the 73 X number of times and then 
> quit.  I’ve asked for that before.  I’d like to see it auto-try three times 
> (configurable) and then give up.  You can always reach up and click on the 
> HALT button to make it quit earlier.
> 
> Gary - AG0N
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


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

Re: [wsjt-devel] AutoSeq Question

[Bill Somerville]

On 18/07/2017 22:56, Tim Carlson wrote:

Not sure how it’s QRM to try to finish the Auto Seq.  If the other guy’s Auto 
Seq keeps sending “RRR”, why should’t I try to reply with another “73” to 
complete the sequence?  I only operate on HF at this point, and during the QSO, 
that frequency is only shared by two QSO partners, isn’t it?


Hi Tim,

if you see another RRR then it is simple to click "Enable Tx" to repeat 
your 73 message. Either way the QSO is complete and both sides can log 
it. The 73 back to the station sending RRR is really on a courtesy. 
These days most stations have no interest in receiving a 73 message on 
HF and move on as soon as they have sent RRR or RR73.


I would agree using MS or other marginal propagation paths, sending a 
few 73 messages to tell the original caller that they can stop sending 
is useful but on MS and other fast modes there is plenty of time to 
decide to click a button to repeat a 73 message.


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] AutoSeq Question

[Tim Carlson]

Not sure how it’s QRM to try to finish the Auto Seq.  If the other guy’s Auto 
Seq keeps sending “RRR”, why should’t I try to reply with another “73” to 
complete the sequence?  I only operate on HF at this point, and during the QSO, 
that frequency is only shared by two QSO partners, isn’t it?

Thanks!

-Tim KD0GYG

> On Jul 18, 2017, at 3:48 PM, Bill Somerville  wrote:
> 
> On 18/07/2017 22:44, Gary McDuffie wrote:
>> Why not let us have the ability to send the 73 X number of times and then 
>> quit.  I’ve asked for that before.  I’d like to see it auto-try three times 
>> (configurable) and then give up.  You can always reach up and click on the 
>> HALT button to make it quit earlier.
> 
> Hi Gary,
> 
> that only makes sense when a QSO is on a frequency shared only by two QSO 
> partners. On HF and 6m terrestrial it would likely create unnecessary QRM.
> 
> 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] AutoSeq Question

[Gary McDuffie]

> On Jul 18, 2017, at 3:48 PM, Bill Somerville  wrote:
> 
> that only makes sense when a QSO is on a frequency shared only by two QSO 
> partners. On HF and 6m terrestrial it would likely create unnecessary QRM.

Less than if you turn it off in the config and let it run forever.  

Gary
--
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] AutoSeq Question

[Bill Somerville]

On 18/07/2017 22:44, Gary McDuffie wrote:

Why not let us have the ability to send the 73 X number of times and then quit. 
 I’ve asked for that before.  I’d like to see it auto-try three times 
(configurable) and then give up.  You can always reach up and click on the HALT 
button to make it quit earlier.


Hi Gary,

that only makes sense when a QSO is on a frequency shared only by two 
QSO partners. On HF and 6m terrestrial it would likely create 
unnecessary QRM.


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

[Bill Somerville]

On 18/07/2017 22:20, W4LDE-Ron wrote:
I recently download and installed WSJT-x 1.8.0 RC1 (R7843) over my 
existing 1.7.1 and have run all modes successfully but
I have noticed that the audio in slider doesn't function at all in the 
this latest version.


I operate WIN10 with all current updates.  To test this bug I loaded a 
fresh install of 1.7.1 on a different PC, a Sony laptop and the audio in

slider works as expected.  I then set the audio in for 30db.

I installed ver 1.8.0 RC-1 over the 1.7.0.  The audio in behaved the 
same as on the 1st install on a HP desk top.  Whats interesting is 
that the audio in setting

is exactly as left by ver 1.7 but again the slider will not function.


Hi Ron,

as has been discussed here and on the Yahoo wsjtgroup support group 
several times, the change in behaviour between v1.7 and v1.8 is that the 
slider no longer adjusts the level of the thermometer indicator next to 
it, it still effects the gain of both horizontal and vertical waterfalls 
and the 2D spectrum below the vertical waterfall. It never has effected 
the digital audio level to the decoders. The decoupling from the level 
indicator was done to reinforce the fact that it has no bearing on 
decoding and never has.


The level indicator has become a bit smarter in v1.8 as it covers 90 dB 
(with respect to an ADC count of one) and it is colour coded to indicate 
excessively high or low signal levels.


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] AutoSeq Question

[Gary McDuffie]

> On Jul 18, 2017, at 11:26 AM, Tim Carlson  wrote:
> 
> OK, I get it - if the other person sends RRR, then never sends a final 73, I 
> would be stuck sending 73 “forever” (I assume the Tx watchdog would still 
> apply).

If you don’t want it to quit sending 73, turn it off in the config.  It’s on 
the first tab.

> How about keep the current logic, but if I receive another RRR (they didn’t 
> get my final 73), automatically send another 73, but keep Auto Tx disabled.

Why not let us have the ability to send the 73 X number of times and then quit. 
 I’ve asked for that before.  I’d like to see it auto-try three times 
(configurable) and then give up.  You can always reach up and click on the HALT 
button to make it quit earlier.

Gary - AG0N


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

Re: [wsjt-devel] Rovers and FT8

[Bill Somerville]

On 18/07/2017 22:34, Rich - K1HTV wrote:
Until/Unless this can be fixed, the answer is to manually step through 
the steps, which means you will have to always be on your toes with a 
quick mouse button trigger finger to successfully complete each QSO. I 
believe that this holds true for any complex station call with a slant 
bar in it.


Hi Rich,

not for long.

It is not too difficult to sort out since we have support for type one 
and type two compound calls (terminology of the compress message 
protocol) and /R suffixes are valid type 1 compound callsigns. It just 
needs a bit of adjustment to the auto-sequencing logic to get it working 
correctly. I am test an enhancement right now.


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

[W4LDE-Ron]

I recently download and installed WSJT-x 1.8.0 RC1 (R7843) over my 
existing 1.7.1 and have run all modes successfully but
I have noticed that the audio in slider doesn't function at all in the 
this latest version.


I operate WIN10 with all current updates. To test this bug I loaded a 
fresh install of 1.7.1 on a different PC, a Sony laptop and the audio in

slider works as expected.  I then set the audio in for 30db.

I installed ver 1.8.0 RC-1 over the 1.7.0.  The audio in behaved the 
same as on the 1st install on a HP desk top. Whats interesting is that 
the audio in setting

is exactly as left by ver 1.7 but again the slider will not function.

73 de Ron W4LDE






---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
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] Rovers and FT8

[Rich - K1HTV]

Tim,

  I believe that since the "/R" is eliminated from the exchanges, the original 
"CALL/R" which a station responds to does not match the "CALL" w/o the "/R" 
which is sent in subsequent steps. Since there isn't a match, it won't 
automatically proceed to the next step in the sequence. Until/Unless this can 
be fixed, the answer is to manually step through the steps, which means you 
will have to always be on your toes with a quick mouse button trigger finger to 
successfully complete each QSO. I believe that this holds true for any complex 
station call with a slant bar in it.


73,

Rich - K1HTV

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

Re: [wsjt-devel] WSJT-X: EME short codes in JT65 mode

[Joe Taylor]

Hi Bill,

On 7/18/2017 5:14 PM, Bill Somerville wrote:

I am reviewing handling of auto-sequencing and general responses to 
messages by double-clicking them. I have a question about JT65 short 
codes as used for EME QSOs.


There doesn't appear to be any automated way of moving from receiving an 
OOO report to sending an RO short code. Am I missing something? A double 
click on a received OOO report sends an OOO report back, shouldn't it 
send an RO message back?


I think EME users have always selected messages by clicking the 
appropriate "Next" RadioButton, rather than doubkle-clicking on a 
received "OOO" message.  But it seems OK to me to implement the logical 
behavior you describe.


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

[wsjt-devel] WSJT-X: EME short codes in JT65 mode

[Bill Somerville]

Hi All,

I am reviewing handling of auto-sequencing and general responses to 
messages by double-clicking them. I have a question about JT65 short 
codes as used for EME QSOs.


There doesn't appear to be any automated way of moving from receiving an 
OOO report to sending an RO short code. Am I missing something? A double 
click on a received OOO report sends an OOO report back, shouldn't it 
send an RO message back?


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 Bug in AutoSequencing For Rovers Using Callsign/R

[Bill Somerville]

On 18/07/2017 20:56, Tim Goeppinger via wsjt-devel wrote:
I think FT8 has a bright future for VHF Contests and Field Day, but I 
really struggled with it in the CQ WW VHF contest last weekend.


I believe I have discovered a bug that affects the couple of dozen 
hams who go roving in VHF Contests.   The contest rules say that as a 
rover,
we must use /R after our callsign.  I entered N6GP/R and my grid into 
WSJT-8, and tried FT8 during the contest a bit.   I had Autosequencing 
turned on, and I kept getting stuck in the signal report part of the 
QSO.   I was receiving signal report, and sending a report over and 
over again.  My QSOs were almost taking as much time to complete as a 
JT65 QSO!



Hi Tim,

I am sorting out some issues with auto-sequencing as or with type 1 & 2 
compound callsign holders. Hopefully the changes will be tested and 
ready for an RC2 release of WSJT-X v1.8.0.


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 Bug in AutoSequencing For Rovers Using Callsign/R

[Tim Goeppinger via wsjt-devel]

I think FT8 has a bright future for VHF Contests and Field Day, but I really 
struggled with it in the CQ WW VHF contest last weekend.
I believe I have discovered a bug that affects the couple of dozen hams who go 
roving in VHF Contests.   The contest rules say that as a rover,
we must use /R after our callsign.  I entered N6GP/R and my grid into WSJT-8, 
and tried FT8 during the contest a bit.   I had Autosequencing turned on, and I 
kept getting stuck in the signal report part of the QSO.   I was receiving 
signal report, and sending a report over and over again.  My QSOs were almost 
taking as much time to complete as a JT65 QSO!
I emailed Pat, N6RMJ, with whom I had one of these elongated FT8 QSOs.   I 
asked if there was some problem with my signal, and he said no.  I asked him to 
provide our QSO out of his ALL.TXT file.
N6RMJ is running WSJT-X V 1.8 r 14 with Win 7 Pro
Here are the QSO exchanges from the N6RMJ perspective
170716_193445  Transmitting 50.31 MHz  FT8:  CQ N6RMJ DM14    
193500 -10  0.6 1639 ~  N6RMJ N6GP DM14  
170716_193515  Transmitting 50.31 MHz  FT8:  N6GP N6RMJ -10   
193530  -9  0.1 1777 ~  DE N6GP/R R-15   
170716_193545  Transmitting 50.31 MHz  FT8:  N6GP N6RMJ -10   
193600  -9  0.6 1704 ~  DE N6GP/R R+00   
170716_193615  Transmitting 50.31 MHz  FT8:  N6GP N6RMJ -10   
170716_193615  Transmitting 50.31 MHz  FT8:  N6GP N6RMJ RRR   
193630  -9  0.6 1633 ~  DE N6GP/R R-19   
170716_193645  Transmitting 50.31 MHz  FT8:  N6GP N6RMJ RRR   
193700 -10  0.6 1705 ~  DE N6GP/R 73 
170716_193715  Transmitting 50.31 MHz  FT8:  N6GP N6RMJ 73
It appears that something went wrong with his autosequencer at 19:35:45 and 
19:36:15 because it was not seeing my signal reports and continued to send his 
signal reports.   Looks like he manually intervened during the 19:36:15 
transmission with a mouse click to send the RRR.  

I am not fully versed on how the autosequencer works. but for whatever reason, 
the "DE N6GP/R R-15" seemed to cause the problem.  Is the problem that the 
N6RMJ callsign is omitted, or that my callsign changed from the original N6GP 
to N6GP/R ?
For completeness, here is my side of the QSO from my ALL.TXT
N6GP/R running WSJT-X 1.8.0 rc1  with Window 7 Starter
193445  -4 -0.1 1739 ~  CQ N6RMJ DM14    
170716_193500  Transmitting 50.313 MHz  FT8:  N6RMJ N6GP DM14  
193515  -5 -0.1 1739 ~  N6GP N6RMJ -10   
 170716_193530  Transmitting 50.313 MHz  FT8:  DE N6GP/R R-15   
193545 -10 -0.1 1812 ~  N6GP N6RMJ -10   
  170716_193600  Transmitting 50.313 MHz  FT8:  DE N6GP/R R+00   
193615   0 -0.1 1740 ~  N6GP N6RMJ -10   
170716_193630  Transmitting 50.313 MHz  FT8:  DE N6GP/R R-19   
193645  -9 -0.1 1740 ~  N6GP N6RMJ RRR   
170716_193700  Transmitting 50.313 MHz  FT8:  DE N6GP/R 73 

Tnx & 73,
Tim N6GP


--
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] TQSL's config.xml

[Greg Beam]

Hi Dave,

 

OK, thanks for clearing that up. I knew something wasn’t straight forward, but 
could not recall what it was. The resubmission part is what was missing.

 

Thanks

 

Greg

 

From: Dave AA6YQ [mailto:aa...@ambersoft.com] 
Sent: Tuesday, July 18, 2017 2:01 PM
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] TQSL's config.xml

 

>>>AA6YQ comments below

 

From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Tuesday, July 18, 2017 2:02 PM
To: 'WSJT software development'
Subject: Re: [wsjt-devel] TQSL's config.xml

 

Hi Dave,

 

Thanks. I recall--vaguely--there being some issue with using this method before 
LoTW implements the mode. I don’t recall what it was offhand. Something to the 
affect that, once you’ve created the map, you (or LoTW) cannot go back and 
change it in the event the mapping we select locally differs from the 
server-side implementation. 

 

>>>That’s not correct. When LoTW accepts FT8 QSOs directly, you can remove the 
>>>automatic mapping to DATA from TQSL. At that point in time, it would be 
>>>polite to resubmit your FT8 QSOs to LoTW so that QSO partners pursuing an 
>>>FT8 WAS endorsement (if one is introduced) will get the “exact mode matches” 
>>>they need.

 

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] TQSL's config.xml

[Dave AA6YQ]

>>>AA6YQ comments below

 

From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Tuesday, July 18, 2017 2:02 PM
To: 'WSJT software development'
Subject: Re: [wsjt-devel] TQSL's config.xml

 

Hi Dave,

 

Thanks. I recall--vaguely--there being some issue with using this method before 
LoTW implements the mode. I don’t recall what it was offhand. Something to the 
affect that, once you’ve created the map, you (or LoTW) cannot go back and 
change it in the event the mapping we select locally differs from the 
server-side implementation. 

 

>>>That’s not correct. When LoTW accepts FT8 QSOs directly, you can remove the 
>>>automatic mapping to DATA from TQSL. At that point in time, it would be 
>>>polite to resubmit your FT8 QSOs to LoTW so that QSO partners pursuing an 
>>>FT8 WAS endorsement (if one is introduced) will get the “exact mode matches” 
>>>they need.

 

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] TQSL's config.xml

[Gordon Higgins]

YES eqsl  uploades  ft8  ok

On 18 July 2017 at 19:20, Ryan Tourge  wrote:

> It's my understanding that when FT8 is implemented you can upload as FT8
> and it will then confirm FT8 QSOs and unconfirm the DATA QSOs. I might be
> wrong.
>
> On Tue, Jul 18, 2017 at 2:02 PM, Greg Beam  wrote:
>
>> Hi Dave,
>>
>>
>>
>> Thanks. I recall--vaguely--there being some issue with using this method
>> before LoTW implements the mode. I don’t recall what it was offhand.
>> Something to the affect that, once you’ve created the map, you (or LoTW)
>> cannot go back and change it in the event the mapping we select locally
>> differs from the server-side implementation. Thus, for whatever reason at
>> the time, I chose to just wait for LoTW to implement the mode.
>>
>>
>>
>> I think when JT9 came out, there was discussion about the use of mapping
>> to data. However, I can’t recall exactly what the situation was. It may be
>> a moot point now. It may also I am confusing the RTTY to DATA debate, no
>> sure.
>>
>>
>>
>> 73’s
>>
>> Greg, KI7MT
>>
>>
>>
>>
>>
>> *From:* Dave AA6YQ [mailto:aa...@ambersoft.com]
>> *Sent:* Tuesday, July 18, 2017 11:21 AM
>> *To:* 'WSJT software development' 
>> *Subject:* Re: [wsjt-devel] TQSL's config.xml
>>
>>
>>
>> You can configure TQSL to automatically “map” FT8 QSOs to DATA now, which
>> will enable LoTW to accept them. See
>>
>>
>>
>> https://lotw.arrl.org/lotw-help/pref-adi/
>>
>>
>>
>>  73,
>>
>>
>>
>>Dave, AA6YQ
>>
>>
>>
>>
>>
>>
>>
>> *From:* Greg Beam [mailto:ki7m...@gmail.com ]
>> *Sent:* Tuesday, July 18, 2017 1:00 PM
>> *To:* 'WSJT software development'
>> *Subject:* Re: [wsjt-devel] TQSL's config.xml
>>
>>
>>
>> You could ask Rick M., Dave, or one of the other Trusted QSL developers,
>> but, I would think that adjustments to the client-side will have little to
>> no affect—other than mapping the mode to data—until the server-side model
>> has been updated to accommodate the new mode.
>>
>>
>>
>> Even if the ADIF spec is released today, the backend work would still
>> need to be done before correct mapping of FT8 QSO’s could be realized. I
>> don’t know what the LoTW eng/test/production release process is, but I
>> would suspect work has already begun adding changes to the server model
>> based on the proposed ADIF changes.
>>
>>
>>
>> I don’t really understand the urgency here. All one must do is hold back
>> their FT8 QSO’s until the LoTW server is ready to accept them (as FT8 QSO’s
>> that is). This situation “is not new”, it happens with every new mode /
>> sub-mode introduction.
>>
>>
>>
>> 73’s
>>
>> Greg, KI7MT
>>
>>
>>
>> *From:* Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourc
>> eforge.net ]
>> *Sent:* Tuesday, July 18, 2017 10:15 AM
>> *To:* WSJT software development 
>> *Cc:* Black Michael 
>> *Subject:* Re: [wsjt-devel] TQSL's config.xml
>>
>>
>>
>> 3.0.6 has not had finally approval yet.
>>
>> eQSL is just implementing it early.
>>
>> I doubt ARRL will ever touch a draft ADIF spec.
>>
>>
>>
>> de Mike W9MDB
>>
>>
>>
>>
>> --
>>
>> *From:* Dan Malcolm 
>> *To:* wsjtx-devel 
>> *Sent:* Tuesday, July 18, 2017 11:05 AM
>> *Subject:* [wsjt-devel] TQSL's config.xml
>>
>>
>>
>> A question for smarter people than me.
>>
>>
>>
>> TQSL’s config.xml contains all the modes acceptable to TQSL.  Instead of
>> mapping FT8->DATA in TQSL, could I accomplish something similar but more
>> accurate by inserting a new XML coded line in config.xml?
>>
>> Insert a line like: “FT8”
>>
>>
>>
>> This might even be moot, since the new ADIF spec is out and includes
>> FT8.
>>
>> · LoTW’s website shows config.xml’s latest iteration is v11.0.
>> No mention of which ADIF spec.
>>
>> · ADIF.ORG’s website still shows v3.0.5 as the latest.
>>
>> · eQSL says it’s using ADIF spec 3.0.6.
>>
>>
>>
>> It’s entirely possible that ARRL will update config.xml soon on its own.
>>
>>
>>
>> Dan – K4SHQ
>>
>>
>>
>> 
>> --
>> 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] TQSL's config.xml

[Ryan Tourge]

It's my understanding that when FT8 is implemented you can upload as FT8
and it will then confirm FT8 QSOs and unconfirm the DATA QSOs. I might be
wrong.

On Tue, Jul 18, 2017 at 2:02 PM, Greg Beam  wrote:

> Hi Dave,
>
>
>
> Thanks. I recall--vaguely--there being some issue with using this method
> before LoTW implements the mode. I don’t recall what it was offhand.
> Something to the affect that, once you’ve created the map, you (or LoTW)
> cannot go back and change it in the event the mapping we select locally
> differs from the server-side implementation. Thus, for whatever reason at
> the time, I chose to just wait for LoTW to implement the mode.
>
>
>
> I think when JT9 came out, there was discussion about the use of mapping
> to data. However, I can’t recall exactly what the situation was. It may be
> a moot point now. It may also I am confusing the RTTY to DATA debate, no
> sure.
>
>
>
> 73’s
>
> Greg, KI7MT
>
>
>
>
>
> *From:* Dave AA6YQ [mailto:aa...@ambersoft.com]
> *Sent:* Tuesday, July 18, 2017 11:21 AM
> *To:* 'WSJT software development' 
> *Subject:* Re: [wsjt-devel] TQSL's config.xml
>
>
>
> You can configure TQSL to automatically “map” FT8 QSOs to DATA now, which
> will enable LoTW to accept them. See
>
>
>
> https://lotw.arrl.org/lotw-help/pref-adi/
>
>
>
>  73,
>
>
>
>Dave, AA6YQ
>
>
>
>
>
>
>
> *From:* Greg Beam [mailto:ki7m...@gmail.com ]
> *Sent:* Tuesday, July 18, 2017 1:00 PM
> *To:* 'WSJT software development'
> *Subject:* Re: [wsjt-devel] TQSL's config.xml
>
>
>
> You could ask Rick M., Dave, or one of the other Trusted QSL developers,
> but, I would think that adjustments to the client-side will have little to
> no affect—other than mapping the mode to data—until the server-side model
> has been updated to accommodate the new mode.
>
>
>
> Even if the ADIF spec is released today, the backend work would still need
> to be done before correct mapping of FT8 QSO’s could be realized. I don’t
> know what the LoTW eng/test/production release process is, but I would
> suspect work has already begun adding changes to the server model based on
> the proposed ADIF changes.
>
>
>
> I don’t really understand the urgency here. All one must do is hold back
> their FT8 QSO’s until the LoTW server is ready to accept them (as FT8 QSO’s
> that is). This situation “is not new”, it happens with every new mode /
> sub-mode introduction.
>
>
>
> 73’s
>
> Greg, KI7MT
>
>
>
> *From:* Black Michael via wsjt-devel [mailto:wsjt-devel@lists.
> sourceforge.net ]
> *Sent:* Tuesday, July 18, 2017 10:15 AM
> *To:* WSJT software development 
> *Cc:* Black Michael 
> *Subject:* Re: [wsjt-devel] TQSL's config.xml
>
>
>
> 3.0.6 has not had finally approval yet.
>
> eQSL is just implementing it early.
>
> I doubt ARRL will ever touch a draft ADIF spec.
>
>
>
> de Mike W9MDB
>
>
>
>
> --
>
> *From:* Dan Malcolm 
> *To:* wsjtx-devel 
> *Sent:* Tuesday, July 18, 2017 11:05 AM
> *Subject:* [wsjt-devel] TQSL's config.xml
>
>
>
> A question for smarter people than me.
>
>
>
> TQSL’s config.xml contains all the modes acceptable to TQSL.  Instead of
> mapping FT8->DATA in TQSL, could I accomplish something similar but more
> accurate by inserting a new XML coded line in config.xml?
>
> Insert a line like: “FT8”
>
>
>
> This might even be moot, since the new ADIF spec is out and includes FT8.
>
> · LoTW’s website shows config.xml’s latest iteration is v11.0.
> No mention of which ADIF spec.
>
> · ADIF.ORG’s website still shows v3.0.5 as the latest.
>
> · eQSL says it’s using ADIF spec 3.0.6.
>
>
>
> It’s entirely possible that ARRL will update config.xml soon on its own.
>
>
>
> Dan – K4SHQ
>
>
>
> 
> --
> 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

Re: [wsjt-devel] TQSL's config.xml

[Greg Beam]

Hi Dave,

 

Thanks. I recall--vaguely--there being some issue with using this method before 
LoTW implements the mode. I don’t recall what it was offhand. Something to the 
affect that, once you’ve created the map, you (or LoTW) cannot go back and 
change it in the event the mapping we select locally differs from the 
server-side implementation. Thus, for whatever reason at the time, I chose to 
just wait for LoTW to implement the mode.

 

I think when JT9 came out, there was discussion about the use of mapping to 
data. However, I can’t recall exactly what the situation was. It may be a moot 
point now. It may also I am confusing the RTTY to DATA debate, no sure.

 

73’s

Greg, KI7MT

 

 

From: Dave AA6YQ [mailto:aa...@ambersoft.com] 
Sent: Tuesday, July 18, 2017 11:21 AM
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] TQSL's config.xml

 

You can configure TQSL to automatically “map” FT8 QSOs to DATA now, which will 
enable LoTW to accept them. See

 

https://lotw.arrl.org/lotw-help/pref-adi/

 

 73,

 

   Dave, AA6YQ

 

 

 

From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Tuesday, July 18, 2017 1:00 PM
To: 'WSJT software development'
Subject: Re: [wsjt-devel] TQSL's config.xml

 

You could ask Rick M., Dave, or one of the other Trusted QSL developers, but, I 
would think that adjustments to the client-side will have little to no 
affect—other than mapping the mode to data—until the server-side model has been 
updated to accommodate the new mode. 

 

Even if the ADIF spec is released today, the backend work would still need to 
be done before correct mapping of FT8 QSO’s could be realized. I don’t know 
what the LoTW eng/test/production release process is, but I would suspect work 
has already begun adding changes to the server model based on the proposed ADIF 
changes. 

 

I don’t really understand the urgency here. All one must do is hold back their 
FT8 QSO’s until the LoTW server is ready to accept them (as FT8 QSO’s that is). 
This situation “is not new”, it happens with every new mode / sub-mode 
introduction.

 

73’s

Greg, KI7MT

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Tuesday, July 18, 2017 10:15 AM
To: WSJT software development  >
Cc: Black Michael  >
Subject: Re: [wsjt-devel] TQSL's config.xml

 

3.0.6 has not had finally approval yet.

eQSL is just implementing it early.

I doubt ARRL will ever touch a draft ADIF spec.

 

de Mike W9MDB

 

 

  _  

From: Dan Malcolm  >
To: wsjtx-devel  > 
Sent: Tuesday, July 18, 2017 11:05 AM
Subject: [wsjt-devel] TQSL's config.xml

 

A question for smarter people than me.

 

TQSL’s config.xml contains all the modes acceptable to TQSL.  Instead of 
mapping FT8->DATA in TQSL, could I accomplish something similar but more 
accurate by inserting a new XML coded line in config.xml?

Insert a line like: “FT8”

 

This might even be moot, since the new ADIF spec is out and includes FT8.  

* LoTW’s website shows config.xml’s latest iteration is v11.0.  No 
mention of which ADIF spec.

* ADIF.ORG’s website still shows v3.0.5 as the latest. 

* eQSL says it’s using ADIF spec 3.0.6.

 

It’s entirely possible that ARRL will update config.xml soon on its own.

 

Dan – K4SHQ

 

--
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] AutoSeq Question

[Tim Carlson]

Hi Jim,

OK, I get it - if the other person sends RRR, then never sends a final 73, I 
would be stuck sending 73 “forever” (I assume the Tx watchdog would still 
apply).

How about keep the current logic, but if I receive another RRR (they didn’t get 
my final 73), automatically send another 73, but keep Auto Tx disabled.

-Tim

> On Jul 18, 2017, at 9:58 AM, James Shaver (N2ADV)  
> wrote:
> 
> Hi, Tim - it prevents endless sending of "73" - someone could inadvertently 
> forget to disable their TX and get up to get a cup of coffee (or, uh, get rid 
> of said coffee), pet the cat, feed the kids, etc and keep sending 73 over and 
> over. I disable Auto after my report goes out and switch to manual to prevent 
> the situation you describe :)
> 
> 73!
> Jim S. 
> N2ADV
> 
>> On Jul 18, 2017, at 10:56 AM, Tim Carlson  wrote:
>> 
>> Hi All,
>> 
>> I have a general question about Auto Seq when answering a CQ call.
>> 
>> Out of 78 completed QSO’s with FT8 and Auto Seq, at least a dozen of them 
>> (when I’m answering a CQ) end with me sending “73” which disables my Auto 
>> Tx, then receiving another “RRR”.  I have to then scramble and click “Enable 
>> Tx” again, which usually isn’t very timely because I’m in my logbook, 
>> looking up the QRZ page of my QSO partner, or looking at a map of their 
>> location.
>> 
>> Is there a reason that Auto Tx is disabled on my “73” rather than on receipt 
>> of the other person’s “73”?  I don’t want to leave my partner endlessly 
>> calling “RRR”.
>> 
>> Thanks!
>> 
>> -Tim KD0GYG
>> --
>> 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] TQSL's config.xml

[Dave AA6YQ]

You can configure TQSL to automatically “map” FT8 QSOs to DATA now, which will 
enable LoTW to accept them. See

 

https://lotw.arrl.org/lotw-help/pref-adi/

 

 73,

 

   Dave, AA6YQ

 

 

 

From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Tuesday, July 18, 2017 1:00 PM
To: 'WSJT software development'
Subject: Re: [wsjt-devel] TQSL's config.xml

 

You could ask Rick M., Dave, or one of the other Trusted QSL developers, but, I 
would think that adjustments to the client-side will have little to no 
affect—other than mapping the mode to data—until the server-side model has been 
updated to accommodate the new mode. 

 

Even if the ADIF spec is released today, the backend work would still need to 
be done before correct mapping of FT8 QSO’s could be realized. I don’t know 
what the LoTW eng/test/production release process is, but I would suspect work 
has already begun adding changes to the server model based on the proposed ADIF 
changes. 

 

I don’t really understand the urgency here. All one must do is hold back their 
FT8 QSO’s until the LoTW server is ready to accept them (as FT8 QSO’s that is). 
This situation “is not new”, it happens with every new mode / sub-mode 
introduction.

 

73’s

Greg, KI7MT

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Tuesday, July 18, 2017 10:15 AM
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] TQSL's config.xml

 

3.0.6 has not had finally approval yet.

eQSL is just implementing it early.

I doubt ARRL will ever touch a draft ADIF spec.

 

de Mike W9MDB

 

 

  _  

From: Dan Malcolm 
To: wsjtx-devel  
Sent: Tuesday, July 18, 2017 11:05 AM
Subject: [wsjt-devel] TQSL's config.xml

 

A question for smarter people than me.

 

TQSL’s config.xml contains all the modes acceptable to TQSL.  Instead of 
mapping FT8->DATA in TQSL, could I accomplish something similar but more 
accurate by inserting a new XML coded line in config.xml?

Insert a line like: “FT8”

 

This might even be moot, since the new ADIF spec is out and includes FT8.  

· LoTW’s website shows config.xml’s latest iteration is v11.0.  No 
mention of which ADIF spec.

· ADIF.ORG’s website still shows v3.0.5 as the latest. 

· eQSL says it’s using ADIF spec 3.0.6.

 

It’s entirely possible that ARRL will update config.xml soon on its own.

 

Dan – K4SHQ

 

--
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] TQSL's config.xml

[Greg Beam]

You could ask Rick M., Dave, or one of the other Trusted QSL developers, but, I 
would think that adjustments to the client-side will have little to no 
affect—other than mapping the mode to data—until the server-side model has been 
updated to accommodate the new mode. 

 

Even if the ADIF spec is released today, the backend work would still need to 
be done before correct mapping of FT8 QSO’s could be realized. I don’t know 
what the LoTW eng/test/production release process is, but I would suspect work 
has already begun adding changes to the server model based on the proposed ADIF 
changes. 

 

I don’t really understand the urgency here. All one must do is hold back their 
FT8 QSO’s until the LoTW server is ready to accept them (as FT8 QSO’s that is). 
This situation “is not new”, it happens with every new mode / sub-mode 
introduction.

 

73’s

Greg, KI7MT

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Tuesday, July 18, 2017 10:15 AM
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] TQSL's config.xml

 

3.0.6 has not had finally approval yet.

eQSL is just implementing it early.

I doubt ARRL will ever touch a draft ADIF spec.

 

de Mike W9MDB

 

 

  _  

From: Dan Malcolm  >
To: wsjtx-devel  > 
Sent: Tuesday, July 18, 2017 11:05 AM
Subject: [wsjt-devel] TQSL's config.xml

 

A question for smarter people than me.

 

TQSL’s config.xml contains all the modes acceptable to TQSL.  Instead of 
mapping FT8->DATA in TQSL, could I accomplish something similar but more 
accurate by inserting a new XML coded line in config.xml?

Insert a line like: “FT8”

 

This might even be moot, since the new ADIF spec is out and includes FT8.  

* LoTW’s website shows config.xml’s latest iteration is v11.0.  No 
mention of which ADIF spec.

* ADIF.ORG’s website still shows v3.0.5 as the latest. 

* eQSL says it’s using ADIF spec 3.0.6.

 

It’s entirely possible that ARRL will update config.xml soon on its own.

 

Dan – K4SHQ

 

--
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] TQSL's config.xml

[Dan Malcolm]

Mike, 

I agree with that assessment.  I did not realize that ADIF 3.0.6 was still 
draft, but since it is, that explains a lot.  While changing my end is easy, 
that doesn’t make it the right thing to do.  I will stay with what I have until 
ARRL makes the change.

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Tuesday, July 18, 2017 11:15 AM
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] TQSL's config.xml

 

3.0.6 has not had finally approval yet.

eQSL is just implementing it early.

I doubt ARRL will ever touch a draft ADIF spec.

 

de Mike W9MDB

 

 

  _  

From: Dan Malcolm  >
To: wsjtx-devel  > 
Sent: Tuesday, July 18, 2017 11:05 AM
Subject: [wsjt-devel] TQSL's config.xml

 

A question for smarter people than me.

 

TQSL’s config.xml contains all the modes acceptable to TQSL.  Instead of 
mapping FT8->DATA in TQSL, could I accomplish something similar but more 
accurate by inserting a new XML coded line in config.xml?

Insert a line like: “FT8”

 

This might even be moot, since the new ADIF spec is out and includes FT8.  

* LoTW’s website shows config.xml’s latest iteration is v11.0.  No 
mention of which ADIF spec.

* ADIF.ORG’s website still shows v3.0.5 as the latest. 

* eQSL says it’s using ADIF spec 3.0.6.

 

It’s entirely possible that ARRL will update config.xml soon on its own.

 

Dan – K4SHQ

 

--
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] TQSL's config.xml

[Dan Malcolm]

Bill,

I had that same thought, hence my query.  While changing my end is easy,
that doesn't make it the right thing to do.  I will stay with what I have
until ARRL makes the change.

Thanks

 

Dan - K4SHQ

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Tuesday, July 18, 2017 11:08 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] TQSL's config.xml

 

On 18/07/2017 17:02, Dan Malcolm wrote:

TQSL's config.xml contains all the modes acceptable to TQSL.  Instead of
mapping FT8->DATA in TQSL, could I accomplish something similar but more
accurate by inserting a new XML coded line in config.xml?

Insert a line like: "FT8"

Hi Dan,

I doubt that will work as it probably has to match capability on the LotW
server which will not be prepared to accept ADIF records from you specifying
the mode as FT8. I would take the tQSL configuration file as private to the
LotW developers and leave it alone.

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] TQSL's config.xml

[Black Michael via wsjt-devel]

3.0.6 has not had finally approval yet.eQSL is just implementing it early.I 
doubt ARRL will ever touch a draft ADIF spec.
de Mike W9MDB

  From: Dan Malcolm 
 To: wsjtx-devel  
 Sent: Tuesday, July 18, 2017 11:05 AM
 Subject: [wsjt-devel] TQSL's config.xml
   
A question for smarter people than me.  TQSL’s 
config.xml contains all the modes acceptable to TQSL.  Instead of mapping 
FT8->DATA in TQSL, could I accomplish something similar but more accurate by 
inserting a new XML coded line in config.xml?Insert a line like: “FT8”  This might even be moot, since the 
new ADIF spec is out and includes FT8.  · LoTW’s website shows 
config.xml’s latest iteration is v11.0.  No mention of which ADIF spec.·
 ADIF.ORG’s website still shows v3.0.5 as the latest. · eQSL says it’s 
using ADIF spec 3.0.6.  It’s entirely possible that ARRL will update config.xml 
soon on its own.  Dan – K4SHQ  
--
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] TQSL's config.xml

[Bill Somerville]

On 18/07/2017 17:02, Dan Malcolm wrote:


TQSL’s config.xml contains all the modes acceptable to TQSL.  Instead 
of mapping FT8->DATA in TQSL, could I accomplish something similar but 
more accurate by inserting a new XML coded line in config.xml?


Insert a line like: “FT8”


Hi Dan,

I doubt that will work as it probably has to match capability on the 
LotW server which will not be prepared to accept ADIF records from you 
specifying the mode as FT8. I would take the tQSL configuration file as 
private to the LotW developers and leave it alone.


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] TQSL's config.xml

[Dan Malcolm]

A question for smarter people than me.

 

TQSL's config.xml contains all the modes acceptable to TQSL.  Instead of
mapping FT8->DATA in TQSL, could I accomplish something similar but more
accurate by inserting a new XML coded line in config.xml?

Insert a line like: "FT8"

 

This might even be moot, since the new ADIF spec is out and includes FT8.  

* LoTW's website shows config.xml's latest iteration is v11.0.  No
mention of which ADIF spec.

* ADIF.ORG's website still shows v3.0.5 as the latest. 

* eQSL says it's using ADIF spec 3.0.6.

 

It's entirely possible that ARRL will update config.xml soon on its own.

 

Dan - K4SHQ

 

--
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] AutoSeq Question

[James Shaver (N2ADV)]

Hi, Tim - it prevents endless sending of "73" - someone could inadvertently 
forget to disable their TX and get up to get a cup of coffee (or, uh, get rid 
of said coffee), pet the cat, feed the kids, etc and keep sending 73 over and 
over. I disable Auto after my report goes out and switch to manual to prevent 
the situation you describe :)

73!
Jim S. 
N2ADV

> On Jul 18, 2017, at 10:56 AM, Tim Carlson  wrote:
> 
> Hi All,
> 
> I have a general question about Auto Seq when answering a CQ call.
> 
> Out of 78 completed QSO’s with FT8 and Auto Seq, at least a dozen of them 
> (when I’m answering a CQ) end with me sending “73” which disables my Auto Tx, 
> then receiving another “RRR”.  I have to then scramble and click “Enable Tx” 
> again, which usually isn’t very timely because I’m in my logbook, looking up 
> the QRZ page of my QSO partner, or looking at a map of their location.
> 
> Is there a reason that Auto Tx is disabled on my “73” rather than on receipt 
> of the other person’s “73”?  I don’t want to leave my partner endlessly 
> calling “RRR”.
> 
> Thanks!
> 
> -Tim KD0GYG
> --
> 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] AutoSeq Question

[Tim Carlson]

Hi All,

I have a general question about Auto Seq when answering a CQ call.

Out of 78 completed QSO’s with FT8 and Auto Seq, at least a dozen of them (when 
I’m answering a CQ) end with me sending “73” which disables my Auto Tx, then 
receiving another “RRR”.  I have to then scramble and click “Enable Tx” again, 
which usually isn’t very timely because I’m in my logbook, looking up the QRZ 
page of my QSO partner, or looking at a map of their location.

Is there a reason that Auto Tx is disabled on my “73” rather than on receipt of 
the other person’s “73”?  I don’t want to leave my partner endlessly calling 
“RRR”.

Thanks!

-Tim KD0GYG
--
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 Mode Does Not Stop Transmitting

[Jordan Sherer]

Hi all. I've recently run into a problem with my Elecraft KX2 running FT8 in 
the release candidate version of WSJTX.

Frequently the Elecraft won't unkey at the end of the transmission when 
operating FT8. I noticed that, in general, CAT control is a little slow with 
the KX2 anyway, so I'm wondering if the fast progression of FT8 is causing a 
command to be missed.

I haven't figured out a way to reproduce the behavior 100% of the time, but it 
does seem to happen most frequently on partial transmissions (say, replying 
late to a CQ by a few seconds). I'll continue digging here to see if I can 
verify.

This behavior has never happened in JT65 and JT9 modes.

Any thoughts as to what might be going on here?

Best,
Jordan
KN4CRD--
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] HALT fails to work - r7925

[dgb]

When xmtg the HALT button don't stop transmission

73 Dwight NS9I


--
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] Double Answers Appearing in Rx Window - r7925

[dgb]

Same here - everytime.

73 Dwight NS9I


On 7/17/2017 9:57 PM, Neil Zampella wrote:

Meant Rx frequency window .. :(


On 7/17/2017 10:45 PM, Neil Zampella wrote:
V1.7.1-r7925 ... double entries in Tx window when replying via Auto 
Sequence.


Neil, KN3ILZ




-- 


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] Suggestions for three extra bits in FT8

[Adrian Fabry]

Sorry please ingonre these 2 lines:

  P5DX DB0AAA -10
DB0AAA P5DX R-14 QRZ



On Tue, Jul 18, 2017 at 11:00 AM, Adrian Fabry  wrote:

> Hi all,
>
> with these 3 bits we can have 8 combinations, actually 7 usable, one is by
> default (let's say 000) for current messages types (standard of free).
>
> I would propose to use 1 combination (001) for DXpedition mode:
> - 001 when CQ or QRZ in DXpedition mode. This will instruct callers to
> spread in freq and to expect a shorter sequence.
> - 001 when DX is confirming the report from the caller. Will display a
> message like:
> *YO2NAA P5DX RRR QRZ*
>
> This message if decoded by YO2NAA will stop TX and prompt for LOG (if
> enabled).
>
> The full sequence:
>
> *=CQ P5DX PM29*  - contains 001  -  The* =* sign before CQ is displayed
> by WSJT to indicate DXped mode CQ. In addition can also be a different
> color)
>   *P5DX YO2NAA KN05*
> *YO2NAA P5DX -17*
> *  P5DX YO2NAA R-12*
> *YO2NAA P5DX RRR QRZ*- contains 001  (actually the message is YO2NAA
> P5DX RRR, but QRZ will be displayed by WSJT when detect 001)
>
>   P5DX DB0AAA -10
> DB0AAA P5DX R-14 QRZ
> etc
>
> If the caller used TX2 instead of TX1:
>
> *=CQ P5DX PM29  * - contains 001
>  *P5DX YO2NAA -12*
> *YO2NAA P5DX R-17*
> *  P5DX YO2NAA RRR*
> *YO2NAA P5DX 73 QRZ* - contains 001
>
>
> Other combinations of the 3 bits can be used for contest modes. Can be
> different type of contests, MSK144 (CQ WW VHF) style or different.
>
> 73 Ady,
> YO2NAA
>
>
>
>
> On Wed, Jul 12, 2017 at 1:28 AM, Tim Carlson  wrote:
>
>> Thanks, everyone for the discussion.
>>
>> The biggest takeaway for me is that I shouldn't use the wide graph to
>> determine the quality of the signal, which helps.
>>
>> I do have a waterfall display on my IC-7300, but it has nowhere near the
>> resolution of the wsjt-x wide graph so it’s not very helpful either.
>>
>> I’ll be quiet now!  :)
>>
>> -Tim KD0GYG
>>
>> > On Jul 11, 2017, at 1:54 PM, James Shaver (N2ADV) 
>> wrote:
>> >
>> > If you throw attenuation at the signal and the issue goes away, the
>> cause is most likely on the receive side.  It also helps to have a
>> panadapter available (something that isn't tied into the AF chain).  The
>> waterfall itself should not be used to determine signal quality.
>> >
>> > 73,
>> >
>> > Jim S.
>> > N2ADV
>> >
>> >> On Jul 11, 2017, at 2:45 PM, Bill Somerville 
>> wrote:
>> >>
>> >>> On 11/07/2017 19:12, Tim Carlson wrote:
>> >>> Would you consider that the first signal on the left is being
>> overdriven somewhat?  Or is that just a consequence of a stronger signal?
>> Or is it some atmospheric condition causing the signal to spread?
>> >>>
>> >> Hi Tim,
>> >>
>> >> hard to tell but it is all too common for the Tx audio level fed to
>> the rig to be too high. This causes non-linearity and will almost certainly
>> widen the transmitted signal. The main product of clipping is harmonics but
>> if the sender is using the split operating facility that is largely
>> innocuous due to the harmonics being above 3000 Hz and attenuated by the
>> rig's Tx SSB filter low pass cut off. Still there is no excuse for over
>> driving the audio input to the rig and there is a secondary consequence. At
>> each frequency shift of the modulation there is a minimal phase
>> discontinuity, we shift the phase without a glitch but nevertheless it is a
>> discontinuity. These small discontinuities fractionally widen the signal
>> when the audio is correctly matched through to the transmitter but over
>> drive widens them considerably. This is what you are seeing, a horizontal
>> spike on the waterfall at each tone shift.
>> >>
>> >> You must also be careful about attributing blame in these situations,
>> all of the above can happen on the receiving side too, so check your own
>> house is in order before accusing another of having a poor signal.
>> >>
>> >> 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
>> 

Re: [wsjt-devel] Suggestions for three extra bits in FT8

[Adrian Fabry]

Hi all,

with these 3 bits we can have 8 combinations, actually 7 usable, one is by
default (let's say 000) for current messages types (standard of free).

I would propose to use 1 combination (001) for DXpedition mode:
- 001 when CQ or QRZ in DXpedition mode. This will instruct callers to
spread in freq and to expect a shorter sequence.
- 001 when DX is confirming the report from the caller. Will display a
message like:
*YO2NAA P5DX RRR QRZ*

This message if decoded by YO2NAA will stop TX and prompt for LOG (if
enabled).

The full sequence:

*=CQ P5DX PM29*  - contains 001  -  The* =* sign before CQ is displayed by
WSJT to indicate DXped mode CQ. In addition can also be a different color)
  *P5DX YO2NAA KN05*
*YO2NAA P5DX -17*
*  P5DX YO2NAA R-12*
*YO2NAA P5DX RRR QRZ*- contains 001  (actually the message is YO2NAA
P5DX RRR, but QRZ will be displayed by WSJT when detect 001)

  P5DX DB0AAA -10
DB0AAA P5DX R-14 QRZ
etc

If the caller used TX2 instead of TX1:

*=CQ P5DX PM29  * - contains 001
 *P5DX YO2NAA -12*
*YO2NAA P5DX R-17*
*  P5DX YO2NAA RRR*
*YO2NAA P5DX 73 QRZ* - contains 001


Other combinations of the 3 bits can be used for contest modes. Can be
different type of contests, MSK144 (CQ WW VHF) style or different.

73 Ady,
YO2NAA




On Wed, Jul 12, 2017 at 1:28 AM, Tim Carlson  wrote:

> Thanks, everyone for the discussion.
>
> The biggest takeaway for me is that I shouldn't use the wide graph to
> determine the quality of the signal, which helps.
>
> I do have a waterfall display on my IC-7300, but it has nowhere near the
> resolution of the wsjt-x wide graph so it’s not very helpful either.
>
> I’ll be quiet now!  :)
>
> -Tim KD0GYG
>
> > On Jul 11, 2017, at 1:54 PM, James Shaver (N2ADV) 
> wrote:
> >
> > If you throw attenuation at the signal and the issue goes away, the
> cause is most likely on the receive side.  It also helps to have a
> panadapter available (something that isn't tied into the AF chain).  The
> waterfall itself should not be used to determine signal quality.
> >
> > 73,
> >
> > Jim S.
> > N2ADV
> >
> >> On Jul 11, 2017, at 2:45 PM, Bill Somerville 
> wrote:
> >>
> >>> On 11/07/2017 19:12, Tim Carlson wrote:
> >>> Would you consider that the first signal on the left is being
> overdriven somewhat?  Or is that just a consequence of a stronger signal?
> Or is it some atmospheric condition causing the signal to spread?
> >>>
> >> Hi Tim,
> >>
> >> hard to tell but it is all too common for the Tx audio level fed to the
> rig to be too high. This causes non-linearity and will almost certainly
> widen the transmitted signal. The main product of clipping is harmonics but
> if the sender is using the split operating facility that is largely
> innocuous due to the harmonics being above 3000 Hz and attenuated by the
> rig's Tx SSB filter low pass cut off. Still there is no excuse for over
> driving the audio input to the rig and there is a secondary consequence. At
> each frequency shift of the modulation there is a minimal phase
> discontinuity, we shift the phase without a glitch but nevertheless it is a
> discontinuity. These small discontinuities fractionally widen the signal
> when the audio is correctly matched through to the transmitter but over
> drive widens them considerably. This is what you are seeing, a horizontal
> spike on the waterfall at each tone shift.
> >>
> >> You must also be careful about attributing blame in these situations,
> all of the above can happen on the receiving side too, so check your own
> house is in order before accusing another of having a poor signal.
> >>
> >> 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
>
--
Check out the