search

krakenrf / gr-krakensdr

GNU General Public License v3.0
55 stars 14 forks source link

missing context for instructions referencing "krakensdr root directory" #2

Closed dennishiding closed 1 year ago

dennishiding commented 1 year ago

Next copy the heimdall_only_start.sh and heimdall_only_stop.sh file from this repo into your krakensdr root directory.

I cannot determine where this is suggesting I copy these files. In getting to this step I've constructed the following directories:

heimdall_daq_fw
kfr
gr-krakensdr
librtlsdr
mpir

in a subdirectory of my home directory. And

miniforge3

in my home directory none of these other than perhaps gr-krakensdr seem likely matches, btu gr-krakensdr is the source location for this repo

I don't see a krackensdr directory in the operating system root dir /

so close and yet so far...

dennishiding commented 1 year ago

Personally I think I resolved this.

My instructions for my self (and others that happen to find this bread crumb)

--- Setting up the heimdall_only_start and heimdall_only_stop wrappers ---
These are convenience wrappers for starting the data acquisition.  Copy them
from the gr_krakensdr repo the the parent directory of where
heimdall_daq_fw repo was cloned.    Optionally add a first command of 
``` cd $(dirname $0)```
to the beginning of them to allow them to be run from PATH without
requiring cd'ing to the containing directory first.

Use these scripts to start the data acquisition driver before running
gnuradio-companion.

Of course since I still don't have the full chain running, these notes might be proven wrong in the future.

Pretty sure all of below is in error after rerunning sudo make install and paying more attention to output versus other things I've learned along the way.

To get the KrakenSDR blocks to show up in gnuradio-compantion I also needed to export GRC_BLOCKS_PATH=/usr/share/gnuradio/grc/blocks:/home/dennis/221226krakenrf/gr-krakensdr/grc prior to running gnuradio-companion.

Though this is still not sufficient to run a graph that includes KrakenSDR source. Due to error

 File "/home/dennis/221226krakenrf/gr-krakensdr/kraken.py", line 34, in <module>
    from gnuradio import krakensdr
ImportError: cannot import name 'krakensdr' from 'gnuradio' (/usr/lib64/python3.10/site-packages/gnuradio/__init__.py)

Guessing this is a python path issue, tried running gnuradio-compantion after a conda activate kracken but that environment failed due to missing something that looked gnuradio specific.

More info in next comment as to why strikethrough so much above.

dennishiding commented 1 year ago 
[dennis@fedora build]$ sudo make install
[  0%] Built target pygen_apps_9a6dd
[100%] Built target pygen_python_krakensdr_655e2
[100%] Built target copy_module_for_tests
Install the project...
-- Install configuration: "Release"
-- Installing: /usr/local/lib64/cmake/gnuradio-krakensdr/gnuradio-krakensdrConfig.cmake
-- Installing: /usr/local/include/gnuradio/krakensdr/api.h
-- Installing: /usr/local/local/lib64/python3.10/site-packages/gnuradio/krakensdr/__init__.py
-- Installing: /usr/local/local/lib64/python3.10/site-packages/gnuradio/krakensdr/krakensdr_source.py
-- Installing: /usr/local/local/lib64/python3.10/site-packages/gnuradio/krakensdr/krakensdr_correlator.py
-- Installing: /usr/local/local/lib64/python3.10/site-packages/gnuradio/krakensdr/doa_music.py
-- Installing: /usr/local/local/lib64/python3.10/site-packages/gnuradio/krakensdr/__init__.pyc
-- Installing: /usr/local/local/lib64/python3.10/site-packages/gnuradio/krakensdr/krakensdr_source.pyc
-- Installing: /usr/local/local/lib64/python3.10/site-packages/gnuradio/krakensdr/krakensdr_correlator.pyc
-- Installing: /usr/local/local/lib64/python3.10/site-packages/gnuradio/krakensdr/doa_music.pyc
-- Installing: /usr/local/local/lib64/python3.10/site-packages/gnuradio/krakensdr/__init__.pyo
-- Installing: /usr/local/local/lib64/python3.10/site-packages/gnuradio/krakensdr/krakensdr_source.pyo
-- Installing: /usr/local/local/lib64/python3.10/site-packages/gnuradio/krakensdr/krakensdr_correlator.pyo
-- Installing: /usr/local/local/lib64/python3.10/site-packages/gnuradio/krakensdr/doa_music.pyo
-- Installing: /usr/local/share/gnuradio/grc/blocks/krakensdr_krakensdr_source.block.yml
-- Installing: /usr/local/share/gnuradio/grc/blocks/krakensdr_krakensdr_correlator.block.yml
-- Installing: /usr/local/share/gnuradio/grc/blocks/krakensdr_doa_music.block.yml
[dennis@fedora build]

