Re: [wsjt-devel] Monthly ALL.TXT archives

[Roy Gould]

To Gary, ZL2IFB: I can see that because you are so active that it would be
helpful to make monthly files.  It seems to me that an easy way to do this
is that on the first of the month, the file could be renamed to show the
month it is for, and then open a new clean file to continue the data
collection.

I searched my ALL.TXT file in EXCEL and found your call sign 17 times. Most
of these were from stations working you, but there were instances where I
was copying you.

73, Roy, W7IDM

On Wed, Jun 26, 2019 at 6:10 PM Dan Malcolm  wrote:

> I use a combination of the ALL.TXT breakup techniques.  I keep it yearly
> as I’m not quite so active as Gary.  My ALL.TXT file ran to 1.2 TB last
> year.  I use a PHP app I wrote that suits me.  It allows me to search by
> year including the current year.  About 0100 I have a scheduled copy of the
> current ALL.TXT copied to a search directory.  In the event I need to
> search since then I have a trivial batch file that can copy the most
> current version.  All searches are performed on copies, not the live file.
> My searches are probably complicated more than need be because the rig and
> WSJT-X runs 24/7 unless there is a thunder storm or I’m on vacation.
>
>
>
> __
>
> Dan – K4SHQ
>
>
>
> *From:* Gary Hinson [mailto:g...@isect.com]
> *Sent:* Wednesday, June 26, 2019 5:36 PM
> *To:* 'WSJT software development' 
> *Subject:* Re: [wsjt-devel] Monthly ALL.TXT archives
>
>
>
> Hi Roy.
>
>
>
> I am very active on FT8, clocking up about 900 FT8 QSOs per month and
> monitoring open HF FT8 subbands all ZL day while I work on the adjacent
> screen.
>
>
>
> My ALL.TXT typically grows to more than 30 Mb per month e.g.:
>
>
>
>
>
> Early each new month, I manually add the previous month’s ALL.TXT to a ZIP
> archive.  Luckily the ALL.TXT data structure is very simple so it
> compresses down neatly to about 40 Mb per year:
>
>
>
>
>
> I sometimes need to check through my ALL.TXT for details of a QSO that
> someone has claimed on a QSL card or by email, but doesn’t appear in my
> Logger32 station log.  It’s easy to open the relevant month’s ALL.TXT
> section from the ZIP archive and search for the QSO in question … and
> almost always I find a nearly-completed or completed QSO that for some
> reason wasn’t transferred to Logger32.
>
>
>
> If you try opening the current ALL.TXT file in, say, Notepad while WSJT-X
> or JTDX is still running, you’ll probably get pop-up warnings every 15
> seconds that the file has been updated when new decodes are written to it:
> that doesn’t happen if you are using a closed/archived ALL.TXT file.
>
>
>
> So, monthly ALL.TXTs are worthwhile for highly active stations … and I
> think they would be useful for almost everyone.
>
>
>
> 73
> Gary  ZL2iFB
>
>
>
> *From:* Roy Gould 
> *Sent:* 27 June 2019 03:52
> *To:* WSJT software development 
> *Subject:* Re: [wsjt-devel] Monthly ALL.TXT archives
>
>
>
> Thanks for the education. Before you started discussing the ALL.TXT file I
> did not know it existed. So I decided to check it out and see what it was
> all about. Here are some things that I found out about it in my case.
>
>
>
> The file in my computer was nearly 24 MB in size. I double clicked on it
> and it immediately came into Notepad on my Windows 10 computer so I could
> take a look at it. I tried Finding things such as CQ FD and it found
> several of those. I searched for my call sign (W7IDM) and it found it. I
> discovered that beginning on 19/02/27 that the format of the data stored
> was radically different and put into a much better format. So I deleted all
> of the previous entries leaving only the new format and that became the
> file that I am currently using. This file is about 6 MB in length.
>
>
>
> I tried loading the file into EXCEL from Office 365 and EXCEL said that it
> looks like this data is in fixed width columns and asked if I agreed. I
> said yes and the data came in just fine. Now that it is in EXCEL format I
> have the ability to use the powerful EXCEL data base functions to do a lot
> of different types of analysis.
>
>
>
> I don't see any particular need to want to break it into monthly segments.
> Perhaps it would be good to save it in yearly segments. It appears that I
> can easily work with a whole year of data at a time, so why break it up
> monthly?
>
>
>
> So, for what it is worth, these are my observations...
>
>
>
> 73, Roy, W7IDM
>
>
>
>
>
> On Tue, Jun 25, 2019 at 11:55 AM Sam W2JDB via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> Hi,
>
>
>
> I recompiled the program with "openread" and "sharedenynone" but it seems
> that when wsjtx attempts to append to the file I received the same error
> message.
>
>
>
> BTW, I open the file and close the file as soon as I finish scanning the
> file. It is only at the end of the decode when wsjtx is attempting to
> append to the file while alltext.exe is still parsing the file that the
> error pops up. If the scan finishes before wsjtx attempts to append 

