SDR Hardware and Low-Level Drivers

[Dirk_SDR]

If we (users) want to use a (new) SDR receiver, we must use so called SDR players like SDRsharp, HDSDR, SDR++, SDR Console, SDRuno...
But as interface between hardware and player there are DRIVERS of different type:
- Winrad ExtIO
- Osmocom
- SoapySDR
- ...
and with different tasks:
- USB
- TCP
- ...
and for different OS:
- Windows
- Linux
- Android
- ...
Of course the players and drivers have to be programmed.
The players are mostly maintained by very good and engaged programmers keeping their programs up-to-date.

The situation with low-level drivers is different:
Some hardware developers sell their receivers with good drivers, other don't.
Then many programmers work on different types of drivers mostly for no money and in their free time.

This is all not new, so why do I write it here?

I think, the situation could be much improved for end users:
1. Each new hardware should be supported by the developer with fully functional low-level drivers/firmware.
2. The main OS (e.g. Windows, Linux, Android) should be supported from the beginning.
3. The different types of drivers (ExtIO, Osmocom ...) should be simplified by reducing them to only ONE kind of "common driver type".
4. SDR players should on the long run only support this one common type of driver and should work together with hardware developers to describe and implement such a common driver type standard. Then drivers for new hardware could be developed much faster.
5. All hardware settings of each receiver should be realized by an own window by the driver's UI and not as SDR player settings somewhere in the player's menues.

Only my thoughts?
What do you think?

 

[ArloG]

If we (users) want to use a (new) SDR receiver, we must use so called SDR players like SDRsharp, HDSDR, SDR++, SDR Console, SDRuno...
But as interface between hardware and player there are DRIVERS of different type:
- Winrad ExtIO
- Osmocom
- SoapySDR
- ...
and with different tasks:
- USB
- TCP
- ...
and for different OS:
- Windows
- Linux
- Android
- ...
Of course the players and drivers have to be programmed.
The players are mostly maintained by very good and engaged programmers keeping their programs up-to-date.

The situation with low-level drivers is different:
Some hardware developers sell their receivers with good drivers, other don't.
Then many programmers work on different types of drivers mostly for no money and in their free time.

This is all not new, so why do I write it here?

I think, the situation could be much improved for end users:
1. Each new hardware should be supported by the developer with fully functional low-level drivers/firmware.
2. The main OS (e.g. Windows, Linux, Android) should be supported from the beginning.
3. The different types of drivers (ExtIO, Osmocom ...) should be simplified by reducing them to only ONE kind of "common driver type".
4. SDR players should on the long run only support this one common type of driver and should work together with hardware developers to describe and implement such a common driver type standard. Then drivers for new hardware could be developed much faster.
5. All hardware settings of each receiver should be realized by an own window by the driver's UI and not as SDR player settings somewhere in the player's menues.

Only my thoughts?
What do you think?

I'm compelled to reply. Although not 100% qualified to be totally accurate. Some comparisons might help.
If what you state in the opening were true. You could take a Ford ECU that operates the engine and plug in a...Porsche dashboard and instrument cluster. In a real world you could. In the form of an interface. EXTIO drivers of sorts.
Would Ford release their code of the data stream and commands to communicate with the dash electronics? And Porsche doing the same?
Highly unlikely.
With a plugin interface (look up Maestro steering wheel interface for aftermarket car stereos) that when the ECU sends 'bob'. The interface sees it and translated it to 'hans'. Back and forth.
I don't know about Realtek. A bit though. They do it. But Broadcom is one mfg. that either does release source code for developers, or doesn't.
Or presents a ton of legal papers assuring non disclosure with severe penalties if their proprietary information is leaked.
And providing a way for developers to communicate with their engineering team to provide drivers that the dev. can test bed.
SDRPlay has their API manual available so an SDR "Control panel" (aka: 'real radio receiver') can be interfaced. So when you tell the radio you want to tune up manually. Or with direct keyboard entry. The radio internal electronics accepts the commands.

One thing comes to mind. The ASUS Transformer tablets had (have?) source code available to allow a developer to cook up their own flavor of the Android operating system. And there were tons of guys who did.
Windows, Linux OS can for the most part be installed on many platforms. The installer is smart enough to probe the main board hardware and peripherals and identify, then install the correct (or almost) correct drivers. For a PIII, 4, etc. processor, Realtek Ethernet chip, Winbond controller.
Apple on the other hand. You can only slide the installer disc in the optical drive tray or USB stick. In a genuine Apple computer. With Apple, or Apple approved chipsets. With an Apple approved GPU and such.
If on Saturday evening your graphics card or Ethernet card goes south. You're not running out to the computer store and getting a replacement.
Hence why the Hackintosh team has made it possible to use a regular pc to install OS X with drivers in the form of kext files.
And how Apple must be pissed that schematic and board views were leaked so that your Genius Bar guys that condemn your device can actually be repaired. $200-$500 to save $2500 of what would be scrap and lost data by the brainiacs. Yeah.

USB. As handy and apparently quite well at doing the job. Is still behind TCI/IP. Industries that once used serial cables, parallel cables to communicate to a PC and various peripherals. Have jumped right over USB in favor of TCP/IP. That is what I've largely seen and retain my opinion on.

Airspy are quite buttheads. They used to allow the use of different SDR radios. Someone got a wild hair and decided that everyone needs to get an RTL based device. I use SDR# so seldom. I may be wrong. The whole "cease and decist" order from the developer of the USRP interface that allowed users with EXTIO devices was just plain stupid.
My go-to SDR application is simply HDSDR for my Icom IC-R8600. And SDRPlay radio.
I can tune the radio, change modes, frequency bandwidth. Punch in a frequency with my pc keyboard. Mouse around easily.
All without 40-eleven screens to jump through.
But definitely kudos to Simon over at SDR-Console.
And you. DSD+. You suck. RTL RTL RTL. Like that guy you voted for says. "Come on, Man!"

A standardized driver is quite far fetched. That would mean every SDR radio would start out as an ASUS tablet with source code at your finger tips.

 

[Dirk_SDR]

Can underline nearly everything you say.
I also like to use HDSDR. This player is a good example to show what I mean:
It can handle nearly every SDR hardware with ExtIO drivers. The range is from simple RTL-SDR sticks up to so called Nextgen SDRs like the RX-888.
So if you would call the ExtIO drivers "common drivers" (like I suggested in my post) and all players would accept these common drivers, then this would be the standard I'm talking about. As you can see with SDR#, the use of ExtIO drivers could easily be implemented and finally removed again.
Every SDR player could be programmed to use ExtIO drivers (or another "common standard type").
Then for new SDR hardware only ONE driver type would have to be programmed and not an Osmocom, ExtIO, SoapySDR, ... driver,- and Simon perhaps could also use that common driver for SDR Console (perhaps in another world also Youssef).
Now what about Ford and Porsche?
Of course there are such SDRs with highly different abilities. But the common driver I'm talking about is only the interface between player and hardware with a certain set of commands, status report messages, streaming functions and a user UI displayed on top of any player prog, which could be defined as a standard and used with nearly every SDR hardware. Very special functions (e.g. dealing with Cypress USB hardware on the RX-888) could be separated into a special firmware part.
Maybe I'm dreaming ...