Git Product home page Git Product logo

Comments (21)

luigifcruz avatar luigifcruz commented on May 27, 2024 2

@0xCoto I'm not sure if I can help. I don't have experience with the SDRplay SDK. The current release of PiSDR does not support the device yet. The manufacturer sent me a unit for integration but it didn't arrive yet. I'm planning to add full support in the next major release coming soon.

from virgo.

0xCoto avatar 0xCoto commented on May 27, 2024

Looks like we'll have to resolve the virgo.observe issue first, as the rest of the problems are definitely dependent on the acquisition of the data. The osmocom documentation includes some information on interfacing between your SDRplay device and GNU Radio.

Perhaps @luigifcruz can give an input as to whether SDRplay devices have been tested with PiSDR (or e.g. if a Soapy Source shall be used instead)?

What happens if you set 'dev_args': 'sdrplay'?

from virgo.

CEverest-RFI avatar CEverest-RFI commented on May 27, 2024

It comes up with the same error, 'No supported devices found'. I've tried rebuilding GrOsmoSDR, as in the documentation it says to build it using the parameter -DENABLE_NONFREE=TRUE to enable the driver, and get an error:

-- Build type not specified: defaulting to release.
CMake Error at CMakeLists.txt:45 (find_package):
Could not find a configuration file for package "Gnuradio" that is
compatible with requested version "3.9".

The following configuration files were considered but not accepted:

/usr/local/lib/cmake/gnuradio/GnuradioConfig.cmake, version: 3.8.2.0

-- Configuring incomplete, errors occurred!
See also "/home/pi/Desktop/gr-osmosdr/build/CMakeFiles/CMakeOutput.log".

Although I'm not sure whether this is worth doing as I'm not sure how GrOsmoSDR is installed on the PiSDR image in the first place.

from virgo.

0xCoto avatar 0xCoto commented on May 27, 2024

Have you got a 'Soapy SDR Source' block available in GNU Radio?

from virgo.

luigifcruz avatar luigifcruz commented on May 27, 2024

Maybe worth taking a look if the UDEV rules for the SDRplay were installed since the logs are mentioning that no device was found. This generally happens on make install when a certain flag is passed to CMake.

from virgo.

CEverest-RFI avatar CEverest-RFI commented on May 27, 2024

I do have a Soapy Source, but not specifically a Soapy SDR Source. I've tried replacing the source with the Soapy Source though, and set the drivers as sdrplay, but get the same error. As for the UDEV rules, where should I be looking, and what should I be looking for? I can find the 80-drivers.rules file, but that doesn't have any mention of SDRPlay.

I did find an official pi image by SDRplay, and in the description, it does say that GNU Radio source blocks are not avaliable yet for the RSPdx, so I'm not entirely sure theres anything that can be done until the image is updated.

from virgo.

0xCoto avatar 0xCoto commented on May 27, 2024

I remember having success getting an SDRplay device to work with Virgo (with gr-osmosdr), but it was a bit tricky to set up because their drivers are a bit outdated/incompatible with GNU Radio ≥3.8. Since you're using a somewhat semi-unsupported device, I'd suggest trying to downgrade to GNU Radio 3.7 and installing the drivers provided by SDRplay.

from virgo.

CEverest-RFI avatar CEverest-RFI commented on May 27, 2024

After having a look around, I decided to try updating gnuradio to 3.9, and installing the following to see if I could use the soapy block, and it seems to recognise and accept the RSPdx when testing:

https://github.com/pothosware/SoapySDRPlay3

although I am having another issue, but i'm not sure whether it would better to contact them, as I'm not sure whether the issue is with me misconfiguring the block or something else:

TypeError: primitive_connect(): incompatible function arguments. The following argument types are supported:
1. (self: gnuradio.gr.gr_python.hier_block2_pb, block: gnuradio.gr.gr_python.basic_block) -> None
2. (self: gnuradio.gr.gr_python.hier_block2_pb, src: gnuradio.gr.gr_python.basic_block, src_port: int, dst: gnuradio.gr.gr_python.basic_block, dst_port: int) -> None

