I had successfuly run my Flex 6500 on Previous full release 1.9.13 for a few months often leaving it running for 24 hrs without any lockups.
I could not use the first recent Beta release due to numerous lockups with continuous audio tone requiring a long button press to reset.
I updated tp 1.10.16 on release and was lockup free until tonight when I experienced a lockup whilst listening to the radio. Same symptoms continuous audio tone and long button press required to reset.
Anybody else have lockup issues on 1.10.16 and does flex acknowledge that the problem still exists.
Not what I really want for the WPX contest.
Regards Andy M5ZAP
had been on about 4 hours. long button push. no tone.
I want to assure you that FlexRadio takes customer issues with our products very seriously. We acknowledge that there is a problem in SmartSDR v.1.10.16 and we are committed to fixing it.
However, this issue is a low incidence problem when compared to all FLEX-6000s in operation which directly affects the rate at which we can issue a fix. Because of the low incident rate, it makes the problem much harder to duplicate, isolate and resolve. We have attempted to capture data on several units experiencing these issues without success. Whether the logging process actually affects the issue or whether the incidence rate is just too low is inconclusive.
We continue to troubleshoot this problem and as soon as we can drive it to resolution we will issue a v1.x release that provides a fix. But with incomplete forensics on the problem, it is hard to predict when this might occur.
At this time the only recommendation we can suggest is to have you revert to a release that provides a stable operating environment until a fix can be delivered.
We hear you and we are on it. Thank you.
Hi Tim, from your post on 19 april i want to clarify this:
"do a normal power off on the radio by pressing and releasing the power button. Give it a good 15-30 seconds to respond. "
If the radio shutdown after the delay without indicating that it is shutting down, is this a lockup that you want us to report ? ( On my last 4 events, my 6500 shutdown after 45, 60, 90, 60s)
73, Donald, VE2HJ
After the event, I tried other ways to connect remotely, as well as locally by WiFi/lan, using SmartSDR for iOS, etc., and the radio remained not discoverable.
The situation was remedied by a long press of the power button once and only needed a short press another time. It's possible that the long press was not needed the first time, I just did it for fun.
These "freeze-ups" only took less than an hour to occur over VPN. Last night, I ran the same radio for hours using local lan control and front-panel microphone w/powered speakers from the rear panel without any incident.
My observed version of the problem seems VPN/remote dependent.
It would be interesting to know if any radio shipped with the factory firmware version 1.10.16.xxx ever had a lockup ?
this would suggest it is not the firmware but something else. ( upgrading process, virus etc.)
So i think that we should indicate the serial no. of the radio when we report a crash.
73, Donald, VE2HJ
Upon reboot radio had 6 of 8 slices apparently randomly distributed to the 8 pans.
Yesterday radio was on about 12 hours doing cw, no issues... Nothing different between how I ran yesterday or today. Radio has default profiles.
Flex 6300 1.10.16 No USB's
PALSTAR HF AUTO
Tim have you tried putting the radio in a heat chamber to see if it has any effect?(hot or cold)
Just now running 4 wsjtx in a relatively cool room (its 73) I had a much louder tone;
The rig starts emitting the tone, I observe its not in xmit mode, so I start loading this page; After a few seconds ssdr lost comm;
I hit the rig on/off button once, and began navigating here and typing. The rig shutdown; I didnt notice if it ever said "shutting down", and it took probably a good minute.
I thought Tim had said this wasnt a crash (since the button push "worked"), but the rig wailing and being non-responsive to ssdr, sure seems to me to be a crash...
Rig had been on 1.5 hours (or however long it was from my last crash)
I reflashed to the latest 1.10.16, reset to factory default, and started my 6700 up in the default 20 meter panadapter. It ran crash free for almost a day. I then added a few more HF panadapters on 10M, 17M, and 40M.
It ran crash-free for another half a day.
I then configured the XVTR tab for my DEMI LPNA and opened a 2M panadaptor and populated it with 5 slices on five different repeater frequencies. There were 3 other panadapters open - 10M, 20M, and 40M. NO profiles were imported, or even saved. No transmissions were made - receive only.
Two odd hours later it locked up and crashed!
(Your mileage might vary.)
I went on vacation a few days ago, and by the time I arrived at my destination, the radio was offline. Fortunately, our housesitter was able to reboot the radio for me, and before that, I uninstalled Dimension. Everything has been great for two days now, and I'm still connected.
So, I realize this is simply empirical evidence, but may help those who are still having issues, at least if the cause is Dimension. It may not be the "fault" of the program, but associated with the changing PC time? A big thanks to posters in this thread that suggested it as a possible cause - it led me to removing Dimension, which appears to have fixed my problem.
73 de Eric NC6K
Here is my system:
6300 direct connect to PC. no other devices connected to computer Ethernet connector.
Del OptiPlex 740 running windows 10.( internet connection through USB WiFi dongle and wireless router)
running in CW mode.
one slice opened
Can't get much simpler.
Since the 6300 has different hardware then the 6500 and 6700, I am less likely to point the finger at the hardware.
My gut felling is this is a asynchronous timing issue in the software. such as missing a flag or missing an interrupt. something along those lines.
At my company the problem closes to the customer gets the most attention. In other words "All hands on deck!" for customer problems and everything else put on hold.
I will say one more thing:
A good reputation cost money, a bad one comes for free.
I had 4 wsjtx sessions, 1 cw skimmer.. Prior to the crash I had 8 pans, 8 slices; post crash I had 8 pans, slices A-F; F was in the last pan which had been slice H.
DAX slices also needed resetting..
Looking back over the past few weeks, the reports have not provided any additional beneficial information that we do not already have logged in the bug report. Most of the reports just describe the operating state of the radio before the crash and we have sufficient information of this nature at this point. What we have determined at this juncture is there is such a wide variability in operating setups, whether or not the radio is transmitting or receiving, the length of time the radio has been powered on, whether or not client software is connected to the radio and if USB cables are or are not used, it validates the random nature of the problem, but unfortunately gets us no closer to determining root cause.
And additional incident reports recently reported with the same type of information can not elevate the criticality of this issue since it is already at the highest level possible.
In addition, the thread has diverged into topics not related to the original poster's topic, which degrades the SNR for people looking for relative and pertinent information on the topic.
At this juncture, I am inclined to close this thread. This does not mean you cannot continue to provide useful information to FlexRadio regarding this issue. It is just that we believe the troubleshooting process would be better served off of the Community at this time.
As I stated early on if anyone has a procedure or a set of steps that reproducibly causes this type of crash to occur, we want to know about them ASAP. The best way to report the reproducible set of events that cause a crash is by opening a HelpDesk support ticket (https://helpdesk.flexradio.com).
This conversation is no longer open for comments or replies.
This conversation is no longer open for comments or replies.