Distorted TX DAX audio

  • 4
  • Problem
  • Updated 3 days ago
  • Acknowledged
Radio Flex 6300 / SmartSDR 2.0.17 / OS Windows 10.  I have a remotehams remote that I provide to other hams.  Every couple days I have been experiencing distortion in the TX DAX audio.  A simple close of all the programs and relaunch fixes the issue.  This has been occurring with 1.9 / 1.10 and now 2.0.  Was hoping that it would washout with the newer releases.  Audio into and out of remotehams is clean.  I have just closed and launched the DAX program and the problem goes away.  See below Link with Audio of a TX with no problem and a less then a minute later it starts.

https://drive.google.com/drive/folders/0ByikFTG2iMyWcl9vMmFaMURTRGc?usp=sharing
Photo of James Skala

James Skala

  • 90 Posts
  • 17 Reply Likes

Posted 1 year ago

  • 4
Photo of Ray Andrews, K9DUR

Ray Andrews, K9DUR, Elmer

  • 243 Posts
  • 61 Reply Likes
James,

This is a known issue that has been around for some time. All you have to do is stop & re-start DAX. I hope that Flex can get a handle on it soon.

73, Ray, K9DUR
Photo of James Skala

James Skala

  • 90 Posts
  • 17 Reply Likes
UGG! Tim when will this be fixed?
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9152 Posts
  • 3478 Reply Likes
This issue is in our bug tracker as issue #2391.  I have no ETA data at this time.
(Edited)
Photo of KM4CQG

KM4CQG

  • 226 Posts
  • 37 Reply Likes
I am having the exact same problem as well.

Ian
Photo of Mike NA5U/K5D/K1N

Mike NA5U/K5D/K1N

  • 29 Posts
  • 1 Reply Like
I was told this is memory leak. There was a stab at fixing it but looks like it didn't work. It was better after the attempt but 2.0 has it back as bad as before.
73,
Mike
NA5U
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9152 Posts
  • 3478 Reply Likes
We suspect buffer corruption, not a memory leak.
Photo of Lee - N2LEE

Lee - N2LEE

  • 275 Posts
  • 143 Reply Likes
makes more sense than a memory leak now that you mention it
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9152 Posts
  • 3478 Reply Likes
This buffer corruption problem has been linked to long duration DPCs on the PC running DAX.  If this is your issue, you can try to take mitigating action to resolve the condition.

Here are some relevant HelpDesk articles on the subject.

https://helpdesk.flexradio.com/hc/en-us/articles/202118398-What-are-DPCs-and-why-do-they-matter-

https://helpdesk.flexradio.com/hc/en-us/articles/202118698-Using-LatencyMon-to-collect-DPC-Latency-D...
Photo of James Skala

James Skala

  • 87 Posts
  • 16 Reply Likes
Tim, thanks for that information.  I will run this and see what we get.  So no matter how powerful the PC or CPU usage this DPC ISR stuff could be happening in the background even thought CPU and RAM is in great shape? 

Is FlexRadio saying this is not a DAX issue but a consumer configuration / performance issue?

What about the external programs like remotehams that process audio and their audio chain has no problem while DAX is?

thanks for your hard work, really enjoying 2.0
Photo of Ray Andrews, K9DUR

Ray Andrews, K9DUR, Elmer

  • 240 Posts
  • 61 Reply Likes
Tim,

I just ran LatencyMon for about 12 minutes.  "Highest  measured interrupt to process latency" was initially 864 us and never went higher than that.  The "Highest reported DPC routine execution tims" was 442 us & came from ndis.sys.

My PC runs 24/7 & problem occurs about 24-72 hours after DAX is started, whether I am actively using DAX or not.  I have not been using it recently in order to monitor the problem, but I have created a script file that kills & re-starts both CAT & DAX when I start the SamrtSDR client.

73, Ray, K9DUR
Photo of James Skala

James Skala

  • 87 Posts
  • 16 Reply Likes
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9152 Posts
  • 3478 Reply Likes
James, DPCs are not related to how powerful the CPU is or the speed and amount of RAM.  It is about the hardware interaction (primarily drivers and the BIOS) with the operating system.

What we are saying is that the current DAX driver appears to be susceptible to issues with PCs that experience long duration DPCs.  We are investigating using a different driver technology for DAX that should provide relief from this type of situation.  


Ray - I have seen instances where LatencyMon had to run for hours to "catch" an instance of a long duration DPC.
Photo of James Skala

James Skala

  • 87 Posts
  • 16 Reply Likes
Thanks cant wait to get home to hound dog this out.
Photo of James Skala

James Skala

  • 87 Posts
  • 16 Reply Likes
_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for  5:29:42  (h:mm:ss) on all processors.

_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name:                                        DESKTOP-IT7CH92
OS version:                                           Windows 10 , 10.0, build: 15063 (x64)
Hardware:                                             M32CD_A_F_K20CD_K31CD, ASUSTeK COMPUTER INC.
CPU:                                                  GenuineIntel Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz
Logical processors:                                   4
Processor groups:                                     1
RAM:                                                  16308 MB total

_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed:                                   3696 MHz
Measured CPU speed:                                   1 MHz (approx.)
Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.
WARNING: the CPU speed that was measured is only a fraction of the CPU speed reported. Your CPUs may be throttled back due to variable speed settings and thermal issues. It is suggested that you run a utility which reports your actual CPU frequency and temperature.

_________________________________________________________________________________________________________
MEASURED INTERRUPT TO DPC LATENCIES
_________________________________________________________________________________________________________
The interrupt to DPC latency reflects the measured interval in which a DPC could execute in response to a hardware request from the moment the interrupt service routine started execution.
Highest measured interrupt to DPC latency (μs):       527.514713
Average measured interrupt to DPC latency (μs):       2.982746

_________________________________________________________________________________________________________
 REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.
Highest ISR routine execution time (μs):              43.547619
Driver with highest ISR routine execution time:       HDAudBus.sys - High Definition Audio Bus Driver, Microsoft Corporation
Highest reported total ISR routine time (%):          0.003113
Driver with highest ISR total time:                   HDAudBus.sys - High Definition Audio Bus Driver, Microsoft Corporation
Total time spent in ISRs (%)                          0.006193
ISR count (execution time <250 μs):                   1796816
ISR count (execution time 250-500 μs):                0
ISR count (execution time 500-999 μs):                0
ISR count (execution time 1000-1999 μs):              0
ISR count (execution time 2000-3999 μs):              0
ISR count (execution time >=4000 μs):                 0

_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.
Highest DPC routine execution time (μs):              375.566017
Driver with highest DPC routine execution time:       ndis.sys - Network Driver Interface Specification (NDIS), Microsoft Corporation
Highest reported total DPC routine time (%):          0.143481
Driver with highest DPC total execution time:         ndis.sys - Network Driver Interface Specification (NDIS), Microsoft Corporation
Total time spent in DPCs (%)                          0.504743
DPC count (execution time <250 μs):                   124171242
DPC count (execution time 250-500 μs):                0
DPC count (execution time 500-999 μs):                28
DPC count (execution time 1000-1999 μs):              0
DPC count (execution time 2000-3999 μs):              0
DPC count (execution time >=4000 μs):                 0

_________________________________________________________________________________________________________
 REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

Process with highest pagefault count:                 none
Total number of hard pagefaults                       0
Hard pagefault count of hardest hit process:          0
Highest hard pagefault resolution time (μs):          0.0
Total time spent in hard pagefaults (%):              0.0
Number of processes hit:                              0

_________________________________________________________________________________________________________
 PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s):                       764.454298
