Spot display causes radio to stutter

K8AC

I'm running Maestro with a 6500, with the Maestro, 6500 and PC connected via an ethernet switch and ethernet cables.  Software at 2.4.9 on Maestro and 6500 and PC is running Win 10, 64 bit, latest level.  DXLab Commander sends spots to the Maestro and the connection between Commander and the Maestro is via TCP (SmartSDR CAT not involved).  At the moment, I'm sitting here looking at 20 SSB with 10-12 spots displayed - all that works fine.  The  problem occurs when new spots arrive from Commander.  If it's just one or two spots, I hear a distinct stutter in the radio audio (audio taken from 6500, not the Maestro).  If it's many spots, the audio is blanked for a second or two and the bandscope and waterfall freeze.  It always recovers and normal operation returns, but it happens again on the next spot update.

Jay Nation

Floyd

I "still" see the same problem when using, DXLabs suite, with Spots enabled in SmartSDR, I reported the problem to both Dave AA6YQ, and to Flexradio here in the Community. My workaround since has been to disable Spots in SmartSDR, while I wait for a new release of SmartSDR, and hope for the audio dropouts out of the radio's Lineout/PC speaker jack, to be fixed. I prefer hearing dropout free audio, over seeing spots on the panadapter.  DXLabs Spot Collector displays the spots itself, and will tune the radio to a spot that get's clicked in Spot Collector, which is how I tracked/used spots before the spots feature was added to SmartSDR.

    #FlexRadio IRC chat

For real-time discussions

        SDRgadgets

User created documentation.
           Volunteer!!

         73, Jay - NO5J

Mike-VA3MW

I just did some testing on this, but in my case, I was  using SliceMaster to send spots.  

I configured SM to send 100 spots (sh/dx/100) and I never heard a thing as the display on the Maestro was populated.

My setup is the radio, Win10PC running SM is all remote on a 100M switch, and the Maestro is local to me logged in via SmartLink.  Very basic setup.  

The Maestro has headphones plugged in and powered set of computer speakers.  If there was a blip, I couldn't hear it.

This was on 2.4.9.  

Over the summer, I had issues and even worse when running Skimmer.  The moment I replaced a LAN cable between the PC and the switch, the problem disappeared.  Put the cable back and it reoccurred.  I cut up the cable and tossed it.  Hopefully that helps some in diagnosing this.  What I had to be sure of was that I solved the problem in the right place and that fixed the symptom.  

Mike va3mw

K8AC

I'll try SliceMaster in  place of the DXLab spots and see if the symptom changes.

WF7B

I seem to remember this during the opening minutes of cqww cw. It made the radio unusable. I disabled spots from HRD and the problem went away. Later I tried again and was fine. I attributed the problem to the shear volume of spots in the opening minutes. I had no problems with cw skimmer spots.

bahillen

I had that problem too. On a big contest weekend. Computer was crushed. I tuned CPU for maximum speed. Changed BIOS CPU settings for max speed. Then added 8gb of RAM. In Task Manager RAM showed about 50% used but that is misleading because that doesn’t count the amount that is saved to the hard drive. After installing 8 GB more the amount used was at 7.5 GB and machine CPU decrease. CPU was wasting power writing to disk or memory management. An important thing I learned in web searches ant articles is that Windows is not a very good real time audio processor because to some degree how it handles interrupts. Interrupts knock holes in the audio stream. To overcome this I found you have to reduce the reasons the interrupts occur as much as possible as well as the duration of the interrupts. I got free Drive Booster to update all drivers. Video cards are valuable in removing graphic processing from main CPU. some settings slow down your processor and need to be adjusted. Get as much RAM as your computer will take. 16 GB good choice. Add Gig bit switch as router may slow you down and lose packet and network interrupts. . To save CPU turn off DAX IQ channels. If needed for Skimmer, minimize to 24000 and turn off channels not used. Finally on Spot settings window reduce settings lowers the interruptions. Close Chrome if not needed as well as other apps that are using some CPU. LatencyMon has been a tool to track progress as you reduce interrupts as outlined in Tim’s article on Flex website. Objective is to reduce frequency and interrupts duration. It also identifies which drivers are involved with the problem. See what works for you. This is about 2-3 months of work for me. 73 Bill W9JJB

Dave AA6YQ

DXLab Commander places spots on a Flex Panadapter by invoking the SmartSDR API.

If that action results in audio stutter, it is by definition a defect in SmartSDR. This behavior was reported to Flex personnel months ago by me and several other Flex users.

Jay Nation

