SmartSDR for Linux

Walt Corey

Putting a face and a date to SmartSDR for Linux. I am very excited about the 6000 Series, from the moment I saw it at Boxboro, MA two years ago this summer. I was, however, under the impression the 6000 series would be OS agnostic. Clearly not so, it still requires Windows. I've been a software developer for the last 40+ years, I haven't professionally done Windows in 14 years. I have a Windows VM here for the sole purpose of TurboTax...and now xxxSDR. If its manpower that is the holdup I will offer my services to move Smart SDR to a truly agnostic framework or something very close to it. I, and others, would really like to see this happen and rather than hoping someone else has it tasked I offer myself as a resource. I'd really like to see some movement on this. If this falls into NDA status, I am ok signing that.

Walt Corey - KZ1F

Tim - W4TME

Walt - your assumption is incorrect.  The radio is OS agnostic.  In addition to the SmartSDR for Windows client, there an iPad control surface app (client) by K6TU.  The radio is controlled via TCP/IP so any OS that supports a TCP/IP stack has the ability to communicate with the radio.  If you are offering to work on a Linux client, then you will want to to get the SmartSDR API, by contacting Steve (steve@flexradio[dot]com) and requesting it.

Walt Corey

Thanks Tim, (long time no talk, how you doing, how's the family). I didn't mean the radio per se, I meant SmartSDR.  When we first spoke I thought SmartSDR would be HTML5 based or some such making it truly a portable animal. There was a q/a 4 months ago between W9XC and Mack which was very non committal. Al, nn4zz, did a poll after he and I emailed on this subject, in the FlexRadio group and it is evenly divided between those wanting Windows and those wanting Linux. If one can extrapolate from that to the larger user base and, more importantly, those yet to purchase a flex, I believe there is an untapped revenue stream to be capitalized on. I would have to assume the "for Windows" suffix after SmartSDR implies their may be a SmartSDR for Android or for IOS or for Mac or, in this case, for Linux. I just wanted to put some skin in the game, so to speak.

Walt

Tim - W4TME

Hi Walt.  Doing well.  So is the family.  One of the challenges is that a web front-end is not the best option for rendering high resolution spectrum displays and other statefull stuff going on between the client and the radio.  Not that it can't be done, just not the optimal approach to take.  From a support standpoint, we know how normal web pages can render differently on different types and versions of browsers.  Throw in a 30 fps x8 set of spectrum displays and you can imagine the challenges the support team would face.  We designed and built the first SmartSDR client to provide the maximum and most consistent user experience across many different types of PCs and SmartSDR for Windows has done a really good job of that.  My kudos to the development team for hitting that bulls-eye.

Yes, it is a fair assumption that the "for Windows" suffix implies that there may be other clients for other operating systems coming down the pike. Based on the interest we have had in the API program, we hope that there will be additional clients for the FLEX-6000 in the not too distant future.

Walt Corey

As temping as it may be to procure the SDK and write a control surface in my own image I know, from my experience writing PMNOS and OS2NOS in the late 80's that it will be a one-off I will own. Yes, there was a number of people who also used them and made suggestions for improving or changing it, it was still a one off. In that vein, a comment I made on the linuxham group was, given HRD is warm to the idea of a Linux image, perhaps I might offer my services. Not to diminish fldigi at all but it is not clear to me that would work from Linux to the FlexService without external cables and that pretty much defeats the purpose of vac and DAX. So I think it gets back to a fully functioning FlexRadio blessed control surface. In that regard the other motivation for this thread, aside from offering some skin in the game, is to raise the level of interest in a pure Linux solution such that it might alter or otherwise motivate development priorities in Austin.  No, I didn't know K6TU wrote an IPAD interface.

Walt -KZ1F

Kirk, K6KAR

Out of the several computers I use, I only have one that is running Windows (8.1).  All the others run Mint!  The one computer that runs Win 8.1 also runs some of the windows based aps but most importantly, Flex Radio OS's.    If it wasn't for the Flex Radio OS's, I'd run Linux exclusively, as it's so much more efficient,  So my vote is (obviously), for a Linux based Flex Radio OS.

K6KAR

Steve-N5AC

I received a request fairly early on to get the API details from some guys that wanted to write a Linux client.  We sent them all the stuff, but my impression is that they have not had a chance to get around to writing a client.  There is nothing Windows specific about the API -- you can write a client on any platform you choose and we invite anyone who would like to write a Linux client to do so.  We'll provide all the support we are able.

Walt also asked about HTML5.  Someone else asked me about HTML 5 vs. writing applications for a platform recently in email and this was the response I gave them:

We actually discussed this as an option probably 3 years ago when we got started on the project.  At that time there were several issues with this approach:

1. HTML5 was not yet mature
2. Browser implementation varied widely and some things that worked in one browser broke in the others.  We tried out several HTML5 demos to see who worked and who didn't.  Chrome was the clear leader at the time.  It was clear to us that we would have to develop for "many platforms."  Browsers are supposed to all work the same but they do not.  This expectation, we felt, would be a real problem for us.  "I'm using IE 7.0 and it doesn't work.  No, I don't want to install FireFox!"
3. The companies that had the means to develop applications on mobile and on desktop platforms almost without exception were not betting on HTML5.  Even today, there are very few applications that are HTML5 -- you do not surf to a webpage and install an HTML5 link on the homepage of your iPad, you download a native app.  We saw this trend and expected it to continue.
4. Where there were HTML5 applications, they were ALL compromises in application capability over what could be done natively
5. Performance was a real concern in HTML5.  We saw that different browsers performed very differently with demanding applications. We envisioned that we would be tweaking and writing code for different browsers based on how each performed.  Make no mistake -- we are a high performance graphics application.
6. We had little experience in web application development and lots in PC application development.


So we made the call to skip HTML5 and I consider it a very good decision.  I believe we would be in a much worse place today had we made that decision.


We also looked at a number of "write once, run anywhere" platforms including Adobe Air, etc.  In the end we skipped all of these also.  We chose WPF which was a bit of a gamble and it was expensive at first, but I feel like it was the right decision.  It's hard to make these decisions in the IT world as you have to be good at predicting which technologies will survive and which will not.  We knew HTML5 would survive, but we were (are) concerned about its viability as a pure application platform.


At this point doing HTML5 would be a distraction with little payoff.  We believe everyone really wants a native application and this is what most companies are providing.

Walt Corey

Hi Steve, Thanks for responding. It didn't take long into my career to realize software had a shelf life. For exactly the reasons you mentioned, software is originally written with the best information (and technology) at the time. Three years later, five years later, likely the playing field is radically different by virtue of new technology and new hardware. My framing this as an idea was deliberate. It's not a bug, it's not a problem (except for those holding their breath for a Linux solution), it is an idea. I am reasonable certain it is on your roadmap somewhere. I totally understand a reluctance to discuss plans, as plans can change and there are competitive issues to consider. So, really, my intent was two-fold. If it were a case of resources, I find myself in a situation where my services may be readily available. I am really close (perhaps closer than I realize) to retirement and I was just laid off. The last 14 years have been almost exclusively Linux. And, to be sure, there are other, more well known, Linux developers out here as well. The other was, as mentioned previously, while not expecting you to publicize your roadmap, perhaps it would be informative if you knew where we (the existing or prospective customer base) were hoping it was on your roadmap. Al's recent poll suggest Windows and Linux are pretty much in a dead heat with respect to user preference.

Tim suggested I contact you, in a more 1 on 1 setting, and acquire or attempt to, the existing SDK. In the late 80's and early 90's I wrote an OS/2 based version of a tcp/ip stack based on an existing  DOS offering. It was fully reentrant true multitthreaded and did some things the faux DOS threading could not do. It didn't gain an awful lot of traction although it did have some worldwide appeal. I was professionally and personally using OS/2 and did not want to hang a dos box out just for AMPR.org use. The fit and finish of your existing SmartSDR is obvious. I doubt in any realistic time frame I could replicate that. In the mean time you guys would still be trucking forward with your business plans. Whatever I did would pretty much be a one off I would own as it would likely never be merged with the code base. I completely understand your rationale in one of your talks for being, um, cool to the idea of Open Sourcing the UI or kernel.  I'll have to revisit the talk you gave referencing being at a grocery store and having a QSO with one on the other side of the planet on an iPhone or Android. That would be a game changer as well.
So, in no way was my idea a criticism or complain or a rant. I wanted to start a discussion while at the same time offering to put some skin in it as well.

A fellow developer friend of mine recently lamented the future of HTML5 as Netflix, apparently, dropped it as a future for their streaming engine. They are a different use case than you are, I believe. Besides, I just threw it out there as what would be a graphical user interface that was independent of its host OS. 

Thanks,
Walt kz1f

Ken - NM9P

Linux Mint is, to date, the best Linux Distro that I have tried.
Having little competence in programming beyond GW-Basic 20 years ago, I wouldn't be much help!  But I would LOVE to have a version of SmartSDR that ran on Linux Mint.
Any takers?

Steve-N5AC

Well, hey Walt -- if you want to do a Linux client we'd be delighted to work with you.  Do you want to ring me next week and we can talk about it?

Steve

Walt Corey

I'd be happy to. You are an hour behind EDT?

Steve-N5AC

Yes -- Central time

Dave - WB5NHL

I'm definitely interested and willing to be alpha/beta tester for a native Linux client.

Ken - NM9P

Put me on the list, too.  I'll help test it, if I can get Linux Mint loaded on my new computer.  My current "Mint Machine" doesn't have enough video horsepower to run a full-fledged SmartSDR application.   (Or does it?  I haven't tried...)

Asher - K0AU

Lot of interesting points here.  I agree with Steve that HTML5 (+JavaScript) is very browser-dependent.  Hard to write code that runs well on Firefox, Safari, Chrome and IE.  However I still think a  RESTful control interface to the radio makes a lot of sense. 

Not every SDR client needs to implement a lab grade waterfall / panafall.  A DXing client might use clusters and spots as the home view and just show small spectrum slices to help break through pileups.  A contesting client may want DSP support on the radio to find a clear frequency, or to report total receive energy across a spectrum slice as you rotate the antenna to estimate band conditions.  I don't think it's reasonable to expect any one company with limited engineering resources to build every specialized client.

There are interesting new web developments like WebRTC for audio and asynchronous JavaScript for responsive control.  My 2 cents is that ham radio is caught up in what the telecom guys call "element management" - separate control app for each box - rather than system management or workflow management.  Spotting, logging, digi mode operation and radio control are all siloed rather than tightly integrated.

From a feature standpoint I don't expect Flex to support every crazy digital detector native in their DSP.  If someone made a LAN-connected DSP box with a SATA SSD flash drive for playback and skimmers with search triggers for CW, digi, RTTY and even voice - how would you integrate that into the station architecture?  Or if there were a cloud-based service to take data streams from radios across the country for weak signal detection?

Would be great if we could use the amazing 6K series radio as a catalyst to developing a new ham station software and system architecture!

Walt - KZ1F

I try very diligently to not argue with those I ask favors of. Not that I am arguing with Steve or others on here. As Steve said, they went with the best information and state of the art at the time they needed to make a decision. Certainly nobody would sell software (or even launch it, if they constantly dithered over technology choices and refused to put money on the table because there will always be a faster computer, if not next week, next month and there will always be better and faster and more professional grade software, if not next week, next month. This is why I chose the term putting skin in the game. At some point one has to put their money on the table and place their bet. Having said that, I offer the following URL which is a current testing result:

http://jquerymobile.com/gbs/1.4/
PrimeFaces Mobil is built on top of jquery, which is what is graded at that url.
If you look closely this may expose why Steve made the comment about someone running IE 7 and not wanting to change.

That may not be at all practical as I don't know what to expect from the UDP endpoints. There are only a couple of ways to find that out and I suspect the phone is a good place to start.

Walt - kz1f
 

Walt - KZ1F

Asher, you sound a tad like a software developer. Are you? I agree with you comment about RESTful endpoints. I disagree with you implied support for tightly coupled. You may not have meant that so pse don't react to that disagree. I also agree with not every mobile device needs (or can support) lab grade waterfalls. This is why I think each slice receiver could be a separate 'Rolodex' card so only one, on a mobile device is actively updating, a user could flip to the 'next' slice receiver for a look-see and if they wanted to select that band as the active band, they could do that (space management).

Asher - K0AU

Totally agree with loosely coupled.  I am more of a product manager than a software developer these days... but I've played around a bit with multi-tier web development.  Contact me privately (qrz.com has my contact info) and we can compare notes.

Walt - KZ1F

This conversation seems to have died. Too bad. Before I continue I want to say first I love this radio, warts and all. A look at my QRZ page (kz1f) gives ample testimony not only to my new antenna but also the 6500. To recap,my concern about venturing into a portable or linux friendly version of SSDR was tempered with the, perhaps, inevitable outcome that whatever I wrote would be orphaned to probably always being a one off as it would always be unsupported and trail whatever FRS did. I was trying to convince them they should, now that it is 3 years later, revisit a web based or JavaFX2 based application. About the same time I was interested in FlexRadio I discovered this site, now called, RemoteHamRadio. Well, it was/is incredibly expensive. Their business model is not selling radios it is selling time on a radio. But that is not the subject here. I lost interest in them as, at the time, they didn't have an apparent web interface and I went with Flex. In a conversation with Al, NN4ZZ, I made reference to these folks as having 'contest quality' sites. Having forgotten the name I did a google and discovered what I want to  share. The subject here is proof of concept for a web based, clearly smart, SDR control surface. I think a better job could be done than what this video depicts but it validates my point. So, in as gentle as possible effort to build community support I'd like to ask my fellow Flexers to view the following, http://www.remotehamradio.com/webdx/ and weigh in as to whether this would work for a control surface to the 6000 series. Not this exactly due to look and feel issues but in concept, this front end. The nice thing about this is it could be collocated on the 6000 box. The main thing is, it needs to be something directly supported by FRS so it doesn't lag or die as a result of its author getting hit by a truck or losing interest in fending off a bunch of users demanding new functionality.

This video shows +/- what I had in mind and the suitability of the technology to support it.

The first argument is likely  we don't have web developers. They are a dime a dozen and there are a lot of them out of work right now.
 
Walt - kz1f

MadSci

I'm only just jumping into the fray here...

My plan is to build a cross-platform, open source, down-to-the-metal interface for the 6000+ radios.

If all goes well, that should open up a lot of opportunities and good starting points for 3rd party development and hopefully (with that) some longevity to these and related projects.

As for web-based interfaces specifically, I don't think that's the right place to focus at first. Instead, I think the right place to focus is on making the basic platform available and extensible from the ground up and then building demonstration applications on top of that.

If this is done correctly then it should be fairly easy to create a web based interface, a cross platform gui, and various server based controls that might be bolted into "any handy computer" without too much effort.

In the interest of keeping FlexRadios open and "OS agnostic" I think it's also not a good idea to bake interfaces (a web interface specifically) into the radio itself. It's much better for the radio to concentrate on doing what a radio does, and doing it very well. Keeping that API focused, open, and efficient will allow folks to build interfaces and applications that we can't even imagine at this point.

My team and I have some experience making cross-platform applications work. We code primarily in C/C++ with Java based middle-ware, Javascript in the browser, Python & other scripting languages for glue, and so forth... I'm looking forward to using that experience to open up these great radios and bringing some of my own (and hopefully others') ideas into reality. For as long as I've been building radios I've wanted the 6000+ (high performance A/D at the Antenna) in an affordable, flexible package. Up to now that's been impossible... but the FR folks have done it... so now I can concentrate on what I wanted to do with it :-)

I've got a couple of concerns to keep in the foreground -- Security, for one, must be baked in to the core of all of this. I think it's a good thing that the radio itself is very restrictive about how it communicates on the network -- that's a good start. Whatever extends that should be very careful about how security is handled along the way... this is especially true of anything that might be potentially public-facing such as a web interface.

The other thing is solid, open engineering. If this is done right then it will be adopted by many who just find it easier to support and extend than anything else; and the platforms built upon this work will be inherently reliable -- nothing takes the fun out of a project like having to constantly kick it in the side or jump through hoops to make it work.

With regard to a broader systems approach, as discussed earlier in the thread, I can't imagine a more fertile ground than the ability to network multiple radios in multiple locations and integrate those and their related station technologies into a coherent whole. If we can reduce the barriers to making that a reality then what comes next will be a game changer for everyone.

Well, those are my thoughts anyway. We'll see how it goes :-)

_M

Walt - KZ1F

Well, let me just throw this out.

1) The advantage of being hosted on the box is four fold, a) loopback adapter, b) unexposed logic behind the exposed endpoints, c) at least one less layer of abstraction, and d) simultaneous upgrade with the main SDR software. That way everybody is merely a thin-ish client also program to program communications should be JAX-RS or JAX-WS to abstract the actual secret sauce of FRS's intellectual property.

