Ok I have seen the Alpha release of 1.4

Lee - N2LEE

Mike, what kind of Ham are you. How dare you have a REAL life with outside interest and a balanced view of the world. hehe

Bill -VA3WTB

As I understand it, Flex will not be late ever again on a release. Because they most likely won't mention one in the future. When it comes out it does.

Walt - KZ1F

Mike, you and I are more in agreement than you realize. Re-read what I said, esp with regard to Christmas morning and the scene in Frankenstein with the town folk with pitch forks and reed torches. For myself, the 6000 series is an interesting radio, it ranks high but has a few serious drawbacks, one, it absolutely requires Microsoft Windows to run. Yes, Stu wrote an contesting iPad app for it and I am writing a Linux and Android 'smarter' SDR for it. Mine will integrate DXCluster, logging, LOTW, rotor control and amp control. I think the RHR website lacks imagination but look at what it does, very impressive. I preordered the 6500 based on what, I think it was, Greg told me at Boxboro which was it wouldn't require Windows to run. Yeah, it really does require it.  A ham radio that does 6 meters but doesn't do FM? Really? Jay, remote control, is not a WOW, breaking technology. People have been remotely controlling their entire shacks for, if not decades, years. I refer you to the Product Review section of the latest QST, now all that's needed is a little dongle at the remote site. Running a remote station is way more than the radio's control, it is the station's control, amp, rotor, station grounding etc. SSDR 2.x is good, no doubt, it's moving the ball further down the field but it is not an **** event. Nor is it anything to wet one's pants over. To Jay's point about controlling the morale at FRS, God, I hope not. I think some on this board have done more to dissuade potential customers than they have persuaded potential customers. Again, I refer to my prior comment about pitch forks and torches. If I didn't already have over $5k into FRS I'd go elsewhere, simply based on the rhetoric on this board, the vitriol when they are late. The constant whining about perceived simple functionality that either doesn't work right or is missing. So, no Jay, you (this board) are not inspiring the troops here.  If anything it is hurting their chances for success. To your (Mike's) point, I don't think I've ever seen a group of adults swoon over something so shamelessly. How's that for vocabulary, everybody understood it? When one builds expectations and anticipation that high, there is only one way for it to go when the high wears off. It doesn't matter whether it's a Flex radio SSDR version or a date with the captain of the high school cheer squad, or that new BB gun for Christmas. It will never be as good as this level of anticipation and expectation sets the bar at.

Walt - KZ1F

Wow Mike, I don't believe I'd go that far. I recently entered retirement and, more specifically, fixed income. While I was still working I decided to build the scaffolding for my perceived primary hobby during retirement. The Flex, for good or ill, is part of that. As I explained to people at work, none of us know how many days we have left, but I do know this; however many days I have left just got 10 hours longer. People have to have a transition from working to not working, something to occupy that 10 hours longer/day. If they don't do that they won't be in retirement long. Yes, I am a member of ARRL, yes I get QST. I might glance at it every month and maybe, occasionally, read an article but I certainly don't 'hang on every word' they write. I occasionally talk with Steve Hicks, but it is not as if it is hero worship.  The other image that popped in my head about much on this board are Wayne and Garth. I wouldn't call ham radio a 'frivolous waste of time'. The goal of any hobby is to provide enjoyment to the participant of it. For myself, I much prefer reminiscing about that cheer leader than fantasising over what the next point release or roadmap feature  FRS has planned, even though the cheerleader proved to be just another high school girl but with an inflated ego. 

Dale KB5VE

As I understand it there will be a limited ROAD MAP with features that are being addressed but there will be no time frame.

Steve W6SDM

There could also be a road map with estimated dates available to those who were willing to agree to the following:

I promise not to whine, cry, bawl, howl, snivel, whimper, squall, mewl, bleat or otherwise vociferate displeasure, verbally or in writing, should Flex Radio not have the features I want, when I want, working exactly the way I want, all of the time. 

 

DrTeeth

I wonder what penalties there should be for transgressors?

George KF2T

Sorry about your cheerleader, Walt. They're not all bad. Come to think of it, my daughter looks a lot like the one I dated back when (yeah, I'm double braggin'). Point is, life is good, and our hobby is fun. Let's all enjoy it. And at our ages, not too many cheerleaders come knocking, so getting our kicks form a software upgrade ain't all that bad. Keeps us off the street and out of trouble. Mostly.

Gerald-K5SDR

A few thoughts on some of the banter back and forth on this topic.

1. For you all this is a hobby.  For us, it is our livelihood.  
2. We are not as bad as some make us out to be nor as good as some make us out to be.  But we are pretty good.
3. There are two kinds of criticism: constructive and destructive.  We appreciate and always try to listen to the former.  The latter accomplishes nothing except to cause harm to all, which in some cases may be what is intended.
4. We try to learn from our and get better every day.  
5. We are the only company in ham radio with a public software road map.  We do this as a courtesy to you.  I expect that we will continue to communicate our directional road map from time to time but without specific dates. 
6. We are not going to communicate publicly everything we are working on for competitive reasons.
7. We love what we do and want you to enjoy the work of our hands.  
   