CPU 0 ISR highest execution time (μs):                43.547619
CPU 0 ISR total execution time (s):                   4.569197
CPU 0 ISR count:                                      1475071
CPU 0 DPC highest execution time (μs):                375.566017
CPU 0 DPC total execution time (s):                   379.468369
CPU 0 DPC count:                                      117965197
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s):                       29.986554
CPU 1 ISR highest execution time (μs):                5.339827
CPU 1 ISR total execution time (s):                   0.331346
CPU 1 ISR count:                                      321744
CPU 1 DPC highest execution time (μs):                220.524351
CPU 1 DPC total execution time (s):                   4.217557
CPU 1 DPC count:                                      1663268
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s):                       44.540662
CPU 2 ISR highest execution time (μs):                2.205087
CPU 2 ISR total execution time (s):                   0.000002
CPU 2 ISR count:                                      1
CPU 2 DPC highest execution time (μs):                182.601732
CPU 2 DPC total execution time (s):                   8.217507
CPU 2 DPC count:                                      2277722
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s):                       37.633667
CPU 3 ISR highest execution time (μs):                0.0
CPU 3 ISR total execution time (s):                   0.0
CPU 3 ISR count:                                      0
CPU 3 DPC highest execution time (μs):                114.716991
CPU 3 DPC total execution time (s):                   7.506331
CPU 3 DPC count:                                      2265083
_________________________________________________________________________________________________________
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9152 Posts
  • 3478 Reply Likes
You only ran it for 5 minutes.  Normally you have to run it while using the radio and after you experience DAX corruption for the data to be valid.
Photo of James Skala

James Skala

  • 87 Posts
  • 16 Reply Likes
5:29:42 (h:mm:ss) 5 Hours
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9152 Posts
  • 3478 Reply Likes
Whoops, missed that.  Was there an issue with DAX during that time period?
Photo of James Skala

James Skala

  • 87 Posts
  • 16 Reply Likes
Yep, so I kept it up and continue to text into dummy load via remotehams. I will perform capture again in a couple days when it occurs again
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9152 Posts
  • 3478 Reply Likes
RRR.  Thanks
Photo of James Skala

James Skala

  • 87 Posts
  • 16 Reply Likes
Had issue occur multiple times since last post see below output from latencymon on last occurrence 


_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for  2:12:08  (h:mm:ss) on all processors.

_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name:                                        DESKTOP-IT7CH92
OS version:                                           Windows 10 , 10.0, build: 15063 (x64)
Hardware:                                             M32CD_A_F_K20CD_K31CD, ASUSTeK COMPUTER INC.
CPU:                                                  GenuineIntel Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz
Logical processors:                                   4
Processor groups:                                     1
RAM:                                                  16308 MB total

_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed:                                   3696 MHz
Measured CPU speed:                                   1 MHz (approx.)
Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.
WARNING: the CPU speed that was measured is only a fraction of the CPU speed reported. Your CPUs may be throttled back due to variable speed settings and thermal issues. It is suggested that you run a utility which reports your actual CPU frequency and temperature.

_________________________________________________________________________________________________________
MEASURED INTERRUPT TO DPC LATENCIES
_________________________________________________________________________________________________________
The interrupt to DPC latency reflects the measured interval in which a DPC could execute in response to a hardware request from the moment the interrupt service routine started execution.
Highest measured interrupt to DPC latency (μs):       543.306908
Average measured interrupt to DPC latency (μs):       3.310021

_________________________________________________________________________________________________________
 REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.
Highest ISR routine execution time (μs):              34.524351
Driver with highest ISR routine execution time:       HDAudBus.sys - High Definition Audio Bus Driver, Microsoft Corporation
Highest reported total ISR routine time (%):          0.011174
Driver with highest ISR total time:                   Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation
Total time spent in ISRs (%)                          0.014343
ISR count (execution time <250 μs):                   3402540
ISR count (execution time 250-500 μs):                0
ISR count (execution time 500-999 μs):                0
ISR count (execution time 1000-1999 μs):              0
ISR count (execution time 2000-3999 μs):              0
ISR count (execution time >=4000 μs):                 0