In regard to my earlier post in this thread, the stuttering was heard out of the radio's LineOut/Speaker jack which is connected to the PC speakers on the desk. The only thing running on the PC was the DXLab's Suite, That should eliminate my PC as a source of the problem. But mYMMV. Meanwhile I'll just wait for the next SSDR release with Spots disabled.

The Stuttering didn't seem to affect any of the DAX RX audio channels, when I ran WSJT-X or Fldigi. It was only noticeable in the speaker audio. Disabling the Spots feature would stop the stuttering, as would closing the DXLab's suite.  

    #FlexRadio IRC chat

For real-time discussions

        SDRgadgets

User created documentation.
           Volunteer!!

         73, Jay - NO5J

K8AC

Just to clarify my situation: Your problem was completely different from mine.  I don't run SmartSDR on the PC - only use the Maestro.  My PC is "free breathing" - 3.5 G I7 with average utilization of 5%, 16 GB RAM, solid state drives.  My previous panadapter setup was NaP3 running with a different transceiver and using the PC for the panadapter display including a DX spot feed and never ran into any delays.  It may well be that the Maestro tablet processor is stressed while handling  a lot of spot updates at one time, but the result should not be interruption of the main functions of the transceiver.  In this case, if the updates are too much to handle, the answer is to discard them and not interfere with the basic operation of the transceiver. This is clearly a problem in how the Maestro SmartSDR is handling the situation.

Jay Nation

Dave
Correct, I reported it to Flexradio too. 
They only change/difference is the Spot's feature.
Dxlab's isn't stuttering, the radio is, but only when displaying spots.
Hopefully Flexradio will work on fixing the problem.

    #FlexRadio IRC chat

For real-time discussions

        SDRgadgets

User created documentation.
           Volunteer!!

         73, Jay - NO5J

bahillen

Has anyone submitted a help desk request for this? If it is a problem in process of investigation it would be good. Maybe a company update. My issue was added with help desk support with great exchange with Tim. May not be on the active list with all the affected users. I made great progress on my side but have thought there was something going on the Flex side too The Maestro side maybe more interrupt friendly than Windows but no way to know. It seems we are pushing the limits. As I recall it may have been sweepstakes that lit my screen up with spots everywhere on 4 band slices. My computer is a high performance box. Don’t know how Flex would have anticipated the stress placed on the processor in a major contest. Have thought about a separate computer for 3rd party software and putting spots together outside SmartSdr or Maestro. I have run SmartSDR on main computer with DAX for HRD log and DM780 and another with DAX for WSJT-C. Both computers running DAX and Slice-Master 6000. I was surprised it worked. May be a diagnostic tool to identify the problem source. 73 Bill W9JJB

EC5W

Hello. Same problem here, using H-Spot or N1MM to broadcast spots via API. Miguel,EA5GF

Jay Nation

Bill

FYI

https://community.flexradio.com/flexradio/topics/spots-studder-when-using-dxlab-with-6400-or-6600m 

Eric KE5DTO at Flexradio, added it to bug # 6651, 3 months ago.

    #FlexRadio IRC chat

For real-time discussions

        SDRgadgets

User created documentation.
           Volunteer!!

         73, Jay - NO5J

Marty Ray

Same here. 6600M with MacLoggerDX. Pops and clicks in the audio and the waterfall freezes for up to 30 seconds.

Mike-VA3MW

I don't think it is the Maestro tablet that is stressed out, or I would be able to recreate this. 

I tested a rapid push of over 100 spots and not a single blip.   I also ran CQWW with the same setup in what would be a limited bandwidth situation as the Maestro was remoted  in on 1 mb/sec upload and no hiccups.

I don't deny it is happening, but we may have to look along a broader scope.   When this is happening, what is your FPS set to and your Rate set to?  Does the problem go away if the rates are set to lesser values?

Just a thought to consider.

Andy - KU7T

Same here. I have gotten used to it by now. Not a PC issue. I can reproduce it with PC turned off, just the 6600M running. 73, Andy KU7T

K8AC

After some more experimentation with this problem, I can reproduce it at will.  It apparently has nothing to do with the volume of spots updated, but the stutter and screen freeze is prolonged with many spots coming in.  And, I've discovered that the problem occurs on the Maestro even with Spots set to disabled in the Maestro menu.  If you're a DXLab user, you can reproduce it this way: Go into Commander config, Bandspread tab.  With the Maestro tuned to your favorite band and the audio turned up, go to the "Display calls on panadaptor" box and repeatedly check the box, turning the function on and off.  On my system, each transition causes the Maestro audio to stutter and the screen to stutter and or freeze for a couple of seconds.  Even checking/unchecking the box slowly results in the stutter, telling me it probably has nothing to do with the volume of spots, but rather just the act of communicating with the spot source.

