Re: [wsjt-devel] Pulled back on 73

[Bill Somerville]

On 04/08/2017 02:22, James Shaver (N2ADV) wrote:

I had a FT8 QSO with W7PSK earlier (thanks!) where I was calling CQ, he responded to me, 
we went through the sequence, he sent his 73 and then moved off to call CQ elsewhere on 
the band. Unfortunately, my 73 pulled his TX back to where I was causing him to 
accidentally start calling CQ where he had just answered me. Would it be simple to have 
the TX not be pulled back upon receipt of the 73?  I know he could have unchecked 
"Call 1st" and avoided being pulled back but then if someone had answered him 
after calling CQ, he would have to manually answer.


Hi Jim,

I can reproduce that behaviour if I have him with "Lock Tx=Rx" checked. 
The more use cases I test with auto-sequencing the more I am growing to 
dislike "Lock Tx=Rx".


I will see if I can work out how to stop this sort of thing happening.

73
Bill
G4WJS.


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

[wsjt-devel] Pulled back on 73

[James Shaver (N2ADV)]

I had a FT8 QSO with W7PSK earlier (thanks!) where I was calling CQ, he 
responded to me, we went through the sequence, he sent his 73 and then moved 
off to call CQ elsewhere on the band. Unfortunately, my 73 pulled his TX back 
to where I was causing him to accidentally start calling CQ where he had just 
answered me. Would it be simple to have the TX not be pulled back upon receipt 
of the 73?  I know he could have unchecked "Call 1st" and avoided being pulled 
back but then if someone had answered him after calling CQ, he would have to 
manually answer. 

Just curious. :)

73!
Jim S. 
N2ADV

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

Re: [wsjt-devel] Build error with hamlib3

[Ricky Scott]

thanks greg, thought PY was, but that is my error. On August 3, 2017 at 4:12 PM Greg Beam  wrote:Hi Rick, The short answer is, JTSDK-PY is not the right environment for building Hamlib3. Either JTSDK-QT, or MSYS, but not JTSDK-PY. To keep the WSJT-X Development list clear JTSDK related issue, please use jt...@groups.io for reporting problems. 73’sGreg, KI7MT From: Ricky Scott W7PSK [mailto:w7...@w7psk.net] Sent: Thursday, August 3, 2017 4:57 PMTo: wsjt-devel@lists.sourceforge.netSubject: [wsjt-devel] Build error with hamlib3 Uplgraded JTSDK to 710 by update upgrade in JTSDK Maintenance tried building hamlib 3 with JTSDK-PY with build-hamlib3 received some errors rigctl.exe - system errorThe code execution cannot proceed because libwinpthread-1.dll was not found.  Reinstalling the program may fix this problem Recieved it twice   * Checking Files    rigctl.exe .: OK    rigctld.exe : OK    riglist.h ..: OK    hamlib.pc ..: OK    libhamlib.a : OK * Testing Dummy Rig Control    Set Freq .: 14500    Return Freq . : RIG CONTROL TEST ERROR There was a problem testing Rig Control. Check the build for errors manually and report the problem to the devel-lsit if you cannot resolve the problem.(JTSDK-PY 3.3 ) C:\JTSDK)
 

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

Re: [wsjt-devel] Build error with hamlib3

[Greg Beam]

Hi Rick,

 

The short answer is, JTSDK-PY is not the right environment for building 
Hamlib3. Either JTSDK-QT, or MSYS, but not JTSDK-PY.

 

To keep the WSJT-X Development list clear JTSDK related issue, please use 
jt...@groups.io   for reporting problems.

 

73’s

Greg, KI7MT

 

From: Ricky Scott W7PSK [mailto:w7...@w7psk.net] 
Sent: Thursday, August 3, 2017 4:57 PM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Build error with hamlib3

 

Uplgraded JTSDK to 710 by update upgrade in JTSDK Maintenance

 

tried building hamlib 3 with JTSDK-PY with build-hamlib3

 

received some errors

 

rigctl.exe - system error

The code execution cannot proceed because libwinpthread-1.dll was not found.  
Reinstalling the program may fix this problem

 

Recieved it twice 

 

 * Checking Files
rigctl.exe .: OK
rigctld.exe : OK
riglist.h ..: OK
hamlib.pc ..: OK
libhamlib.a : OK

 * Testing Dummy Rig Control
