Re: [wsjt-devel] Field Day time problem

[Larry B. via wsjt-devel]

My guess, after many years of FD, is that MOST operators would have little idea 
of what ANY indication of a clock-sync issue means.  Many ops are sitting down 
operating for the first time, getting their feet wet with (NOT A CONTEST) Field 
Day.  PLUS, as has been noted, many FD sites DO NOT have a reasonable ability 
to sync their clocks.  

I suspect that, for what it’s worth, any attempts to make this better will just 
result in either FD ops NOT going back to FT8 (or FT4 in the future), or will 
just ignore this.  REMEMBER – adults do not learn anything from a “once-a-year” 
encounter with anything requiring some rather deep learning.  If you don’t do 
something every month, you won’t remember it. 

73 -- Larry -- W1DYJ



From: Black Michael via wsjt-devel 
Sent: Sunday, June 23, 2019 16:43
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] Field Day time problem

Of all the DT drifeters I saw not one was running JTAlert.

Then again highlighting the DT values > 0.5 seconds might be a better solution 
though once you get your clock set the I find the highlighting irritating as 
all highlight should be calling your attention to something.

And based on watching FD today I think 80% (4 of 5) > 0.5 second might be the 
good target.

Mike.





On Sunday, June 23, 2019, 03:10:58 PM CDT, August Treubig 
 wrote: 


JTAlert already does that.   Highlights in red. 

Aug
AG5AT 


Sent from my iPad

On Jun 23, 2019, at 2:04 PM, Gary Hinson  wrote:


Instead of “Your clock is off” (which, to some, may mean “Your clock is turned 
off”) I suggest “Your clock is wrong” or better still the action-oriented 
“Check your clock”.



And the proposed 3 out of 5 decodes being more than half a second wrong risks 
triggering the message far too often when the band is busy, especially during 
events such as field day and DXpeditions when a greater proportion of ops are 
probably using temporary setups without atomic clock references.  I think a 
statistical test would be more appropriate, although I’m not sure which one 
(ask a statistician!).



Another approach would be simply to highlight DT values that are more than, 
say, 1 second wrong in the decode panes (e.g. with red or orange backgrounds 
for minus and plus DT values), and leave the ops to notice the slew of reds or 
oranges and figure out what’s going on.  This has the advantage that, if we are 
reasonably sure of our own clocks, we might notice and maybe send a message to 
other stations whose DT values are highlighted.



73

Gary  ZL2iFB



From: Black Michael via wsjt-devel  
Sent: 24 June 2019 00:27
To: WSJT Software Development 
Cc: Black Michael 
Subject: [wsjt-devel] Field Day time problem



I've seen about 2 dozen clubs doing Field Day where their clocks are off.



We need to provide an indication in WSJT-X when clocks are off like this.



With concurrence I can do a patch for thismy idea is this.



At least 5 decodes where 60% or more > 0.5 seconds is an indication of bad 
timing.

A message would be put in the Rx Frequency window "Your clock is off...see 
help".  With appropriate references in the Help to search "your clock is off" 
and time solutions.



This doesn't cover the case where their clock is way off as they won't see any 
decodes.  The only solution for that would be doing a time query from a known 
source and I don't think we want to go that route.



de Mike W9MDB





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

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








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

Re: [wsjt-devel] Field Day time problem

[Jim Shorney]

You know, you can set a computer clock with WWV +/- propagation delay and 
muscle reaction time. It works and is very much like what one might do in the 
field on a bad day. Don't over think it.

73

-Jim
NU0C

On Sun, 23 Jun 2019 18:15:00 -0400
Topher Petty  wrote:

