Date   

locked Re: Puzzling QSO endings #QSO_practices

 

Thanks all for replying. It seems as if my practices are consistent with mainstream thoughts on QSO's end and courtesy. I'd like to have a 73, but I don't require it. Every logged QSO is sent to both eQSL and LoTW. I seldom get an eQSL from anyone saying the I am not in their log. When I check my eQSL listings, I see a handful of QSO's that I can't confirm in either my log or in WSJT's ALL.TXT. I keep several years' worth of ALL.TXT to use with a search facility I've written in PHP.

__________
Dan – K4SHQ
CFI/II

-----Original Message-----
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Lawrence Godek
Sent: Friday, May 13, 2022 8:16 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Puzzling QSO endings #QSO_practices

I do the same.


On 5/13/2022 10:03 AM, chas cartmel wrote:
Just for information I always send a '73' or a 'RR73" to a contacted station when signal reports are exchanged and acknowledged.
For me it is operating 'manners' rather than a necessity.

The QSO is logged automatically but I mark it as no '73' and tend not
to QSL these stations unless there is QSB and signal weak . It's only 30 seconds after all.
I also do not work stations responding to my CQ with a signal report rather than a grid square. Again 30 seconds of effort.


73 Charlie
G4EST
www.g4est.me.uk
Stay safe out there



-----Original Message-----
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Dan
Malcolm
Sent: Friday, May 13, 2022 1:43 PM
To: main@WSJTX.groups.io
Subject: [WSJTX] Puzzling QSO endings #QSO_practices

I've observed this operating practice for some time now and not such a big deal. FT8 QSO should, but don't have to, end with 73's being exchanged. Many don't send a 73, but end the QSO after sending a signal report. That's fine. But I also see some operators will continue sending signal reports until I have answered with a 73 several times. I'll usually get a confirmation via eQSL or LoTW so I assume they received my signal report. This makes me think I'm missing something. Is there an explanation?


__________
Dan - K4SHQ
CFI/II





This email has been scanned by BullGuard antivirus protection.
For more info visit www.bullguard.com








locked Re: Puzzling QSO endings #QSO_practices

 

Mike,
I'll reply to an R-XX with a plane 73 up to four times. Then I assume he just can't receive me. Sometimes I'll use JTAlert's message facility to send a notification that I have them in my log.

Thanks for the clarification.
__________
Dan – K4SHQ
CFI/II

-----Original Message-----
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Michael Black via groups.io
Sent: Friday, May 13, 2022 11:54 AM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Puzzling QSO endings #QSO_practices

There are those that expect a 73 and those that don't.
If you or they are using the standard RRR response then both 73's are usually used in FT8.
But...they will log when they send their 73.
I've never seen anybody end after an R-XX report.  If they keep sending it means they didn't get your 73.
Mike W9MDB




On Friday, May 13, 2022, 11:48:14 AM CDT, Dan Malcolm <k4shq@...> wrote:

I've observed this operating practice for some time now and not such a big deal.  FT8 QSO should, but don't have to, end with 73's being exchanged.  Many don't send a 73, but end the QSO after sending a signal report.  That's fine. But I also see some operators will continue sending signal reports until I have answered with a 73 several times.  I'll usually get a confirmation via eQSL or LoTW so I assume they received my signal report.  This makes me think I'm missing something.  Is there an explanation?


__________
Dan - K4SHQ
CFI/II


locked Re: WSPR

Ellis Birt (G7SAI)
 

If you have the gps for time you may as well use it for location and to discipline your DDS frequency


locked Re: error scanning adif log #adiFiles

Martin G0HDB
 

On Sat, May 14, 2022 at 06:10 PM, Bill Parris wrote:

I know this has been covered many times in the past, but my problem continues.
I have upgraded to the latest version, still have the error message. I have
read all of the previous posts regarding fixing this. When I bring up the
file in notepad, the header does not appear, just the first logging entry.
How can I locate the header?
Bill, AA4R
Bill:

Are you sure you're looking at the correct file, namely wsjtx_log.adi? There's another file - wsjtx.log - in the same directory but this isn't the ADIF file that gets read by the software; my understanding is that the .log file simply records all the logging transactions rather than containing the logged QSOs themselves.

