DXLab Does Not Support SmartSDR v 3

  • 1
  • Problem
  • Updated 5 months ago
     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
Photo of Lawrence Libsch

Lawrence Libsch

  • 24 Posts
  • 5 Reply Likes
  • disappointed

Posted 8 months ago

  • 1
Photo of Pat N6PAT

Pat N6PAT

  • 855 Posts
  • 271 Reply Likes
Photo of Bill -VA3WTB

Bill -VA3WTB

  • 4070 Posts
  • 986 Reply Likes
DXLab will never support V3? in the future? Seems strange, this is something all 3rd party developers are needing to address.
Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
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.
Photo of Chris Tate  - N6WM

Chris Tate - N6WM, Elmer

  • 976 Posts
  • 274 Reply Likes
Dave I put a shoutout on the alpha reflector on this.  Thanks for your wonderful application I have been using for years now.
Photo of Mike - VE3CKO

Mike - VE3CKO, Elmer

  • 554 Posts
  • 290 Reply Likes
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.



Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
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.
Photo of Mike - VE3CKO

Mike - VE3CKO, Elmer

  • 554 Posts
  • 290 Reply Likes
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.
Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
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?
Photo of Pat N6PAT

Pat N6PAT

  • 855 Posts
  • 271 Reply Likes
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.
Photo of Bill -VA3WTB

Bill -VA3WTB

  • 4070 Posts
  • 986 Reply Likes
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.
Photo of Bill -VA3WTB

Bill -VA3WTB

  • 4070 Posts
  • 986 Reply Likes
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.
Photo of Pat N6PAT

Pat N6PAT

  • 855 Posts
  • 271 Reply Likes
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.
(Edited)
Photo of Bill -VA3WTB

Bill -VA3WTB

  • 4070 Posts
  • 986 Reply Likes
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.
Photo of KY6LA - Howard

KY6LA - Howard, Elmer

  • 3794 Posts
  • 1642 Reply Likes
@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 apology
Photo of Bill -VA3WTB

Bill -VA3WTB

  • 4070 Posts
  • 986 Reply Likes
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.
Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
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.
Photo of David Decoons wo2x

David Decoons wo2x, Elmer

  • 1491 Posts
  • 325 Reply Likes
For single client use most functions including spots on display, click/tune on spots, and logging interface all work fine in version 3. As Dave pointed out there is some functionality that does not work because now the program needs to be able to identify which client it is to "talk to".

For those that use Kenwood CAT to SmartSDR CAT interfacing there is no change in functionality.

Dave wo2x
Photo of Andy - KU7T

Andy - KU7T

  • 260 Posts
  • 26 Reply Likes
Exactly.

Basically, if a program uses the "legacy" CAT protocol, all is fine (DXlab with CAT instead of Flex protocol, N1MM+, spots, most other logging programs). 

On the other hand, if a program uses the Flex or .NET API, it may or may not work as those are affected (DXLab with Flex protocol, SliceMaster).

So, DXLab does work FINE if you do not use the FlexApi, but the CAT port. I am not sure what functionality does not work with CAT, but you can control your rig, key it, read frequency, etc. Pretty much everything you do with any other rig. 

73
Andy
KU7T
Photo of David Decoons wo2x

David Decoons wo2x, Elmer

  • 1491 Posts
  • 325 Reply Likes
Most functions work using the TCP API connection. There are some functions, two of which Dave has mentioned, that do not work currently in SSDR V3. I personally do not use those functions so it does not impact how I use DX Labs.

Dave wo2x
Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
When I extended Commander to support the SmartSDR API, I removed the CAT support. Yes, you can set Commander's Radio Model selector to "Kenwood" and it will sort of work via CAT, but that's not a supported configuration.
Photo of Bob Wright, N7ZO

Bob Wright, N7ZO

  • 279 Posts
  • 76 Reply Likes
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

(Edited)
Photo of Tom N5MOA

Tom N5MOA

  • 97 Posts
  • 25 Reply Likes
"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.
Photo of Zack Schindler - N8FNR

Zack Schindler - N8FNR

  • 152 Posts
  • 27 Reply Likes
Me too. I was going to buy V3 when it comes out. Now I am going to wait until this all shakes out. I am not going to use my 6400 without DXLabs.
Photo of Gary Huber

Gary Huber

  • 1 Post
  • 0 Reply Likes
I am seriously looking at buying a new 6600, but I am primarily a DXer with a real "investment" in DXLab Suite. I'm also seriously considering purchasing a Maestro, but it looks like I'll take a pass on SmartSDR V3 until this "backward compatibility" issue shakes out. I was going to get my order in this week, but I may have to rethink things. AB9M
Photo of Pat N6PAT

Pat N6PAT

  • 855 Posts
  • 271 Reply Likes
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.




Photo of Larry Benoit

Larry Benoit

  • 95 Posts
  • 25 Reply Likes
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

