Date   

locked Re: Operating portable #WSJTX_config #FT8

Jim Brown
 

On 7/19/2021 2:33 PM, Marion D. Kitchens wrote:
Do the rules part 97 PROHIBIT using suffix?
No. But for the reasons Bill cited, doing so is a bad idea.

73, Jim K9YC


locked Re: Operating portable #WSJTX_config #FT8

Marion D. Kitchens
 


Do the rules part 97 PROHIBIT using suffix?  I kinda like seeing those suffizs because it offers addition information.
 
Just my 2 cents worth....
 
Marion,    K4GOK
 
On Mon, 19 Jul 2021 14:05:09 -0700 "Karl Beckman" <wa8nvw@...> writes:

This has been well covered recently in this forum, almost to the point of becoming annoying.  Please take note and pass the word to your ham friends. 
1)  FCC RULES PART 97 DOES NOT REQUIRE OR EVEN MENTION THE IDEA OF MODIFYING YOUR ISSUED OPERATOR CALL SIGN WITH A /P, /M, OR /R SUFFIX.  It has been over 45 years since that ID method and the single licensed station location concept was abandoned by the FCC,
2)  Well meaning amateur "Elmers", PLEASE STOP teaching new hams those archaic cancelled ID rules which do not exist in Part 97. They are incompatible with the advanced digital QSO technologies available to us.  The ITU defines a reversed format for amateur DX operation outside the licensee's country which uses the host country's assigned prefix. 
3)  When operating WSJTx modes you enter your issued callsign (maximum 6 characters) and your grid square. Nothing else will fit into the highly compressed data protocols of these weak signal modes and be readable by your QSO partner at the other end.  Meanwhile, ARRL and others offering virtual QSL services have added multiple location capability into their packages, specifically to accomodate amateur operators with more than one station equipment location. 
- -

Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io
 


locked Re: WSJT-x signal processing versus RTTY decoding in Fldigi? #decode

Bill Somerville
 

On 19/07/2021 19:26, Bruce KX4AZ wrote:
I have always been in awe over the signal processing and error correction techniques used in the assorted WSJT-x modes....and my curiosity compels me to ask...

I wonder if any of these techniques could be applied with other modes like RTTY in programs like Fldigi.  Of course, RTTY has no error correction by design, but what about the other "tricks" used by WSJT-x for weak signal decoding?  Or do programs like Fldigi already have the latest and greatest decoding algorithms built in for weaker RTTY signals?

If this query doesn't belong in this forum, would appreciate a "re-direct" sent my way.
Hi Bruce,

simple answer, if you want weak signal efficiency then don't start with something like BAUDOT using FSK at 45.5 baud.

Of course authors of soundcard RTTY decoders have explored and implemented all sorts of smart filtering and other DSP techniques to get the best decoding performance they could. There is probably very little leeway for much better performance without changing the protocol in some way.

73
Bill
G4WJS.


locked Re: Operating portable #WSJTX_config #FT8

Bill Somerville
 

On 19/07/2021 22:05, Karl Beckman wrote:
This has been well covered recently in this forum, almost to the point of becoming annoying.  Please take note and pass the word to your ham friends. 
1)  FCC RULES PART 97 DOES NOT REQUIRE OR EVEN MENTION THE IDEA OF MODIFYING YOUR ISSUED OPERATOR CALL SIGN WITH A /P, /M, OR /R SUFFIX.  It has been over 45 years since that ID method and the single licensed station location concept was abandoned by the FCC,
2)  Well meaning amateur "Elmers", PLEASE STOP teaching new hams those archaic cancelled ID rules which do not exist in Part 97. They are incompatible with the advanced digital QSO technologies available to us.  The ITU defines a reversed format for amateur DX operation outside the licensee's country which uses the host country's assigned prefix. 
3)  When operating WSJTx modes you enter your issued callsign (maximum 6 characters) and your grid square. Nothing else will fit into the highly compressed data protocols of these weak signal modes and be readable by your QSO partner at the other end.  Meanwhile, ARRL and others offering virtual QSL services have added multiple location capability into their packages, specifically to accomodate amateur operators with more than one station equipment location. 
- -

Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io

