Hi,
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
- 201 Posts
- 40 Reply Likes
Posted 3 years ago
- 136 Posts
- 24 Reply Likes
had been on about 4 hours. long button push. no tone.
- 612 Posts
- 137 Reply Likes
Tim - W4TME, Customer Experience Manager
- 9202 Posts
- 3562 Reply Likes
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.
- 107 Posts
- 25 Reply Likes
- 122 Posts
- 28 Reply Likes
Thanks,
- 107 Posts
- 25 Reply Likes
https://community.flexradio.com/flexr...
I suggest you downgrade, use ddutil for spe control and allow FRS to do their part in fixing the current version.
- 84 Posts
- 21 Reply Likes
- 122 Posts
- 28 Reply Likes
- 136 Posts
- 24 Reply Likes
- 72 Posts
- 42 Reply Likes
- 72 Posts
- 42 Reply Likes
- 90 Posts
- 11 Reply Likes
Tim - W4TME, Customer Experience Manager
- 9202 Posts
- 3562 Reply Likes
Tim - W4TME, Customer Experience Manager
- 9202 Posts
- 3562 Reply Likes
Tim - W4TME, Customer Experience Manager
- 9202 Posts
- 3562 Reply Likes
Tim - W4TME, Customer Experience Manager
- 9202 Posts
- 3562 Reply Likes
- 84 Posts
- 21 Reply Likes
Have any of your Alpha or Beta testers had premature terminations with 1.16 that required a long press or removal of power? Of that subset, if any, have they experienced the same issue with 2.0 Alpha or Beta?
As for my system, I ran for over a month without a stoppage and then the other day, while transmitting in WSJT-X I had a sudden stop. Yesterday I had both a radio freeze and a computer freeze in that order. There was a delay in the computer freeze of about 30 seconds. Again I was using WSJT-X but in receive only. I had not transmitted since the radio started about 30 minutes before the stop. It seems that putting the Flexcontrol at port 240 has stopped the SSDR quitting with the error related to the Flexcontrol.
I still have random issue with the USB ports not controlling the SteppIR controller and even less frequent issues with the USB ports not controlling the SPE amplifier. Disabling and enabling normally starts the process.
Best regards,
Paul
- 72 Posts
- 42 Reply Likes
Since I see this problem quite regularly, can I get a copy of the 2.0 BETA to test on my setup? If you want to really put it to the test where this problem is concerned, there are several of us here who should be included in final testing.
Thanks,
Rick, W7YP
Tim - W4TME, Customer Experience Manager
- 9202 Posts
- 3562 Reply Likes
1.) Yes, alpha team members do experience radio crashes, freezes and occasionally a "bricked" radio. This is the risk they assume by being on the alpha team. They are black box testing alpha code and by its very nature, it may have issues we did not anticipate or encounter in white box testing.
2.) Now, the $64k question. Are these incidents related to the issue that people in the field are experiencing? Honestly, we don't know for certain. This is the reason for my answer above.
This particular issue is not a systemic bug. If it was, it would have been fixed immediately because it would have been reproducible in our lab and we could have determined root cause very quickly.
To date, we have not had a radio in our lab (and we have lots of them) running 1.10.16 lockup in the manner described on the Community. If we can't catch the issue in action while debugging, then it makes determining root cause much more challenging because we have to start doing thought experiments on hypothetical possibilities how the fault might occur and then go look at that section of code to see if we see anything that might be a contributing factor.
We have tried doing in the field logging, but the crash is a seg fault, meaning that when the crash occurs, it does so in such a manner that the logging facility crashes too before we can catch a "last gasp" console feedback. Therefore we get no useful forensics from the logging we have tried.
In addition, since the crashing is really random. For example when the radio is in use or idle, whether it has been running for 10 minutes or 10 days, there is no pattern to assist in trying to zero in on the root cause. Also, we have not received any feedback from users having the problem that describes a particular set of steps or events that can reproducibly generate the failure. If we had this information, the issue can be addressed in very short order.
There is another dynamic in play here too and that is there have been a lot of reports of issues that have been lumped into this post that are not applicable. I wrote a response that differentiates other types fault behaviors from the one associated with this post. There are situations were a network issue can look like a crash, but isn't. These "false positive" reports can muddy the waters when trying to determine the root cause if the issue.
It is possible that through the process of building SmartSDR v2.0 that we have serendipitously squashed the bug that is causing the problems and 2.0 users will not experience it. We will not know for certain until we can get more data points (more people using the code) and validate that the issue has been mitigated. If this turns out to be the case, then we have something to work with, as we can look at the changes we made for 2.0 and if any look to be good candidates for a fix, we'll incorporate them into the planned 1.x maintenance release.
I also want to close with none of this hampers our desire and drive to find this bug and squash it. As hard as it may be to believe, this issue gnaws at us more than you because it is an enigma we can unravel. As noted earlier, we are seriously committed to fixing this issue.
Tim - W4TME, Customer Experience Manager
- 9202 Posts
- 3562 Reply Likes
- 639 Posts
- 89 Reply Likes
Again I apologize if this has already been done.... Just what FRS needs, is some 72 year old yeahoo looking over your shoulder.
Tim - W4TME, Customer Experience Manager
- 9202 Posts
- 3562 Reply Likes
- 72 Posts
- 42 Reply Likes
Please don't take this personally; but, if you're existing tools have yet to reproduce the problem in your lab, yet it's occurring on many customers' installations, then your tool kit is less than totally adequate. That leaves you with two options: (1) Expand your alpha/beta testing to include many of those who are frequently experiencing the problem, or (2) Look for the deficiencies in the tools and testing methods you're currently using. Especially when close to a major release, we found the first approach to be the most productive and least taxing on our own resources.
Tim - W4TME, Customer Experience Manager
- 9202 Posts
- 3562 Reply Likes
- 38 Posts
- 2 Reply Likes
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
- 72 Posts
- 42 Reply Likes
Tim - W4TME, Customer Experience Manager
- 9199 Posts
- 3559 Reply Likes
That condition indicates a crash. The other condition does not.
Eric - KE5DTO, Official Rep
- 917 Posts
- 346 Reply Likes
The latter is what indicates the firmware was not running properly. Holding the power button down for ~4 seconds performs the same shutdown as the end of the 60 sec timer.
- 72 Posts
- 42 Reply Likes
- 220 Posts
- 50 Reply Likes
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.
- 38 Posts
- 2 Reply Likes
It would be interesting to know if any radio shipped with the factory firmware version 1.10.16.xxx ever had a lockup ?
IF NOT
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
- 72 Posts
- 42 Reply Likes
- 136 Posts
- 24 Reply Likes
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.
- 107 Posts
- 25 Reply Likes
Flex 6300 1.10.16 No USB's
SPE 1.3K-FA
PALSTAR HF AUTO
- 72 Posts
- 42 Reply Likes
- 72 Posts
- 42 Reply Likes
Virtually all other crashes I saw on 1.10.16 occurred either while running some kind of digital mode or after having done so for some period of time. DAX would seem to be a contributor to this lockup problem.
- 546 Posts
- 96 Reply Likes
- 72 Posts
- 42 Reply Likes
- 72 Posts
- 42 Reply Likes
- 98 Posts
- 14 Reply Likes
Tim have you tried putting the radio in a heat chamber to see if it has any effect?(hot or cold)
- 72 Posts
- 42 Reply Likes
- 98 Posts
- 14 Reply Likes
The point is, FRS has not actually been able to reliable reproduce the issue. I am suggesting that stressing the radio might help in making the problem more frequent
As an engineer, I know the hardest problems to find, let alone solve, are the ones that happen once in a blue moon.
The problem with real time systems, it is very difficult to distinguish a FW verse a HW problem. They both act the same.
This is the type of problem I would love to work on. But I am not part of FRS so all I can do is suggest things to try.
Dave KB1WOD
- 72 Posts
- 42 Reply Likes
What I'm kicking against isn't the long delay in resolving this; instead, it's the apparent lack of commitment to fixing it right now. All that's being offered are excuses that it's something on the user's end, whether it's supposedly high latencies in the user's network/PC or something else going on in the PC.
I'm sorry, but this is a client-server architecture and NOTHING which happens on the client side should ever cause the server (radio) side to crash (segmentation fault), overwriting profiles and who knows what else. NOTHING!
When that does happen, YOU HAVE A PROBLEM IN THE SERVER (RADIO).
I totally agree with you that they're not adequately stressing the systems in their labs and that's why they're not seeing the crashes while dozens of us are. I know for a fact that they do not have any systems in their lab with an SPE Expert 1.3K-FA and DEMI 2m LDPA connected to the radio's two USB ports, as I do. I offered to help, at least with testing of SSDR 2.0 alpha/beta, but was flatly told that "the alpha testing is closed."
Who, when faced with problems like these, doesn't make an exception to do testing that they cannot do themselves? I've helped many other teams in the past and they jumped at my offer.
But not FRS!
I didn't pay nearly 10 grand for my station so that I could spend much of my time grabbing my ankles why repeating "Thou shalt not anger the FRS gods."
- 136 Posts
- 24 Reply Likes
- 136 Posts
- 24 Reply Likes
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)
- 38 Posts
- 2 Reply Likes
Here Eric answer to my question on that point .
"To clarify, there are two separate shutdown measures that the radio takes. If the radio firmware is up and running properly, a single short press of the power button should initiate a shutdown within 5-10 sec. Otherwise, there is a 60 sec timer in the power control chip that will shut things down if the firmware does not respond.
The latter is what indicates the firmware was not running properly. Holding the power button down for ~4 seconds performs the same shutdown as the end of the 60 sec timer.
- 72 Posts
- 42 Reply Likes
I hope this discussion isn't going to degrade into an argument over semantics. Whether there are different failure scenarios, which there likely are, the radio has gone down and the effect on the consumer is the same.
These must be resolved soon and every step taken to resolve it, even if it means reaching out more proactively to users like us that are seeing this regularly. They clearly haven't succeeded in recreating the operating environments that we have; otherwise, they'd be seeing these lockups in their lab. I know for a fact that they don't have my setup in their lab, which consists of a 6700 with both an SPE Expert 1.3K-FA and a DEMI 2m LDPA connected to the radio's USB ports.
If this isn't a firmware problem, then it's a hardware problem and covered under warranty. If this is a hardware problem and the incident rate is as low as they insist it to be, then try swapping out the radios of 2 or 3 people who see this problem regularly and see if it goes away. If it does, then take the hit and do warranty replacements. In the end, the cost of that could easily be much less than the sales hit for failing to act quickly.
The longer they delay, the hotter everyone gets and the more the word spreads that you might want to avoid the Signature Series for a while.
I am supposed to give a presentation on my 6700 to our local ham club in August. I'm sorely tempted to give a FULLY honest presentation.
- 451 Posts
- 45 Reply Likes
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.)
73,
Roy AC2GS
- 72 Posts
- 42 Reply Likes
As far as I've been able to determine, since the LDPA interface is via a BIT cable, the presence of that interface is not likely to be the source of the problem. The fact that we're running several slice receivers on 2m and in FM mode is likely stressing the radio differently than is the case with most of the radios in FRS' lab.
I don't know how many, if any, of their alpha/beta testers have an LDPA in their setup. I did get confirmation that FRS' lab doesn't have a radio with my setup. I've offered to help do some late testing of the SSDR 2.0 alpha/beta, but was flatly turned down.
That certainly doesn't install confidence in the level of support that we can count on.
- 451 Posts
- 45 Reply Likes
(I doubt that our mutual problems are merely coincidental.)
I doubt that it is the USB signals (my DEMI is the older one without USB controls, only the 1.3K-FA has a USB connection to my 6700).
FRS used a few technical "tricks" to get their DACs at 2M frequencies. There has been a "bug" on their list regarding 2M slices not showing a signal. I regularly select an input other than XVTR and then re-select XVTR, to get my 2M reception back. This has been documented from a very early version of SSDR and there is no cure in sight.
I think the firmware has to be very mindful of using the 2M slice and if you don't, the whole thing crashes. Since few people use their 6700 as an All-In-One there is relatively little, in the way of complaints.
There are probably other ways to crash SSDR, but using 2M FM repeater receivers seems to be my particular way.
Perhaps with this new data FRS will borrow someone's DEMI LDPA and fix this bug????????????
- 72 Posts
- 42 Reply Likes
- 759 Posts
- 164 Reply Likes
I've pretty much given up using 2m FM on my 6700. When having any other panadapters open at the same time it has difficulty changing bands on multiple panadapter with a 2m panadapter open. The lack of a good all mode squelch, constant bugs showing up when changing bands and no repeater tone suppression of receive signals pretty much keeps me off of the repeaters. I do use it for 2m SSB though there isn't much activity down there.
I have to count myself as lucky.. I've only had a few lock ups on my 6700 where I was forced to do a hard reset. Due to the COM (in-use) issue that has been around for months and still not fixed, I am still using an older version of SmartSDR.
I love my 6700, but my patience is starting to wear thin. When I purchased my rig, I knew the software was not quite complete. I had no idea I would still be plagued with these types of problems 5 years later.
I have already solved the remote operations by instituting a VPN, so I really don't need that functionality. Bugs have actually kept me from using my rig remotely. Instead I've been using an IC-7100 for remote. I just want the basic radio to work as it should and to include the basic functions nearly every other radio built in the last 20 years has. The bells and whistles should follow basic functionality and major bugs.
Just one software developer (or 2 hrs per day) dedicated to clean up and bug fixes should of been able to take care of most of these issues and would have gone a long way in keeping customers happier. Bug fixes should have been released in between normal software updates. Instead, we've had to resort to several work-a-rounds. 5 years is too long.
While I'll most likely keep my 6700 for many more years, I almost hate to admit that I'm now looking for a 2nd SDR. Next time, I won't be sold on what the rig will be able to do in the future.
- 480 Posts
- 82 Reply Likes
7 mike
- 72 Posts
- 42 Reply Likes
If FRS isn't going to match that commitment, then the least they could do for us poor suckers is to put the existing code base in the public domain and allow the two branches to compete. I think I know who will win.
It's also an insult to have to pay for "support" annually such as it is, when that 'support' takes years to add features which can readily be found in a $1000 transceiver and should have been in the Signature Series from day one.
- 63 Posts
- 26 Reply Likes
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
- 546 Posts
- 96 Reply Likes
Interesting comment about time keeping. I was having crashes on 1.10.16 and noticed my computer time was monitored by Windows Net Time. Learned Meinberg would not work if Windows Net Time was active. So turned off Windows time correction and Meinberg took over keeping my computer right on time. I use "Time.IS" in a browser to show the timing error which is typically <.01 seconds. So since switching over to Meinberg no crashes.
Question for FRS: Is there any communication between the radio and SSDR that is time stamped. If so what happens if the time stamp goes backwards?
- 451 Posts
- 45 Reply Likes
I read about the "Dimension time sync" interaction and decided to test the hypothesis for my particular problem. I uninstalled Dimension and switch back to the latest SSDR firmware with my profiles installed and my 5 2 Meter FM repeaters on the panadapter...
Five hours later, my 6700 crashed and locked up!
I'm back (once again) to my last stable firmware, and the knowledge that, at least for me, the problem is this firmware really has a problem with the "magic" involved in getting 2M operation out of the 6700.
It would have been nice if it was just all Dimension's fault, but that has not been the case for me.
Your mileage might vary.
- 93 Posts
- 18 Reply Likes
Tim - W4TME, Customer Experience Manager
- 9199 Posts
- 3558 Reply Likes
No. All time stamping is relative, not absolute so a clock that is not synced will not make any difference. And the types of things timed are the network quality metrics, nothing critical to the operation of the radio.
- 546 Posts
- 96 Reply Likes
Thanks for the clarification, so looks like we can exclude time keeping software from causing the radio to crash.
- 72 Posts
- 42 Reply Likes
I suspect that few, if any, of the radios in FRS' lab are stress-testing 2m FM mode, which is one thing that's unique about 2m support versus SSB and CW in HF modes.
In any event, I can't stress this enough: This is a CLIENT-SERVER architecture and what happens on the client side SHOULD NEVER CAUSE THE SERVER (RADIO) TO CRASH!
It's unfair to blame Dimension, network latencies, or anything else OUTSIDE of the radio for what is clearly happening INSIDE the radio.
- 31 Posts
- 8 Reply Likes
73, Frédéric, HB9CQK
- 31 Posts
- 8 Reply Likes
Mike - VE3CKO, Elmer
- 545 Posts
- 287 Reply Likes
- 90 Posts
- 11 Reply Likes
FWIW... whatever is causing the instability under 1.10.16, doesn't appear to rear its head under 1.9.13 (I have rolled between the two versions on two clients)-- or at least not @ my QTH.
- 63 Posts
- 26 Reply Likes
I should also note that when my radio crashed under the circumstances I described, there was no sound (I have heard that high-pitched tone in the past with a 6300 I used to have). Just trying to provide as much info as I can to help everyone solve the issue.
- 72 Posts
- 42 Reply Likes
- 72 Posts
- 42 Reply Likes
- 63 Posts
- 26 Reply Likes
- 1784 Posts
- 547 Reply Likes
No freezes.
I use windows 7 64bit.
Anyone with windows 7 suffering the issue? Just adding my 2 cents in a setup that doesn't suffer the problem. I use 1.10.16.
- 98 Posts
- 14 Reply Likes
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
no DAX
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.
Dave KB1WOD
- 72 Posts
- 42 Reply Likes
But correlation doesn't always equal causation and your very simple setup shows that quite conclusively. It's clear that this can happen very randomly and its quite possible that certain radios are more susceptible to it due to timing differences within each of them.
I think you're on the right track about this being a timing issue or what we frequently referred to as a "race condition." Based upon the fact that the 'true' crash, as Tim would call it, is due to a segmentation fault, the problem is either causing an attempt to execute code in an invalid memory space or code with a bad data pointer is attempting a read or write to invalid memory space.
My decades of experience doing embedded systems has educated my "gut" to suspect that this is the latter case, as I've seen far more of them than the former. The former occurs when attempting to "jump through a pointer" to a firmware routine when the pointer hasn't been properly initialized or got corrupted.
The latter often occurs in firmware/software that uses lots of string or circular buffers, where "put" and "take" pointers are being updated and used by asynchronously executing code. I can guarantee that these radios use lots of these kinds of buffers. Unless the buffer pointer manipulation routines are written with bullet-proof control over accessing of the buffers' control structures, sooner or later two asynchronous events occur which cause pointer corruption and BOOM, down she goes.
These can be quite difficult to find but I've found some in the past just by doing a very close scrutiny of the buffer access control routines and associated hardware support (e.g., "semaphores.")
Rick, W7YP
- 940 Posts
- 197 Reply Likes
BUT as Tim mentioned the logging program gets locked out also. w/o a log, it's all guess work. A useful tool in this case is the Lauterbach debugger that uses h/w regs on the CPU along with JTAG to log the full information even after the fact. I've seen some talented Engineers work with these to find strange bugs. I'm convinced one of these in the hands of a sharp person could become a modern version of "Have Gun - Will Travel" as they are expensive and not easily learned.
Another useful tool is a good source code analyzer.
---
now for some info to shed some light on the problem (doubtful)
A 6500 is in use at this station and about 4 full lock ups have been observed so far. The radio runs 24/7, mainly SWL and some CW. To test DaX interaction all 4 slices were activated with DaX, and some FLDiGI / WSJT. Even turned on a couple Dax I/Q channels with nothing attached. There was no lockup with this test case, after several days. Not very scientific but it seems plugging cables in the switch the radio runs on would eventually cause a lock but since that might take several hours this doesn't seem reasonable. Switching cables was to put Maestro on the switch and remove it. Sometimes lock was on the Win-10 machine and sometimes when using Maestro. Twice locks happened late at night when there was no activity. Placing the 6500, PC and Maestro on an independent switch and leaving cable alone and no locks observed since. This switch is very old and made to Home Theater setup.
Putting it all in perspective, this doesn't even qualify as a minor nuisance here, a minute or two to reboot and the station is back on the air.
The 6500 has been converted to 'man pack' portable operation in preparation for Field Day (along with Maestro), Will post some images if anyway would like.
Regards,.
_..--
TiM
k3Tim now portable 6
- 72 Posts
- 42 Reply Likes
My wife has an ICOM IC-7300 SDR radio ($1350) which has never malfunctioned once and has been running for many weeks on end.
I guess I expect a bit more from a radio setup that cost 7.5 times what my wife's IC-7300 did.
Rick, W7YP
- 63 Posts
- 26 Reply Likes
Eric NC6K/KH6
- 855 Posts
- 271 Reply Likes
What would you do if there was a severe electrical storm and your radio is connected and running? There's a good chance that if lighting caused your radio to start a fire your insurance company would not cover it because they would say you had no business running a ham radio (and amp, tuner, etc.) during a severe thunderstorm
KY6LA - Howard, Elmer
- 3789 Posts
- 1638 Reply Likes
Not in the slightest bit inconvenient. I am Remote far more than I am local. I am currently in France 6,500 miles from my SOCALbase. -
Remote reboot is incredibly easy. I use a couple of 8 port digital loggers web power switches which give me full remote comptrol of my station
Been running reliably Remote from 28+ countries for years
BTW. The station is on 24/7/365 but no lightning in SOCAL
OTOH if I got nervous I could always shut things down remotely
BTW. I can also raise and lower tower remotely and have cameras to watch it happen. It does have an automatic lowering mechanism with battery backup if winds exceed 25MPH.
- 63 Posts
- 26 Reply Likes
@Howard - it would be a LOT simpler to have the FlexRadio monitor some sort of watchdog timer and automatically do a hard reboot if the radio became unresponsive. After spending $7k for the 6700, not to mention all my other toys, I really don't feel the need to buy more hardware to do a remote reset, although I may if I have to. My Yaesu 5000 will run for months without locking up, and may have to go back to being my primary remote radio.
I think it's fair for Flex users to ask for reliability, regardless of why. You guys are starting to sound like the Microsoft apologists that insist users are in the wrong for complaining about Windows (which deserves many of the complaints) when they have problems with lockups, etc.
While the thread is very long, it helped me find my particular problem, and I'm on four straight days of remote operation on 6 Meters without a freeze. I even picked up a few new countries and states. So, a huge thanks to those that contributed useful suggestions and observations.
KY6LA - Howard, Elmer
- 3789 Posts
- 1638 Reply Likes
An 8port remote web power switch only cost $125. Not a big deal. It even is programmable to reboot itself on a lost internet connection.
An even more important factor is the ability to remote reboot routers,modems and switches
There are lots of reason for needing to remotely reboot radios and computers. For example software and firmware upgrades need reboots Over the years I. Have done several remote upgrades with no issues. Done 2. Already this month.
- 62 Posts
- 15 Reply Likes
73
Mike
- 63 Posts
- 26 Reply Likes
73,
NC6K
KY6LA - Howard, Elmer
- 3789 Posts
- 1638 Reply Likes
KY6LA - Howard, Elmer
- 3789 Posts
- 1638 Reply Likes
I ended up double homing my main router with a 4G connection as an alternative Internet route just in case my cable modem route failed. Used it once so far in a year.
The good thing about the data loggers is that they re programmable ...so I sett up one to control my cable modem and main router. The Data Logger pings the Internet and when it loses connection for 5+ minutes, it reboots the. Cable modem and then 5 minutes later reboots the main router. It logs the reboots .. definitely has had to reboot more than once
In one case the Cable Internet was systemically down for 24+ hours but the 4G worked
with all the redundancy that I've built into the station to eliminate single point failureI'm getting very close to 24 /7/ 365 of uptime
- 1784 Posts
- 547 Reply Likes
There are tons of things you can do for remote operation.
The way I had it setup is I placed a GSM relay to reboot the Router as last line of defense. Everything else worked with a combination of web accesible relays.
You can actually get fairly fancy but there are neat software packages out there. I really like PSTRotator which includes a couple of features that are great. You can connect it to a weather station or connected to an online accessible weather station and PSTRotator can be programmed to move your antennas to face wind direction or even lower the tower at a certain wind speed. It also has a feature to move the antennas every so often to prevent birds to loiter.
Here is some of the Gear I use:
A ton of stuff from these guys https://www.itead.cc/smart-home.html
http://www.ebay.com/itm/KMTronic-LAN-Ethernet-IP-8-channels-WEB-Relay-board-BOX/281238587222?_trksid...
http://www.ebay.com/itm/2000W-Wireless-GSM-Call-Remote-Control-Relay-Smart-Switch-Home-Security-Syst...
http://www.ebay.com/itm/LAN-Ethernet-2-Way-Relay-Board-Delay-Switch-TCP-UDP-Controller-Module-WEB-Se...
- 136 Posts
- 24 Reply Likes
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..
- 1788 Posts
- 550 Reply Likes
- 201 Posts
- 40 Reply Likes
Yes I have, It behaves the same as a short button press, which is there is a delay of around 50 seconds before the radio shuts down. Which at least lets you shut the radio down if you are operating remote.
Mike - VE3CKO, Elmer
- 552 Posts
- 289 Reply Likes
Tim - W4TME, Customer Experience Manager
- 9202 Posts
- 3562 Reply Likes
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.
Related Categories
-
SmartSDR for Windows
- 5335 Conversations
- 1639 Followers
-
FLEX-6700 Signature Series SDR
- 3133 Conversations
- 644 Followers
-
FLEX-6500 Signature Series SDR
- 3676 Conversations
- 953 Followers
-
FLEX-6300 Signature Series SDR
- 3034 Conversations
- 869 Followers