Of course that mean it must have FRS blessing, which precludes the profit motive. Between this thread and the webSSDR I have expressed, ad nauseum, that I suspect anyone paying for this, which one can argue they already have, they would expect support for as long as they want it, not as long as the developer wants to keep their respective hand(s) in it. When companies buy software, vendor viability is a chef concern. Perhaps less so for individuals but for people reluctant to spend money, I suspect so.

2) Open source....see 1C. Yes, it is totally up to FRS how much of their secret source they want to 'open' but from my understanding it is zero or very close to it. I could be wrong.

3) Security. I've spent about the last 3 years working with SAML which would be a good fit but I actually think OAuth 2 is a better fit, and longer working with other forms.  There are three roles I've identified, perhaps more I haven't. Listener, transmitter, and control operator. For the later, think admin. I would use encrypted certificates, revolving keys, and frequent challenge/response. Personally, at this point I don't have strong feelings on symmetric encryption (SSL) but I do think there should be regular client authentication with a valid key not self signed. This would argue the certificate being signed by the radio or FRS and certainly a certificate store being on the 6000 box itself. The radio needs to be the RP/SP.   That said, I think, in my mind, this really argues FRS needs to own this. Providing a POC is one thing providing the solid level of integration necessary and solid support and growth is quiet another.

4) Open...IMHO I don't see that. Absolutely I'd like to see this up on GitHub but I think to do this correctly implies NDA with FRS and that implies closed source.