Invoked with: <gnuradio.gr.gr_python.top_block_pb object at 0xb5bf0ce0>, <Swig Object of type 'gr::basic_block_sptr *' at 0xb5b30ef0>, 0, <gnuradio.gr.gr_python.basic_block object at 0xb1561300>, 0

from virgo.

luigifcruz avatar luigifcruz commented on May 27, 2024

As for the UDEV rules, where should I be looking, and what should I be looking for?

@CEverest-RFI Sorry for the delay. This PDF (page 4) details the installation process of the UDEV rules for SDR Play. https://sdrplay.com/docs/Mirics_SDR_API_Linux_install_technote_r1p1.pdf

from virgo.

CEverest-RFI avatar CEverest-RFI commented on May 27, 2024

I think there may be an issue with changing the source block, as I've managed to get a SoapySDR source block working with with the SDR, but changing any of the files, such as ftf.grc or wola.grc is not easily done due to permissions, but even when done (by copying them out of the folder then sudo mv them back in), the other files such as run_ftf.py are written assuming the osmosdr source block is in use, so even getting the correct source block would not be able to fix it without rewriting run_ftf.py and run_wola.py.

from virgo.

0xCoto avatar 0xCoto commented on May 27, 2024

Yeah, that makes sense. Your logic to sudo mv the grc files to the package directory is completely fair, but before you do that, open the grc and recompile (run the flowcharts). You'll probably have to rename the .py files to match run_ftf.py and run_wola.py, but other than that, replacing all 4 files (sudo mv to the package directory) should do the trick.

from virgo.

CEverest-RFI avatar CEverest-RFI commented on May 27, 2024

I tried regenerating the flow graphs, then sudo mv into the directory, but it can't seem to find run_wola:

Traceback (most recent call last):
File "/home/pi/.local/lib/python3.7/site-packages/virgo/virgo.py", line 514, in observe
from run_wola import run_observation
ModuleNotFoundError: No module named 'run_wola'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "Test2.py", line 17, in
virgo.observe(obs_parameters=obs, obs_file='observation.dat')
File "/home/pi/.local/lib/python3.7/site-packages/virgo/virgo.py", line 516, in observe
from .run_wola import run_observation
File "/home/pi/.local/lib/python3.7/site-packages/virgo/run_wola.py", line 29
def init(self, bandwidth=2e6, bb_gain=20, channels=1024, dev_args=, duration=60, frequency=1420e6, if_gain=20, obs_file=observation.dat, rf_gain=30, t_sample=1):
^
SyntaxError: invalid syntax

And there seems to be the other issue of this syntax. The formatting of the error is a bit wrong on here, the ^ should be underneath the end of dev_args=,

I then tried setting dev_args=0 (as in the .grc's they have a dev_args=0 variable, but I'm not sure whether thats the correct thing to do), but get the following error:

Traceback (most recent call last):
File "/home/pi/.local/lib/python3.7/site-packages/virgo/virgo.py", line 514, in observe
from run_wola import run_observation
ModuleNotFoundError: No module named 'run_wola'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "Test2.py", line 17, in
virgo.observe(obs_parameters=obs, obs_file='observation.dat')
File "/home/pi/.local/lib/python3.7/site-packages/virgo/virgo.py", line 516, in observe
from .run_wola import run_observation
File "/home/pi/.local/lib/python3.7/site-packages/virgo/run_wola.py", line 27, in
class run_observation(gr.top_block):
File "/home/pi/.local/lib/python3.7/site-packages/virgo/run_wola.py", line 29, in run_observation
def init(self, bandwidth=2e6, bb_gain=20, channels=1024, dev_args=0, duration=60, frequency=1420e6, if_gain=20, obs_file=observation.dat, rf_gain=30, t_sample=1):
NameError: name 'observation' is not defined

from virgo.

0xCoto avatar 0xCoto commented on May 27, 2024

