Potential gnuradio 3.7/3.8 issue.

[SteveBz]

Hi Apostolos,

Then if I deactivate the vitual environment and install astro-virgo outside the virtual environment using pip3. I get

built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp 
[INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5
Found Rafael Micro R820T tuner
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
[R82XX] PLL not locked!
Traceback (most recent call last):
  File "test.py", line 25, in <module>
    virgo.observe(obs_parameters=obs, obs_file='observation.dat')
  File "/home/image/.local/lib/python3.8/site-packages/virgo/virgo.py", line 555, in observe
    observation = run_observation(dev_args=dev_args, frequency=frequency, bandwidth=bandwidth, rf_gain=rf_gain,
  File "/home/image/.local/lib/python3.8/site-packages/virgo/run_wola.py", line 107, in __init__
    self.connect((self.osmosdr_source_0, 0), (self.blocks_head_0, 0))
  File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 37, in wrapped
    func(self, src, src_port, dst, dst_port)
  File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 105, in connect
    self.primitive_connect(*args)
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 0x7f6f56290f30>, <Swig Object of type 'gr::basic_block_sptr *' at 0x7f6f51f5dea0>, 0, <gnuradio.gr.gr_python.basic_block object at 0x7f6f51f5e230>, 0
swig/python detected a memory leak of type 'gr::basic_block_sptr *', no destructor found.

So this is really nice. It detects the RTL.SDR and what looks like a syntax error.

Is this a gnuradio 3.7/3.8 problem? What should I do?

I have a beautiful waveguide just begging to be tested :)

Kind regards

Steve.

[SteveBz]

Hi Apostolos,

I tested a number of options:

gnuradio3.7 does not have a release candidate for ubuntu 20.04, or at least it fails to add.
gnuradio3.8 produces a different error (see below) and might be easier to fix.
gnuradio3.9.5 produces the above error and seems to install gnuradio3.8.
gnuradio3.10 also produces the above error and seems to install gnuradio3.8.

built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp 
[INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5
Found Rafael Micro R820T tuner
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
[R82XX] PLL not locked!
Traceback (most recent call last):
  File "test.py", line 25, in <module>
    virgo.observe(obs_parameters=obs, obs_file='observation.dat')
  File "/home/image/.local/lib/python3.8/site-packages/virgo/virgo.py", line 558, in observe
    observation.start()
  File "/usr/lib/python3/dist-packages/gnuradio/gr/top_block.py", line 111, in start
    top_block_start_unlocked(self._impl, max_noutput_items)
  File "/usr/lib/python3/dist-packages/gnuradio/gr/runtime_swig.py", line 4832, in top_block_start_unlocked
    return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
RuntimeError: list contains invalid format!

It uses that file top_block.py in gr, but I see there is already one in virgo, plus a top_block_old.py. Should it be using that one? I'm not sure how to direct it, apart from copying the top_block.py in virgo over the one in the gr directory.

Maybe I'll try.

Kind regards

Steve.

[0xCoto]

Hi Steve, is this a continuation of the previous issue you opened, or separate? Could you please check if the issue might be related to this and let me know of your suspicion: #7

[SteveBz]

No it's much better without a venv. They are not related.

[SteveBz]

The two different error messages, ie the the ones in 3.9.5 & 3.10 look like 7.

But the error when I install 3.8 as 3.8 doesn't look like a serious error. It looks like an installation or version error.

I think if I hacked it it would work. I'll try.

[SteveBz]

No, the hack didn't work. It made it worse. Sorry.

[0xCoto]

Hmm. I haven't really tried using gr in virtual environments. It is picky about which python version you use to run virgo though (it should match gr's version). I'd first try outside of the virtual environment. What error does it yield, and what GR version are you using? I'd suggest settling on 3.8 or 3.9. The issue described in #7 has an easy fix (just change a property in the flowchart and recompile). Have you had any past experiences with running GR, or is this your first time?

[SteveBz]

It's my first time with GR. Can you give me some easy instructions to fix the compile bug you mention, please? I'll reinstall and do that.

Kind regards

Steve

PS I think the venv issue is caused by the fact that gr isn't installed by pip and the python components therefore aren't copied to the venv directory.

[SteveBz]

Hmm. I haven't really tried using gr in virtual environments. It is picky about which python version you use to run virgo though (it should match gr's version). I'd first try outside of the virtual environment. What error does it yield, and what GR version are you using? I'd suggest settling on 3.8 or 3.9. The issue described in #7 has an easy fix (just change a property in the flowchart and recompile). Have you had any past experiences with running GR, or is this your first time?

Hi Apostolos,

I'm not clear what this means.

Are you saying that I can rebuild the pipeline with gnu-radio companion and it will work?

How do I do that? Is that what the grc files are?

Please be a little less Socratic in your teaching methods 😁

Kind regards.

Steve.

[0xCoto]

Let's try to re-install everything from the beginning. Could you uninstall everything GR and Virgo-related installations and follow the few commands listed here? https://virgo.readthedocs.io/en/latest/installation.html

They should work fine for Ubuntu. You can verify the installation of Virgo by running:

python -c "import virgo" (no output indicates a successful installation).

I'd advise not working with virtual environments for now, because GNU Radio tends to get quite sensitive with which Python you use etc.

Once all the commands have been successfully run and everything has been installed, run gnuradio-companion from the terminal. Does the GUI interface open up normally?

Could you try following a very basic example test for your SDR (using blocks SDR Source -> QT Sink) to verify GNU Radio interfaces with your device properly? Here's a video to guide you: https://youtu.be/aG1j6Fyyc8A

No need to run anything complex, just enough to ensure the signal picked up by your SDR can be seen by GNU Radio.

Once that's all verified, we can begin looking into interfacing GR with Virgo on your machine. 🙂

[SteveBz]

OK, All done. Seems to work.

Now if I look at the Virgo directory, I can see 2 .grc files. They both have the problem you describe. When I change the 'None' to 'String' the both compile to 'rub_observatory' Is that right? Which is the one I need?

In fact I'm battling with 2 problems at the moment, one is the RTL.SDR/Virgo problem there. The other one is how to attach the feedhorn, so in fact I'm still waiting for some bolts of the right size to arrive. When they do I'll send you a photo of the whole setup. Hopefully the radio will be sorted out too! 😃

Thanks for your help.

[0xCoto]

After applying the fix to both files, rename the WOLA-compiled file to run_wola.py and the FTF-compiled file to run_ftf.py. They by default get compiled as the same name, which is poor code practice on my end.

If you can try running Virgo now using the same python, it should work. To figure out which python GR is using, you can click on the compile button within gnuradio companion and look at the log at the bottom left. It should display the version/path of the python being used to execute the compiled script.

[SteveBz]

OK, just tested it and it seems to work.

I need to rename the files as you say. Great job, now I only need for the right size bolts to arrive in the post!! Thursday, apparently.

On a second point, how did you get Pictor to look so beautiful? It looks like you had a professional product designer, professional metal-worker, professional painter and then a professional photographer. Everything looks so aesthetically pleasing.

As I look around the web, I find that other people have had the same problem that I did with that 'recompile', and then even given up. I'll put together a few words and post them here so that maybe you can update the README. It was really such an easy thing once I understood!

Have a good day. Talk soon.

Kind regards

Steve.