As stated on multiple occasions, we will release v1.4 when it meets our quality standards and not before.  It's close but not quite there.

73,
Gerald

DrTeeth

Thanks for the further information and update. Keep your spirits up, you are doing a fine and difficult job.
Maybe the release of the 1.4 video should have been synchronised with the release of the software? When a video is published it gives the impression of an imminent software release stirring up further excitement in the customer base. It sure has me hitting the site more often to check for it, hi hi.

Walt - KZ1F

Or we could do what I perceive Gerald asked, which was treat them like a company not like an emotionally wounded relative that needs a cheering section, Musketeer section, or Peanut Gallery. I doubt Kenwood, Icom, Yeasu, or Elecraft have an aforementioned cheering sections. Maybe they also don't have a community bulletin board either, hmmmm.

AE0MW

1 quick comment Gerald, intended to be constructive.

You really need to divorce bug fixes from major software releases.

Although I am certainly exited (and impatient) to have some of the new features in v1.4, what I really needed was a v1.3.81 with the DAX bugs introduced in 1.3.8 fixed.

I can't speak for everyone else, but I was perfectly OK with waiting for 1.4 to fix the issues when it was 'coming soon' but as it kept getting pushed further and further back in the mean while I'm struggling with bugs introduced in the last version that supposedly met your quality standards.

Please remember sustaining engineering. It's important to address the old problems even as you work on the new shiny projects.

Bill -VA3WTB

That's right, Icom, Yeasu, Elecraft, are far removed from there customers. Flex does not operate like other company's. The staff at Flex are right out there, like real people. As you rub shoulders with the customer base this way this interaction is going to happen. And would we want it any other way?

Drax

But Moses got **** at the heathens and smashed the current version of the tablets.

Rick_K7ET

Gerald...The only thing out of all of this that really concerns me is with Eric's grand mug, the lack of **** breaks must really be taking a toll!  Hi, Hi!

Norm - W7CK

I tend to agree with Mike here when he mentions divorcing critical bug fixes from major software releases.

It would be really nice to have bug fixes released on a more regular basis and save additional features for the major update releases. 

Its been hard waiting all these months to get DAX and persistence bugs fixed.  I use 2m a lot and so far it has been difficult having more than 1 panadapter open while using 2 meters.  It would have been nice having these bugs fixed months ago and it would have certainly made waiting for v1.4 much easier. 

Please don't take this wrong. I'm not trying to stir up the **** and cause grief.  I'm just trying to provide some constructive criticism and maybe help keep the troops happier in the future!

Norm - W7CK 

Lee - N2LEE

Norm, the process of software development is not that simple. If fixing bugs were that straight forward then that is exactly what they would do. But, every time you add or change a line of code you run the risk of breaking work code. This requires a procedure called regression testing.

Bugs are always given higher priority in the development process. 

I believe Flex is much further ahead than most people think with version 1.4. I have not personally used 1.4 but my impression is this is Beta not Alpha. Alpha is more of a proof of concept code base and not very stable.

I predict that with in two weeks of 1.4 release people will be asking about 1.4.x and when it will be released.

KY6LA_Howard

In a world of infinite resources divorcing bug fixes from major releases might be possible. BUT in the real world, resources are finite. the resources required to release interim bug fixes will detract from the resources available to complete the next release and delay everything.

Jay Nation

My understanding ...

1. Alpha > For in house developers only. Seen in house not released.
2. Beta   > Released to beta testers only. Not seen by customers.
3. Release > Released to customers.

The 1.4 release has not happened, it's being beta tested. the beta
release testing has revealed bugs. Theres at least 1 known bug, so it isn't a candidate for release yet.  

The 1.3.8.126 Release is the current version. you can run older releases but there isn't anything new available yet.

If they released 1.4 before they fix the known bugs, wouldn't customers insist on an immediate bug fix release?

They beta test the bug fix releases too, so that would only cause further delay while a release that shouldn't have gone public gets fixed and retested. this will also push out all the subsequent releases too. 

Yes I'd like to see 1.4 get released, but not if releasing it means waiting longer for 1.5, 2.0, and X.X.

If there some feature anyone wants to see added, its a safe bet it won't be added in 1.4, won't be in 1.5 if it hasn't been requested yet. but might make it into the releases after 1.5 (NB,NR), if it doesn't require WAN remote, or if it does it will be in a 2.X release, or later, or never. 

Customers have found bugs in the 1.3.8.126 release. Some of those bugs will be fixed in 1.4, others won't. There are currently no known bugs in 1.5 and later releases. But there will be if we keep complaining about waiting for releases. I'm willing to promise you that. 

