Re: [wsjt-devel] Pulled back on 73

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

[wsjt-devel] Pulled back on 73

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

Re: [wsjt-devel] Build error with hamlib3

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

Re: [wsjt-devel] Build error with hamlib3

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

[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

Re: [wsjt-devel] About qrm

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

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

"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,

Re: [wsjt-devel] About qrm

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

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

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

Re: [wsjt-devel] About qrm

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

[wsjt-devel] About qrm

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

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

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

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

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

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

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

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

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

Re: [wsjt-devel] 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

Re: [wsjt-devel] distance in log

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

Re: [wsjt-devel] distance in log

> 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,

Re: [wsjt-devel] distance in log

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

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

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

Re: [wsjt-devel] distance in log

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.

Re: [wsjt-devel] distance in log

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

Re: [wsjt-devel] distance in log

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

Re: [wsjt-devel] distance in log

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