Problems receiving and transmitting with XTRX using osmocom gr-osmosdr

[O1234O]

Hello,

I am trying to receive and transmit with XTRX and osmocom source and sink, respectively. However, I do not know the information that I must include in osmocom source in the field "Device argument" and "Ch0: Antenna" to receive with RXA.

I have the same doubts to transmit with port TXA using osmocom sink.

Does anyone know how this block must be configured?

Thank you very much.

[fleischkaesbroetchen]

You have to set "xtrx" as Device Argument and leave blank Ch0: Antenna to receive with RXA. You find this when you click on a block in GNU Radio under the Documentation tab.

An easy way to look at a signal is with: osmocom_fft -a "xtrx=0" -s 4000000 -f 106000000

And with SDRangel I made good experiences.

[O1234O]

Thank you very much for your prompt answer. Do you know if the configuration to transmit in port TXA is Device Argument xtrx and leave blank Ch0: Antenna?

Thanks in advance.

[fleischkaesbroetchen]

I figure that's right but I never try it.

[WilfredoLora]

@O1234O Compile the new version of gr-osmosdr as it now supports the XTRX. See the link below from the osmocom repo: https://osmocom.org/projects/gr-osmosdr/repository/revisions/dc82ffd1f8b7fee5a8de2d73dabd24eb6d83d5a6
You will see that XTRX is on the list.

Also, i am trying to figure out the arguments as well.

[b3sholt]

@RFNOD I just tried to use master of gr-osmosdr but I am running into issues. I am using GnuRadio 3.8.2.0. I have an osmocom Source block, but when I attempt to run the flowgraph I get "ImportError: /usr/local/lib/x86_64-linux-gnu/libgnuradio-osmosdr.so.0.2.0: undefined symbol: xtrx_tune_rx_bandwidth" Have you run into a similar issue before?

[WilfredoLora]

@b3sholt yeah, I am working on merging the gr-osmosdr fork upstream. Testing at the moment and will tweak as I go. Stay tuned.

[WilfredoLora]

@chemeris Is there a way we can merge your gr-osmosdr fork upstream? Or should I fork it, and work on merging the PR's? Just asking before I put in the work. Lots of people in the community are looking forward in getting the xtrx working. Thanks!!

[WilfredoLora]

@O1234O Try one of the following and please report back if any of them helps. Thanks!!

AUTO
RXL
RXH
RXW

[WilfredoLora]

@b3sholt as for a Osmo fix. I am working on that. I was able to merge it with a fork for GR3.7 and working on getting to work on GR3.8. ZeroChaso from Pentoo will test the fork as well before I submit it to merge with upstream.

[b3sholt]

Thanks @RFNOD! Will be on the lookout for the GR3.8 fix!

[curtcorum]

also related to #93 #89 #82 #83

Part of the problem seems to be that the instruction in README.md :

git submodule update

Leaves all the individual submodule repositories in detatched head stale states.

It took a long time but figured out that my xtrx_api.h header file was old after fresh build:

curt@nye:/usr/local/include$ ls -alh xtrx_api.h 
-rw-r--r-- 1 root root 15K Jan 10 16:36 xtrx_api.h

and had the old xtrx_open_list in it:

/** Open XTRX device form semicolon separated device list
 * @param devices   Path to XTRX devices, semicolon separated (returned from xtrx_discovery)
 * @param flags     Semicolon separated flags. Can be NULL.
 * @param[out] dev  XTRX device handle
 * @return number of devices on success, errno on error
 *
 * When @ref devices is NULL only first enumerated device is created.
 * Only 'loglevel' flag is parsed.
 */
XTRX_API int xtrx_open_list(const char* devices, const char* flags, struct xtrx_dev** dev);

Here is the git submodule state after the 'git submodule update' command:

curt@nye:~/src/images$ git submodule foreach git branch -v
Entering 'sources/liblms7002m'
* (HEAD detached at 38bfb48) 38bfb48 Migration to Python 3
  master                     b07761b Migration to Python 3
Entering 'sources/libusb3380'
* (HEAD detached at da900c7) da900c7 proper initialization to work with short packets
  master                     c83d1e9 fix Windows build
