Hi Martin, I do other software development on that system too, and indeed I installed VS code from the snap store. It could be that a different installation defined the XDG_DATA_HOME between running the calibration and trying to use the files. Anyhow, the file is being used so I consider this solved. Thank you for the support!
Tim Op ma 14 apr 2025 om 14:38 schreef Martin Braun <martin.br...@ettus.com>: > Hi Tim and others affected by this, > > I think that narrows down. And I'm afraid UHD is not at fault here, or > rather, it has no way of knowing any better, at least I'm pretty confident > that is the case. > > UHD is designed to follow the freedeskop specifications: > https://specifications.freedesktop.org/basedir-spec/latest/ > > ...that means if you specify XDG_DATA_HOME, then UHD will use that value. > Not all data that UHD stores or loads is subject to this path, but the > calibration data are. So UHD is looking for the data in the "right spot", > and if you need a different path, you have to specify UHD_CAL_DATA_PATH > (see earlier message). > > There's still two mysteries here: > > 1. Why did usrp_calibrator store the data in `/.local`? > > My hypothesis is that it was run in a context where XDG_DATA_HOME was not > set. The code to store and retrieve cal data is the same between > usrp_calibrator and normal UHD operations. That's how we make sure the > paths aren't the same. > > 2. Why is XDG_DATA_HOME set in your case? > > Maybe VS Code is installed from snap, and populates that variable? This is > ultimately a question for you, I'm afraid. > > --M > > On Mon, Apr 14, 2025 at 12:58 PM Tim Vancauwenbergh < > tim.vancauwenberg...@gmail.com> wrote: > >> Hi Martin, >> >> running echo $XDG_DATA_HOME in the virtual environment gives: >> /home/username/snap/code/188/.local/share >> I am using Visual Studio Code, if it might help. >> >> Tim >> >> Op ma 14 apr 2025 om 11:51 schreef Martin Braun <martin.br...@ettus.com>: >> >>> Ah, those are more recent than UHD 4.6. >>> >>> Is the environment variable XDG_DATA_HOME set on your system? What does >>> "echo $XDG_DATA_HOME" print for you? >>> >>> BTW, if the only problem is that the cal data path is misattributed, >>> then you can set the environment variable >>> UHD_CAL_DATA_PATH=~/.local/uhd/shrae/uhd/cal. That should do the trick. >>> However, I would still like to figure out what caused this. >>> >>> --M >>> >>> On Mon, Apr 14, 2025 at 11:39 AM Tim Vancauwenbergh < >>> tim.vancauwenberg...@gmail.com> wrote: >>> >>>> Hello Martin, >>>> >>>> only installed via apt, I did not specify snap. >>>> uhd.get_lib_path() returns: /lib/x86_64-linux-gnu -> libuhd.so found >>>> here >>>> uhd.get_pkg_path() returns: /lib >>>> I am unable to use uhd.get_pkg_data_path() and uhd.get_module_paths() >>>> -> uhd has no attribute >>>> >>>> Tim >>>> >>>> Op do 10 apr 2025 om 17:14 schreef Martin Braun <martin.br...@ettus.com >>>> >: >>>> >>>>> That was very helpful. So there's a discrepancy between what the >>>>> cal-tool thinks the path is (~/.local/...) and what UHD thinks it is >>>>> (~/snap/code/188/.local). >>>>> >>>>> I'm also a bit surprised about that UHD path. Did you install UHD via >>>>> snap? (If yes, I didn't even know that was possible!). I know you say you >>>>> installed via apt, but I'm just baffled why UHD thinks this is the right >>>>> path. >>>>> >>>>> There are other path APIs, here is what they look like on a system >>>>> where I install UHD, manually, into a random location: >>>>> >>>>> >>> uhd.get_lib_path() >>>>> '/home/mbr0wn/prefix/master/lib' >>>>> >>> uhd.get_pkg_data_path() >>>>> '/home/mbr0wn/prefix/master/share/uhd' >>>>> >>> uhd.get_cal_data_path() >>>>> '/home/mbr0wn/.local/share/uhd/cal' >>>>> >>>>> >>>>> The first (get_lib_path()) is the path where the libuhd.so file is >>>>> located. Is that the case for you? >>>>> >>>>> You can see even there, the cal files are, by default, searched for in >>>>> ~/.local/share/uhd/cal. >>>>> >>>>> --M >>>>> >>>>> On Thu, Apr 10, 2025 at 10:13 AM Tim Vancauwenbergh < >>>>> tim.vancauwenberg...@gmail.com> wrote: >>>>> >>>>>> Hello Martin, >>>>>> >>>>>> it prints the following: >>>>>> home/username/snap/code/188/.local/share/uhd/cal >>>>>> That folder does not exist, the deepest path I can go is >>>>>> home/username/snap/code/188/.local/share/ >>>>>> I manually created the folders uhd/cal and pasted the calibration >>>>>> files there. Now the function usrp.has_rx_power_reference() returns True. >>>>>> I'll investigate further. >>>>>> >>>>>> Tim >>>>>> >>>>>> Op wo 9 apr 2025 om 09:02 schreef Martin Braun < >>>>>> martin.br...@ettus.com>: >>>>>> >>>>>>> Tim, >>>>>>> >>>>>>> sorry for suggesting this so late: What does this Python script >>>>>>> print: >>>>>>> >>>>>>> import uhd >>>>>>> print(uhd.get_cal_data_path()) >>>>>>> >>>>>>> >>>>>>> ? >>>>>>> >>>>>>> On Tue, Apr 8, 2025 at 10:53 AM Tim Vancauwenbergh < >>>>>>> tim.vancauwenberg...@gmail.com> wrote: >>>>>>> >>>>>>>> Hello Martin, >>>>>>>> >>>>>>>> thanks for your reply. It would be helpful to know where the driver >>>>>>>> looks for the file, but until now I did not find any variable or >>>>>>>> function >>>>>>>> to obtain this location. >>>>>>>> >>>>>>>> FYI, I am using a virtual environment on Ubuntu 24.0.2 LTS with >>>>>>>> Python 3.12.3. >>>>>>>> The following packages related to uhd are installed via apt: >>>>>>>> >>>>>>>> *Status**Package Name**Version**Architecture**Description* >>>>>>>> ii libgnuradio-uhd3.10.9t64:amd64 3.10.9.2-1.1ubuntu2 amd64 gnuradio >>>>>>>> universal hardware driver functions >>>>>>>> ii libuhd4.6.0t64:amd64 4.6.0.0+ds1-5.1ubuntu0.24.04.1 amd64 universal >>>>>>>> hardware driver for Ettus Research products - library >>>>>>>> ii python3-uhd 4.6.0.0+ds1-5.1ubuntu0.24.04.1 amd64 universal >>>>>>>> hardware driver for Ettus Research products - Python3 >>>>>>>> ii soapysdr0.8-module-uhd:amd64 0.4.1-4build4 amd64 UHD device >>>>>>>> support for SoapySDR >>>>>>>> ii uhd-doc 4.6.0.0+ds1-5.1ubuntu0.24.04.1 all universal hardware >>>>>>>> driver for Ettus Research products - doc >>>>>>>> ii uhd-host 4.6.0.0+ds1-5.1ubuntu0.24.04.1 amd64 universal >>>>>>>> hardware driver for Ettus Research products - host apps >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Tim >>>>>>>> >>>>>>>> Op di 8 apr 2025 om 10:14 schreef Martin Braun < >>>>>>>> martin.br...@ettus.com>: >>>>>>>> >>>>>>>>> Tim, >>>>>>>>> >>>>>>>>> at first glance, you're doing everything right. Thanks for taking >>>>>>>>> the time and reading the docs. We'll need to look into this. >>>>>>>>> >>>>>>>>> I saw you also opened >>>>>>>>> https://github.com/EttusResearch/uhd/issues/842, that's very >>>>>>>>> helpful. Sorry I can't give you the right answer immediately! >>>>>>>>> >>>>>>>>> --M >>>>>>>>> >>>>>>>>> On Thu, Apr 3, 2025 at 11:28 AM Tim Vancauwenbergh < >>>>>>>>> tim.vancauwenberg...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hello >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've recently run the uhd_power_cal.py script to calibrate the RX >>>>>>>>>> paths of a B200mini using a calibrated signal generator. >>>>>>>>>> >>>>>>>>>> It generated two files, saved at >>>>>>>>>> /home/username/.local/share/uhd/cal: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - b2xxmini_pwr_rx_rx2_33ECA1A#A.cal >>>>>>>>>> >>>>>>>>>> - b2xxmini_pwr_rx_tx+rx_33ECA1A#A.cal >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Using python, I have the following code: >>>>>>>>>> >>>>>>>>>> print(f"RX info: {usrp.get_usrp_rx_info()}") >>>>>>>>>> >>>>>>>>>> This returns the following: >>>>>>>>>> >>>>>>>>>> RX info: {'mboard_id': 'B200mini', 'mboard_name': 'B200mini', >>>>>>>>>> 'mboard_serial': '33ECA1A', 'module_serial': '33ECA1A', >>>>>>>>>> 'rx_antenna': 'TX/RX', 'rx_id': 'Unknown (0xffff)', >>>>>>>>>> 'rx_ref_power_key': 'b2xxmini_pwr_rx_tx+rx', 'rx_ref_power_serial': >>>>>>>>>> '33ECA1A#A', 'rx_serial': '', 'rx_subdev_name': 'FE-RX1', >>>>>>>>>> 'rx_subdev_spec': 'A:A'} >>>>>>>>>> >>>>>>>>>> Running the following functions return false however. >>>>>>>>>> >>>>>>>>>> usrp.has_rx_power_reference() >>>>>>>>>> uhd.usrp.cal.database.has_cal_data('b2xxmini_pwr_rx_tx+rx', >>>>>>>>>> '33ECA1A#A'): >>>>>>>>>> >>>>>>>>>> Why? *How can I use the calibration file in python to obtain >>>>>>>>>> estimated received power level at the RX side in dBm?* This is >>>>>>>>>> not clear in the documentation. I would like to do this for the TX >>>>>>>>>> side as >>>>>>>>>> well. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> References: >>>>>>>>>> >>>>>>>>>> https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a1dadf323c5f00ac4f93b231adc13e34... >>>>>>>>>> <https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a1dadf323c5f00ac4f93b231adc13e34c> >>>>>>>>>> >>>>>>>>>> https://files.ettus.com/manual/classuhd_1_1usrp_1_1cal_1_1database.html#a5605b43f778efc10f29cb616afb... >>>>>>>>>> <https://files.ettus.com/manual/classuhd_1_1usrp_1_1cal_1_1database.html#a5605b43f778efc10f29cb616afbfb7d9> >>>>>>>>>> https://files.ettus.com/manual/page_power.html >>>>>>>>>> _______________________________________________ >>>>>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>>>>>> >>>>>>>> _______________________________________________ >>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>> >>>> _______________________________________________ >>> USRP-users mailing list -- usrp-users@lists.ettus.com >>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>> >> _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