Mike VE3CKO

I would think at this point the fact that the radio is stuttering is a symptom, not a cause. Also would think it is a bit pre-mature to blame either party. If the 3rd party software is just dumping spots perhaps prolonging communication longer than necessary, then FRS would have to tighten up protocols or setup some kind of throttling setting. I'd like to see if lowering the FPS and waterfall rate helps with this. I use SliceMaster and HRD and don't experience this as yet.

K8AC

I don't believe anyone is blaming any parties, just reporting on observations regarding how the parties' products are performing.  To satisfy your curiosity, here's what I've done: on the Maestro, reduced the FPS as far as it will go.  It appears that the frame rate is about 1 per second at that point.  I've reduced the Rate as far as it will go to the left.  Movement of the waterfall is barely perceptible at that point.  Having done those things, I can go into DXLab and check/uncheck the "Display calls on panadaptor" box AND THE MAESTRO AUDIO STUTTERS 100% OF THE TIME  on a transition from on to off or off to on.  And this occurs with Spots DISABLED on the Maestro Spots menu. 

Mike VE3CKO

Interesting, that information should be useful to developers, thanks.

Dave AA6YQ

It is not premature to- identify SmartSDR as the locus of the defect. The only way to display spots on a panadaptor is by invoking the SmartSDR API. The defective behavior has been observed with 4 different applications - DXLab, H-spot, N1MM, MacLogger DX - on two different platforms - Windows, Mac. 

Over the past months, Flex has not said "we tried, but cannot replicate the behavior". They've said nothing.

K8AC

Tim just closed my ticket on the problem, explaining that the problem is due to the volume of spots being fed to the Maestro.  As I've explained elsewhere, I can duplicate this problem 100% of the time if I disable spots in Maestro, go to the Commander config bandspread tab and repeatedly turn "Display calls on panadaptor" on and off rapidly.  With each transition, the Maestro stutters.  Clearly there will be no solution forthcoming.  If anyone is interested in buying a 6500 and Maestro, drop me a line (k8ac at k8ac.net).

WF7B

I don’t have a Maestro, I still have seen the problem, seems to me the whole SmartSDR (waterfall and pan) was jittery.

K1DBO

This problem was discussed a bit on the Alpha mailing list back when the spots API was first introduced.  The issue isnt related to spots specifically, it's pretty easy to reproduce the problem.  An API client only has to send "too many" commands to the radio without waiting for a reply.  Once the "limit" has been hit, any additional commands will trigger a click in the audio.  ...or at least that's the way it was back then.  I havent done much to test if the problem still exists.  Slice Master takes care not to send "too many" commands at once.  So, for the most part, it doesnt seem to trigger the clicks.

Dave AA6YQ

Thanks, Don.

Interesting that no one from Flex noted this restriction in the API documentation, or mentioned it to developers they know have products that use the API.

Dave AA6YQ

I have modified Commander version 13.8.2 to limit the rate at which SmartSDR API commands are sent to the radio, tested it with my 6500, and sent it to four DXLab users who earlier reported the audio stutter when callsigns were being displayed on their panadapter.

Mike VE3CKO

Ah, kinda what I figured which is why I haven't yet experienced it with SliceMaster. One app talks back and forth while the other sort of shouts commands. Isn't this community great. A little give and go and within 2 days of this thread, Dave gets right on it and appears to be on the track to fix it. Nice going.

Dave AA6YQ

You think it's great that Flex released SmartSDR with a known defect (audio stuttering when the API command rate is "too high"), but didn't inform its customers? Given the reports earlier in this thread, they evidently didn't inform other developers, either.

Mike, your characterization of "one app talks back and forth while the other sort of shouts commands" is inaccurate. Commander fully complies with the SmartSDR API as documented. There is nothing in the API documentation stating that an API command should not be issued unless fewer than X previous commands are unacknowledged. It took me 10 minutes to implement this restriction, after Don K1DBO revealed its existence above - and I had to experiment with my 6500 to determine the value for X. Will the same value work with other Flex models?

Developing software that fails when the rate of incoming commands is too high is disappointing, but understandable; all developers make mistakes (though this is a particularly egregious mistake). Releasing software with a known defect without informing customers of its presence and without informing developers of a known workaround is inexcusable.