Re: [wsjt-devel] Wide Graph during TX
My bad. I was thinking of the Wide Graph window. What is the purpose of Wide Graph progress? I don't think I have it enabled. Rick From: Andy Durbin Sent: Sunday, June 7, 2020 12:51 PM To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] Wide Graph during TX "The Wide Graph pauses because nothing is received for processing." No, you are mistaken. Wide Graph progress has nothing to do with signal reception. Secondly, my TS-590S provides feedback of the audio modulation. It is not based on RF. Some rigs, e.g some Flex, do provide TX monitoring at the RF level. However, it doesn't matter how the rig implements TX monitoring. The fact remains that many rigs do provide the ability to monitor the TX signal while transmitting and this signal can usually be provided on the same audio channel that provides WSJT-X the audio signal while receiving. Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Wide Graph during TX
Andy, Before starting a transmission, the Transmit / Receive relay kicks in and disables the receiver section and enables the transmitter section. That protects the receiver from the 1 or more watts of output generated by the transmitter. The receiver section is generally designed for microwatts of input. The Wide Graph pauses because nothing is received for processing. I've thought about using a second radio but it would have to be miles away from my QTH. 73, Rick WK1P From: Andy Durbin Sent: Sunday, June 7, 2020 9:42 AM To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] Wide Graph during TX Wide Graph has always been frozen during TX for JT-65, JT-9, and JT65. It's been that way since the earliest versions of WSJT-X, but why? If Wide Graph continued to run during TX it would/could allow monitoring of TX audio for rigs that have that capability. Perhaps if people could see the shit they are sometimes transmitting they would do something to fix their signals. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Crash report
Hi Jari, That’s useful information. Especially if it can be reproduced. It says that the DLL named Qt5Core caused an EXCEPTION_ACCESS_VIOLATION. (Exception Code: c005) Simply put, it tried to access a memory address it did not have permission to read or write. But that’s not helpful. The crash should have created a memory dump file, .DMP, that could be used to debug it. If I remember, there should be a line of text with a path to the dump file. The crash occurred in the Qt libary code so it might be a known bug. It also could be caused by wsjtx passing in an invalid pointer to the Qt5Core code. Makes me wish I had my Windows Mobile debugging setup. Rick/WK1P From: Jari A Sent: Friday, August 16, 2019 5:36:07 AM To: WSJT software development Subject: [wsjt-devel] Crash report Win 7 pro 64 bit; WSJT-X started and being MSK144, - 50.280 Change manually qrg on radio to 50.313 and got FT8 signal to waterfall. Changing mode to FT8 from MSK144, cause crash. Shut WSJT-X and restart, got again signal from rx, change mode to FT8 and crash. Wait till rx signal end, restart WSJT-X, change mode to FT8 and all was fine. Problem signature: Problem Event Name: APPCRASH Application Name: wsjtx.exe Application Version: 0.0.0.0 Application Timestamp: 5d2a83ec Fault Module Name: Qt5Core.dll Fault Module Version: 5.12.4.0 Fault Module Timestamp: 5d0204a7 Exception Code: c005 Exception Offset: 001e8507 OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1035 Additional Information 1: 486f Additional Information 2: 486f0dae17f2ae9969ab02f5f36da8e9 Additional Information 3: a1db Additional Information 4: a1dbf885406e2ee4382d67208ad5cb6f Regards, :Jari / oh2fqv ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT Audio Input Loss
Bill, Disabling the USB power down on timeout was a good idea but no luck in solving the issue. I don't use a screen saver because I sometimes run my C++ code for days. Windows System for Linux (WSL) built HamLib but not WSJT-X. I'm going to try to spend some time getting it to build wsjtx. 73, Rick, WK1P From: Bill Somerville Sent: Monday, July 8, 2019 6:39 PM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] WSJT Audio Input Loss On 08/07/2019 21:57, Rick Drexel wrote: I started up WSJT-X on 10 meters this morning and expected to find it running when I got back home. After all, there was no activity and therefore nothing to decode. Nope, Wide Graph was frozen just as if I'd been monitoring a contest. WSJT-X was the only app running all day. I started it at 1000 UTC and it quit around 1135 UTC. It failed after 1.5 hours. Another random data point. Which doesn't rule out the Race Condition possibility given the 4 core/8 thread CPU it's running on. Just curious. How does WSJT-X make use of an Internet browser??? Hi Rick, have you disabled power saving options on your USB hubs? Some monitor drivers cause issues with audio streams when they go into screen save mode. WSJT-X doesn't use any web browser although if you request the online help to open it will tell the operating system to open the relevant URL however it feels it should, which is normally by passing it to the default web browser, open the application if necessary. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT Audio Input Loss
Band conditions being what they are, I started up WSJT-X on 10 meters this morning and expected to find it running when I got back home. After all, there was no activity and therefore nothing to decode. Nope, Wide Graph was frozen just as if I'd been monitoring a contest. WSJT-X was the only app running all day. I started it at 1000 UTC and it quit around 1135 UTC. It failed after 1.5 hours. Another random data point. Which doesn't rule out the Race Condition possibility given the 4 core/8 thread CPU it's running on. Just curious. How does WSJT-X make use of an Internet browser??? Rick From: Black Michael Sent: Saturday, July 6, 2019 5:57 PM To: WSJT software development; pe...@ni6e.com; Rick Drexel Subject: Re: [wsjt-devel] WSJT Audio Input Loss We've heard a few people say IE has caused audio problems. But...for the main testwhat happens if you run no browser at all? And how often does it fail? de Mike W9MDB On Saturday, July 6, 2019, 04:48:26 PM CDT, Rick Drexel wrote: The rig is an Icom IC-7100 connected by a USB cable directly to a Windows 10 64-bit desktop machine with 32 GB RAM. No sound card needed but I do have to check Settings to make sure WSJT-X Audio Tab hasn’t changed after a forced restart. I use Firefox or IE to open PskReporter to see what’s been reported by WSJT-X during the monitoring period. Rick WK1P From: Black Michael via wsjt-devel Sent: Saturday, July 6, 2019 3:35:43 PM To: pe...@ni6e.com; WSJT software development Cc: Black Michael Subject: Re: [wsjt-devel] WSJT Audio Input Loss What web browser do you use? There aren't a lot of these report so it doesn't seem like this is a common problem otherwise we'd hear more about it5. There has to be something in common. So what does your audio path look like? Rig, sound card, USB Hub?, PC model. de Mike W9MDB On Saturday, July 6, 2019, 02:32:27 PM CDT, Rick Drexel wrote: Your observations match those I have seen for about a year. I've tried to find a common set of circumstances that always cause the failure but have had no luck. I use WSJT-X in FT8 receive mode and PSKREPORTER to check band performance over a long time period. After a random amount of time, WSJT-X come to a halt. Specifically the Wide Graph Display and the Band Activity Display stop updating. The UTC in the Wide Graph Display no longer matches the UTC in the bottom left portion of the Main window. There is no correlation between the activity on the band and the time it takes to hang. Rarely does it not hang. As a software developer this has all the hallmarks of a race condition failure. Two (or more) threads update a shared resource without using a LOCK, UPDATE, UNLOCK sequence. During a thread context swap one of the threads reads the value, loses control to another thread that updates the value, then the first thread gets scheduled and writes back its stale value. The result is undefined behavior. Most of the time there is no conflict. Even under a heavy load. Then it fails unexpectedly. This makes it extremely difficult to debug. To recover I have to exit out of WSJT-X and restart it. This might not be the root cause but I would put it high on my list of the usual suspects. 73, Rick WK1P From: Peter Putnam Sent: Wednesday, July 3, 2019 3:06 PM To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] WSJT Audio Input Loss Greetings, I have been using WSJT-X quite successfully for several years during June VHF Contests. I experienced a failure of the WSJT program to accept received audio input after several hours of proper operation during the recent Field Day exercise. I'll provide a brief outline and reply with more detail, should it be needed. My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The WSJT-X software version is 2.0.1 7ddcb7. My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX" program that interfaces various applications that wish to receive the audio stream. WSJT accepts the stream and displays results on the Wide Graph and a small audio signal-strength window. Activity proceeded normally for the first three hours of Field Day, until both the Wide Graph and the audio signal-strength stopped showing any incoming audio. I can't offer any help on what might have caused the problem. It was abrupt and seemingly unrelated to any other system actions. I am unable to reproduce the problem. Several operators spent several hours speculating about what a solution might be. Program restarts and computer re-boots (time-tested favorite of generations) changed nothing. The only useful clue was that the DAX audio output stream was present and could be re-directed to Fldigi, but not to WSJT-X. I was able to restore operation for a brief period by stopping WSJT, renaming WSJT.ini and restarting WSJT. That fix lasted for a
Re: [wsjt-devel] WSJT Audio Input Loss
The rig is an Icom IC-7100 connected by a USB cable directly to a Windows 10 64-bit desktop machine with 32 GB RAM. No sound card needed but I do have to check Settings to make sure WSJT-X Audio Tab hasn’t changed after a forced restart. I use Firefox or IE to open PskReporter to see what’s been reported by WSJT-X during the monitoring period. Rick WK1P From: Black Michael via wsjt-devel Sent: Saturday, July 6, 2019 3:35:43 PM To: pe...@ni6e.com; WSJT software development Cc: Black Michael Subject: Re: [wsjt-devel] WSJT Audio Input Loss What web browser do you use? There aren't a lot of these report so it doesn't seem like this is a common problem otherwise we'd hear more about it5. There has to be something in common. So what does your audio path look like? Rig, sound card, USB Hub?, PC model. de Mike W9MDB On Saturday, July 6, 2019, 02:32:27 PM CDT, Rick Drexel wrote: Your observations match those I have seen for about a year. I've tried to find a common set of circumstances that always cause the failure but have had no luck. I use WSJT-X in FT8 receive mode and PSKREPORTER to check band performance over a long time period. After a random amount of time, WSJT-X come to a halt. Specifically the Wide Graph Display and the Band Activity Display stop updating. The UTC in the Wide Graph Display no longer matches the UTC in the bottom left portion of the Main window. There is no correlation between the activity on the band and the time it takes to hang. Rarely does it not hang. As a software developer this has all the hallmarks of a race condition failure. Two (or more) threads update a shared resource without using a LOCK, UPDATE, UNLOCK sequence. During a thread context swap one of the threads reads the value, loses control to another thread that updates the value, then the first thread gets scheduled and writes back its stale value. The result is undefined behavior. Most of the time there is no conflict. Even under a heavy load. Then it fails unexpectedly. This makes it extremely difficult to debug. To recover I have to exit out of WSJT-X and restart it. This might not be the root cause but I would put it high on my list of the usual suspects. 73, Rick WK1P From: Peter Putnam Sent: Wednesday, July 3, 2019 3:06 PM To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] WSJT Audio Input Loss Greetings, I have been using WSJT-X quite successfully for several years during June VHF Contests. I experienced a failure of the WSJT program to accept received audio input after several hours of proper operation during the recent Field Day exercise. I'll provide a brief outline and reply with more detail, should it be needed. My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The WSJT-X software version is 2.0.1 7ddcb7. My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX" program that interfaces various applications that wish to receive the audio stream. WSJT accepts the stream and displays results on the Wide Graph and a small audio signal-strength window. Activity proceeded normally for the first three hours of Field Day, until both the Wide Graph and the audio signal-strength stopped showing any incoming audio. I can't offer any help on what might have caused the problem. It was abrupt and seemingly unrelated to any other system actions. I am unable to reproduce the problem. Several operators spent several hours speculating about what a solution might be. Program restarts and computer re-boots (time-tested favorite of generations) changed nothing. The only useful clue was that the DAX audio output stream was present and could be re-directed to Fldigi, but not to WSJT-X. I was able to restore operation for a brief period by stopping WSJT, renaming WSJT.ini and restarting WSJT. That fix lasted for a half hour. Repeating the procedure provided operation for the rest of Field Day. The two .ini files that were renamed are available for your inspection, along with the one that continued to function. Any suggestions you can offer to prevent a recurrence would be greatly appreciated. Regards, Peter NI6E ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7Cc8a88765c47b45e54e0208d6ffea13fc%7C84df9e7fe9f640afb435%7C1%7C0%7C63698175354267sdata=QIhhN8eBXU7WkgMKIK4WOGh%2BO2Zt6d3mRyQ5qFFV%2FGM%3Dreserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-devel=02%7C01%7C%7C028b11a517d4493b190808d702496ee4%7C84df9e7fe9f640afb435%7C1%7C0%7C636980386726425860=6R6u7cKiy5Rvb2kB4AM3H0Kqd5bTbc8AM0DazKU%2B5KI%3D=0> ___ wsjt-de
Re: [wsjt-devel] WSJT Audio Input Loss
Your observations match those I have seen for about a year. I've tried to find a common set of circumstances that always cause the failure but have had no luck. I use WSJT-X in FT8 receive mode and PSKREPORTER to check band performance over a long time period. After a random amount of time, WSJT-X come to a halt. Specifically the Wide Graph Display and the Band Activity Display stop updating. The UTC in the Wide Graph Display no longer matches the UTC in the bottom left portion of the Main window. There is no correlation between the activity on the band and the time it takes to hang. Rarely does it not hang. As a software developer this has all the hallmarks of a race condition failure. Two (or more) threads update a shared resource without using a LOCK, UPDATE, UNLOCK sequence. During a thread context swap one of the threads reads the value, loses control to another thread that updates the value, then the first thread gets scheduled and writes back its stale value. The result is undefined behavior. Most of the time there is no conflict. Even under a heavy load. Then it fails unexpectedly. This makes it extremely difficult to debug. To recover I have to exit out of WSJT-X and restart it. This might not be the root cause but I would put it high on my list of the usual suspects. 73, Rick WK1P From: Peter Putnam Sent: Wednesday, July 3, 2019 3:06 PM To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] WSJT Audio Input Loss Greetings, I have been using WSJT-X quite successfully for several years during June VHF Contests. I experienced a failure of the WSJT program to accept received audio input after several hours of proper operation during the recent Field Day exercise. I'll provide a brief outline and reply with more detail, should it be needed. My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The WSJT-X software version is 2.0.1 7ddcb7. My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX" program that interfaces various applications that wish to receive the audio stream. WSJT accepts the stream and displays results on the Wide Graph and a small audio signal-strength window. Activity proceeded normally for the first three hours of Field Day, until both the Wide Graph and the audio signal-strength stopped showing any incoming audio. I can't offer any help on what might have caused the problem. It was abrupt and seemingly unrelated to any other system actions. I am unable to reproduce the problem. Several operators spent several hours speculating about what a solution might be. Program restarts and computer re-boots (time-tested favorite of generations) changed nothing. The only useful clue was that the DAX audio output stream was present and could be re-directed to Fldigi, but not to WSJT-X. I was able to restore operation for a brief period by stopping WSJT, renaming WSJT.ini and restarting WSJT. That fix lasted for a half hour. Repeating the procedure provided operation for the rest of Field Day. The two .ini files that were renamed are available for your inspection, along with the one that continued to function. Any suggestions you can offer to prevent a recurrence would be greatly appreciated. Regards, Peter NI6E ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7Cc8a88765c47b45e54e0208d6ffea13fc%7C84df9e7fe9f640afb435%7C1%7C0%7C63698175354267sdata=QIhhN8eBXU7WkgMKIK4WOGh%2BO2Zt6d3mRyQ5qFFV%2FGM%3Dreserved=0 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