--
Martin G0HDB


locked Re: WSPR

Stan Gammons
 

On 5/14/22 02:38, Alan G4ZFQ wrote:
I've seen some drift that was -3 or -4. Anything to be concerned about?
Stan,

If it is only occasional from maybe one or two stations then it is their
problem.
If it is on most spots of your transmission then you are drifting.

A search seems to indicate that some IC-7300s do drift on TX. eg
http://www.wsprnet.org/drupal/node/7967

73 Alan G4ZFQ

Hi Alan,

It looks like the IC-7300 does drift some. I tried with my TS-590SG and
the drift shows as 0 on almost every station that reported hearing me.
The TS-590SG does have the optional TCXO.

I've thought about making a WSPR transmitter using an Arduino UNO with a
GPS module for the time and an AD9850 DDS. Something like this
https://www.george-smart.co.uk/arduino/arduino_wspr/   The sketch
doesn't look quite right though. Will have to see if it works when I get
the Skylab GPS module.

73

Stan
KM4HQE


locked Re: Puzzling QSO endings #QSO_practices

Jeff Stillinger
 

You are right, it is not that big of a deal.    Your station, your process.

In my operation process, I do expect to see confirmation that my signal report was received, either with a RR73 or the full RRR 73 sequence.   If I do not receive acknowledgement after the third attempt, I assume the contact was lost to propagation.   I do not log it and I move on to the next contact without second thought. Win some, loose some, next...  I run my logging and uploads in real time.   With everything else there is to do in life, the chances of me taking time out to reconstruct a broken contact are slim to none.

On Friday 5/13/2022 07:43, Dan Malcolm wrote:
I've observed this operating practice for some time now and not such a big deal. FT8 QSO should, but don't have to, end with 73's being exchanged. Many don't send a 73, but end the QSO after sending a signal report. That's fine. But I also see some operators will continue sending signal reports until I have answered with a 73 several times. I'll usually get a confirmation via eQSL or LoTW so I assume they received my signal report. This makes me think I'm missing something. Is there an explanation?


__________
Dan - K4SHQ
CFI/II





locked Re: error scanning adif log #adiFiles

Reino Talarmo
 

Add this to the top of the fileADIF Export<adif_ver:5>3.1.1<created_timestamp:15>20220331 125620<programid:6>WSJT-X<programversion:5>2.5.4<eoh>
Hi
I don't have any header on the adif file, but wsjt-x reads it without any hiccup. 8000+ records is shortly shown on the info box in the bottom line left hand.
Do your wsjt_log.adi file possibly contains empty rows or a header line somewhere inside the file?
In notepad you could search for <eoh> or some contents of the proposed header above.
By the way I have in another wsjtx_log.adi file header "WSJT-X ADIF Export<eoh>".
73, Reino OH3mA


locked Re: error scanning adif log #adiFiles

Michael Black
 

Add this to the top of the fileADIF Export<adif_ver:5>3.1.1<created_timestamp:15>20220331 125620<programid:6>WSJT-X<programversion:5>2.5.4<eoh>

On Saturday, May 14, 2022, 12:10:10 PM CDT, Bill Parris <aa4r@...> wrote:

I know this has been covered many times in the past, but my problem continues.  I have upgraded to the latest version, still have the error message.  I have read all of the previous posts regarding fixing this.  When I bring up the file in notepad, the header does not appear, just the first logging entry.  How can I locate the header?
Bill, AA4R


locked error scanning adif log #adiFiles

Bill Parris
 

I know this has been covered many times in the past, but my problem continues. I have upgraded to the latest version, still have the error message. I have read all of the previous posts regarding fixing this. When I bring up the file in notepad, the header does not appear, just the first logging entry. How can I locate the header?
Bill, AA4R


locked Re: Long running WSPR tx crashing WSJT; recreating issue and narrowing down parameters #wsjt-x-crashing #macOS

Michael Black
 