For the syntax error, it seems to be a GR version issue (I'm planning to push a fix for this soon). Open the flowcharts and change dev_args and obs_file from Type: None to Type: String and re-compile.

When you compile run_ftf.grc you should see a run_observation.py get generated. Rename that to run_ftf.py and sudo mv the file to the installation directory. Do the same for run_wola.grc, but rename it to run_wola.py before sudo mv'ing. See if that works.

from virgo.

CEverest-RFI avatar CEverest-RFI commented on May 27, 2024

I did that, and managed to get the .observe and .plot functions to work:

plot

Although I'm using a small omnidirectional antenna, so I'm not sure whether any of the plot would be useful, apart from that gap in data on the left, which seems to occur every time its run.

I still can't get .monitor_rfi to work though, I just get the following error:

Traceback (most recent call last):
File "Test2.py", line 17, in
virgo.monitor_rfi(1415e6, 1425e6, obs_parameters=obs, data='rfi_data')
File "/home/pi/.local/lib/python3.7/site-packages/virgo/virgo.py", line 1118, in monitor_rfi
observe(obs_parameters=rfi_parameters, spectrometer='ftf', obs_file=data+'/'+str(i)+'.dat')
File "/home/pi/.local/lib/python3.7/site-packages/virgo/virgo.py", line 511, in observe
from .run_ftf.py import run_observation
ModuleNotFoundError: No module named 'virgo.run_ftf.py'; 'virgo.run_ftf' is not a package

from virgo.

0xCoto avatar 0xCoto commented on May 27, 2024

The gap is essentially masked RFI channels (manually input by the user). If you don't want to mask anything, check the virgo.plot parameters: you just have to get rid of the rfi=[...] argument.

As for the other error, it's not quite clear why it would occur, since virgo.monitor_rfi basically calls virgo.observe. It appears like it can't find run_ftf.py, but you're saying virgo.observe works fine?

Are you running everything with the same Python from the same script? What happens if you virgo.observe and then virgo.monitor_rfi in the same script? Does the first command succeed and the second fail?

(By the way make sure you don't have any local scripts or directories named 'virgo', as this may often confuse Python that you're trying to import a local module)

from virgo.

CEverest-RFI avatar CEverest-RFI commented on May 27, 2024

I get the same error with both in the same script. The first command seems to succeed, as I get a observation.dat and observation.header file out.
One thing I forgot to mention, was that when i first ran the python scripts, I got the ImportError: No module name virgo. So I used pip install astro-virgo (for both versions of python). Which gave me another copy of virgo in at:

/home/pi/.local/lib/python3.7/site-packages/virgo

Which was the one I modified, as when running the script this was the folder it seemed to run the .grc files from. Not sure whether that could be related or not, though.

from virgo.

CEverest-RFI avatar CEverest-RFI commented on May 27, 2024

Hi, just wondering if there is any update, or anything I can do that might help with diagnosing the issue?

from virgo.

0xCoto avatar 0xCoto commented on May 27, 2024

Hi @CEverest-RFI - Sorry for th late reply. Are you running everything from the same Python?

from virgo.

0xCoto avatar 0xCoto commented on May 27, 2024

Also, please share a screenshot of what the modified WOLA and FTF flowcharts look like.

from virgo.

CEverest-RFI avatar CEverest-RFI commented on May 27, 2024

Yes, I am running it all from the same python, which is python 3.7, as far as I can tell. The WOLA and FTF flowcharts are below:

2021-05-21-174941_2560x1440_scrot

2021-05-21-174944_2560x1440_scrot

from virgo.

0xCoto avatar 0xCoto commented on May 27, 2024

In case anyone's wondering, the issue ended up being some (accidental) modification of virgo.py, these lines in particular:

if spectrometer.lower() != 'wola':
    try:
        from run_ftf import run_observation
    except:
        from .run_ftf import run_observation

tried to load run_ftf.py instead of run_ftf. The file must have been named run_ftf.py.py to work.

from virgo.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.