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

Dave AA6YQ

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?

Ria

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. 

Dave AA6YQ

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.

Ria

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.

Dave AA6YQ

It's API-level compatibility that I'm asking about, not SmartSDR-level compatibility.

Ria

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. 

Dave AA6YQ

Great! How did you assess API-compatibility of the alpha/beta versions you tested?

Ria

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. 

Dave AA6YQ

Perhaps someone from Flex will explain whether or not maintaining API compatibility is an objective.

Larry Loen WO7R

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?

Ria

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

Larry Loen WO7R

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.

Ria

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

Eric-KE5DTO

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.

Eric-KE5DTO

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.

Dave AA6YQ

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

Eric-KE5DTO

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.

Dave AA6YQ

Excellent! My compliments...

Steve-N5AC

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.

Dave AA6YQ

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.