DXLab Commander 14.0.7 with support for SmartSDR versions 2.4.9, 2.5.0, and 3.0.25 (without multiFlex) is available

  • 1
  • Idea
  • Updated 2 months ago
Thanks to to Jamie WW3S, Mark W3II, Dave WO2X, Steve K5FR, Chris N6WM, Dave NX6D, Eric KE5DTO, and Ed Gonzalez for their help with this release.

See the release note for additional details.

Note that SmartSDR v3.0.19 contains defects that prevent Commander from operating correctly.
Photo of Dave AA6YQ

Dave AA6YQ

  • 191 Posts
  • 224 Reply Likes

Posted 2 months ago

  • 1
Photo of WA2SQQ

WA2SQQ

  • 475 Posts
  • 122 Reply Likes

Software, such as DX Commander, is a peripheral product. When the manufacturer of the host product, FRS in this case, decides to make changes to expand or improve their product’s performance, such changes usually require the peripheral products to make the necessary updates to their product. It's just not realistic to assume the opposite.

V3.0 made it possible for more than one person to connect to the same radio, so it would be expected that peripheral products would also be required to add some sort of multi-client capability. As I understand it, DX Commander did not have that native capability, so its not fair to suggest that a “defect” in 3.0 was to blame. Definitely sounded like a case of the tail attempting to wag the dog.

In your defense, perhaps the v3.0 pre-release communications could have been better, but we didn’t see FRS blaming DX Commander. All concerned need to realize that it’s a team effort, where better communication benefits the entire cause. No bickering, just more collaboration!

Photo of Dave AA6YQ

Dave AA6YQ

  • 191 Posts
  • 224 Reply Likes
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.
Photo of WA2SQQ

WA2SQQ

  • 475 Posts
  • 122 Reply Likes
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 ;-)
Photo of Dave AA6YQ

Dave AA6YQ

  • 191 Posts
  • 224 Reply Likes
As for

"When the manufacturer of the host product, FRS in this case, decides to make changes to expand or improve their product’s performance, such changes usually require the peripheral products to make the necessary updates to their product. It's just not realistic to assume the opposite."

The purpose of an API is to protect "peripheral products" from being broken by changes to the "host product". It is to Flex's benefit to attract the development of complementary "peripheral products" because they broaden available functionality at low cost to Flex, and they expand Flex's footprint in the marketplace.

Making non-upward-compatible changes in SmartSDR's API, as Flex did in v3, is inexcusable: all of the changes could have been made in an upward-compatible manner. The extent to which this error will adversely impact Flex in terms of future support from 3rd party developers is TBD.
Photo of WA2SQQ

WA2SQQ

  • 475 Posts
  • 122 Reply Likes

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.

Photo of Dave AA6YQ

Dave AA6YQ

  • 191 Posts
  • 224 Reply Likes
re "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."

I agree. However, that's not the situation in SmartSDR v3. The API could have been extended in an upward-compatible manner to support multiFlex.

(Edited)