_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.
Highest DPC routine execution time (μs):              226.984848
Driver with highest DPC routine execution time:       ndis.sys - Network Driver Interface Specification (NDIS), Microsoft Corporation
Highest reported total DPC routine time (%):          0.231901
Driver with highest DPC total execution time:         ndis.sys - Network Driver Interface Specification (NDIS), Microsoft Corporation
Total time spent in DPCs (%)                          0.723889
DPC count (execution time <250 μs):                   53943768
DPC count (execution time 250-500 μs):                0
DPC count (execution time 500-999 μs):                0
DPC count (execution time 1000-1999 μs):              0
DPC count (execution time 2000-3999 μs):              0
DPC count (execution time >=4000 μs):                 0

_________________________________________________________________________________________________________
 REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

Process with highest pagefault count:                 none
Total number of hard pagefaults                       0
Hard pagefault count of hardest hit process:          0
Highest hard pagefault resolution time (μs):          0.0
Total time spent in hard pagefaults (%):              0.0
Number of processes hit:                              0

_________________________________________________________________________________________________________
 PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s):                       387.643007
CPU 0 ISR highest execution time (μs):                34.524351
CPU 0 ISR total execution time (s):                   3.700013
CPU 0 ISR count:                                      2479622
CPU 0 DPC highest execution time (μs):                226.984848
CPU 0 DPC total execution time (s):                   221.033955
CPU 0 DPC count:                                      51501895
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s):                       16.723305
CPU 1 ISR highest execution time (μs):                6.873918
CPU 1 ISR total execution time (s):                   0.848960
CPU 1 ISR count:                                      922913
CPU 1 DPC highest execution time (μs):                73.712121
CPU 1 DPC total execution time (s):                   1.526959
CPU 1 DPC count:                                      643739
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s):                       18.518138
CPU 2 ISR highest execution time (μs):                3.058983
CPU 2 ISR total execution time (s):                   0.000010
CPU 2 ISR count:                                      5
CPU 2 DPC highest execution time (μs):                211.801948
CPU 2 DPC total execution time (s):                   3.711762
CPU 2 DPC count:                                      873541
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s):                       17.157728
CPU 3 ISR highest execution time (μs):                0.0
CPU 3 ISR total execution time (s):                   0.0
CPU 3 ISR count:                                      0
CPU 3 DPC highest execution time (μs):                55.425866
CPU 3 DPC total execution time (s):                   3.307845
CPU 3 DPC count:                                      924593
_________________________________________________________________________________________________________
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9152 Posts
  • 3478 Reply Likes
Thanks for the info.  I'll add it to the defect report.
Photo of Sergey, R5AU

Sergey, R5AU

  • 846 Posts
  • 111 Reply Likes
James !

I am operate on Win10 virtual machine and at time of switching between Host and VM some time buffer corrupted  or in case network time out it can be happened. My suggestion is to change priority of the DAX task via command    START /REALTIME DAX.EXE   with admin privileges. of course you can create a BAT file and out into the Start Menu, BTW do not forget disable initial autostart  of dax.exe
Photo of Bill W2PKY

Bill W2PKY

  • 461 Posts
  • 79 Reply Likes
I could never get DAX stable under Win10 on my ASUS Z97-A motherboard, no matter what I did with Affinity,Privileges,Priority etc. Went back to Win7 Pro and DAX is stable on the receive side but the transmit buffer becomes corrupted if SSDR is run for long periods of time, IE. overnight.
However DAX is stable on my Surface Pro 3 & 4. So it seems that Win10 has issues with certain hardware. Just my observation.
Photo of Sergey, R5AU

Sergey, R5AU

  • 846 Posts
  • 111 Reply Likes