Photo of Mike, W8BE

Mike, W8BE

  • 179 Posts
  • 38 Reply Likes
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. 
Photo of Pat N6PAT

Pat N6PAT

  • 855 Posts
  • 271 Reply Likes
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.
Photo of Mike - VE3CKO

Mike - VE3CKO, Elmer

  • 552 Posts
  • 289 Reply Likes
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.
Photo of Mike, W8BE

Mike, W8BE

  • 179 Posts
  • 38 Reply Likes
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.  
Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
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.
(Edited)
Photo of Bill -VA3WTB

Bill -VA3WTB

  • 4070 Posts
  • 985 Reply Likes
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.
(Edited)
Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
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.
(Edited)
Photo of Gene - K3GC

Gene - K3GC

  • 251 Posts
  • 63 Reply Likes
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.  
Photo of Dave Gipson

Dave Gipson

  • 167 Posts
  • 49 Reply Likes
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."
Photo of Mike - VE3CKO

Mike - VE3CKO, Elmer

  • 554 Posts
  • 290 Reply Likes
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.
Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
I have exactly one objective in this matter: help Flex improve its relationship with 3rd party developers.

Recall how this thread started: my post on the DXLab Discussion Group making it clear to users that the current version of DXLab doesn't support SmartSDR v3 -- because v3 is not upward compatible with v2 - was reposted here by a DXLab/Flex user. Your responses:

"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"

"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."

DXLab users posting in this thread are not "cheering me on". They are expressing dissatisfaction with Flex's decision to make the SmartSDR v3 API be non-upward-compatible with the SmartSDR v2 API. Had Flex not made that decision, the current version of DXLab -- and the current version of every other 3rd party application -- would support SmartSDR v3 out of the gate.


Photo of Mike, W8BE

Mike, W8BE

  • 179 Posts
  • 38 Reply Likes
Mike,

I am certainly not cheerleading for any one.  I rely on DXLab.   There is no incentive for me to upgrade  other than curiosity / support for Flex.   Now there is a reason not to upgrade since I wont be able to use DXLab with 3.0.  If the situation changes I will probably upgrade.   
Photo of K3SF

K3SF

  • 317 Posts
  • 105 Reply Likes


On a professional level, These type of 'corporate' conflicts could be better handled in offline 'face to face' between the corporate entities. as i currently see it, there is one entity trying to be a profitable corporation creating jobs in America and the other offering freeware.

Dont get me wrong, i appreciate freeware as much as the next ham and in the world at large too. I also applaud the effort of those who develop and share their labors.
I do use freeware such as FLDIGI and WSJTX that run on my Mac.

BUT

My Position as a Mac user, i find i have no need to run DXlab here as there is one mac app,  MacDXlogger,  that has most of the same capability. True, I did pay for it but Don Agro provides awesome support at almost 24/7 and in my opinion Don creates professional grade software which also includes MacDoppler and dogparkSDR.

https://www.dogparksoftware.com/home.html.



So i am ready to run SSDR V3 on my 6600M whenever it is released.



just my two cents eroded by inflation

Paul K3SF









(Edited)
Photo of Don Agro

Don Agro

  • 129 Posts
  • 80 Reply Likes
Thanks Paul, but since the Flex SmartSDR V3 API (MultiFlex) is not upward compatible with the V2 API - Third party applications like MacLoggerDX and dogparkSDR will not operate with SmartSDR V3 (MultiFlex) until they are re-written to support both the V2 and the V3 APIs at runtime or split into multiple versions for each API Version.

73 de VE3VRW Don Agro
Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
It is to the advantage of a corporation seeking to be profitable to provide an API that that enables 3rd parties to develop complementary products. Such complementary products expand the total available market for the corporation's products, increase the perceived value provided by the corporation's products, and enhance the corporation's brand -- all at modest cost to the corporation (develop/test/document/maintain the API, communicate with the 3rd parties).

The above is true independently of whether the complementary products are free or paid-for. 
Photo of K3SF

K3SF

  • 317 Posts
  • 105 Reply Likes
Don and Dave

I wish you all the best on working with Flex to make it all happen.

I do understand the difficulty encountered when API's do not remain compatible over revisions. But with problems come opportunities to excel. (That is what my mom would always tell me)

I think this may make a perfect 'opportunity' to provide an abstraction layer to minimize similar impact in the future. OR i am totally off the wall.

in either case...
good luck in making it all happen for us your faithful users.

Paul K3SF
Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
Developing an abstraction layer to bridge the V2 and V3 APIs would cause all 3rd party developers to stop working until the abstraction layer was developed, tested, and documented. At this point, the same effort could likely re-work the V3 API to be upward compatible with V2.

Of course any 3rd party developer who's already done the work to move to the V3 API would be unhappy to have to rip up track, and Flex may be unable to tolerate additional delays in V3 at this point.
Photo of K3SF

