Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
Need the latest SmartSDR, Power Genius, Tuner Genius and Antenna Genius Software?
SmartSDR v3.8.23 and the SmartSDR v3.8.23 Release Notes
SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
Power Genius XL Utility v3.8.9 and the Power Genius XL Release Notes v3.8.9
Tuner Genius XL Utility v1.2.11 and the Tuner Genius XL Release Notes v1.2.11
Antenna Genius Utility v4.1.8
SmartSDR v3.8.23 and the SmartSDR v3.8.23 Release Notes
SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
Power Genius XL Utility v3.8.9 and the Power Genius XL Release Notes v3.8.9
Tuner Genius XL Utility v1.2.11 and the Tuner Genius XL Release Notes v1.2.11
Antenna Genius Utility v4.1.8
If you are having a problem, please refer to the product documentation or check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
DXLab Does Not Support SmartSDR v 3
Lawrence Libsch
Member ✭✭
On Apr 2 Dave, AA6YQ,reported that DXLab does not support SmartSDR v3. This is of great concern for those of us who use DXLab and would otherwise wish to upgrade to SmartSDR v3.
Larry, K4KGG
Larry, K4KGG
1
Comments
-
Here is the link for anyone that's interested
https://groups.io/g/DXLab/topic/dxlab_does_not_support/30876070?p=,,,20,0,0,0::recentpostdate%2Fstic...
0 -
DXLab will never support V3? in the future? Seems strange, this is something all 3rd party developers are needing to address.0
-
The SmartSDR 3 API is not upward compatible with the SmartSDR 2 API. This is an egregious violation of good software engineering practice. New functionality should be supported by adding new data types and methods to the API, not by changing the syntax and semantics of existing methods and thereby breaking existing clients.
After SmartSDR 3 stabilizes, I will review the "migration" documentation that Flex has provided, and update Commander accordingly. Whether specific features of SmartSDR 3.0 will be supported remains to be determined, pending input from the DXLab user community.
The point of my post on the DXLab group was to make clear to the DXLab user community that the current version of Commander does not support SmartSDR 3. Since that thread, Flex personnel have reported correction of the "displaying or clearing lots of callsigns causes audio perturbations" defect in SmartSDR 2.4.9. The correction will appear in both SmartSDR 2.X and 3.X.9 -
After reading that posting, sounds like someone is having a gripe because of the lack of support on the dongle, and issues he is having with using spots. As per the dongle, this is really old news. It is really sad no 3rd party developer has picked up the ball regarding the dongle. I have one.
As per 3.0 other developers have or will figure out how to use SmartLink to connect to a remote Flex 6XXX. Perhaps the DXLab user-base may start demanding it once 3.0 has been out there.
1 -
I have been using DXLab for many years and find its integration with the Flex radios quite valuable, probably more valuable than the new features in V3.0. I would have a hard time upgrading if DXLab did not work with it.
Also, I have written several C# apps that use the V2 API to improve my station operation and to provide features not in SmartSDR. Although I have not seen the V3 API, I have to agree with Dave that it would be an "egregious violation of good software engineering practice" if my apps no longer functioned.
73, Bob, N7ZO
5 -
The "issues I am having with spots" are the result of a defect in SmartSDR 2.4.9 that Flex has ignored for months. The correction has yet to appear in a SmartSDR release.
The Flex documentation for using SmartLink to connect to a remote 6XXX radio says "read our source code". When a Flex engineer can find 15 minutes to provide actual documentation, I'll consider supporting it.
What's really sad is the increasingly sloppy approach to software engineering that Flex has been taking of late.
3 -
I do not mean to speak against the software at all, but as I mentioned in a previous thread when this topic came up, I use SliceMaster to display spots when I want to and do not experience any of the audio issues, I'll have to search an re-read to re-educate myself about the topic. From my perspective it seems you are being nasty towards Flex for not holding your hand to guide you through these issues, while others have figured it out.
1 -
Dave I put a shoutout on the alpha reflector on this. Thanks for your wonderful application I have been using for years now.
1 -
"I have been using DXLab for many years and find its integration with the Flex radios quite valuable, probably more valuable than the new features in V3.0. I would have a hard time upgrading if DXLab did not work with it."
Nothing reported as now in v3 gives me any cause to upgrade.
If SSDR won't work with DXLabs past v2, I probably never will upgrade. Since I don't fall in the "serious multi-op remote contester" category, I doubt anyone cares.
0 -
DX Labs, Slice Master and CW Skimmer are an unbeatable combination. I will not use any version of SSDR where these packages could not function
If I was running FRS I would make an impressive offer to purchase the rights to these wonderful applications and incorporate them in all future versions of SSDR. That would be the smart move.
0 -
The "display or delete too many spots causes audio perturbations" is an acknowledged SmartSDR defect. Yes,one can minimize the adverse effect by reducing the rate at which new spots are displayed, but that should not be necessary.
API documentation is "hand-holding"? Are you the Flex poster child for sloppy software engineering?
0 -
Mike,
How is this situation any different than Flex asking Microsoft for assistance in solving the Windows update hosing DAX problem? It seems to me that Flex is hoping for some hand holding of it's own as Microsoft is under no obligation to help Flex and the DAX issue.
0 -
Dave, you are not in any position to call Flex sloppy. You are not even close to their level. I too use 3rd party software for spots without any problems at all.
After you spending time insulting the Flex software engineering I would be surprised they would try and help you at all. Perhaps that is the reason they have not helped you so much in the past.0 -
Flex has not been asking Microsoft for help, they have asked questions to understand how their updates work,,but Flex knows as far as Windows goes it is what it is and Flex works around it.0
-
Bill,
You've read the posts where others have said that no functioning DX Labs = no upgrade. That is how important DX Labs is for many of us. It's a deal breaker when it comes to SSDR upgrades so Flex should be doing it's best in assisting DX Labs to make it work or they may not find too many interested in SSDR upgrades.1 -
Then let the release come out, let things settle and see what can be done, insulting Flex and trashing them really does not help as much some think it does.1
-
@Bill VA3WTB. As much as I disagree with Dave on many political and transaction al things, Dave is one of the most brilliant programmers I have ever run into in my life If Dave says there is a backwards compatibility issue then I can assure you that there is , that Flex is listening to Dave and will work to fix it. You owe Dave an apology3
-
I oplogize to Dave for my comments, you are correct that Flex has been very sloppy in their approach to software engeneering and Flex has not been kind to you.2
-
I did not accuse Flex of being "unkind", nor have they been. Eric KE5DTO has been very helpful over the years. When the SmartSDR API first appeared, it was essentially undocumented; Eric answered my questions, and I reciprocated by populating the Flex API Wiki with the information he provided. I deemed that a worthy use of time, as it accelerated access to the SmartSDR API for DXLab as well as for other applications wishing to use the API.
SmartSDR 3 is without question non-upward-compatible with SmartSDR 2; Flex has written a "migration guide" to explain the changes that API clients must make. Of course a client application that aspires to support users running both SmartSDR 2 and SmartSDR 3 must be capable of invoking both flavors of the API. Bluntly, there is no excuse for this. As I posted above, one augments an API by providing new data types and new operations, not by modifying the existing operations. This approach enables existing client applications to run without modification, and enables those applications seeking to exploit the new functionality to do so by simply invoking the new operations using the new data types. This has been standard practice since the early 1990s; even the ARRL gets it right with its LoTW API.
Had I known that Flex was contemplating making the SmartSDR v3 API non-upward-compatible with v2, I'd have immediately engaged and pointed out the downsides of that approach.
6 -
I've used DXLab Suite for several years and would not be willing to sacrifice it for the advertised benefits of SmartSDR V3.
I hope that the folks at DXLab and Flex will step back and reset their relationship for the sake of Flex radio owners and the amateur radio community in general. An unfortunate conflict such as this benefits no one.
73,
Larry KB1VFU
1 -
I have been using DXLab since 2014. I don't need the features in 3.0 but would have upgraded it to support Flex. Now that I hear that DXLab will not support 3.0 I will not upgrade. I assume this came out with the Alpha testing of the code. Maybe Flex is rewriting their api's to address this hence the delay of 3.0. This deflates any excitement I have regarding 3.0 at this point.2
-
Does anyone know if the same situation applies for CW Skimmer and Slice Master? Will they function with v3?
I use both in conjunction with DX Labs.
0 -
I haven't seen any other 3rd party developers complaining publicly regarding functionality with v3 but at least one has indicated they have been given access to v3 for development purposes. That's called co-operation, so I have no doubt these developers already have or will function with v3. There are indeed some very impressive 3rd party applications out there only because FRS has wisely went in that direction, encouraging, sharing and providing the tools necessary to develop. It's a win/win approach for users and FRS.
0 -
Mike,
I am not sure how many other 3rd party programs are as robust as DXLab. One of the great things I liked about DXLabs is that I could interface to SMartSDR using the API's socket other radios using CAT. Dave has a tremendous application and from what I have seen he brings up very valid points. I now have a conundrum as our club will upgrade it's 6400 to V3.0 and I wont be able log contacts using DXLab. Since I don't want to walk away from DXLab I probably wont be using our club 6400 much after the upgrade.
Since 3.0 is mainly for contesters I am thinking N1MM may have the same issue.
1 -
Mike, VE3CKO: Except that's not what Flex did.
It took months for Flex to decide how to make the SmartSDR API public. And when they finally made it public, the API came with no documentation.
I don't speak for all 3rd party developers, but from my perspective, the ecosystem of 3rd party products that compliment Flex 6XXX radios has emerged in spite of Flex, not because of an effective program to encourage its formation. 3rd party developers have been going "above and beyond" because they like the company's products and want to help move them forward.
The non-upward-compatible nature of the SmartSDR v3 API with respect to v2 is terrible for 3rd party developers, for the reasons cited above.
Mike, you should consider the difference between product management and cheerleading. The latter adds no value, but can damage your credibility. Direct feedback from users and 3rd party developers is highly valuable, despite the fact that it may not be 100% accurate. The effective product manager actively solicits constructive criticism, and does not attack those who offer it.10 -
Dave, I am sorry, I am having trouble following your thinking. In your reply to my apology to you,to witch was not excepted,,,,,you mentioned Flex has been great help to you over the years answering all your questions.
But now you stated the ecosystem of 3rd party products that compliment Flex 6XXX radios has emerged in spite of Flex, not because of an effective program to encourage its formation.0 -
I was on the fence about V3 until now. There was very little that it offered me but I was willing to do the upgrade for the general improvement and bug fixes that it would offer.
Not so now. I will not even consider V3 until I have solid evidence that it will play nicely with DXLab. I do not need Flex SSDR V3. I DO need DXLab and will not consider a substitute.6 -
An effective program to encourage 3rd party developers to develop applications that compliment Flex 6XXX transceivers would at minimum have provided complete documentation when the SmartSDR API was launched, and would ensure that each new version of the API is upwardly compatible with its predecessor - meaning that existing applications would run correctly on the new version without modification. Application modifications would only be required in order to exploit new capabilities provided by the new version.
Instead, the API was originally launched with no documentation. Yes, Eric KE5DTO promptly and accurately responded to my many "how does this work?" emails, but that should not have been necessary. Nor should it have been necessary for me to populate the SmartSDR API Wiki with the information I gained from Eric.
The fact that the SmartSDR v3 API is not upward compatible with the v2 API illustrates poor communications with at least this 3rd party developer. Had I been made aware that this was the plan, I'd have engaged with Steve N5AC within seconds and pointed out the downside of this approach. As I've said, above, this lack of upward compatibility among SmartSDR releases is terrible for 3rd party developers.12 -
I've already had other FLEX owners tell me there is nothing in V3.0 to entice them to upgrade when it is available. I've been advocating on behalf of FLEX that we should support FLEX. Now to hear these issues of non-compatibility, added to the Windows driver issue, I cannot in fair conscience recommend to my friends they upgrade to V3.0 and they won't.
If FLEX doesn't get in front of this RIGHT NOW, it will not fair well going forward. Alter all, it is a "Software Defined Radio."
5 -
I have not tried DXLab as I use another product that has help me achieve my goals. Dave, you have twice now accused me of cheer-leading or being a poster boy for FRS. As brilliant of a programmer you maybe and how a great program DXLab is, your little insults certainly won't encourage me to try or switch to DXLab and if you decide not to make DXLab work with v3 compatible then you would have made the choice for me and I won't download and try it out. You may certainly have a valid point regarding documentation, I get it. I do think this is getting out of hand, the sky isn't falling.
You have your supporters coming out and saying they will not upgrade to v3, using your own words are they not "cheerleading" as well? I won't say that because I don't think they are. They clearly love your software and are simply voicing their opinion. I certainly won't accuse any of them losing "credibility" for cheering you on.
3
Leave a Comment
Categories
- All Categories
- 282 Community Topics
- 2.1K New Ideas
- 565 The Flea Market
- 7.7K Software
- 6.1K SmartSDR for Windows
- 154 SmartSDR for Maestro and M models
- 383 SmartSDR for Mac
- 248 SmartSDR for iOS
- 241 SmartSDR CAT
- 176 DAX
- 352 SmartSDR API
- 8.9K Radios and Accessories
- 7K FLEX-6000 Signature Series
- 103 FLEX-8000 Signature Series
- 884 Maestro
- 43 FlexControl
- 842 FLEX Series (Legacy) Radios
- 839 Genius Products
- 432 Power Genius XL Amplifier
- 295 Tuner Genius XL
- 112 Antenna Genius
- 262 Shack Infrastructure
- 183 Networking
- 426 Remote Operation (SmartLink)
- 132 Contesting
- 684 Peripherals & Station Integration
- 125 Amateur Radio Interests
- 911 Third-Party Software