SmartSDR v3.4.24 and the SmartSDR v3.4.24 Release Notes | SmartSDR v2.9.2 and the SmartSDR v2.9.2 Release Notes
SmartSDR v1.12.1 and the SmartSDR v1.12.1 Release Notes
Power Genius XL Utility v3.7.32 and the Power Genius XL Release Notes v3.7.32
Tuner Genius XL Utility v1.1.16 and the Tuner Genius XL Release Notes v1.1.16
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
I propose you guys switch programming models away from time and feature boxed to something more akin to CD (continuous delivery). What this requires is smaller chunks, smaller stories. Maybe not all of some large feature makes it into one 'sprint' (unit of delivery). The output of a sprint is a shippable product. What the customer sees is predictability and consistency, both important. Instead of a release that 'escapes' with 6 new features perhaps not all ready for prime time, at 3 weeks or at 4 week something is available and what that is is totally ready for prime time. Just from the first paragraph of 6-14 I count 6 defined features in 1.4. As a rhetorical question, rather than blowing a 3 month window waiting to get 6 features passable, would it be better to consistently release 1-2 features fully baked every month, a 3 week sprint and 1 week to 'harden' with very targeted tightly focused limited end user (with QA) testing. Again, the goal being consistency in delivery, quality, focus and if a given 'feature' or task is not ready, it doesn't ship but the rest of what is ready does.
This is where the industry has gone. It doesn't mean FRS has to. I just think it should.
The reference to escaped is this. There is a belief among some in this industry, software isn't released, it escapes. It's good to see an Insider again.
Walt - kz1f
Stu Phillips - K6TU Member ✭✭FlexRadio already runs an agile process with pull through based on prioritized delivery.
I love this idea. It seems no matter how carefully software is scrutinized during the beta process, something always falls through the cracks and changes need to be made. There is no better beta tester than the users. As each single enhancement is added it could be much more thoroughly tested by its users before other enhancements are added.
Neal_K3NC Member ✭✭Agree with Stu, I think the time-bound schedule was used to prove Flex's ability to deliver after a bit of a rocky start with the 6000 schedule. They have more than proven their ability by now, both in quality and promised feature set. I am sure no situation is perfect but these guys have done more than I ever imagined they could (and my expectations were sky-high to begin with).
I also like this model. It's frustrating to wait months and then be delayed longer for a new release. I've been waiting forever for workable NR,NB and ANF, but even though it is now slated for 1.5 it could be almost another year away. I would rather pay a yearly fee and see improvements pumped out on a regular basis instead of posturing for a big release for $199.
Actually, yeah there is, it needs to be very focused, limited, and directed. But thank you Jim0
It already is focused limited and directed. Just because the speed of production of a particular favorite feature doesn't match your fantasy, doesn't mean your fantasy should somehow try to control the reality of what it takes to create this software. All "features" are not equal. You will note in the latest Flex Insider DSP and noise abatement is referred to as a "science project". This means stuff has to be created out of thin air and tested both for performance and against how it affects the other systems, and possibly discarded for something else. Not trivial. I can well understand Flex's desire to get pretty far down the road with the other features like FM LAN API memories CWX contest software integration etc. before they throw their resources into cutting edge research. This allows the users then to work through the new stuff to exploit strengths and reveal weakness while the DSP research is ongoing. My impression is DSP is going deep into the guts of the process and may require significant rewrite of some of the code, possibly large amounts of the code. You require a stable platform before you can attempt this or there are just too many moving parts. I remember in the days of the SDR-1000 one of the guys I think it was Phil Harmon rewrote and dramatically improved the AGC code for the radio. One day you had an average AGC and the next a superior AGC. No other radio offers this kind of feature BUT the road of going from average to superior often is not just plodding along making little changes as you would wish the process to be. It is not evolutionary but revolutionary. I want a radio that lets me hear under the noise not just one with a little better noise blanker.
In my opinion this approach is what moves Flex into the forefront as far as innovation, and I loves me some innovation.
You will note your radio is Man's Best Ham Radio according to Sherwood's list. It didn't get there by accident.
NX6D Dave Member ✭✭
A larger number of released versions of the code leads to a larger number of versions that must be maintained. FRS intends to support older versions of SSDR indefinitely. I frankly doubt they will be able to afford to do this, but for now we'll take them at their word. As bugs are discovered and fixed, those patches will have to be applied to an increasing number of code branches.
Having made my living doing this sort of software engineering, I know that in many cases patches won't apply cleanly in some branches and will have to be re-engineered. This consumes a lot of valuable time and leads to longer test cycles which will create pressure to keep the number of releases down. If they limit the lifetime of each release, which they have just said they don't intend to do, maintenance will either consume increasing amounts of time, or they will change their policy.
If we users agree to a fixed lifetime model, then a more agile release scheme may become affordable.0
I think the DAX issue more than makes my point. Fantasy is a strange word to use in place of good solid proven software before more bells and whistles are added to obfuscate the issues.
Fantasy is like fantasy football. You create a production scenario based on how you would run Flex radio without a clear understanding of the actual processes and limitations in play. I think the word is apropos.
Steve-N5AC Community Manager adminWalt, I think you make a good point. In a traditional software shop, there would be a product owner that would be someone intimately familiar with the customer (or a customer), who would typically be a homogenous group of folks doing the same thing. This person would put each feature through the paces right after a developer/team have made it and give it a thumbs up or down. Typically there is a rapid interaction.
Our customers are very diverse and each of the groups exercise very different parts of the radio. But we have to test all the parts before we make a release and we rely heavily on our Alpha team to test different parts of the radio. I feel like we are already wearing folks out at the current rate of releases and increasing it would make that worse. These dedicated folks that help us test their favorite mode/style/etc are not on call 24x7 so we have to work around their schedule. We often get our best test time on the weekends rather than throughout the week. It does take a lot of work to get a release out in the field, both on their part and on ours.
We do continually deliver software to our Alpha team. They typically get a release every 2-4 weeks. But while they are testing, we don't sit on our hands. We are developing new things. So we apply fixes to the old things already shipped plus add the new functionality. Remote audio in the LAN is a perfect example where things may work great in our office, but then we deploy to customers that have very different network topologies and they find issues. It may take weeks to examine the issues, try things out and find solutions that work well for everyone. It doesn't typically take our whole staff to work on one feature so the other guys are off working on something new. And consequently, you end up with more things in the software.
Jim, I assume when you mention the DAX issue, you are saying that you think we could have tested it more from the start and ended up with the correct solution in the first release rather than add something later. The point is a good one and this has been the case on some features. In the case of DAX, though, we worked it pretty hard in the office and were pleased with the capabilities. Our Alpha team was as well and we felt good about what we had. Only after it had been in the field a while did we put the pieces together and see that there are very real, but not consistent, issues that arose. Setting up DAX was the #1 or #2 thing we were getting calls about on the phone. Only when we heard several people explain issues they were having did we realize that we could give them the information to make understanding and using DAX easier and so we promptly did that. Our intuition about what will work well is not always right and sometime we misjudge how people will do things, use things, etc. and when we learn from customers we make changes that help them.
To this end, we've actually considered asking our customers during install if we could collect anonymous usage statistics and patterns that would help us see things we could improve. This is a project for another day ;-)
Anyway, the points made here are all well taken and I assure you our management team reads all these types of comments. We routinely discuss the best ways to develop and deliver software and the entire software team works very hard to make sure we're getting you the most value we can. Thanks for all the comments.5
Ned K1NJ Member ✭✭
The insider seemed to me to say that that was the direction Flex would now tend to take.
There would be feature driven releases rather than package releases at a particular point
in time. I thought that was what Walt was looking for. This was how it was done in PSDR development well into the Flex 5000 generation. I got the impression that Flex and their
customers were pretty happy with that approach.
Taking a look back and bringing some lingering issues to completion in a version 1.5 makes
good engineering and business sense. Vs. 2.0 will be here when it's here. I think Flex is
being reasonable albeit very conservative about projecting a time for that release. I'll bet it
will be sooner rather than later than we might think.
The communication here is healthy and helpful. Thank you for that.
According to PowerSDR users, their DSP is far superior to that in SSDR so nothing has to be 'created out of thin air'. The parameters already exist.
SSDR is not an extension of PSDR
I know, but the parameters must be the same, so the wheel does not need to be re-invented, just remade.
I am actually thinking of going to a 3000 because it just works. ANF and NB just works on that radio.It does not work at all on this.
I agree. Too many loose ends that need to be rectified before adding more loose ends. Soon, it will get out of hand.0
SO not true but I covered this with Steve OOB.
Lee, I was referring to beta testing. "Just because the speed of production of a particular favorite feature doesn't match your fantasy, doesn't mean your fantasy should somehow try to control the reality of what it takes to create this software"
Might I ask who that comment was directed towards?
Steven if you have a 6300 I would consider taking it off your hands :-)
Not right now. I have a used 3000 coming.
Very good... It was worth a shot!. Good luck and thanks for the quick reply.0
David Decoons, wo2x Member, Super Elmer Moderator
I personally would like to see more frequent point releases instead of a single point release between minor versions. Right now the point releases roll quite a few fixes into the point release.
If the time between minor releases is going to increase as the radio matures then maybe have point releases as serious bugs are squashed and confirmed by the alpha team.
For example, I did not install 1.2.17 since the AGC slow was horrible for my environment. 1.3.0 improved it but for my operating I prefer the AGC slow in 1.2.0.
Just a thought but may not be realistic.
I don't know if FRS has a trouble ticket number associated with each reported problem, like DXLab has, but I'd like to see an association of the trouble ticket numbers to a release so I could see what "detailed improvements or fixes" to expect. I don't want to keep entering the same problem as others. This community forum is horrendous for finding things. The roadmap is nice for new features but too high level to show fixes intended for the next release.
Or I could just wait and see if my needs are bubbling to the top. Unless it's "the squeaky wheel gets the oil" situation. In which case I'll just keep bringing up my problems or desires! Even if a list of pending problems is published I can at least determine if I should report a finding or not. I don't like to make work for Tim!
I see the same old problems being discussed across multiple threads which is very disorganized and difficult to follow! A published list with priorities set for each would at least give users a sense of what's ahead.
I for one, try to manage my radio budget like others, but to keep an F5K AND purchase a 6X00 series was out of the question for this retiree! So I held onto my 5000 as long as I could before it started to lose value, and bought the 6500! As far as what features, reliability and functionality I lost, there were many! Most of which are discussed on this forum. They're scattered all over! I just decided the time was right and pulled the rigger on a good deal on a 6500! Now I'm at the mercy of the developers to deliver what I used to have with the 5000!
So, it's been a step forward as well as a step backward!
Since I'm a Vhf/UHF enthusiast I missed the transverter table for a while, now I miss the I2C interface AND I'm disappointed I can't setup a slice for 6m and a 2M transverter slice to monitor both at the same time! WHO KNEW?
I'm also a remote user enthusiast having remoted my F5K for the past several years. I look forward to any improvements to that end also.
BUT, I agree with others that it's time to deliver at least what the F5K had and then continue on with NEW features. I didn't want to take a step backwards only to have to wait to catch up again! Otherwise, I would have purchased on of the "Signature" radios 2 years ago knowing full well it wasn't quite ready for prime time! It appears now we have a slew of dedicated Flex users ( I'm one) who should at least be credited with taking "Signature-2" deliveries!
I better quit now before turns into a rant!
OH, it already was? Joe - KC2TN1
Time to pop another Xanax and chill out. You were obviously reading the community before you bought your 6500 and knew the state of development. The reason your 5000 was decreasing in value was because others decided the 6000 series radios represented a better value. I have no doubt that Flex is trying to juggle the desires of the entire community. Your time will come.
You're exactly right Jon! I was reading the comunity reviews and following the prices! Had the prices on F5K not been dropping I would have waited! I do have faith in FRS to deliver! I bought the F5K early on and went through all the changes and upgrades before it became stable! I was hoping not to have to go through that again! Which is why I didn't purchase the Signature series early on! My expectation was that when general shipping began I would at least have the functionality and reliability of my F5K. What , with all the experience gained in developing PSDR , SSDR even with a new architecture, had the functional foundation in place and was well understood by the community. They knew what the base reliability should have been with the general release. This is why we are having all these discussions! It's always controversial when reliability takes a step backwards even in the face of new features! Yes my F5K was working fine and I wanted to stay on the bleeding edge, but there's a price to pay sometimes. I'm not complaining! I know that FRS is doing their best to manage the process. This company is unlike any other amateur radio production company in the world! Taking direct input from their clients and communicating back to them with a time line. I've managed software development projects and understand how unpredictable they can be! I guess this is why the analyst in me would like to see more details on what's coming up in each release. Once you open up to the user, it's tough to shut the door. I have no intention on going back to a hardware based radio and I know the 6000 series will become my favorite until the 7000 series is announced ! Chilling while waiting for 2.0,1
Leave a Comment
- 20.1K All Categories
- 189 Community Topics
- 2K New Ideas
- 390 The Flea Market
- 6.7K Software
- 5.7K SmartSDR for Windows
- 109 SmartSDR for Maestro and M models
- 277 SmartSDR for Mac
- 210 SmartSDR for iOS
- 208 SmartSDR CAT
- 143 DAX
- 332 SmartSDR API
- 8.2K Radios and Accessories
- 6.7K FLEX-6000 Signature Series
- 682 Maestro
- 37 FlexControl
- 808 FLEX Series (Legacy) Radios
- 576 Genius Products
- 323 Power Genius XL Amplifier
- 208 Tuner Genius XL
- 45 Antenna Genius
- 174 Shack Infrastructure
- 113 Networking
- 286 Remote Operation (SmartLink)
- 109 Contesting
- 455 Peripherals & Station Integration
- 105 Amateur Radio Interests
- 723 Third-Party Software