K3SF

  • 317 Posts
  • 105 Reply Likes
hi Dave...

you have just taught me that " i am totally off the wall"  in my thought process.

i am a most willing learner.

I am more than happy to learn something new everyday
and
i do appreciate your effort to teach.

good luck going forward
and
i would like to add in the voice of Captain Picard   "Make it so"  ;-)

Paul K3SF


Photo of Steve K9ZW

Steve K9ZW, Elmer

  • 1610 Posts
  • 783 Reply Likes
It is very good to see that while DXLab may not support SmartSDR V3 out of the gate, that Dave AA6YQ hasn't ruled out later SmartSDR v3 support.

It also a good reminder how long te DXLab and FRS relationship has gone on, apparently a reasonable two-way dialogue for the most.  

Hopefully there will be a meeting of the minds as SMartSDR v3 rolls out shortly.  

As Dave AA6YQ points out the v3 transition is quite a fork in the road- I know that for my (arguably and factually much more trivial than the DXLab suite) needs I am approaching v3 "as if a whole new radio" as the added capabilities appear to have required a lot of API rework to capture with v3.

As long as the "smart folk" are talking things tend to get worked out.

All best and 73

Steve
K9ZW
Photo of Pat N6PAT

Pat N6PAT

  • 855 Posts
  • 271 Reply Likes
Why did this all come out so close to the release of V3? Did I miss previous conversations about this? It's all new to me - and it seems to many others as well.

Can you imagine how upset  folks would have been if they found this out only after shelling out $$ for the upgrade?


Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
Pat, that's exactly why I posted the "DXLab does not support SmartSDR V3" message on the DXLab Discussion Group.

I'd guess fewer than 10% of DXLab users are members of that group; hopefully those Flex users who aren't members of that group will see this thread.
Photo of Pat N6PAT

Pat N6PAT

  • 855 Posts
  • 271 Reply Likes
But why was this not disclosed in this forum sooner? FRS must have been working on V3 for a long time. How did this come as such a surprise to everyone? Why now on the eve of the new release?

I would think that such a change that renders widely used software packages useless in the new release would have been communicated to the user community long ago.
Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
To be sure I wasn't revealing anything Flex considered confidential, I waited till I received a email message extolling the virtues of SmartSDR v3 from Flex Sales before posting the "DXLab doesn't support SmartSDR v3" message on the DXLab Discussion Group.

Eric KE5DTO sent me the SmartSDR v3 migration guide several months ago.

No one from Flex ever contacted me to say:

1. let me review with your the primary benefits of V3 and help you understand why you should ensure that DXLab users will have access to V3

2. let me hear from you about the obstacles in extending DXLab to support v3, and see if there's anything Flex can do to mitigate them

This is "Managing a 3rd Party Developer Ecosystem 101".

Even better would have been a web conference for 3rd party developers held a year ago, at which Flex would have shared its objectives for SmartSDR v3. Such discussion would certainly have surfaced the "hey, why is V3 not upward compatible with V2?" issue now being discussed.

(Edited)
Photo of Pat N6PAT

Pat N6PAT

  • 855 Posts
  • 271 Reply Likes
I just think that someone , probably FRS, should have been more proactive in communicating this to the user community so customers could make a more informed decision regarding V3. 

The first I heard of this was from your post. There would have been quite an uproar had this not been known until after upgrades were purchased.

Thank you for the heads up and thank you for a fine software package.
Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1864 Posts
  • 679 Reply Likes
Software deprecation is a strategy that is often used in situations like this.

https://en.m.wikipedia.org/wiki/Depre...

It provides a path and time (often years) to upgrade to the new function calls.

Maybe there were reasons not to take that approach either.

Al / NN4ZZ
Photo of Mike - VE3CKO

Mike - VE3CKO, Elmer

  • 554 Posts
  • 290 Reply Likes
Well said Steve.
Photo of Jon - KF2E

Jon - KF2E

  • 689 Posts
  • 230 Reply Likes
I'm 100% on board with Dave. I've been a DXLab user longer than I've been a Flex user. I also have found little reason to upgrade to V3 other than to support Flex. This gives me a reason not to upgrade. I guess to be fair I should use some of the upgrade funds to donate to DXLab.

Jon
Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
Thanks Jon, but I don't accept donations.
Photo of Burch - K4QXX

Burch - K4QXX

  • 544 Posts
  • 133 Reply Likes
Wow, I am glad I read this thread.  If V3 does not work with Dogpark, I will definitely not be purchasing V3 until it works with DogparkSDR.
Photo of Kevin

Kevin

  • 931 Posts
  • 271 Reply Likes
I wonder what else would be on the list of incompatibilities. Nothing that wasn't written specifically for V3 would be compatible with the new Flex software? I guess this would mean fldigi and the gateway, cw skimmer and the gateway, wsjt-x and jtdx, n1mm+? These are the main tools I use in addition to DXLab suite. 