5) I haven't actually ruled out doing this but I'd have to NDA the entire source for SSDR, SCAT, DAX and then only on the understanding they'd accept the portable version and maintain it going forward. Essentially Steve, you'd get a contractor for free for the duration. Again, though, that would preclude it ever seeing the inside of GitHub.


As Dennis Miller was so found of saying, "Just my opinion, I could be wrong".

MadSci

Some of what you're suggesting would create some significant performance barriers... That is, if encryption and authentication had to happen at the radio level for all incoming requests that would slow down and complicate controls and throughput.

Also, hardening that interface against potential attacks on the public Internet would be much more difficult and would distract them from doing what only they can do -- improve the radio itself.

What I think makes more sense is to have the radio take basic security measures and continue to reject outright packets that do not arrive from a known control host. Official guidelines for the network interface on the radio should recommend strongly against any attempts to expose it directly to the public network (say by router trickery) as that too would expose it to attacks that it may not be hardened against. It's not the radio's job to also be a web service open to attack. Something else should stand in front of it.

With that arrangement any control software (gui or web based server) would be responsible for protecting the radio(s) under it's control. That isolates the problem to regimes that make sense.

For example: if the software is a single-user control interface then there is little extra security work to do.

However, if the interface exposes one or more radios to the wider network for remote operations then that software should take appropriate and necessary security steps... most certainly that kind of software would have to do so because it's likely that more than the radio(s) would be under remote control... for example amplifiers, antennas, computing equipment, etc.

