DXLab Commander 14.0.7 with support for SmartSDR versions 2.4.9, 2.5.0, and 3.0.25 (without multiFle

Dave AA6YQ

WA2SQQ

Dave AA6YQ

I provided Flex engineers with remote access to my development system so they could identify the root cause of the SmartSDR v3.0;19 misbehavior I was experiencing. They reported finding two defects in the SmartSDR panadaptor creation logic, which they expeditiously corrected in SmartSDR 3.0.20. While these defects may have been created when Flex extended SmartSDR to support multiFlex, they prevented correct operation even when multiFlex was not in use. 

The sentence in my announcement noting the presence of these defects in SmartSDR 3.0.19 was to inform users that a later version of SmartSDR is required to enable Commander 14.0.7 to work correctly - not to cast blame on anyone. Since the founding of FlexRadio, my relationship with Flex management and engineers has been collegial; Eric KE5DTO has been particularly responsive and helpful.

Had Flex provided me with a target date for the SmartSDR v3 release, the detection and correction of these SmartSDR defects might have been accomplished earlier in the process.  It's understandable why Flex might choose to not share such information.

WA2SQQ

The initial rollout of any software, especially updates, is bound to introduce some bugs. It just seems that lately everyone is pointing fingers at others. Your points are well taken. I have to deal with similar situations in the digital camera world every day. Since we changed to collaboration mode, so much more gets done, so much faster. And it's really great to see so many users jumping in to assist ;-)

Dave AA6YQ

WA2SQQ

Dave, I have no desire to turn this into a debate which is the direction you seem to be heading. I do not plan on making any further responses. I do speak from almost 40 years of experience in the consumer electronics industry. Like FRS, I work for a multi-million-dollar company who uses API’s for many of our products. I deal with companies like Adobe,  Apple and DXO whose software is used to edit the video and still images our products produce.  

New codecs require these companies to constantly create new drivers. Yes, API’s are designed to promote compatibility, but only for as long as your current platform can support them. At some point, when you decide that you want to expand your design, changes must be made and often that means a radical change. In my situation, the companies mentioned above constantly update, while many of the smaller software developers, many who offer free software don’t. Those companies who are serious about remaining competitive and growing will update their products. Those who decide not to, eventually loose market share.  

For the host company, such decisions are based on ROI – making changes that will result in selling more units. You write some very nice software, but it’s not realistic to think that your software will solely drive FRS’s development direction. Actually, market research shows that the biggest market share gains go to those companies who continually improve their product, like FRS has done; what the Japanese call Kaizen. Have a good day.

Dave AA6YQ