If you look at my QRZ page I have links to USB adaptors which break the shield.  There are both USB-A and USB-B adaptors.  You can put those on most any USB device (not the hub though) and reduce the RFI running around your setup.  This is because everybody ties the USB shield to pin 4 on the usb plug and also tie the common return on power to chassis -- both of which are the wrong thing to do.
Having your station properly grounded also matters so please describe your shack grounding system. Most common mistake I see is the "rod in the ground outside the shack" which is not tied to the main house ground.  And then what that is ground correctly 2nd most common is the shack PC is then grounded to the house ground instead of lifting the ground pin to ground.
Mike W9MDB





On Saturday, May 14, 2022, 06:25:19 AM CDT, Chuck Moore via groups.io <wd4hxg@...> wrote:


locked Re: Long running WSPR tx crashing WSJT; recreating issue and narrowing down parameters #wsjt-x-crashing #macOS

Chuck Moore
 

StuLike you I have an IC-7300. Unfortunately triyng to keep it operating when operating FT-8 it is hit or miss. The consensus has been rf is getting into the USB line andcausing havoc with control of the rig. I am not convinced and think it is actuallyrf getting into the audio codecs inside the radio. I have two stations, about 300miles apart and each is equipped with Yaesu radios and the Yaesu SCU-17.  Each operates reliably with full power, no issues, one at 100 watts and the other at 200watts. I can pull the Yaesu rig and SCU-17 in either location and replace them with the IC-7300 and problems start.  At 10 watts out (minimum output) I can make one or two transmissions and boom, Windows plays the cascading downward tones.The screen then displays multiple messages that the audio codecs are not working. Above 10 watts the computers balks soon as the transmitter is keyed.I have tried  multiple fixes to include, toroids (32 material) on power cables, USB cable,coax etc. I tried the Icom recommended Tripp-Lite USB cable with integral ferritecores for RFI suppression. No joy. I can re-insert the Yaesu rigs and SCu-17, and life is back to normal. The Icom was purchased in the fall of 2021 and is currently awaiting my nexttrip to HRO in Virginia where I will place it on consignment. It is the secondIcom radio I purchased in the last decade and both have been disappointing.Please keep us posted on what your solution is.73Chuck WD4HXGOn May 13, 2022, at 6:07 AM, stuartogawa@... wrote:I am performing long running WSPR tx antenna experiments using 4 different antennas (3 sky loops and 1 vertical)from 160m to 6m; long duration tx experiments and testing defined over 2.5+ years.3 months ago I purchased an ICOM 7300 ( recent firmware). Connected this to Mac Mini M1 (2020). OS = Big Sur 11.6.5. 16 gigs of RAM. Never use more than 10 gigs of RAM per the Mac Activity Monitor displaying total RAM used (when running WSJT, chrome, and activity monitor...no other apps running).Successfully configured Mac WSJT v 2.5.4. Duty cycle set to 90%. No band hopping. 6m only for this particular antenna experiment. Began non stop tx.The next morning I noticed the WSJT stopped transmitting. I subsequently quit the WSJT and restarted. Over the course of .5 months I have been trying to narrow down and resolve this WSJT transmit failure issue.I run this setup along with 4 Zachtek WSPR transmitters non stop; the 4 Zachtek's have been operational for the past 2.5+ years. I needed more power than the Zachtek (200 milliwatts) to extend and expand my experiments, hence the purchase of the Icom 7300.I read through all Mac OS transmit fail issues (in this forum) and a sufficient number of the Windows transmit fail issues (in this forum).What has not been expressed in these threads, which I may have missed, is actually how many hours, days, or weeks people are transmitting with their Mac or Windows OS and the Icom 7300...nonstop...before a crash occurs. For the past 3 months I typically have to quit and restart WSJT every 15 to 18 hours when running nonstop transmitting at 90% duty cycle. 90% = approx. 20 WSPR transmissions/hour.I decided to dive deep, understand and express the software issue I am encountering. (I have a sw development and big data/analytics background with deep research). I am wondering if anyone has encountered or tested the issue as documented below:-------------What I have done as a result of the recommendations here as well as found on the net:* Installed a toroid donut (mix type 43) on the USB cable (to trap RF). No resolution.* I downgraded from WSJT 2.5.4 to 2.5.2; one member in this forum suggested that 2.5.2 was more stable for the Mac OS. No resolution.Impact - none of these suggestions resolve the issue when long running WSJT with WSPR---------I then performed the following experiments to help identify, narrow, and characterize the issue:Experiments 1a, b, c, d, e, and f May 7 to May 10 (baseline testing)Configuration: WSJT 2.5.2, Mac Mini M1 (2020). OS = Big Sur 11.6.5. 10 watts TX. * WSJT tx set to verbose mode = every transmission logged and displayed in WSJT primary operational screen* quit all apps on mac except WSJT, Chrome Browser, and Mac Activity Monitor running* fresh start WSJT; no tx logged in primary log screen* begin non stop transmission at 90% duty cycle 6m WSPR** note - when I set tx duty cycle to 90%, then this equates to roughly 19 to 21 WSPR transmissions/hr; I use 20 WSPR tx as an average for all my experiments to help narrow down the issue* note - when WSJT just starts, Mac Activity Monitor displays approx 150 megs of RAM used by WSJT and 11 threads activated (receiving mode); when tx is running, then 13 threads activated* I ran this aforementioned test N = 6 timesResults and observations:* As time unfolds, two specific observations at WSJT failure:First observation** as WSPR TX increases over time, the amount of RAM used by WSJT, as captured by the Activity Monitor grows** critical window observation: in all 6 experiments, when WSJT RAM utilization reaches between 180 to 185 megs per the Activity Monitor, WSJT fails to transmitSecond observation** in all 6 experiments, critical window observation is that between 285 and 310 logged WSPR TX messages in the primary window WSJT fails------------Experiment 2* same configuration as Experiment 1 with one exception (scientific method approach)** changed the WSJT preferences display to NOT display TX messages in the primary screen. all other parameters exactly the same* execute test* WSJT failed some time < 15 hours; I was at work when failure occurred; cannot provide number of TX messages (probably in a file log) Interesting failure observation* Unlike Experiment 1 and derivatives, when WSJT failed, the progress bar displaying tx or rx status stopped in the middle of the progression. I have not seen that in previous experiments and observations.----------Experiment 3* Same configuration as Experiment 1* Executed same steps as 1* Waited for WSJT failure to occur* Once the failure occurred, I performed the following test steps:** did NOT quit application** selected the Erase button on the primary screen, which consequently deletes all displayed TX WSPR transmission** selected the TX buttonOutcome* TX began and then I went to work* Came home and saw the same outcome in Experiment 2...progress bar stopped midway through the progression; < 15 hours----------Has anyone done nonstop transmissions like this and encountered similar issues?Given there is plenty of Mac RAM per the Activity Monitor, the issue feels like a WSJT sw memory management, allocation, stack overflow issue...even when displayed verbose method is turned off.Your insights appreciated.thanks.-stuwb6yrw