As for point 4)... I've made my expectations and goals clear to FR and it is my understanding thus far that they have no problem what I'm proposing (with some very specific caveats). In fact, we spent quite a bit of effort nailing that down so I'm confident that side of it will work out fine.

To be clear: I am not attempting to speak for them, just expressing my understanding of the situation.

FR's intellectual properly will remain inside the radio - safely tucked away. The same is true of their private SDR software. However they have no problems with open software exploiting their API which is based on TCP/UDP.

Open software that makes their radios more accessible on more platforms can only add value to the equation. That 3rd party software must stand on it's own, however, and that's perfectly fine. Anyone using that software who seeks assistance will have to pursue the 3rd party vendor -- and that's how it should be. Good 3rd party software with good support will gain a good reputation. If not so good, then not so much.

_M

Walt - KZ1F

I agree with most all you've said. The genesis for OAuth comes from and encryption comes from 1) it's something Steve said they were already looking at, security and to make the radio work from outside the LAN. Actually, although I haven't tried it, one should be able to do that anyway, using, as you said router magic. I wouldn't call it trickery. (tomato tomooto) The use of certificates wouldn't add much if anything. You likely wouldn't have to encrypt the UDP stuff, but I would say control information on the tcp side, yeah probably. I don't think hacking a session is a huge probability even if over wifi, but where the goal is exposed radios as, I think his name is Greg, the "Dreaming of..." blog guy, to have, just for grins and chuckles, a massive DDOS attack which controls all seen radios to remote control is unlikely but not un achievable. Just in the last couple of weeks there was the guy who hacked the Apple iPhone extorting money from their owners in order to unlock them. I actually believe I know the attack vector he used because I almost let him into mine..didn't though. There are people who do this just because they can.

Really cool you made way more progress with Steve than I clearly have. Is access to the TCP and UDP traffic and handshaking still under NDA? If so, that precludes exposing that which means a shim layer (otherwise known as another layer of abstraction) and now you've just added another source of brittleness. Of course Steve might be thinking, "Well you never called me back".

In use cases I've heard Steve talk about (existing You tube videos) I read it as implying a distributed ability. Consequently I'd want to know and control who had access. I think their existing model is segregated well enough to not adversely effect non c&c data traffic. But then you'd have the whole routing UDP traffic issue. Well, FRS would actually have to deal with that for a WAN based solution.

There already is the ability to control the 6000's remotely. The issue is that requires intermediary, 3rd party, software. By being another layer adds brittleness. The advantage of an OS agnostic UI on the 6000s is not 3rd party software, just a handful of REST calls to do CAT specific stuff and open a port to take audio from. But SSDR or the browser, can be launched on any program.

I think the collocation issue is really dependent on how much spare capacity in already in the box. A question I asked earlier was effectively, I know one SSDR can connect to one of many 6000 boxes. Can two SSDRs connect to the same box? My point here is to have a single point of entry is preferable, to have 2 (SSDR + some other) is more brittleness if there were one SSDR and multiple external client pieces add yet more brittleness. Your earlier comment about IP is not quite right, SSDR, SCAT, and DAX are also their IP. I wasn't talking about yet another layer, rather replacing.

It all comes down to how much excess capacity is on the box. I think having the SSDR on the box is really the only sensible thing for best performance and long term viability for users. Right now FRS could completely scrap the code for SSDR, SCAT, DAX and no one would be the wiser. If there is a blossoming after market then either FRS is locked in or anybody who purchased an after market piece runs the risk of being locked in and, at that, have to update multiple software pieces in order to get 'a new radio every 3 months'.

Why the pseudonym?

MadSci

I will try to respond to all of that in sequence (or close to it).