Karl,

modes like FT8, FT4, MSK144, Q65, and FST4, which all share the same basic source encoding rules, have a great deal of flexibility for nonstandard callsigns (by non-standard I mean in terms of these modes definition of a standard callsign which is more complex than "maximum of 6 characters"). If a nonstandard callsign is used with these modes then there are restrictions on what other information can be passed in standard format messages. The main restriction is that gridsquares cannot be conveyed in CQ or QRZ messages, another secondary but important restriction is that two stations with such nonstandard callsigns cannot easily work each other, yet another is that the special contest modes do not support nonstandard callsigns.

73
Bill
G4WJS.


locked Re: Operating portable #WSJTX_config #FT8

Karl Beckman WA8NVW - NNV5BH
 

This has been well covered recently in this forum, almost to the point of becoming annoying.  Please take note and pass the word to your ham friends. 
1)  FCC RULES PART 97 DOES NOT REQUIRE OR EVEN MENTION THE IDEA OF MODIFYING YOUR ISSUED OPERATOR CALL SIGN WITH A /P, /M, OR /R SUFFIX.  It has been over 45 years since that ID method and the single licensed station location concept was abandoned by the FCC,
2)  Well meaning amateur "Elmers", PLEASE STOP teaching new hams those archaic cancelled ID rules which do not exist in Part 97. They are incompatible with the advanced digital QSO technologies available to us.  The ITU defines a reversed format for amateur DX operation outside the licensee's country which uses the host country's assigned prefix. 
3)  When operating WSJTx modes you enter your issued callsign (maximum 6 characters) and your grid square. Nothing else will fit into the highly compressed data protocols of these weak signal modes and be readable by your QSO partner at the other end.  Meanwhile, ARRL and others offering virtual QSL services have added multiple location capability into their packages, specifically to accomodate amateur operators with more than one station equipment location. 
- -

Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io


locked Re: Clock Sync #Timesync

Alan <n5pa@...>
 

Joe:

I am completely agree with you!  And in my unscientific means, it works well enough to keep your time for WSJT-X working. It may not be as accurate as a yottasecond (Ys or 10 to the 24th), but it is accurate enough to work with WSJT-X, and as that is all that matters!

73,
Alan Clark, N5PA
Ellisville, MS
Email:  n5pa@...
URL:  http://www.n5pa.com

On Jul 19, 2021, at 11:55 AM, Joe <joe@...> wrote:

Hi Jim,

"If one assumes the velocity factor of a USB cable is about 80%, that means about 250 microseconds of propagation delay per meter."

Let's see...  the speed of light is 3 x 10^8 m/s, so the delay in a 1 meter cable is 1.0/(0.8x3x10^8) = 4.2 x 10^-9.  I make it around 4 nanoseconds, not 250 microseconds.  But you're certainly right, the cable delay is well under a millisecond.  :-)

  -- 73, Joe, K1JT



locked WSJT-x signal processing versus RTTY decoding in Fldigi? #decode

Bruce KX4AZ
 

I have always been in awe over the signal processing and error correction techniques used in the assorted WSJT-x modes....and my curiosity compels me to ask...

I wonder if any of these techniques could be applied with other modes like RTTY in programs like Fldigi.  Of course, RTTY has no error correction by design, but what about the other "tricks" used by WSJT-x for weak signal decoding?  Or do programs like Fldigi already have the latest and greatest decoding algorithms built in for weaker RTTY signals?

If this query doesn't belong in this forum, would appreciate a "re-direct" sent my way.


locked Re: Clock Sync #Timesync

Jim Pennino
 

Yeah, sometimes there is a disconnect between the brain and the fingers...