locked Re: Yaesu FT991A Won't Transmit in FT8 #Cat_RigControl #NewUser #TechnicalHelpQuestion #transmit #Yaesu

Reino Talarmo
 

Hi Ropert,

The sensitive part of your installation is the connection between your radio and MacBook. I think you mentioned it to be a USB cable. A quite low common mode current on the cable do enter into your rig and MacBook sensitive digital circuits disturbing USB communication. How the RF current enters through USB connections depends on how the circuitry and cable screens are wired. Further information is e.g. in Jim's papers: k9yc.com/RFI-Ham.pdf presents the concepts; k9yc.com/2018Cookbook.pdf presents designs of effective transmitting chokes for the HF bands. Note that a common mode choke works correctly, when there is a low RF impedance to ground on the both side of the choke. A short wire to "real" ground would be best.

SSB does not normally use at all the rig - MacBook communication unless you have some logging program in use. You could get RF burns, if you rig and microphone happens to be in high impedance point of your "antenna system". In any case radio - computer interfaces can be much more sensitive than human can sense, or should I say "is".

It could be possible that something is damaged in the radio as well due to high RF current/voltage 100 W transmission can generate. Does SSB or CW still works or have you lost all transmission capability?

The antenna manufacturer does not tell the whole story how an end fed antenna actually works by the laws of physics (any current needs a return bath). By the way in the recommendations of the European radio amateur training discourages use of EFHW antennas due to the fact that the user needs to deal with the "missing half of the antenna". Please note that know how well EFHW can work, when a suitable "grounding" arrangements are used and power level is not too high, say 10 W. In most cases the antenna feed point in those cases is close to ground, not elevated as in the installation instructions you referred.