Regarding security, oauth etc... IMO, the simpler and more narrow these mechanisms are the better it will be. Direct authentication with the device on a narrow local network is a good start. Anything after that for wider and more remote access should be handled at a different layer. This also simplifies the API and reduces the potential for breakage as that API evolves.

One key argument for this is the rapid evolution of new attacks and exploits. We would not want to have to burn new firmware in our radios every few months to keep up with that, and we'd not like to have to struggle with some radios not being up to date (hardened against the latest threat). That kind of thing is better handled outside of the box where it is more easily managed.

For example, we are fairly used to the idea that our computer's operating systems are patched frequently -- sometimes even on a weekly basis. This is a necessity as demonstrated by the frequent news of disaster and frustration caused by bad-guys exploiting unpatched systems.

On the contrary, when is the last time you took your car in for a firmware upgrade? I'm guessing that for most people the answer is close to never.

By making the radios themselves essentially inaccessible without help from the outside they can remain safe and their firmware more stable unless there is a good reason to change it (like a new feature!). This also keeps the owner/operator clearly "in the driver's seat" with regard to how it is operated. If the operator doesn't explicitly allow access to the radio through some other device then outside control should be impossible. That's easier done if there is no expectation that the radio is "safe" to connect to the WAN or "WAN ready." I "WAN ready" radio might be exploited unintentionally simply because the owner didn't think about it and wasn't aware of the threat.

I don't think this model makes things more brittle necessarily. FR will certainly update any of their software as needed along with the underlying API that they provide; and at the same time they will let their 3rd party developers know in advance of any changes so that those softwares can also be updated.

As for the TCP/UDP stuff being under NDA, technically, yes it is. But my interpretation of that after some significant conversation is that it's not secret for the sake of protecting the IP so much as for avoiding confusion and complications.

As for the question of open software specifically (open source), it has been said that while it's not ok for a 3rd party developer to publish any kind of "how to" on the API it is not considered a problem to publish source code that makes use of the API. In one of the videos it was actually suggested that folks go and take a look at some source code provided by a 3rd party developer for that purpose.

In any case -- if the radio is on your network you will certainly be able to read the traffic and infer how the API works. indeed this has been suggested as a method for coming up to speed on the TCP/UDP part of the API.

Putting the agreements in place simply keeps things private enough to avoid confusion about the API as it changes over time and avoids confusion over who should support any 3rd party software. That is -- no 3rd party developer will be making any claims (intentional or not) about how the API works, and FR won't be put in the position of supporting nor deflecting those claims. It really just clarifies the responsibilities and keeps things tidy.

Regarding WAN based solutions -- If any WAN based application is a separate application (either by FR or a third party) control over access becomes a separate issue from the radio itself. Indeed, multiple radios might be behind a WAN gateway, and in some cases the WAN application might allow multiple users to access a single radio hardware. Authentication schemes, access control, compression, streaming, encryption, and all of the other related complexities can be isolated to the application allowing the radio firmware to remain stable, simple, and robust.

Another reason to have all of that separate from the radio is the constantly evolving complexity of the applications themselves. I've thought quite a bit about what API calls might be required to make a remote web-based application work for this kind of installation and the one consistent conclusion I have is that it constantly changes. The moment you think you've got it figured out and boiled down to the pieces you need, you have another great idea that requires a new RPC. So you go back to the drawing board. Then you have a conversation with another HAM and they see things differently... another great idea, another RPC, or maybe even a whole other worldview. IMO, firmware is not the right place for rapid change.

Also -- consider bandwidth. One of the key features of the 6000+ radios is the way the architecture compartmentalizes the heavy bandwidth requirements so that they live inside the radio. Even still -- having done that there is still the potential for a LOT of data to be produced and consumed. That's easy to do on a local LAN, but once you begin exposing that to the WAN there is much more uncertainty.

Any excess capacity in the box can be better applied to providing additional features that require high bandwidth access to the data. (I can already imagine several) Those features can then made available via a simple, consistent API that allows a control application to combine those features into the desired user experience.

Perhaps the thing I'm focused on here is the concept of SDR instead of a specific application.

My systemic view of "Software Defined Radio" includes the idea of modularity at the hardware layer and unity at the interface later. An SDR Console might make a wide array of radio hardware available to the operator. Some of that hardware might exist in multiple geographic locations with varying capabilities. Much of that hardware might be utilized by multiple operators simultaneously to provide the operator with abilities that would not be possible with a single radio.

Imagine running the entire station at your antenna feed point via a fiber optic cable. How about a real-time picture of actual propagation and band usage? How about a radio version of looking-glass where you can "hear" what you sound like at multiple stations around the world in real time? How about an automatically generated approximation of your station's radiation pattern? How about an emergency network station that utilizes the best transmitters and receivers in real time based on the desired contact?... What if that emergency network were self healing as HAMs joined and departed?... or what if it could combine receivers from multiple stations to pick out extremely weak signals or even triangulate their position by tagging the signals with accurate timestamps?... I'm just getting started...

The 6000+, with it's mix of high performance, flexible architecture, and network access, can be the perfect modular hardware platform for that vision. Right out of the box with any computer it would be a great radio... With a little extra software and the Internet to tie it together it could redefine the entire concept. I hope it works out that way.

The pseudonym? It's just for fun, but it's stuck and it fits. -- I'm the MadScientist in all the places I roam and it's been that way for decades. It's just a habit now to chose that wherever I can.

;-)

_M

Walt - KZ1F

Dude, so not fair.
1) It's more difficult to have a serious conversation with someone who refuses to say who they are.
2) remarking on my points 1 by 1 (good) without references my points makes it way difficult to respond to. I have to look at what I said side by side with what you said to get the gist of where we agree and where we disagree.
3) Mad Scientist - Rambo...Back in the early 90's I worked for a company in Westboro MA. I was a PSE and there was this guy who was QA. For some unknown reason, perhaps my approach to problem solving he took to calling me Rambo. So, mad scientist, yeah I understand that, except for the whole (see #1).

