Flex 6700 times out after running for a while

Ernest - W4EG

The last several days, my Flex 6700 has developed what I consider to be an anomaly. I turn the unit on and after a while the radio GUI disappears. I then receive the following message.

 
 
I click okay (above) the radio GUI reappears; it works for a while. Then the same thing happens again,
Before this occurred, I used to leave the radio and computer on for days; with no issues.
Using v1.3.8 - computer I7 quad core - 8gb of memory - All of MS latest updates. No internet issues, since the radio is connected directly to the modem. 
I have not try to reinstall v1.3.8 to see if that would cure the problem. Or should wait for the new SmartSDR revision?
Only thing that changed; is that with my current moving plans. I have taken my towers mounted antennas down and currently using  a 18-HT vertical: Which has being working well for several years.
Any idea why this is occurring?

Mike NN9DD

Make sure you have your power setting in the control panel set to performance and to not shut down the Internet card. Mine started experiencing the same last week and it was the card being shut off. Changed the setting all has been well Mike N9DFD

Steve W6SDM

From my experience, I think you should look at the network as well.  There are a number of things that could cause it to kick the radio, or any other client, off the network.  Does your radio have a dedicated IP on your LAN?

N7BCP

I've been battling radio disconnects for some time and I can tell you that high cpu load can cause it. I have an i7 quad core with eight gig of ram and with four pans displaying wide the radio will disconnect after a few minutes. The water falls start to show black gaps when the cpu load is too high to support smartsdr. Perhaps a recent update has affected your video or NIC driver performance. I've also disabled the TCP offloading features on my NIC which has reduced the radio disconnects I'd like to see SmartSDR continue to maintain the connection without giving up even if this means a gap in RX while there is a laps in network connectivity or a momentary resource issue instead of giving up. The video streaming apps I use can automatically recover from these situations, the video freezes for a moment and then resumes without restarting the app.

Ernest - W4EG

Steve,
I believe that it is dedicated since this just started happening. And the IP address in the radio it's the same since I place it in operation. 
I have not added any new software or changes, except for the MS updates that are done automatically.

Kevin LaFata

I had the same issue a few times over the last several days as well. Similarly to Ernest, prior to that, I could leave the radio running for long periods of time with no issues at all. In my case, it's a 6300. Yesterday is was happening almost every time I tried to use SmartSDR. I had rebooted the computer, and tried both a direct connect to the radio, as well as going through the LAN. 

Later in the afternoon, everything was working great again and has been since.

The computer didn't seem slow at the time, but I didn't check the process utilization or network connections. If I see it happen again, that will be the first thing I'll pull up. 

I'm wondering if some background process was running at the time, and/or there was a heavy load on the network during that time frame. The computer also runs Cabonite (online backup), which can sometimes be a resource hog.

Steve K9ZW

I had issues like this which in my case resolved themselves when I replaced a very inexpensive router with a little Cisco gigabit Smart Switch (SG-200-08 in my case) unit. 

Seemed my inexpensive unit was just not up to actual performance standards and would partially drop connections.  Replacing the router also cured some on/off printer and streaming audio issues, so it was a wider win than just sorting my SmartSDR to Radio problem.

I'm wondering if there is a list of wire and wireless routers that have been successful for Flex-6x00/SmartSDR operations?  Or a list of ones that don't work very good?

Ditto lists on NICs and wireless adapters could be useful.

73

Steve

K9ZW

Steve W6SDM

Looks like you got the easy stuff out of the way.  I still get disconnects too - not very often but it does happen every couple of days when leaving everything up and running.  I am using a quad core i7 with 16 GB of RAM and a solid state drive running Windows 7 Ultimate.  The system should be robust enough.  I also have a Netgear Nighthawk dual band gigabit router with the radio plugged directly into the router, so it's not a weak network connection either.

Best that I can figure is that the network does some auditing of clients and occasionally kicks one out.  Maybe all of the other clients that I have hooked up are better at reconnecting than the Flex is.  That would be a good question for some of the network engineers.

Ken - NM9P

I have been getting the same. Also have the condition that when the monitor "times out" and goes to sleep, the display seems to go on "hold." When I move the mouse and wake it up, the panafall goes into fast forward mode until it catches up. If I am away from the station a much longer time, it acts as if the panafall buffer has gotten full and has no other resources and disconnects the rig. I havee also had the rig disconnect when changing profiles. Rig/shack: 6500 with FlexControl knob. Lenovo k410 with i5 and 6 gb ram. Win8.1 Rig and computer connected to TP-Link metal case gigabit switch, then to UVerse router and Internet. I have been running the memory stack program along with the rig, and ACLog, FLDigi, and k9dur voice keyer all at the same time. CPU load has always been below 50%

George KF2T

Add me to the "this started recently" list. Annoying. 1.3.8 had been running pretty well up to this point. I notice I can prompt a disconnect when switching global profiles and attempting to change a value (power slider, filter, etc.) right away. Related to network traffic? Maybe. I am running a GigE network, with assigned IPs, and only a switch between my 6500 and computer. SSDR 1.4 is on the horizon - perhaps it will help.

PS - checked and found my adapter Power Management setting had changed to "Allow the computer to turn off this device." (Control Panel - Network & Internet - Change Adapter Settings - (double click appropriate adapter) - Properties - Configure - Power Management) It's only a few menus deep... Not sure if it will help, but will see.

Ernest - W4EG

Let me answer all your suggestions on this message:

Radio was left on overnight.  

No stoppage for the last 15 hours.

The computer is dedicated to the radio and occasional web browsing.

The latency is less than 15 percent; which was the highest seeing so far.

No wirelesses are in use at this time in conjunction with the radio.