What it should have said is the propagation VELOCITY is about 250 meters per microsecond or 4 nanoseconds per meter.

For those interested, the device I ordered is: https://www.ebay.com/itm/174136333219

Note that one needs to specify which GNSS system(s) (max of two) you want to use. As I am in the US, I chose GPS+GLONASS.

Re the Adafruit GPS HAT: I recently upgraded my old GPS HAT to the current GNSS HAT. It is too soon to have precise numbers, but it appears that the accuracy of this HAT, to a 95% confidence level, is a bit under 200 microseconds.

Jim WB6DKH


locked Re: #FT8 How to restore grid to 'needed' status for alerts #FT8

Pietro Molina
 

It's a simple text file (XML formatted), so notepad is good to edit.
My suggest is to use notepad+ with XML plugin, It helps to show a friendly view.

Pietro

Pietro (mobile)


Il lun 19 lug 2021, 15:45 Bob Wolters <bobw5xc@...> ha scritto:

I have not tried to edit an .ADI file, can someone tell me what additional software to use to edit one ?

 

Thanks again,

 

Bob                    W5XC

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Pietro Molina
Sent: Monday, July 19, 2021 6:42 AM
To: main@wsjtx.groups.io
Subject: Re: [WSJTX] #FT8 How to restore grid to 'needed' status for alerts

 

Well, the solution by Reino is more elegant.. you won't loose the qso, but only restore the grid as unworked.

 

73

 

I2OIM

Pietro (via Tablet)

 

Il lun 19 lug 2021, 13:10 Reino Talarmo <reino.talarmo@...> ha scritto:

Bob, look at that call in the wsjtx_log.adi file and delete it.

Pietro I2OIM

Hi,

There are two more sensible or logical solutions as well.

If the actual grid is known, replace the current by it, otherwise change gridsquare length to “0” and delete the current one.
In Both solutions the grid is “not worked” on the WSJT-X point of view. Well, a Rescan or WSJT-X closing and opening is needed to update PC knowledge.

73, Reino OH3mA



 

Virus-free. www.avg.com

 





locked Re: Clock Sync #Timesync

Joe
 

Hi Jim,

"If one assumes the velocity factor of a USB cable is about 80%, that means about 250 microseconds of propagation delay per meter."

Let's see...  the speed of light is 3 x 10^8 m/s, so the delay in a 1 meter cable is 1.0/(0.8x3x10^8) = 4.2 x 10^-9.  I make it around 4 nanoseconds, not 250 microseconds.  But you're certainly right, the cable delay is well under a millisecond.  :-)

  -- 73, Joe, K1JT


locked Re: Clock Sync #Timesync

 

Thanks Jim.  As I suspected, there was much I didn’t understand.  One good point is that the new USB3 cable is much better quality than the old one.

 

As part of my military service I was a calibration team chief.  Our time/frequency reference was via a VLF time signal supplied by NBS and broadcast courtesy of the Navy.  That was 1975 time frame.  How far have we come.

 

I will remove the older GPS puck.  It has been concerning me anyway. 

 

I am in the middle of a rebuilding a Raspberry Pi 2 and I have the Adafruit GPS hat.  If I can get that working, I will discontinue using the pucks.  Prices do change and the Adafruit hat ran $62 with shipping, but it will be an interesting project.  Thankfully there is an abundance of help from those who have already accomplished this project to guide me.

 

__________

Dan – K4SHQ

CFI/II

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Jim Pennino via groups.io
Sent: Monday, July 19, 2021 10:55 AM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Clock Sync #Timesync

 

In my testing I have tried various combinations of multiple receivers and I do NOT recommend attaching more than one reference clock, i.e. a GPS, to a machine.

NTP will work with more than one, but I have seen some strange things happen when both devices are of equal quality.

