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
Posted 2 years ago
Tim - W4TME, Customer Experience Manager
There have been several requests for FlexRadio to provide an update on this issue. The issue being addressed here is the random and occasional freezing of the radio, sometimes with an audio tone, other times without, that requires a press and hold of the radio's power button to recover.
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.
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.
Tim, We know FRS is on it. Thanks for the update. Keep up the GREAT work. "Your friend and Comrade" James Skala KY4JLS
My Flex 6700 is under two years old. I would like to return it for one that does not lockup under warranty. The older software will not run my Expert 2K off the USB ports on the Flex. How do I go about getting a replacement unit that works as advertised???
Thanks,
Thanks,
See Official response.
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.
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.
Tim - Can you say if there are any Alpha or Beta testers that have been having the quitting issue with 1.16, that are now using your prerelease of 2.0, and if they are experiencing the same problems? I know you have a Do Not Comment policy, but in this case I wonder if you can share any issues that are carried over from version 1 to version 2 related to the sudden stop issue.
Sorry, but I did not buy this radio to go backwards. I have been fighting this for a very long time. I believe this problem is much more common than they admit. I have at least three (3) other friends in the Columbia area having the same issue and have never made a comment about it. I certainly hope the release of V2.??? corrects this very serious lockup issue.
I wish they would address the DAX corruption as well..
It would be helpful if everyone who has seen a radio lockup on 1.10.X releases would post that fact to this forum; and, if you have friends who've experienced it, ask them to post the details as well. We need to document that this isn't a rare event, as I strongly suspect it isn't. I know that problems often go unreported for various reasons; however, failing to report isn't helping yourself OR the larger FRS community. Remember: It's the squeaky wheel that gets the grease.
(Edited)
Just made it to 72 hours of continuous operation on 1.10.15. 3.5 days is the longest I managed to do previously on 1.10.16. Keep your fingers crossed.
Havent had a lockup incident in 5weeks and counting...
Tim - W4TME, Customer Experience Manager
David Livingston - as noted the issue is a software problem and not a hardware issue so returning it is not covered under the hardware warranty. Downgrading is a temporary recommendation until we can definitively determine the root cause of the issue.
Tim - W4TME, Customer Experience Manager
Paul - it is difficult to answer your question because the sample sizes are vastly different and there aren't enough data points to accurately extrapolate the data, but empirically, the 2.0 code we are currently testing does seem to have a lower incident rate.
Tim - W4TME, Customer Experience Manager
Rick - Your suggestion to have everyone who has experienced a problem to post they are having it isn't going to accelerate the process. What we need is a reproducible set of events or actions that cause a problem. That is constructive feedback we can use to fix the problem. Reports without constructive feedback are just complaints and we are already aware of the issue as noted above.
(Edited)
Tim - W4TME, Customer Experience Manager
N1MW - Resolving the DAX issues is also high on our fix list too.
Tim -Thanks for the reply but I am not asking for a statistically accurate answer. Many of us on this board have either owned companies or worked with companies that have had hardware/software issues that were difficult to track down and we all appreciate the difficulty if the issue is not easily reproducible.
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
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
Tim,
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
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
Paul, Any answer to your question may be misinterpreted, so let me try to explain it in detail.
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.
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.
(Edited)
Tim - W4TME, Customer Experience Manager
Rick - I am afraid that Alpha releases are not available for public distribution.
Tim - I apologize if this has been mentioned before, back in the day, we use to find very intermittent bugs (sometimes called race conditions) by running timing margins and voltage margins...
Again I apologize if this has already been done.... Just what FRS needs, is some 72 year old yeahoo looking over your shoulder.
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
No problem. We have a variety of tools to help identify these types of issues.
Tim,
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.
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
Thanks for your feedback. We'll take it under consideration.
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
It has always taken my 6700 roughly a minute to shut down following a crash and, so far, it has always eventually reported "Shutting down" on its display. Only a couple of times have I had to do the long push and hold on the on/off button to shut it down.
(Edited)
Tim - W4TME, Customer Experience Manager
Only a couple of times have I had to do the long push and hold on the on/off button to shut it down.
That condition indicates a crash. The other condition does not.
That condition indicates a crash. The other condition does not.
Eric - KE5DTO, Official Rep
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.
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.
I think it's fair to say that to, most people, once the radio becomes unresponsive to SmartSDR and will not reconnect, it has "crashed", especially when most of the time a corrupt profile is the 'parting gift'.
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
It might also be informative to find out, from those experiencing the problem on 1.10.16 after upgrading to it, whether they had reset to factory defaults BEFORE doing the upgrade, as well as what version they were running before they upgraded to 1.10.16.
Lockup occurred on a freshly rebooted PC and Radio about 10 mins into reboot. But this time the lockup occurred while TX'ing. The TX was locked up even with not connection to radio. Red TX was on the power button, tried to reconnect to radio by relauching the SmartSDR but radio was not listed. Short button power did not turn off radio. Long button power off required.
Flex 6300 1.10.16 No USB's
SPE 1.3K-FA
PALSTAR HF AUTO
Flex 6300 1.10.16 No USB's
SPE 1.3K-FA
PALSTAR HF AUTO
(Edited)
Welcome to the club. I've been experimenting with 1.10.15 for the past 8 days and it's been far more stable on my radio than was 1.10.16. If you decide to give it a try, be sure to reset your radio to factory defaults on 1.10.16 BEFORE doing the back-rev to 1.10.15.
After several days running without a radio lockup on 1.10.15, but only doing SSB or CW, I fired up WSJT -X to see if DAX might be a factor in precipitating the radio crash. 2.5 hours later, I had my answer. SSDR had lost connection to the radio and the radio had to be restarted, restored to factory defaults and my profiles reloaded.
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.
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.
I have been running 1.10.16 w/DAX but only 4 channels active. Will activate the remainding channels to see if problems return.
It may well have nothing to do with DAX. After this morning's crash, I restarted the radio, forced factory defaults and then reloaded my profiles. Did nothing more with the radio but it crashed while idling within 20 minutes. The profile I loaded was newly created 9 days ago, right after a reset to factory defaults. Then it was saved.
(Edited)
Well, DAX crashed during the night and took my PC down with it. The 6700 appeared to be alive because a single, brief push immediately put it into "Shutting down." When I rebooted the PC, it crashed again while DAX was loading. Went into safe mode and uninstalled 1.10.15 BETA. leaving FlexVSP still installed. System booted normally after that. Will reinstall 1.10.16.174 and try not to think about how much money I've paid for all of these delightful experiences.
Just had a lock up with long button reset. Been a long while since I have had a lock up (months). BTW it is almost 90 degrees here today.
Tim have you tried putting the radio in a heat chamber to see if it has any effect?(hot or cold)
Tim have you tried putting the radio in a heat chamber to see if it has any effect?(hot or cold)
Dave, my 6700 is in a temperature-controlled room, kept to 70F year-round.
Rick,
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
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
I hear you, Dave. I'm an old EE who's done decades of embedded systems development, most of it designing data networking equipment. These are hard problems to solve.
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."
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."
Banner night; I now can state there are at least two levels of tone; Earlier had a more subdued not as loud grocky kind of tone..
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)
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)
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.
Sure sounds like a "crash" to me. I think what Tim was trying to say is that a "crash" to them is a case of the radio going down due to a segmentation fault.
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.
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.
Here are the results of a little experimentation with my 6700.
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
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
I find that very interesting, Roy, as all of my crashes have occurred since I updated to 1.10.16 while also adding the DEMI 2m LPDA and an SPE Expert 1.3K-FA into the picture. I have run for 4 days with that setup, but only one time. Most of the time the radio would crash in less than 24 hours.
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.
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.
I have the exact same setup - 6700, DEMI LDPA, Expert 1.3K-FA!
(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????????????
(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????????????
Considering its relatively low cost, FRS should buy one or two of the LDPAs for their lab.
As far as I know, the 6700 is the only rig that can use the LDPA on native 2m. The 6700 is now 5 years old and I doubt there is much interest in fixing the problems. I also doubt there will be another Flex rig in the near future with 2m built in.
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.
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.
Will think twice before any more $$ for Flex from me for any of its products with so many bugs, & lockups with my Flex6700
7 mike
7 mike
(Edited)
Norm, your points are 100% spot on. I also have an ANAN-100D SDR transceiver that's been rock solid from day one, and the operating software (PowerSDR) and firmware for it have been entirely maintained and enhanced by open source volunteers. These inspired contributors continue to enhance and maintain that code base at an impressive rate.
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.
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.
I have (at least in my case with Flex 6700 and latest SmartSDR version) confirmed that the Dimension time sync program was the cause of my problems. I've never had an issue even with many other programs in use (multiple instances of JT programs, HRD, etc.), and was using SPTimeSync successfully. Two weeks ago, I was on a business trip to Europe, and operated remotely for the entire week with no lockups, etc. The radio was still fine when I got home. Then, I installed Dimension for time synchronization since it's automatic, and experienced a bunch of lockups when I was home. The radio looked fine (display had no errors and the usual info on it), but SmartSDR had lost connection, and the only way to fix was to hold the power button until it powered down (occasionally with an error message), and then restart the radio.
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
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
Eric-
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?
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?
Well, I am open to new ideas.
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.
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.
No dimension running and have had lockup with tone on 2 6500s and a 6700 just running one slice on SSB.
Tim - W4TME, Customer Experience Manager
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?
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.
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.
Tim-
Thanks for the clarification, so looks like we can exclude time keeping software from causing the radio to crash.
Thanks for the clarification, so looks like we can exclude time keeping software from causing the radio to crash.
No Dimension here, either; however, I also have the DEMI LDPA and run a panadapter with several slice repeaters covering our local VHF repeaters. Never saw the crash before I added the LDPA, but that may simply be due to the fact that I was running 1.9 before I added the LDPA and had to upgrade to 1.10 to get the necessary support for the LDPA.
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.
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.
Hi Rick, I could not agree more with you regarding the client should never be able to crash the radio. I think FRS support is not playing a blame game here. My understanding is that they are desperately looking for a "reliable" trigger that causes the radios to crash, so they can find a way to fix it on the radio side. My "long button press recovery crashes" ALL happened without any USB connections to the radio, but with many active slices using JTDX with my 6700. I used several different time synch programs - does not make a difference. I use IP ports to contol the slices, no virtual COM ports The last 10 days or so I have not had a crash, but I am using the radio differently: My shack is 33C (do not ask me for F - it is too warm for me!), so I use the WLAN and run SINGLE slices with JTDX and my MacBook. Only a few crash free days however does not mean that this really makes a difference. I am not surprised that the beta gave you troubles. For me this was worse than the release version.
73, Frédéric, HB9CQK
73, Frédéric, HB9CQK
(Edited)
Oh, I forgot: I never used 2m with my 6700!
Mike - VE3CKO, Elmer
My 6700 is still crashing occasionally and I have not yet removed Dimensions. Will try that. I use BKTimeSync by IZ2BKT
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.
Just wanted to add that I don't have the GPS option, nor was I using 2 M/transverter. I also want to be clear that I am NOT blaming Dimension, but another day has passed successfully with no crashes, which tells me that something about the combination of my setup with Dimension is likely the root cause of my crashes.
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.
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.
Kevin, 1.9.13 seems to be stable for those that have rolled back to it. That's what I was running without any crashes. Then I added the DEMI 2m LDPA and SPE Expert 1.3K-FA to the picture, both connected to the 6700 via its 2 USB ports. Support for those accessories required an update to 1.10, and that's when things began to unravel for me.
Eric, are you running Windows or IOS? If Windows, what version and release?
Windows 10 Home v1607 release 14383.1198
I have the 6700, 1.3k, 2m DEMI amp and 70cm demi xvtr. Using both USB ports, one has the demi the other a hub for the 2 1.3k CATs and 1 ThumbDV for dstar.
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.
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.
(Edited)
I don't think the peripheral concerns at the cause of any crashes per se.
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
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
Dave, I agree with you 100% that peripheral concerns aren't the cause of the problem. Some things on the client side may change the timing of events within the radio, which ultimately precipitates the crash within the radio. A number of things can produce that timing difference, easily leading to the belief that this NTP routine or that GPS time sync routine, or network latency or whatever is the 'trigger.'
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
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
Any modern OS worth it's salt would `catch' a memory pointer dereference to nonexistent memory or other bad actions such as divide by zero. I was debugging a Android based camera a couple weeks back and a div/0 was caught, logged and the stack dump (ie. core dump for the OT'ers) unwound to show exactly the line of source code causing the fault.
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
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
Tim, maybe if you saw 4 lockups in a day, during QSOs, etc., you'd consider it more than a "minor nuisance'. But then, maybe you have the patience of Job.
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
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
Agree with Rick - try a simple reboot if you're 3000 miles from your home QTH on a business trip or vacation, and there's no one at the house to reset the radio. How inconvenient would that be?
Eric NC6K/KH6
Eric NC6K/KH6
I would NEVER leave a radio on when no one is at home and I'm 3000 miles away.
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
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
(Edited)
KY6LA - Howard, Elmer
@Eric
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.
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.
@Pat - San Diego in summertime has about 0% chance of lightning. Tower is cranked down to 25' in case of winds, and SteppIR can be retracted to minimize area. There is a housesitter, but she's not there to reboot my radio every time it locks up, although she's nice enough to do it if I ask. I've operated remotely for years (since it was possible), and not really worried about it. We had a hot water pipe burst in a bathroom last weekend when all were home, and in the five minutes it took me to run downstairs and shut off the water, we had $30k+ in damage, so being home didn't help there (yes, I know that's irrelevant to the discussion). Also, remote contest stations operate multiple HP stations with no one there - why can't I have my home station OTA while I'm away for a few days to a week?
@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.
@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
@Eric]
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.
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.
Hi Howard, could you please share the brand / model. Most interested as I am preparing my station for remote access. I have a 6500, SPE 1,3K Amp and a Green Heron rotator. Any assistance would be welcome.
73
Mike
73
Mike
Thanks, Howard. That is very helpful to know. I use Chrome Remote Desktop, which is a very low-tech, but surprisingly reliable solution for access to all my radio/work PCs. I will message you privately about the h/w.
73,
NC6K
73,
NC6K
KY6LA - Howard, Elmer
Yes. You are correct
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
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
I also advice you to take a look at https://domoticz.com/
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...
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...
Have any of you tried to turn off the radio bridging the contacts on the Rem On RCA in the back of the radio after a crash?
Hi,
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.
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
I have not tried this yet, thanks Andy. Does it behave the same as a long button press (5 seconds) ?
Tim - W4TME, Customer Experience Manager
