I just logged in with the thought of asking you what kind of antenna you intend using, but you already answered the question.
Welcome to the junction of Software Defined Radio and Part 15! This is a major theme park of fun!
OK, I have a lot of new info. Hopefully I can remember it all.
It turns out that SDR++ server is really just SDR++ run from a command line with a few options, and you still need SDR++ on the client side to listen. Not exactly what I was hoping for. It works fine, but the bandwidth requirements are crazy. Over 10Mbps with compression, and over 100 Mbps without compression. Now, I haven't yet gone through the documentation sufficiently to see if the viewed bandwidth can be narrowed down (it defaults to about 2.5 Mhz). Hopefully it can, with a corresponding reduction in bandwidth.
Unfortunately, the only browser-based client/server SDR software I have been able to find is OpenWebRX, which, if it is supported in Windows, I haven't been able to find. There's OpenWebRX and then a fork, OpenWebRX+, but it only appears to run under MacOS and Linux.
Now to the downside. Instructions on installing this software are really, really poor. The only reason SDR++ worked quickly is because I had gone through the laborious process of installing the drivers when attempting to install SDR#.
I had to install SDR++ on another computer to run the server, and at first, it just didn't work. No errors, no messages, just nothing showing up on the receive display. Typical open source software. The Quick Start Guide stated that drivers came with the package, and they appeared to be there, but the program didn't do anything. I had to go through the driver installation process that I went through for SDR#, and then run SDR++. At that point, things went a lot more smoothly.
I have to wonder about these developers. I appreciate free software, don't get me wrong, but it wouldn't take much to write proper installation instructions. It would also be nice to have some error messages if catastrophic things error.
Anyway, we need to get the required bandwidth down at least several orders of magnitude. Listeners would still have to install SDR++ on their computer. It's relatively simple to set up to get input from a server, but even then it's not exactly turnkey. So it's not looking promising.
I would imagine that most of the other SDR software packages would operate in the same way. You'll need to install the SDR software on a computer to listen to the server.
I'll continue to report as I find out more details.
I believe this is the type of data stream you get from your SDR.
Mattress springs, shock mounts and spin cycles. A spectral pogo stick.
There is still hope.
The developers of OpenWebRX+ (and RX) have created images for Linux that can be run in a virtual machine on a PC. They currently support an app called Docker.
Like most open source projects, documentation is terrible. Even though I installed Docker, it was not able to find the image for the application using the documented commands. Either I did something wrong with Docker, or things are screwed up on the image end.
I'm giving up for now, but will try to install on the actual server computer tomorrow. I'm not holding my breath, as it's now more of a curiosity to see if I can actually get it done.
Accomplished a lot today. The SDR works. Eliminated some programs from consideration. Got one working. Got a server working but requires too much bandwidth. Reinforced my belief that a web interface is the way to go, if only I can get the server software running on Windows.
I suspect mp3 streaming will still be the way to go after all is said and done.
Starting up this Friday morning I have decided to designate Artisan radio as the Official SDR Server Research Project and suspended my own efforts along the same line.
I had intended using this U.S. 3-day upcoming holiday weekend as a time to upgrade my server computer to Windows 10, but uncertainty over the process makes it easy for me to shelve my plans pending the outcome of Artisan's work.
In the longer outlook I am contemplating installing an SDR on every computer in the house.
The biggest impediment to getting things going is documentation. Most of the software is coming out of the Linux world, and there are a lot of assumptions made as to the level of knowledge. If you're diving into the world of SDR's from the Windows world, good luck.
At one point, I was considering grabbing the source code for a lot of these packages, and creating my own server. But I've had experience modifying open source software, and it isn't pretty. Virtually no inline documentation, and certainly no overall description. The modifications I made took me about an hour, including testing. It took days to figure out exactly what was going on in the software before making the modifications.
At the end of all this, I plan on writing up some simple instructions on how to get at least one of these SDR packages running (including the server). I'm hoping it will be the web-based software, but I have my doubts.
I forgot to mention that I did get bandwidth for SDR++ client/server to around 3 Mbps, by lowering the bandwidth (the amount of spectrum being displayed, which limits the data being sent to the client by the server). But that was with a bandwidth of 250 Khz, which was the minimum for the RTL-SDR (each SDR will have different limits). Still not really acceptable for any kind of Internet work (although OK for LAN's).
Having now abandoned the many eager hours spent delving into the spaghetti bowl of SDR circuitry I have been sitting with a vacuous blank stare and a debilitating sense of not knowing what to do. Just like a child complaining, "Mommy, I'm bored". There must be some grand and noble purpose I could spend my time on, and that's what I'm waiting to suddenly think of.
.
I have some good news, and some bad news.
I managed to get OpenWebRX+ running inside Docker and a virtual Linux machine. I was able to connect to the server using a browser. Unfortunately, the server would not recognize the RTL-SDR dongle.
There are 2 potential reasons for this. I had to go through a whole process to get the USB dongle shared with the Linux virtual machine. That may not be working correctly.
It could also be that the server does not support the V4 Blog dongle (the latest).
So I'm stuck, and giving up for the moment. I know the dongle works, as SDR++ (both server and client side) work with it.
Carl, you may have given up prematurely. I think the next step is to try out OpenWebRX+ on another SDR, and since you have an SDRPlay, that would be ideal.
If you're willing to do that, I will document (not now, but in the next day or so), the steps I went through to get Windows to support virtual machines, the installation of Unix and Docker, and getting the app to actually run within Docker. Finally, sharing the SDR hardware with the Linux virtual machine. You can't rely on the available documentation.
This has actually been a very frustrating day except for when I got the server working (sans dongle) in a browser.
And people expect AI (which is orders of magnitude more complicated) to work flawlessly? Hey, do I have a lot of land in Florida to sell them.
@ Artisan-Radio Once I figure out what you've asked me to try I will do it. The SDR is too fascinating to abandon. It is highly intelligent while in no way being artificial.
What we want - that is the collective we in this thread - is an SDR server program that will capture the IQ data from the SDR, process it on the server side according to whatever parameters have been set up by the listener, and then send the resulting UI data and audio to a browser on a remote computer.
The only program(s) I've been able to find that does this is OpenWebRX and a fork, OpenWebRX+. All the others, SDR++, SDR# etc. have the server gather the IQ data from the SDR, and then send it to the client for processing. That's a heck of a lot of data. Orders of magnitude more than just UI and audio data.
So OpenWebRX appears to be the way to go.
Unfortunately, it only runs on Linux. It would be ideal to configure a server computer with Linux and run the program on it. That is one solution I'm going to eventually try.
The solution from the developers of the program to run cross platform under Windows is pretty brain dead. Windows is capable of running Linux as a Virtual Machine (WLS - Windows Linux Subsystem). The developers created what is called a Docker container - this is really just a program which can be run under an application called Docker (which runs cross platform), and on Windows this container runs under the WLS.
The theory is that you write the Docker container, and then you can run it within Docker on Windows, Linux, etc. because Docker runs in all these environments.
A much better way to write a program for cross platform use is to write it using a cross platform development environment, which contains different native run modules for things such as user interfaces for the various O/S's you're supporting. QT is an example of one such IDE (Interactive Development Environment). Programs developed under QT can run under Windows, Linux etc. You just need to link into the program the native run modules for your O/S. The downside is that instead of creating a single, Docker image, you have to create images for each of the O/S's you want to run under. But still not a very big deal and you avoid a lot of issues you get running in a VM.
The developers of OpenWebRX didn't bother taking the time to make the software cross platform. They admit Windows was an afterthought, and Linux is their focus. And as I stated before, there are plenty of issues running in a VM. One is that it's difficult to communicate with real world hardware in a virtual machine (it is virtual, after all). WLS in Windows doesn't support this, so you have to rely on other software (again, open source) to allow you to do it (and this is one of the potential reasons why I can't get OpenWebRX+ to communicate with the RTS-SDR I have).
Another issue is that if something fails, it's difficult to track down exactly where and why it's failing. You get error messages in your Linux VM that may not correspond exactly to what is going on in the real Windows world. In the case of the error I'm getting, with the RTL-SDR failing, it could very well be that the program running in the Docker container (in the VM under Windows, yipes) does not support the latest version of the SDR.
So we have to approach this systemically. I'm hoping that once I get the installation process documented for Windows, Carl can try out the program with his SDRPlay. If that fails, then we know that there's something wrong with the run-time environment, probably the issue of the driver communicating to the VM. The SDRPlay seems to be the go-to SDR for the program, so if it doesn't work, nothing will.
Meanwhile, I'm going to try to get the original program, OpenWebRX (minus the +) running, to see if I get the same behavior.
My final step would be to set up a Linux computer and install the software on it. That's probably the easiest approach, but since I started the Windows project, I really would like to see it finished, one way or the other. It may be the other.
I'm not going to be like some, and say that I don't like to speak ill of others, but...
I'm going to go ahead and speak ill of these Linux and open source developers. I'm sure they're brilliant within the very limited context they work in, but if they're attempting to get their software 'out there', they're going about it the wrong way. Limited, poor documentation. Documentation that is just plain wrong. Source code that is difficult, if not impossible to understand without large amounts of effort.
It's like they're saying that if it's difficult to write, it should be difficult to use and understand.
In some ways it's an ego thing. Create an aura of mysticism surrounding what you do, and people will bow down before you, seeking your wisdom and advice. Gee, reminds me of some in the Part 15 world.
In actual fact, the best developers go out of their way to ensure that their programs are easy to understand, easy to use and well documented. Because then they'll work by a large number of users with varying skill levels. They'll be easy to maintain, and it will be easier to develop new features. It's easy to make the process of writing software look difficult and obscure. It's far more difficult to make writing and using these programs look easy.
Gotta correct a mistake in my last post. It's WSL (Windows Subsystem for Linux), not WLS.
Anyway, I'm glad that I took some time off from the problem, and have just been thinking about it.
The more I think about it, the more I realize that installing OpenWebRX (either version, + or not) on Windows is a bad idea. Just too much of a kludge.
So Carl, I'm rescinding, at least for now, my request for you to try to install using SDRPlay.
I'm going to install Linux (Ubantu Server) on one of my spare computers, and try to install it that way. Better all around. In fact, I'm just flashing the bootable USB drive as I type this.
Ubantu Server is pretty much the same as Ubantu Desktop, but without the visual interface. That's OK, as I intend to use the command line only. My sole purpose for this is to get OpenWebRX running.
I'll start with the plain old OpenWebRX, and then maybe try the OpenWebRX+. We'll see.
@ Artisan-Radio Got it. I'll stand by and stand down, to borrow a phrase from a recent president.
Meanwhile, I'm also proceeding slowly as I circle around the question of upgrading a computer from Windows 7 to Windows 10. I'm fairly certain that it would be safe to find and download the Windows 10 ISO and go from there with a later plan.
Now I'm headed over to Mark's thread to talk about 'perfect women'.
After some trials and tribulations, I managed to get to the point where I was attempting to install OpenWebRX+ on a Ubuntu computer, and the installation failed with missing dependencies. Apparently, the software depends on an older version of Python (the programming language), but downgrading the python version in the O/S causes other things to fail. Linux is highly dependent on Python, and the latest Ubuntu version requires the latest version of Python.
I think I was closer getting the Docker image to run. I'm almost certain, upon further thinking, and further experience with the software, that it did not have the correct drivers. The RTL-SDR V4 Blog requires new drivers, and the software probably had the V3 drivers.
Most people using the software use the Raspberry PI as a server, and there is an image for it as well. I have no interest in that.
My final attempt to get the software going will be to purchase either a V3 dongle, or an SDRPlay, hook it up and see if the Docker container can see it. They're older pieces of equipment that should have working drivers. I'm doing this just to see if I can get the stupid thing to work. I have no plans on actually using the software beyond this experimentation, as I simply have no trust in it. I also want to compare another SDR to the one I have.
So, conclusions. Don't mess with OpenWebRX unless you can handle a lot of frustration. The other software packages, such as SDR++ and SDRRuno (I believe that's it for the SDRPlay) are far superior and actually work. They're not really client/server, as most of the processing is still done on the client side, even with a server. Obviously, OpenWebRX can and does work if the sun, moon and stars are all in alignment. My thinking, though, is that they're all using either Raspberry PI's or older Linux versions. I'm not going to mess around with it any more (other than what I stated previously).
I'll stick with my IceCast streaming.