Re: [wsjt-devel] Monthly ALL.TXT archives

[Dan Malcolm]

I use a combination of the ALL.TXT breakup techniques.  I keep it yearly as I’m 
not quite so active as Gary.  My ALL.TXT file ran to 1.2 TB last year.  I use a 
PHP app I wrote that suits me.  It allows me to search by year including the 
current year.  About 0100 I have a scheduled copy of the current ALL.TXT copied 
to a search directory.  In the event I need to search since then I have a 
trivial batch file that can copy the most current version.  All searches are 
performed on copies, not the live file.  My searches are probably complicated 
more than need be because the rig and WSJT-X runs 24/7 unless there is a 
thunder storm or I’m on vacation.

__
Dan – K4SHQ

From: Gary Hinson [mailto:g...@isect.com]
Sent: Wednesday, June 26, 2019 5:36 PM
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] Monthly ALL.TXT archives

Hi Roy.

I am very active on FT8, clocking up about 900 FT8 QSOs per month and 
monitoring open HF FT8 subbands all ZL day while I work on the adjacent screen.

My ALL.TXT typically grows to more than 30 Mb per month e.g.:

[cid:image001.png@01D52C51.0A1E2AE0]

Early each new month, I manually add the previous month’s ALL.TXT to a ZIP 
archive.  Luckily the ALL.TXT data structure is very simple so it compresses 
down neatly to about 40 Mb per year:

[cid:image003.png@01D52C51.0A1E2AE0]

I sometimes need to check through my ALL.TXT for details of a QSO that someone 
has claimed on a QSL card or by email, but doesn’t appear in my Logger32 
station log.  It’s easy to open the relevant month’s ALL.TXT section from the 
ZIP archive and search for the QSO in question … and almost always I find a 
nearly-completed or completed QSO that for some reason wasn’t transferred to 
Logger32.

If you try opening the current ALL.TXT file in, say, Notepad while WSJT-X or 
JTDX is still running, you’ll probably get pop-up warnings every 15 seconds 
that the file has been updated when new decodes are written to it: that doesn’t 
happen if you are using a closed/archived ALL.TXT file.

So, monthly ALL.TXTs are worthwhile for highly active stations … and I think 
they would be useful for almost everyone.

73
Gary  ZL2iFB

From: Roy Gould mailto:roygou...@gmail.com>>
Sent: 27 June 2019 03:52
To: WSJT software development 
mailto:wsjt-devel@lists.sourceforge.net>>
Subject: Re: [wsjt-devel] Monthly ALL.TXT archives

Thanks for the education. Before you started discussing the ALL.TXT file I did 
not know it existed. So I decided to check it out and see what it was all 
about. Here are some things that I found out about it in my case.

