Re: [wsjt-devel] DXpedition Mode Test Results

2018-03-07 Thread gary 
Some of the participants may have been deliberately breaking the rules as part 
of the test.  

It wasn't made clear, in advance, whether we should simply pretend the fox was 
real to simulate a genuine deep DX pileup, or do weird stuff to check how 
resilient the whole thing is.

I guess the team already has the wherewithal to generate WAVs simulating 
conventional pileups of arbitrary depth, perhaps even test setups with banks of 
hound-simulators calling and making simulated QSOs with the fox ... but 
replicating all the weirdness and antisocial goings-on that happen in real HF 
pileups, along with the propagation and path anomalies (such as polar flutter 
and multipath DX sigs) is a tough ask.  So, I guess some of the participants 
went intentionally weird.

I wondered about the XE station on 20, for instance: he could easily have been 
a deliberate part of the test, perhaps primed by Joe to call CQ or mess around. 
 Likewise with those participants who didn't read or heed the instructions: 
some may have knowinly avoided using DXpedition mode to see what happened.

Something to think about for the next test maybe?  Maybe not.  Spontaneous and 
accidental weirdness may be testing enough!

73
Gary  ZL2iFB

-Original Message-
From: Alex, VE3NEA <alsh...@dxatlas.com> 
Sent: Thursday, 8 March 2018 10:11 a.m.
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] DXpedition Mode Test Results


> - Of course, some Hounds did not operate as intended.  Several kept trying to 
> raise Fox by calling below 1000 Hz.  

Perhaps the software should block attempts to send Tx1 below 1000 Hz if Hound 
mode is enabled, and show a popup message explaining why transmission did not 
start.

73 Alex VE3NEA

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


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

Re: [wsjt-devel] DXpedition Mode Test Results

2018-03-07 Thread Gary McDuffie 


> On Mar 7, 2018, at 1:27 PM, Joe Taylor  wrote:
> 
> I'm sure there is more to be said, but that will do for now.  Depending on 
> programming progress and on my own travel schedule, we may schedule another 
> public test within a few weeks.

Thanks for the great job, Joe.  It’s clear that lots of work went into this and 
I look forward to more tests.  I just hope I can be available to do a better 
job of it.  

I like the idea of randomizing for the fox, and maybe even for the hounds, but 
I wonder if that eliminates the ability for the hound to manually bounce around 
dodging other signals.

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] DXpedition Mode Test Results

2018-03-07 Thread Alex, VE3NEA 


- Of course, some Hounds did not operate as intended.  Several kept trying to raise Fox by calling below 1000 Hz.  


Perhaps the software should block attempts to send Tx1 below 1000 Hz if Hound mode is enabled, and show a popup message 
explaining why transmission did not start.


73 Alex VE3NEA

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

Re: [wsjt-devel] DXpedition Mode Test Results

2018-03-07 Thread John Zantek 
Magnificent summary.  Bravo!

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: Wednesday, March 7, 2018 12:28 PM
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: [wsjt-devel] DXpedition Mode Test Results

Hi all,

Here are a few highlights of results from last night's public test of
FT8 DXpedition Mode:

  - The overwhelming majority of participating Hounds operated as intended,
and according to instructions.  I copied 190 unique Hound callsigns during
the 2300 hour (when I was acting as Fox on 20m) and 330 unique callsigns
during the whole four hours.  I suppose that we had at least 400-500
participants, maybe more.

- Fox's multi-signal capability worked very well at the tested values,
NSlots = 3, 4, and 5.  This feature is surely a "keeper", and I see no
reason not to use NSlots = 5 -- especially if Fox is running power.

  - In the four test hours the number of "QSOs" logged by Foxes on 20, 30,
40, and 80m was 320, 189, 454, and 351.  However, a regrettable program bug
was preventing deletion of Hound callsigns from Fox's "QSO-in-Progress" list
after a QSO had been logged.  As a result, many repeated "RR73" messages
were sent, many dupe QSOs were logged, and the QSO-in-Progress list kept
growing.  As another consequence, some QSOs took up to ~20 min to complete,
and a number of Hounds who had been sent a report never received their
QSO-confirming "RR73".

- AA7A actually worked 120 unique calls in the 40m hour, and the other Foxes
worked comparable slightly lower numbers.  When this program bug is
corrected, hourly QSO in the 300-400 range should certainly be achievable.