Set Freq .: 14500
Return Freq . :


 RIG CONTROL TEST ERROR


 There was a problem testing Rig Control.
 Check the build for errors manually and
 report the problem to the devel-lsit if
 you cannot resolve the problem.


(JTSDK-PY 3.3 ) C:\JTSDK)

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

[wsjt-devel] Build error with hamlib3

[Ricky Scott W7PSK]

Uplgraded JTSDK to 710 by update upgrade in JTSDK Maintenance

tried building hamlib 3 with JTSDK-PY with build-hamlib3

received some errors

rigctl.exe - system error
The code execution cannot proceed because libwinpthread-1.dll was not 
found.  Reinstalling the program may fix this problem


Recieved it twice

 * Checking Files
rigctl.exe .: OK
rigctld.exe : OK
riglist.h ..: OK
hamlib.pc ..: OK
libhamlib.a : OK

 * Testing Dummy Rig Control
Set Freq .: 14500
Return Freq . :


 RIG CONTROL TEST ERROR


 There was a problem testing Rig Control.
 Check the build for errors manually and
 report the problem to the devel-lsit if
 you cannot resolve the problem.


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

Re: [wsjt-devel] About qrm

[Richard Bown]

Its not entirely Off limit on this reflector
Its the dev list for weak signal applications.
However, FT8 is being used as a mode of preference, when a QSO could easily be 
completed on SSB or
CW.
How about adding a feature that would put a BIG red screen splash up when 
signals exceed a certain
limit to remind users its for weak signal use, If you want to work trans 
atlantic now you have to
hope its in to a country that has now internet or any means of time syncing; 
transceivers have
microphones as well !
All I see is spots for either 50.276 of 50.313 MHz .
Maybe those in N A dont want to speak to other hams anymore, weak signal modes 
are a useful tool
that can be used when the signals are too weak to use CW or SSB

So A feature request A BIG RED SPLASH SCREEN when signals are big enough to use 
SSB or CW, this is
turning from a very useful tool to an automatic square ( grid ) bagging thing, 
which I dont think
Joe intended it for.


On Thu, 3 Aug 2017 13:47:02 -0700
Jim Brown  wrote:

> On 8/3/2017 12:40 PM, James Shaver (N2ADV) wrote:
> > I was running 10 milliwatts and had an IMD of -35dB.
> >
> > Power is only the tiniest fraction of the equation.
> >  
> Yes, and how much is appropriate depends entirely on the band, the 
> conditions, and what you want to work.
> 
> High power does not, by itself, generate trash. Poorly adjusted rigs, 
> poor quality rigs, use of ALC between an amp and the rig, failure to 
> TUNE the power amp (or running it into an un-matched antenna), running a 
> rig from lower than it's rated DC supply voltage, overdrive in the audio 
> chain between rig and computer, all generate trash.
> 
> AND -- rigs with poor strong signal handling characteristics also 
> generate trash that they send to the computer to decode. Yes, WSJT modes 
> can be used with pretty simple and inexpensive rigs, but better rigs 
> work better on both TX and RX. And often when someone complains of a 
> strong signal being trashy the trash is created in the rig of the ham 
> who's complaining!
> 
> I use WSJT modes only on 6M and 160M, and only for weak signal work. I 
> routinely run 500W on 6M, and anywhere from 5W (to finish QRP WAS on 
> 160M) and 1500W to work DX on 160M.
> 
> BTW -- this entire discussion is out of place on this reflector, which 
> is for WSJT Developers.
> 
> 73, Jim K9YC
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


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

Re: [wsjt-devel] distance in log (Bill Somerville) (Jim Brown)

[ANDY DURBIN]

"Yes, that is common behavior in DXKeeper -- it does the same with QSOs
imported as ADIF from contest loggers like N1MMPlus."


This was discussed in the DXLabs group here:

https://groups.yahoo.com/neo/groups/dxlab/conversations/messages/169659


It was clear that in this case it was JTAlertX, not DXK,  that was "harvesting 
" previous QSO data.


Let's continue the conversation using the DXLabs thread, or on the new HamApps 
group, if any follow up is needed.


73,

Andy k3wyc



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

Re: [wsjt-devel] About qrm

[jarmo]

Thu, 3 Aug 2017 15:40:52 -0400
"James Shaver (N2ADV)"  kirjoitti:


> your reach does not exceed your grasp lest you become an "alligator"
> with more mouth than ears. 

When I got my license, I learned, LISTEN; LISTEN; then LISTEN, before
transmitting.

