Date   

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

Robert44
 

Hi Reino, Steve and Jim and many thanks for you guys' feedback! Below are the instructions for the Chameleon Lightweight End Fed Sloper antenna I am using (it does have an integrated transformer as part of the antenna):

https://static.dxengineering.com/global/images/instructions/cha-lefs.pdf

Chameleon does say to use their ferrite which is like 6 or so ferrites integrated into a short length of coax which is placed right at the feed point of the antenna. I am not Chameleon's ferrite but rather 6 DXengineering clamp on ferrites (mix 31) at the antenna feed point and 6 more at the radio's (Yaesu FT-991A) coax feed point. This worked well for voice modes even at the full 100 Watts. Also, the antenna with Chameleon's ferrite has good reviews (for voice modes) but I have never seen reviews for digital modes.

Do digital modes and computers tend to be more sensitive than radios using voice modes? I am thinking that is indeed the case. If so a large lack of RF suppression could be the problem here. This is a long thread but the gist of it is my radio receives and decodes perfect but has problems transmitting. It now will not transmit at all, even at 5 Watts. I was thinking that at 5 Watts the RF common mode current would be 1/20 of what it would be at 100 Watts. My wife has an identical MacBook Pro as mine and I downloaded WSJT-X on her computer and still it does not work so I don't think it is a computer problem.

I think I might try moving the ferrite down the coax from the antenna and see how that works. If it does not work I think I will try a different antenna. Also, do you guys think common mode current from using 100 Watts could have damaged my radio??? I THINK the radio stopped transmitting when I tried to transmit with 100 Watts. I have done several full factory resets with no luck and computer restarts. Many thanks!

Robert KI5TPC


locked Re: Puzzling QSO endings #QSO_practices

Jim Preston N6VH
 

On 5/13/2022 5:43 AM, 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
Dan,

Not every one has the same requirement for what constitutes a valid QSO. Some require a 73, others don't. In my case, all I ask is that I get an acknowledgement of the report I sent. RR73 covers both bases of course, but RRR is good enough for me. If I don't get an acknowledgement of my report, then I don't consider it a QSO. As I said, every one has their own standards. I always send 73 at the end of a QSO, except for Fox/Hound.

73,

Jim N6VH


locked Decoding Issue …. #FT8

Carl Griebno
 

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 Re: Lotw #logging

Robert Bower
 

Thank you

On 2022-05-13 08:17, s52d wrote:
LotW: you specify YOUR UL in ADIF (either via TQSL or with proper ADIF data).
Your corespondent locator is obtained from his data: so you need to have
LotW confirmed QSO with proper data from his side. Some 95 % of LotW users
managed to fill up TQSL data with own locator.
73 gl
Iztok, S52D
On 5/13/22 5:10 AM, Robert Bower wrote:
Am I doing something wrong or is there a format issue?
Once I got everything working on my G90, I made a few contacts on ft8.
I created the qso for each. I then copied the adif file and uploaded it to lotw.
Even though the adif file contained the grid square field for the contacts when I viewed the qsos on lotw the qth field was blank.
Thanks
Robert
W9RWB
--
Thanks,

Robert Bower
W9RWB
WRPH745


locked Re: Puzzling QSO endings #QSO_practices

chas cartmel
 

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

Michael Black
 

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: Lotw #logging

s52d
 

LotW: you specify YOUR UL in ADIF (either via TQSL or with proper ADIF data).

Your corespondent locator is obtained from his data: so you need to have

LotW confirmed QSO with proper data from his side. Some 95 % of LotW users

managed to fill up TQSL data with own locator.


73 gl

Iztok, S52D

On 5/13/22 5:10 AM, Robert Bower wrote:
Am I doing something wrong or is there a format issue?

Once I got everything working on my G90, I made a few contacts on ft8.

I created the qso for each. I then copied the adif file and uploaded it to lotw.

Even though the adif file contained the grid square field for the contacts when I viewed the qsos on lotw the qth field was blank.

Thanks

Robert
W9RWB


locked Automated QSOs #QSO_practices

Kermit Lehman
 

In FT4 mode WSJT-X has an option: "Best S+P"