I don't use slicemaster or frlogger yet but the developers are active in this community. What's the impact to you?

If new features were added as API additions then developers could just add the new features as required. But if the whole API is changed, developers now have to maintain an interface to both? I find it pretty amazing that these tools I use can support so many different radios. Is there a case where another manufacturer wiped the slate clean?

And most of all... I would love to hear from Flex on their intentions or plans. Were they going to delay release until the API is published and developers could catch up? Or maybe the delay is to re-think the API backward compatibility. Or is it simply, they found a better, more supportable and expandable way of doing things and really need this forklift upgrade. There could be all sorts of OK reasons besides just developing in a vacuum but I would really like to hear their perspective.

If you buy V3 day one... what will work with it? The ARRL Amateur Radio Logbook I guess.

73,
Kev K4VD
Photo of Zack Schindler - N8FNR

Zack Schindler - N8FNR

  • 152 Posts
  • 27 Reply Likes
DXLab, CWSkimmer and fldigi will be show stoppers for me. I use these all the time.
Photo of Ross - K9COX

Ross - K9COX

  • 354 Posts
  • 108 Reply Likes
Houston (Austin) , we have a problem
Photo of Winston VK7WH

Winston VK7WH

  • 337 Posts
  • 89 Reply Likes
Is it possible that the reason we haven’t heard anything from FlexRadio is because their Software Engineers in Austin are “heads down, bottoms up” trying to circumvent this issue, so that they can demonstrate Version 3 running with, say, DXLABS at Dayton?

It certainly would be a master stroke if they could pull it off.

Sometimes it pays to dream. Fingers crossed

Winston VK7WH
Photo of ZENKI

ZENKI

  • 11 Posts
  • 1 Reply Like
Having a strategy for attracting, retaining, and nurturing 3rd party developers is not something you do when you have time. Companies that depend on the 3rd party community are focused on the relationship all the time. So, it is irrelevant how busy the FRS developers are.
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1057 Posts
  • 1099 Reply Likes
Official Response
First, I'd like to say it's always possible to do more work and provide more support than we've provided to our third party developers.  Dave's comments, while harsh listening from the inside of FlexRadio and also unique in their voracity, are not the only comments that we've received saying that we could do more to support developers over the years.  

As a young ham in college I purchased a Kenwood TM-721A, a dual-band VHF/UHF FM transceiver.  I really loved that radio, especially the inverted color LCD display technology used.  From my standpoint, that radio was ahead of it's time and it was a great seller for Kenwood.  Even today, I still find that radio "beautiful."  Writing code was my passion as a young man and I wanted badly to crack open the case and add my own capabilities to that radio.  I wondered why, in a hobby like ham radio where we're all learning and experimenting, the radio could not provide ready access to the guts to let me play with it.  I didn't expect Kenwood to make the radio available for me to play with in this manner, but I didn't forget what that felt like either.  After we'd developed the API for internal use at FlexRadio, I pushed hard to open it to the world and provide it so others, like myself, could expand its capabilities, experiment and learn about radios.  And I knew the investment would bring capabilities and pleasure to our customers.  From my perspective and from a company perspective, I'm very glad we did this, it was the right thing to do and I'd do it again.

But like any business decision, opening the API comes with a cost and we've not always invested as heavily in the API as we could have.  When we first opened it, I and the other engineers spent many late nights and weekends updating the Wiki that houses the TCP/IP API and Eric wrote documentation to support the Windows side of the API.  Our team has worked to keep both of these sets of documentation current.  When we first released the API the Wiki had only a portion of the commands in it at launch.  This is no one's fault but mine.  It's probably fair to say I drug FlexRadio into the API world and FlexRadio took me at my word that it was the right thing to do without knowing the cost of maintaining the API for all time and as a result we've occasionally struggled to keep up.

As an engineer, I know what's hard and what's not so hard in the software world.  Generally, getting started in something new is what's really hard.  Once you have your first program running, adding capabilities and experiencing how they work, you can incrementally add and test and the mental work load goes down and the fun goes up.  As a result, I wanted to make sure the basics were well documented and that there were tools to find out everything else.  More than once, I told someone interested in developing for the platform that they could "get the basics from the Wiki on how to connect and communicate to the radio and then literally anything else you want to do can be discovered simply by running WireShark and watching the traffic between the client and the radio."  For the uninitiated, WireShark can display all the commands between the radio and any client.  To discover how to do something, you can watch the communications and press the button in SmartSDR then watch what command we send.  This is not ideal, but to an engineer like myself the message is clear: you can do anything we [FlexRadio] can do because we are layered on the API ourselves.  It's not something "separate" that we have to keep up to date.