The file in my computer was nearly 24 MB in size. I double clicked on it and it 
immediately came into Notepad on my Windows 10 computer so I could take a look 
at it. I tried Finding things such as CQ FD and it found several of those. I 
searched for my call sign (W7IDM) and it found it. I discovered that beginning 
on 19/02/27 that the format of the data stored was radically different and put 
into a much better format. So I deleted all of the previous entries leaving 
only the new format and that became the file that I am currently using. This 
file is about 6 MB in length.

I tried loading the file into EXCEL from Office 365 and EXCEL said that it 
looks like this data is in fixed width columns and asked if I agreed. I said 
yes and the data came in just fine. Now that it is in EXCEL format I have the 
ability to use the powerful EXCEL data base functions to do a lot of different 
types of analysis.

I don't see any particular need to want to break it into monthly segments. 
Perhaps it would be good to save it in yearly segments. It appears that I can 
easily work with a whole year of data at a time, so why break it up monthly?

So, for what it is worth, these are my observations...

73, Roy, W7IDM


On Tue, Jun 25, 2019 at 11:55 AM Sam W2JDB via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:
Hi,

I recompiled the program with "openread" and "sharedenynone" but it seems that 
when wsjtx attempts to append to the file I received the same error message.

BTW, I open the file and close the file as soon as I finish scanning the file. 
It is only at the end of the decode when wsjtx is attempting to append to the 
file while alltext.exe is still parsing the file that the error pops up. If the 
scan finishes before wsjtx attempts to append to the file, there is no error.

Sorry, but that is the best that I can do. As I posted before, I do not use the 
alltext.exe while wsjtx is running.

Sam W2JDB



-Original Message-
From: DG2YCB, Uwe mailto:dg2...@gmx.de>>
To: 'WSJT software development' 
mailto:wsjt-devel@lists.sourceforge.net>>
Sent: Tue, Jun 25, 2019 12:13 pm
Subject: Re: [wsjt-devel] Monthly ALL.TXT archives
Sam,
alltext.exe works great, BUT there is one big disadvantage: Once the ALL.txt 
file is opened with alltext.exe, the ALL.TXT file is locked by Windows. And due 
to that WSJT-X is showing error messages “Cannot open …ALL.TXT” 

Re: [wsjt-devel] Monthly ALL.TXT archives

[Gary Hinson]

Hi Roy.

 

I am very active on FT8, clocking up about 900 FT8 QSOs per month and 
monitoring open HF FT8 subbands all ZL day while I work on the adjacent screen. 
 

 

My ALL.TXT typically grows to more than 30 Mb per month e.g.:

 



 

Early each new month, I manually add the previous month’s ALL.TXT to a ZIP 
archive.  Luckily the ALL.TXT data structure is very simple so it compresses 
down neatly to about 40 Mb per year:

 



 

I sometimes need to check through my ALL.TXT for details of a QSO that someone 
has claimed on a QSL card or by email, but doesn’t appear in my Logger32 
station log.  It’s easy to open the relevant month’s ALL.TXT section from the 
ZIP archive and search for the QSO in question … and almost always I find a 
nearly-completed or completed QSO that for some reason wasn’t transferred to 
Logger32.   

 

If you try opening the current ALL.TXT file in, say, Notepad while WSJT-X or 
JTDX is still running, you’ll probably get pop-up warnings every 15 seconds 
that the file has been updated when new decodes are written to it: that doesn’t 
happen if you are using a closed/archived ALL.TXT file.

 

So, monthly ALL.TXTs are worthwhile for highly active stations … and I think 
they would be useful for almost everyone.

 

73
Gary  ZL2iFB

 

From: Roy Gould  
Sent: 27 June 2019 03:52
To: WSJT software development 
Subject: Re: [wsjt-devel] Monthly ALL.TXT archives

 

Thanks for the education. Before you started discussing the ALL.TXT file I did 
not know it existed. So I decided to check it out and see what it was all 
about. Here are some things that I found out about it in my case.

 

