Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
Need the latest SmartSDR, Power Genius, Tuner Genius and Antenna Genius Software?
SmartSDR v3.8.19 and the SmartSDR v3.8.19 Release Notes | SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
SmartSDR v1.12.1 and the SmartSDR v1.12.1 Release Notes
Power Genius XL Utility v3.8.8 and the Power Genius XL Release Notes v3.8.8
Tuner Genius XL Utility v1.2.11 and the Tuner Genius XL Release Notes v1.2.11
Antenna Genius Utility v4.1.8
SmartSDR v3.8.19 and the SmartSDR v3.8.19 Release Notes | SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
SmartSDR v1.12.1 and the SmartSDR v1.12.1 Release Notes
Power Genius XL Utility v3.8.8 and the Power Genius XL Release Notes v3.8.8
Tuner Genius XL Utility v1.2.11 and the Tuner Genius XL Release Notes v1.2.11
Antenna Genius Utility v4.1.8
If you are having a problem, please refer to the product documentation or check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
6300, 7 weeks old, SSDR v1.5.1, Dirty transmit all modes on cold start, fine on re-start
Douglas Maxwell
Member ✭✭
Why when engineering say they have found a fix for this "firmware startup temperature related interface calibration bug" don't we get a SSDR v1.5.x release instead of v1.6 minor release with a whole load of other unassociated contesting related functionality? There seems to be an unacceptable delay (>4 weeks) in getting this known firmware fix to the customer. A firmware interface timing related bug in a product should be top priority and an easy fix for any competent firmware engineer. The way in which this fix is being delayed by waiting for other functionality shows not only poor customer service, but poor engineering practice as no doubt more faults will be introduced. The issue here is massive, if a timing constraint is missing or maladjusted in the firmware, it presents a ticking temperature related timebomb where each time you alter the firmware you roll the dice as to whether several hundred of your products in the field will stop working. This is currently where the 6300 firmware development is. The question to the 6300 customer is (and to quote dirty Harry) "do you feel lucky punk?". Instead let's force Flex to take a breath and stabilise the basics like interface timing before moving on.
1
Answers
-
Perhaps because the intermediate fix is to simply leave the radio powered up 24-7 after the restart. The only thing that ever gets turned off in my shack are the lights when I go to bed.0
-
We are talking about a very complicated radio in the Flex. there is not anyone on this board that knows as much about it as they do, nothing is done without good reason. As far as customer support it is next to non and a bar for all the industry.1
-
No I don't accept this temporary fix. I don't think that expecting to be able to turn the radio off at night and for it to work on first power up in the morning is unreasonable. Further than that, the radio does not inform the user that calibration has failed and spurious broadband qrm is evident on SSDR. This is as serious as faults get and other spectrum users should not have to put up with it. Flexradio's reputation is in the balance here and I'm not sure they are taking this seriously enough.0
-
This is not my experience. Everyone that has SSDR v1.5.1 in a 6300 is a potential QRM generator. The correct action would be to make a general announcement of failure and advise users of corrective action. To my knowledge this has not been done for v1.5.1.1
-
Flexradio's reputation is in the balance here and I'm not sure they are taking this seriously enough……
Perhaps for you and quite the overly broad statement. My 6.3 tx has been rock solid, clean and reliable. Zero issues. Would I be disappointed if it were not. Why sure but zero reason to over react and hyperventilate. Like others, I think FRS cares substantially about the quality of their product and to suggest otherwise is irresponsible. If I had to leave my rig on or press a button more than once as a temporary fix while waiting for a quality permanent solution, I think I could manage. Looking forward to contest focused v1.6, but would even possibly consider postponing that till v1.7 but am tired of squeaky wheels always getting the grease in life.2 -
Why drop a **** in the wee hours Sunday during the night when FRS is closed?
Have they responded to your Help Ticket or other requests? You did make them, right?
Have they actually told you hold your pants until 1.6 is out?
Back in the pre-general release days my station configuration (my 6700 is #11) did some bad stuff and they sent me a patch, which was not a general release otherwise. You had to ask.
As to make broad claims that a new version will mess things up worse, that is pure bad attitude hanging out.
Unfortunately we've grown to expect this sort of childish the shy is falling ranting on eHam, but at least there there is an ignore.
Call Flex tomorrow, and please report what they personal tell you.
/[pet peeve rant off]
73
Steve K9ZW5 -
The reputation of Flex is already very solid, I don't believe this problem with the 6300 is going to make or break them, they know what it is and have been making changes in the code. Writing this code is very complicated. This is the reason very few can do it. Most people who have followed Flex knows how they do things. Each part of the code they change effects other things, I expect that is the reason for not doing a minor release and finishing this upcoming release with all they have planed for it. Then there is testing to do. Being a Flex owner one can not rush things, just wait till releases come out.
1 -
As somebody who is also experiencing this issue, I found the easiest solution was to downgrade to 1.4 until the problem with 1.5x is fixed. From previous posts I understand that Douglas was advised not to do that by FRS (not sure why). It is a bit of a pain as I did find the full-duplex and RTTY options quite useful and I have also got a fairly useless ThumbDV but I am happy to wait (not too long though) as everything else still works fine with 1.4.
1 -
Is someone saying Flex has poor customer service?
Are they serious?
1 -
I have to agree with the poster of this topic. Although I think many functions can be held off to a major release, I believe when there are bugs that have an impact on fundamental function, safety or reliability, a minor point release is needed.
I dont think anyone disputes the excellent customers service or the complexity of the product but they are the manufacturer of the product so complexity is relative and good customer service is all a matter of perspective. In this instance I think Flex should be more vigilant in dealing with this specific issue.3 -
And with that I believe all that could be said, has been said. Doug, if you haven't already, give FRS a call and discuss your concerns.0
-
Depends what the minor release is and what it effects. If this is something that other parts of the code rely on than a point release may set them back several more weeks. Customer service in the past has always been first rate. I tend to believe if it must wait till the next big release then there must be very good reasons for it. That's all I will comment on this, I don't have the inside scoop. Interesting to note, it's always the same few guys taking Flex to task even knowing a problem is being worked on.1
-
What is REALLY needed here is some input from FRS, and not a lot of gas from FRS customers who have nothing critical to say about the company.
@Bill - "it's always the same few guys taking Flex to task even knowing a problem is being worked on". The OP has 18 posts and I doubt that he fits into that category. If I were he, I would be very upset with your generalisation. Most of the posts in this thread seem to be, for want of a better phrase, "FRS fanboys" who cannot bear to hear a bad word said about the company.
5 -
Douglas,
I entirely disagree with your observations. As an F6300 owner who does in fact suffer from this bug my level of concern is 0.1 out of 10. Yes I know it will get fixed, yes I could downgrade to previous release in the meantime, yes I could just hit reset and try again. All of these are reasonable temporary fixes in the short term.
Any good engineer would not issue a firmware fix as a **** kneejerk reaction for such a minor bug. I have every confidence that it will get sorted soon, so why all the fuss?
ps. did you not appreciate that the Flex F6 family is a constant "work-in-progress" and will be in a state of flux for some time whilst they are pushing the boundaries of what's possible? I have to ask why you purchased one? If in doubt downgrade it to legacy radio with its very limited functions.
Steve G1XOW
2 -
Simple fix.. first I had a 6300 and has ZERO issues after the 1.5.1 version came out, however to fix the issue simply revert/downgrade back to the 1.4.16 version and wait... With any SDR (SOFTWARE defined radio) you are going to come across bugs from time to time, even the almighty Microsoft, apple, linux, HPUX, etc have bugs.. hence the reason they have "patches" on a fairly regular basis..
Good Luck3 -
Not only patches on a regular basis but 'hotfixes' for urgent matters. I am not in a position to say how urgent the OP's issue is.
2 -
It appears to be that time when Tim should intervene and close this thread to further...um, comments.1
-
What again? My case has been closed twice so far by FRS. Me.... I'm still sitting here with a 6300 that has a temperature related bug in the firmware and a promise that it is going to be fixed at some convienient unknown point in the future. In my book that's poor customer service.1
-
I have no faith in any firmware version produced so far. The fact that one version is more stable than another is down to pure luck during the firmware build process. This is why Flex must concentrate more on constraining their firmware design and interpreting the timing analysis results than adding more functionality.0
-
Doug... I have made the same complaint on this board for the exact issue your dealing with. However the "Fan Boys" are here in droves. Any complaint against flex will come with swift and harsh, and some times, ridiculous criticisms by a small few - even those few are good guys at heart.
I have been officially informed as part of MY case that it is fixed in the upcoming version 1.6. I can say Flex communication is very good none the less.
However, I agree with your point that this specific issue because of its nature should be giving a higher priority with a one off fix - JUST for this issue. All other issues I have are not consistent enough nor do they impact my ability to use the products fundementals as intended. I am NOT looking forward to all the other rumored enhancements that are coming. My only must have is having a rig that works in a consistent manner.3 -
Apparent broadband emissions from the 6300 is not a minor bug in my book, YMMV. Lots of people non the wiser using linear amplifiers causing mayhem especially on data modes where its harder to detect. No indication to the user that something is wrong.... Yep really serious and a good reason for concern.1
-
Referring back to the OP:
Why when engineering say they have found a fix for this "firmware startup temperature related interface calibration bug" don't we get a SSDR v1.5.x release instead of v1.6 minor release with a whole load of other unassociated contesting related functionality?
Most of our customers not only buy our radios for the world class performance they get with the radio today, they also buy our radios knowing that a key part of our value proposition is the ongoing features we continue to add to the radio over time. We choose the features with customer input and market input and will continue to add new features to the radio because that's "what we do." At the time that this issue was discovered, we asked all customers with the problem to let us know and we worked with those customers to isolate the issue and produce a fix. v1.6 was looming on the horizon and our internal date that we expected a public release was ~11/15/15. We carefully weighed the cost of having the engineers stop work on that release to prepare a follow-on v1.5 release (the incremental effort of just producing a release). In the decision are all the "usual factors" including the cost of making the release, the percentage of customers reporting the problem, the severity of the issue, the differential in time of a specific release to fix the problem vs. waiting for the next release and the efficacy of any known work-arounds. Ultimately this is a judgment call and we made the call to include the fix in v1.6. By doing so, we are able to provide more value to our customers because engineering work is not diverted, but the decision might have gone another way depending on any of the factors I mentioned.
There seems to be an unacceptable delay (>4 weeks) in getting this known firmware fix to the customer.
Again this is a judgment call and depends on the factors I mentioned. It was expected that we would have a release out in 2-3 weeks at the time we found and fixed the issue (internally, anyway), but it has grown slightly beyond this. If there were no work-arounds, the story would be much different. You already know one work-around, the other is to simply revert to the prior release and skip the one with the problem.
A firmware interface timing related bug in a product should be top priority and an easy fix for any competent firmware engineer.
It would be fun to debate this, but I'm going to resist that temptation. Instead, I'll provide an apposite quote from another movie, "Things may appear simple in the cubicle at CIA, but in the middle of the Atlantic with Soviet warships bearing down on us, they get more complex."
The way in which this fix is being delayed by waiting for other functionality shows not only poor customer service, but poor engineering practice as no doubt more faults will be introduced.
I would like to think that we've done a good job showing our customers that we are more than willing to "press the big red button" and drop everything to service particular customer needs when the time is right. It was a judgment call, but we felt like this was not one of those times. We could of course "press the big red button" any time something comes up, but this would greatly diminish what we are able to achieve as an organization. We strive to strike a balance that pleases our customers and feels like "the right thing to do." We do wrestle with the decisions internally and I sleep every night knowing that we make these decisions with good information and the best interests of our customers in mind.
The issue here is massive, if a timing constraint is missing or maladjusted in the firmware, it presents a ticking temperature related timebomb where each time you alter the firmware you roll the dice as to whether several hundred of your products in the field will stop working. This is currently where the 6300 firmware development is.
First, I disagree with your characterization. We have a two-level scale for ranking issues. The first is the severity -- that is how bad is the problem. If it causes a crash or a fault that makes the radio non functional, it gets a "severity 1" assignment. If it is a misspelling on a help panel, it gets a "severity 4" assignment. After this, it gets a priority assignment that speaks to how quickly we fix a problem. If a third party product connects to the radio and causes a "severity 1" issue, but there are only two know customers of the third party product and they have work-arounds, the issue will not get a high priority even though the problem itself is judged severe. We then use these two factors to schedule work -- what gets done first. We occasionally have internal and external customers question our decision and the decisions are almost never reversed after everyone talks through them. This tells me that we generally make good decisions. Everyone is not going to agree with every decision we make, though. This particular issue has been fixed -- we had customers that reported the issue test our change for the problem and universally agree that it is solved. In this case, the question is not whether we will fix this issue, it is when we will release the fix.
The question to the 6300 customer is (and to quote dirty Harry) "do you feel lucky punk?". Instead let's force Flex to take a breath and stabilise the basics like interface timing before moving on.
I think you'll find that we are very responsive to direct customer concerns -- that is when you call our support line or enter a help desk ticket and discuss your problem (as evidenced by other comments in this thread). An alternate approach to a post like this might have been to appeal to our customer support team and comment "I'm concerned that the fix for this is taking too long and might cause customers issues that should be corrected sooner. Is there any way you would consider releasing a fix earlier since v1.6 has not yet been released to the field?" We (engineering team) regularly discuss issues that we might otherwise feel are not severe because our customer team has brought them to our attention with an explanation for why we need to handle a particular issue in a certain way, time frame, etc. Said another way, in all the excitement of creating a new release we (engineering) sometimes forget if we've fixed five or six defects. Our customer advocacy team is excellent about reminding us. The process we have works well and if it didn't, I think the plurality of responses you see in this community would have a different tenor.
Having said this, when a post like this is made, we convene a team of 6-8 people to discuss not only the post, but how we got to the situation where the post was made. In a sense, the actual post and the concern of the post are less important than whether there is a "process hole" or something that should be changed that "got us here in the first place." This is not to say we are disinterested in the problem, but rather we are more interested in being sure that we are able to continually address issues before they become a serious customer problems. In this case, we did not find a hole in our process. We can't always know the future in decision making and have to make decisions based on predicted outcomes -- in this case the likely release date for v1.6.22 -
My friend also has a 6300 using v1.5.1 with zero issues. This is the most worrying part for me, the interface in question is obviously on a timing knife edge at around room temperatures. My take on this is that dependent on your hardware's PVT corners (component batch dependent) the 6300 will either cold start properly or not. The fact that this issue comes and goes from firmware version to version means the firmware isn't constrained properly. Let's hope this is nailed now and doesn't disappear through adding new features and implementation luck only to come back at a later date after more development.0
-
Thanks to the OP for voicing his concerns and thanks to Steve for a sincere and open response.2
-
I second that, with the following observation. What I find is incredibly unhelpful is the, "swift and harsh" response from those people who's only intent is to shout down the person who opened the thread. Such reaction general adds no value and served no purpose but to inflame an already inflamed situation. The net of this being both the author and FRS are put on the defensive. This not only does the author a disservice but results in a huge disservice to the mgmt of FRS. These food fights serve no purpose but potentially turn off prospective customers. Bullying the op with the problem doesn't solve the problem, it makes a bigger problem.1
-
First of all thanks for taking the time to personally respond to the OP. The first hole in your process starts with closing logged issues before the fix has been released. You may be confident you have fixed the issue, but please allow time for the customer to see the fix before closing their issue. The second hole in your process was not informing me of a known "good" firmware version to down grade to, instead of just informing me it would be fixed. The third hole in your process is consideration to other spectrum users. Can you qualify to other spectrum users why your company feels it efficient to hold a known cure to tx qrm in your 6300 products while waiting for your other developments? The above comments are for your company and to do with what they see fit. They are meant in a truthfull and positive manner that is hard to express in discussion posts. As you will know from my case history this isn't the only issue I've had with my 6300 and explains the added frustration with this product.... more than the "fanboys" will know. I hope that my reports and pictures to your engineers show I mean well. I am overjoyed that you may have found this issue and look forward to being able to use the 6300 with a degree of confidence.1
-
Bob... you have not properly grasped the gist of the conversation and have added no value with that comment. Please keep watching the blinking light on your computer.2
-
It is worth pointing out the community (and Doug) knew of FRS workaround weeks ago:
https://community.flexradio.com/flexradio/topics/bad-transmit-signal
73
Steve K9ZW
3 -
Rick is electricity free where you live?
0 -
Bob the term you used for the people of Japan is derogatory. WWII ended in 1945
1
Leave a Comment
Categories
- All Categories
- 289 Community Topics
- 2.1K New Ideas
- 530 The Flea Market
- 7.5K Software
- 6K SmartSDR for Windows
- 146 SmartSDR for Maestro and M models
- 359 SmartSDR for Mac
- 249 SmartSDR for iOS
- 230 SmartSDR CAT
- 172 DAX
- 352 SmartSDR API
- 8.7K Radios and Accessories
- 7K FLEX-6000 Signature Series
- 20 FLEX-8000 Signature Series
- 841 Maestro
- 43 FlexControl
- 847 FLEX Series (Legacy) Radios
- 793 Genius Products
- 415 Power Genius XL Amplifier
- 277 Tuner Genius XL
- 101 Antenna Genius
- 243 Shack Infrastructure
- 166 Networking
- 404 Remote Operation (SmartLink)
- 130 Contesting
- 630 Peripherals & Station Integration
- 125 Amateur Radio Interests
- 869 Third-Party Software