You could try a counterpoise from the outer cell of the antenna connector and a current balun on the feedline. Even better could be to insert the current balun where the feedline goes close to ground and connect the feedline outer conductor to ground at that point. Unfortunately that may affect to the SWR values. I could not deduct how they simulated radiation patterns in Figure 4. Well at least they had a perfect ground.

73, Reino OH3mA


locked Re: WSPR

Alan G4ZFQ
 

I've seen some drift that was -3 or -4. Anything to be concerned about?
Stan,

If it is only occasional from maybe one or two stations then it is their problem.
If it is on most spots of your transmission then you are drifting.

A search seems to indicate that some IC-7300s do drift on TX. eg http://www.wsprnet.org/drupal/node/7967

73 Alan G4ZFQ


locked Re: Long running WSPR tx crashing WSJT; recreating issue and narrowing down parameters #wsjt-x-crashing #macOS

stuartogawa@...
 

Starting next set of experiments to understand and characterize the WSJT long running tx failure.

Next set of experiments: 4a, b, c, d, e, f

Same configuration as Experiment 1 with the following exception:
* changed TX percentage (duty tx cycle) from 90% to 50%
* quit WSJTx and began non stop transmission
* will perform this exactly for 4a, b, c, d, e and f without any config changes
* will summarize experiment outcome results early next week

---------

Results and observations from experiment 4a

* average number of wspr transmissions/hr = 14 using 50% tx duty cycle
* WSJT ran for 25 hours before failure
* The progress bar continued operating; hence part of the sw was operational; not a full P0 / Sev 0 (app fully down / locked / complete unresponsive) as documented in experiment 2 and 3 outcomes
* 349 WSPR contacts logged before failure
* WSJT RAM usage grew from 150.1 baseline starting point to 242 megs of RAM used by WSJT before failure

------------

* Observation notes from experiment 4a:
** RAM utilization was materially higher (at 50% tx duty cycle) before failure relative to the 180 to 190 megs of RAM used by WSJT at 90% duty cycle before failure; delta approx 55 more megs of RAM WSPR tx log stored data before failure. Hence, more WSPR transmissions logged before failure. This is an important tell tale.
** The reduced TX percentage (from 90% to 50%) of course means that less Tx data being created and stored. One could rationalize that I was able to run longer hours before failure - mean time before failure - (25 hrs as opposed to 14 to 18 hrs) because WSJT at 50% duty cycle had less WSPR Tx log entries for the same time frame
** I was able to log 349 WSPR WSJT contacts at 50% duty cycle (experiment 4a) versus approx 280 to 330 WSPR WSJT (experiments 1 to 3) contacts at 90% duty cycle; not a big delta between these (so far). Yet I wonder if the program garbage collection algo and applied method is correct; will I get more contacts using 50% duty cycle for the same time because the program has latency doing garbage clean up? While it is to early to tell without more experiments, it is looking like if you don't quit WSJT and transmit up to a certain ceiling, call it 350 entries(for now) in the WSJT primary screen, you will get a tx failure.

---------------

Question

Curious if other WSJT users who eventually have a crash/ failure, regardless of operating system, encounter a WSJT failure when they hit the 330 to 379 transmission entries AND without quitting WSJT. If you quit WSJT before 250 tx entries, you may not ever encounter this crash.


locked Re: Decoding Issue …. #FT8

Reino Talarmo
 

Are you sure that your local oscillator frequency is low enough and the signals you see on the waterfall are from the upper side band of the receiver? E.g. on 20 m band the local oscillator frequency should be 14.074 MHz or lower.
73, Reino OH3mA