gnuradio companion reports that /usr/share/gnuradio/grc/blocks is where it expects blocks, not /usr/local.

Even if it was using /usr/local, I would not expect /usr/local/local/ to be valid

So guess I'm off to try to discern what the correct paths are, and see if I there are options in ccmake that will reconfigure the install appropriately.

cmake .. -D CMAKE_INSTALL_PREFIX=/usr

is not sufficient. With some debug added it appears that /usr/lib64/cmake/gnuradio/GrPython.cmake is finding:

-- GR_PYTHON_DIR= local/lib64/python3.10/site-packages

which isn't correct, and is where the extra "local" is likely coming from. Path that it looks like should be used is /usr/lib64/python3.10/site-packages/gnuradio/ but construction from CMAKE_INSTALL_PREFIX and the faulty GR_PYTHON_DIR is bogus.

At this point I'm suspecting the /usr/lib64/cmake/gnuradio/GrPython.cmake from gnuradio-devel package is broken. A hack work around might be to just hardcode GR_PYTHON_PATH in GrPython.cmake and go back through the gr-krakensdr configure/build/install steps to see it it works.

To bad long run of holiday free work will start before getting this running. :frowning_face:

dennishiding commented 1 year ago

hack solution to GR_PYTHON_DIR insert line to hard code path between "endif()" and "file(TO_CMAKE_DIR ${GR_PYTHON_DIR}..." lines in /usr/lib64/cmake/gnuradio/GrPython.cmake

endif()
set( GR_PYTHON_DIR "lib64/python3.10/site-packages" )
file(TO_CMAKE_PATH ${GR_PYTHON_DIR} GR_PYTHON_DIR)

Also add modified CMAKE_INSTALL_PREFIX to gr-krakensdr build/install directions

git clone https://github.com/krakenrf/gr-krakensdr

cd gr-krakensdr
mkdir build
cd build
cmake .. -D CMAKE_INSTALL_PREFIX=/usr
make
sudo make install

Now running a gnuradio-companion graph with the KrakenSDR source results in continuous stream of 

Ethernet Connection Failed, Error: <class 'ConnectionRefusedError'>
Ethernet Connection Failed, Error: <class 'ConnectionRefusedError'>
Ethernet Connection Failed, Error: <class 'ConnectionRefusedError'>
Ethernet Connection Failed, Error: <class 'ConnectionRefusedError'>
Ethernet Connection Failed, Error: <class 'ConnectionRefusedError'>

I've run the heimdall_only_start.sh script and gotten the coffee cup script output from it.

netstat -tuln shows the 5001 port listening, though I don't see the adjacent port.

tcp        0      0 0.0.0.0:5001            0.0.0.0:*               LISTEN
krakenrf commented 1 year ago

The heimddall setup has you create a root krakensdr folder which contains the heimdall_daq_fw and krakensdr_doa folders. Installing gr-krakensdr assumes that you at least have been through the heimdall install.

For your other errors, i'm not exactly what's going wrong there. On a fresh setup with GNU Radio installed via the package manager there are no errors. How did you install GNU Radio in your setup?

dennishiding commented 1 year ago

For your other errors, i'm not exactly what's going wrong there. On a fresh setup with GNU Radio installed via the package manager there are no errors. How did you install GNU Radio in your setup?

I had installed gnuradio and gnuradio-dev through the package manager. As noted in the other issue the package gnuradio-dev references gmp and mpir packages without them being dependencies.

As noted in issue in daq_fw repo the connection issues were because the daw_fw was not running despite it appearing that it did. At least part of that problem is that the sudo in heimdall_only_start.sh seems to defeat the earlier line conda activate kraken by leaving that environment in the process of switching users. If you've already performed the installations in the root account that you did building the conda environment you wouldn't notice that. Repeating the operations done in the conda activate kraken environment on the root account got me past that particular issue.

krakenrf commented 1 year ago

Yes the conda and pip installs must all be done within the 'kraken' conda environment, not the root environment. All code is run from within the 'kraken' conda environment.