Bill many DPC/Buffer interrupts issues are belong Power management/ACPI systems, and in some cases - ex.: LapTops can`t be solved at all (Motherboard/BIOS things) in all other cases 3 ways of solving are here:
- BOIS
- different OS management: Power settings
- drivers update, BTW with drivers not everything are clear, even native drivers for HW are not always optimal

also useful links:
https://www.sweetwater.com/sweetcare/articles/solving-dpc-latency-issues/
https://answers.microsoft.com/en-us/windows/forum/windows_10-other_settings/windows-10-high-dpc-late...
https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/high-ndissys-dpc-windows-10...
check your drivers - https://sdi-tool.org/

P.S. I have read many times issues related with ROG ASUS MB series 
(Edited)
Photo of Kevin K4VD, Elroy

Kevin K4VD, Elroy

  • 775 Posts
  • 171 Reply Likes
Wouldn't a DPC issue be a short term issue? Maybe when the system is busy handling lots of interrupts there's some sort of issue. But then when things calm down again shouldn't DAX start working again?

For instance, I listen to Disturbed in VLC and I hear a pop. Dang. But that's it. It popped and went away and all is back to normal.

Then I transmit a single tone with DAX and I see this:


That's not a pop. It doesn't clear up by itself and it probably sounds strange on the air. In fact, maybe it sounds like something from Disturbed. This is what happens to me every 24+ hours or so.

I restart DAX and get this:


Is this covered by whatever #2391 is about? As 2391 has been around at least six months and I believe the problem has been around longer is it just something that can't be fixed?

I guess there's lots of people very happy with the remote feature in the new software version. But for me, it is the same old software with pretty much all the same old issues. Almost exactly the same old issues.

73,
Kev K4VD
Photo of WH6HI - Pat

WH6HI - Pat

  • 285 Posts
  • 43 Reply Likes
Like others, I have also experienced this problem. But I still use windows 7, so the problem is not directly based on OS version. It usually happens to me when the system has been running for 4 + hours without being used. If I should use the system during that period I don't have the problem. When I do have the problem it is when I am using Dax along the digital apps that depend on Dax for audio input. So what is happening when the system is running for long periods of time not being actively used. Is the streaming audio overloading a buffer due to memory leaks. My own solution is to shut down the computer and radio when not in use. When l do this there is never a problem.
(Edited)
Photo of Mark - K9MQ

Mark - K9MQ

  • 12 Posts
  • 2 Reply Likes
Is there a way in Windows 10 that DAX can be restarted every day at a certain time?
Photo of Cedric HB9HFN

Cedric HB9HFN

  • 23 Posts
  • 13 Reply Likes
Yes. I use the windows task scheduler to restart DAX once a day. My "restart" batch looks like as following:

taskkill /f /im DAX.exe
timeout 2
start "" /min /d "C:\Program Files\FlexRadio Systems\SmartSDR v2.0.17\DAX" DAX.exe

73, Cedric HB9HFN
Photo of Greg - KØGDI

Greg - KØGDI

  • 70 Posts
  • 3 Reply Likes
Thanks for this.  I used part of this script to create my own batch file so I don't have to deal with resetting DAX everyday.
Photo of Peter K1PGV

Peter K1PGV, Elmer

  • 541 Posts
  • 315 Reply Likes
>Wouldn't a DPC issue be a short term issue

Yes. Sustained, predictable, issues are not likely to be DPC related.

Some other driver issue? Certainly. Triggered as a result of a few really long instances of ISR to DPC Latency? Maybe. But not a DPC problem as we classically discuss them here on the forum.

Peter
K1PGV
Photo of Greg - KØGDI

Greg - KØGDI

  • 70 Posts
  • 3 Reply Likes
I get the same problem using my 6700 as an APRS digipeater, stations can decode me fine for like a day until the audio starts getting distorted.  Closing DAX and reopening it fixes it.  Hope they can fix this soon.
Photo of Bob2 K2DRH

Bob2 K2DRH

  • 3 Posts
  • 1 Reply Like
Flex 6700 with ver 1.11.2, purchased at Dayton 2016
(no point in paying for a software version I can't use with a DSL internet connection).  

I had noticed that other stations that should have heard me loud and quickly (I run a big 8x7 6M array and high power) were not decoding me as often as they normally do.   This morning while working WSJT MSK144 I turned on the RX audio so the TX audio monitor would work (I don't often listen to audio when I do digital) and heard the audio stream on the monitor sounded distorted similar to being over driven (ie too much audio gain). My CW ID sounded like it had an echo and it all ran together. 

I checked the TX Stream level and it was at the normal setting, cut it back then restored it and it responded correctly on the P/CW window's level meter (I run it flat EQ, no compression in DIGU mode).  I tested it with another station and he said it also sounded distorted and was not getting decodes commensurate with the strength and frequency of my signal bursts.  Another station was SWL and said the same. 

I have three computers running DAX (I often run WSJT or N1MM off different networked computers than the Flex - sometimes I run the Flex on the Maestro), all of them had the same MSK144 TX audio distortion in the monitor when they went to DAX TX.  I then brought up N1MM and tested the voice keyer. It was horribly distorted in both the monitor and over the air on all three computers.  So I tried rebooting the SmartSDR program.  Same problem.

Since the three computers all have different instances of DAX and WSJT running (as well as use different com ports and slices to the DAX RX/TX), the only other thing in common was the radio itself,  So I did not reboot DAX, but rather power cycled the radio with the front panel switch and reconnected.  Bingo - all working normally again per the monitor.  The other stations I was testing with got solid decodes again too and one said that the over the air audio from the N1MM voice keyer was normal. I never had to stop/restart DAX on any machine.
 
I was on N0UK Ping Jockey chat at the time and noted my experience with the DAX.  I immediately got back 2 replies from other stations indicating similar problems with distorted DAX TX audio that had occurred for them.  They both said they had solved the problem by closing and reinitiating DAX.  One told me he had had the problem with previous versions of DAX and SmartSDR too. I see now that others in the community have had this problem and all seem to solve it by reinitiating DAX. My experience was different,  I had 3 instances of DAX running and shutting down the radio then rebooting it solved the problem for all three.

Hope this helps you find and solve this long standing problem.
73 de Bob K2DRH
(Edited)
Photo of Cal Spreitzer

Cal Spreitzer

  • 352 Posts
  • 64 Reply Likes
Just wanted to let Flex know this issue still happens with latest SSDR Software Version 2.1.33!    In the past 5 weeks my new 6600 has had the TX distortion several times while running WSJT-x FT8 Mode.  Closing DAX and restarting the DAX software corrects the issue.    Any updates on fixing this bug #2391???   Cal/N3CAL

Picture of Distorted TX Signal:



Picture of normal TX Signal:
Photo of Greg - KØGDI

Greg - KØGDI

  • 70 Posts
  • 3 Reply Likes
I'm still waiting on this issue to be fixed.  I had to reset DAX multiple times a day otherwise it gets distorted.  :(
Photo of NM1W

NM1W

  • 134 Posts
  • 24 Reply Likes
Yep known issue that dax gets both xmit and rcv corruption....Makes dax a pita on the 6700..   even one dax stream cant avoid corruption after a period of time... Clearly its not something flex is interested in addressing... 
Photo of Bill -VA3WTB

Bill -VA3WTB

  • 3002 Posts
  • 660 Reply Likes
Why is it clearly something they don't want to address?
Photo of Bob2 K2DRH

Bob2 K2DRH

  • 3 Posts
  • 1 Reply Like
Like NM1W says Its not only TX.  I notice that after a few hours of monitoring FT8 on 6M the traces from received stations in WSJT-X wide graph get fuzzy and distorted and cease to decode.  Closing then restarting DAX corrects this and they decode again.  Really is a PITA and should not happen .. why is this so hard to fix?
Photo of Bill W2PKY

Bill W2PKY

  • 461 Posts
  • 79 Reply Likes
Hello Bob2-

I have the Asus Z97A I7-4790 board that will not run DAX [receive] reliably on Win10; However, just fine on Win7 Pro. The transmit buffer does get corrupted if the radio runs for 24 hours or more.

My two Surface Pro tablets will run DAX [receive] just fine on Win10 Pro. Have not checked for the transmit buffer issue on the Surfaces. 

So it seems the receive problem may be hardware related, at least in my case. Any chance you can try a different computer or go back to Win7?

This have been discussed many times before. 
Photo of Bob2 K2DRH

Bob2 K2DRH

  • 3 Posts
  • 1 Reply Like

Yes I see that it has Bill TU. 

I've also discussed it with other Flex owners outside these forums.  Tried it on 3 computers with similar results all Win10.  I do leave my radio and computers both on for extended periods to monitor 6M FT8 when I am not in the shack and now understand that not rebooting for days at a time probably contributes to the problem.   

Photo of Bill Hickey

Bill Hickey

  • 5 Posts
  • 0 Reply Likes
I've had the problem just as described for years with my 6700's and even when I had a 5000.  I believe that I've always run Win7 Pro, even with the 5000.  I leave the radios on 24/7.
Photo of KM4CQG

KM4CQG

  • 226 Posts
  • 37 Reply Likes
I had this problem for a very long time and on occasion it still occurs.

I found the best thing in my case was not to allow Dax or Cat to auto load that has stopped most of the issue. But on occasion Dax will get corrupt and i just close Dax and restart it and i am fixed.

This issues has went on for years look up Dax corruption.

Ian
Km4cqg
Photo of HB9CQK

HB9CQK

  • 25 Posts
  • 6 Reply Likes
We have to differentiate the TX from the RX DAX corruption issue! The thread title indicates TX only while several users are reporting RX issues. I have had RX DAX corruption issues for several years. Just like Ian reports it comes, goes away, but comes back again.

I had an intense support session with Neil from FlexRadio support on this issue. We started with getting rid of DPC's (I had DPC's caused by the nvidia grafics drivers) but that did not help at all. I updated all the drivers and the BIOS - still the same. The PC is a fast ASUS ROG with 7th generation i7 and 32 GB of memory. Processing power is not an issue. I can DEFINITELY influence the occurrence (it happens between several times a day to once a week) by disconecting/connecting USB devices. I got rid of a creative USB sound blaster that I used to interface my IC-7800 with. Things improved, but DAX corruption is still there. I am still in the debugging process. It is very difficult to say if a measure helps or not because it may take a long time for the problem to show again.

I attached two pictures to show you what I see as RX DAX corruption: On the first picture FT8 waterfall traces become fuzzy and the spectrum looks like it went through a low pass filter. Nothing gets decoded in that state. The second pictures is a comparison between my FLEX-6700 and my IC-7800. on 20m FT8. You can see that the waterfall traces on the 6700 become fuzzy, while the IC-7800 is OK.

When I reset DAX (I use the batch file from Cédric, HB9HFN) all is fine, until corruption occurs again. If you have any hints on what else I could try (short of a complete Windows 10 clean install) please let us know! This issue has cost me countless hours.

Thank you very much and 73, Frédéric, HB9CQK



(Edited)
Photo of Asher - K0AU

Asher - K0AU

  • 174 Posts
  • 21 Reply Likes
Is Issue #2391 still open on 2.4.9? Finally upgraded to 2.x and may have seen it again. (Clean 2.4.9 install on Windows 10 with all the latest updates)
Photo of Cal Spreitzer

Cal Spreitzer

  • 352 Posts
  • 64 Reply Likes
I still see the issue on 2.4.9 occasionally.  It has NOT been resolved.

Cal/N3CAL
Photo of James Skala

James Skala

  • 90 Posts
  • 17 Reply Likes
Yes it still exists. I wish it would get fixed!