Windows Power Options Display Off causes loss on waterfall history in SSDR v1.3.8

Ron Parsons

New to SSDR v1.3.8, when Windows Power Options Control Panel turns the display off, the history of the waterafall is mostly lost during the off time. This did not happen with SSDR v1.3.0. 

Most of the waterfall during the off time is black with occasional line of color. A screen shot is available.

Using Windows 7 Home Premium SP1 x64. Flex 6300.

Tim - W4TME

I have entered this problem report into our bug tracker for additional investigation. Thank you for the defect report.

Eric-KE5DTO

I suspect that the issue is not with the display setting, but rather with the network settings.  If the radio is going into a standby or sleep state, it will not be accepting the packets of data from the radio that contain the waterfall information.  Note that the waterfall information is collected in the SmartSDR application whether the application is visible or not.  This is what allows the ability to look back in time.

You might take another look at the Power Options and look carefully at any Sleep/Hibernate/Standby kind of settings.

Ron Parsons

Nothing was changed in my system from before install of SSDR v1.3.8 last evening until now. Settings are:
Turn off display 60 min - briefly set to 15 min for testing, now back at 60 min
Computer sleep/hibernate - Never
Power Plan -  High Performance.

This did not happen before the install of v1.3.8 last evening. I have been monitoring an external noise source and would routinely find the display off and would move the mouse to turn them on. With v1.3.0, the waterfall history would be complete. 

Is there another setting I should check?

Ron Parsons

This morning when I discovered the problem, the display off time was 60 min, I changed only that to 15 min and waited. After the display went off, the gap in the waterfall was there.
Ron

Eric-KE5DTO

Is it possible that the Panadapter was not tuned where you were expecting it to collect data and thus it had no data for that frequency?  I don't know.  I'm reaching for straws here.

From a technical perspective, the radio has no knowledge that the computer has any kind of power saving mode, so it is just going to keep sending the waterfall packets barring that you close the Panadapter (or the whole program).  This leads me to think about what might happen on the client that would prevent receipt of these packets.

One way to isolate whether the OS is no longer accepting those packets would be to download and install Wireshark and run that while the monitor gets turned off.  Then you could check to see whether the expected packets show up.  If they don't make it into Wireshark, then SmartSDR is never seeing them.  This is a little bit like taking out your soldering iron and your scope in the software world, so if this is more than you want to get into, I will understand.

Eric-KE5DTO

Does it happen if you just manually turn off the display while SmartSDR is running?

Ron Parsons

Manually turning off the monitor does not cause loss of waterfall memory.
I set the "turn off display" time to 5 min. 

I installed Wireshark and ran it through a monitor "timeout." When I moved the mouse about 40 secs after the timeout and scrolled back through the packet list, there was no gap.

When the monitors timeout, they go to black, and then a message "entering power save mode" briefly appears on the two monitors. I tried moving SSDR from one monitor to the other but the waterfall gap still happened.

Would it make sense to revert to SSDR v1.3.0? If so, how should one go about it?

Ron

 

Ron Parsons

Eric,

Note that it is not a complete blackout of the waterfall history. I have a screenshot of the gap. Can I email that to you?

Ron

Ron Parsons

Eric,

Note that it is not a complete blackout of the waterfall history. I have a screenshot of the gap. Can I email that to you?

Ron

Bill -VA3WTB

Eric It's up to you what you would do, but I would not revert back. They fixed a lot of things to just throw them away.

Eric-KE5DTO

Ron,

You can go back by just running the SmartSDR v1.3.0 application.  It will require you to go through the update (in this case, actually a downgrade) process.  It's not problem to go back and forth for this kind of A/B comparisons.

Given what you've already told me, I have entered additional information into our defect tracking system and we will look into it.  If you find that this was a new behavior with v1.3.8, please let me know as I will want to add this to the system as well.  Thanks.

Ron Parsons

I did the 1.3.8 to 1.3.0 downgrade, tested the waterfall, did the 1.3.0 to 1.3.8 upgrade and tested again.

Out of abundance of caution, I changed no system parameters except the "turn off display time". I also powered off the 6300 and unplugged the power between steps.

After downgrading to 1.3.0 and letting the system run until the monitors powered off, I waited a couple minutes, then moved the mouse to turn the monitors on. The waterfall did not lose any data while the monitors were off.

After upgrading to 1.3.8 and letting the system run until the monitors powered off, I waited a couple minutes, then moved the mouse to turn the monitors on. The waterfall DID lose data while the monitors were off.

Screen shots are available. So this IS NEW behavior with v1.3.8.

Ron

Eric-KE5DTO

Thanks for taking the time to verify this.  I'll add this info to our issue tracking as this will make it easier to isolate the issue.