Please see the link that I posted yesterday - it describes the issue
with AirSpy and VMWare, and provides a workaround (towards the end):
(under
VMWare Linux)
~iain
On Thu, Nov 29, 2018 at 3:13 PM wllmbecks(a)gmail.com [op25-dev]
<op25-dev(a)yahoogroups.com> wrote:
Hi all,
I was able to replicate the identical issue as trunktracker has reported. It turns out
to be a hardware virtualization issue in handling of the Airspy SDR’s running on Ubuntu as
a VM on VMWare Player and not an issue with the op25 code.
Normally, I use Oracle VirtualBox on a Windows-10 Pro 64 machine to run various Linux
VM’s including Ubuntu 18.04 with op25. That combination has worked perfectly using either
the Airspy R2 or the RTL SDR’s.. However, I installed VMWare Player 15 last evening to
experiment with Ubuntu 18.04 VM and boatbod op25 to quickly discover I got the same
results (error message) as trunktracker when attempting to run my Airspy R2. Conversely,
op25 did run perfectly on the VMWare Player setup as long as I only used the RTL SDR
device.
So it then appears to be some type of virtualization issue with the Airspy devices on
VM’s running on the VMWare Player. I don’t know that is necessarily the case on other
VMWare products such as the Pro version, and etc. But it’s definitely broken as far as
the Airspy is concerned with VMWare Player. Changing USB modes (support) in the VM
settings had not impact on the problem either.
I ran into a similar problem recently on my Windows-10 Machine where none of my SDR’s,
Airspy or RTL types would run on any of my Linux VM’s. That turned out to be a issue with
Windows Defender causing a corruption with the USB hardware virtualization in VirtualBox.
Bill, WA8WG
From: op25-dev(a)yahoogroups.com <op25-dev(a)yahoogroups.com>
Sent: Wednesday, November 28, 2018 6:48 PM
To: op25-dev(a)yahoogroups.com
Subject: Re: [op25-dev] Re: Beginner's Guide To Setting Up OP25 From Scratch
On 29 Nov 2018, at 10:13, 'Trunk Tracker'
trunktracker(a)tampabay.rr.com [op25-dev] <op25-dev(a)yahoogroups.com> wrote:
Then I looked in stderr.2 and found this:
FYI this is a few bugs and bug fixes ganging up to crash.
The first bug was (it is fixed since *2016* -
https://github.com/gnuradio/gnuradio/commit/11973c64437683cc99c48eae9eb4db8…)
in GNUradio #528.
A work around was added to rtl-sdr (which is the "Trying to fill up.." message)
which is at
https://github.com/osmocom/gr-osmosdr/blob/5ecfa255d299b9b4842ccd09a02892a8…
The second bug is p25_demodulator.py crashing because it doesn't detect self.decim is
zero.
It looks like gr-osmosdr now has the work around removed (since July 2017) -
https://github.com/osmocom/gr-osmosdr/commit/ea6b356cfda8a90fa6d727fcc13aae…
tl;dr:
- It didn't find your hardware, check your VM pass through
- Update gr-osmosdr to get less confusing errors :)
--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum