I'm not going to attempt to duplicate all the detailed documentation here. Rather, I will provide links to various websites that will give much better insight than I can.
OpenWebRx+ runs in a virtual Linux environment on Windows 10 or 11. I used Windows 10. The image is built for an application called Docker, which allows you to run OpenWebRx in what is called a container within that virtual environment.
So, first, you will need to install Docker. Here is the link that describes the steps to do that: Windows Installation. The documentation describes how to install WSL - Windows Subsystem for Linux, and to turn on vitualization, all necessary steps to get Docker running.
Docker is free for personal use, but you might have to provide an e-mail. I did, but later discovered that there may be ways around that by just ignoring the input form.
Once you get Docker working, you start it up, and search for the OpenWebRX container. Docker has a library of all these containers, or, at least, maintains a search engine pointing to them. The search should be a menu item on the top - you may have to go into a packages menu item first, I can't remember. You will then see a whole whack of containers for both OpenWebRX (which the software is based on) and OpenWebRXPlus. Choose the one that looks like 'slechev/openwebrxplus' with '-full' on the end. That contains the drivers for all the supported SDR's. You then Pull the container into the Docker Engine.
At that point, you are almost ready to go. But one of the problems is that programs running within WSL cannot directly access USB hardware. So you have to download another software package, USBIPD. Download the latest version, and run it. Before running, ensure that your SDR with the proper Windows drivers is plugged in.
Go into Powershell, and type 'usbipd list'. You'll see a list of USB devices, with info such as Bus ID, PID, a description. Take note of the Bus ID for your SDR. Then type 'usbipd bind -b xxx' where xxx is the Bus ID. Finally, type 'usbipd attach --busid xxx --wsl', again where xxx is the Bus ID. You can now access the SDR from within WSL.
Just a few notes about the USB issue. The bind will remain across computer reboots. The attach will not - you will have to type that last command after each reboot, or put it in the your startup menu. But before you even do that, you have to start WSL - again, all you have to do is to type in that command, or put it in the startup menu.
Now, finally, you are ready to start.
Here is the link to the installation page for OpenWebRX+. You must, and I repeat must, type in all three commands within Powershell exactly as they are detailed in the Installation section. I removed the '\'s and just put each of the commands on a single line (the way they're in the documentation, you would need to put them in a batch file).
In particular, the last command is very important, as it sets up the administrator user for OpenWebRX+ so you can change settings. Remember the password. I forgot it and had to reinstall everything. Yikes!
The Docker Run command will create a separate, running container for OpenWebRX+. You can stop the container and restart it, but do not delete it. Otherwise, you will lose all the changes you've made to your configuration. I also did that, and it was painful.
It's not entirely clear what shell to use for these commands. For example, WSL has a shell, and you can create a shell within your Docker container as well. I used plain old Windows Powershell and everything appears to be working. Docker itself has to be run within Windows, as it's a Windows app, so it makes sense. Not entirely sure how though; one day I'm going to dive into the source.
The -p option in the Run command lets you specify the port to connect a browser. You'll have to open up that port in your router if you want to let Internet users access the SDR.
I ignored plug-ins. A project for another day, and it may clarify some of the directory & shell questions.
Using the administrator account I created, I deleted all profiles except for the one to access Artisan Radio. I also attempted to reduce bandwidth by reducing the number of lines in the waterfall display to 3/second (anything less made no difference). Bandwidth is usually somewhere between 225-250kbps, which isn't bad, about double an HD mp3 stream (which is usually 128kbps).
As a user, you can change the display of the SDR data in a variety of ways, but you can't change the profile or any of the major settings (such as #users, various decoding methods, etc.).
If anyone wants to try this, let me know if I've introduced any errors into the process. You will have the benefits accrued from my experiences, but I may not have remembered everything I did. As you can see, there is far more prep work required than any of the documentation suggests, particularly for Windows users.
I should have said that bandwidth for an RTL-SDR with limited bandwidth (1-2Mhz) generated 225-250kbps network traffic. Other SDR's with more bandwidth, such as the SDRPlay, will generate more, maybe much more.
I tuned in and listened for awhile to the Artisan Radio SDR and found the audio quality and musical selection of such high fidelity that it was difficult to turn it off.
'I Want to Be Happy Cha Cha' with Enoch Light and the Light Brigade from 1958 reminded me of the trouble I got into by sneaking my copy of that record into the FM station where I worked and playing it on the air. The record was banned by management because the crisp percussion and cow bells caused 'shh-shh-shh' interference on the sub-carrier that sent background music to retail stores and doctors offices. I still have both volumes of those records.
Re virtualization on Windows. It should be noted that there are 2 ways that Docker supports - WSL and Hyper-V. WSL is recommended and the way that I went. If you go the other way, you'll be on your own.
After rereading the documentation, there are a few things that are unclear.
When you do the Docker Run command within Powershell, it will come back with an ID, basically a long string of numbers and letters, and then you are brought back to the Powershell prompt.
You can see the running container within the Docker desktop. Keep it running - I start it each time after a reboot, and I start WSL and do the USBIPD attach command. You'll see 2 containers - the original one you pulled from the container library, and the now running one. It is the latter that you can stop, and restart if you want, but do not delete it. It contains all your changed settings, and you'll have to redo them if you delete it.
That container usually starts running again after a reboot, and you restart the Docker desktop, so make sure you've started WSL and attached the Bus ID of the SDR to WSL.
You can refer to the running container by either its name, owrxp, or the ID that was generated when you first ran it in Powershell. The short form of the ID is also displayed within Docker.
You can create other OpenWebRX+ users while the container is running with that 3rd command I referenced back in the original documentation post on running the container (Docker exec -it ...). That sequence lets you pass through the commands following it to the running container.
Essentially, WSL and Docker are hacks to get Linux apps running on Windows, and not very good ones at that. You're better off going straight to Linux with a separate computer - it's much cleaner. If you recall, there were several unresolved modules with OpenWebRX+ when I did that and I got stuck. That's a fault of the documentation on the web. There is further documentation within the running OpenWebRX+ (inside a settings menu item, no less) that gives instructions on how to fix that - basically, you have to install two more undocumented (at least outside of these instructions) packages within Linux. I haven't done that yet, but will.
Ah, the trials and tribulations of using open source software. Basically, software written by hackers who dream of being software development professionals. Don't get me wrong, they're smart, they're creative, but totally undisciplined. You can complain all you want about Windows and other professionally written software, but the scale there is orders of magnitude over most open source stuff (including Linux). You just can't do it properly without some form of process (formal project management), rigorous testing and documentation. I know, because I was involved in large scale software development while working for Microsoft.
Thank you, ArtisanRadio, for posting this.
Joe
N3PKC
FN21 NE PA
I'll post some documentation to install on Linux (Ubantu anyway) once I get it working there. The web documentation, so far at least, is more accurate for that platform, but I wasn't able to get to the interesting parts yet (such as communicating with the SDR via USB) due to unresolved references.
I believe that issue is resolved (no pun intended) and when I get some time (and patience) I'll try to take it to the next step there.
I received my 3rd SDR today, an SDRPlay (the first 2 were the RTL-SDR V3 & RTL-SDR V4). V4 does not appear to be supported by OpenWebRX+.
I'm in the process of following my own documentation and installing the OpenWebRX+ environment on another Windows computer with the SDRPlay. The eventual intention is to use it as an SDR for the AM broadcast band, so that users can monitor another version of Artisan Radio on that band.
Programming will be different, due to Canada's pretty silly laws regarding unlicensed broadcasting (you can't rebroadcast an unlicensed signal on another transmitter - I suppose that's to prevent transmitter networks which aren't explicitly banned in the U.S., although there is some verbiage in the Part 15 laws to limit that).
As a matter of interest, I've also just ordered an Hack RF One, an SDR receiver/transmitter. The software packages I'm using support it as a receiver, but you have to use something like GNU Radio to use it as a transmitter (and that will be another challenge, I believe). The intention for this one is to experiment with it on the amateur radio bands.
I've started the installation of Docker on another computer, to act as a server for the SDRPlay I recently received, and more clarification is required on the installation of WSL on Windows.
First of all, not all computers will support virtualization. If you go into a command line as administrator, and type in 'systeminfo', you'll get a bunch of, well, system information. Down near the bottom, it will have a line for something like 'Virtualization in Firmware' and a yes or no. If no, your machine doesn't support it, and you'll have to use another computer. I ran into this. It will look like things work (using the instructions below), but when you reboot, WSL attempts to start up and fails.
If your computer does support virtualization, the easiest way to install WSL is to go into Powershell, and type 'wsl --install'. It will install WSL and also set up virtualization. It's equivalent, but easier, than going into the Windows Features area of Control Panel, and selecting Windows Subsystem for Linux and Virtual Machine as described in the documentation I linked to.
I will integrate this into the final version of the documentation, but will update this thread as I find things during this new installation.
More documentation clarification (and some reinforcement). I must have just gotten lucky with my first installation of Docker, as things worked pretty much right away.
First, it's important to ensure that virtualization is enabled in your computer's BIOS settings, in addition to installing it in Windows. Where it is in the BIOS depends on the computer. Some of my computers have a separate menu for it, in others you have to go to Advanced Settings > CPU. Some computers have this enabled by default, in others you have to enable it (another one of my problems in the 2nd installation of Docker and WSL).
It also appears that Docker will not install properly in Windows 10 Home (don't know about Windows 11 Home, as I don't have it). It installs in all my Windows 10 Pro computers quite nicely, once you get past the virtualization issues.
Docker is supposed to run in Home, but only Linux containers. I think that OpenWebRX+ is a Linux container (although the precise meaning of all this is a big vague, you've got Docker running in Windows, but using WSL, there are multiple shells - yikes!). Anyway, the point is moot, because I just get this vague Installation Failed error, and the only difference I can see between this attempt and all the others is that the others are being installed in Windows 10 Pro.
Docker also requires quite a bit of HDD space, you need at least 5GB free & ideally a lot more. It will clean up a bit after being installed, but can easily run out of space if you're not careful.
The more I do with this software, the more I see how much of a hack all of it really is. If OpenWebRX+ wasn't the only SDR supporting software with a browser interface, I'd be tossing it.
This software is like a house of cards. Do one thing out of order and the whole thing comes tumbling down.
You have to start WSL in a command windows before doing anything, or things just don't work. Even after running it.
You cannot restart the Docker Desktop if you close it. If you attempt to run Docker without first having WSL started, it fails and cannot be restarted.
The only way to get an SDRPlay installed is to install SDRuno, which is the bundled software. It contains the drivers and a user interface. So you have to install SDRuno before you can attempt to start Docker.
I'm pretty close on this 2nd installation, but we'll have to wait and see. Lots of reboots.
I'm going to have to rewrite the documentation, incorporating all these warnings and changes. There's no way I'm going to attempt to get any other SDR running within OpenWebRX+ - it's all just far too delicate.
Last message on this topic. I managed to install the software with SDRPlay, but the computer was too slow. It was an older i3 running Windows server stuff plus all the OpenWebRX+ software and it stuttered like crazy. So I will redo the steps once again on another, much faster, computer.
I had some issues with getting the SDRPlay recognized within WSL using USBIPD. It turned out that that was resolved by switching to a USB port in the front of the machine. Don't know why, as SDRuno ran with the SDRPlay connected to the back USB port. If you run into issues (you can see your USB devices with the 'lsusb' command within WSL), just try switching ports.
Anyway, after I install on yet another computer, I will start a new thread with updated and hopefully more complete documentation. You never know what else I might run into, and I want the next set of documentation to be as concise as possible.
By the way, I mentioned previously that the USBIPD attach command didn't last across boots. You also lose the USB device within WSL if you detach the cable, and then reattach it. If that happens, you'll have to do another 'attach', and then restart the OpenWebRX+ container.
After about 3 weeks (and it could have been a bit earlier), the OpenWebRX+ server seemed to have died. On the client side, it would bring up the page, but no waterfall display or sound. On the server side, it was still running, but there were obviously problems.
A server reboot brought it back up, no issues (except that I first had to open a command windows and enter wsl, as I documented, followed by doing the 'usbipd attach' command to let Docker have access to the SDR - the attach does not last across boots).
I took the opportunity to switch Decade transmitters. I have 2, one of which has an RDS input in the back. I don't use that (I generate the RDS signals all in software) but I figured that the transmitter might have a few modifications to pass through RDS frequencies a bit better. On the other transmitter, RDS did work, but had errors - on this one, it appears clean. So I'll stick with this one for a while.
I've been having issues receiving the AM broadcast band with all of my SDR receivers. It's actually quite a comedy of errors. OpenWebRX+ doesn't work with the SDR-RTL V4. The V3 works, but doesn't appear to have direct sampling (required for the AM broadcast band) so it may require an up converter. The SDRPlay sort of works with OpenWebRX+ for a while (although the sound is choppy) and then it fails after a few minutes, so something is going wrong there.
I can get the V4 working with SDR++, but the server doesn't work with a browser. I can get the SDR Play working with SDRuno, but it is not client/server. I got the V3 working with SDR++ as well, but it's now being utilized by OpenWebRX+ for the FM station.
I just got my HackRF One, so I may try to get it working with OpenWebRX+ and Docker. It should just plug in and work, once I install the right driver (and usbipd attach it to wsl). It's worth the minimal effort, at any rate.
I know your post is a moth ago, but didn't know where to put it.
I noticed the OpenWebRX player actually had the AM button engaged by default (as opposed to WFM) upon entering the page, which I thought was cool. But I know from your post in other threads that it caused problems.
But that's not what this is about. Lately I've been getting this grey box that I cant turn off, it doesn't display anything and doesn't seem to do anything.
It didnt use to be there and I cant get rid of it no matter what windows I turn on or off.
Yeah, that's one of the issues with the software that I want to fix at some point. Unfortunately, it means going into the code.
That box is meant to display RDS information for Wide FM. I've turned RDS off, but there are no user (or even Settings) options to get rid of that box in the visual display.
Another issue that you can get rid of the graphical display at the top, but not the waterfall, which I find annoying at times. It's not all that accurate, either, as the antenna is so close to the transmitter that it overloads the front end, resulting in that whitish color across the spectrum.
But it wasn't there before. It just showed up within the last couple days.