For devices of equal quality, it appears to take ntp longer to decide which one to select and occasionally marks both as false tickers. I am guessing that is because the developers of ntp never envisioned someone could actually afford having more than one high quality source and the selection algorithms are having difficulty deciding between them.

For devices of unequal quality, ntp will quickly pick the better device and the second device from then on serves no purpose, e.g. with a USB GPS and a PPS serial GPS, ntp quickly selects the PPS serial GPS.

I suggest moving one GPS to another machine or just keep it as back up in the remote case of failure.

As for delay times, the actual delay will depend on ALL the hardware involved. My value of 30 milliseconds is a rough average for all the systems I've tested and is just a starting point. Of all the devices I've tested, the VK-162 showed the least delay and the device with the largest delay was about 750 milliseconds, so yes, the delay can be quite large. If the delay pushes 1,000 milliseconds or goes over that (I have seen one that did which got binned), I would not trust the device for time keeping and use something else. Your numbers look reasonable to me.

A couple of other miscellaneous notes while I'm at it:

If one assumes the velocity factor of a USB cable is about 80%, that means about 250 microseconds of propagation delay per meter. As delay times are in the milliseconds, then a 4 meter USB extension cable should add about 1 millisecond of delay, which is down in the noise level of the jitter. Some quick testing of extension cables shows this to be true. I would, however, only use shielded cables in a RF environment least the cables become antennas.

During my career I often worked with clients that had a real need for accurate time and it was not unusual for a client to spend tens of thousands of dollars in today's money on hardware plus my fees to achieve this. In my retirement I became interested in how far the state of the art has progressed and wondered about the quality of time keeping hardware available for the arbitrary limit of $50 as well as what useful things can be done with a Raspberry Pi, thus all this testing.

I decided to up the game and have ordered a GNSS disciplined OCXO oscillator. While the oven controlled oscillator just guarantees an accuracy of a few nanoseconds, at $180 it is about $600 cheaper than a rubidium oscillator and there are limits to retirement hobby spending. As a bonus this will provide a 10 MHz reference that is +/- 0.0002 Hz for my frequency counter, or anything else with an external reference input.

If anyone is interested in either/or high accuracy time keeping or frequency measurement, I can write up the results after I have done testing of this device.

Jim WB6DKH


locked Re: Clock Sync #Timesync

Robert Lorenzini
 

Which GPSDO did you settle on Jim? I have a BG9 clone and a Bodnar. The BG9 osc has drifted
beyond where it can be corrected but I'm still using the NMEA for position only.

Bob - wd6dod

On 7/19/2021 8:55 AM, Jim Pennino via groups.io wrote:

In my testing I have tried various combinations of multiple receivers and I do NOT recommend attaching more than one reference clock, i.e. a GPS, to a machine.

NTP will work with more than one, but I have seen some strange things happen when both devices are of equal quality.

For devices of equal quality, it appears to take ntp longer to decide which one to select and occasionally marks both as false tickers. I am guessing that is because the developers of ntp never envisioned someone could actually afford having more than one high quality source and the selection algorithms are having difficulty deciding between them.

For devices of unequal quality, ntp will quickly pick the better device and the second device from then on serves no purpose, e.g. with a USB GPS and a PPS serial GPS, ntp quickly selects the PPS serial GPS.

I suggest moving one GPS to another machine or just keep it as back up in the remote case of failure.

As for delay times, the actual delay will depend on ALL the hardware involved. My value of 30 milliseconds is a rough average for all the systems I've tested and is just a starting point. Of all the devices I've tested, the VK-162 showed the least delay and the device with the largest delay was about 750 milliseconds, so yes, the delay can be quite large. If the delay pushes 1,000 milliseconds or goes over that (I have seen one that did which got binned), I would not trust the device for time keeping and use something else. Your numbers look reasonable to me.

A couple of other miscellaneous notes while I'm at it:

If one assumes the velocity factor of a USB cable is about 80%, that means about 250 microseconds of propagation delay per meter. As delay times are in the milliseconds, then a 4 meter USB extension cable should add about 1 millisecond of delay, which is down in the noise level of the jitter. Some quick testing of extension cables shows this to be true. I would, however, only use shielded cables in a RF environment least the cables become antennas.

During my career I often worked with clients that had a real need for accurate time and it was not unusual for a client to spend tens of thousands of dollars in today's money on hardware plus my fees to achieve this. In my retirement I became interested in how far the state of the art has progressed and wondered about the quality of time keeping hardware available for the arbitrary limit of $50 as well as what useful things can be done with a Raspberry Pi, thus all this testing.

I decided to up the game and have ordered a GNSS disciplined OCXO oscillator. While the oven controlled oscillator just guarantees an accuracy of a few nanoseconds, at $180 it is about $600 cheaper than a rubidium oscillator and there are limits to retirement hobby spending. As a bonus this will provide a 10 MHz reference that is +/- 0.0002 Hz for my frequency counter, or anything else with an external reference input.

If anyone is interested in either/or high accuracy time keeping or frequency measurement, I can write up the results after I have done testing of this device.

Jim WB6DKH




locked Re: Clock Sync #Timesync

Jim Pennino
 

In my testing I have tried various combinations of multiple receivers and I do NOT recommend attaching more than one reference clock, i.e. a GPS, to a machine.

NTP will work with more than one, but I have seen some strange things happen when both devices are of equal quality.

For devices of equal quality, it appears to take ntp longer to decide which one to select and occasionally marks both as false tickers. I am guessing that is because the developers of ntp never envisioned someone could actually afford having more than one high quality source and the selection algorithms are having difficulty deciding between them.

For devices of unequal quality, ntp will quickly pick the better device and the second device from then on serves no purpose, e.g. with a USB GPS and a PPS serial GPS, ntp quickly selects the PPS serial GPS.

I suggest moving one GPS to another machine or just keep it as back up in the remote case of failure.

As for delay times, the actual delay will depend on ALL the hardware involved. My value of 30 milliseconds is a rough average for all the systems I've tested and is just a starting point. Of all the devices I've tested, the VK-162 showed the least delay and the device with the largest delay was about 750 milliseconds, so yes, the delay can be quite large. If the delay pushes 1,000 milliseconds or goes over that (I have seen one that did which got binned), I would not trust the device for time keeping and use something else. Your numbers look reasonable to me.

A couple of other miscellaneous notes while I'm at it:

If one assumes the velocity factor of a USB cable is about 80%, that means about 250 microseconds of propagation delay per meter. As delay times are in the milliseconds, then a 4 meter USB extension cable should add about 1 millisecond of delay, which is down in the noise level of the jitter. Some quick testing of extension cables shows this to be true. I would, however, only use shielded cables in a RF environment least the cables become antennas.

During my career I often worked with clients that had a real need for accurate time and it was not unusual for a client to spend tens of thousands of dollars in today's money on hardware plus my fees to achieve this. In my retirement I became interested in how far the state of the art has progressed and wondered about the quality of time keeping hardware available for the arbitrary limit of $50 as well as what useful things can be done with a Raspberry Pi, thus all this testing.

I decided to up the game and have ordered a GNSS disciplined OCXO oscillator. While the oven controlled oscillator just guarantees an accuracy of a few nanoseconds, at $180 it is about $600 cheaper than a rubidium oscillator and there are limits to retirement hobby spending. As a bonus this will provide a 10 MHz reference that is +/- 0.0002 Hz for my frequency counter, or anything else with an external reference input.

If anyone is interested in either/or high accuracy time keeping or frequency measurement, I can write up the results after I have done testing of this device.

Jim WB6DKH


locked Re: Contest mode? #ContestMode

George J Molnar, KF2T
 

