SmartSDR v3.7.4 and the SmartSDR v3.7.4 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
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
DXLab Commander 14.0.7 with support for SmartSDR versions 2.4.9, 2.5.0, and 3.0.25 (without multiFle
See the release note for additional details.
Note that SmartSDR v3.0.19 contains defects that prevent Commander from operating correctly.
Comments
-
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!
0 -
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.
0 -
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 ;-)
0 -
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.
2 -
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.
0 -
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.
1
Leave a Comment
Categories
- All Categories
- 245 Community Topics
- 2.1K New Ideas
- 490 The Flea Market
- 7.4K Software
- 5.9K SmartSDR for Windows
- 135 SmartSDR for Maestro and M models
- 327 SmartSDR for Mac
- 243 SmartSDR for iOS
- 224 SmartSDR CAT
- 163 DAX
- 347 SmartSDR API
- 8.5K Radios and Accessories
- 6.9K FLEX-6000 Signature Series
- 768 Maestro
- 42 FlexControl
- 836 FLEX Series (Legacy) Radios
- 727 Genius Products
- 392 Power Genius XL Amplifier
- 251 Tuner Genius XL
- 84 Antenna Genius
- 222 Shack Infrastructure
- 149 Networking
- 370 Remote Operation (SmartLink)
- 118 Contesting
- 582 Peripherals & Station Integration
- 116 Amateur Radio Interests
- 811 Third-Party Software