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?
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.
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.
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.
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.
6500 with FlexControl knob.
Lenovo k410 with i5 and 6 gb ram.
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%
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.
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.
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
Checked the logs - no 4228 events.
I wonder if this might also tie into the oft-reported drops of DAX?
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.
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.
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.
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.