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@gmail.com 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

Join main@WSJTX.groups.io to automatically receive all group messages.