Knowing for some that this would not be enough, we also created a community topic for the API that encourages sharing information and an email help line just for developers.  This email, devhelp@flexradio.com, goes straight to the desk of the engineers.  We are committed to answering 100% of the emails that come in this way, in part because we know that everything is not always documented as well as we would like, but also because we love engineers just like we love customers and we yearn to help them experience the fun of writing software in and along with radios and we know that what they do is for the benefit of our mutual customers.

With SmartLink, we needed to use cryptographic techniques for a number of reasons related to security and the protection of our customers and their equipment.  This, necessarily, made understanding what we did with SmartLink harder without documentation.  We were asked to write a comprehensive guide on how SmartLink works for developers.  We're a small shop with a few engineers and we did what we felt like we had time to do -- we wrote a guide that would get developers jump-started and had what we felt like were the necessary details.  We've provided this now to a number of fellow developers who have coded to SmartLink.  With multiFLEX, it was a whole other world.  We changed the guts of the radio to support multiple clients at the same time and this work was non-trivial.  We actually wanted to do this when the radio first shipped but it was hard enough we had to shelve it and only now had the time to implement.  We discussed how to make the API backward compatible since we'd done this every time in the past.  Making it backward compatible would allow a companion program to use either command set (v2 or v3) and it would work -- of course without using the v3 commands, no multiFLEX capabilities would be possible.  As we discussed it, we realized that the API would be less understandable and would look awful over time.  I could go into detail on this, but suffice it to say that we wanted to avoid confusion and make it easy to understand moving forward.  Right off the bat we developed a migration guide that explained the API differences and showed examples of old and new code to assist developers with the migration.

Since that time, we've had several developers take what we've written and adapt their code.  We're asking a lot -- for the engineer that wants to support both v2 and v3, they have to have their code spit out different versions of the commands and parse different responses based on whether v2 or v3 is running.  It's not ideal, but it's not always an ideal world.  We looked at what other engineers have done and felt like it was a greater error to "bastardize" our API rather than force developers to support two API calls depending on version.  Our customers reading this should give developers that have chosen to go along with us on this a pat on the back.  These guys are troopers.  In a way, what we've done is unfair -- we've asked them to update their API when it was convenient for us or their software will no longer work with ours.  Was this something we wanted to do?  Of course not.  Could we have done it differently?  Yes.  Do we feel like we made the best choice we could?  Yes.

I'm proud that FlexRadio, in the spirit of ham radio, opened our API to the community.  I wish we had time to do everything asked of us in this regard, but we do what we feel we have time to do.  We answer every question posed by developers and like Dave has said, when developers call or ask for help we drop what we're doing to help them.  Dave is a nice guy -- I've met him at several hamfests.  While I disagree with his approach of calling us out publicly, he writes good code and his application is well loved by the amateur community.  Dave is, in a sense, right to criticize us.  I would like to do all the things Dave and other developers have asked of us.  At the same time, we have a large customer base that is also asking us to add features, repair defects, stay the leader in SDR technology and work capabilities in their particular niche of the amateur world.  We want to do all of these things, we really do.  We regularly look at the list of all the things we could do and make those choices.  We are often not happy making those choices -- we want to do everything.  Let me say that again: every engineer we employ wants to do everything our customers and developers ask of us.  We can't, but we do listen to the feedback and we do what we are able to do.  

We are passionate about what we do.  We know that some will look at what we've done and celebrate the decisions we've made and what we've created.  We also know that others will malign us for our choices.  Neither group are every entirely wrong.  In Star Trek II, The Wrath of Kahn, (sorry I'm a bit of a trekkie), Captain Kirk asks Spock how a new crew on the Enterprise will respond in a crisis.  Spock's response, "As with all living things, each according to his gifts," tips a hat to what we all know: each of us has gifts and capabilities that we can bring to bear on a problem, but there are limits to the capabilities of all living things.  The same goes for abstract entities composed of those living things: companies.  We do the best we are able, but we also provide several easy ways for developers to reach us if you feel we've not done enough.  We'll always want to do more and if you ask nicely and we're able, we'll drop what we're doing and help because that's what hams do.
Photo of N9VC

N9VC

  • 191 Posts
  • 58 Reply Likes
I, for one, appreciate everything Flex has accomplished.

73, Jim N9VC
Photo of N5LB - Lionel B

N5LB - Lionel B

  • 226 Posts
  • 69 Reply Likes
Thanks Steve. Great explanation.
Photo of Pat N6PAT

Pat N6PAT

  • 855 Posts
  • 271 Reply Likes
That's a nice explanation but the question remains (unless it was answered in all that) will DX Labs , Slice Master and CW Skimmer work with V3 when it is released or not?
Photo of Mike - N1MD

Mike - N1MD

  • 93 Posts
  • 3 Reply Likes
I have the same question. The answer is the crux of the issue.
Photo of K3SF

K3SF

  • 306 Posts
  • 101 Reply Likes