One enhancement that might help in this situation is to build a call queue that allows multiple callers to be stacked and worked either sequentially or from a pick list by the operator. The progress of each contact could be maintained so that in QSB or scatter situations, contacts could “interleave” a little bit to improve rate.  Rare grid rovers, expeditions, and other popular stations could benefit. 


Having a blast on the radio. Thanks to all!

George/KF2T


locked Re: #WSJTX_config - Rigblaster HRD WSJTX No Audio Device Configured #WSJTX_config

Bill Somerville
 

On 19/07/2021 15:51, Paul St John wrote:
I am using a Lenovo Core i3 10 Gen running HRD and WSJT-X to a Rigblaster Advanced and a KX3. It works perfectly with an old HP Laptop.  However, using the same settings on my Lenovo Laptop the HRD CAD seems to work and I can start WSJT-X. However, I see no sound coming into the program from the KX3. There are no decodes and when I hit tune, I get the error message “No audio output device configured.” The only difference in settings between the two laptops - that I can see - is that the HP Laptop connects through COM 13, whereas the Lenovo is using COM4.  I have used the Rigblaster software on the Lenovo to create a COM 13 and then used HRD to find it, but that hasn’t helped.  I checked the Rigblaster function using the General Tab on both the Microphone and the Speakers tab in the Control Panel. Both reported the Location as RIGblaster Advantage Audio, and under Device Status said, “This device is working properly.” Yet it doesn’t work on the Lenovo.   I got normal output into the Lenovo’s speakers when I brought up a Youtube video, so I think the Lenovo soundcard is working ok. Any suggestions would be greatly appreciated.

Tnx, Paul, N6DNM
Paul,

you need to set up the audio input and output for WSJT-X in "Settings->Audio". If you are on Windows 10 then you may need to allow WSJT-X to use microphone devices in teh Camera and Microphone Privacy settings of Windows.

73
Bill
G4WJS.


locked #WSJTX_config - Rigblaster HRD WSJTX No Audio Device Configured #WSJTX_config

Paul St John
 

I am using a Lenovo Core i3 10 Gen running HRD and WSJT-X to a Rigblaster Advanced and a KX3. It works perfectly with an old HP Laptop.  However, using the same settings on my Lenovo Laptop the HRD CAD seems to work and I can start WSJT-X. However, I see no sound coming into the program from the KX3. There are no decodes and when I hit tune, I get the error message “No audio output device configured.” The only difference in settings between the two laptops - that I can see - is that the HP Laptop connects through COM 13, whereas the Lenovo is using COM4.  I have used the Rigblaster software on the Lenovo to create a COM 13 and then used HRD to find it, but that hasn’t helped.  I checked the Rigblaster function using the General Tab on both the Microphone and the Speakers tab in the Control Panel. Both reported the Location as RIGblaster Advantage Audio, and under Device Status said, “This device is working properly.” Yet it doesn’t work on the Lenovo.   I got normal output into the Lenovo’s speakers when I brought up a Youtube video, so I think the Lenovo soundcard is working ok. Any suggestions would be greatly appreciated.

Tnx, Paul, N6DNM

--
Paul St. John, N6DN


locked Re: #Transmit #K4 - Split Operation -> DATA-R Mode on Elecraft K4 #transmit #Elecraft

Rick Tavan
 

Yes, on W9MDB's recommendation I tried V. 2.5.0 and it fixed the problem. "Split Operation | Rig" works fine on K4 now. Thanks!

/Rick N6XI

On Mon, Jul 19, 2021 at 2:52 AM Bill Somerville <g4wjs@...> wrote:
On 19/07/2021 02:38, Rick Tavan wrote:
> I'm running WSJT-X 2.4.0 on a Dell XPS-13 laptop, running Windows 10
> Home 19.09 connected to an Elecraft K4 in DATA mode. Settings | Radio
> | Split Operation = Rig in order to position the transmit tone in the
> passband. I believe SPLIT was working a few WSJT-X releases ago. Now,
> when I double-click a CQ in the left-hand window, it puts the K4 VFO B
> into DATA-R mode ("reverse") and the K4 complains on its screen that
> that type of split mode isn't allowed. I suppose it also returns an
> error to WSJT-X because it then refrains from using SPLIT mode.
> Instead, it transmits on VFO A which remains at the bottom of the
> band. I'm pretty sure this was introduced in a recent release of
> WSJT-X. Any thoughts?
>
> Thanks & 73,
>
> /Rick N6XI

