Unhandled error on Band Change

Mickey N4MB

On 30m, CW, clicked on Band => 40m, SmartSDR gave this error, then the error below that, then terminated SmartSDR. SmartSDR had been on 30m for 8 hours or so... I suppose this means "I don't want to go to 40m" Hope this helps... Click on OK and I got a bigger error box:

Tim - W4TME

What radio model are you using? At the time of the band change, how many panadapters and slices were open?

Mickey N4MB

FLEX-6500 One panadapter, one slice. I had left the rig on 30m, then went back, changed bands, it occurred immediately when I clicked 40. Mickey N4MB

Tim - W4TME

OK. Has it happened more than once?

Mickey N4MB

> Has it happened more than once? I've had a couple of crashes, but this is the first where I've captured the messages. I don't expect a team of programmers to start working on this immediately, :-), I'm just supplying info that might be pertinent in the event this is a larger problem, or in the event others see it. If there's a core file or a log you'd like me to save in the event it does happen again, I'd be happy to do so. No expectation of action, as long as it doesn't do it in the middle of a contest or when I'm chasing rare DX. Platform - AMD 6 core, Windows 7 x64. Mickey N4MB

Tim - W4TME

Got it. Thanks for the info. I can write this up now as a defect for additional investigation. Thanks for the report.

Eric-KE5DTO

I tried to reproduce this just now and wasn't able to get it to happen. I suspect it may be a result of some configuration difference other than just changing bands. If you can home in on anything in particular that seems to correlate to the crash, please let us know. Thanks for reporting this.

Tom-KJ4QDZ

I've had it (the error) twice in the past 2 days using a 6500. The last instance I had one panadapter and 2 slices open, set up in split mode SSB. Then changed bands from 17m to 10m and BAM! I had just changed from 20m to 17m only minutes before with no error.

Sergey R5AU

I can report following issues including current topic: my setup: Win7 64, F6700, Gig Ethernet with CAT6 cables, running applciations: CatSSDR, SSDR, DDUtil, MDLX or HRD, 2k-fa manager; 1. in version 1.0 i have get Unhandled error 2 times and can't recognised with any specific manipulation with radio setup or application, this error message appear after SSDR lost connection to the radio, where radio are not appear on SSDR start page. After several attempts to start SSDR and i get message : Connection to the radio lost, and i have recieved unhandled error message. Recovery - reboot radio 2. On this moment i have noted two cases what are crossing with #1: in case i got "lost radio", i push power button on radio - radio restarting completely and then switching off 3. Switch off with power button: i have not recognised dependencies, but, radio switch off with power button takes a different time from 5sec till 30-40sec, firstly i think regarding sifferent stages with GPSDO but for now after many attempts i have no clue with any setup behind 4. Just note regarding SSDR GUI: Menu ANT, in case moving slider GAIN, her cloud with number of the gain appeared behind "LOOP A" and "LOOP B" buttons

Tim - W4TME

Thanks for the detailed procedure for reproducing the defect.

Matt-KD5FGE

Your item number 4 has been fixed in the next release. Thank you for the feedback!

Mickey N4MB

More info... Same error, multiple times. This time CW on 30m for more than 8 hours (left on) on 30m at about 10.108, CW mode, ATU tuned, two slice receivers on a single display, tuned about 1kHz apart, Speaker muted, headphones active, clicked on Band, then 10M. Rig changed band, but displayed first error, OK, then the 2nd error. OK, then "SmartSDR has stopped working" click "Close Program" Attempts to reproduce it have failed, but slice RX disappears on band changes. No, I don't see the <A or anything, must click on +RX to get it a new one.

Eric-KE5DTO

We are completely the overhauling the band button behavior in order to implement band related persistence in SmartSDR v1.1. I suspect between those changes and the stability of the antenna switching we have made recently should address this issue. Time will tell. Stay tuned.