Entering 'sources/libxtrx'
* (HEAD detached at 2443a10) 2443a10 gpio & sync API
  master                     acb0b1c xtrx_open_string: properly terminate 4096-byte paramstrings (#19)
Entering 'sources/libxtrxdsp'
* (HEAD detached at 84c6f4c) 84c6f4c make ARCH check valid for all x86 family
  master                     eec2864 Add FFT accelleration functions
Entering 'sources/libxtrxll'
* (HEAD detached at 9106b98) 9106b98 add ability to work with any packet size using short packets
  master                     1b6eddf Fixing typos (#5)
Entering 'sources/xtrx_linux_pcie_drv'
* (HEAD detached at ab29a2b) ab29a2b update package to version 0.0.1-2
  master                     5ae3a3e aarch64: fixup DMA for RK3399

I am now trying a build with:

git submodule foreach git checkout master

which gives the submodule status:

curt@nye:~/src/images$ git submodule foreach git branch -v
Entering 'sources/liblms7002m'
* master b07761b Migration to Python 3
Entering 'sources/libusb3380'
* master c83d1e9 fix Windows build
Entering 'sources/libxtrx'
* master acb0b1c xtrx_open_string: properly terminate 4096-byte paramstrings (#19)
Entering 'sources/libxtrxdsp'
* master eec2864 Add FFT accelleration functions
Entering 'sources/libxtrxll'
* master 1b6eddf Fixing typos (#5)
Entering 'sources/xtrx_linux_pcie_drv'
* master 5ae3a3e aarch64: fixup DMA for RK3399

anyway really hopes this explains things!

[curtcorum]

@RFNOD So far I have only been able to get gr-osmosdr source to work with device argument "xtrxsoapy" not "xtrx" with gnuradio-3.8 and python3. #83 #96

[b3sholt]

Has anyone been able to run the gr-osmosdr source with gnuradio-3.8 yet without using soapy?

[WilfredoLora]

I think gr-osmosdr is still broken. Will see if I can reach out to a maintainer at osmocom for an update.

[b3sholt]

@RFNOD, have you heard from the osmocom folks yet?

[WilfredoLora]

@b3sholt nope. Nothing. Will see if i can try a different way.

[Brayan1710]

I think you guys could try with GNU Radio 3.7 I was building with 3.8, but I had many errors so I decided try with 3.7 and I could run gr-osmosdr on it.

[b3sholt]

@Brayan1710 , thanks for the insight. My fear is that I will be stuck at 3.7 indefinitely given the lack of current support for the XTRX (recently just moved our entire baseline to 3.8). It is a cool little piece of hardware, but without some level of software support to keep pace with major SDR platforms, it does not bode well for it to be a viable product used in industry.

[b3sholt]

@RFNOD, just going through old stuff and just curious on this. From the looks of the issue board, is the XTRX dead at this point? I give you props for attempting to help maintain and update code, but with zero support from the Fairwaves team for two years...it feels kinda like a lost cause. Rather unfortunate to be honest. My company would love to use the XTRX as there are very few SDRs that fit this capability/form factor and the other existing products are very expensive. I would even be concerned about procuring the actual hardware as well since Fairwaves has been absent for so long. Wondering if they get new stock on crowd supply, or are they simply selling the existing units with no future plans for additional runs?

[WilfredoLora]

@b3sholt I agree, I believe the XTRX SDR is dead. The Fairwaves site is down and I have not been able to get in contact with anyone to help with this project. @chemeris is the SDR dead???

The plan for 2022 is to look into the XTRX project and possibly revive it for current hardware. I have one and would like to get it working. Without the gerbers, it is gonna suck to make any hardware modifications. Since I only have one, I am being cautious to not damage it and don't want to sink money into more hardware in case this is dead-end. As for crowd supply, I am going to reach out and see what they say.

In other words, I will work on this when I can in the new year, I am not going to be the point person for this project, because school, work, kids, and...you know, life. Will try my best and hopefully have some news soon.

Happy New Years!!!

[earwin]

@b3sholt @RFNOD Happy New Years!
The project is not dead-dead, but rather.. frozen. It doesn't pay enough to sustain itself, and the team is trying to earn its living elsewhere.
My speculation (take with a fat spoonful of salt) is that producing new batches is realistic modulo component availability, but active software support is unlikely in the next half a year at least.
I will try to get a more coherent statement out of the folks with more know.

[WilfredoLora]

Thanks @earwin we look forward to hearing back with more info!!

[curtcorum]

If the originators have no interest/time would it be possible to open source the hardware (or the parts that need fixing at least) so that the community could get the project moving?

The ambitious density of the board always seemed to me like it might require fixing/tweaking in order to get it completely stable? This is in no way meant to detract from the design or designers, just an observation based on my past industry experience!