Yes, I know, how small power can be Strong.. I rather QRP... I mentioned
this, saw two stations from same grid, looked "qrz", stronger had
"possibility" to use power, and he sure did...

But, my suggestion was to make stations beware, NOT to use. I try my
best to find best and ideal combination to work with these fine modes...

CW and SSB dx'ing is, what I rather do, never liked RTTY.. etc, but
this JT/FT I like... As you said, much to do, having better qsos, but
there is always stations, who does not care...

End of this

Jarmo

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

Re: [wsjt-devel] distance in log (Bill Somerville)

[Laurie, VK3AMA]

On 3/08/2017 11:50 PM, ANDY DURBIN wrote:


JTALertX will override the WSJT-X logged grid and use a completely 
different grid from a previous QSO in DXK log.


It's a nasty defect that I hope will be fixed.  Until then I manually 
enter the grid to comment line on all my QSO.


73,

Andy k3wyc



Andy,

Why not try posting your JTAlert observations/concerns on the HamApps 
group where JTAlert support is provided. Posting to other groups except 
the primary support group for JTAlert will not facilitate a timely 
investigation of a perceived defect or its resolution if found to be valid.


de Laurie VK3AMA

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

Re: [wsjt-devel] About qrm

[James Shaver (N2ADV)]

There is a long standing myth that power by itself creates "poor signals" which 
has, unfortunately, created a vast legion of "power cops" who have taken it 
upon themselves to chastise everyone on their waterfall with a strong signal, 
assuming that everyone that is strong or has what appears to be a "bad signal" 
are automatically running "too much power."  

I received an email from one such individual just a few weeks ago chastising me 
for being a "lid running a linear and wrecking the band" along with other 
choice phrases and showing me a screen shot of my JT9 signal at +18dB. 

I was running 10 milliwatts and had an IMD of -35dB. 

Power is only the tiniest fraction of the equation.  

If ops spent more time adjusting their receive settings instead of worrying 
about how much power someone else is running, there would be a lot more happy 
operators out there.  

Remember that the difference between 5 watts and 100 watts is only about 16 dB 
assuming an ideal antenna in free space.  It's actually far less in real world 
applications.  

Don't misunderstand: you should only run as much power needed to make the 
desired contact (I seem to recall that being a question on my Technician Class 
License exam) and if you're calling CQ, make sure your reach does not exceed 
your grasp lest you become an "alligator" with more mouth than ears. 

73,

Jim S. 
N2ADV

> On Aug 3, 2017, at 3:29 PM, jarmo  wrote:
> 
> Seems, that these modes are more and more becoming
> HIGH power modes, what consumes lots of qrm.
> 
> Could there be possibility to add, when someone
> opens WSJTX, first window shows you "FORGET LINEAR"
> and you have to agree, before wsjtx opens.
> 
> That does not help much, but shows those guys
> with linears, that, linear means QRM...
> 
> Seen signals from abt 2000 km, with rprt +17...
> That's not propagation...
> 
> Jarmo
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


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

[wsjt-devel] About qrm

[jarmo]

Seems, that these modes are more and more becoming
HIGH power modes, what consumes lots of qrm.

Could there be possibility to add, when someone
opens WSJTX, first window shows you "FORGET LINEAR"
and you have to agree, before wsjtx opens.

That does not help much, but shows those guys
with linears, that, linear means QRM...

Seen signals from abt 2000 km, with rprt +17...
That's not propagation...

Jarmo

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

Re: [wsjt-devel] distance in log (Bill Somerville)

[Jim Brown]

On 8/3/2017 8:35 AM, ANDY DURBIN wrote:


Please disregard my previous message.  I had not correctly remembered 
the results of my test.  Here is what I reported in the DXLAbs group:



"I ran another test this morning using the same call but with a 
completely different grid. This seems a reasonable simulation of 
someone operating from an alternate QTH.  The grid was logged to DXK 
as I had entered it in WSJT-X.  But, and it's a big but,  the station 
data for entity, state,  country, CQ zone and ITU zone was harvested 
from a previous QSO."




Yes, that is common behavior in DXKeeper -- it does the same with QSOs 
imported as ADIF from contest loggers like N1MMPlus.


BUT -- Dave Bernstein, AA6YQ, DXLabs author is usually quite willing to 
integrate with other freeware applications, and has done so for real 
time data exchange. It's worth bringing him into the conversation. His 
software is free, well supported, and generally bug free. It might be 
worth doing that rather than reinventing the wheel within WSJT-X.


