SDR software/hardware API

General Discussion
1

I guess the SDR sofware world could be still considered to be in a nascent state. But seems like it’s past the time for that. I am wondering how we get past that?

I look at the Vulkan API and think that’s a good model of how we make SDR API move forward. I don’t understand the inner workings at Vulkan and there are some deep pockets involved there but that’s okay as long as the end product is an open API.

Whatever umbrella organization, that represents this, would have to be hardware neutral because I see that as a stumbling block now.

This discussion is worth having and a solution is worth finding to ease the current, and significant, pain and suffering that exists right now with the SDR hardware/software landscape.

####Reworded from Vulkan (khronos.org):

Melon* is a new generation SDR API that provides high-efficiency, cross-platform access to modern SDRs used in a wide variety of devices from PCs and consoles to mobile phones and embedded platforms and stand-alone devices.

*

I made up a name so it wouldn’t say :wink:

1 Like
2

@hTo137,

We already have that and it’s been around - still used - for nearly 5 or more years…it’s the framework we like to call: HPSDR. TAPR uses it, Flex uses it, Red Pitaya uses it, and while I tried in vain to have Pavel Demin work it for LimeSDR (he didn’t want to step on anyone’s work that’s doing their own spin to it now) it would still be THE framework to use for SDRs that are out there or emerging. But, as we all know, everyone likes to do it ‘their way’ and that’s why there’s different varieties of SDR hardware out there that don’t support it because they’re rolling their own software - the rest looked at the heavy lifting involved to ‘roll their own’ and compared it to what HPSDR had to offer and just adapted their design to it to make life easier - Red Pitaya is a great example of that.

All it would take is a wrapper around what exists for LimeSDR and the exposed API interfaces that HPSDR has (or needs) and then set it into the openHPSDR framework and A LOT of this would be done. The non-trivial part of this is the decimation and interpolation to make the Lime in/out rates line up with what HPSDR can operate smoothly for their mod and demod functions…I think that’s the same issue that SDRAngel is tackling now for transmit…

Marty (KN0CK)

3

Looks to be close to what I was getting at. Although I see a lot of mention of hardware specifics. But regardless the fact that adoption is low there says it’s not right in some way.

Vulkan seems to have concentrated on the technical side. For example it can make older GPUs useful again and do so with improved efficiency. Two big wins for the user base of that hardware and in the case of Valve(Steam) it means more games will run for a larger proportion of their customer/user base and more revenue. And for the development community it provides a single point to concentrate on. (Well Apple is going their own way with a Vulkan sub-set called Metal, but at least it’s a Vulkan sub-set IIRC)

Any intitiative in the SDR API realm will have to provide some advantages to get people on board. The advantage to the user base that I can think of is having things that can be easily compiled, will work well with the hardware and will have a single point of bug/issue reporting.

As it is now…well it’s a wreck right now. For the initiative to work it will have to rely on high technical merits. Otherwise it won’t be taken seriously. That would mean that at a minimum a couple million bucks to hire a few programmers and others to get it rolling.

As a reminder/addition the initiative could take advantage of the billions of radios in phones too. IIRC phones could rx FM, etc.

It would be great to have it happen and not have the long pain/suffering period that graphics APIs had/have.

I can’t see much down side to this kind of initiative as long as it is built on technical merits and geography and politics stay out.

4

@hTo137,

Look…Don’t get me wrong…It’s a great idea, but…

…You have to get all the SDR manufacturers together (which is like herding cats all over the Earth right now) and make them face a completely new software architecture that - at first glance - would make them want to standardize upon - and that would have to be pretty compelling and would likely come from some ‘think tank’ or SDR consortium (and I don’t think that exists yet, TAPR was a great start to that) - no one person is going to convince them to move to some new software architecture.

Then you have all the hardware differences between all those manufacturers to sort out that they could even get their SDR to fit this new software paradigm - that’s not trivial. Every SDR has their own features (or drawbacks) - - not many have what the Lime has: MIMO. And from what I’ve seen so far every major manufacturer has their own proprietary protocol over USB, Ethernet, or the ever-fading Firewire. Only the TAPR/HPSDR and the LimeSDR are open source and don’t hide their protocols for tuning/demod. If anyone recalls, even the RTL-SDRs had a proprietary tuning and demod until someone cracked the Rafael and Realtek chipsets and allowed them to be used for everything except candy-making.

