SmartSDR / Signature Series API

Richard G7EIX

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.

Steve-N5AC

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

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

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

guess we will not see   DXLAB    with good stuff  added to marry up with  the FLEX  6000 series 

Andrew O'Brien

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

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

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

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

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

Side note... I use DXLab, would love to keep him happy. ;-)

rfoust

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

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

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.