Super awesome thanks. I sure will be willing to test it out.
Here is what i have discovered so far running latest DragonOS environment in an attempt to get xtrx pcie device up and running (turns out to have the same issues Ubuntu 20.04 has), But DragonOS gives me all kinds of turnkey goodies. Ultimately i suspect either soapy, version 2.0 of libqcustomplot, or perhaps a recompile of gnuradio is required to get things working but im very close because the libxtrx driver works, gnuradio cant find the device for some reason though:
LIBXTRX notes
Following directions from this site : https://github.com/xtrx-sdr/images
the following are noteworthy about libxtrx compile:
1. libqcustomplot1.3 has been replaced by libqcustomplot2.0 in the dependencies
2. cmake -DENABLE_SOAPY=NO is required for compile because of compile time abort errors (see attachement)
3. cmake -DINSTALL_UDEV_RULES=ON .. does not appear to work on its own for non root user access and requires cp sources/xtrx_linux_pcie_drv/50-xtrx.rules /etc/udev/rules.d/ to be used as well
4. I have not flashed the FPGA and have been using the original firmware
5. ./test_xtrx -t -l2 also works fine
6. sudo ./test_xtrx -t -l2 works just fine
7. /usr/local/lib/xtrx/./xtrx_fft also functions as expected so the driver level code appears to be working.
gr-osmosdr source notes
1. Compiles and installs as expected per https://github.com/osmocom/gr-osmosdr
2. git checkout --track origin/gr3.8 is required to get the code to compile (alternatively upgrading gnu-radio to 3.10 (but the upgrade takes all the other fine goodies that DragonOS offers away so i opted to revert gr-osmosdr driver to gnuradio 3.8.
3. Running the source or sync block using xtrx device args (results in device not found errors)
CPU Features: SSE2+ SSE4.1+ AVX+ FMA+
Using avx for xtrxdspiq16sc32
Using avx for xtrxdspiq8ic16
Using avx for xtrxdspiq16ic16i
Using avx for xtrxdspiq8ic8i
Using avx for xtrxdspsc32iiq16
Using avx for xtrxdspiq8sc32
Using avx for xtrxdspiq8sc32i
Using avx for xtrxdspiq16sc32i
Using avx for xtrxdspsc32iq16
Using avx for xtrxdspiq8ic16i
Using avx for xtrxdspic16iiq16
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.1.0
built-in sink types: uhd hackrf bladerf soapy redpitaya xtrx file
xtrx
xtrxobj::xtrxobj = 4
09:44:53.453764 INFO: xtrxopenstring:531 [XTRX] xtrxopen(): no devices were found
Traceback (most recent call last):
File "/home/dogbert/Documents/TestSDRDevices.py", line 185, in <module>
main()
File "/home/dogbert/Documents/TestSDRDevices.py", line 163, in main
tb = topblockcls()
File "/home/dogbert/Documents/TestSDRDevices.py", line 119, in init
self.osmosdrsink0 = osmosdr.sink(
File "/usr/local/lib/python3/dist-packages/osmosdr/osmosdrswig.py", line 1442, in make
return osmosdrswig.sinkmake(args, kwargs)
RuntimeError: Couldn't open : Error: 2</module>
Done (return code 1)
osmocom_fft -a xtrx -A RXW -s 4000000 -f 804000000 -F shows similar errors
*$ osmocomfft -a xtrx -A RXW -s 4000000 -f 804000000 -F
CPU Features: SSE2+ SSE4.1+ AVX+ FMA+
Using avx for xtrxdspiq16sc32
Using avx for xtrxdspiq8ic16
Using avx for xtrxdspiq16ic16i
Using avx for xtrxdspiq8ic8i
Using avx for xtrxdspsc32iiq16
Using avx for xtrxdspiq8sc32
Using avx for xtrxdspiq8sc32i
Using avx for xtrxdspiq16sc32i
Using avx for xtrxdspsc32iq16
Using avx for xtrxdspiq8ic16i
Using avx for xtrxdspic16iiq16
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.1.0
built-in source types: file fcd rtl rtltcp uhd hackrf bladerf rfspace airspy airspyhf soapy redpitaya xtrx
xtrx
xtrxobj::xtrxobj = 4
09:46:23.621860 INFO: xtrxopenstring:531 [XTRX] xtrxopen(): no devices were found
Couldn't instanciate source (no device present?). *
The INFO: line is in the same color text as the driver level messages so its odd that the driver reports the no devices found vs it being the application or plugin layer message
The device args and antenna callouts are a little hard to follow for me but the source code indicates the following (and if i got it wrong, there may be a simple solution here): https://github.com/xtrx-sdr/images/issues/66
I'm not sure what the "test" is doing, but between this an the test xtrx.c file there's some issues.
now run
cmake ..
make
sudo make install
sudo ldconfig
For me the errors for compiling with Soapy went ahead and it finished.
Then I was able to run SoapySDRUtil --info
And I could see xtrx support was added. This may mean you could open CubicSDR and/or SigDigger and see if the applications use your radio. It may also mean you could have support within GQRX using Soapy vs GR Osmosdr. I'll wait to hear how this works for you so far.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
when removing this from the Cmake file to avoid compiling txt_xtrx_soapy.c, i too got it to compile, no fresh install of DragonOS was required. I expect this executable is not required.
gqrx now sees and can use the xtrx in RX mode, the device string has changed from the past incarnations and is now:
XTRX:pcie:///dev/xtrx0
I may still have to grep around in the source code to see what the antenna calls are now and if they have changed.
If i have time later today i will attempt to recompile gr-osmoSDR
now that the libxtrx driver on my machine supports soapy, that may just be the ticket... stay tuned...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's great news! I suspect when you compile gr-osmosdr it'll install the libs somewhere besides the apt install. You may need to wipe away the libs from the apt install without actually using apt-get remove.
I know this probably isn't recommened, but you may notice in DragonOS that I started with the apt install of GNU Radio. Over time I wanted newer libs for HackRF, Bladerf, etc.. so instead of uninstalling from Apt causing a chain reaction of software removal, I instead compiled what was needed from source and manually removed apt installed libs in some cases. I then tested everything and found it all to work together nicely.
You may need to remove those manually once you compile and install your own. What that'll do to how GQRX and other things work, not sure. If what you compile from source is named the same, i suppose you could just copy or symlink them there as well. That's just me rambling on, but that sort of approach has worked for me in some cases.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I got the xtrx pcie working after a re-compile. I took a more cavalier approach and just installed the gr-osmosdr (compiled install) over the top of whatever was there natively from the DragonOS baseline. gr-osmosdr cmake file has an uninstall option and gnuradio appears to show the xtrx device in the source/sink block's documentation tab when compiled version is installed and it goes away when uninstalled.
I still dont think i have the device args working on the osmoSDR gnuradio blocks as my test file kept crashing on startup till i removed the rtl_sdr dongle i had installed in the computer, which was confusing the plugin. But after i removed the rtl_sdr dongle from the system it fired up. I only tested TX by sending out 500khz wide Gaussian noise on 440mhz. I have to exercise it further.
LAstly, i cant get SDR angel to do anything. there is noi indication that it found any devices and Im not too savvy on that program.
So i think we basically have the sauce to get it working on a build, its just a matter of if you want to use the hacked source code from libxtrx that excludes test_xtrx program. I will put in a ticket on the libxtrx github site to look into the bug surrounding soapy compiles.
Let me know when you have a candidate build and i will try it out.
-73
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Quick note before I run out the door.. in GNU Radio on the source or sink osmosdr block, open it up and in the device arguments block put in something like hackrf=0 but i guess in your cause maybe xtrx=0. I have to do that with the hackrf, otherwise UHD tries to take over and run it.
For SDRAngel, I looked quickly at terminal while starting it and don't see a mention of the xtrx module, so that might require manually building it from source.
Seems like progress is being made though! Can you pass along anything you set when compiling gr-osmosdr from source? I'm wondering if by doing this if the functionality of anything else is messed with.
Lastly, I stuck a gr-soapy block in GNU Radio. There's both a source and sink. I've used it with success against SDRPlay equipment. I just pulled it up and clicked the drop down box and it now shows me xtrxsoapy. Maybe see how that works for you and your flow graphs?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I haven't forgotten about this thread, just been busy, I'll post my fix
today if I can. I posted a comment on the libxtrx GitHub site to see if
someone can fix the actual problem.
I will post the cmake file I used on the dragonOS ticket soon. There
appears to be some issue with GNUradio releasing the hardware resource back
to the OS after running a flowgraph but it's intermittent. I'll explore
that more later.
Quick note before I run out the door.. in GNU Radio on the source or sink
osmosdr block, open it up and in the device arguments block put in
something like hackrf=0 but i guess in your cause maybe xtrx=0. I have to
do that with the hackrf, otherwise UHD tries to take over and run it.
For SDRAngel, I looked quickly at terminal while starting it and don't see
a mention of the xtrx module, so that might require manually building it
from source.
Seems like progress is being made though! Can you pass along anything you
set when compiling gr-osmosdr from source? I'm wondering if by doing this
if the functionality of anything else is messed with.
Lastly, I stuck a gr-soapy block in GNU Radio. There's both a source and
sink. I've used it with success against SDRPlay equipment. I just pulled it
up and clicked the drop down box and it now shows me xtrxsoapy. Maybe see
how that works for you and your flow graphs?
Status: open Milestone: 1.0 Labels: xtrx pcie Created: Sun Jan 30, 2022 04:11 AM UTC by Casey Last Updated: Sun Jan 30, 2022 08:44 PM UTC Owner: nobody
add XTRX pcie support libxtrx and gr-osmosdr plugin support by default.
It should work with osmocom, I was targeting this device for an embedded
cell tower application but there are limited native mini -pcie hardware
options available. I did get a demo running years back with the ettus
205mini and an odroid, never published the project though. But the 205s
clock isn't good enough on it's own. I'm
not sure about srsLTE
Status: open Milestone: 1.0 Labels: xtrx pcie Created: Sun Jan 30, 2022 04:11 AM UTC by Casey Last Updated: Sun Jan 30, 2022 09:15 PM UTC Owner: nobody
add XTRX pcie support libxtrx and gr-osmosdr plugin support by default.
That would be great. Can i work on a script and have you test it? I imagine there is soapy support to. I just do not have equipment to test with.
Last edit: Cemaxecuter 2022-01-30
Super awesome thanks. I sure will be willing to test it out.
Here is what i have discovered so far running latest DragonOS environment in an attempt to get xtrx pcie device up and running (turns out to have the same issues Ubuntu 20.04 has), But DragonOS gives me all kinds of turnkey goodies. Ultimately i suspect either soapy, version 2.0 of libqcustomplot, or perhaps a recompile of gnuradio is required to get things working but im very close because the libxtrx driver works, gnuradio cant find the device for some reason though:
LIBXTRX notes
Following directions from this site : https://github.com/xtrx-sdr/images
the following are noteworthy about libxtrx compile:
1. libqcustomplot1.3 has been replaced by libqcustomplot2.0 in the dependencies
2. cmake -DENABLE_SOAPY=NO is required for compile because of compile time abort errors (see attachement)
3. cmake -DINSTALL_UDEV_RULES=ON .. does not appear to work on its own for non root user access and requires cp sources/xtrx_linux_pcie_drv/50-xtrx.rules /etc/udev/rules.d/ to be used as well
4. I have not flashed the FPGA and have been using the original firmware
5. ./test_xtrx -t -l2 also works fine
6. sudo ./test_xtrx -t -l2 works just fine
7. /usr/local/lib/xtrx/./xtrx_fft also functions as expected so the driver level code appears to be working.
gr-osmosdr source notes
1. Compiles and installs as expected per https://github.com/osmocom/gr-osmosdr
2. git checkout --track origin/gr3.8 is required to get the code to compile (alternatively upgrading gnu-radio to 3.10 (but the upgrade takes all the other fine goodies that DragonOS offers away so i opted to revert gr-osmosdr driver to gnuradio 3.8.
3. Running the source or sync block using xtrx device args (results in device not found errors)
Executing: /usr/bin/python3 -u /home/dogbert/Documents/Test_SDR_Devices.py
CPU Features: SSE2+ SSE4.1+ AVX+ FMA+
Using avx for xtrxdspiq16sc32
Using avx for xtrxdspiq8ic16
Using avx for xtrxdspiq16ic16i
Using avx for xtrxdspiq8ic8i
Using avx for xtrxdspsc32iiq16
Using avx for xtrxdspiq8sc32
Using avx for xtrxdspiq8sc32i
Using avx for xtrxdspiq16sc32i
Using avx for xtrxdspsc32iq16
Using avx for xtrxdspiq8ic16i
Using avx for xtrxdspic16iiq16
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.1.0
built-in sink types: uhd hackrf bladerf soapy redpitaya xtrx file
xtrx
xtrxobj::xtrxobj = 4
09:44:53.453764 INFO: xtrxopenstring:531 [XTRX] xtrxopen(): no devices were found
Traceback (most recent call last):
File "/home/dogbert/Documents/TestSDRDevices.py", line 185, in <module>
main()
File "/home/dogbert/Documents/TestSDRDevices.py", line 163, in main
tb = topblockcls()
File "/home/dogbert/Documents/TestSDRDevices.py", line 119, in init
self.osmosdrsink0 = osmosdr.sink(
File "/usr/local/lib/python3/dist-packages/osmosdr/osmosdrswig.py", line 1442, in make
return osmosdrswig.sinkmake(args, kwargs)
RuntimeError: Couldn't open : Error: 2</module>
*$ osmocomfft -a xtrx -A RXW -s 4000000 -f 804000000 -F
CPU Features: SSE2+ SSE4.1+ AVX+ FMA+
Using avx for xtrxdspiq16sc32
Using avx for xtrxdspiq8ic16
Using avx for xtrxdspiq16ic16i
Using avx for xtrxdspiq8ic8i
Using avx for xtrxdspsc32iiq16
Using avx for xtrxdspiq8sc32
Using avx for xtrxdspiq8sc32i
Using avx for xtrxdspiq16sc32i
Using avx for xtrxdspsc32iq16
Using avx for xtrxdspiq8ic16i
Using avx for xtrxdspic16iiq16
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.1.0
built-in source types: file fcd rtl rtltcp uhd hackrf bladerf rfspace airspy airspyhf soapy redpitaya xtrx
xtrx
xtrxobj::xtrxobj = 4
09:46:23.621860 INFO: xtrxopenstring:531 [XTRX] xtrxopen(): no devices were found
Couldn't instanciate source (no device present?). *
The INFO: line is in the same color text as the driver level messages so its odd that the driver reports the no devices found vs it being the application or plugin layer message
Can you try this on a fresh install of DragonOS Focal. I just messed with it and got it to compile, but I'm not sure about what I did.
sudo apt-get install build-essential libusb-1.0-0-dev cmake dkms python3 python3-pip gpsd gpsd-clients pps-tools libboost-all-dev git qtbase5-dev libqcustomplot-dev libqcustomplot2.0 libqt5printsupport5 doxygen swig
The above shouldn't harm the current install. Then run
sudo pip3 install cheetah3
git clone https://github.com/xtrx-sdr/images.git
cd images/
git submodule init
git submodule update
cd sources/
mkdir -p build
nano /home/dragon/images/sources/libxtrx/soapy/test_xtrx_soapy.c
Comment out the two lines I show with a #
set(CMAKE_CXX_STANDARD 11)
project(soapyxtrx C CXX)
find_package(SoapySDR REQUIRED)
add_executable(test_xtrx_soapy test_xtrx_soapy.c)
target_link_libraries(test_xtrx_soapy ${SoapySDR_LIBRARIES})
SOAPY_SDR_MODULE_UTIL(
TARGET XTRXSupport
SOURCES
Registration.cpp
SoapyXTRX.cpp
LIBRARIES
xtrx
)
I'm not sure what the "test" is doing, but between this an the test xtrx.c file there's some issues.
now run
cmake ..
make
sudo make install
sudo ldconfig
For me the errors for compiling with Soapy went ahead and it finished.
Then I was able to run SoapySDRUtil --info
And I could see xtrx support was added. This may mean you could open CubicSDR and/or SigDigger and see if the applications use your radio. It may also mean you could have support within GQRX using Soapy vs GR Osmosdr. I'll wait to hear how this works for you so far.
Ya that was it , Great work!
images/sources/libxtrx/soapy/test_xtrx_soapy.c
when removing this from the Cmake file to avoid compiling txt_xtrx_soapy.c, i too got it to compile, no fresh install of DragonOS was required. I expect this executable is not required.
gqrx now sees and can use the xtrx in RX mode, the device string has changed from the past incarnations and is now:
XTRX:pcie:///dev/xtrx0
I may still have to grep around in the source code to see what the antenna calls are now and if they have changed.
If i have time later today i will attempt to recompile gr-osmoSDR
now that the libxtrx driver on my machine supports soapy, that may just be the ticket... stay tuned...
That's great news! I suspect when you compile gr-osmosdr it'll install the libs somewhere besides the apt install. You may need to wipe away the libs from the apt install without actually using apt-get remove.
I know this probably isn't recommened, but you may notice in DragonOS that I started with the apt install of GNU Radio. Over time I wanted newer libs for HackRF, Bladerf, etc.. so instead of uninstalling from Apt causing a chain reaction of software removal, I instead compiled what was needed from source and manually removed apt installed libs in some cases. I then tested everything and found it all to work together nicely.
For example
/usr/lib/x86_64-linux-gnu/libosmosdr.so.0
/usr/lib/x86_64-linux-gnu/libosmosdr.so.0.0.0
You may need to remove those manually once you compile and install your own. What that'll do to how GQRX and other things work, not sure. If what you compile from source is named the same, i suppose you could just copy or symlink them there as well. That's just me rambling on, but that sort of approach has worked for me in some cases.
You know what else too, you should check SDRAngel. It has, i believe, the libs included with it for xtrx and should maybe support RX and TRX.
I got the xtrx pcie working after a re-compile. I took a more cavalier approach and just installed the gr-osmosdr (compiled install) over the top of whatever was there natively from the DragonOS baseline. gr-osmosdr cmake file has an uninstall option and gnuradio appears to show the xtrx device in the source/sink block's documentation tab when compiled version is installed and it goes away when uninstalled.
I still dont think i have the device args working on the osmoSDR gnuradio blocks as my test file kept crashing on startup till i removed the rtl_sdr dongle i had installed in the computer, which was confusing the plugin. But after i removed the rtl_sdr dongle from the system it fired up. I only tested TX by sending out 500khz wide Gaussian noise on 440mhz. I have to exercise it further.
LAstly, i cant get SDR angel to do anything. there is noi indication that it found any devices and Im not too savvy on that program.
So i think we basically have the sauce to get it working on a build, its just a matter of if you want to use the hacked source code from libxtrx that excludes test_xtrx program. I will put in a ticket on the libxtrx github site to look into the bug surrounding soapy compiles.
Let me know when you have a candidate build and i will try it out.
-73
Quick note before I run out the door.. in GNU Radio on the source or sink osmosdr block, open it up and in the device arguments block put in something like hackrf=0 but i guess in your cause maybe xtrx=0. I have to do that with the hackrf, otherwise UHD tries to take over and run it.
For SDRAngel, I looked quickly at terminal while starting it and don't see a mention of the xtrx module, so that might require manually building it from source.
Seems like progress is being made though! Can you pass along anything you set when compiling gr-osmosdr from source? I'm wondering if by doing this if the functionality of anything else is messed with.
Lastly, I stuck a gr-soapy block in GNU Radio. There's both a source and sink. I've used it with success against SDRPlay equipment. I just pulled it up and clicked the drop down box and it now shows me xtrxsoapy. Maybe see how that works for you and your flow graphs?
I haven't forgotten about this thread, just been busy, I'll post my fix
today if I can. I posted a comment on the libxtrx GitHub site to see if
someone can fix the actual problem.
I will post the cmake file I used on the dragonOS ticket soon. There
appears to be some issue with GNUradio releasing the hardware resource back
to the OS after running a flowgraph but it's intermittent. I'll explore
that more later.
On Sun, Jan 30, 2022, 2:15 PM Cemaxecuter cemaxecuter@users.sourceforge.net
wrote:
Related
Tickets: #18
Hi Casey,
I have ordered XTRX from Crowdsupply. I was wondering if this sdr can work with srsLTE or osmocom.
It should work with osmocom, I was targeting this device for an embedded
cell tower application but there are limited native mini -pcie hardware
options available. I did get a demo running years back with the ettus
205mini and an odroid, never published the project though. But the 205s
clock isn't good enough on it's own. I'm
not sure about srsLTE
What are you working on?
On Tue, Mar 29, 2022, 9:37 PM anOldSoul anoldsoul@users.sourceforge.net
wrote:
Related
Tickets: #18
I'm going to work on giving 4g internet access to rural areas, using sdr and open source software like srsLTE. I don't know if it's possible.