[USRP-users] Re: RFNOC packet size - Keep one in N
Hi Lorenzo,
Regarding the SPP=364, this sounds like it is being set according to your
Ethernet transport MTU. Sometimes the NIC defaults to MTU=1500 rather than
9000. If I am right it means that even if you created a graph without K1N,
you would still get SPP=364. If the Ethernet MTU is set to 9000, I would
expect that the SPP would resolve to 2000.
Regarding the 2048 vs 2044, you might be running into a limitation there.
With the packet header bytes, the maximum payload length might not be able
to reach 2048 - I'm not really certain. But, as a test, you could try 2000
(after you resolve the SPP=364 issue).
Rob
On Mon, Feb 27, 2023 at 6:36 PM Minutolo, Lorenzo
wrote:
> Hi All,
> I am trying to build a firmware for an x300 device that uses the radio
> block and the Keep-1-in-N block using UHD 4.4.
> For my application I need the Keep-1-in-N block to operate in packet
> mode, on packets 2048 samples long.
>
> Before connecting the graph, I try to set the radio block to use packets
> of that length with the following command (C++):
> radio_control->set_property("spp", 2048, 0);
> The first issue arises as, calling the function to check the spp, I read
> 2044 instead of 2048.
>
> After connecting the graph with radio RX->K1N->RX_streamer I check again
> for the radio spp and I get 364.
>
> Reading this page:
>
> https://kb.ettus.com/RFNoC_Frequently_Asked_Questions#What_is_the_SEP_buffer_size.3F
>
> I understand I could possibly use a larger packet by changing the CHDR
> width of the design. If I change the value in my YML file, I get Vivado to
> throw an error saying that 64 is the only value supported for the device.
>
> Running the design compiled with 64 bit CHDR width results in an even
> different packet size written on file.
>
> The questions are:
>
>1. how can I make the radio to work with packets 2048 samples long in
>a x300? Does changing the SEP buffer size help? I'm currently using 8192 as
>buffer size.
>2. why introducing the K1N block reduces the packet size to 364
>samples? how do I change this behaviour?
>
> I can share the whole code/firmware if needed.
>
> Thanks in advance for the help.
> Lorenzo
> ___
> 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] Re: Wrong Measurement Results
Hi Henry, I am unsure if you tried with an "LO offset" or if you just changed your center frequency. Changing the center frequency will not avoid the problems which can occur at the LO frequency. There are two ways you can create a CW signal that is offset from the LO frequency. You can either change the "LO offset" setting of the tuning options or you can use a waveform that inherently has an offset frequency. Rob On Tue, Feb 28, 2023 at 1:21 AM wrote: > Hello, again. > > I tried with step attenuators and the result is there was difference > around 2dB between 0 degree and 180 degree rotation of horn without > attenuator. When I connected the attenuators to rx and tx paths, the > difference raised around 10dB. When I change step of attenuator, I can > decrease difference at 2, 3dB. But I can’t fix this. > > Yes my signal is CW wiothout offset. I tried to shift the center frequency > of receiver. But the result is same. But I discovered something, When I > switch the center frequency with 10MHz step, like starting 4GHz to 4.4GHz > with 10MHz step, there is no difference at 0 and 180 degree of horn in some > frequencies. And also, If change the antenna location, I can find the > location which is no difference at 0 and 180 degree in same frequency like > just 4GHz. > > VNA is using swept technique. I know the values are uncalibrated in GNU > Radio, I don’t care about the actual values at this stage, maybe i can > improve the systems in the coming days but not now. Actually, When I rotate > the Horn 45 degree in roll-axes, I can see 3dB decrease. In cross position, > I mean 90 degree, Values are sensible. I can see the same result in VNA at > the same degree except 180 degree. That doesn’t make sense. > > Thanks for all answers. > ___ > 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] Re: RFNOC4, FFT Block, Python
Hi,
Sorry for reviving this thread, I still have found no solution to this problem.
I moved my application from python to c++ for performance reasons and the issue
is somehow different.
I found this old thread about the fft length on rfnoc:
https://www.mail-archive.com/usrp-users@lists.ettus.com/msg07587.html
Apparently you can modify the fft block to accept multiple smaller packets,
perform the fft and output multiple packets.
The drawbacks are that you have to manually reset the fft (to avoid frames
being mixed in different streams) and that errors will somehow be mishandled.
Has there been any work in this direction? Is the modification as simple as
changing some parameter in the xilinx FFT IP definition in uhd?
Would be nice to have this feature by default, I'm trying to implement it,
regardless of the drawbacks, because in the end I will need a real time FFT of
2048 samples.
Thanks,
Lorenzo
From: Rob Kossler
Sent: Tuesday, September 13, 2022 6:54 AM
To: Minutolo, Lorenzo
Cc: USRP-users@lists.ettus.com
Subject: Re: [USRP-users] RFNOC4, FFT Block, Python
Hi Lorenzo,
The FFT block requires the number of samples per packet to exactly equal the
FFT size. When the graph commits, UHD will try to resolve a packet size that
all of the blocks are happy with. Perhaps if the FFT size is 2^11, this packet
size may be bigger than the radio wants to deliver (or bigger than the SPP you
specified in the rx_streamer, I don't really know).
In my opinion, this is a really unnecessary limitation of the stock FFT block.
With relatively minor changes, this block would not need any linkage between
packet size and FFT length.
Rob
On Mon, Sep 12, 2022 at 8:20 PM Minutolo, Lorenzo
mailto:minut...@caltech.edu>> wrote:
Hi All,
I'm using UHD 4.2 to play around with RFNOC4. I successfully added an FFT block
to the XG image of an X300, no static connections. uhd_usrp_probe returns as
expected. I use the attached code to test it out.
When I commit the graph I get the following error:
Traceback (most recent call last):
File "/home/lorenzo/test_rfnoc_fft.py", line 71, in
graph.commit()
RuntimeError: ValueError: samples per package must not be smaller than atomic
item size
Digging a bit in the libraries I see that it originates from
rfnoc_streamer.cpp, specifically:
[...]
if (ais.is_valid()) {
const auto spp = this->rx_streamer_impl::get_max_num_samps();
if (spp < ais.get()) {
throw uhd::value_error("samples per package must not be
smaller than atomic item size");
}
[...]
Has someone encountered this error before?
Thenks,
Lorenzo
Attached code:
args = "addr=192.168.30.2"
graph = uhd.rfnoc.RfnocGraph(args)
radio_ID_A = uhd.rfnoc.BlockID(0, "Radio", 0);
radio_block_A = graph.get_block(radio_ID_A);
radio_ctrl_A = uhd.rfnoc.RadioControl(radio_block_A)
set_freq = 300e6
spp = 512
radio_ctrl_A.set_tx_frequency(set_freq, 0)
tx_freq = radio_ctrl_A.get_tx_frequency(0)
radio_ctrl_A.set_rx_frequency(set_freq, 0)
rx_freq = radio_ctrl_A.get_rx_frequency(0)
print("Tuning is TX %.1f, RX: %.1f MHz" % (tx_freq/1e6,rx_freq/1e6 ) )
radio_ctrl_A.set_properties(f'spp={spp}', 0)
radio_ctrl_A.set_rx_antenna('RX2',0)
radio_ctrl_A.set_rate(200e6)
DDC_ID = graph.find_blocks("DDC")[0]
DDC_block = graph.get_block(DDC_ID)
DDC_control = uhd.rfnoc.DdcBlockControl(DDC_block)
DDC_control.set_input_rate(200e6, 0)
DDC_control.set_output_rate(5e6, 0)
FFT_ID = graph.find_blocks("FFT")[0]
FFT_block = graph.get_block(FFT_ID)
FFT_control = uhd.rfnoc.FftBlockControl(FFT_block)
FFT_control.set_length(spp)
FFT_control.set_magnitude(uhd.libpyuhd.rfnoc.fft_magnitude.COMPLEX)
FFT_control.set_direction(uhd.libpyuhd.rfnoc.fft_direction.FORWARD)
FFT_control.set_shift_config(uhd.libpyuhd.rfnoc.fft_shift.REVERSE)
stream_args = uhd.usrp.StreamArgs('fc32','sc16')
stream_args.args = 'spp='+str(spp)
rx_stream = graph.create_rx_streamer(1, stream_args)
graph.connect(
radio_ID_A,0,
DDC_ID,0,
False
)
graph.connect(
DDC_ID,0,
FFT_ID,0,
False
)
graph.connect(
FFT_ID,0,
rx_stream,0
)
graph.commit()
___
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] Re: RFNOC packet size - Keep one in N
I see,
I'll try and play with the network parameters to see if anything changes.
The large packet strategy doesn't seem to be the best approach for what I am
doing anyway, since I cannot reach 2048 samples.
I'll also try to modify the K1N block to me more like a Keep-M-in-N block.
Where the M packets are not discarded but accumulated.
Hopefully the combination of this mod and a packet resize on the FFT side will
allow me to make a 2048 samples long decimation and FFT.
Your help is really appreciated.
Lorenzo
From: Rob Kossler
Sent: Tuesday, February 28, 2023 8:05 AM
To: Minutolo, Lorenzo
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] RFNOC packet size - Keep one in N
Hi Lorenzo,
Regarding the SPP=364, this sounds like it is being set according to your
Ethernet transport MTU. Sometimes the NIC defaults to MTU=1500 rather than
9000. If I am right it means that even if you created a graph without K1N, you
would still get SPP=364. If the Ethernet MTU is set to 9000, I would expect
that the SPP would resolve to 2000.
Regarding the 2048 vs 2044, you might be running into a limitation there. With
the packet header bytes, the maximum payload length might not be able to reach
2048 - I'm not really certain. But, as a test, you could try 2000 (after you
resolve the SPP=364 issue).
Rob
On Mon, Feb 27, 2023 at 6:36 PM Minutolo, Lorenzo
mailto:minut...@caltech.edu>> wrote:
Hi All,
I am trying to build a firmware for an x300 device that uses the radio block
and the Keep-1-in-N block using UHD 4.4.
For my application I need the Keep-1-in-N block to operate in packet mode, on
packets 2048 samples long.
Before connecting the graph, I try to set the radio block to use packets of
that length with the following command (C++):
radio_control->set_property("spp", 2048, 0);
The first issue arises as, calling the function to check the spp, I read 2044
instead of 2048.
After connecting the graph with radio RX->K1N->RX_streamer I check again for
the radio spp and I get 364.
Reading this page:
https://kb.ettus.com/RFNoC_Frequently_Asked_Questions#What_is_the_SEP_buffer_size.3F
I understand I could possibly use a larger packet by changing the CHDR width of
the design. If I change the value in my YML file, I get Vivado to throw an
error saying that 64 is the only value supported for the device.
Running the design compiled with 64 bit CHDR width results in an even different
packet size written on file.
The questions are:
1. how can I make the radio to work with packets 2048 samples long in a
x300? Does changing the SEP buffer size help? I'm currently using 8192 as
buffer size.
2. why introducing the K1N block reduces the packet size to 364 samples? how
do I change this behaviour?
I can share the whole code/firmware if needed.
Thanks in advance for the help.
Lorenzo
___
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] Re: Wrong Measurement Results
On 28/02/2023 01:20, henry.powell...@gmail.com wrote: Hello, again. I tried with step attenuators and the result is there was difference around 2dB between 0 degree and 180 degree rotation of horn without attenuator. When I connected the attenuators to rx and tx paths, the difference raised around 10dB. When I change step of attenuator, I can decrease difference at 2, 3dB. But I can’t fix this. Yes my signal is CW wiothout offset. I tried to shift the center frequency of receiver. But the result is same. But I discovered something, When I switch the center frequency with 10MHz step, like starting 4GHz to 4.4GHz with 10MHz step, there is no difference at 0 and 180 degree of horn in some frequencies. And also, If change the antenna location, I can find the location which is no difference at 0 and 180 degree in same frequency like just 4GHz. VNA is using swept technique. I know the values are uncalibrated in GNU Radio, I don’t care about the actual values at this stage, maybe i can improve the systems in the coming days but not now. Actually, When I rotate the Horn 45 degree in roll-axes, I can see 3dB decrease. In cross position, I mean 90 degree, Values are sensible. I can see the same result in VNA at the same degree except 180 degree. That doesn’t make sense. Thanks for all answers. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com Henry: The fact that antenna position within your space makes a difference indicates to me that this is utterly unrelated to the radio at all. I use USRPs in radio astronomy, where we try to get repeatable measurements day-over-day. We generally achieve that to within about 0.4dB -- and only a tiny fraction of the non-repeatable is the radio. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] How I can chagne RFNOC blocks to another daughter board or RF B?
I simulated an RX RFNOC block as a receiver, it works correctly but I want to RX RFNOC blocks to be executed on RF B or another daughter board. how can change it to another daughter board... Thanks very much. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: How I can chagne RFNOC blocks to another daughter board or RF B?
On 28/02/2023 13:22, sp wrote: I simulated an RX RFNOC block as a receiver, it works correctly but I want to RX RFNOC blocks to be executed on RF B or another daughter board. how can change it to another daughter board... Thanks very much. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com If you look at the 'rfnoc_rx_to_file.cpp' example in the source-code repository, you can see that there are "radio-id" and "radio-chan" command-line parameters. LInes 307 to 320 show the high-level RFNoC API for accessing the different channels within the device. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Underflows every 33s at 200 Msps
Hello, I have a simple application (C++) that essentially copies input to output. Using X310, direct connect 10 GbE, DPDK. Each thread is tied to an isolated core, none of the cores (other than DPDK) uses more than 75%. UHD: GNU C++ version 9.4.0; Boost_107100; DPDK_19.11; UHD_4.4.0.0-0-g5fac246b Kernel command line: iommu=pt intel_iommu=on hugepages=1024 isolcpus=1-7 nohz_full=1-7 rcu_nocbs=1-7 irqaffinity=0 intel_idle.max_cstate=0 ipv6.disable=0 fips=1 . I have turned off all the services I can think of, including irqbalance. I am seeing an underflow event every ~33.4s. Very repeatable across runs. Anyone have any idea what could be causing this? Eugene. Eugene Grayver, Ph.D. Aerospace Corp., Principal Engineer Tel: 310.336.1274 ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Underflows every 33s at 200 Msps
On 28/02/2023 18:56, Eugene Grayver wrote: Hello, I have a simple application (C++) that essentially copies input to output. Using X310, direct connect 10 GbE, DPDK. Each thread is tied to an isolated core, none of the cores (other than DPDK) uses more than 75%. UHD: GNU C++ version 9.4.0; Boost_107100; DPDK_19.11; UHD_4.4.0.0-0-g5fac246b Kernel command line: |iommu=pt intel_iommu=on hugepages=1024 isolcpus=1-7 nohz_full=1-7 rcu_nocbs=1-7 irqaffinity=0 intel_idle.max_cstate=0 ipv6.disable=0 fips=1|. I have turned off all the services I can think of, including irqbalance. I am seeing an underflow event every ~33.4s. Very repeatable across runs. Anyone have any idea what could be causing this? Eugene. This is a "loopback through the computer stack" type application? Basically a receiver and a transmitter, in separate threads, but sharing a buffer between them? These can be tricky, and plenty of others have "stumbled" with this type of app, particularly at high sample rates. I've never done one of these myself, but I suspect that some kind of elastic FIFO mechanism will be required. I"m happy to have others chime in, but this class of application, despite its *appearance* of simplicity can reveal the limitations of ordinary general-purpose operating systems, and their schedulers, and buffer-management systems. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] No module named 'uhd'
Hi USRP users, I am currently developing an OOT RFNoC module. When I tried to build a custom image, it gave me errors as below. I checked the python path, and it seems fine. Is there anyone that has any idea of the reason for this? I am using n310 with uhd v4.2.0.0. (I checked with uhd4.0, and didn't encounter this problem). Thanks in advance. Best regards. Traceback (most recent call last): File "/usr/local/bin/rfnoc_image_builder", line 29, in from uhd.imgbuilder import image_builder ModuleNotFoundError: No module named 'uhd' make[3]: *** [icores/CMakeFiles/n310_rfnoc_image_core.dir/build.make:57: icores/CMakeFiles/n310_rfnoc_image_core] Error 1 make[2]: *** [CMakeFiles/Makefile2:300: icores/CMakeFiles/n310_rfnoc_image_core.dir/all] Error 2 make[1]: *** [CMakeFiles/Makefile2:307: icores/CMakeFiles/n310_rfnoc_image_core.dir/rule] Error 2 make: *** [Makefile:203: n310_rfnoc_image_core] Error 2 ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: No module named 'uhd'
I also checked the uhd installation logs. Why it couldn't find the uhd module? -- Up-to-date: /usr/local/lib/python3.8/site-packages/uhd -- Up-to-date: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/yaml_utils.py -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/__init__.py -- Up-to-date: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/rfnoc_image_core.vh.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/rfnoc_image_core.v.mako -- Up-to-date: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/connect_io_ports.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/device_transport.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/ctrl_crossbar.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/device_io_ports.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/chdr_xb_sep_transport.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/rfnoc_block.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/drive_unused_ports.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/static_router.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/stream_endpoints.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/sep_xb_wires.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/connect_clk_domains.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/image_builder.py On Wed, Mar 1, 2023 at 11:52 AM AERMAN TUERXUN. < armantur...@g.ecc.u-tokyo.ac.jp> wrote: > Hi USRP users, > > I am currently developing an OOT RFNoC module. > When I tried to build a custom image, it gave me errors as below. > I checked the python path, and it seems fine. > Is there anyone that has any idea of the reason for this? > I am using n310 with uhd v4.2.0.0. > (I checked with uhd4.0, and didn't encounter this problem). > > Thanks in advance. > Best regards. > > Traceback (most recent call last): > File "/usr/local/bin/rfnoc_image_builder", line 29, in > from uhd.imgbuilder import image_builder > ModuleNotFoundError: No module named 'uhd' > make[3]: *** [icores/CMakeFiles/n310_rfnoc_image_core.dir/build.make:57: > icores/CMakeFiles/n310_rfnoc_image_core] Error 1 > make[2]: *** [CMakeFiles/Makefile2:300: > icores/CMakeFiles/n310_rfnoc_image_core.dir/all] Error 2 > make[1]: *** [CMakeFiles/Makefile2:307: > icores/CMakeFiles/n310_rfnoc_image_core.dir/rule] Error 2 > make: *** [Makefile:203: n310_rfnoc_image_core] Error 2 > > > ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: No module named 'uhd'
On 28/02/2023 23:01, AERMAN TUERXUN. wrote: I also checked the uhd installation logs. Why it couldn't find the uhd module? -- Up-to-date: /usr/local/lib/python3.8/site-packages/uhd -- Up-to-date: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/yaml_utils.py -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/__init__.py -- Up-to-date: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/rfnoc_image_core.vh.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/rfnoc_image_core.v.mako -- Up-to-date: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/connect_io_ports.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/device_transport.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/ctrl_crossbar.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/device_io_ports.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/chdr_xb_sep_transport.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/rfnoc_block.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/drive_unused_ports.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/static_router.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/stream_endpoints.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/sep_xb_wires.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/connect_clk_domains.v.mako -- Installing: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/image_builder.py On Wed, Mar 1, 2023 at 11:52 AM AERMAN TUERXUN. wrote: Hi USRP users, I am currently developing an OOT RFNoC module. When I tried to build a custom image, it gave me errors as below. I checked the python path, and it seems fine. Is there anyone that has any idea of the reason for this? I am using n310 with uhd v4.2.0.0. (I checked with uhd4.0, and didn't encounter this problem). Thanks in advance. Best regards. Traceback (most recent call last): File "/usr/local/bin/rfnoc_image_builder", line 29, in from uhd.imgbuilder import image_builder ModuleNotFoundError: No module named 'uhd' make[3]: *** [icores/CMakeFiles/n310_rfnoc_image_core.dir/build.make:57: icores/CMakeFiles/n310_rfnoc_image_core] Error 1 make[2]: *** [CMakeFiles/Makefile2:300: icores/CMakeFiles/n310_rfnoc_image_core.dir/all] Error 2 make[1]: *** [CMakeFiles/Makefile2:307: icores/CMakeFiles/n310_rfnoc_image_core.dir/rule] Error 2 make: *** [Makefile:203: n310_rfnoc_image_core] Error 2 ___ USRP-users mailing list --usrp-users@lists.ettus.com To unsubscribe send an email tousrp-users-le...@lists.ettus.com Maybe your ld.so.conf doesn't include /usr/local/lib, or you didn't "sudo ldconfig" after doing the install? What's in your PYTHONPATH? Is that path actually *exported* or did you set it locally in your .bashrc (or equivalent). If you manually go into python and: import uhd What happens? ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: No module named 'uhd'
Hi Marcus, Thank you for your help. I set it in the .bashrc file before. I exported it and now it's working. Best regards On Wed, Mar 1, 2023 at 1:06 PM Marcus D. Leech wrote: > On 28/02/2023 23:01, AERMAN TUERXUN. wrote: > > I also checked the uhd installation logs. > Why it couldn't find the uhd module? > > -- Up-to-date: /usr/local/lib/python3.8/site-packages/uhd > -- Up-to-date: /usr/local/lib/python3.8/site-packages/uhd/imgbuilder > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/yaml_utils.py > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/__init__.py > -- Up-to-date: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/rfnoc_image_core.vh.mako > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/rfnoc_image_core.v.mako > -- Up-to-date: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/connect_io_ports.v.mako > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/device_transport.v.mako > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/ctrl_crossbar.v.mako > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/device_io_ports.v.mako > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/chdr_xb_sep_transport.v.mako > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/rfnoc_block.v.mako > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/drive_unused_ports.v.mako > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/static_router.v.mako > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/stream_endpoints.v.mako > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/sep_xb_wires.v.mako > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/templates/modules/connect_clk_domains.v.mako > -- Installing: > /usr/local/lib/python3.8/site-packages/uhd/imgbuilder/image_builder.py > > On Wed, Mar 1, 2023 at 11:52 AM AERMAN TUERXUN. < > armantur...@g.ecc.u-tokyo.ac.jp> wrote: > >> Hi USRP users, >> >> I am currently developing an OOT RFNoC module. >> When I tried to build a custom image, it gave me errors as below. >> I checked the python path, and it seems fine. >> Is there anyone that has any idea of the reason for this? >> I am using n310 with uhd v4.2.0.0. >> (I checked with uhd4.0, and didn't encounter this problem). >> >> Thanks in advance. >> Best regards. >> >> Traceback (most recent call last): >> File "/usr/local/bin/rfnoc_image_builder", line 29, in >> from uhd.imgbuilder import image_builder >> ModuleNotFoundError: No module named 'uhd' >> make[3]: *** [icores/CMakeFiles/n310_rfnoc_image_core.dir/build.make:57: >> icores/CMakeFiles/n310_rfnoc_image_core] Error 1 >> make[2]: *** [CMakeFiles/Makefile2:300: >> icores/CMakeFiles/n310_rfnoc_image_core.dir/all] Error 2 >> make[1]: *** [CMakeFiles/Makefile2:307: >> icores/CMakeFiles/n310_rfnoc_image_core.dir/rule] Error 2 >> make: *** [Makefile:203: n310_rfnoc_image_core] Error 2 >> >> >> > ___ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > > Maybe your ld.so.conf doesn't include /usr/local/lib, or you didn't "sudo > ldconfig" after doing the install? > > What's in your PYTHONPATH? Is that path actually *exported* or did you > set it locally in your .bashrc (or equivalent). > > If you manually go into python and: > > import uhd > > What happens? > > > ___ > 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] Re: Wrong Measurement Results
Hello, I am sharing how i did it. I set lo_offset=20e3 then i am changing center_frequency. Also thank you Marcus, have a nice day. ``` self.uhd_usrp_source_0.set_center_freq(uhd.tune_request(center_freq, rf_freq=center_freq-lo_offset, rf_freq_policy=uhd.tune_request.POLICY_MANUAL), 0) self.uhd_usrp_sink_0.set_center_freq(uhd.tune_request(center_freq, rf_freq=center_freq-lo_offset, rf_freq_policy=uhd.tune_request.POLICY_MANUAL), 0) ``` ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
