unable to switch bands

Walt - KZ1F

I was comparing performance between SSDR and XPSSDR. I decided to take a break and actually do some dxing. I can't switch bands any longer. I did something, not sure what, that caused the right hand view to go away. Eventually I figured out how to get it back and that's when I noticed I could not switch bands. If I have the pan and the slice on 10.000 (WWV) and switch to 15 mts the slice goes away and the pan stays on 30m (10.000). If I stop and restart SSDR the pan that displays is 15mts.

Commensurate with this is the spectrum display is now in spaz mode, again.  I just posted a vid up to YouTube.

Has anyone seen this on their system?

Walt
 

https://www.youtube.com/watch?v=s-mOFPn0pO8

George KF2T

Just guessing, I'd say the alternative software testing left the system in an unstable state. Have you tried a reset, including disconnecting power?

DH2ID

Walt, did you try resetting your Flex? I have not seen this behaviour before.

Larry _ NY8T

I have seen in older versions that I could not change modes until I closed all slices and then re opened one. Restarting SSDR didn't help because the same slice opened up when the software started, just a suggestion if you haven't already tried this.

Walt - KZ1F

Nope, the radio was a fresh power up.

Walt - KZ1F

factory reset? I refer you to my monologue on factory resets from yesterday.

If the radio seriously requires factory resets at this stage in the game, there is a serious issue.

Walt - KZ1F

I did discover that power off/power on does resolve the issue. However, closing and reopening SSDR didn't.  Oh yes, I am supposed to say this.

SSDR 1.4.16
Radio 1.4.16

At the point I entered this I had not powered off and powered on the radio. When you think about it, that IS rebooting the computer.

To George's point. No, it is not my code. Quite literally, with the exception of client name, the radio does not know the difference between SSDR and XPSSDR.  I didn't ssh into the radio (anyone want to know how??) and start modifying the bits. I didn't do a firmware upgrade using my software.  I was using SSDR when this occurred.

This is the first time I've seen this...I think. It just strikes me there are an awful lot of reported issues where the resolution is, if not reboot the radio, turn off all power to the radio for 60 seconds and then reboot the radio. Last I knew 1.5 was to be a clean up release. Then it was well, there would be some last min features. Those two are the antithesis  of each other. I do not think we are doing ourselves any favors by pushing FRS as hard as some are for new features. I am not offering an indictment against FRS. I am offering an indictment against the users pushing for more, faster, why isn't it done yet, sought of fever pitch. The radio is very much a closed system sitting inside a Linux OS and a TCP/IP protocol stack. At some point, it should be sufficiently bullet proof it can not wedge itself. And we, the users, need to give FRS the latitude to focus on that.

It would be really nice if Tim would say, yep, we saw that and it is fixed in 1.4.18. Cool!! Short of that, less than cool. Like I said yesterday, Microsoft got everybody desensitized to 'reboot the system' as a viable, acceptable remedy. Even to the point of spoofing it in "Web Dude vs Sales Guy" (the youtube video). It shouldn't be an acceptable remedy. rebooting is not a fix.

Steve K9ZW

It isn't really useful to post induced faults without details, including if the usual remedies corrected the fault. When you have a radio-server, network, client - all present I. Lots of hardware/software potential variations, not to mention what third party stuff is running... Well it is only if someone is super lucky having found and resolved the same situation that you'll get much help. What is excellent is posting the recipe step-by-step to reproduce the problem. Again without that it is pretty hard to diagnose. One wonders is FRS might at some point offer a utility, sort of like sysdump to create files of the state and content, along with sysinf type data, to make induced fault reporting easier? Lacking that perhaps some sort of routine form for reporting? Otherwise it is like "Name that Tune" guessing with too few notes. 73 Steve K9ZW

Walt - KZ1F

Steve, I would hope you would realize that some problems are transient in nature. That doesn't mean it's the fault of the reporter it means it's a transient problem. I opened up this issue to provide the video as flex asked people to provide videos of problems they see as opposed to just describing them and to to see if somebody else actually had seen it. It might be that people have seen it in the lab and the only way to find that out is to ask them. Starting off a response to a reported problem by calling it induced is kind of silly and kind of pedantic. I can assure every reader of this that i, in no way, fabricated this problem. That would indeed be a good trick. I do agree however it would be nice if flex with provide a utility to basically take a snapshot of the radio and and the state of smartSDR such that that combination of variables might point them in the direction of what's wrong. I disagree with your assessment of name that tune as somebody intimately familiar with the software inside the radio itself might see the description see the display of the problem and know exactly where to look for a potential bug so in fact you're wrong on your assessment of you didn't provide enough information I provided all the information that was available at the time.