Hi Rick,

give WSJT-X V2.5.0 RC3 a try and let us know how it goes please?

73
Bill
G4WJS.






--
--

Rick Tavan
Truckee and Saratoga, CA


locked Re: #FT8 How to restore grid to 'needed' status for alerts #FT8

Brad, K8ZM
 

These are just text files so any text editor will work, notepad works fine.

73, Brad N8GLS

Sent from my Samsung Galaxy S10 "not so" Smartphone


-------- Original message --------
From: Bob Wolters <bobw5xc@...>
Date: 7/19/21 9:45 AM (GMT-05:00)
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] #FT8 How to restore grid to 'needed' status for alerts

I have not tried to edit an .ADI file, can someone tell me what additional software to use to edit one ?

 

Thanks again,

 

Bob                    W5XC

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Pietro Molina
Sent: Monday, July 19, 2021 6:42 AM
To: main@wsjtx.groups.io
Subject: Re: [WSJTX] #FT8 How to restore grid to 'needed' status for alerts

 

Well, the solution by Reino is more elegant.. you won't loose the qso, but only restore the grid as unworked.

 

73

 

I2OIM

Pietro (via Tablet)

 

Il lun 19 lug 2021, 13:10 Reino Talarmo <reino.talarmo@...> ha scritto:

Bob, look at that call in the wsjtx_log.adi file and delete it.

Pietro I2OIM

Hi,

There are two more sensible or logical solutions as well.

If the actual grid is known, replace the current by it, otherwise change gridsquare length to “0” and delete the current one.
In Both solutions the grid is “not worked” on the WSJT-X point of view. Well, a Rescan or WSJT-X closing and opening is needed to update PC knowledge.

73, Reino OH3mA



 

Virus-free. www.avg.com

 


locked Re: #BugReport #logging Failure to log contact correctly #IssueReport #logging

 

Bill,

I tried that previously, but because of the use I make of these fields in the status UDP, I want them cleared after logging. I use them to display current contact location in DxAtlas. I'll try and see if I can log then start the new contact. failing that, log as soon as I send the RR73 as Jim K9YC's suggestion.

--
73 Phil GM3ZZA


locked Re: #FT8 How to restore grid to 'needed' status for alerts #FT8

Bob Wolters <bobw5xc@...>
 

I have not tried to edit an .ADI file, can someone tell me what additional software to use to edit one ?

 

Thanks again,

 

Bob                    W5XC

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Pietro Molina
Sent: Monday, July 19, 2021 6:42 AM
To: main@wsjtx.groups.io
Subject: Re: [WSJTX] #FT8 How to restore grid to 'needed' status for alerts

 

Well, the solution by Reino is more elegant.. you won't loose the qso, but only restore the grid as unworked.

 

73

 

I2OIM

Pietro (via Tablet)

 

Il lun 19 lug 2021, 13:10 Reino Talarmo <reino.talarmo@...> ha scritto:

Bob, look at that call in the wsjtx_log.adi file and delete it.

Pietro I2OIM

Hi,

There are two more sensible or logical solutions as well.

If the actual grid is known, replace the current by it, otherwise change gridsquare length to “0” and delete the current one.
In Both solutions the grid is “not worked” on the WSJT-X point of view. Well, a Rescan or WSJT-X closing and opening is needed to update PC knowledge.

73, Reino OH3mA



 

Virus-free. www.avg.com

 

13101 - 13120 of 39791