4) We agree the radio, especially the transmitter, is what needs to be protected. The farther away you are from the asset being protected the more vectors there become for getting to that asset. So let's talk IAM.

Consider your facebook account, if you are young enough to have one or your Google account. Both use OAuth. Now, consider your bank account, would you be happy protecting access to you weath with the same security you guard your facebook page? Fortunately the banks make that decision, not someone less informed. Banks use SAML. I use that metaphor as that is one essentially coined by a coworker, "would you use a bank who's idea of IAM was the same as Google+. The universal immediate knee **** response was 'absolutely not'. So the question becomes is access to the virtual PTT button more like a bank or more like a Facebook page. Put that way, I'd argue more like a bank. At another level I think that may be overkill. Certainly physical access is insufficient as is simple challenge/response of a username and password.  So now we are in the land of credentials, what I am or what I have. I have a signed certificate, as opposed to a two factor authentication scheme. If you place that at a point external to the virtual ptt switch ( like on aftermarket software) one attack vector still remains the radio proper. If you have multiple paths to that asset protecting one of them is grossly insufficient.

What problem do I want solved?  I want equal access to my radio regardless of the form factor or OS that I chose to prefer. If I were happy with Windows and thought Microsoft was the Mecca of of all great things software, I'd be a very happy camper. Unfortunately I do not believe that, quite the opposite. I bought the radio premised on the assertion it would be OS agnostic. Strictly speaking, as Tim argues, the box itself is. However, the vendor supplied control surface is not so I contend FRS failed to deliver on that 'promise', at least to date. How many people would buy Microsoft Windows if doing so meant they had to go to some other company to get software in order to use said Microsoft Windows? Put slightly differently how many people would buy a product if doing so meant they would simultaneously have to buy Microsoft Windows in order to run the product?

The problem I want solved is to have a kick **** radio station such that I can at least compete with the 'big boys' out there within the constraints imposed by the local governing authorities.  I believe I've got that.

The problem I want FRS to solve is to make good on their marketing of the 6000 that is OS agnostic. If, in order to do that, FRS prefer someone else take the fishing expedition to vet technology that would facilitate that then I can help. I totally get that it is the R in R&D that is expensive. I totally get they have a road map to deliver on such that their backers, be it public or private investors, are sufficiently happy with their performance. That means controlling costs. People do what they are good at doing. If FRS had nothing more than Windows developers they would do Windows. If they had no Web developers they wouldn't be doing a web solution. Ditto for Android and Linux and OSx.

What I am trying to get my head around is an aftermarket effort designed to do what FRS should have, and may still do, all along. This is especially true as soon as profit motive gets added to the equation. If you, or Stu, were to say, here, this is a control layer sitting on top of the 6000 that does run on Android, Linux, OSx, iPad, whatever else and I want $200/yr or $100/yr or $50/yr until I get tired of supporting it and playing catchup with FRS. In order to make that long term feasible, there would have to be a sufficient income stream to justify, if not the effort, the continued effort to support that plan. Anyone contemplating going with the aftermarket solution would, if only subconsciously, have to weigh the probability said solution would be supported going forward. From the production side you have to evaluate what income stream would justify the effort and what would the market bear. The lower the unit pricing the more units but the lower the unit pricing the less attractive a long term commitment would be. Yes, I understand c/b analysis. So, in addition to the whatever annual cost of the aftermarket solution there is the additional $5k-$9k initial investment plus an annual $200/year maintenance being paid to FRS.

Earlier, you alluded to a full throated solution that 3rd party vendors could seamlessly plug into. YES I totally agree that is what I, and I suspect the rest of the Flex6000 user base current and future, thought SmartSDR was. So, and yes I am putting words in your mouth, you (or Stu) say, "well they didn't deliver so I will for an additional".

1) there is nothing to say they won't.
2) whatever you or Stu or I delivered would have to be AT LEAST as good as the Windows solution FRS has, to date, delivered.
I do not mean as good, functionally, I mean as good functionally as well as fit and finish, profession software written and maintained on an ongoing basis. Something worthy of being paid for, which every Flex 6000 owner is already doing on an ongoing basis.

The reason I restarted this thread as WebSDR is because I happened on the WebSDR RemoteHamRadio uses. I agreed with Stu, it lacks currency UI wise, but getting past the UI (one doesn't pay $30/hr for the UI they pay for access to the PTT switch and affiliated hardware), it is also use of technology and usable from Windows, Linux, OSx, Android, iPhone, iPad, etc.

I think what we both agree on is SmartSDR would need to be replaced. I can only speak for myself but where I place the bar for software I pay for is way higher than where I place the bar for software I didn't pay for.

Back to technology...
My understanding is the UDP data is just raw data, either inbound or outbound, little processing of that data is required in SSDR. The TCP session(s) are all about command and control (C&C).  It may not be desirable or warranted to encrypt the UDP traffic, there is a lot of it relative to TCP traffic, but by virtue of what the TCP traffic is, that should be secure.

So my take is, and has been, the Solomon solution would be to provide an SDR alternative that FRS could embrace as a solution and maintain from the existing on-going revenue stream from existing and future users.

Having said all of that, I do not believe you actually said your intent is to commercialize an alternative after market control surface.

"Instead, I think the right place to focus is on making the basic platform available and extensible from the ground up and then building demonstration applications on top of that.". I am not disagreeing with that. That doesn't sound like a bolt on, it sounds like a replacement strategy. It sounds like redesigning SSDR from the ground up. I am OK with that too. The advantage of an 'on the box' solution is the work has already been done, you are serving content. Producing the audio and video stream, is already done all that is left is serving pages (to use the web metaphor). The web approach has been completely vetted as seen from people's examples on the aforementioned thread. I am not necessarily married to it. It just solves some problems right up front, rather than kicking them down the road.

What you described above as a federation of 6000's is absolutely a good use case and a good chunk of my career has been in that space as well. My primary goal is to have a portable control surface such my choices are not dictated by what the radio or control surface requires.

I believe, for example, the Google Nexus 10 is a dual quad core device with a 10" form factor. type AC (as opposed to N) wirelss connectivity, ample processing power to manage a flex 6000 but has no concept of com1-4. That's what I want to be using in 12 months. Speech to text is done already...a 10" form factor with speech to CW and, hey, why not cw to speech. How about speech to / from PSK31, Olivia?

THAT would be a game changer. I would be even more surprised if FRS announced that was on their road map than I'd be if they said it wasn't. In other words, if I were Steve I'd keep that such a guarded secret there would be very few people that would know that was my agenda, vs. "gee that never occurred to me".

So for MadSci and Stu, this is what I perceive the competition to be. I'd rather help them achieve it than bet they aren't going there.

Walt - kz1f

MadSci

Dude, so not fair
1) It's more difficult to have a serious conversation with someone who refuses to say who they are.