First off
To Dave, i owe you an apology..
After additional research, the api non-compatibility impacts are worse than it first appears.



An explanation on how we got into this situation is is nice
but
real issue for this user is how do I as a flex user go forward.

I so wanted V3 to work
and 
to work in my computer environment ( Macs)
but.
now it seems it wont....or at least any time soon

What else is broken first comes to my mind.

api non-compatibility disrupts the whole flex eco-system which from my perspective includes third party software

Being a Mac user it now seems there are even more widespread impacts
and
i thank Don Agro on correcting me
and
making me read the 'fine print' on his website for MLDX

Question #1
When V2.5 is released will it have the same non-compatible api?

Question#2
When will Flex update the 3rd party software compatible matrix with various version ssdr?

Question #3
Did any of the Alpha testers raise this non-compatibility issue of 3rd party software failure?


Just saying there are a lot more unanswered questions at this time regarding  V3
V3 is great concept....implementation  MMMmm   i have my second thought on that at the moment.

I still think my flex 6600m ( v.2.4.9) is a great radio as it is now
but
i just know it could be so much more

At this stage i am in wait and see mode cause my ham radio experience is more than just the radio. It is the whole composition of hardware and software ( 3rd party s/w) that augment and "interface" with the radio.

Paul K3SF






Photo of Mike, W8BE

Mike, W8BE

  • 172 Posts
  • 38 Reply Likes
Steve's answer pretty much tells me what I already thought.   To sum it up in Star Trek terms  "The needs of Flex out weigh the needs of the 3rd party developers."  
Photo of Pat N6PAT

Pat N6PAT

  • 855 Posts
  • 271 Reply Likes
But the needs of the cash paying Flex customers outweigh anything and the cash paying Flex customers want to be able to use those third party packages
Photo of Dave AA6YQ

Dave AA6YQ

  • 198 Posts
  • 227 Reply Likes
1. My comments in this thread are neither harsh, nor voracious; they are accurate.

2. Given your public announcement of imminent SmartSDR v3 availability, I had no choice but to inform the DXLab user community that the current version of DXLab does not support v3, and to explain why not. 

3. Steve, you've made two serious errors:

A. Knowing before you initially released the SmartSDR API that supporting multiple simultaneous clients was on the roadmap, you should have designed the API with that support in mind. Doing so would not have required implementing multiple simultaneous client support. Thinking it through sufficiently to to avoid a later non-upward-compatible API change would have been sufficient. 

B. Having missed the opportunity to avoid this situation, you confronted a tradeoff. You characterized an upward-compatible v3 API as "less understandable and would look awful over time". Given a choice, this 3rd party developer would have strongly preferred "deal with a single API whose latest additions are complex and ugly" over "rework my application to support two non-upward-compatible APIs". You made the wrong call. Had you made the right call, every 3rd party application would support SmartSDR v3 out of the gate.

No one who knows you, Steve, doubts that your intentions were good. Unfortunately, we live with outcomes, not intentions.



(Edited)
Photo of Bill -VA3WTB

Bill -VA3WTB

  • 4015 Posts
  • 975 Reply Likes
Sounds like the line is made then, I hope some other developers will be interested in working with Flex on this, here is to hoping.
Photo of Dave AA6YQ

Dave AA6YQ

  • 198 Posts
  • 227 Reply Likes
As for "We were asked to write a comprehensive guide on how SmartLink works for developers", I asked Eric KE5DTO months ago for a simple explanation of how to connect to a remote 6XXX via SmartLink. This is, what, 15 minutes of work for a knowledgeable engineer? Still waiting...
Photo of Mike - VE3CKO

Mike - VE3CKO, Elmer

  • 545 Posts
  • 287 Reply Likes
I know Mark WS7M (FRlogger) has already said he's working on it, and I thought I read SliceMaster is too. Carl Moreschi, N4PY has said "my software is fully functional with V3.  I am an alpha tester and my software works very well on all Flex versions."
So I do think developers will decide to move forward with v3 or not, that is obvious their own decision. Either they will get with the program or don't. Again all this sky is falling talk is so counter productive. Steves' statement says it all. He put it all out there taking ownership in an open, honest statement, and yet that still isn't good enough, the complaining continues. Wow.

(Edited)
Photo of Manuel - W4SSB

Manuel - W4SSB

  • 64 Posts
  • 11 Reply Likes
Whether you agree with Steve or not you have to admit he is one very articulate guy !!! Wish I could express myself in words as he does.
Photo of Burt Fisher

Burt Fisher

  • 1269 Posts
  • 485 Reply Likes
He is very smart. The question will be is version 3 a revision that was worth developing, does it appeal to a niche group? Steve references Star Wars, here is my reference 
https://www.youtube.com/watch?time_continue=6&v=7YyBtMxZgQs
Steve being the sword master, talented in what he does.
However Indiana Jones gets to the point without any fanfare, ala AA6YQ, "No one who knows you, Steve, doubts that your intentions were good. Unfortunately, we live with outcomes, not intentions."
Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1864 Posts
  • 679 Reply Likes