> Example from a quick search:
> https://www.aliexpress.com/item/Aviation-Vehicle-Positioning-Receiver-G-MOUSE-Glonass-Navigation-USB-GPS-Module-Dongle-Tracking-Replacement-Alarm-Car/33006770294.html
> 
> 73 de AI8W, Chris
> 
> On Sun, Jun 23, 2019 at 6:11 PM Topher Petty  wrote:
> 
> > GPSD (Linux and OSX should be able to run this) can sync time to the
> > computer from a GPS receiver... I've used that in the past on where
> > internet access is problematic and time sync was critical. A cheap USB GPS
> > unit could then be purchased (I've seen them as low as $5 on US sites, and
> > around $2 on alibaba/aliexpress) for that purpose. Plug in the GPS, run
> > GPSD, sync, go.
> >
> > It'd be very difficult for a computer to be off on its dT if it was
> > continually syncing time to the GPS satellites...
> >
> > There's an old saying in IT.. something about programming idiot-proof
> > software causing bigger idiots to be created... I forget the exact wording.
> >
> > 73 de AI8W, Chris
> >
> > On Sun, Jun 23, 2019 at 5:57 PM Mike Lewis  wrote:
> >  
> >> You could use the DT of the received stations to adjust the clock.
> >>
> >>
> >>
> >> Select a group with the largest agreement within a narrow range of a few
> >> tenths of a second, and the program, or a program, can offer to adjust the
> >> time into that range.  Sort of like a wire protocol that derives its own
> >> clock sync from the data stream.  The change mechanism could be a
> >> calculation or a manual slider.
> >>
> >>
> >>
> >> *From:* Jim Jennings 
> >> *Sent:* Sunday, June 23, 2019 14:15
> >> *To:* Black Michael ; WSJT software development <
> >> wsjt-devel@lists.sourceforge.net>
> >> *Subject:* Re: [wsjt-devel] Field Day time problem
> >>
> >>
> >>
> >> When one of our stations at Field Day was set up for FT8, it became
> >> apparent that a system time sync was needed before it could be used.  One
> >> of our participants was able to provide a NTP sync with his smart phone,
> >> and W6AF (2A SV) managed a couple  dozen contacts on 20 Meters with five
> >> watts (Yaesu FT-817) into a low dipole.  What about a location where
> >> cellular or WiFi coverage is unavailable?
> >>
> >>
> >>
> >> VK4ADC’s free program GPS2Time can synchronize a computer’s system clock
> >> using a GPS set with NMEA serial output (I have two hand held Garmins that
> >> do this) through a COM port.  The website is:
> >>
> >> https://www.vk4adc.com/web/software-projects/55-vk4adc-utils/181-gps2time.
> >> If I had known about this prior to Field Day, I would have brought the
> >> program and the essential items to try it.
> >>
> >>
> >>
> >> Jim, W7XZ
> >>
> >>
> >>
> >> PS  FT8 was a big hit with the ops who tried it for the first time.
> >>
> >> *From:* Black Michael via wsjt-devel
> >>
> >> *Sent:* Sunday, June 23, 2019 05:27
> >>
> >> *To:* WSJT Software Development
> >>
> >> *Cc:* Black Michael
> >>
> >> *Subject:* [wsjt-devel] Field Day time problem
> >>
> >>
> >>
> >> I've seen about 2 dozen clubs doing Field Day where their clocks are off.
> >>
> >>
> >>
> >> We need to provide an indication in WSJT-X when clocks are off like this.
> >>
> >>
> >>
> >> With concurrence I can do a patch for thismy idea is this.
> >>
> >>
> >>
> >> At least 5 decodes where 60% or more > 0.5 seconds is an indication of
> >> bad timing.
> >>
> >> A message would be put in the Rx Frequency window "Your clock is
> >> off...see help".  With appropriate references in the Help to search "your
> >> clock is off" and time solutions.
> >>
> >>
> >>
> >> This doesn't cover the case where their clock is way off as they won't
> >> see any decodes.  The only solution for that would be doing a time query
> >> from a known source and I don't think we want to go that route.
> >>
> >>
> >>
> >> de Mike W9MDB
> >>
> >>
> >>
> >>
> >> --
> >> --
> >>
> >> ___
> >> 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] Field Day time problem

[Topher Petty]

Example from a quick search:
https://www.aliexpress.com/item/Aviation-Vehicle-Positioning-Receiver-G-MOUSE-Glonass-Navigation-USB-GPS-Module-Dongle-Tracking-Replacement-Alarm-Car/33006770294.html

73 de AI8W, Chris

On Sun, Jun 23, 2019 at 6:11 PM Topher Petty  wrote:

> GPSD (Linux and OSX should be able to run this) can sync time to the
> computer from a GPS receiver... I've used that in the past on where
> internet access is problematic and time sync was critical. A cheap USB GPS
> unit could then be purchased (I've seen them as low as $5 on US sites, and
> around $2 on alibaba/aliexpress) for that purpose. Plug in the GPS, run
> GPSD, sync, go.
>
> It'd be very difficult for a computer to be off on its dT if it was
> continually syncing time to the GPS satellites...
>
> There's an old saying in IT.. something about programming idiot-proof
> software causing bigger idiots to be created... I forget the exact wording.
>
> 73 de AI8W, Chris
>
> On Sun, Jun 23, 2019 at 5:57 PM Mike Lewis  wrote:
>
>> You could use the DT of the received stations to adjust the clock.
>>
>>
>>
>> Select a group with the largest agreement within a narrow range of a few
>> tenths of a second, and the program, or a program, can offer to adjust the
>> time into that range.  Sort of like a wire protocol that derives its own
>> clock sync from the data stream.  The change mechanism could be a
>> calculation or a manual slider.
>>
>>
>>
>> *From:* Jim Jennings 
>> *Sent:* Sunday, June 23, 2019 14:15
>> *To:* Black Michael ; WSJT software development <
>> wsjt-devel@lists.sourceforge.net>
>> *Subject:* Re: [wsjt-devel] Field Day time problem
>>
>>
>>
>> When one of our stations at Field Day was set up for FT8, it became
>> apparent that a system time sync was needed before it could be used.  One
>> of our participants was able to provide a NTP sync with his smart phone,
>> and W6AF (2A SV) managed a couple  dozen contacts on 20 Meters with five
>> watts (Yaesu FT-817) into a low dipole.  What about a location where
>> cellular or WiFi coverage is unavailable?
>>
>>
>>
>> VK4ADC’s free program GPS2Time can synchronize a computer’s system clock
>> using a GPS set with NMEA serial output (I have two hand held Garmins that
>> do this) through a COM port.  The website is:
>>
>> https://www.vk4adc.com/web/software-projects/55-vk4adc-utils/181-gps2time.
>> If I had known about this prior to Field Day, I would have brought the
>> program and the essential items to try it.
>>
>>
>>
>> Jim, W7XZ
>>
>>
>>
>> PS  FT8 was a big hit with the ops who tried it for the first time.
>>
>> *From:* Black Michael via wsjt-devel
>>
>> *Sent:* Sunday, June 23, 2019 05:27
>>
>> *To:* WSJT Software Development
>>
>> *Cc:* Black Michael
>>
>> *Subject:* [wsjt-devel] Field Day time problem
>>
>>
>>
>> I've seen about 2 dozen clubs doing Field Day where their clocks are off.
>>
>>
>>
>> We need to provide an indication in WSJT-X when clocks are off like this.
>>
>>
>>
>> With concurrence I can do a patch for thismy idea is this.
>>
>>
>>
>> At least 5 decodes where 60% or more > 0.5 seconds is an indication of
>> bad timing.
>>
>> A message would be put in the Rx Frequency window "Your clock is
>> off...see help".  With appropriate references in the Help to search "your
>> clock is off" and time solutions.
>>
>>
>>
>> This doesn't cover the case where their clock is way off as they won't
>> see any decodes.  The only solution for that would be doing a time query
>> from a known source and I don't think we want to go that route.
>>
>>
>>
>> de Mike W9MDB
>>
>>
>>
>>
>> --
>> --
>>
>> ___
>> 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] Field Day time problem

[Topher Petty]

GPSD (Linux and OSX should be able to run this) can sync time to the
computer from a GPS receiver... I've used that in the past on where
internet access is problematic and time sync was critical. A cheap USB GPS
unit could then be purchased (I've seen them as low as $5 on US sites, and
around $2 on alibaba/aliexpress) for that purpose. Plug in the GPS, run
GPSD, sync, go.

It'd be very difficult for a computer to be off on its dT if it was
continually syncing time to the GPS satellites...

There's an old saying in IT.. something about programming idiot-proof
software causing bigger idiots to be created... I forget the exact wording.

73 de AI8W, Chris

On Sun, Jun 23, 2019 at 5:57 PM Mike Lewis  wrote:

> You could use the DT of the received stations to adjust the clock.
>
>
>
> Select a group with the largest agreement within a narrow range of a few
> tenths of a second, and the program, or a program, can offer to adjust the
> time into that range.  Sort of like a wire protocol that derives its own
> clock sync from the data stream.  The change mechanism could be a
> calculation or a manual slider.
>
>
>
> *From:* Jim Jennings 
> *Sent:* Sunday, June 23, 2019 14:15
> *To:* Black Michael ; WSJT software development <
> wsjt-devel@lists.sourceforge.net>
> *Subject:* Re: [wsjt-devel] Field Day time problem
>
>
>
> When one of our stations at Field Day was set up for FT8, it became
> apparent that a system time sync was needed before it could be used.  One
> of our participants was able to provide a NTP sync with his smart phone,
> and W6AF (2A SV) managed a couple  dozen contacts on 20 Meters with five
> watts (Yaesu FT-817) into a low dipole.  What about a location where
> cellular or WiFi coverage is unavailable?
>
>
>
> VK4ADC’s free program GPS2Time can synchronize a computer’s system clock
> using a GPS set with NMEA serial output (I have two hand held Garmins that
> do this) through a COM port.  The website is:
>
> https://www.vk4adc.com/web/software-projects/55-vk4adc-utils/181-gps2time.
> If I had known about this prior to Field Day, I would have brought the
> program and the essential items to try it.
>
>
>
> Jim, W7XZ
>
>
>
> PS  FT8 was a big hit with the ops who tried it for the first time.
>
> *From:* Black Michael via wsjt-devel
>
> *Sent:* Sunday, June 23, 2019 05:27
>
> *To:* WSJT Software Development
>
> *Cc:* Black Michael
>
> *Subject:* [wsjt-devel] Field Day time problem
>
>
>
> I've seen about 2 dozen clubs doing Field Day where their clocks are off.
>
>
>
> We need to provide an indication in WSJT-X when clocks are off like this.
>
>
>
> With concurrence I can do a patch for thismy idea is this.
>
>
>
> At least 5 decodes where 60% or more > 0.5 seconds is an indication of bad
> timing.
>
> A message would be put in the Rx Frequency window "Your clock is off...see
> help".  With appropriate references in the Help to search "your clock is
> off" and time solutions.
>
>
>
> This doesn't cover the case where their clock is way off as they won't see
> any decodes.  The only solution for that would be doing a time query from a
> known source and I don't think we want to go that route.
>
>
>
> de Mike W9MDB
>
>
>
>
> --
> --
>
> ___
> 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] Field Day time problem

[Mike Lewis]

You could use the DT of the received stations to adjust the clock.

Select a group with the largest agreement within a narrow range of a few tenths 
of a second, and the program, or a program, can offer to adjust the time into 
that range.  Sort of like a wire protocol that derives its own clock sync from 
the data stream.  The change mechanism could be a calculation or a manual 
slider.

From: Jim Jennings 
Sent: Sunday, June 23, 2019 14:15
To: Black Michael ; WSJT software development 

Subject: Re: [wsjt-devel] Field Day time problem

When one of our stations at Field Day was set up for FT8, it became apparent 
that a system time sync was needed before it could be used.  One of our 
participants was able to provide a NTP sync with his smart phone, and W6AF (2A 
SV) managed a couple  dozen contacts on 20 Meters with five watts (Yaesu 
FT-817) into a low dipole.  What about a location where cellular or WiFi 
coverage is unavailable?