73, Jim K9YC

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

Re: [wsjt-devel] r 7970 : Sked frequency moving

[Charles Suckling]

Hi Bill

 

I've been testing your fix and after  running it for one hour continuously
there were no changes to Sked Frequency.

 

Thanks!

 

73

 

Charlie

 

  _  

From: Charles Suckling [mailto:char...@sucklingfamily.free-online.co.uk] 
Sent: 01 August 2017 08:57
To: 'WSJT software development'
Cc: 'Daniel Gautschi'
Subject: Re: [wsjt-devel] r 7970 : Sked frequency moving

 

Hi Bill

 

I now have set up to have rig control (IC735) operating with WSJT-X, and can
confirm Dan's observations.

 

Recipe:

 

Receiving just band noise.

 

Mode QRA64D, no auto seq.

 

First observation (possibly unrelated to the current issue)  is that with
Doppler tracking set to none (and CFOM, other methods not tested) tuning the
radio dial alters sked frequency. Tool tip and my memory was that this is
only supposed to happen with CTRL key pressed.

 

Increment tests:

 

With TX not enabled, both sked frequencies stay fixed indefinitely (in this
case 225k).

 

With TX enabled, and Doppler tracking set to none,  after 10 cycles of
transmit/receive cycles both sked frequencies did not change.

 

With TX enabled and Doppler tracking set to CFOM the incrementing of sked
frequencies is seen.

 

At end of T period 1 RX sked freq decreased by 30Hz.

At end of R period 1 TX sked freq decreased by 30Hz.

 

At end of T period 2 RX sked freq decreased again by 30Hz.

At end of R period 2 TX sked freq decreased again by 30Hz.

 

At end of T period 3 RX sked freq decreased again by 30Hz.

At end of R period 3 TX sked freq decreased again by 30Hz.

 

At end of T period 4 RX sked freq decreased again by 30Hz.

At end of R period 4 TX sked freq decreased again by 30Hz.

 

The point in the cycle at which  the frequency changes seems to be:  TX sked
frequency changes on the minute change, while RX sked frequency changes at a
variable time between end of decode attempt and the minute change.

 

73

 

Charlie

 

 

 

 

 

  _  

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: 31 July 2017 19:10
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] r 7970 : Sked frequency moving

 

On 31/07/2017 18:53, Charles Suckling wrote:

We were testing r7970  today on 10GHz EME QRA64D.

 

HB9Q (who unlike me routinely runs Doppler correction using rig control from
WSJT-X) noticed a progressive change in sked frequency from period to
period, of the order of 25-30Hz.  This behaviour is has not been seen with
1.8 rc1.  We were using constant freq on moon Doppler.

 

Hi Charlie,

it would be helpful to know what rig is being used, also if the nominal sked
frequency displays in the "Astronomical Data" window are shifting or staying
put.

Is it possible that there is an undisciplined oscillator somewhere and this
is drift, admittedly I can't see any obvious Rx period drift on the
waterfall sample but with 10G Doppler spreading and 64 tones it is hard to
judge. Nice strong signals off the Moon BTW! Perhaps we should be looking at
wide tone spaced FT8 for super quick microwave EME QSOs.

73
Bill
G4WJS.

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

Re: [wsjt-devel] distance in log (Bill Somerville)

[Black Michael via wsjt-devel]

This really belongs on the JTAlert list
Buta lot depends on what online callbooks you have enabled...and what the 
operator has done.  I'd say most don't bother changing QRZ  or HamQTH to update 
their location which would return the correct data if they did bother to 
update.If they just leave it at their default you'll get the wrong data.If you 
don't have any services turned on I do believe JTAlert will use the last known 
data for that call.
I'm not familiar with any logbooks that validate grid against country info.  
Are there any?
And then there's the question of matching for awards on LOTW or eQSL.  I think 
they will use whatever location data is on their account...completely ignoring 
whatever is in anybody's log info so it really doesn't matter what gets put int 
heir for awards.
de Mike W9MDB

  From: ANDY DURBIN 
 To: "wsjt-devel@lists.sourceforge.net"  
 Sent: Thursday, August 3, 2017 10:36 AM
 Subject: Re: [wsjt-devel] distance in log (Bill Somerville)
   