The radio is connected directly to a Netgear N600 modem/router.

Last video update was several months ago.

I 'm using SSD and Win7/64 with automatic updates.

George "Annoying" is not the word I like to use but it's frustrating: Every time the error message appears. I have to shut the blue I/O switch and turn the power supply off too.

Neil K2NF

You may want to open up the Windows event viewer , select Administrative Events, and look in the event list for TCP/IP event ID 4228.This is a warning event that usually indicates some process is hogging or backing up packets on the Ethernet Network Interface on the system and that Windows may be losing packets.  If these events are showing up every time the connection is dropped, it may be an indicator that SSDR cannot deal with the packet drops and instead self-terminates. Some apps are designed to deal with short term packet loss without terminating, others are not. Dont know how SSDR would respond if this is occurring. Ideally an engineer from Flex will comment on this if they have seen it before

Also, make sure that you have run FULL virus and malware scans on your system with updated definitions. There are some pretty insidious viruses out at this time which escape detection by most  real time virus protection, especially that provided by Microsoft.  Some of these are capable of randomly tying up Ethernet ports which then can result in other processes terminating if those processes  cannot deal with the packet congestion

Realize these are long shots but may provide some additional direction

George KF2T

Good ideas, Neil. Yes, it does seem like short term packet loss causing SSDR to glitch is what we're seeing. I've seen the "Client connected from x.x.x.x" message when I "almost" had a disconnect. 


Checked the logs - no 4228 events.

I wonder if this might also tie into the oft-reported drops of DAX? 

Neil K2NF

Very good chance considering that DAX follows a server model. Unfortunately, I don't think SSDR writes an error log either locally or to the Application log in Windows Event Viewer nor does it have a user accessible debug mode so its difficult to make the association. In any case, I do remember Tim ( W4TME ) once mentioning on this site that the Lan version of SSDR would require a router / switch that did not drop packets. As such, it would appear that SSDR may have a known sensitivity to these types of packet congestion / drop events. 

Bill Roberts

For whatever it's worth, I've been getting the same error message and SSDR termination. Running a 3 month old Dell I7, Windows 8.1 64, 12 GB drive and a Dlink GB router. My 6300 ran fine for the first new months. The unexpected terminations are a recent development. Wonder if it's a Windows update?

Mike NN9DD

For me it start after 1.38 was already installed and running correctly. My bet is a change from a windows or driver update Mike N9DFD

Ernest - W4EG

Neil,
checked the Event viewer and did not see the 4228 error. However, saw 23,525 on the list; going back to 2013.

 

I must add; I have no ideas what they are or mean! 
Some may be related to HRD v6.8 but HRD was not running when the error were occurring. The only software running SmartSDR, Win/7 and Outlook.
 

Ernest - W4EG

I have only seeing this once; yesterday (2 Dec 15).

k3Tim

New Flex 6500 user here...  Was NOT seeing this problem at first.  The 6500 is connected to PC on a dedicated Ethernet that can run to 2.0Gb.  The adapter had been set to half-duplex, 100 mbps.  When changed to auto-negotiate, the link established full-duplex 1Gb, at which point the TOs stated happening, albeit very occasionally.  Setting the network adapter back to half-duplex @ 100 mb and problem has NOT occurred ( > 24 hours burn time). 

Off Topic Note:
Using the 6500 in a warm-up to ARRL RTTY Roundup has been a blast!  Some stations were right on top of each other but between the 6500 and FlDigi, contacts were easily made with them.

Regards All,

K3Tim

George KF2T

Somewhat inclined to agree with N9DFD. 1.38 has been running well for a while here, and all of the sudden a bunch of us are having a similar issue. 

Did un-install SSDR and scrubbed the system of all the CAT and DAX devices/ports. Restarted and ran my registry cleaner to catch stragglers. Did a "by the book" re-install of SSDR. Been running for a couple of hours straight with FLdigi, logger, etc., all going strong. No glitches. 

Perhaps a fine Windows "Update" changed a setting or overwrote something that messed with the Flex. Regardless, it seems very stable now (just like it used to be!).

FWIW, I was pretty amazed to see the amount of network traffic DAX uses. Wow. SSDR with a nice fast panadater and waterfall, running full screen - 0.5 Mbps. DAX with one active pair - 3.2 Mbps! I can sure understand the admonition not to rely on DAX for remote audio. 

Appetite whetted for 1.4. Broke down and bought myself a Windows 8 tablet for Christmas just to play remote without having to leave my power-hungry Mac Pro on.

Reg

The source of the problem could be "Patch Tuesday"

A common theme in this thread is that SmartSDR 1.3.8 was running fine and now it has started disconnecting on a regular basis.  Microsoft releases patches on a regular basis, the second Tuesday of each month.  IT administrators call it Patch Tuesday, or worse.  Microsoft will rarely push an emergency patch out of cycle and the normal routine is Patch Tuesday.  A number of patches in the recent past have rolled back drivers to the version originally distributed with that version of Windows.  In our world this is a big problem if they roll back an Intel video driver to a version before September 2013 and we are using Intel embedded video.  It is entirely possible that this newly emerged issue arises from Patch Tuesday on December 9 or November 11.  Microsoft may have modified or rolled back some portion of the LAN drivers on our machines.

An obvious thing to do is check the MANUFACTURER'S WEBSITE to see if there is a newer driver for the LAN adapter in our machines.  We can't rely on Microsoft Update to deliver a current version of drivers.

Microsoft used to publish considerable detail about security threat patches.  At some point they decided that this practice provided useful information to the hackers and they no longer publish the details.

If driver updates fix the problem please share your results.  Together we can solve this.

Reg