SmartSDR for Linux

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).

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

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

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?

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

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

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