VK4ADC’s free program GPS2Time can synchronize a computer’s system clock using 
a GPS set with NMEA serial output (I have two hand held Garmins that do this) 
through a COM port.  The website is:
https://www.vk4adc.com/web/software-projects/55-vk4adc-utils/181-gps2time.  If 
I had known about this prior to Field Day, I would have brought the program and 
the essential items to try it.

Jim, W7XZ

PS  FT8 was a big hit with the ops who tried it for the first time.
From: Black Michael via wsjt-devel
Sent: Sunday, June 23, 2019 05:27
To: WSJT Software Development
Cc: Black Michael
Subject: [wsjt-devel] Field Day time problem

I've seen about 2 dozen clubs doing Field Day where their clocks are off.

We need to provide an indication in WSJT-X when clocks are off like this.

With concurrence I can do a patch for thismy idea is this.

At least 5 decodes where 60% or more > 0.5 seconds is an indication of bad 
timing.
A message would be put in the Rx Frequency window "Your clock is off...see 
help".  With appropriate references in the Help to search "your clock is off" 
and time solutions.

This doesn't cover the case where their clock is way off as they won't see any 
decodes.  The only solution for that would be doing a time query from a known 
source and I don't think we want to go that route.

de Mike W9MDB




___
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] Field Day time problem

[Jim Jennings]

When one of our stations at Field Day was set up for FT8, it became apparent 
that a system time sync was needed before it could be used.  One of our 
participants was able to provide a NTP sync with his smart phone, and W6AF (2A 
SV) managed a couple  dozen contacts on 20 Meters with five watts (Yaesu 
FT-817) into a low dipole.  What about a location where cellular or WiFi 
coverage is unavailable?

VK4ADC’s free program GPS2Time can synchronize a computer’s system clock using 
a GPS set with NMEA serial output (I have two hand held Garmins that do this) 
through a COM port.  The website is:  
https://www.vk4adc.com/web/software-projects/55-vk4adc-utils/181-gps2time.  If 
I had known about this prior to Field Day, I would have brought the program and 
the essential items to try it.

Jim, W7XZ

PS  FT8 was a big hit with the ops who tried it for the first time.
From: Black Michael via wsjt-devel 
Sent: Sunday, June 23, 2019 05:27
To: WSJT Software Development 
Cc: Black Michael 
Subject: [wsjt-devel] Field Day time problem

I've seen about 2 dozen clubs doing Field Day where their clocks are off.

We need to provide an indication in WSJT-X when clocks are off like this.

With concurrence I can do a patch for thismy idea is this.

At least 5 decodes where 60% or more > 0.5 seconds is an indication of bad 
timing.
A message would be put in the Rx Frequency window "Your clock is off...see 
help".  With appropriate references in the Help to search "your clock is off" 
and time solutions.

This doesn't cover the case where their clock is way off as they won't see any 
decodes.  The only solution for that would be doing a time query from a known 
source and I don't think we want to go that route.

de Mike W9MDB









___
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] Initial thoughts on FT8 and FD

[VE3FBZ]

Perhaps drop the grid in FD mode and put in the Class letter. 

I strongly support this modification.

This would allow us to select wanted/require call to complete our maps etc. 


 Regards and 73s
VE3FBZ
London Amateur Radio Club
www.larc.ca 




> On Jun 22, 2019, at 16:57, WB5JJJ  wrote:
> 
> I’ve noticed that rc7 32b is still fully functional after several restarts to 
> check, even in FT4. Oops. Of course it may stop at any time.
> 
> Also had to turn Call 1st off (operating 1D) because of all the “D”’s calling 
> me. My CQ does not indicate my class so everybody is clueless unless they 
> also watch the left window all the time. 
> 
> Perhaps drop the grid in FD mode and put in the Class letter. Even better, 
> don’t allow a “D” to auto connect to another "D" calling CQ when Call 1st is 
> active. That would speed thing up for sure.
> 
> I'm sure bullets are now flying my way to punch holes in my suggestion, but 
> I'll duck out of the way as best I can and just go with the flow.  
> 
> WB5JJJ - George
> ___
> 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] Field Day time problem

[Black Michael via wsjt-devel]

Of all the DT drifeters I saw not one was running JTAlert.
Then again highlighting the DT values > 0.5 seconds might be a better solution 
though once you get your clock set the I find the highlighting irritating as 
all highlight should be calling your attention to something.
And based on watching FD today I think 80% (4 of 5) > 0.5 second might be the 
good target.
Mike.


 

On Sunday, June 23, 2019, 03:10:58 PM CDT, August Treubig 
 wrote:  
 
 JTAlert already does that.   Highlights in red.
AugAG5AT 

Sent from my iPad
On Jun 23, 2019, at 2:04 PM, Gary Hinson  wrote:




Instead of “Your clock is off” (which, to some, may mean “Your clock is turned 
off”) I suggest “Your clock is wrong” or better still the action-oriented 
“Check your clock”.

  

And the proposed 3 out of 5 decodes being more than half a second wrong risks 
triggering the message far too often when the band is busy, especially during 
events such as field day and DXpeditions when a greater proportion of ops are 
probably using temporary setups without atomic clock references.  I think a 
statistical test would be more appropriate, although I’m not sure which one 
(ask a statistician!).

  