Hi Pat,

RE: "...but the question remains (unless it was answered in all that) will DX Labs , Slice Master and CW Skimmer work with V3 when it is released or not?"

The answer for CW Skimmer may depend on what third party application you are using to connect it to SSDR.   There is a list of the programs  on the "Works with Flex" list that integrate with your Flex Radio.  https://www.flexradio.com/works-with-flex/

But it sounds like some of the programs listed may not be supported on V3.  If this is correct, it may make sense to update the page to show the V2 / V3 status?  For example I use SDR-Bridge. 

Maybe something like this...



Regards,  Al / NN4ZZ  
al (at) nn4zz (dot) com


Photo of Pat N6PAT

Pat N6PAT

  • 855 Posts
  • 271 Reply Likes
I use Slice Master to launch CW Skimmer. after that is running then I use DX Lab Launcher to activate Spot Collector.


Photo of Bill - W9KKN

Bill - W9KKN

  • 33 Posts
  • 13 Reply Likes
Just out of curiosity, do you have to use the 3.x FlexLib, or will the 2.x assemblies still communicate with a 3.x radio? If the latter were the case, couldn't you continue using the old methods and have the API contract between your application and FlexLib remain the same until you decided to use the new FlexLib?
(Edited)
Photo of Bill -VA3WTB

Bill -VA3WTB

  • 4070 Posts
  • 986 Reply Likes
So as I read, it sounds like V3 is not and will not be backwords compatible. Steve explained why. So the developers will need to make their software to work with each Version on their own. Looks like some software will not work with V3 out of the gate, but if the developer is willing to go the extra mile, it will be.

We are going to wait and see how this shacks out.
Photo of Pat N6PAT

Pat N6PAT

  • 855 Posts
  • 271 Reply Likes
"So the developers will need to make their software to work with each Version on their own."

Wrong. These third party packages are probably used by the vast majority of Flex owners. It is in Flex's best interest to work with the developers and not leave them to retool their software alone.

Otherwise they may see a significant drop off  in upgrade purchases to the point where there may no longer be a financial incentive for Flex to develop future upgrades to SSDR,

I would like to know if those of you that are lining up for V3 and MultiFlex are still planning on the upgrade if you cannot use the third party utilities.



Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
Bill, let me introduce you to the concept of "opportunity cost". Every development team has a finite number of developers, testers, and writers. A decision to assign personnel to accomplish task A means those personnel cannot accomplish task B. Thus the "opportunity cost" of assigning personnel to task A is a delay in the availability of task B. 

Thus the question is not "are developers willing to go the extra mile?", but rather "will developers prioritize re-working their applications to support SmartSDR v3 over the many other opportunities they have to provide more value to their user community.

Given SmartSDR v3's new functionality is primarily aimed at contesters, 3rd party developers of contesting applications will likely consider supporting it to be a high priority relative to alternative opportunities.

DXLab, on the other hand, is explicitly not a contesting application; its focus is on DXing, with strong support for general operation. If it weren't for the fact that some DXers are also contesters who would prefer to not have to switch SmartSDR versions before and after each contest weekend, there would be little reason to extend DXLab to support SmartSDR v3.
Photo of Bill -VA3WTB

Bill -VA3WTB

  • 4070 Posts
  • 986 Reply Likes
Thank you Pat,,I am sure your not saying anything that Flex had not carefully considered.
My point was,,I think you missed it.  Steve explained the Flex posission and said he is to blame for much of the confusion as he has not kept up with these things as he should have, give Steve credit for being honest, as he always is.

But this is were we are at the moment, each software will need to be made to work with V2 and V3 separately, as both API are not compatible with each other. Only if a developer is willing to do this will a software be compatible with V3.

Un like you, I do not beleive this problem will be for ever, and that it spells the end of Flex Radio. I think down the road the developers will make the changes needed as they work with Flex in the transition.
And perhaps Steve could become more active in aiding this change over.
Photo of Steve K9ZW

Steve K9ZW, Elmer

  • 1610 Posts
  • 783 Reply Likes
@Dave AA6YQ. - as contesting is only one scenario for use of the capabilities of v3 would you think the v2-compatible DXLab could suffice for non-contest use with v3?

Would seem there are many more possibilities that would benefit from seamless v3 integration unless I’m seeing someth8ng not there.

73

Steve
K9ZW
Photo of K3SF

K3SF

  • 317 Posts
  • 105 Reply Likes
there are a few scenarios other than contesting where V3 would be "nice" to have.

One of my  planned usage is to let my 6600m run on three band checks checking FT8 activity and needed band fill and alerting me. while i take the dog for a walk and do pedestrian mobil on ssb.