The file in my computer was nearly 24 MB in size. I double clicked on it and it 
immediately came into Notepad on my Windows 10 computer so I could take a look 
at it. I tried Finding things such as CQ FD and it found several of those. I 
searched for my call sign (W7IDM) and it found it. I discovered that beginning 
on 19/02/27 that the format of the data stored was radically different and put 
into a much better format. So I deleted all of the previous entries leaving 
only the new format and that became the file that I am currently using. This 
file is about 6 MB in length.

 

I tried loading the file into EXCEL from Office 365 and EXCEL said that it 
looks like this data is in fixed width columns and asked if I agreed. I said 
yes and the data came in just fine. Now that it is in EXCEL format I have the 
ability to use the powerful EXCEL data base functions to do a lot of different 
types of analysis.

 

I don't see any particular need to want to break it into monthly segments. 
Perhaps it would be good to save it in yearly segments. It appears that I can 
easily work with a whole year of data at a time, so why break it up monthly?

 

So, for what it is worth, these are my observations...

 

73, Roy, W7IDM

 

 

On Tue, Jun 25, 2019 at 11:55 AM Sam W2JDB via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

Hi,

 

I recompiled the program with "openread" and "sharedenynone" but it seems that 
when wsjtx attempts to append to the file I received the same error message. 

 

BTW, I open the file and close the file as soon as I finish scanning the file. 
It is only at the end of the decode when wsjtx is attempting to append to the 
file while alltext.exe is still parsing the file that the error pops up. If the 
scan finishes before wsjtx attempts to append to the file, there is no error. 

 

Sorry, but that is the best that I can do. As I posted before, I do not use the 
alltext.exe while wsjtx is running.

 

Sam W2JDB

 

 

 

-Original Message-
From: DG2YCB, Uwe mailto:dg2...@gmx.de> >
To: 'WSJT software development' mailto:wsjt-devel@lists.sourceforge.net> >
Sent: Tue, Jun 25, 2019 12:13 pm
Subject: Re: [wsjt-devel] Monthly ALL.TXT archives

Sam,

alltext.exe works great, BUT there is one big disadvantage: Once the ALL.txt 
file is opened with alltext.exe, the ALL.TXT file is locked by Windows. And due 
to that WSJT-X is showing error messages “Cannot open …ALL.TXT” because the 
file is in use (see screen shot). Is there a fix for this (or any workaround)? 
I don’t know why, but the normal Windows editor does not lock the ALL.txt. file 
like alltxt.exe does.

 



 

73 de Uwe, DG2YCB 

 

 

Von: Sam W2JDB via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net 
 ] 
Gesendet: Dienstag, 25. Juni 2019 16:07
An: wsjt-devel@lists.sourceforge.net  
Cc: Sam W2JDB
Betreff: Re: [wsjt-devel] Monthly ALL.TXT archives

 

Hi Rich,

 

IN the QLOGBeta file folder is a program called alltext.exe.

I use it to search the all.txt file. It has various filters and presents only 
the lines that meet the criteria. I use that when I need to confirm what I 
think is an incomplete QSO. Try it. Its pretty fast. 

 

73, 

 

Sam W2JDB

 

 

 

-Original Message-
From: Rich Zwirko - K1HTV 

Re: [wsjt-devel] clock patch

[Neal Pollack]

Only some are due to lack of internet.
USB GPS receivers are now approx $12 USD on Ebay.  I have tested a few and
they work fine with NMEAtime2. Which is none simple software.
The message could suggest what to do for both internet connected and
off-grid users.  But really, to keep the message short, it should point to
a help page or file that is specific to time setting options, rather than a
huge user guide, since the public no longer reads very much.

With regard to time setting software, I really can't recommend BKTtimeSync
for the same reasons we are discussing this issue:  It works for me but is
far too complicated for the average ham, and lacks sufficient docs or help.

But NMEAtime2 is really simple and just works, for using GPS.

For internet users,  NetTime or Dimension4 for basic users or Meinberg NTP
for more advanced users.