From the WSJT-X manual:
Clicking Best S+P during an Rx cycle arms the program to examine all CQ messages decoded at the end of the Rx sequence. The program will select the best potential QSO partner (from a contesting perspective), and treat it as if you had double-clicked on that line of decoded text. Here "best potential QSO partner" means "New Multiplier" (1st priority) or "New Call on Band" (2nd priority). "New Multiplier" is currently interpreted to mean "New DXCC"; a more broadly defined multiplier category (for the ARRL RTTY Roundup rules) will be implemented in due course. We may provide additional priority rankings, for example “New Grid on Band” (useful for North American VHF contests), sorting by signal strength, etc.

The ARRL Digital contest rules say (in accordance with the general ARRL policy)
OPRG.4. Each contact must include contemporaneous direct initiation by both operators making a contact. Initiation of a contact may be by either local or remote control. Fully automated contacts are prohibited.

Although the operator has to keep ticking on "Best S+P" for each new QSO, "Best S+P" selects the station to call and initiates the QSOs. As such, it is prohibited under ARRL rules. This should probably be mentioned in the rules to avoid any misunderstanding. 

73,
Ken, AB1J

-----Original Message-----
From: Ria, N2RJ <rjairam@...>
To: main@wsjtx.groups.io
Sent: Wed, May 11, 2022 9:43 pm
Subject: Re: [WSJTX] DX-pedition multi trace contacts #FoxAndHound

MSHV has multi answer and full automation as well, unfortunately.

Ria
N2RJ

On Wed, May 11, 2022 at 5:37 PM n4qwf . <N4QWF1@...> wrote:

Thank you, I don't know what MSHV is but I will do a search for it.

73<<John

On Wed, May 11, 2022 at 5:01 PM Darin - NY7H <darin.crowley@...>
wrote:

I think he's working MSHV.

Darin
NY7H

On Wed, May 11, 2022, 1:45 PM n4qwf . <N4QWF1@...> wrote:

You know I ask a fair question. I did not expect a smart ass remark.
What I
meant was He was not working split. No I was not on his frequency. I was
calling him at a open spot in the waterfall.  What I noticed was I did
not
have the WSJT program setup for F/H nor in split mode. Neither did any of
the other many stations who called and worked him. He was sending two
tracks and responding to two stations in the same time slot.  I guess I
expected more from the WSJT list than this.

<<John N4QWF

On Wed, May 11, 2022 at 4:17 PM Robert Lorenzini <bob@...>
wrote:

You worked a DX station on his frequency? There is a word for this.

Bob - d6dod

On 5/11/2022 1:09 PM, n4qwf . wrote:
I am aware of the Fox/Hound function of WSJT as I have used it many
times to work DX. Yesterday I worked VU4W on 17m FT8. I was not sure
how
he
was operating as he was answering two stations at once but he was not
using
F/H. I worked him direct on his frequency. I have never seen this type
of
operation before. Would someone point me to information explaining this
type of operation?





















locked 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


locked MAP65 v3.0 input sources problem #AudioIssues #map65

Ed N1QG
 

I cannot get MAP65 v3.0 to find most of my audio endpoints, in particular, the one I need for 90khz bandwidth via virtual cable.
I am running an RSP2 through HDSDR and Virtual CableB to map65.
In map65 v2.7 I see seven input choices available (3 MME, 3 Direct X, 1 WDM-KS - the one I need).
In v3.0 I only see the three MME inputs.

