Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
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.

SmartSDR / Signature Series API

Richard G7EIX
Richard G7EIX Member ✭✭
edited February 2020 in SmartSDR for Windows
I know its probably a while off, but I was just wondering when the API is scheduled for general release or BETA preview? I appreciate that SmartSDR 1.is the top priority, but just wondered if work was in progress on the API in line with the currently development path? I personally am looking forward to playing with the API.
Tagged:

Answers

  • Steve-N5AC
    Steve-N5AC Community Manager admin
    edited February 2017
    Richard, There are two APIs currently. There is a TCP/UDP/IP API that can be used from any Ethernet connected device to control and monitor the radio. This is the same API that we use internally for the SmartSDR-Windows client so everything you can see & do in that client is accomplished over the API. The second API is a layer on the first that translates between the TCP/UDP/IP API and a .NET API (FlexLib) which is more Windows-like. Both APIs are used extensively in the product and we have other developers using both APIs. There is some documentation on the TCP/UDP/IP API, but almost none on the .NET API today. Really the key thing missing is documentation since both APIs are available. Note that neither API has authentication and authorization which will be added later. This will undoubtedly break every user of the API. For this reason, we have not been "pushing" the APIs, but rather responding to individuals that are asking to use it. If you or anyone else would like access to the APIs, feel free to contact me and we can discuss further. A key missing piece is someone to actually document the APIs. Today, we make decisions about whether stepping an additional party through the API is justified (versus more development work) and we would prefer to be able to simply hand out the documentation or have a developer program. Steve
  • Richard G7EIX
    Richard G7EIX Member ✭✭
    edited March 2015
    Steve Thanks for the response. I am very interested in getting to play with them. Most of my ham radio software development is for my own pleasure and not for general release - but I think this could change with the 6000 series. I'm no documentor though, we have people to do that where I work :-) Do I drop you an email direct at flexradio? Thanks again. This is getting exciting and interesting!
  • Andrew O'Brien
    Andrew O'Brien Member ✭✭✭
    edited February 2020
    I spoke with a software developer of amateur  radio products and they report  that access to API documentation is limited  unless " agreeing to indemnify FlexRadio". and no reply from Flex when an exception was sought. What is the purpose of the this requirement? 
    Andy K3UK
  • jim
    jim Member ✭✭
    edited December 2016
    guess we will not see   DXLAB    with good stuff  added to marry up with  the FLEX  6000 series 
  • Andrew O'Brien
    Andrew O'Brien Member ✭✭✭
    edited August 2014
    However, Jim... I see that SDR Bridge is developed so I am hopeful people that develop software for old fashioned  radios will eventually find time to mess with the API and develop things that hitherto had not been imagined. 
  • Steve-N5AC
    Steve-N5AC Community Manager admin
    edited December 2016
    We have about 35 developers in the program right now. The indemnification clause is very common for API programs and protects FlexRadio in the event that use of the API results in a lawsuit. For example, let's say that someone developed a program for transferring medical information from a disaster site. Then they sold this application to hospitals guaranteeing 100% uptime. We would have no knowledge of the sales, necessarily, nor the terms of the agreement. Later, we release a new version of software that accidentally breaks an API command, causing a loss of the 100% uptime promise. The developer and FlexRadio are sued by the hospital. The indemnification clause simply says that the developer will protect us from a lawsuit that arises out of their use of the API. Again, most of the API programs have a clause like this. If you've ever been to a hospital and had any kind of a procedure (sorry I'm using hospitals twice in the same discussion), you sign a document that indemnified the hospital from most causes of death. You might be going in for a lance of a boil, but you sign a piece of paper that acknowledges that you could die from the procedure and you agree not to sue the hospital. Why? Because the hospital, while doing their best to help you, cannot always have all the answers and freak things happen. What happens if you don't sign the paper? The hospital will not treat you. If you ask the hospital "wait, is there a chance I could die??" You will be comforted with a "well, it's EXTREMELY unlikely, but all kinds of bad things could happen if you don't treat the wound properly when you leave here. You should be fine -- we just have to have everyone sign that." Do you walk out of the hospital and refuse treatment? Probably some people do. Having said all of this, we are reviewing the terms of the agreement and again comparing to the industry standard practices. We may or may not revise the terms depending on what we find and the advice we receive. Frankly, if we had our way, legal agreements would never be necessary ;-)
  • Jon_KF2E
    Jon_KF2E Member ✭✭
    edited September 2014
    Steve,

    I was talking with Dave of DXLab fame. I believe he would like to support the Flex API in his suite of applications but is hesitant because of the indemnification requirement. Couldn't their be a separate license for amateur radio hobby use that didn't include the indemnification clause? I can understand the concern of a developer like Dave who is a one man operation, signing on for the indemnification clause. He is a great example of why a separate license might make sense.

    I hate to see developers like Dave scared off. He provides a great product for the amateur radio community. If an agreement could be worked out it would allow DXLab to be an even better fit with Flex...a win for everyone.

    Jon...kf2e
  • Mike NN9DD
    Mike NN9DD Member ✭✭
    edited December 2016
    Nobody likes them but the today's world requires them. I have not read it so I am not sure it's exact language, but my guess it protects flex from bad code written by another developer and holds them harmless for issues that may create. It's ham radio but even bad things can happen with their code and all of a sudden someone is suing everyone. Seems unnecessary but it is good business to protect oneself and understand why it is there Mike N9DFD
  • Dave AA6YQ
    Dave AA6YQ Member ✭✭
    edited July 2015
    Is it necessary for amateurs to indemnify Elecraft, Icom, Kenwood, TenTec, or Yaesu before obtaining documentation of their CAT instruction sets? No.

    In an amateur radio setting, any damage arising from the use of a Flex API would by definition be the result of a defect in that API.

    If the Flex API will be used in commercial settings like the example Steve N5AC cites above, then a commercial license is appropriate for use in those settings.

        73,

               Dave, AA6YQ
  • rfoust
    rfoust Member ✭✭
    edited December 2016
    Side note... I use DXLab, would love to keep him happy. ;-)
  • rfoust
    rfoust Member ✭✭
    edited March 2017
    I've been in the developer program for a while now. The documentation that exists now may not be complete, but it isn't bad at all. The way that software talks to the radio really isn't all that difficult. The .net layer basically just takes the network communication work away from the developer and makes it a little easier (if you're developing on Windows). There is some functionality I'd like to see added to SmartSDR (both from the client/server perspective) but the stuff they have now is actually quite good.
  • Jon_KF2E
    Jon_KF2E Member ✭✭
    edited September 2014
    I certainly understand Flex's need to protect itself from litigation. I resurrected this tread in hopes that a second non-commercial license might be considered for use by amateur developers.

    Jon...kf2e
  • Walt - KZ1F
    Walt - KZ1F Member ✭✭
    edited November 2016
    I think the issue comes down to are the derivative works sold or given away. Regardless of which it is, it is beyond the scope of FRS to control that. Consequently it makes sense they need to protect themselves as if the author of the derivative work did, implicitly or explicitly make claims about the suitability. UCC 2-314 Unless excluded or modified (Section 2-316), a warranty that the goods shall be merchantable is implied in a contract for their sale if the seller is a merchant with respect to goods of that kind.

Leave a Comment

Rich Text Editor. To edit a paragraph's style, hit tab to get to the paragraph menu. From there you will be able to pick one style. Nothing defaults to paragraph. An inline formatting menu will show up when you select text. Hit tab to get into that menu. Some elements, such as rich link embeds, images, loading indicators, and error messages may get inserted into the editor. You may navigate to these using the arrow keys inside of the editor and delete them with the delete or backspace key.