I'm sorry. I didn't intend to hide anything and I've never had anybody be upset by my alias (amused maybe, but not upset). Also, since I did put my real name (Pete McNeil) in my profile I figured it wasn't a problem. I've checked the box to show my real name (Pete McNeil) rather than my NickName... hope that makes things better. I may tweak it some more.. I'm new to this platform.

2) remarking on my points 1 by 1 (good) without references my points makes it way difficult to respond to. I have to look at what I said side by side with what you said to get the gist of where we agree and where we disagree.

Sorry again. I was trying to avoid quoting everything point by point, and I didn't really want to litigate as much as illuminate... I'm already long winded (bad habit) ;-)

Consider your facebook account, if you are young enough to have one or your Google account. Both use OAuth. Now, consider your bank account, would you be happy protecting access to you weath with the same security you guard your facebook page? Fortunately the banks make that decision, not someone less informed. Banks use SAML. I use that metaphor as that is one essentially coined by a coworker, "would you use a bank who's idea of IAM was the same as Google+. 

I don't really want to try and lock down authentication methodologies in this post. I'm simply suggesting that whatever they turn out to be the radio itself should be as narrow and restrictive as possible and shouldn't be responsible for defending itself from the outside world.

Think of it like this: In order for our work folks to get into our systems remotely they must not only identify themselves to each system specifically, but first they must get past our firewall via the VPN. I'm suggesting the same should be true for the radio -- before you get a shot at it you've got to get onto the local network -- either by way of a VPN and it's authentication, or by way of some other app that's got it's own strong security.

Earlier, you alluded to a full throated solution that 3rd party vendors could seamlessly plug into. YES I totally agree that is what I, and I suspect the rest of the Flex6000 user base current and future, thought SmartSDR was. So, and yes I am putting words in your mouth, you (or Stu) say, "well they didn't deliver so I will for an additional". 

I'm really not saying that -- I have no such axe to grind about what FR did or didn't deliver. In fact, I think that by building an plain-text API at the network level, by delivering data based on published standards (VITA-49), and by making that API available to anyone willing to sign up for their dev program they've pretty much delivered on "OS agnostic."

Sure, their current SSDR is windows only -- but that's not a restriction. It's a starting place.

No matter what FR does in the future, as long as the API remains open then the potential exists for alternatives to be created and supported... and that's a good thing.

Cross-platform software of any complexity is "hard" for a lot of reasons. The vast majority of computer users are running Windows right out of the box. Windows likes to be a bit of a walled garden (.Net everywhere or good luck with that...) There is no wonder in my mind at all why the SSDR is a Windows driven beast... it makes perfect sense. It is the shortest path to reaching the most people.

Having said all of that, I do not believe you actually said your intent is to commercialize an alternative after market control surface. 

If you, or Stu, were to say, here, this is a control layer sitting on top of the 6000 that does run on Android, Linux, OSx, iPad, whatever else and I want $200/yr or $100/yr or $50/yr until I get tired of supporting it and playing catchup with FRS. In order to make that long term feasible, there would have to be a sufficient income stream to justify, if not the effort, the continued effort to support that plan.

Well,... I'm not that far down the road yet, but I'll admit I have in mind the goal of creating a system that is good enough to accomplish that... and there is ample precedent in the open source world for business models like that.

If everything goes the way I would like then my team and I will create an open source, cross-platform library for integrating with the 6000+, and then on top of that we will create cross-platform applications that are good alternatives to the current SSDR and also good demonstrations of the other concepts I have in mind (like federation etc). We would hope that by supporting those applications and building services on top of them we can make sufficient revenue to provide continued development and support. Then if I'm really lucky others will build upon that work to accomplish truly extraordinary things that I've not even thought of yet. We're just not far enough down the road to see what any of that might look like and so for now it's not top of mind for me.

What you might not get is that I am interested in this project because I want it to exist - not because I want to make money from it. From that perspective, it only needs to make enough money (long term) to pay for it's toys. If it does better than that then we will use the extra to improve it.

I have a vision and I want it to be real. That is the goal. Along the way I hope that vision is compelling enough that others will appreciate it too; will help to bring it about; and help to make it last.

_M
Pete McNeil
KF4HCW

Walt - KZ1F

Hi Pete, no, I wasn't 'upset'. There are those that actually DO want to make money on it. I think I speak for others as well but, for myself, I believe I already have paid for it. While it may not be in the very next release, I am OK with that. All I am saying is the most straight-forward way to insure it's arrival is to help out FRS realize it, not compete with them. Right about the time Microsoft was coming out with a commercially viable product I was in Redmond a lot. Microsoft made a point of differentiating the space they were leaving open for others and the space they were 'claiming' for themselves. What I made reference to was in the first YouTube video Steve did, I believe, at Dayton a year ago. He talked about the guy in the supermarket on his mobile device in qso with rare dx. Fldigi is already portable. HRD isn't. They both kind of overlap but I think HRD is a better integrated solution where the component pieces are available to each of the other component pieces. It looks professional. Unfortunately, likely by momentum, it is a Windows only solution. My understanding is they are warm to the idea of someone taking their code and making it portable. Still having the same fit and finish and functionality, the Windows user could hardly complain, it still runs on WIndows, yet the Android user suddenly has first class access to HRD.