#yiv6886920110 #yiv6886920110 -- P 
{margin-top:0;margin-bottom:0;}#yiv6886920110 Please disregard my previous 
message.  I had not correctly remembered the results of my test.  Here is what 
I reported in the DXLAbs group:
"I ran another test this morning using the same call but with a completely 
different grid.   This seems a reasonable simulation of someone operating from 
an alternate QTH.  The grid was logged to DXK as I had entered it in WSJT-X.  
But, and it's a big but,  the station data for entity, state,  country, CQ zone 
and ITU zone was harvested from a previous QSO."
73,
Andy k3wyc

From: ANDY DURBIN 
Sent: Thursday, August 3, 2017 6:50 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: distance in log (Bill Somerville) "  Do you have a logging 
application that does not accept grid squares?"
JTALertX will override the WSJT-X logged grid and use a completely different 
grid from a previous QSO in DXK log.
It's a nasty defect that I hope will be fixed.  Until then I manually enter the 
grid to comment line on all my QSO.
73,Andy k3wyc

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


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

Re: [wsjt-devel] distance in log (Bill Somerville)

[ANDY DURBIN]

Please disregard my previous message.  I had not correctly remembered the 
results of my test.  Here is what I reported in the DXLAbs group:


"I ran another test this morning using the same call but with a completely 
different grid.   This seems a reasonable simulation of someone operating from 
an alternate QTH.  The grid was logged to DXK as I had entered it in WSJT-X.  
But, and it's a big but,  the station data for entity, state,  country, CQ zone 
and ITU zone was harvested from a previous QSO."


73,

Andy k3wyc



From: ANDY DURBIN 
Sent: Thursday, August 3, 2017 6:50 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: distance in log (Bill Somerville)


"  Do you have a logging application that does not accept grid squares?"


JTALertX will override the WSJT-X logged grid and use a completely different 
grid from a previous QSO in DXK log.


It's a nasty defect that I hope will be fixed.  Until then I manually enter the 
grid to comment line on all my QSO.


73,

Andy k3wyc


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

Re: [wsjt-devel] distance in log (Bill Somerville)

[ANDY DURBIN]

"  Do you have a logging application that does not accept grid squares?"


JTALertX will override the WSJT-X logged grid and use a completely different 
grid from a previous QSO in DXK log.


It's a nasty defect that I hope will be fixed.  Until then I manually enter the 
grid to comment line on all my QSO.


73,

Andy k3wyc


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

Re: [wsjt-devel] distance in log

[Bill Somerville]

On 03/08/2017 14:35, Wolfgang wrote:

Hello Bill,

thanks for your fast reply!

Thursday, August 3, 2017, 3:24:16 PM, you wrote:

*> understood but the distance shown is always derived from the grid
> information, there is no way to override it.

*Do not want to override it.

Since the distance is written on the screen and the value beeing 
somewhere

in the code, my wish was, to append that number plus 'km' or 'mi' to the
comment field of the log. Right now, I type it myself at the end of a 
QSO...


73 de Wolfgang
OE1MWW


Hi Wolfgang,

this sounds like an opportunity for a simple application that converts 
ADIF records plus a home grid square into lines as map coordinates. Then 
QSOs could be plotted on a map. I suspect such an application already 
exists, maybe something in the Google Earth API perhaps.


73
Bill
G4WJS.

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

Re: [wsjt-devel] distance in log

[Jordan Sherer]

> Right now, I type it myself at the end of the QSO...

I do the same thing. If I forget, I have to pull up the log, compute the 
distances based on the grid, and update it manually. Having it as an option to 
automatically add this to the content would be nice.

Best,
Jordan
KN4CRD

On Aug 3, 2017, 9:36 AM -0400, Wolfgang , wrote:
> Hello Bill,
>
> thanks for your fast reply!
>
> Thursday, August 3, 2017, 3:24:16 PM, you wrote:
>
> > understood but the distance shown is always derived from the grid
> > information, there is no way to override it.
>
> Do not want to override it.
>
> Since the distance is written on the screen and the value beeing somewhere
> in the code, my wish was, to append that number plus 'km' or 'mi' to the
> comment field of the log. Right now, I type it myself at the end of a QSO...
>
> 73 de Wolfgang
> OE1MWW
>
> --
> Amateur radio is the most expensive type of free-of-charge communication!
> Amateurfunk ist die teuerste Art der kostenlosen Kommunikation!
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] distance in log