Another approach would be simply to highlight DT values that are more than, 
say, 1 second wrong in the decode panes (e.g. with red or orange backgrounds 
for minus and plus DT values), and leave the ops to notice the slew of reds or 
oranges and figure out what’s going on.  This has the advantage that, if we are 
reasonably sure of our own clocks, we might notice and maybe send a message to 
other stations whose DT values are highlighted.

  

73

Gary  ZL2iFB

  

From: Black Michael via wsjt-devel  
Sent: 24 June 2019 00:27
To: WSJT Software Development 
Cc: Black Michael 
Subject: [wsjt-devel] Field Day time problem

  

I've seen about 2 dozen clubs doing Field Day where their clocks are off.

  

We need to provide an indication in WSJT-X when clocks are off like this.

  

With concurrence I can do a patch for thismy idea is this.

  

At least 5 decodes where 60% or more > 0.5 seconds is an indication of bad 
timing.

A message would be put in the Rx Frequency window "Your clock is off...see 
help".  With appropriate references in the Help to search "your clock is off" 
and time solutions.

  

This doesn't cover the case where their clock is way off as they won't see any 
decodes.  The only solution for that would be doing a time query from a known 
source and I don't think we want to go that route.

  

de Mike W9MDB

  

  



___
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] Field Day time problem

[August Treubig]

JTAlert already does that.   Highlights in red.

Aug
AG5AT 

Sent from my iPad

> On Jun 23, 2019, at 2:04 PM, Gary Hinson  wrote:
> 
> Instead of “Your clock is off” (which, to some, may mean “Your clock is 
> turned off”) I suggest “Your clock is wrong” or better still the 
> action-oriented “Check your clock”.
>  
> And the proposed 3 out of 5 decodes being more than half a second wrong risks 
> triggering the message far too often when the band is busy, especially during 
> events such as field day and DXpeditions when a greater proportion of ops are 
> probably using temporary setups without atomic clock references.  I think a 
> statistical test would be more appropriate, although I’m not sure which one 
> (ask a statistician!).
>  
> Another approach would be simply to highlight DT values that are more than, 
> say, 1 second wrong in the decode panes (e.g. with red or orange backgrounds 
> for minus and plus DT values), and leave the ops to notice the slew of reds 
> or oranges and figure out what’s going on.  This has the advantage that, if 
> we are reasonably sure of our own clocks, we might notice and maybe send a 
> message to other stations whose DT values are highlighted.
>  
> 73
> Gary  ZL2iFB
>  
> From: Black Michael via wsjt-devel  
> Sent: 24 June 2019 00:27
> To: WSJT Software Development 
> Cc: Black Michael 
> Subject: [wsjt-devel] Field Day time problem
>  
> I've seen about 2 dozen clubs doing Field Day where their clocks are off.
>  
> We need to provide an indication in WSJT-X when clocks are off like this.
>  
> With concurrence I can do a patch for thismy idea is this.
>  
> At least 5 decodes where 60% or more > 0.5 seconds is an indication of bad 
> timing.
> A message would be put in the Rx Frequency window "Your clock is off...see 
> help".  With appropriate references in the Help to search "your clock is off" 
> and time solutions.
>  
> This doesn't cover the case where their clock is way off as they won't see 
> any decodes.  The only solution for that would be doing a time query from a 
> known source and I don't think we want to go that route.
>  
> de Mike W9MDB
>  
>  
> ___
> 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] Field Day time problem

[WB5JJJ]

The latest JTAlert has this feature.  You can set several DT error time
limits to be highlighted in red in the WSJTx Band Activity window of the
drifting station's DT.

If a station sees lots of red in the DT column, hopefully they would take
notice and figure out they are out of sync.

WB5JJJ - George

On Sun, Jun 23, 2019 at 2:09 PM Gary Hinson  wrote:

> Instead of “Your clock is off” (which, to some, may mean “Your clock is
> turned off”) I suggest “Your clock is wrong” or better still the
> action-oriented “Check your clock”.
>
>
>
> And the proposed 3 out of 5 decodes being more than half a second wrong
> risks triggering the message far too often when the band is busy,
> especially during events such as field day and DXpeditions when a greater
> proportion of ops are probably using temporary setups without atomic clock
> references.  I think a statistical test would be more appropriate, although
> I’m not sure which one (ask a statistician!).
>
>
>
> Another approach would be simply to highlight DT values that are more
> than, say, 1 second wrong in the decode panes (e.g. with red or orange
> backgrounds for minus and plus DT values), and leave the ops to notice the
> slew of reds or oranges and figure out what’s going on.  This has the
> advantage that, if we are reasonably sure of our own clocks, we might
> notice and maybe send a message to other stations whose DT values are
> highlighted.
>
>
>
> 73
>
> Gary  ZL2iFB
>
>
>
> *From:* Black Michael via wsjt-devel 
> *Sent:* 24 June 2019 00:27
> *To:* WSJT Software Development 
> *Cc:* Black Michael 
> *Subject:* [wsjt-devel] Field Day time problem
>
>
>
> I've seen about 2 dozen clubs doing Field Day where their clocks are off.
>
>
>
> We need to provide an indication in WSJT-X when clocks are off like this.
>
>
>
> With concurrence I can do a patch for thismy idea is this.
>
>
>
> At least 5 decodes where 60% or more > 0.5 seconds is an indication of bad
> timing.
>
> A message would be put in the Rx Frequency window "Your clock is off...see
> help".  With appropriate references in the Help to search "your clock is
> off" and time solutions.
>
>
>
> This doesn't cover the case where their clock is way off as they won't see
> any decodes.  The only solution for that would be doing a time query from a
> known source and I don't think we want to go that route.
>
>
>
> de Mike W9MDB
>
>
>
>
> ___
> 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] Field Day time problem

