On 08/02/2017 00:48, Bill Somerville wrote:
On 08/02/2017 00:44, Josh Rovero wrote:
Is there a setting that can be used to prevent the accumulation of c2
and wav files in the
C:\Users\\appdata\Local\\save directory?
Selecting menu item Save->None isn't it. They still accumulate.
Hi Josh,
tha
On 08/02/2017 00:44, Josh Rovero wrote:
> Is there a setting that can be used to prevent the accumulation of c2
> and wav files in the
> C:\Users\\appdata\Local\\save directory?
>
> Selecting menu item Save->None isn't it. They still accumulate.
Hi Josh,
that should be it, if it is not working
Is there a setting that can be used to prevent the accumulation of c2 and
wav files in the C:\Users\\appdata\Local\\save
directory?
Selecting menu item Save->None isn't it. They still accumulate.
--
P.J. "Josh" Rovero http://www.roveroresearch.org
Ham Radio: KK1D http://www.roveroresear
On 08/02/2017 00:24, Phil Frost wrote:
> I notice the source has a debian/directory, but not debian/control.
> I'd like to make a custom build and I figure this is the quickest way
> to a working build.
>
> It seems there's already some process in place for building Debian
> packages; who mainta
I notice the source has a debian/directory, but not debian/control. I'd
like to make a custom build and I figure this is the quickest way to a
working build.
It seems there's already some process in place for building Debian
packages; who maintains that or where can I find it?
Gee Laurie, I think you are being a bit extreme asking for users to accept some
(or any) responsibility.
You should be well aware that these days we all expect our software to overcome
any thought processes or effort on the users behalf and if anything goes wrong,
or is not absolutely perfect,
Also, do you have the log fields visible on JTAlert? The "Time" field there is
the start time it uses prior to the change to WSJT-X.
de Mike W9MDB
From: ANDY DURBIN
To: "wsjt-devel@lists.sourceforge.net"
Sent: Tuesday, February 7, 2017 3:57 PM
Subject: Re: [wsjt-devel] WSJT-X: QSO s
That will be in 1.7.1.
de Mike W9MDB
From: ANDY DURBIN
To: "wsjt-devel@lists.sourceforge.net"
Sent: Tuesday, February 7, 2017 3:57 PM
Subject: Re: [wsjt-devel] WSJT-X: QSO start and end times (Laurie, VK3AMA)
"There is also the
option that the *user take some responsibility* ov
"There is also the option that the *user take some responsibility* over
what they are logging and spend a few seconds during a lengthy JT65/9
QSO to ensure that the Start time (if they are using JTAlert) is
correct. If they are not using JTAlert, the Time_on field is available
for editing prior to
Agreed, Laurie - and considering systems like LoTW or QRZ etc allow for +/-30
minutes for award tracking, it would seem this isn't a massive issue to the end
user anyway, especially if they're paying attention to what they're actually
logging (I know those extra few key strokes may be difficult
Hi
I created a new Audio Device in the "Audio MIDI Setup“ Application (comes with
OS X), and named it so that it is alphabetically the first Audio Device
(something like „AAA…“);
I added just the "USB Audio CODEC“ to it. So it is basically a reference to the
"USB Audio CODEC“ device.
Then I co
On 8/02/2017 3:04 AM, ANDY DURBIN wrote:
- QSO Start time field in Log Fields area. Populated with the utc time
when
a new QSO partner Callsign is detected. If it contains a value
it will
override the time provided by WSJT-X and JT65-HF logging event.
I could find no record th
On 8/02/2017 5:09 AM, Bill Somerville wrote:
Added to all this you have the ALL.TXT file for reference so if in the
rare event you forget that the start time is too early due to an
extended call that is not heard and, say, if an LotW confirmation is
not forthcoming; you can review the QSO,
My Comments inline...
On 8/02/2017 1:16 AM, ANDY DURBIN wrote:
"I also wonder if the ones complaining are using the older version of
JTAlert which tries to "guess" the TIME_ON from the 1st observation of
the callsign which works on a normal QSO but not when you're waiting
for them at all"
Hi Siegfried,
> My audio device (which is provided by the driver for the USB connected IC7300
> and RS590S) is „USB Audio CODEC“, which is alphabetically below „Build-In
> Output“ etc.
Same as mine. I also make sure in System Preferences > Sound that
Input/Output devices are also USB Audio C
All the logic is not just to make start times matchthat's just a capability
added to the logic.There are several situations where the start of QSO is not
easily determined as I sent earlier and the DX call changing is not the most
reliable indicator.
Hopefully the patch I sent makes it bet
This improves the start time a bit and I think covers the test that you ran
where you skipped the grid.So received grid messages and reports will set start
time (back a couple minutes) if start time is not already set.
https://www.dropbox.com/s/m6byc65bkkabtyx/timeon.patch?dl=1
de Mike W9MDB
Hi
thank you for trying!
What are the names of the audio devices you see in the
Preferences->Audio->Soundcard Input and Output combo boxes?
Maybe the problem is related to the naming of these devices - for example it
might accidentially switch to the first device in the list, and depending on
t
On 07/02/2017 16:40, ANDY DURBIN wrote:
"what could that reasonable test be?"
It could be a test that the time span between the derived QSO start
time and the derived QSO end time did not exceed a user specified
maximum QSO duration. I would set it to 30 minutes. You could set
it to what
I'm still pleased by JTSDK. I'm using Debian 8.6 (Jessie) and have
already done several successful upgrades (currently r7472 - I'm overdue
:-) ) using JTSDK.
You have to be careful to follow the instructions to the letter when
installing JTSDK, particularly the README.pkg-lists file. But once
Hi Keith and Siegfried,
I downloaded r7405 (the official release) and have been trying all afternoon to
reproduce this problem and cannot succeed. No faults after several hours. I
wonder what is different with my setup:
MacBook Pro with OSX 10.11.6. Mac USB to powered hub: hub USB to Signa
I can see a couple of improvements that should solve the problem you saw and
get this to work with double-clicking messages.
So...what agreement do we want for determining the QSO start time? What
message is time_on for each side?
de Mike W9MDB
From: Bill Somerville
To: wsjt-devel@lists
Were you progressing by double-clicking the messages instead of using the
buttons?
Right now that resets the start time. Maybe that needs to be changed.
doubleClickOnCall2 and doubleClickOnCall both reset start time.I think the
set_dateTimeQSO(-1) could be removed from both of those.Do we have s
"what could that reasonable test be?"
It could be a test that the time span between the derived QSO start time and
the derived QSO end time did not exceed a user specified maximum QSO duration.
I would set it to 30 minutes. You could set it to whatever time was
appropriate for your fishing
Why new DX call will not work well.
CQ W9MDB EM49W9MDB K1JT W9MDB G4WJS IO91 -- your proposed start timeI work
K1JTI then work somebody else while you keep trying perhaps on a split freqYou
finally get through somewhere down the pileup
Your start time may not even be close.
The logic in there
On 07/02/2017 16:04, Black Michael wrote:
Give me the ALL.TXT entries from the test and the times you saw on
logging and I'll figure out what's going on.
Hi Mike,
Station A ALL.TXT:
1509 Transmitting 14.076 MHz JT65: G0FUN G4WJS IO91
1511 Transmitting 14.076 MHz JT65: G0FUN G4WJS IO91
1
On 07/02/2017 16:16, Bill Somerville wrote:
> 1534 Transmitting 14.076 MHz JT65: G4WJS G0FUN 73
> 1535 -1 0.1 1500 # G0FUN G4WJS 73
...
Sorry prematurely sent e-mail.
I believe Station A (G4WJS) had a log window showing time on and off as
15:31 and Station B (G0FUN) was offered time on an
That's JTAlert's "guess" of when the QSO start from the "new QSO partner" which
can be horribly wrong as you've found out.
WSJT-X r7430 added it's own TIME_ON field and JTAlert 2.9.0 now uses that
instead of it's own guess.
de Mike W9MDB
From: ANDY DURBIN
To: "wsjt-devel@lists.sourceforg
Give me the ALL.TXT entries from the test and the times you saw on logging and
I'll figure out what's going on.
de Mike W9MDB
From: Bill Somerville
To: wsjt-devel@lists.sourceforge.net
Sent: Tuesday, February 7, 2017 9:50 AM
Subject: Re: [wsjt-devel] WSJT-X: QSO start and end times
"I do believe it's JTAlert 2.9.0 that has the TIME_ON fix and you have to be
using r7430 or greater.
de Mike W9MDB"
I browsed the JTAlert change log:
JTAlert Ver 2.5.0 13 Nov 2014
- QSO Start time field in Log Fields area. Populated with the utc time when
a new QSO partner Callsign is
So we need to define "reality". and "the actual start of QSO". JTAlert pre
2.9.0 would have used the CQ or Tx 1 message time as the 1st observation of the
QSO.
Given a standard QSO what's the "start"?
0 - CQ W9MDB EM491 - W9MDB G4WJS IO912 - G4WJS W9MDB -013 - W9MDB G4WJS R-014 -
G4WJS W9MDB R
On 07/02/2017 15:40, Black Michael wrote:
How do you do the simulation?
The TIME_ON defaults to the logging time only when it hasn't been set
yet. Currently only done when Tx 2 or 3 is clicked by either Next or Now.
Are you simulating without clicking? That might 'splain it.
Hi Mike,
two
How do you do the simulation?
The TIME_ON defaults to the logging time only when it hasn't been set yet.
Currently only done when Tx 2 or 3 is clicked by either Next or Now.Are you
simulating without clicking? That might 'splain it.
de Mike W9MDB
From: Bill Somerville
To: wsjt-devel@li
On 07/02/2017 13:50, Black Michael wrote:
> Where are the examples of it being wrong? I'm a bit pedantic about
> time and would like to fix it to be what everybody agrees is "correct".
Hi Mike,
TBH I am struggling to get the current version of WSJT-X to record any
reasonable QSO start time whe
On 07/02/2017 14:16, ANDY DURBIN wrote:
Any code that attempts to derive a QSO start time should also include
a reasonableness test on QSO duration.
HI Andy,
what could that reasonable test be?
For example a pair EME operators with marginal conditions and mid level
equipment might expect to
Hi Bill,
>> At line 54 of file C:\Users\*bill*\src\wsjt-svn\lib\decoder.f90 (unit
>> = 13)
>>
>> Fortran runtime error: Cannot open file
>> 'C:\Users\OEM\AppData\Local\Temp\WSJT-X*/*decoded.txt': Permission denied
In r7559 I made a change so that up to three tries will be made to open
this file,
I do believe it's JTAlert 2.9.0 that has the TIME_ON fix and you have to be
using r7430 or greater.
de Mike W9MDB
From: ANDY DURBIN
To: "wsjt-devel@lists.sourceforge.net"
Sent: Tuesday, February 7, 2017 8:16 AM
Subject: Re: [wsjt-devel] WSJT-X: QSO start and end times
"I also wo
"I also wonder if the ones complaining are using the older version of JTAlert
which tries to "guess" the TIME_ON from the 1st observation of the callsign
which works on a normal QSO but not when you're waiting for them at all"
I have not complained to anyone but I have had to track down multipl
The CQ/QRZ logic doesn't allow for sitting on your grid report with somebody
and they eventually come back to you.
I see this as a state transition problem and almost implemented it that way.
GRID->RPT->ACK
The GRID state is nowhere near 100% accurate as either side could be sitting on
CQ obvious
Under normal conditions that would be true and it is true almost 100% from the
CQ side...butanswering a CQ you can sit on TX 1 waiting for an opening
while somebody else is in a QSO with them.Namely when you respond to a CQ but
they end up working somebody else first.That's why I subbed some
On 07/02/2017 07:52, DI Siegfried Hanisch wrote:
#
Operating system
Mac OS X 10.11.6 but it also happened in earlier versions of Mac OS X
#
Concise description of the problem
after some transmissions, the Audio input and output seems to be
switched from the selected (configured) Audio Devic
Hi All.
I can confirm.
Exactly the same problem on my side.
Only difference being is that I am running via usb directly into a FT-991.
I dont have this issue when running wsjt.
Only on wsjt-x. So can also rule out RF getting into the usb somehow.
Of course any user using the default audio out w
Hi Mike,
On 07/02/2017 04:45, Black Michael wrote:
In that case it could be simplified to just the start of Tx 2 or 3.
CQ/Tx 1 still not being even close in too many circumstances.
Why is Tx 1 not the start of a QSO?
I'd like to see exactly what is being reported as inaccurate and what
they
On 07/02/2017 04:10, ANDY DURBIN wrote:
"I don't see why it should not be that the start time is when the DX call
box gets changed and the end time is when the QSO is logged."
I frequently double click a call of interest so I can track the
station in the Rx frequency pane. It could be hour
Hi
Program version
currently I use WSJT-X v1.7.0 r7405 but it also happened on 1.6 already, so
I do not think this bug was introduced lately
Operating system
Mac OS X 10.11.6 but it also happened in earlier versions of Mac OS X
Concise description of the problem
after some transmissions
Hi
(sorry if this message shows up twice, I just saw that I need to subscriber
first before being able to post)
Program version
currently I use WSJT-X v1.7.0 r7405 but it also happened on 1.6 already, so
I do not think this bug was introduced lately
Operating system
Mac OS X 10.11.6 b
46 matches
Mail list logo