1.4 will get released soon enough.

 

DrTeeth

That is my understanding too, but there is usually a 2a - release candidates. It seems to be universal across the software industry.

For some reason, FRS calls all their pre-release versions 'alpha'. The only other exception I can think of is WSJT-X, which has 'RC' in a file name for Release Candidate when it is actually a beta (they say that in the text on site too).

<Elmer Fudd> Noticed how vewy, vewy quiet </Elmer Fudd> it is around here as we wait for v 1.4?

Bill -VA3WTB

Yes not a sound. This must be a very large release. Almost everything asked about for problems, they say it is being addressed in 1.4.

Gerald-K5SDR

We call our external test group "alpha" but they are technically beta.  We provide releases to them on a frequent basis across a release cycle.  In the strict definition of beta, we have been in beta for at least six weeks.  Since we don't do public beta releases, it matters less what we call it.  

This is a very large release from a coding standpoint.  Many things happened "under the hood" that resulted in performance and stability improvements.  For example, my new i7 CPU dropped from 70% on 8 cores on v1.3.8 to 15% on 4 cores on the recent beta.  Graphics card loading dropped from 50% to 30%.  However your mileage may vary on different machines.

Jay -- N0FB

Excellent news!

Brent Parker

Gerald - Thanks for the updates. That's a significant cpu performance difference. Looking forward to it, when it's ready.

I'm not a programmer (not bad as an IT guy, but programmer - NO!) I've been reading some of the discussion pitching separate bug releases vs enhancement releases. That doesn't seem pratical to me, but I'd like your thoughts. Is that possiable?

I'm an architect, and when we're modeling a complex building in 3D, it's a single model. We can't have different development paths, as they  would never merge together. So it's somewhat of a singular path, and yes, one change can introduce a "bug". (we call them leaks).

We do have design options, which we can turn off and on, but it gets real complicated in a hurry. Having two options take more than double the work, which is a whole other issue.

Thanks,

Brent  W8XG

Lee - N2LEE

Sounds like the product is right about where I suspected in my previous post.

There has been a lot work on the code base which also explains why so much testing is needed. The changes Gerald described is much more than bug fixes, thats for sure.

Lee

DrTeeth

I imagine programming is like building a house of playing cards in that each one you add can ruin the whole thing.

Gerald-K5SDR

Brent, you are correct that developing in two branches increases the total work required to manage and merge the code bases.  If we were a very large company, it might be practical.  

k3Tim

Programming is like building a modern skyscraper.  Each room represents a function, the doors to the rooms are the interfaces allowing data to flow in/out.  The functions (rooms) perform various operations on the data.  Passing data among the rooms on various floors is like a multi-threaded application passing data around.  If someone blocks the data (a door is shut) then the thread freezes. This can happen if a resource is needed but some other thread has it tied up.  One can wait for X milliseconds for a response although this starts adding complexity.  Another method is for the blocked room to say I'll "call" you when I have your data ready (call back function).  Any zippy / multi-thread application that handles real-time information (I/Q data from SDR / User Input / Audio Channels....) would be multi-threaded with call-back functions and interrupts.  This throws an extra complicated dimension of timing onto the code development.  The code sequencing will be more random now due to the multi-thread and random events. It's much easier to handle data that does not have the real-time component.

Gerald has mentioned multiple processors / FPGAs / DSPs etc.  This is like a campus of buildings exchanging data via walkways between the buildings.  The flow has to be just right and both sides in sync.  It is very easy for an app to lock waiting on one to respond with data whilst the other is waiting for an ACK from the last exchange, ie. a walkway gets jammed up / blocked. From my personal experience, this problem is very difficult to code / debug.  

Imagine a bug that happens rather randomly and only once in 5 hours.  How to find it?  You theorize what is happening, put debug code in place to verify and wait for your trap to catch the lil' ****. If you miss, it's another several hours to work on a new trap.  You've just burned an entire day!  

On the positive note, I believe C# is the programming language of choice.  This allows for "data abstraction".  For example, floating point numbers can be 'abstracted' to say, Frequency in units of KHz.  One could then add / subtract / display frequencies in a more user / programmer) friendly manner.  Without ever seeing their code I can guarantee they have data abstraction routines to handle I/Q data.  For example, adding an array of two I/Q data streams or finding the phase angle / magnitude of an I/Q pair.

The challenge is to architect the code (skyscraper) with functions (rooms) + data abstractions (hallways - elevators)  to solve the data manipulations needed to meet product requirements.  If done well, the code structure should be clean (Skyscraper is not the Leaning Tower of Pizza).  If it's well done, changes (mission creep) should be handled w/o to extensive effort.

With CPU's running at Ghz speeds and multi-cores the number of instructions going thru the CPU is huge!  If an app crashes after 3 or 4 days it's considered "unstable". Do the math for that error rate!

_..--
 k3Tim