Description of 6400/6600 Architecture and Programming Model with comparison to 6300/6500/6700?

  • 1
  • Question
  • Updated 1 year ago
  • Answered
Where can I find a description of the 6400/6600 architecture and programming model that highlights differences from the 6300/6500/6700?

Can all commands documented in the SmartSDR TCP/IP API be used to control the 6400/6600? Will the description of this API be updated to reflect new capabilities provided by the 6400/6600?
Photo of Dave AA6YQ

Dave AA6YQ

  • 178 Posts
  • 214 Reply Likes

Posted 1 year ago

  • 1
Photo of Ria - N2RJ

Ria - N2RJ, Elmer

  • 2305 Posts
  • 939 Reply Likes
I believe the API will be uniform across all models except for things like number of slices,  transverter ports and pre-amp gain. The plan is for SmartSDR to be unified anyway. 
(Edited)
Photo of Dave AA6YQ

Dave AA6YQ

  • 178 Posts
  • 214 Reply Likes
An incompatible new API that supports all models could be characterized as "uniform".

I'd like to understand whether all commands in the currently-documented API will work (with appropriate parameters) when controlling a 6400/6600, and whether the use of any new API commands will be necessary to control a 6400/6600.
(Edited)
Photo of Ria - N2RJ

Ria - N2RJ, Elmer

  • 2305 Posts
  • 939 Reply Likes
From alpha/beta versions I have tested everything seems to be mostly the same as 2.0.19 GA, and compatible except for the new stuff added for the Power Genius XL amplifier. The exact API won't be released until the 2.1 version general release which should be soon.
Photo of Dave AA6YQ

Dave AA6YQ

  • 178 Posts
  • 214 Reply Likes
It's API-level compatibility that I'm asking about, not SmartSDR-level compatibility.
Photo of Ria - N2RJ

Ria - N2RJ, Elmer

  • 2305 Posts
  • 939 Reply Likes
API level compatibility is what I am talking about. Bear in mind that  SmartSDR is also the radio firmware, so when you update SmartSDR, it updates the radio firmware. SmartSDR is not just a client. 
(Edited)
Photo of Dave AA6YQ

Dave AA6YQ

  • 178 Posts
  • 214 Reply Likes
Great! How did you assess API-compatibility of the alpha/beta versions you tested?
Photo of Ria - N2RJ

Ria - N2RJ, Elmer

  • 2305 Posts
  • 939 Reply Likes
My own applications and those from third parties behave identically with the GA and new alpha versions. I also did simple testing with telnet and wireshark. 

However, do not take anything from me as a guarantee - nobody will be able to tell you right now what the final version released with the radios will end up being, not even Flex themselves. 
(Edited)
Photo of Dave AA6YQ

Dave AA6YQ

  • 178 Posts
  • 214 Reply Likes
Perhaps someone from Flex will explain whether or not maintaining API compatibility is an objective.
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 211 Posts
  • 31 Reply Likes
What would make me happy is to see a few examples in languages like C++, Java, or Python.  I did find some "write only code" that kinda sorta helps in C# (not my first language to say the least).

A simple exemplar or two would help.

You know, something that just shows exactly how to connect, how to format a command, and how to receive the results.

Also, it would be nice to know if you could expect to fake it by connecting via things like PuTTY / Telnet.  (My few experiments with this suggestion "no").

The descriptions are commendably language independent, but a few hints as to actually how to do the basic invocation in a popular language or two (which is pretty commonplace out there) would help a lot.  Why should everyone reinvent the wheel here?
Photo of Ria - N2RJ

Ria - N2RJ, Elmer

  • 2305 Posts
  • 939 Reply Likes
This has been the most helpful:
https://www.dropbox.com/s/0xv90d2gq4n5x58/A%20Flex%206000%20API%20Primer%20V1-002.pdf?dl=1

So far I have written apps in Python, PHP, C++ and Swift.

Also, it would be nice to know if you could expect to fake it by connecting via things like PuTTY / Telnet.  (My few experiments with this suggestion "no").
You can in fact do this. 


Ria
(Edited)
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 211 Posts
  • 31 Reply Likes
Ria, thanks for the link.  Extremely helpful.

With it, I was able to us "tcpdump" to get the basic discovery info out of the radio and, contrary to my prior experiences somehow, succesfully use telnet (from Linux anyway) to do basic connection and status gathering (on the TCP/IP side only so far).