BUT!!!  All of the users, both internet and GPS, need to be reminded to
turn OFF windows automatic time setting before using the software's above.
I see too many users whose DT is swinging wildly between plus and minus 2.5
seconds, then next at 0.2 DT.  This is because they have windows trying to
set time while also using the above programs to set time, and the two are
fighting a tug of war.

If you guys put a DT warning message in the code that points to a time help
page, then I volunteer to be one of several editors for the above type of
help content about time sync'ing options.

Cheers,

Neal
N6YFM

On Wed, Jun 26, 2019, 3:16 AM 
wrote:

> Send wsjt-devel mailing list submissions to
> wsjt-devel@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> or, via email, send a message with subject or body 'help' to
> wsjt-devel-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
> wsjt-devel-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wsjt-devel digest..."
>
>
> Today's Topics:
>
>1. Re: Clock patch (DG2YCB, Uwe)
>2. Re: Clock patch (Roeland Jansen)
>3. Re: Clock patch (Bill Somerville)
>
>
> --
>
> Message: 1
> Date: Wed, 26 Jun 2019 11:36:58 +0200
> From: "DG2YCB, Uwe" 
> To: "'Black Michael'" , "'WSJT software
> development'" 
> Subject: Re: [wsjt-devel] Clock patch
> Message-ID: <004801d52c02$b33f1430$19bd3c90$@gmx.de>
> Content-Type: text/plain; charset="utf-8"
>
> I?ve not yet seen the results, but your this approach really looks like
> something which could bring a substantial progress regarding the timing
> issue.
>
>
>
> Reason why I am supporting a warning message is that, besides field days,
> I saw dozens of OMs/YLs who are not aware at all that system time of their
> PCs needed to by synced. Alone two examples yesterday. Contacted both.
> Seemed to be both are ?old? men, with no computer skills. One replied the
> following: ?I am no longer a very young man (84 years old) who tries to
> tamper with the new methods; with a total ignorance of the English
> language??. If we like it or not: That?s the reality! Of course we could
> let FT8, FT4, etc. be something only for the tiny community of
> well-educated, scientifically trained OMs with good to excellent computer
> skills. But if we want to make QSOs with more OMs/YLs, then WE need to do
> something which helps THEM to overcome the hurdles.
>
>
>
> 73 de Uwe, DG2YCB
>
>
>
> Von: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
>
> Gesendet: Mittwoch, 26. Juni 2019 06:19
> An: WSJT Software Development
> Cc: Black Michael
> Betreff: [wsjt-devel] Clock patch
>
>
>
> This patch shows a message if 80% of DT values are >= 0.5 seconds.
>
>
>
> https://www.dropbox.com/s/8j7qao9wa4wmzdm/clock.patch?dl=1
>
>
>
> I picked the 50% point of FT4's 1 second tolerance but perhaps a slightly
> larger value might be appropriate.
>
>
>
> I think most, if not everybody, can get the > 20% < 0.5 seconds without a
> problem.
>
>
>
> Even with my rather extreme latency of 300-400ms I don't trigger this.
>
>
>
> de Mike W9MDB
>
>
>
>
>
> -- next part --
> An HTML attachment was scrubbed...
>
> --
>
> Message: 2
> Date: Wed, 26 Jun 2019 11:55:47 +0200
> From: Roeland Jansen 
> To: WSJT software development 
> Subject: Re: [wsjt-devel] Clock patch
> Message-ID:
> <
> caj2u8oytzmmcmcauqppc9d3hk+6jxw1nxnvht-5auv5t5wt...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I did not look at the patches Mike sent but:
>
> https://time.is/
>
> gives you how good/bad the time  is. If you start up:  do check like this
> and refuse to go on if the timeskew is too large.
> Add a link how to fix in the message and you force people to fix it.
>
> (not that people read notices)
>
> just my bad idea.
>
>
> On Wed, Jun 26, 2019 at 11:41 AM DG2YCB, 

Re: [wsjt-devel] Monthly ALL.TXT archives

[Roy Gould]