I can make the system work with the MME Cable Output (VB-Audio...). input in v3.0 but only with 45 khz bandwidth passing through to map65.
In v2.7, indeed, this MME choice gives 45 khz (I presume MME can't get the I/Q to turn into 90 khz BW), but I can select the WDM-KS input and get the full 90 khz bandwidth.

I read some previous comments about turning off power savings modes, and have disabled usb suspend, and each hub's power savings modes, all to no effect. I have uninstalled v2.7 and v3.0 (i.e. wsjtx), reinstalled (as well as Virtual Cable B), and obtain exactly the same behavior as before.

I have installed the same set of software on my laptop (also Win10, with latest updates) and obtain identical behavior as per above, i.e., I only see the MME audio endpoints on v3.0, but see all seven endpoints on v2.7.
Just to add to the mystery, originally (some months ago) V3.0 did NOT have this issue (i.e. I saw all seven input choices). A bit later (presumably after a windows 10 update) I would see this problem on (fast) boot up, but could readily fix it by doing a driver refresh (ctl-win-shift-B), or simply disable fast boot. I suspect that the win10 update in February caused the latest behavior, where even the driver refresh does not fix the problem.

Anybody have any ideas what to try next?
Thanks! Ed


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

Reino Talarmo
 

Hi Steve,

No problem. That mail is a part of a mail chain and in an earlier one the antenna type was mentioned and it was obvious that an UNUN is a part of the installation (it was not a relevant issue in the mail as such, relevant is that the feedpoint impedance is high). It was also mentioned that at the high impedance side the antenna wire is connected to the "upper" end of the transformer and the "lower" end of the transformer it connected to the coaxial outer conductor (transformer is actually an autotransformer, that's fine). So the coaxial outer conductor is assumed to work as a counterpoise or as the missing part of the antenna.

Your addition of the current balun at the coax 15 feet from the feedpoint "cuts" the coax so that those 12 feet behaves as a counterpoise that also radiates. As a result common mode current on the rest of the coax is lower enough and your interfaces behave correctly.

Most probably the common mode impedance of the balun is much higher than those clamp on ferrites offer and the balun is in a more proper position on the coax or did you put the clamp on ferrites at the 12 feet point?

73, Reino OH3mA

If using an EFHW, you will have an UNUN that transforms the high impedance at the antenna to approximately 50 ohms.
The explanation below “seemed” to omit the UNUN that is part of the EFHW system. I admit I may have skimmed over it quickly and apologies if I didn’t follow.


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

SteveO
 

Was following this and was confused.

If using an EFHW, you will have an UNUN that transforms the high impedance at the antenna to approximately 50 ohms.

On my mobile and home setups (both EFHW’s) I used to use clamp on ferrites everywhere to no real improvement. I purchased an RF Choke (MFJ) and installed about 12 feet from the UNUN and solved the problem. So I bought a second one for the mobile installation. No more issues for me.

The explanation below “seemed” to omit the UNUN that is part of the EFHW system. I admit I may have skimmed over it quickly and apologies if I didn’t follow.

Best regards,
Steve de KC5NK

Sent from Mail for Windows

From: Reino Talarmo
Sent: Thursday, May 12, 2022 1:52 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Yaesu FT991A Won't Transmit in FT8 #Cat_RigControl #NewUser #TechnicalHelpQuestion #transmit

I have always thought that the ferrite choke reduces or eliminates the current flowing on the outer conductor of the coax. Also, what do you mean by "The potential integrated RFI choke on the coax only moves resonance point?"
Hi Robert,
Your assumption is correct, but how much?
How much current is reduced depends on two issues:
The impedance of the ferrite choke and the impedance the choke sees to the both directions of the insertion point. A clamp on ferrite choke at HF is order of tens of ohms and a multi turn ferrite choke could be few thousand ohms. That is the simple part. In addition the impedance of the choke can be quite reactive, but usually ferrite is selected so that the impedance is heavily resistive.
What impedance the choke sees depends on many issues, but in the case of an end fed half wave antenna the impedance is at the antenna side is order of thousand ohms. Towards coaxial cable it depends strongly on the length of coax (as wave lengths) and how the coax or more often how the rig (or PC) is connected to ground. If that connection to ground is made via house mains wires, then also that length needs to be added to the coax length. That impedance could be from tens of ohms to hundreds or even thousands of ohms.
So without a choke we could be 100 mA RF current on the outer conductor of the coax. If we clamp one typical ferrite choke 100 ohms and the antenna impedance is 2000 ohms, then the current will be 95 mA i.e. no real attenuation. Let's take a typical choke, say 1500 ohms, then the current will be 57 mA, still not a huge improvement, but could just move to the safe side, hi! (I assumed that the choke impedance is mainly resistive. If reactive part is large compared to the resistive part, then reactive parts may cancel more or less each other. I have seen in some simulations how an addition of a "good" ferrite choke actually doubled the common mode current in a low impedance case.)
I want to "correct" my statement about the resonance point change due to a RFI choke in this specific case, where the choke will be in a high impedance point, the effect is minimal.
73, Reino OH3mA

PS. this discussion may be quite off the main purpose of this mailing list, but some WSJT-X users have problems in this field although as such RFI cannot solved by programming.


locked Re: Kenwood Silicon Labs Driver issues #TechnicalHelpQuestion

Marlo Montanaro - KA2IRQ
 

I have a Dell Windows 10 laptop that uses Silicon Labs drivers to connect via a virtual serial port to a console port on a router. This is very similar to your situation with the Kenwood.

I couldn't get it to work to save my life. The Silicon Labs driver in Device Manager just showed up with a big yellow exclamation point - not working.

The answer turned out to be a manual update of the driver. Don't use the Silicon Labs application to do the updates. You can probably remove that software.

Connect to the device, let the drivers install, but they won't work.

In Device Manager, find the device, right click and select "Update Driver".
Click on "Search Automatically for Drivers"
Click on "Search for update drivers on Windows Update"
Click on "Check for Updates" > View Optional Update
Select "Silicon Labs Inc - Port - 10.x.x.x" and click "Download and Install"
For me, I never saw the "Download" percentage change from zero- but when I went back to Device Manager, a COM port was listed and working.

Hope that helps you out.

73,
Marlo
KA2IRQ


locked Re: Kenwood Silicon Labs Driver issues #TechnicalHelpQuestion

Jim Bacher - WB8VSU
 

Without knowing more, I would unplug the USB cable at both ends and plug them back in. Could be the cable was bumped and isn't fully engaged on one of the ends.

Although not likely I have had USB ports fail. So if resetting the cable doesn't help, change to a different USB port on the computer.

Make sure with the Device Manager that the com port and audio device settings didn't change. I have had audio and com ports change, for unknown reasons after a reboot.

⁣Jim Bacher, WB8VSU
wb8vsu@...
https:\\trc.guru​

On May 12, 2022, 11:39 PM, at 11:39 PM, "Williams, G (af8c) via groups.io" <af8c@...> wrote:
I wrote what he told me had happened.  Note the words "he can". I am
getting all the information over a telephone call.  I can't see what is

happening.  About a month ago he had the same problem and "fixed" it by

merely reinstalling the Silicon Labs driver.  I was hoping to hear from

folks who have recently worked with the Silicon Labs install.  I hope
we
aren't the only two people who have TS590SG's running FT8.  It was
difficult to ask him what he was seeing on his screen because at the
time today when I heard the story, he was not in the shack and was just

telling me the stories.  Obviously I will be working to get more
detailed information.

By the way, patch Tuesday is all about Windows updates:

https://www.zdnet.com/article/microsoft-may-2022-patch-tuesday-seven-critical-vulnerabilities/

We don't "do" a patch.  Microsoft does them.  My TS590SG is still
working with FT8 with my laptop today, the very day the laptop got all
those patches installed. His laptop wasn't working already several days

ago because of issues with the Silicon Labs driver reinstall failure.

--Glenn, AF8C

On 5/12/2022 10:05 PM, Ron via groups.io wrote:
You gave us some good history but haven't really described exactly
what is
occurring now. Are you seeing any error messages? It would be
helpful if
you could walk us through step by step what you are doing. You say
you did
a patch. Are you referring to Windows Update. You said you installed
the
Kenwood driver "umpty times" why did you feel the need to do that?
Were
you expecting a different result.

Sorry, wish I could be of more assistance, I have a TS-590 as well,
but
we're going to need more information than what you've provided thus
far.

Ron - KJ5XX

On Thu, May 12, 2022, 4:04 PM Williams, G (af8c) via groups.io <af8c=
alumni.caltech.edu@groups.io> wrote:

I am trying to help my friend with his Kenwood TS590SG WSJT-X
problem.

Background:
My friend and I are running TS590SG transceivers with WSJT-X FT8
from
Dell laptops. Both of us were having absolutely no problems for
many
many months. In fact my installation was in December 2020. This
radio
and computer combination with Windows 10 (and other recent
versions of
Windows) has had no problems so far in 18 months of use (knock on
wood). Note that the operation with the TS590SG requires a Silicon
Labs
USB driver be downloaded and installed for Windows. We both did
that in
late 2020.. Along the way after that there have been Windows
updates.
So far, my system setup is still working as of three days ago.

His is another story...

My friend's Dell Windows 10 laptop stopped working with FT8 last
week,
before patch Tuesday this week. He can reinstall the Silicon Labs
package umpty times and yet there are no good results. This is
while
reading and using the Kenwood special instructions on how to do it.
The
installation is specific on order of installing and plugging in the
radio with the USB cable. He says it's as if Windows will not accept
the
installation of the Silicon Labs driver when viewing Device Manager.

So we are looking for anyone with new knowledge of what to check
for.

--73, Glenn, AF8C

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus







--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus




locked Re: Kenwood Silicon Labs Driver issues #TechnicalHelpQuestion

Williams, G (af8c)
 

No "other" software is running besides WSJT-X and normal windows.
--73, Glenn, AF8C

On 5/13/2022 2:01 AM, hisami dejima via groups.io wrote:
Hi,
In that configuration,
Will other software, Fldigi, Omnirig etc. work perfectly?
73, Hisami 7L4IOU



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


locked Re: External computer display goes blank when sending at >50W #macOS

Ron
 

Agree with Chuck. This is likely due to stray RF in the shack.

Are you noticing any "hotspots" in the shack when touching metal objects
while transmitting or other odd behavior with equipment in the shack when
you transmit? If so it all points to stray RF.

What grounding methods are you using to equipment, to home, outside
grounding, etc? Do you have long runs of wire from shack to any grounding
rod or tie in or bonding to house mains?

Suggest you add ferrite snap on "beads" to your Monitor power cable and
cable from monitor to your PC.

Ron - KJ5XX

On Thu, May 12, 2022, 4:37 PM HOWARD POMERANTZ <HOWPOM@...> wrote:

MacBook Pro
MacOS: Catalina 10.15.7
WSJT-X: 2.5.4
XCVR: Icom IC-7300

This problem started after I installed 2.5.4.

Appears to only occur when I try to TX using btwn 50-100W.

Sending appears to be normal and the screen returns to normal after TX.

Any ideas would be appreciated.






locked Re: Kenwood Silicon Labs Driver issues #TechnicalHelpQuestion

hisami dejima
 

Hi,
In that configuration,
Will other software, Fldigi, Omnirig etc. work perfectly?
73, Hisami 7L4IOU


Robert Bower
 

Am I doing something wrong or is there a format issue?

Once I got everything working on my G90, I made a few contacts on ft8.

I created the qso for each. I then copied the adif file and uploaded it to lotw.

Even though the adif file contained the grid square field for the contacts when I viewed the qsos on lotw the qth field was blank.

Thanks

Robert
W9RWB


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


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

Stuart Ogawa
 

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 times


Results 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 transmit

Second 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 button

Outcome
* 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.

-stu
wb6yrw


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

Jim Brown
 

On 5/12/2022 8:57 AM, Robert44 via groups.io wrote:
On Wed, May 11, 2022 at 02:44 PM, Reino Talarmo wrote:

The potential integrated RFI choke on the coax only moves resonance point,
there is still the same current flowing on the coax outer conductor.
Hi Reino and thanks for the help! I did not know what I quoted above! I have always thought that the ferrite choke reduces or eliminates the current flowing on the outer conductor of the coax. Also, what do you mean by "The potential integrated RFI choke on the coax only moves resonance point?"
You are both correct. What Reino is telling you is that the supplied choke is very inadequate to stop current flow, and that multiple turns are required, the number of turns depending on the frequency, to kill that current.

Study k9yc.com/RFI-Ham.pdf and http://k9yc.com/2018Cookbook.pdf

73, Jim K9YC

4121 - 4140 of 38088