locked Re: Decoding Issue …. #FT8

Pietro Molina
 

Sure you have no AFC?

Pietro I2OIM

Il ven 13 mag 2022, 23:26 Carl Griebno <k2gej.sc@...> ha scritto:

I have a waterfall full of strong signals but few will decode, almost
always at 500 Hz and below.
Using a QRPGuys FSK Transceiver III, No Cat control, comms over audio
cable to computer.
Have had some complete quo’s but quite iffy.
ANY help. Will be appreciated.

I disabled Windows time and installed Dimension 4. Time.is now has my
computer time exact.
Signal Bar hovers around 70 , stays green.
TX does just fine. I get answers to CQ but Miss because of decoding
issues.

Thanks,
K2GEJ






locked WSPR

Stan Gammons
 

I've been tinkering with WSPR lately. At first it was receive only using an SDRplay RSP1A, CubicSDR and WSJTX 2.5.4 on Kubuntu 20.04 Antenna is a 55 ft random wire fed with a 9:1 unun at the antenna and RG-8X into the shack. I decided to try transmitting with my IC-7300, set at 5 watts, WSJTX 2.5.4 on Kubuntu and the same antenna. Looks like folks are hearing me. Just curious about the drift as reported on the wsprnet.org site. I've seen some drift that was -3 or -4. Anything to be concerned about?

73

Stan
KM4HQE


locked WSPR

Stan Gammons
 

I've been tinkering with WSPR lately. At first it was receive only using an SDRplay RSP1A, CubicSDR and WSJTX 2.5.4 on Kubuntu 20.04 Antenna is a 55 ft random wire fed with a 9:1 unun at the antenna and RG-8X into the shack. I decided to try transmitting with my IC-7300, set at 5 watts, WSJTX 2.5.4 on Kubuntu and the same antenna. Looks like folks are hearing me. Just curious about the drift as reported on the wsprnet.org site. I've seen some drift that was -3 or -4. Anything to be concerned about?

73

Stan
KM4HQE


locked Re: Puzzling QSO endings #QSO_practices

Lawrence Godek
 

I do the same.

On 5/13/2022 10:03 AM, chas cartmel wrote:
Just for information I always send a '73' or a 'RR73" to a contacted station when signal reports are exchanged and acknowledged.
For me it is operating 'manners' rather than a necessity.

The QSO is logged automatically but I mark it as no '73' and tend not to QSL these stations unless there is QSB and signal weak
. It's only 30 seconds after all.
I also do not work stations responding to my CQ with a signal report rather than a grid square. Again 30 seconds of effort.


73 Charlie
G4EST
www.g4est.me.uk
Stay safe out there


-----Original Message-----
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Dan Malcolm
Sent: Friday, May 13, 2022 1:43 PM
To: main@WSJTX.groups.io
Subject: [WSJTX] Puzzling QSO endings #QSO_practices

I've observed this operating practice for some time now and not such a big deal. FT8 QSO should, but don't have to, end with 73's being exchanged. Many don't send a 73, but end the QSO after sending a signal report. That's fine. But I also see some operators will continue sending signal reports until I have answered with a 73 several times. I'll usually get a confirmation via eQSL or LoTW so I assume they received my signal report. This makes me think I'm missing something. Is there an explanation?


__________
Dan - K4SHQ
CFI/II





This email has been scanned by BullGuard antivirus protection.
For more info visit www.bullguard.com







locked Re: Puzzling QSO endings #QSO_practices

WB5JJJ - George
 

I, on the other hand, log just about anything that has all the BASIC elements of a contact (as in callsign and signal report exchanged). You would be surprised as to how many LoTW confirmations I get even though I didn't see their RR73, RRR or even 73. WSJTx logs the contact after either party starts transmitting RR73 or RRR, so I go with that. And yes, there are those that require a 73 both ways even if I send RR73, they won't log it unless I send a second 73 alone, which I don't normally -- go figure, it doesn't bother me one bit. If I notice they don't confirm, I just assume they are don't use LoTW and never look back.
--
73's
George - WB5JJJ
Hamshack Holine #4969

1401 - 1420 of 35397