another was dx hunting on cw, using cwskimmer on couple bands while doing some 40m net activity

still another, is letting a friend use couple bands dx hunting from his new england retreat while i work my last ATNO for HR.

there a quite a few other scenarios for V3 besides contesting....
and
all of them require the api to work with other 3rd party s/w that currently works with V2
but will no longer work with V3

all of my scenarios are currently blown out of the water...

V3 would have been another opportunity to maximize the results and pleasure of my limited ham time...even though retired here..ham time is still precious commodity to come by.

Paul K3SF
Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
I am an active DXer with a Flex 6500. I'm not aware of anything in SmartSDR v3 that would better support my needs than does v2. Not one of the 5200+ members of the DXLab Discussion Group has posted anything of the form "I hope DXLab will soon support SmartSDR v3, because ..." As I posted above, it's obvious that those who participate in contests would prefer to not have to switch SmartSDR versions before and after.

If you're aware of value in SmartSDR v3 that I'm overlooking, by all means please describe it.
Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
Thanks for the scenarios, Paul. What sort of antenna configuration do you have that permits you to operate on multiple bands simultaneously? Are you a contester?
Photo of KY6LA - Howard

KY6LA - Howard, Elmer

  • 3794 Posts
  • 1642 Reply Likes
@Dave... While I used to be an active contester.. now I primarily DX and Remote. 
Here are some non contest V3 scenarios

I tend to watch 2 -4 bands simultaneously on my 6700 with a computer dedicated to SSDR/W.with FT8 (AntA - SteppIR MonstIR Beam and AntB Multiband Dipole)

With V3. I now keep a second copy of SSDR running in the background on my main (not radio) computer so when I hear an announcement of DX I want, I can just pounce on it without having to change operating positions to get to the radio.


Second Scenario when I am remote, the Radio computer sends me needed spots to my cell phone and I pounce on it via SSDR/iOS

Third Scenario.. I sometime schlep a Maestro.. Again the Radio computer alerts me to DX then the Maestro is used to make the Q

Fourth Scenario.  While the MonstIR owns the Pacific, there is a mountain between me and EU.  So I log onto my buddies MonstIR on the other side of the mountain about 30miles away to work the EU while he uses mine to work the Pacific.  Both of us can use our own radios to transmit and one instance of the remote to receive
Photo of K3SF

K3SF

  • 317 Posts
  • 105 Reply Likes
hi dave

Dont do much serious contesting, i just get on and have fun seeing if i can do dxcc over a weekend on a single band or some other self imposed criteria,
BUT
i am avid DX'er for sure..i am just one short of HR at 330 confirmed...
and
have 8 band dxcc
i have to admit that mldx by Don Agro has helped a lot in my pursuit of DX.

The ability to mix my own cwskimmer into overall cluster/spots list helped my on 80m dxcc where world spots are mostly useless
also the way he setup filtering and alarming is great too



The antenna farm has shrunk some.. current antennas are 8 element LPDA T8 by tennydyne,( 20 thru 10m and have used it on 6m too) T8 sit on a hazer trolley on 45ft tower. 

145 ft OCF at 60ft -- for 80 thru 6m)
and

43ft vertical - works best on 40 thru 20m 

There was a DXEE multi-band dipole and sloper at one time...i try to make all my antenna are multi-band.

i also use a 6x2 antenna matrix switch( WX0B sixpack) so i can have two different antennas feeding my 6600M or split to other radios (ic7300 as my backup) with other switches


on my property ( aprox ~ 2acres)  most of my trees are old forest typically over 100ft tall and over 200 years old...but branches do fall down and bring down the wire antennas..winter ice storms or strong thunder storms have made ... i install skyhooks using slingshot method...and use counterweights to help the antennas stay up in swinging trees

one of the best episodes is when i had an OCF taken down my a branch that was 18 inches in diameter and its counter-weight was up at 60ft in the air.  Used chainsaw to free the OCF and it popped backup into place..and still worked fine

pic of the station




Paul K3SF
Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
Howard, thanks! With two antennas, what sort of switching to you use to support simultaneous multiband operation?

Paul, thanks as well!
Photo of KY6LA - Howard

KY6LA - Howard, Elmer

  • 3794 Posts
  • 1642 Reply Likes
Switching... V3 does it for me as the profile selects the band and antenna automatically.  - it also keys the right relay to activate my SPE-2K when I want power.

While I have some physical separation between antennas my 6700 seems to have enough isolation that I can transmit on 40M on AntA and Still receive OK on AntB on 20M or vice versa.  I forgot to mention I also have a Mag loop antenna for low band reception which does a marvelous job hearing in noisy conditions.  so I sometimes run 2 receive antennas on the same band while working a second band.
Photo of Dave AA6YQ

Dave AA6YQ

  • 200 Posts
  • 227 Reply Likes
Many thanks for the info, Howard!