Thanks for the education. Before you started discussing the ALL.TXT file I
did not know it existed. So I decided to check it out and see what it was
all about. Here are some things that I found out about it in my case.

The file in my computer was nearly 24 MB in size. I double clicked on it
and it immediately came into Notepad on my Windows 10 computer so I could
take a look at it. I tried Finding things such as CQ FD and it found
several of those. I searched for my call sign (W7IDM) and it found it. I
discovered that beginning on 19/02/27 that the format of the data stored
was radically different and put into a much better format. So I deleted all
of the previous entries leaving only the new format and that became the
file that I am currently using. This file is about 6 MB in length.

I tried loading the file into EXCEL from Office 365 and EXCEL said that it
looks like this data is in fixed width columns and asked if I agreed. I
said yes and the data came in just fine. Now that it is in EXCEL format I
have the ability to use the powerful EXCEL data base functions to do a lot
of different types of analysis.

I don't see any particular need to want to break it into monthly segments.
Perhaps it would be good to save it in yearly segments. It appears that I
can easily work with a whole year of data at a time, so why break it up
monthly?

So, for what it is worth, these are my observations...

73, Roy, W7IDM


On Tue, Jun 25, 2019 at 11:55 AM Sam W2JDB via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hi,
>
> I recompiled the program with "openread" and "sharedenynone" but it seems
> that when wsjtx attempts to append to the file I received the same error
> message.
>
> BTW, I open the file and close the file as soon as I finish scanning the
> file. It is only at the end of the decode when wsjtx is attempting to
> append to the file while alltext.exe is still parsing the file that the
> error pops up. If the scan finishes before wsjtx attempts to append to the
> file, there is no error.
>
> Sorry, but that is the best that I can do. As I posted before, I do not
> use the alltext.exe while wsjtx is running.
>
> Sam W2JDB
>
>
>
> -Original Message-
> From: DG2YCB, Uwe 
> To: 'WSJT software development' 
> Sent: Tue, Jun 25, 2019 12:13 pm
> Subject: Re: [wsjt-devel] Monthly ALL.TXT archives
>
> Sam,
> alltext.exe works great, BUT there is one big disadvantage: Once the
> ALL.txt file is opened with alltext.exe, the ALL.TXT file is locked by
> Windows. And due to that WSJT-X is showing error messages “Cannot open
> …ALL.TXT” because the file is in use (see screen shot). Is there a fix for
> this (or any workaround)? I don’t know why, but the normal Windows editor
> does not lock the ALL.txt. file like alltxt.exe does.
>
>
> 73 de Uwe, DG2YCB
>
>
> *Von:* Sam W2JDB via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
> *Gesendet:* Dienstag, 25. Juni 2019 16:07
> *An:* wsjt-devel@lists.sourceforge.net
> *Cc:* Sam W2JDB
> *Betreff:* Re: [wsjt-devel] Monthly ALL.TXT archives
>
> Hi Rich,
>
> IN the QLOGBeta file folder is a program called alltext.exe.
> I use it to search the all.txt file. It has various filters and presents
> only the lines that meet the criteria. I use that when I need to confirm
> what I think is an incomplete QSO. Try it. Its pretty fast.
>
> 73,
>
> Sam W2JDB
>
>
>
> -Original Message-
> From: Rich Zwirko - K1HTV 
> To: WSJT 
> Sent: Tue, Jun 25, 2019 10:00 am
> Subject: [wsjt-devel] Monthly ALL.TXT archives
> Recently, a WSJT-X users asked me how to check if a QSO was actually
> completed. He had received a request to confirm a QSO which was not in his
> log. I pointed him at the ALL.TXT file. He got back to me later saying that
> the file size was enormous and too large for any of his text editors to
> read.
>
> Monthly, I edit my ALL.TXT file and manually archive the decoded data for
> future use. These files have been used a number of times to confirm QSOs
> when a station that I work, usually a DXpedition, says I'm not in the log
> and I know that it was a solid QSO. I excerpt the decodes, showing
> responses to me and others, attaching the info to an email that is sent to
> him.
>
> Unless it is kept to a reasonable size, the ALL.TXT will be useless to
> most WSJT-X ops who want to check it. Why not archive the lines of decoded
> data into a file with a file name reflecting the month that the data was
> decoded, such as:
>
> 2019-06ALL.TXT
>
> I believe that this change should be seriously considered in a future
> release of WSJT-X.
>
> 73,
> Rich - K1HTV
>
>
> ___
> 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 