That's a lot of progress (for me) in a short period of time.  I also know that it is a completey standard TCP style connection, of which there are about a billion code examples all over the internet.  It seems that only the "discovery" mode is all that special and the rest can almost certainly be done just as the guy who wrote the PDF did from looking at the data stream as it flows by.
Photo of Ria - N2RJ

Ria - N2RJ, Elmer

  • 2305 Posts
  • 939 Reply Likes
They actually conform to VITA-49.

https://www.vita.com/VITA-49/

The discovery isn't even hard. I wrote python code in 2 minutes to implement a simple web based radio chooser. :)

Ria
Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 805 Posts
  • 266 Reply Likes
Official Response
There are no plans to make major changes to the API.  I would say that our approach is somewhat akin to the linux model, if a bit more conservative.  If we find that we have made a serious error in our API, we tend to figure out the right way to do it and leave both the old "wrong" way and implement the new "right" way and mark the old way of doing it deprecated (usually in FlexLib) in the next public version.  Then a public version or 2 down the road, we remove the deprecated functionality.

That's the general approach.  Obviously, if there is something security related, we may move faster than that.

This is a bit different than the approach like Windows where you support APIs indefinitely, regardless of problems found with them.  This has some advantages in that you can still run some of the same programs on Windows 10 as you did against Windows 95, but this is seldom a good reason to keep around a bad idea in my experience.

In general, we are not going to mess with the API.  But we are not hard set against ever changing it if there if there is a good reason for doing so.  

Does that help answer the question?

For what it's worth, I expect that those that are using the API appropriately (reading values like preamp settings, antenna options, etc from the radio) will find that the FLEX-6400/FLEX-6600 models just work with their existing code.
(Edited)
Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 805 Posts
  • 266 Reply Likes
I should also mention that the rate of change on the radio's ethernet API is slower than our FlexLib implementation of a client.  We have found better ways to handle the interaction in C# and have continued to make improvements on the C# side for the sake of stability and reducing race issues. 

For example, we have changed to a model where rather than creating a Slice object and then calling a Slice.RequestSliceFromRadio function, we now just call a RequestSlice function in the Radio class.  This leads to less ambiguity about when the Slice data from the radio is valid and simplifies the startup/removal process for such objects.  There is even a RequestSliceBlocking function that will return a reference to the created Slice.  Much easier to use!  These changes generally make new applications that use FlexLib easier to develop, but may require some minor changes to implement for existing FlexLib applications.

None of these FlexLib changes have any impact on applications using the ethernet API.
Photo of Dave AA6YQ

Dave AA6YQ

  • 178 Posts
  • 214 Reply Likes
Thanks, Eric. Where can I find a description of the 6400/6600 architecture and programming model that highlights differences from the 6300/6500/6700? Or should I interpret your response above to mean "there are no differences"?
Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 805 Posts
  • 266 Reply Likes
I'm not aware of any differences other than the ones I mentioned above (different preamp values, antenna port options, etc) that are already encapsulated in the API.
Photo of Dave AA6YQ

Dave AA6YQ

  • 178 Posts
  • 214 Reply Likes
Excellent! My compliments...
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1049 Posts
  • 1057 Reply Likes
Dave, there is one I know about which I'll try to get some specifics on.  With the 6600 we added an additional XVTR port and also the mnemonics for the ports will change with both radios.  So the 6400 will have ANT1, ANT2, XVTA and RX_A.  The 6600 will add RX_B and XVTB.  I believe in prior implementations, we provide a command to ask for RX ports, but not one that asks about TX capable ports so we've added this to the API.  So on a 6600 you can ask and get the response ANT1,ANT2,XVTA,XVTB.  
This one is somewhat fundamental to radio operation.  There are others that are more peripheral, for example there is an API to control the reference selection and show which references have a signal on them, etc.  In the 6700/6500 the reference selection was fully automatic, whereas with the new models you have more control and visibility.  There will be other things as well, but most can go unimplemented unless your client needs the new functionality.
Photo of Dave AA6YQ

Dave AA6YQ

  • 178 Posts
  • 214 Reply Likes
Thanks, Steve. If I understand correctly, what you've described are "upward-compatible" changes, meaning that any competently-implemented application that successfully controls a 6300/6500/6700 should successfully control a 6400/6600, but could be further extended to exploit new 6400/6600 capabilities.

The term "competently-implemented" is meant to rule out poor software engineering practice, e.g. having code that won't tolerate the expansion of the Port enumeration.

If you send me the specifics, I'll add them to the API Wiki.
(Edited)