- Of course, some Hounds did not operate as intended.  Several kept trying
to raise Fox by calling below 1000 Hz.  (Most of these that I noticed were
from non-English speaking countries.  We will probably need translations of
the FT8 DXpedition Mode User Guide.)  A few would-be Hounds were not
obviously not using v1.9.0-rc2, and were calling Fox "blind" in 1st
sequence.  A few Hounds tried using compound callsigns, which is not
supported -- and which needs to be made more clear in the instructions.

- Nearly everybody noticed the XE1GK calling CQ on the low-end Fox frequency
and working people these.  Please don't be too hard on
Ignacio: he obviously misunderstood what was supposed to be happening, and
how to operate in the test run.  He sent me an abject apology. 
Anyway, his signal helped us to evaluate how well we can cope with QRM and
DQRM.

Two operating hints that should be used as needed, but in general were not:

  - Hounds should manually reset their Tx frequency as needed to evade QRM.

  - Fox may decide to use the randomizing feature to vary his own Tx
frequency.


I list here some relatively minor bugs and other things that came to 
light during the test run:

  - Spurious "Callsign mismatch" warning messages were displayed to the 
Fox operator.

  - Fox's log window should automatically scroll to the bottom.  Or 
maybe it should simply show the most recent ~10 QSOs logged.

  - I'm not sure that Fox's "Max Calls" parameter worked as designed.

  - Sometimes Fox sent RR73 to the same station in more that one slot, 
in the same transmission.

  - The dreaded "Blue Decode" button was seen by some.

  - Hounds sometimes send a spuriously low signal report to Fox, even 
when Fox is loud.

  - If Hound hits "Enter" with the DX Call box empty, a blank message 
can be transmitted.

  - It a random station (not Fox) calls a Hound, it can trigger a Hound 
transmission just as if Fox had called.

  - Previously decoded Hound calls can sometimes reappear in Fox's left 
window, when they should not.


Finally, let me outline a few new features we may decide to implement.

  - At least for debugging, and possibly as an option, offer a display 
window that shows the Fox operator the contents of all active queues.

  - Limit the number of QSOs in progress to no more than NSlots.

  - Option to suppress display of the waterfall timestamp.

  - Have Fox call CQ in one slot at least once every few (1 or 2?) minutes.

  - Should Hound's Tx3 frequency be re-randomized for each repeat try?

I'm sure there is more to be said, but that will do for now.  Depending 
on programming progress and on my own travel schedule, we may schedule 
another public test within a few weeks.

-- 73, Joe, K1JT


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


--
Check out the vib

[wsjt-devel] DXpedition Mode Test Results

2018-03-07 Thread Joe Taylor 

Hi all,

Here are a few highlights of results from last night's public test of 
FT8 DXpedition Mode:


 - The overwhelming majority of participating Hounds operated as 
intended, and according to instructions.  I copied 190 unique Hound 
callsigns during the 2300 hour (when I was acting as Fox on 20m) and 330 
unique callsigns during the whole four hours.  I suppose that we had at 
least 400-500 participants, maybe more.


- Fox's multi-signal capability worked very well at the tested values, 
NSlots = 3, 4, and 5.  This feature is surely a "keeper", and I see no 
reason not to use NSlots = 5 -- especially if Fox is running power.


 - In the four test hours the number of "QSOs" logged by Foxes on 20, 
30, 40, and 80m was 320, 189, 454, and 351.  However, a regrettable 
program bug was preventing deletion of Hound callsigns from Fox's 
"QSO-in-Progress" list after a QSO had been logged.  As a result, many 
repeated "RR73" messages were sent, many dupe QSOs were logged, and the 
QSO-in-Progress list kept growing.  As another consequence, some QSOs 
took up to ~20 min to complete, and a number of Hounds who had been sent 
a report never received their QSO-confirming "RR73".


- AA7A actually worked 120 unique calls in the 40m hour, and the other 
Foxes worked comparable slightly lower numbers.  When this program bug 
is corrected, hourly QSO in the 300-400 range should certainly be 
achievable.


- Of course, some Hounds did not operate as intended.  Several kept 
trying to raise Fox by calling below 1000 Hz.  (Most of these that I 
noticed were from non-English speaking countries.  We will probably need 
translations of the FT8 DXpedition Mode User Guide.)  A few would-be 
Hounds were not obviously not using v1.9.0-rc2, and were calling Fox 
"blind" in 1st sequence.  A few Hounds tried using compound callsigns, 
which is not supported -- and which needs to be made more clear in the 
instructions.