Then you have to deal with the software developers themselves and what OS this new architecture would be deployed to - that’s enough to draw battle lines right there with everyone adding their 55 cents on what the architecture should really do or how it’s not perfect.

The only reason that Vulkan even did as well as it did is that there’s a HANDFUL of graphics manufacturers out there and they pretty much want to standardize because of all the different platforms out there that they have to be a component to. The money that’s wagging that dog isn’t them - it’s Dell, and HP, and IBM, and Sony, and Acer, and MSI, etc, etc. They have the deep pockets to drive a graphics standard that fits their platform architecture, but as you mentioned, Apple is on the fringe because they don’t want to play - it’s entirely proprietary for them and always has been.

SDR is different. It’s not a component to anything. It’s just what it is - somebody’s idea to make a better radio than the last guy did. Until you can get them all to standardize on how the radio is communicated to and what it produces it’ll still be the mess that it is. It’s a new technology, and just like VCRs and DVDs played out, until there’s one standard that fits, there’ll be a million ways to do it different until the strongest design keeps standing…and that’s not very likely in the near future.

My money is on a TAPR-like design or the SDRs that work with several apps because they try to make it easy for the developers to interface with their radio. Until that happens, it’s going to continue to be a circus.

73 de Marty, KN0CK

1 Like
5

This here is just meant to start a dialogue/discussion. Feelings, as far as I am concerned, are all not considered. In other words it would be close to impossible for me to take offense to any contribution here.

Don’t need them all just some that are pivotal. The others will come even if only not to feel left out.

[quote]
TAPR was a great start to that) - no one person is going to convince them to move to some new software architecture. [/quote]
The smart ones don’t need convincing and convincing won’t work. Right? You touched upon it and I mentioned using Vulkan. It’s got to be good for them, good for business. Make life easier for their engineers and saving money as well because the engineers can roll out new stuff faster/sooner. Good for the consumer (also can be engineers) as easier and faster/sooner for new implementations which feeds back to the hardware maker/designer. For the end user it’s a seamless experience and the improvements/updates come faster/sooner.

[quote]
Then you have all the hardware differences between all those manufacturers to sort out that they could even get their SDR to fit this new software paradigm - that’s not trivial.[/quote]

These are details that get worked out as the project gets going.

[quote]
Then you have to deal with the software developers themselves and what OS this new architecture would be deployed to - that’s enough to draw battle lines right there with everyone adding their 55 cents on what the architecture should really do or how it’s not perfect.[/quote] Don’t think this matters that much nowadays. Is it easy? No but it’s being done.

[quote]
The only reason that Vulkan even did as well as it did is that there’s a HANDFUL of graphics manufacturers out there and they pretty much want to standardize because of all the different platforms out there that they have to be a component to. The money that’s wagging that dog isn’t them - it’s Dell, and HP, and IBM, and Sony, and Acer, and MSI, etc, etc. They have the deep pockets to drive a graphics standard that fits their platform architecture, but as you mentioned, Apple is on the fringe because they don’t want to play - it’s entirely proprietary for them and always has been.[/quote] I’m not an expert on Vulkan but I do know that the project sticks to technical merits over politics (or tail wagging).

Apple has their walls and for good reasons (and bad).

[quote]
SDR is different. It’s not a component to anything. It’s just what it is - somebody’s idea to make a better radio than the last guy did. Until you can get them all to standardize on how the radio is communicated to and what it produces it’ll still be the mess that it is. It’s a new technology, and just like VCRs and DVDs played out, until there’s one standard that fits, there’ll be a million ways to do it different until the strongest design keeps standing…and that’s not very likely in the near future.[/quote]

There’s a limit to improvements of making the radio better than the last guy. There are not so many novel ways to do things anymore. Here’s what I posted:

Melon* is a new generation SDR API that provides high-efficiency, cross-platform access to modern SDRs used in a wide variety of devices from PCs and consoles to mobile phones and embedded platforms and stand-alone devices.

SDR is not that different. I’m no expert and I’m a newcomer to the whole world of RF but in essence it’s analog/digital information.

[quote]
My money is on a TAPR-like design or the SDRs that work with several apps because they try to make it easy for the developers to interface with their radio. Until that happens, it’s going to continue to be a circus.[/quote]

Time will tell, it always does. I think it’s inevitable that something like Vulkan will take shape. It would be good to have it sooner.