[Wolfgang]

Title: Re: [wsjt-devel] distance in log


Hello Bill,

thanks for your fast reply! 

Thursday, August 3, 2017, 3:24:16 PM, you wrote:

> understood but the distance shown is always derived from the grid 
> information, there is no way to override it.

Do not want to override it.

Since the distance is written on the screen and the value beeing somewhere 
in the code, my wish was, to append that number plus 'km' or 'mi' to the 
comment field of the log. Right now, I type it myself at the end of a QSO...

73 de Wolfgang
OE1MWW

--
Amateur radio is the most expensive type of free-of-charge communication!
Amateurfunk ist die teuerste Art der kostenlosen Kommunikation!


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

Re: [wsjt-devel] WSJT-X: review of message reply and sequencing logic

[Steve Huston]

On Mon, Jul 24, 2017 at 3:35 PM, Bill Somerville  wrote:
> I want this change to go into WSJT-X v1.8.0 RC2
> but I am aware that it is an awfully large change to drop in at this late
> stage, nevertheless I feel it fixes more critical issues than it introduces.
> Currently it is only in the development branch but I urge those brave enough
> to build the development branch to try it and report back. You should note
> that the development branch also contains FT8 decoder changes that are not
> yet finalized and may mis-behave so beware. The FT8 decoder changes are
> reasonably stable at present but watch the change log for comments about
> usability on air please.

GM Bill,

Is there any news on the possibility of merging this into the RC
branch?  Since that branch's creation I've been reluctant to build
from devel when I saw a few changes here and there that would break
on-air usage, but I would be interested in testing these and some of
the other recent fixes that haven't been merged yet.  If the timeline
is short, I'll wait, but if it's still in the air I'll switch back to
devel to aid in testing and watch the 'svn log' output a lot more
closely :D

-- 
Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
  Princeton University  |ICBM Address: 40.346344   -74.652242
345 Lewis Library   |"On my ship, the Rocinante, wheeling through
  Princeton, NJ   08544 | the galaxies; headed for the heart of Cygnus,
(267) 793-0852  | headlong into mystery."  -Rush, 'Cygnus X-1'

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

Re: [wsjt-devel] distance in log

[Bill Somerville]

On 03/08/2017 14:20, Wolfgang wrote:

The distance is on the screen during logging, but not in the log.


Hi Wolfgang,

understood but the distance shown is always derived from the grid 
information, there is no way to override it.


73
Bill
G4WJS.


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

Re: [wsjt-devel] distance in log

[Wolfgang]

Hello Bill,

Thursday, August 3, 2017, 3:09:15 PM, you wrote:

> Do you have a logging application that does not accept grid squares?

oh yes, the wsjt_log.adi has the grid squares and the db in the comment.
Think I have a software to calculate the distance by reading out each
and every log entry by hand, entering the home and the remote location.
Maybe, I could write some code that runs over the .adi to do that.

It's just that our playground is wide. Some people enjoy EME, some
IOTA, others SOTA, DXCC, you name it - or some of them like to see the
distance in the log.

The distance is on the screen during logging, but not in the log.

:-)

73 de Wolfgang
OE1MWW

--
Amateur radio is the most expensive type of free-of-charge communication!
Amateurfunk ist die teuerste Art der kostenlosen Kommunikation!


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

Re: [wsjt-devel] distance in log

[Bill Somerville]

On 03/08/2017 13:30, Wolfgang wrote:

Hi all,

we do have 'db reports to comments' in the 'Reporting' tab.

Is there a chance please, to append the distance into that comment 
field too ?



73 de Wolfgang
OE1MWW


HI Wolfgang,

the "dB reports to comments" option is provided for those who have 
logging software that only accept 59/599 style reports. I'm not sure 
what value adding the distance information to the comments adds, after 
all it is derived from the received or entered grid square which itself 
is in the log record so can always be used to calculate the estimated 
distance. Do you have a logging application that does not accept grid 
squares?


73
Bill
G4WJS.

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

Re: [wsjt-devel] distance in log

[Wolfgang]

Title: Re: [wsjt-devel] distance in log 


Hi all,

we do have 'db reports to comments' in the 'Reporting' tab.

Is there a chance please, to append the distance into that comment field too ?


73 de Wolfgang
OE1MWW

--
Amateur radio is the most expensive type of free-of-charge communication!
Amateurfunk ist die teuerste Art der kostenlosen Kommunikation!


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