- Nearly everybody noticed the XE1GK calling CQ on the low-end Fox 
frequency and working people these.  Please don't be too hard on 
Ignacio: he obviously misunderstood what was supposed to be happening, 
and how to operate in the test run.  He sent me an abject apology. 
Anyway, his signal helped us to evaluate how well we can cope with QRM 
and DQRM.


Two operating hints that should be used as needed, but in general were not:

 - Hounds should manually reset their Tx frequency as needed to evade QRM.

 - Fox may decide to use the randomizing feature to vary his own Tx 
frequency.



I list here some relatively minor bugs and other things that came to 
light during the test run:


 - Spurious "Callsign mismatch" warning messages were displayed to the 
Fox operator.


 - Fox's log window should automatically scroll to the bottom.  Or 
maybe it should simply show the most recent ~10 QSOs logged.


 - I'm not sure that Fox's "Max Calls" parameter worked as designed.

 - Sometimes Fox sent RR73 to the same station in more that one slot, 
in the same transmission.


 - The dreaded "Blue Decode" button was seen by some.

 - Hounds sometimes send a spuriously low signal report to Fox, even 
when Fox is loud.


 - If Hound hits "Enter" with the DX Call box empty, a blank message 
can be transmitted.


 - It a random station (not Fox) calls a Hound, it can trigger a Hound 
transmission just as if Fox had called.


 - Previously decoded Hound calls can sometimes reappear in Fox's left 
window, when they should not.



Finally, let me outline a few new features we may decide to implement.

 - At least for debugging, and possibly as an option, offer a display 
window that shows the Fox operator the contents of all active queues.


 - Limit the number of QSOs in progress to no more than NSlots.

 - Option to suppress display of the waterfall timestamp.

 - Have Fox call CQ in one slot at least once every few (1 or 2?) minutes.

 - Should Hound's Tx3 frequency be re-randomized for each repeat try?

I'm sure there is more to be said, but that will do for now.  Depending 
on programming progress and on my own travel schedule, we may schedule 
another public test within a few weeks.


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

[wsjt-devel] DXpedition mode test results

2018-03-06 Thread Alex, VE3NEA 
There was no propagation on 20m and 30m, but on 40m and 80m I worked DX quickly and without problems. There were a few glitches 
that are hopefully not difficult to fix.


1. When the Fox answered my call at 01:02:00 (see the attached screenshot), his message appeared on the left panel but not on 
the right one.


2. Two or three blank messages were received during the test.

3. Repeated RR73 have already been reported, but here is an interesting case: two RR73's were sent to me in the same time slot, 
on 313 Hz and 433 Hz (visible on the same screenshot):


010300 -13 -0.7  313 ~  VE3NEA RR73; N4EFS  -10
010300 -12 -0.7  372 ~  AB3CV RR73; W5TKZ  -10
010300 -13 -0.7  433 ~  VE3NEA RR73; K4SO  -05
010300 -14 -0.7  493 ~  AB3CV RR73; K1WSN  -09

My apologies if this is a feature rather than a bug. After all, the second VE3NEA RR73; has zero cost because the same message 
starts another QSO, so it makes sense to include it and improve the chances of RR73 being copied.



4. Probably not a glitch, just an observation: sometimes the Fox has more QSO in progress than it has slots. Below, the Fox 
answers my call at 02:07:00, then at 02:07:30 it does not RR my report but finishes three other QSO (and starts three new ones), 
and only at 02:08:00 sends RR73 to me:


180307_020645  Transmitting 3.585 MHz  FT8:  K9AN VE3NEA FN03

020700  -6  0.1  304 ~  W9EQ RR73; VE3NEA  -06
020700  -4  0.1  364 ~  AF3I RR73; KC4JNW  -05
020700  -3  0.1  424 ~  W3RJW RR73; WA4MIT  -05

180307_020715  Transmitting 3.585 MHz  FT8:  K9AN VE3NEA R+04

020730  -4  0.1  304 ~  VE2EBK RR73; KF0QR  -05
020730  -1  0.1  364 ~  W9EQ RR73; W8BAR  -05
020730   0  0.1  424 ~  AF3I RR73; K4DSP  -04

180307_020745  Transmitting 3.585 MHz  FT8:  K9AN VE3NEA R+04

020800  -2  0.1  304 ~  KC4JNW RR73; WW8RT  -04
020800   0  0.1  364 ~  W7AH RR73; KG4W   -04
020800   0  0.1  424 ~  VE3NEA RR73; N2ADV  -04

It is not clear if this behavior increases or decreases the QSO rate.

73 Alex VE3NEA


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