[Enrique Scheuer]

Good idea to create a msg to those out of clock ..repeatedly  it can be
seen writing it on the screen. 73 de Enrique PY2CP

Em dom, 23 de jun de 2019 13:34, Matthew Miller 
escreveu:

> That does seem like it could be useful, I would imagine the problem is
> compounded by field day people in parks probably sync their clock before
> leaving and that's it.
>
> I do find it interesting sync thru my 4G connection in this park NTP
> estimates less delay and jitter than on my normal cable ISP.
>
> It would be really neat if there was a point and click way to tune the
> radio to wwv and have it set the computer clock using the time tone...since
> you would always have the radio when operating it would be easy to flip to
> say 10MHz and re-sync when it gets off
>
> *Sent from my Verizon LG Smartphone*
>
> -- Original message--
> *From: *Black Michael via wsjt-devel
> *Date: *Sun, Jun 23, 2019 8:27 AM
> *To: *WSJT Software Development;
> *Cc: *Black Michael;
> *Subject:*[wsjt-devel] Field Day time problem
>
> I've seen about 2 dozen clubs doing Field Day where their clocks are off.
>
> We need to provide an indication in WSJT-X when clocks are off like this.
>
> With concurrence I can do a patch for thismy idea is this.
>
> At least 5 decodes where 60% or more > 0.5 seconds is an indication of bad
> timing.
> A message would be put in the Rx Frequency window "Your clock is off...see
> help".  With appropriate references in the Help to search "your clock is
> off" and time solutions.
>
> This doesn't cover the case where their clock is way off as they won't see
> any decodes.  The only solution for that would be doing a time query from a
> known source and I don't think we want to go that route.
>
> de Mike W9MDB
>
>
> ___
> 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] Field Day time problem

[Matthew Miller]

That does seem like it could be useful, I would imagine the problem is 
compounded by field day people in parks probably sync their clock before 
leaving and that's it.

I do find it interesting sync thru my 4G connection in this park NTP estimates 
less delay and jitter than on my normal cable ISP.

It would be really neat if there was a point and click way to tune the radio to 
wwv and have it set the computer clock using the time tone...since you would 
always have the radio when operating it would be easy to flip to say 10MHz and 
re-sync when it gets off

Sent from my Verizon LG Smartphone

-- Original message--
From: Black Michael via wsjt-devel
Date: Sun, Jun 23, 2019 8:27 AM
To: WSJT Software Development;
Cc: Black Michael;
Subject:[wsjt-devel] Field Day time problem

I've seen about 2 dozen clubs doing Field Day where their clocks are off.

We need to provide an indication in WSJT-X when clocks are off like this.

With concurrence I can do a patch for thismy idea is this.

At least 5 decodes where 60% or more > 0.5 seconds is an indication of bad 
timing.
A message would be put in the Rx Frequency window "Your clock is off...see 
help".  With appropriate references in the Help to search "your clock is off" 
and time solutions.

This doesn't cover the case where their clock is way off as they won't see any 
decodes.  The only solution for that would be doing a time query from a known 
source and I don't think we want to go that route.

de Mike W9MDB


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

Re: [wsjt-devel] Field Day time problem

[Al Pawlowski]

Seems like the RC version color highlighting of excessive dt’s should do the 
job once it becomes the stable release.

BTW, our club (W6JU) had a GPS NTP server incorporated in the N3FJP logging 
server we used and that worked really well - as did the JTAlert N3FJP 
auto-logging. Only thing we noticed was everyone using the standard FT8 
frequency channels instead of the suggested alternates.

Our CW operators did outdo our FT8 (again), but FT8 #’s were competitive - and 
that with one FT8 and two CW stations. We even made a good number of 6m 
contacts, vs none last year. Phone #’s were much lower than CW or FT8. I don’t 
think we had any other digital mode going, except to copy the W1AW message.


Al Pawlowski, K6AVP
Los Osos, CA USA



> On Jun 23, 2019, at 05:29, wsjt-devel-requ...@lists.sourceforge.net wrote:
> 
> Date: Sun, 23 Jun 2019 12:27:23 + (UTC)
> From: Black Michael mailto:mdblac...@yahoo.com>>
> To: WSJT Software Development  >
> Subject: [wsjt-devel] Field Day time problem
> Message-ID: <1845500221.426201.1561292843...@mail.yahoo.com 
> >
> Content-Type: text/plain; charset="utf-8"
> 
> I've seen about 2 dozen clubs doing Field Day where their clocks are off.
> We need to provide an indication in WSJT-X when clocks are off like this.
> With concurrence I can do a patch for thismy idea is this.
> At least 5 decodes where 60% or more > 0.5 seconds is an indication of bad 
> timing.A message would be put in the Rx Frequency window "Your clock is 
> off...see help".? With appropriate references in the Help to search "your 
> clock is off" and time solutions.
> This doesn't cover the case where their clock is way off as they won't see 
> any decodes.? The only solution for that would be doing a time query from a 
> known source and I don't think we want to go that route.
> de Mike W9MDB

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