You said "Cross platform code of any complexity is hard". I built a whole middleware programming communications framework that was portable in the 90's. Yes, it was hard then, especially if you didn't know how to organize it. What I did was have 90+% of it be absolutely common code. It was knowing where that line between the two was, it was knowing how to implement polymorphism abstraction, and inheritance. It is not that difficult now. There are commercially viable tools that exist now that didn't in the early and mid and even late 90's.

I think it was you that referenced, maybe it was Stu, installing Wireshark and watching the traffic and reverse engineering the product. The people with the most highly vested interest in making the Flex6000 a complete game changer and redefining the Amateur Radio field hardware and software, not to mention commercial field, is FRS. There is a huge opportunity uniquely available to them. It is not available to myself, you, or Stu.  The other dimension of this is NDA. If I or you or Stu sign an NDA and violate it, yes, FRS could initiate legal action...and gain what, they just lost their cookies? If everybody that wanted to hack on it said, I'll sign whatever you want and then, because of first amendment or whatever lame-**** belief system, they totally disregarded it FRS loses despite the NDA. I totally get why they don't want to share.

Frankly, I hope somebody from FRS development is lurking on these threads. Maybe some of what's been mentioned will germinate maybe other ideas will die on the vine. Hypothetically, one gets employed by FRS as a developer, they sign an NDA and noncompete and then voilà, keys to the code base. Supposing this, yet to be named, individual said, I have an idea. Give me 2 months to give you a POC and pay me nothing until you see it. If you like it, pay me for that time, if you don't..thanks. By virtue of getting hired they went through the vetting process. If they violate the non-compete or NDA they never work again professionally. So before that voilà moment FRS gets to decide if the risk / reward is tilted in their favor or if they are talking to someone in the audience at Dayton or Seattle or Hartford writing intellectual checks they can't cash.

I've seen a lot of Ham Radio software written by folks of various programming skills that solve the problem they wanted solved. "It worked well enough for them". Pete, I think you and I, plus or minus, want the same exact thing. I just don't think two guys in a garage have a prayer of accomplishing it. The infrastructure you (and I) require has to be portable, it has to be extendible and it has to ship with the radio. Even if all they do is write a handful of REST endpoints, that would be a start. But I still maintain, a successful environment has to look like the product not like 2 guys in a garage hacked on it for a few weeks.  The fastest, least expensive path is if FRS does this, perhaps with some help. That vision you spoke of, yes, I would really like to see that also.
 Wow, I can really get long winded.

Walt - kz1f

MadSci

Walt,

I've vetted the NDA aspects of this very carefully with Steve. I felt that was necessary before proceeding. I'm confident the terms of the Dev agreement won't be a problem.

As for two guys in a garage... some of the best projects have started that way. In this case we're a bit beyond that. I've got a team of people I work with regularly and several long standing businesses already running. So, my garage is a little bit bigger than most and I'm pretty confident I can make a decent run at this. I'm carving out a tiny corner in my lab and a little bit of time so we can see where it goes. It's going to be fun, and I'll be able to justify playing with radios at my day job - how kewl is that!

As for helping FR do this instead of competing with them... I have said my primary motivation is that I want it to exist, and I'm doing it open source. I'm happy to collaborate with FR on all of it if they wish. Who's to say FR won't take on some or all of what we do and use it to help them move forward? ... and if they don't, then a little competition isn't going to hurt them... in fact the stuff we come up with might just spark innovation and new products at FR and demand in the market.

Hams are, by nature, inventive -- we make things. If FR didn't want folks doing this kind of thing they wouldn't have a dev program right? So, I'm staying positive and moving forward.

Optimism is a critical survival attribute. Without it you die in the puddle you're born in.

Best,
_M

Walt - KZ1F

Oh my gosh. Pete, I am not attacking you either.As for "2 guys in a garage" yes, great bands have started that way, Dell, Apple, and some others have started that way but mostly they crash and burn. I absolutely wish you luck. What jumps out at me is the principals in this conversation all have a vision they want to see to fruition. Nobody has said "I would like to help you". I find that interesting. I am not sure its any more than that. For all I know your team are fellow Google associates and for their 20% innovation time they and you will see what can happen in the space FRS has, to date, left wide open. Good for you. Except Google doesn't do that any more. That you are getting paid to do this and so is your team. cool, nice work if you can get it.

Nothing in what I've said was meant to imply you would fail. Being last in the Boston Marathon just means you did not win it, however, it implies you did finish it though. Nothing says you wouldn't be first. I can't tell, I don't know your day job or how good you are at it, ditto others. I do believe, in order to successful in this, software development has to be a core competency, not only for raw functionality but also for fit and finish. What I want to have can't look like a child with a crayon drew it.

I want the SSDR running natively on an Android tablet in 12 months. I want it supporting logging, either natively or cooperatively. I want on surface SSB, CW, and PSK.

Do I have the chops to do it? Yep, is that on the critical path between me and 5BDXCC, nope. I would undertake it in the scenarios I've articulated, yep. There is nothing in what I've said, implementation-wise that I don't already have a track record accomplishing in commercial products. I know what I know. I do not know all the things I don't know. < there is a subtle point in that. Nothing in this is rocket science. Flgigi does in in their space, there code IS open source. I am sure somewhere that HamLib is open too.

Drivers, start your engines.

Optimism is a critical survival attribute that must be tempered with reality otherwise you will die just outside the puddle you were born in.

But seriously, good luck. One of the outcomes I sought by starting these threads were people stepping up saying, if not "I can help" saying "I can do that".  It would have been nice if Steve had said that, but perhaps that is not a card he chooses to show at this time.

73,

Walt - kz1f