1.3.8 hyperactivity

Walt - KZ1F

When left alone (no other user input) both displays (waterfall and panadapter bandscope go into hyperdrive. It is a very active and fast jitter. the waterfall, rather than being a constant scroll has bands of unredrawn lines. What's odd is this has happened twice when I've been away from the laptop. When I've returned and noticed it, just moving the mouse seems to allow it to settle down eventually. It has happened twice since I've upgraded. I did reboot both pc and 6500.  I did have an initial issue with DAX ch 1 but after toggling between ch 1 and ch 2, channel 1 started to show audio. After the initial post it occurred again, large areas of black (unpainted lines) in the waterfal and the bandscope was jittering worse than.....well, fill in the blank. This never happened with 1.3.0 or earlier.

JB

Walt,

Many background applications launch when the CPU load gets under a certain% or when completely idle. Moving the mouse, hitting, keys, etc. would stop those processes so eventually (like you are seeing) things would return to normal.

Could be antivirus/malware check or some sort of back-up synching (Mozy, Carbonite, etc.). Could also be Windows doing background indexing or some other service. I think you are seeing the result of heavy DPCs. The fact that you are using a laptop is probably adding to the issue if it is older/slower.

Why it wasn't happening before? Lots of possibilities but it may be that Flex changed some code or streamlined some processes that result in the CPU load dropping (a good thing overall but not in this case) or some new drivers were loaded. I know there have been new drivers for NVIDA chips/cards that were released recently. That could be an issue as well.

Take a look at your update history and see what may have installed. Also look at the rev on your video drivers and the date released.

A couple of shots in the dark. Hope a few hit something that helps.

Walt - KZ1F

Thanks John, but no. This is a 1.3.8 issue. I certainly understand there are a ton of appliance operators out there that don't understand Mozy Pro, Carbonite, strong adjacent magnetic fields, Microsoft forced updates etc. I don't say that in a negative way, there are plenty of people who only have PC's for FB, Solitaire, and SSDR. They push a button, it turns on, they click SSDR and it turns on. Precisely what happens with my TV and car. I don't pretend to know how my Prius works under the hood, I press a button and it does or I make a phone call.

 I've been doing PC development since '78 and software development since '69. The only thing that changed was upgrading to 1.3.8. I noticed there was someone else responding that said he has the same symptoms since upgrading. I do not, however, see that email in this thread. In fact was I was ignoring my laptop, directly to my left, as I was typing the issue in the hyperactivity occurred again. No adjacent magnetic fields, no Carbonite, no Microsoft updates. Actually, Microsoft updates do not happen automatically on my laptop (the rest of my machines (6) are Linux. The pushes are automatic but I have to approve the application of them, except when I shut down and get the do not touch the machine message as it is shutting down.  I will have to take a closer look at the release notes to see if there is anything there over 1.3.0 that warrants not demoting my software.

I am going to hazard a guess and say there is a timing loop in the SSDR for Windows. A series of data comes in from a UDP port and, I am guessing, a Scroll event gets triggered to tell the screen update thread to paint. What is now happening, again I guess, is the scroll event is getting emitted in the software with no corresponding data from the UDP port. That is just my guess for the benefit of the folks at Flex.

It might also be related to actions taken by SSDR for Windows on a window screen saver notification, when Windows blanks out the screen. I wasn't aware that there was such a notification but perhaps there is such that the application wouldn't waste time in paint operations when there was nobody to see the output. I suppose it makes sense there was such an event in which case look at what is done when Windows sends the complimentary event that it came out of screen saver mode. Yes, that is it. As I was typing this the screen when into screen saver mode and after typing the last sentence or two, I swiped the touch pad and, sure enough, palsy.


Walt - kz1f

Keith - AE5XN

Walt,

I'm seeing this as well on my early (S/N 30) Flex 6700 with V1.3.8.  It doesn't matter if run Windows 8.1 from my bootcamp partition from a virtual machine, I see it after running V1.3.8 for about 5-10 minutes running with 4 or more panafalls open.  The only change here has been the update to V1.3.8.  It doesn't do this when reverting back to V1.3.0.

I did do the recommended removal of DC power to the rig after the V1.3.8 update and reset everything back to factory defaults via the Power + OK buttons on the front panel.  

Radio is connected to the computer with gigabit ethernet through a Netgear GS108NA 8-port gigabit switch using cat5e cable.

Computer being used here is a late 2013 Mac Pro with dual AMD FirePro D700's (6GB GDDR5 SRAM video memory each) with a single, 2.7GHz 12-core Xeon E5-2697v2 and 64GB of memory.  Again, it happens booted natively in Windows 8.1 via bootcamp, so  I don't think it's due to lack of system resources, hi hi.

Keith - AE5XN

Mike W9OJ

I had to downgrade from 1.3.8 because the panadapter was jumping up and down and the waterfall was going blank along with the panadapter activity. Running Windows 7 and nothing else. Never had the problem with earlier releases.

safetyproumb

And yes, I have experienced the same issues as described by Walt. Beyond what he described, when I went to Settings, Radio Setup, Phone tab and enabled "level meter during receive" in order to check my mic gain setting, I experienced dramatic delays in the response of the level meter. This was so unnerving, that I reverted to v1.3. None of the display issues were present with that version. I upgraded again to 1.3.8 and all the display and delayed meter response issues were there again. So now I'm back with v1.3 until I can get some resolution on this issue.

I'm hoping that this thread gets some attention because it seems that 1.3.8 has made my very adequate Dell Inspiron laptop (with v1.3) not up to the task with v1.3.8. 

Jim - N3JWE

Walt - KZ1F

Keith? Are you and Al in competition for who has the most powerful machine? hihi Keith, you realize, if you put Linux on that box you could rent time to SpaceX and NASA.

I am really resisting the urge to downgrade to 1.3.0. This is awful. I don't understand why there aren't hundreds of people saying 'me too'.

What I would ask people to do is, if they catch it, see if this happens precisely after the machine goes into screen saver mode. In other words, if you catch it just as the screen goes blank or switches to displaying you spouse or high school sweetheart or puppies and kitties, immediately bring it out of screen saver mode and if that brings about the problem then FRS knows where to look in the code first and perhaps the circumvention is to disable screen saver mode.

Walt - kz1f

Keith - AE5XN

Walt,

No competition with Al.  I've just always been one to hunt for mosquitos with a bazooka when it comes to computers, to reference an old Monty Python episode ;-).

I've reverted back to V1.3 for now.  No worries though, just snagged HC5VF on 6m SSB from EM13 using my Zero-Five 29ft. vertical and 500W, so all is well.

Keith - AE5XN

Walt - KZ1F

But you will never use more than a really small fraction of what that system has, ergo, rent out the spare capacity. You could even help medical science cure new diseases with folding@home, <- really worthy cause and, of course, help hunt for ET with SETI@home.

I have been extremely fortunate to hit the deep south pacific the last week or so, West Kiribati, New Caladonia (from McHale's Navy fame), Nauru, Antarctica, Benin, Marshall Is, ZM. I still haven't heard Norfork Is loud enough to copy or I did but wasn't strong enough for him to hear me. All this on 100 Watts. In the coming weeks or for Christmas, I will get a Elecraft KAP-500 with an Elecraft KAT-500.

I've totally **** up my left shoulder cranking my tower horizontal and vertical more times than I can count. But, while I did get the elements perfectly horizontal (see QRZ page for b4 image) I broke my 80 mtr inv V. I tuned it up on 30 and was awed with what I heard, virtually zero background noise. I want 80-30 before the cold weather sets in. So I will have to go through this exercise one more time. Can RG-8x handle 500W or should I swap to RG-8 while it's down?

George KF2T

I noticed some of this just after the latest round of Windows updates got pushed out. Not sure if they have anything to do with each other, but that's where my suspicion lies. Unfortunately, with my system, a lot has changed recently (Mac OS, WSJT-X, SSDR) so I can't precisely nail it down.

George KF2T

Get rid of that RG-8x. You'll be happy you did, especially on receive. I'm partial to RG-213 for everything, including jumpers. 

Walt - KZ1F

Hmmm, interesting George. In my case it had nothing to do with Windows or Microsoft. Whether it's early Windows API (switch from ****) where the user's program has to handle a multitude of events in one giant switch stmt or something like JavaFX8 or Windows MPF. Under the covers the same stuff happens, a user event occurs, likely in another thread, that is data on a UDP port (in this case), the program scrolls the window on pixel width and invalidates the portion scrolled away, this generates a paint even, be it WM_PAINT or OnPaint callback which then draws in that pixel depth invalidated row or column. The net result is the user sees a very smooth waterfall. If what people are seeing is due to a Windows update, every single app running, be it HRD, mini control DM-780 would show the same behavior. This is SSDR 1.3.8.

Walt - KZ1F

Hi George,
   Would you elaborate on how you came to like 213 better? I've tried to research this and get answers all over the ballpark. One guy told me RG8X melts at 900Watts, HRO has told me it can handle 1500 with no problem, another said you want RG8 for superior shielding. Is this a chocolate vs vanilla thing? But the melting at 900 and working fine at 1500 can't both be true. I wouldn't think. Any sort of insight would be greatly appreciated.
Thanks,
Walt

George KF2T

Good morning, Walt. The thing for me is the matched loss value. 213 will pass more of your signal , and more importantly the received signals back, than will RG8 or 8x. When things get mismatched, the loss in the 8x will escalate faster than the 213. Of course, power handling will be affected by mismatch, too. High SWR and high power can "melt" your line. A beefier cable will help. Nothing magic about my choice of 213, though. There are better cables, of course. LMR, hardline, etc. 213 is, for me, a sweet spot between performance and economy. In my installation, open wire is impractical, but it's also a great choice (low loss, high power) if you can install it properly. Check out the loss per meter values for various transmission lines on the Times Microwave site. It'll give you an idea of how much power is disappearing in your feeder. Even more importantly, how much received signal you're dissipating. A couple of dB isn't so bad on transmit, but it truly matters on weak signals. Your Flex has such a good receiver, it would be a shame to deprive it of every microvolt. Lastly, the quality of your cable can affect RFI and your received noise level. In today's RF rich environment, you need the best shield possible. A good cable with a high percentage of quality braid will work wonders. As an experiment, I swapped a one-foot section of 213. For 8x in my shack (between remote tuner bias tee and SWR bridge). The 8x allowed more noise in - noticeable, but not gigantic. Of course that was only 12 inches. Think of what the whole line does. Wow, I've rambled on. Hope this helps! 73

George KF2T

Gotcha, Walt. Watching it more closely, I am becoming inclined to believe there is something in 1.3.8 doing this. Only thing running under Windows here is SSDR, so it's hard to tell. Thanks for the info.

Walt - KZ1F

Update on this issue: I was on 12mtr USB and noticed while very erratic display in the band scope. I don't mean the normal behavior rather something in the -110 range jumping to -70 then immediately back to -110. ALso, on transmit, the wave form displayed in the bandscope lingers long after transmission has ended. I also notice when using the FlexControl (which I don't use much anymore) the 'reticle' keeps moving in the panadapter noticably longer than I am turning the dial. This is perhaps the same duration of the panadapter displaying the transmit waveform after I've stopped transmitting.

ai6re

I have this same problem with Hyperactivity and have uploaded a video of this happening while checking into the flex net today.  Youtube link below. Pardon the poor audio which I should have eliminated. 

http://youtu.be/lWMDLix2klQ

Don ...AI6RE

Mike W9OJ

It was much worse on my 6300 than that. 

Walt - KZ1F

I have new information on this. I discovered some things that may well be important to fellow sufferers of this as well as FRS QA.

Read my discription above for the symptoms. By going into the Windows controls for Power options and disabling the Dell Profile. The hyperactivity issue has vanished and the machine doesn't reboot by itself after some period of time. After reading someone on here complaining/discussing issues with the Flex Control I unplugged mine and things got a little more stable on the display. All the problems have not vanished but I think lag in the SWR meter and displays is still there but the hyperactivity seems to be gone. However. My display no long greys out nor does it turn off. So while the impact on SSDR is gone, SSDR shouldn't be interacting with the Power Option profile...something to look at and for those suffering what I was describing some months back, this is a circumvention, more than a fix. If this can't be resolved for 1.4, perhaps it can for 1.5. At least though there is a circumvention,

Walt - kz1f

Rick N4RZ

Walt, I am having exactly the same problem you have described above. I am running SmartSDR 1.3.8 on a Lenovo M Series machine using an I5-2400 cpu. I have played around a little with CWX but otherwise have a pretty vanilla implementation of the software.  

Walt - KZ1F

Hi Rick,
    Happy New Year and thanks for the input on our shared problem.  I think pursuing this is good as it potentially gives FRS as much anecdotal evidence as possible to narrow down the areas that may be the culprit. For instance people have said and, as I recall, upon initial upgrade to 1.3.8 I had no problem. This issue developed over time or otherwise popped into existence after some period of time using 1.3.8. Rick, anything you can recall, like it didn't happen at first, or it was fine until you set a profile or whatever comes to mind would potentially be valuable. I am running an I7 with a burst speed of 3.5GHz, 8GB of memory on a Dell XPS 15Z. Storage and CPU capacity are not an issue here. Running with SSDR is HRD log, DM780, and DDUtils. Brent, on the other hand has a similar but reversed problem and he is running a business class Xeon processor in a Dell T4800 or some such.  What he said about his Flex control being slow and lagging is, however, identical to what I reported above. The more specific people are with what may be different in how they use SSDR or what may be different about their environment would potentially help Flex root out the issue.

Thanks,
Walt -kz1f

Walt - KZ1F

This appeared to effect the manifestation of the 1.3.8 bug but now it's been a few weeks, no, it doesn't seem so. With the possible exception of the wild waterfall. To the extent it exists, which it does, it doesn't seem as bad. So if there is anything in SSDR that traps sleep events or monitor off events, that would be a place to look.

Walt - KZ1F

This is proven to be fixed with 1.4. I am sure in the preceding paragraphs I described what I viewed as the likely scenario of, upon the screen going off the UDP data for the waterfall and bandscope were queued. I suspect this was done as part of 1.3.8. I believe that is what the issue was and with 1.4 it is resolved. Usually the person opening a bug is able to close it. I don't see an option for that.