Re: [wsjt-devel] Clock patch

[VE3FBZ]

Island people can always sync from know short wave time standards. WWV, CHU.

I send jtx msgs but they still not connect.  Let them figure out that setting 
their time correctly will help increase their contacts.
My 2 cents...again.

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




> On Jun 26, 2019, at 07:04, Roeland Jansen  wrote:
> 
> 
> you are right it does. On the other hand do you really want people to be off 
> on time? 
> 
> You could consider instead of b0rking out -- if there is no internet, warn 
> and go on. 
> 
> Then you have three groups:
> 
> a) groups of people that understand that any system without correct time 
> settings should not be switched on for a start.
> and they have good timing. this group is totally OK
> 
> b) the peope without internet because they are on a weird idland without 
> internet --> they can go on. this group is totally OK
> 
> c) people who have internet and have the time wrong. Those will be stopped 
> dead in the tracks. this group is NOK
> 
> I know it's a bastard operator from hell solution but sometimes forcing 
> people helps. 
> 
> and it's just an idea... just an idea
> 
> 
> 
>> On Wed, Jun 26, 2019 at 12:20 PM Bill Somerville  
>> wrote:
>> On 26/06/2019 10:55, Roeland Jansen wrote:
>> > I did not look at the patches Mike sent but:
>> >
>> > https://time.is/
>> >
>> > gives you how good/bad the time  is. If you start up:  do check like 
>> > this and refuse to go on if the timeskew is too large.
>> > Add a link how to fix in the message and you force people to fix it.
>> >
>> > (not that people read notices)
>> >
>> > just my bad idea.
>> 
>> Hi Roeland,
>> 
>> doesn't that miss the point that many of the poor time sync situations 
>> are where the user has no Internet connectivity?
>> 
>> 73
>> Bill
>> G4WJS.
>> 
>> 
>> 
>> ___
>> 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] Clock patch

[Roeland Jansen]

you are right it does. On the other hand do you really want people to be
off on time?

You could consider instead of b0rking out -- if there is no internet, warn
and go on.

Then you have three groups:

a) groups of people that understand that any system without correct time
settings should not be switched on for a start.
and they have good timing. this group is totally OK

b) the peope without internet because they are on a weird idland without
internet --> they can go on. this group is totally OK

c) people who have internet and have the time wrong. Those will be stopped
dead in the tracks. this group is NOK

I know it's a bastard operator from hell solution but sometimes forcing
people helps.

and it's just an idea... just an idea



On Wed, Jun 26, 2019 at 12:20 PM Bill Somerville 
wrote:

> On 26/06/2019 10:55, Roeland Jansen wrote:
> > I did not look at the patches Mike sent but:
> >
> > https://time.is/
> >
> > gives you how good/bad the time  is. If you start up:  do check like
> > this and refuse to go on if the timeskew is too large.
> > Add a link how to fix in the message and you force people to fix it.
> >
> > (not that people read notices)
> >
> > just my bad idea.
>
> Hi Roeland,
>
> doesn't that miss the point that many of the poor time sync situations
> are where the user has no Internet connectivity?
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> 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] Clock patch

[Bill Somerville]

On 26/06/2019 10:55, Roeland Jansen wrote:

I did not look at the patches Mike sent but:

https://time.is/

gives you how good/bad the time  is. If you start up:  do check like 
this and refuse to go on if the timeskew is too large.

Add a link how to fix in the message and you force people to fix it.

(not that people read notices)