[wsjt-devel] rc7 and Call 1st - Yes, it's still active

[WB5JJJ]

Field Day Configuration.  Still checking out rc7 since it hasn't locked out
so far.  So why not run with it?

For some reason in FT8 and calling CQ, even though Call 1st is UNCHECKED,
about every other sequence an automatic response will be generated to a
random station calling me.

Sometimes this is OK, but since I'm working as 1D another "D" station is
not valid for points.  As it stands, I hover over the ESC key constantly to
cancel a "D" contact from completing.

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

Re: [wsjt-devel] Unwanted automatic switching to contest mode

[Claude Frantz]

On 6/23/19 12:53 PM, Palle Preben-Hansen, OZ1RH wrote:

Hi Palle,

Claude, at present this is not unwanted switching to EU VHF mode, but 
the naming or wording of what is happening is misleading.


The situation seems to be that you work a station that is in a contest 
requiring an exchange of a serial number and/or the full locator (a 
6-digit locator). In order to receive this from you he currently has to 
enable the EU VHF mode which confuses you. This has nothing to do with 
EU VHF, it is just an exchange of an 'oldfasioned' report, a serial 
number and the full locator. A serial number is needed in many other 
contests or QSO-parties than at VHF in EU.


I'm not sure how I should call it, but after this QSO, a red 
backgrounded field containing "EU VHF" appeared in the main window. When 
I opened Settings -> advanced, this contest mode wss clearly switched ON.


The function of WSJT-X and the nomenclature in the menu should be that 
each station requests the kind of exchange he needs from his QSO partner 
for whatever QSO-party or contest he is in. Then you send him what he 
wants and you receive the exchange you want. This may not be the same 
kind of exchange and you do not need to be in the same QSO-party or 
contest, but both of you receive and log the exchange you need. Then no 
confusing windows about a VHF or special contest mode is needed.


I had to revert manually to the "normal" mode, in Settings -> advanced. 
But the contest mode was switched ON automatically. I had no opportunity 
to refuse this mode switching.


There seems to be an error when logging the 6-digit locator in the 
 field. This is probably caused by the assumption that both 
stations send and receive the same type of exchange. The
logging could be fixed so each station logs the exchange received for 
his own contest.


According to the ADIF specs, the  field can only contain the 
primary administrative information. The specs give information about the 
possible values of this field. I had to remove manually from the log 
this  field with this erroneous value.


88, Claude (DJ0OT)


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

[wsjt-devel] Field Day time problem

[Black Michael via wsjt-devel]

I've seen about 2 dozen clubs doing Field Day where their clocks are off.
We need to provide an indication in WSJT-X when clocks are off like this.
With concurrence I can do a patch for thismy idea is this.
At least 5 decodes where 60% or more > 0.5 seconds is an indication of bad 
timing.A message would be put in the Rx Frequency window "Your clock is 
off...see help".  With appropriate references in the Help to search "your clock 
is off" and time solutions.
This doesn't cover the case where their clock is way off as they won't see any 
decodes.  The only solution for that would be doing a time query from a known 
source and I don't think we want to go that route.
de Mike W9MDB

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

Re: [wsjt-devel] Unwanted automatic switching to contest mode

[Palle Preben-Hansen, OZ1RH]

Claude, at present this is not unwanted switching to EU VHF mode, but the
naming or wording of what is happening is misleading.

The situation seems to be that you work a station that is in a contest
requiring an exchange of a serial number and/or the full locator (a 6-digit
locator). In order to receive this from you he currently has to enable the
EU VHF mode which confuses you. This has nothing to do with EU VHF, it is
just an exchange of an 'oldfasioned' report, a serial number and the full
locator. A serial number is needed in many other contests or QSO-parties
than at VHF in EU.

The function of WSJT-X and the nomenclature in the menu should be that each
station requests the kind of exchange he needs from his QSO partner for
whatever QSO-party or contest he is in. Then you send him what he wants and
you receive the exchange you want. This may not be the same kind of
exchange and you do not need to be in the same QSO-party or contest, but
both of you receive and log the exchange you need. Then no confusing
windows about a VHF or special contest mode is needed.

There seems to be an error when logging the 6-digit locator in the 
field. This is probably caused by the assumption that both stations send
and receive the same type of exchange. The
logging could be fixed so each station logs the exchange received for his
own contest.

73, Palle, OZ1RH.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Unwanted automatic switching to contest mode

[Claude Frantz]

On 6/23/19 10:26 AM, Reino Talarmo wrote:


Returning to the STATE value that now contains Maidenhead locator as an EU
VHF contest exchange information. I also think that it is a mistake to use
the STATE field for that purpose. We have  and that now contains
the same information.
Perhaps the use of the STATE field in the EU VHF contest is just a copy from
e.g. RTTY contest information exchange that is recoded into adi file, but
the EU EHF contest exchange happens to contain information that is not
defined in adi STATE?


