Re: [wsjt-devel] Faster contest sequence

2018-11-21 Thread Dave Hachadorian
Hi Saku,

Thanks for the information.

So here is the section in your reference regarding what constitutes a valid QSO

1. It is recommended that a QSO (meaning communication; 2-way contact) between 
two 
 radio station operators is complete, when the 
 following exchange has been completed via 
 radio, without outside help by others: 

  a. both radio station operators have comprehended each other's call 
signs; plus 

  b. some other information (commonly 
  a report, for instance RST) has been 
  exchanged; plus 

  c. confirmations have been exchanged 
 that the other operator has received the 
 above (call sign and some other information). 
Paragraph 1c does not say that you need “confirmation of the confirmations.”  
Rather, 1c requires that confirmations be exchanged that the call sign and QSO 
information have been received.  In the example below, I confirmed receipt of 
her information in my TX3 transmission with the “R.”  She confirmed receipt of 
my information with her TX4 transmission with the “RR.”  No further 
confirmations are required.  The TX5 autosequence transmission, that I am 
proposing be deleted, is only “73,”  which is a nice pleasantry, but not a 
confirmation of anything, and slows down the QSO rate by 50%, 90 seconds per 
QSO vs. 60 seconds per QSO.
Dave Hachadorian, K6LL
Yuma, AZ


From: Saku 
Sent: Wednesday, November 21, 2018 8:21 AM
To: Dave Hachadorian ; WSJT software development ; wsjt-x development Reflector 
Subject: Re: [wsjt-devel] Faster contest sequence

Hi!

Maybe because of this. 

https://www.google.fi/url?sa=t=web=j=http://hf.r-e-f.org/c4_iaru_r1/10vienne/VIE10_C4_11%2520QSO%2520definition.pdf=2ahUKEwiEko_F4eXeAhUCBiwKHU6VBOIQFjAAegQIABAB=AOvVaw0V-30uPteK4he8PsRKJC6r

"Conclusion. 1c" at the end of document is read so that confirmation of 
confirmations must be received both sides.

I.e your 73 will confirm her RR73 to be received.

-- 
Saku
OH1KH


20. marraskuuta 2018 20.54.09 GMT+02:00 Dave Hachadorian  
kirjoitti: 
  I tried using the following sequence in the contest last night. 

  I SEND (TX6)  CQ RU K6LL DM22

  SHE SENDS (TX2) K6LL K7ABC 569 AZ

  I SEND (TX3)  K7ABC K6LL R 579 AZ

  SHE SENDS (TX4) K6LL K7ABC RR73

  I SEND (TX6) CQ RU K6LL DM22


  It worked OK sometimes, but several callers kept coming back for more info, 
apparently looking for that final (TX5) “73” from me.  I guess I don’t 
understand why they were looking for that. When I send TX3, the R tells her 
that I got her report.  When she sends RR73, she tells me that she got my 
report.  The QSO data has gone into the log at both ends and all is good.  Why 
can’t I start an immediate CQ, and why doesn’t the automatic sequence follow 
that pattern?  It would shorten the QSO time from 90 seconds to 60 seconds.

  Thanks.

  Dave Hachadorian, K6LL
  Yuma, AZ






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


Re: [wsjt-devel] DXPedition changes?

2018-11-21 Thread Joe Taylor

On 11/21/2018 12:08 AM, jarmo OH1MRR wrote:


Some months ago we said "The existing FT8 DXpedition mode will still
be supported, and a more powerful DXpedition mode may be offered as
well." We have not yet done serious work on the potentially "more
powerful mode". -- Joe, K1JT


As during VP6D, was seen, that they used 9 slots! 


As far as I know, VP6D used WSJT-X v1.9.1.  The maximum number of slots 
is 5.



When they CQ'ed, using
only one signal, signal was example -7, great, send my call, next lost
them totally, because they answered to 9 stations. I saw only slot
frames, but no decoding information. Someone, who had better antennas,
told me, that they are answering to me, no see...
I could copy, when they answered with 4 slots and fortunately got
qso. 


So, maybe limiting slots to some lower or to documentation some
words for dx, when propagation is bad, don't use more than 3-4 slots
max.


It's easy for Fox to limit the number of slots in use, and good 
operators quickly learn when to do this.


-- 73, Joe, K1JT


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


Re: [wsjt-devel] v2.0 RC4 in congestion !

2018-11-21 Thread Stephen Ireland
Thanks for the kind words Scott. I have “arranged” a little internet WiFi 
systems are quite insecure 

Sent from Mail for Windows 10


From: Scott Brown 
Sent: Wednesday, November 21, 2018 6:06:56 AM
To: WSJT software development
Subject: Re: [wsjt-devel] v2.0 RC4 in congestion !

Good luck on your surgery Steve!

-Scott
KD4YDD

On Nov 20, 2018, at 1:19 PM, Stephen Ireland 
mailto:vk3...@hotmail.com>> wrote:

Mark,

I had considered this and its a fair suggestion – but the start of our band is 
say 7.074. Are we not best working under real world congestion – especially on 
40m - and not closed-conditions? That is why I raised the Fleishman and Pons 
“Cold Fusion” fiasco – an example that runs shivers down the spine of anyone 
trying to research or develop – in the initial post...

John,