just my bad idea.


Hi Roeland,

doesn't that miss the point that many of the poor time sync situations 
are where the user has no Internet connectivity?


73
Bill
G4WJS.



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

Re: [wsjt-devel] Clock patch

[Roeland Jansen]

I did not look at the patches Mike sent but:

https://time.is/

gives you how good/bad the time  is. If you start up:  do check like this
and refuse to go on if the timeskew is too large.
Add a link how to fix in the message and you force people to fix it.

(not that people read notices)

just my bad idea.


On Wed, Jun 26, 2019 at 11:41 AM DG2YCB, Uwe  wrote:

> I’ve not yet seen the results, but your this approach really looks like
> something which could bring a substantial progress regarding the timing
> issue.
>
>
>
> Reason why I am supporting a warning message is that, besides field days,
> I saw dozens of OMs/YLs who are not aware at all that system time of their
> PCs needed to by synced. Alone two examples yesterday. Contacted both.
> Seemed to be both are “old” men, with no computer skills. One replied the
> following: “I am no longer a very young man (84 years old) who tries to
> tamper with the new methods; with a total ignorance of the English
> language…”. If we like it or not: That’s the reality! Of course we could
> let FT8, FT4, etc. be something only for the tiny community of
> well-educated, scientifically trained OMs with good to excellent computer
> skills. But if we want to make QSOs with more OMs/YLs, then WE need to do
> something which helps THEM to overcome the hurdles.
>
>
>
> 73 de Uwe, DG2YCB
>
>
>
> *Von:* Black Michael via wsjt-devel [mailto:
> wsjt-devel@lists.sourceforge.net]
> *Gesendet:* Mittwoch, 26. Juni 2019 06:19
> *An:* WSJT Software Development
> *Cc:* Black Michael
> *Betreff:* [wsjt-devel] Clock patch
>
>
>
> This patch shows a message if 80% of DT values are >= 0.5 seconds.
>
>
>
> https://www.dropbox.com/s/8j7qao9wa4wmzdm/clock.patch?dl=1
>
>
>
> I picked the 50% point of FT4's 1 second tolerance but perhaps a slightly
> larger value might be appropriate.
>
>
>
> I think most, if not everybody, can get the > 20% < 0.5 seconds without a
> problem.
>
>
>
> Even with my rather extreme latency of 300-400ms I don't trigger this.
>
>
>
> 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] Clock patch

[DG2YCB, Uwe]

I’ve not yet seen the results, but your this approach really looks like 
something which could bring a substantial progress regarding the timing issue. 

 

Reason why I am supporting a warning message is that, besides field days, I saw 
dozens of OMs/YLs who are not aware at all that system time of their PCs needed 
to by synced. Alone two examples yesterday. Contacted both. Seemed to be both 
are “old” men, with no computer skills. One replied the following: “I am no 
longer a very young man (84 years old) who tries to tamper with the new 
methods; with a total ignorance of the English language…”. If we like it or 
not: That’s the reality! Of course we could let FT8, FT4, etc. be something 
only for the tiny community of well-educated, scientifically trained OMs with 
good to excellent computer skills. But if we want to make QSOs with more 
OMs/YLs, then WE need to do something which helps THEM to overcome the hurdles. 

 

73 de Uwe, DG2YCB 

 

Von: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Gesendet: Mittwoch, 26. Juni 2019 06:19
An: WSJT Software Development
Cc: Black Michael
Betreff: [wsjt-devel] Clock patch

 

This patch shows a message if 80% of DT values are >= 0.5 seconds.

 

https://www.dropbox.com/s/8j7qao9wa4wmzdm/clock.patch?dl=1

 

I picked the 50% point of FT4's 1 second tolerance but perhaps a slightly 
larger value might be appropriate.

 

I think most, if not everybody, can get the > 20% < 0.5 seconds without a 
problem.

 

Even with my rather extreme latency of 300-400ms I don't trigger this.

 

de Mike W9MDB

 

 

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