In my own opinion, we should always respect the ADIF specs and avoid 
special interpretations. There are so many in use today, unfortunately. 
They make the interchange of information very, very difficult. In many 
cases, a conversion becomes necessary in order to make the interchange 
possible. Try to download your archive file from eQSL, in ADIF format 
and you will see a good example.


The ADIF specs offer many possibilities to include many information. But 
we should use the fields as they are defined, in order to make the 
interchange possible. Further, we have the ability to define own fields. 
Of course, these are then only in our own scope, but nevertheless this 
can be valuable.


88, Claude (DJ0OT)


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

Re: [wsjt-devel] Unwanted automatic switching to contest mode

[Reino Talarmo]

Returning to the STATE value that now contains Maidenhead locator as an EU
VHF contest exchange information. I also think that it is a mistake to use
the STATE field for that purpose. We have  and that now contains
the same information. 
Perhaps the use of the STATE field in the EU VHF contest is just a copy from
e.g. RTTY contest information exchange that is recoded into adi file, but
the EU EHF contest exchange happens to contain information that is not
defined in adi STATE?
73, Reino oh3ma



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

Re: [wsjt-devel] Unwanted automatic switching to contest mode

[Claude Frantz]

On 6/23/19 9:32 AM, Reino Talarmo wrote:


190622_095330 7.074 Tx FT8  0  0.0 1480 HB9CGH DJ0OT -04

190622_095400 7.074 Tx FT8  0  0.0 1480 HB9CGH R 550001 JN58TC


Some observations: 55 and 55 were not exchanged in

the QSO and they are typical FONE reports. According to the ADIF specs, I
consider JN36RW as not valid.

The sent report was exchanged first as the -04, which is equivalent to 55
and your sent it again as the first part of 550001.


Many thanks, Reino !

Yes, you are right. Unfortunately the S/N is not included in the ADIF 
log entry. I'm surprised to see the unusual RS only report related to a 
digital mode. But finally, what can we say about the tone here ? Hi hi..


I suggest to include the exchanges like 550001 in the appropriate fields 
of the ADIF records, which are probably the STX_STRING and SRX_STRING 
fields. Some programs generate the cabrillo log starting with the ADIF log.



Perhaps you have not included in your mail a message from HB9CGH such as:
190622_095345  7.074 Rx FT8 -04 1479 DJ0OT 5500nn JN36RW, which contains the
received report and locator.


You are right again. Here it is:

190622_095345 7.074 Rx FT8 -1  1.8 1479 DJ0OT 550006 JN36RW


The STATE value ie. locator is from that kind exchange of HB9CGH.


But such an information is not valid for a HB9 station, according to the 
ADIF specs, which say:


"the code for the contacted station's Primary Administrative Subdivision 
(e.g. US State, JA Island, VE Province)". Here, the 2 letter canton 
abbreviation code would be appropriate.


Best wishes,
Claude (DJ0OT)


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

Re: [wsjt-devel] Unwanted automatic switching to contest mode

[Reino Talarmo]

>190622_095330 7.074 Tx FT8  0  0.0 1480 HB9CGH DJ0OT -04 
190622_095400 7.074 Tx FT8  0  0.0 1480 HB9CGH R 550001 JN58TC 

>Some observations: 55 and 55 were not exchanged in
the QSO and they are typical FONE reports. According to the ADIF specs, I
consider JN36RW as not valid.

The sent report was exchanged first as the -04, which is equivalent to 55
and your sent it again as the first part of 550001. 
Perhaps you have not included in your mail a message from HB9CGH such as: 
190622_095345  7.074 Rx FT8 -04 1479 DJ0OT 5500nn JN36RW, which contains the
received report and locator.

The STATE value ie. locator is from that kind exchange of HB9CGH.

The automatic switching is sometimes unwanted, I agree.

73, Reino oh3ma



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

[wsjt-devel] Unwanted automatic switching to contest mode

[Claude Frantz]

Hi all,

Please allow me to report about an unusual behaviour which I have 
observed using 2.0.1.


Settings -> advanced -> special operating activity -> OFF

While operating in the usual way, on the 40 m band in FT8 mode, my 
station was called and the mode switched automatically to the EU VHF 
contest mode. I had no opportunity to avoid it. In ALL.TXT, this is 
reported as:


190622_095315 7.074 Rx FT8 -4  1.7 1479 DJ0OT HB9CGH JN36
190622_095330 7.074 Tx FT8  0  0.0 1480 HB9CGH DJ0OT -04 

190622_095400 7.074 Tx FT8  0  0.0 1480 HB9CGH R 550001 JN58TC 


190622_095415 7.074 Rx FT8  0  1.8 1479 DJ0OT HB9CGH RR73
190622_095430 7.074 Tx FT8  0  0.0 1480 HB9CGH DJ0OT 73

The corresponding log entry is:

HB9CGH JN36rw FT8 55 
55 20190622 095315 
20190622 095445 40m 7.075480 
DJ0OT JN58tc FT8  Sent: 
55  Rcvd: 55 JN36RW 


Some observations: 55 and 55 were not exchanged 
in the QSO and they are typical FONE reports. According to the ADIF 
specs, I consider JN36RW as not valid.


Some questions: How can I inhibit this unwanted and inappropriate 
switching to the contest mode ? Why have the above mentioned ADIF fields 
such strange values ?


Best whishes,
Claude (DJ0OT)


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