This idea goes far beyond Ham and SDR hobbiests and just to be clear I have very little skin in the game. I’m just a sufferer of the current situation and being a newcomer I decided to write about this before I become a part of the problem. Or put another way, I get sucked in and can’t see the forest for the trees no more!

6

@hTo137,

Read your response and generally agree with what you’ve written. I’d love to see something like this happen but right now I’m not seeing enough commonality in all the SDRs that are being designed (in terms of the interface details - they ALL process RF and generate I/Q) that, like any other standard being considered, the biggest will impose - ‘a standard’ - and the rest will review and argue it until they get to some kind of middle ground where the rest of the market will soon adopt and follow. Again, I’m just not seeing any of the SDR manufacturers - no matter what it’s used for DC to daylight - setting up any interface standards or putting them out there for anyone to cast the first stone. Like I mentioned in my prior post, no one person is going to light the world on fire, it’s going to take one of the major manufacturers (like Lime Microsystems, Ettus Research, Nuand, SDRPlay, Flex Radio Systems, or the like) to come forward with - ‘the standard’ - and then see where it leads. I really don’t think that’s the way it should be played out. Frankly, - ‘the standard’ - needs to come from a think tank, IEEE, or some other independent research body that has the means to examine and set the course correctly based on their review of the landscape free of any ‘political’ input from a sheer financial perspective of the larger SDR manufacturers and ‘how they did it’.

I just think that’s a ways off yet because if you really look at how long SDR has been out there (and let’s not get me started on things like JTRS and other earlier attempts of doing software defined radio 10 years or more ago), for the consumer market SDR has been in the viewfinder for about 6 years, and affordable within the past 4 years (getting more affordable). SDR today is a novelty and the novelty hasn’t worn off yet from all the colorful GUIs and signal analysis capabilities - - but when it does, someone will try to organize things. Then what you’re wishing for may happen.

The time is coming, but llke they say it ‘downtown’ - “…it aint here yet…” and I don’t expect that it’ll arrive until someone who has no skin in the game but all the knowledge can produce a standard that makes sense and that all manufacturers, hardware/software designers will line up for. But I really think that guessing the numbers for the lottery is more predictable…

7

SDR is far past the novelty stage. The rtlsdr dongles, to me, represented the novelty stage. But when I look at all the things that are done now, it’s clearly no longer a novelty. Finding pulsars, rocket telemetry, cell towers, cell repeaters, gps repeaters, etc., etc.

There are SDRs showing up in all different places now. But maybe the RF world keeps going to fractalness. The would serve some well and others not so well. Myriadrf is a good example that some cohesion and openess is sought. And it’s proof that model serves a lot of people well.

IIRC Vulkan started off as some stakeholders with technical expertise getting together and talking it over out of public scrutiny with the intent to make the final product public. That is a good model and is humane and correct. And I think they slowly trickled out certain aspects of the ideas as they matured to get some community feedback.

If it never happens it will still always be needed. I think there’s a lot at stake. Some would see it locked up and only pay-to-play.

Just to reiterate…the whole thing has to be based upon technical merits/aspects. It can’t be about a single company or conglomerate or cabal or tribe or syndicate or whatever. And the technical aspects will be argued over and will remain technical.

8

@hTo137,

Good luck with that…

MJ

9

[quote=“martywittrock, post:8, topic:1354, full:true”]Good luck with that…
[/quote]

Luck won’t be a player in this one. You have to think bigger, you’re thinking too small.

10

Perhaps a fresh and clean vendor neutral and platform independent SDR support library? :slight_smile:

1 Like
11

@andrewback,

Yes - and that would make a GREAT foundation to that new vendor-neutral SDR infrastructure since this has been adopted by SDRPlay, too.

73 de Marty, KN0CK

12

Yes the idea is right. But then why is adoption low? Maybe it’s just a matter of visibility.

Look at URH and SDRAngel, they both chose to not use soapysdr. Maybe their chosen implementation provides a clue to low adoption rate. I know I have bypassed APIs here and there just because it was actually easier to implement something than try to understand someone else’s abstraction (API).

This is where a central entity that is neutral could be important. The entity can gather the technical players and distill out the needs and then turn that back into the API.

Here’s another exampe of something good but that could be hampered by non-neutral party behind it. I think it’s a great idea and hope it gets wide adoption. And maybe it will just based on its technical merits alone.