No split selected. Please do not take this the wrong way but I cannot see how 
split is relevant to this discussion .  Splits are a fantastic idea – but by 
far the vast majority of FT8 conduct Tx’s with the extensive split 
functionality disabled my observation; An op selects a frequency and stays 
there. An op responds either directly on the calling Op’s offset OR at their 
own selected frequency. Splits CAN be a nightmare for the unwary !

73, its 5am here ... and off for surgery so I be quiet for a few days ... maybe 
!

Steve I



Sent from Mail for Windows 10


From: Mark James mailto:markhjame...@gmail.com>>
Sent: Wednesday, November 21, 2018 12:59:00 AM
To: WSJT software development
Subject: Re: [wsjt-devel] v2.0 RC4 in congestion !

If you are working above 2000, and might have performance issues on receiving 
signals there, another option is to use a higher dial frequency -- eg 7.075 or 
7.076. This doesn't affect the actual frequencies used, just may make it easier 
to manage.



On Tue, Nov 20, 2018 at 7:52 AM John Nelson 
mailto:j...@rmnjmn.co.uk>> wrote:
Steve,

>  one must “adjust” the AF “Power” drive control as one shifts Tx frequency.

Are you not using CAT control with “Split” selected?   If so, VFOB is set such 
that the audio tone generated is always between 1500 and 2000 Hz which should 
always be within the SSB passband.   The TX offset is managed by VFOB.

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


Re: [wsjt-devel] v2.0 RC4 in congestion !

2018-11-21 Thread Stephen Ireland
Hi Folks,

Decoder sensitivity, radio splits, mitigation attempts... all great but it is 
not the issue I am raising for research  On clear bandwidth the protocol 
has no issues...

There are some comments on forums – English and otherwise. Thank you Google 
Translate.

I have run a few “sims” under congestion on-air and via complex “predictors”... 
and performance under congestion is the issue that I am seeking a bit of 
comment for and potential investigation of. As stated I have some observations 
that I lack empirical evidence for at this stage. This is VERY useful feedback 
for Joe and Bill.

73

Stev I

Sent from Mail for Windows 10


From: Scott Brown 
Sent: Wednesday, November 21, 2018 10:21:29 AM
To: M Lewton; WSJT software development
Subject: Re: [wsjt-devel] v2.0 RC4 in congestion !

Settings > Radio > Split Operation > Check Fake It. This seems to do the trick.

Just a bandaid tho. Centering up the dial seems more feasible. 

-Scott
KD4YDD

From: M Lewton 
Sent: Tuesday, November 20, 2018 4:50 PM
To: WSJT software development
Subject: Re: [wsjt-devel] v2.0 RC4 in congestion !

I agree.  A few of operators operating above 2000 have a good signal on the
waterfall, I copy them well but they can't seem to hear me ??
I am running 100 watts using a IC-7300 with BW set to 3600.
It seem that they are running a KW to my 100 watts.
You are right, with some receivers it would be better to set the Freq. to
14.075 instead of 14.074 etc. using rc8 until the next release.

I am happy with the sensitivity of the decoder though.

Maurice
WA6PHR

-Original Message-
From: Mark James
Sent: Tuesday, November 20, 2018 5:59 AM
To: WSJT software development
Subject: Re: [wsjt-devel] v2.0 RC4 in congestion !


If you are working above 2000, and might have performance issues on
receiving signals there, another option is to use a higher dial frequency --
eg 7.075 or 7.076. This doesn't affect the actual frequencies used, just may
make it easier to manage.




On Tue, Nov 20, 2018 at 7:52 AM John Nelson  wrote:
Steve,

>  one must “adjust” the AF “Power” drive control as one shifts Tx
> frequency.

Are you not using CAT control with “Split” selected?   If so, VFOB is set
such that the audio tone generated is always between 1500 and 2000 Hz which
should always be within the SSB passband.   The TX offset is managed by
VFOB.

— John G4KLA___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel










___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7C44e62dccb4654c0a941f08d64ef0fbbb%7C84df9e7fe9f640afb435%7C1%7C0%7C636783194249833574sdata=QLaeCUIjDS9knkwwVaO4%2BEkhYN6Kx9SiaL3OynpeWzI%3Dreserved=0


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


Re: [wsjt-devel] RC4 Crash on Logging - observation

2018-11-21 Thread Tom Melvin
It seems to be due to the sent exchange field not being populated

See:  https://sourceforge.net/p/wsjt/mailman/message/36472011/

It applies to EU-Contest mode as well


73’s

Tom
GM8MJV (IO85)





On 21 Nov 2018, at 01:37, Neal Pollack  wrote:

> I noticed that I could 100% reproduce a crash (app windows vanish, no error 
> message) if
> I click on OK in the Log Prompting dialog pop-up box, WHILE the final 73 was 
> still transmitting.
> If I wait until transmit completes, and THEN click OK to the log dialog box, 
> the app is OK and
> does NOT crash.  I tried 30 additional contact this way with no crash.
> So the crash has something to do with clicking OK to log DURING transmit, on 
> windows ver 1803.
> Not tested with windows 10 ver 1809.
> 
> This is with windows 10 x64 version 1803.   (Not tested with windows 10 ver 
> 1809.)
> This is with core i7 CPU, 16GB memory, and using JTalert (latest version) and 
> using Ham Radio
> Deluxe logger, latest version.
> 
> To confirm, I did a second installation of WSJT-X ver 2 RC4 in a different 
> directory.
> It will also crash 100% of the time if you click on OK in the log dialog 
> pop-up box
> WHILE it is still transmitting the final 73.
> 
> Neal
> N6YFM
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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