Re: [USRP-users] RFNoC block fpga control source issues
Hey Jonathon, I had a chance to debug this a little further (On an N300) and have observed the following behavior: The command packets are getting through to the radio block but are being buffered somewhere along the line so that the first command is either not received or not processed until exactly 16 have been sent. So if I am sending commands in a loop, there is a 16 command delay before the settings bus writes and a rx command is triggered in the radio. This seems to indicate that there is a buffer somewhere that doesn’t pass the commands until it is full. Any thoughts on what the culprit could be? Sam On Oct 23, 2018, 11:17 PM -0700, Jon Pendlum , wrote: > Hey Sam, > > There have been some changes to noc_shell, maybe they are related to your > issue. If you want to try to debug this on the FPGA, I suggest using > chipscope on the file cmd_pkt_proc.v. That is the state machine that receives > command packets and issues settings bus writes. You should be able to see > your command packets come in and get processed by the state machine. You can > double check the command packet / timed command vita time versus the radio > core's vita time. You can also see if the state machine gets stuck in a > certain state. > > Jonathon > > > On Wed, Oct 24, 2018 at 9:44 AM Samuel Prager wrote: > > > Hi Jonathan, > > > > > > Just following up on this. I have switched to the UHD 3.13 release + FPGA > > > version 5.2. This issue still persists. > > > > > > Is it possible that a change to UHD could be causing this to not work? > > > > > > If anyone can confirm that they are able to send commands to the radio > > > block from an rfnoc block in recent versions of UHD it would help a lot. > > > > > > Thanks, > > > > > > Sam > > > > > > On Oct 22, 2018, 1:06 PM -0700, Samuel Prager , wrote: > > > > Hi Jonathan, > > > > > > > > Yes I add my block and the radio block, connect them and tell my block > > > > to send commands to radio block. I have confirmed today that the > > > > simulation still works correctly in Vivado 2017.4 — the settings > > > > registers are written as expected, an rx command is generated in the > > > > radio and the correct number of samples are streamed back into the > > > > tb_streamer. > > > > > > > > Sam > > > > On Oct 21, 2018, 9:20 AM -0700, Jon Pendlum , > > > > wrote: > > > > > How does your testbench work? Do you add the radio core block, send > > > > > timed commands to it, and see the outputs toggle? > > > > > > > > > > > On Sat, Oct 20, 2018 at 1:05 PM Samuel Prager > > > > > > wrote: > > > > > > > Hi Jonathon, > > > > > > > > > > > > > > Thanks for the response! Yes I’m using ce_clk and ce_rst. Thanks > > > > > > > for sharing your code — the only real difference I see is that > > > > > > > you increment the seq_num. I am leaving it as 12’b0 — could this > > > > > > > be causing an issue? > > > > > > > > > > > > > > I should also say that In my case, the command packets are being > > > > > > > sent to the radio block to trigger timed receive commands in > > > > > > > order to reduce the number of software sr_writes. > > > > > > > > > > > > > > Here’s my code just in case: https://pastebin.com/Asgj7Jw2. > > > > > > > > > > > > > > This is something that was simulated/verified and worked in the > > > > > > > past, but perhaps a change has been made that prevents this from > > > > > > > working? > > > > > > > > > > > > > > I will try a release tag as soon as possible — however this is > > > > > > > something I’ve been seeing for a couple of months now that has > > > > > > > kept me on pre-2017.4 releases. > > > > > > > > > > > > > > Sam > > > > > > > On Oct 19, 2018, 8:17 PM -0700, Jon Pendlum > > > > > > > , wrote: > > > > > > > > Hi Sam, > > > > > > > > > > > > > > > > I am using command packets to tune the DDC block's DSP > > > > > > > > frequency. Are you using ce_clk and ce_rst for clock and reset? > > > > > > > > Here is my code if you want to take a look: > > > > > > > > https://pastebin.com/1AeHFb0J. Also, it might be worth trying > > > > > > > > your code on a release tag like v3.13.0.2 in case master has a > > > > > > > > regression. > > > > > > > > > > > > > > > > Jonathon > > > > > > > > > > > > > > > > > On Sat, Oct 20, 2018 at 8:11 AM Samuel Prager via USRP-users > > > > > > > > > wrote: > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > I have an RFNoC block that generates command packets to > > > > > > > > > > write settings registers of the downstream connected block > > > > > > > > > > using the Control Source (cmdout_tdata) of the noc_shell . > > > > > > > > > > Previously this had worked perfectly (prior to > > > > > > > > > > approximately d6b2283 on rfnoc-devel), for both the X300 > > > > > > > > > > and E310, but this functionality appears to perhaps be > > > > > > > > > > broken in the more recent FPGA releases — since around the > > > > > > > > > > switch to Vivado 2017.4 and the move of the noc
Re: [USRP-users] downconversion in rfnoc-radio_loopback
On 10/25/2018 07:03 PM, Chatterjee, Pratik wrote: Thank you for your response. I tried transmitting at a different frequency, still didn't see the baseband signal. Seeing a 3GHz carrier on the output ./rfnoc_radio_loopback --rx-freq=4e9 --tx-freq=3e9 --rate=200e6 --spp=600 I forgot to mention that I am using a wired setup. Signal generator to splitter, splitter to sdr rx and Scope, the sdr tx to Scope. *From:* USRP-users on behalf of Marcus D. Leech via USRP-users *Sent:* Thursday, October 25, 2018 5:22:09 PM *To:* usrp-users@lists.ettus.com *Subject:* Re: [USRP-users] downconversion in rfnoc-radio_loopback On 10/25/2018 04:57 PM, Chatterjee, Pratik via USRP-users wrote: Hi, While testing the rfnoc_radio_loopback.cpp from the 6af6ac3 commit on master, I found that if I send a 50 MHz signal on top of a 4 GHz carrier to the SDR, on the loopback output I just get a 4GHz carrier. I looked into the rfnoc_radio_loopback.cpp file and found no DDC or DUC blocks. Could this be the reason for receiving no baseband signal in loopback (no down conversion logic happening) or am I missing something Has anyone used this file before? Arguments are as follows ./rfnoc_radio_loopback --rx-freq=4e9 --tx-freq=4e9 --rate=200e6 --spp=600 thanks, VP Your TX and RX frequencies are the same--how are you isolating the antennae from one another? What happens if you make your TX frequency different from your RX frequency (which is usually how a repeater works). You should probably specify an RX gain and TX gain -- how much power are you injecting into the RX side? More than -15dBm is near the linearity limits, and much "louder" and you risk device damage to the RX. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] downconversion in rfnoc-radio_loopback
Thank you for your response. I tried transmitting at a different frequency, still didn't see the baseband signal. Seeing a 3GHz carrier on the output ./rfnoc_radio_loopback --rx-freq=4e9 --tx-freq=3e9 --rate=200e6 --spp=600 I forgot to mention that I am using a wired setup. Signal generator to splitter, splitter to sdr rx and Scope, the sdr tx to Scope. From: USRP-users on behalf of Marcus D. Leech via USRP-users Sent: Thursday, October 25, 2018 5:22:09 PM To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] downconversion in rfnoc-radio_loopback On 10/25/2018 04:57 PM, Chatterjee, Pratik via USRP-users wrote: Hi, While testing the rfnoc_radio_loopback.cpp from the 6af6ac3 commit on master, I found that if I send a 50 MHz signal on top of a 4 GHz carrier to the SDR, on the loopback output I just get a 4GHz carrier. I looked into the rfnoc_radio_loopback.cpp file and found no DDC or DUC blocks. Could this be the reason for receiving no baseband signal in loopback (no down conversion logic happening) or am I missing something Has anyone used this file before? Arguments are as follows ./rfnoc_radio_loopback --rx-freq=4e9 --tx-freq=4e9 --rate=200e6 --spp=600 thanks, VP Your TX and RX frequencies are the same--how are you isolating the antennae from one another? What happens if you make your TX frequency different from your RX frequency (which is usually how a repeater works). ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] GNU Radio and RFNoC Hackfest, Nov 12-16 in Santa Clara, CA!
*Greetings USRP Community,* Announcing the *GNU Radio* and *RFNoC Hackfest* at NI Silicon Valley! The GNU Radio and RFNoC HackFest will provide an opportunity for SDR developers to collaborate in person, and work on problems, bugs, or projects related to GNU Radio and RFNoC. *When* November 12th - 16th, 2018 (Monday - Friday) *Where* National Instruments 4600 Patrick Henry Dr Santa Clara, CA 95054 This event is designed to provide a stage for people to talk in front of fellow developers about problems they're currently working on. The majority of the week will be reserved for working groups to collaboratively discuss, work and debug issues related to GNU Radio and RFNoC projects. To help facilitate discussions and help with issues, Ettus Research software engineers will be on hand throughout the week. On Wednesday, an update on the future of RFNoC will be shared with participants. *Logistics* This is a free event hosted by National Instruments and food and drinks will be provided throughout the week. The National Instruments office in Santa Clara is within 7 miles of the Norman Y. Mineta San Jose International Airport (SJC), and there are plenty of hotels within a 1-5 mile radius. Please RSVP using the link below: https://www.ettus.com/gnu-radio-hackfest We look forward to seeing you there! ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] downconversion in rfnoc-radio_loopback
On 10/25/2018 04:57 PM, Chatterjee, Pratik via USRP-users wrote: Hi, While testing the rfnoc_radio_loopback.cpp from the 6af6ac3 commit on master, I found that if I send a 50 MHz signal on top of a 4 GHz carrier to the SDR, on the loopback output I just get a 4GHz carrier. I looked into the rfnoc_radio_loopback.cpp file and found no DDC or DUC blocks. Could this be the reason for receiving no baseband signal in loopback (no down conversion logic happening) or am I missing something Has anyone used this file before? Arguments are as follows ./rfnoc_radio_loopback --rx-freq=4e9 --tx-freq=4e9 --rate=200e6 --spp=600 thanks, VP Your TX and RX frequencies are the same--how are you isolating the antennae from one another? What happens if you make your TX frequency different from your RX frequency (which is usually how a repeater works). ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] downconversion in rfnoc-radio_loopback
Hi, While testing the rfnoc_radio_loopback.cpp from the 6af6ac3 commit on master, I found that if I send a 50 MHz signal on top of a 4 GHz carrier to the SDR, on the loopback output I just get a 4GHz carrier. I looked into the rfnoc_radio_loopback.cpp file and found no DDC or DUC blocks. Could this be the reason for receiving no baseband signal in loopback (no down conversion logic happening) or am I missing something Has anyone used this file before? Arguments are as follows ./rfnoc_radio_loopback --rx-freq=4e9 --tx-freq=4e9 --rate=200e6 --spp=600 thanks, VP ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] LO-Offset between two UBX Daugtherboards
On 10/25/2018 11:33 AM, Christopher Willuweit wrote: Hi, thanks for the reply. The offset is constant, i tested for maybe an hour using different flow graphs.I also expected absolute error of maybe 20ppm, jitter and varying frequency changes but not a constant offset between the two frontends. Can you reproduce this behaviour? I only have 1 UBX in my lab. Perhaps someone in Ettus R can reproduce the results, or comment on why this is to be expected. I'll note that the residual frequency error we're talking about is only 5PPB, but in the case at hand, it really should be zero. *Von:* USRP-users im Auftrag von Marcus D. Leech via USRP-users *Gesendet:* Donnerstag, 25. Oktober 2018 17:14:57 *An:* usrp-users@lists.ettus.com *Betreff:* Re: [USRP-users] LO-Offset between two UBX Daugtherboards On 10/25/2018 04:16 AM, Christopher Willuweit via USRP-users wrote: Hi all, I want to use a single X310 w/ two UBX-160-Daughterboards for a simple transmission setup. You can find the GRC-Flowgraph and a screenshot of the result attached in this mail. I'm experiencing an LO-Offset of ~12Hz and just wanted to know if this is normal. As far as i can tell from schematics, the PLLs in the daughterboard have reference clocks generated by a clock distribution chip in the X310. Since the wires are of matched length i would assume that they can be used frequency and phase synchronized. Did i get something wrong with my settings? On the ettus website i can only find information for phase coherent setups using multiple USRPs. For a start a frequency synchronized setup would be sufficient for my application, phase does not matter. Currently i'm using UHD version 3.14.0.HEAD-31-g98057752 kind regards and thanks! Christopher Willuweit I have to admit, this is a bit odd. Does the frequency error change over time? With both UBX getting the same clock, and the same programming, the residual mutual frequency error should be zero. The absolute frequency error, of course, could be much larger, but it will (should) be the same for both UBX -- same PLLs, same refclock, same programming. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] USRP2 Device Configuration
On 10/25/2018 12:06 PM, Farhad Mirkazemi wrote:
HI Marcus,
Sorry I was away from my office for few days;
*I first made sure I have a new IP address by doing this:*
sudo ./usrp2_recovery.py --ifc=enp4s0 --new-ip=192.168.10.3
[sudo] password for farhad:
('Opening raw socket on interface:', 'enp4s0')
('Loading packet with ip address:', '192.168.10.3')
Sending packet (22 bytes)
Done
*so when I ping for the address 192.168.10.3, I get:*
"ping 192.168.10.3
PING 192.168.10.3 (192.168.10.3) 56(84) bytes of data.
64 bytes from 192.168.10.3: icmp_seq=1 ttl=64 time=0.065 ms
64 bytes from 192.168.10.3: icmp_seq=2 ttl=64 time=0.043 ms
64 bytes from 192.168.10.3: icmp_seq=3 ttl=64 time=0.042 ms
64 bytes from 192.168.10.3: icmp_seq=4 ttl=64 time=0.042 ms
64 bytes from 192.168.10.3: icmp_seq=5 ttl=64 time=0.047 ms
64 bytes from 192.168.10.3: icmp_seq=6 ttl=64 time=0.041 ms
^C
--- 192.168.10.3 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5100ms
rtt min/avg/max/mdev = 0.041/0.046/0.065/0.011 ms"
*but when I do:*
" uhd_usrp_probe --args "addr=192.168.10.3""
I get:
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.009.005-0-g32951af2
Error: LookupError: KeyError: No devices found for ->
Device Address:
addr: 192.168.10.3
*My Ethernet setup is also as follows:*
Inline image
Still any idea?
Many many thanks
-Farhad
Farhad, it seems that you have your host IP address set to the same as
the address of your USRP2. This cannot
work. Every device, whether it's a computer, a USRP, a router, a
server, a toaster, etc, needs an address
that is contextually unique. Set your host (PC) address to
192.168.10.1 and you should be OK.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Core dump after disconnecting radio
If a USRP N210 (and possibly other) radios are disconnected while in use (i.e. while streaming IQ data), the program will end with an exception thrown from within UHD. This can be VERY easily reproduced using the example UHD program rx_stream_to_file with no changes. Simply run: /usr/lib64/uhd/examples/rx_samples_to_file --args addr=192.168.10.2 -duration 20 And wait for the streaming to start. Then disconnect the ethernet cored from the radio. The program will recognize the error and begin to exit gracefully, and then abort with the following backtrace: #0 0x7f8d46c1e1f7 in raise () from /lib64/libc.so.6 #1 0x7f8d46c1f8e8 in abort () from /lib64/libc.so.6 #2 0x7f8d47524ac5 in __gnu_cxx::__verbose_terminate_handler() () from /lib64/libstdc++.so.6 #3 0x7f8d47522a36 in ?? () from /lib64/libstdc++.so.6 #4 0x7f8d475219e9 in ?? () from /lib64/libstdc++.so.6 #5 0x7f8d47522654 in __gxx_personality_v0 () from /lib64/libstdc++.so.6 #6 0x7f8d46fbb903 in ?? () from /lib64/libgcc_s.so.1 #7 0x7f8d46fbbc9b in _Unwind_RaiseException () from /lib64/libgcc_s.so.1 #8 0x7f8d47522c76 in __cxa_throw () from /lib64/libstdc++.so.6 #9 0x7f8d4879f3de in udp_zero_copy_asio_msb::release (this=) at /usr/src/debug/uhd-3.12.0.0/host/lib/transport/udp_zero_copy.cpp:125 #10 0x7f8d485e142e in intrusive_ptr_release (p=) at /usr/src/debug/uhd-3.12.0.0/host/include/uhd/transport/zero_copy.hpp:104 #11 ~intrusive_ptr (this=0x7ffe4921da80, __in_chrg=) at /usr/local/upe/buildtools/include/boost-1_67/boost/smart_ptr/intrusive_ptr.hpp:98 #12 send_pkt (cmd=256, data=, addr=, this=0x856890) at /usr/src/debug/uhd-3.12.0.0/host/lib/usrp/usrp2/usrp2_fifo_ctrl.cpp:165 #13 usrp2_fifo_ctrl_impl::poke32 (this=0x856890, addr=, data=) at /usr/src/debug/uhd-3.12.0.0/host/lib/usrp/usrp2/usrp2_fifo_ctrl.cpp:63 #14 0x7f8d4830e245 in rx_dsp_core_200_impl::issue_stream_command (this=0x859200, stream_cmd=...) at /usr/src/debug/uhd-3.12.0.0/host/lib/usrp/cores/rx_dsp_core_200.cpp:130 #15 0x7f8d48505f0b in operator() (a0=..., this=) at /usr/local/upe/buildtools/include/boost-1_67/boost/function/function_template.hpp:768 #16 issue_stream_cmd (stream_cmd=..., this=0x873718) at /usr/src/debug/uhd-3.12.0.0/host/lib/transport/super_recv_packet_handler.hpp:223 #17 uhd::transport::sph::recv_packet_streamer::issue_stream_cmd (this=0x873710, stream_cmd=...) at /usr/src/debug/uhd-3.12.0.0/host/lib/transport/super_recv_packet_handler.hpp:842 #18 0x0042e246 in recv_to_file > (usrp=..., cpu_format="sc16", wire_format="sc16", channel="0", file="usrp_samples.dat", samps_per_buff=samps_per_buff@entry=1, num_requested_samples=0, time_requested=time_requested@entry=20, bw_summary=false, stats=false, null=false, enable_size_map=false, continue_on_bad_packet=false) at /usr/src/debug/uhd-3.12.0.0/host/examples/rx_samples_to_file.cpp:152 #19 0x0041cbe2 in _main (argc=, argv=) at /usr/src/debug/uhd-3.12.0.0/host/examples/rx_samples_to_file.cpp:387 #20 0x0041a1bb in main (argc=, argv=) at /usr/src/debug/uhd-3.12.0.0/host/examples/rx_samples_to_file.cpp:227 This wouldn't be such a huge problem except that the exception is thrown from a destructor (~intrusive_ptr()), which means it cannot be caught in a C++ program. Has anyone found a solution or workaround to this problem? We are currently using UHD 3.12.0.0. Thanks Will ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] LO-Offset between two UBX Daugtherboards
On 10/25/2018 04:16 AM, Christopher Willuweit via USRP-users wrote: Hi all, I want to use a single X310 w/ two UBX-160-Daughterboards for a simple transmission setup. You can find the GRC-Flowgraph and a screenshot of the result attached in this mail. I'm experiencing an LO-Offset of ~12Hz and just wanted to know if this is normal. As far as i can tell from schematics, the PLLs in the daughterboard have reference clocks generated by a clock distribution chip in the X310. Since the wires are of matched length i would assume that they can be used frequency and phase synchronized. Did i get something wrong with my settings? On the ettus website i can only find information for phase coherent setups using multiple USRPs. For a start a frequency synchronized setup would be sufficient for my application, phase does not matter. Currently i'm using UHD version 3.14.0.HEAD-31-g98057752 kind regards and thanks! Christopher Willuweit I have to admit, this is a bit odd. Does the frequency error change over time? With both UBX getting the same clock, and the same programming, the residual mutual frequency error should be zero. The absolute frequency error, of course, could be much larger, but it will (should) be the same for both UBX -- same PLLs, same refclock, same programming. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] n3xx master clock rate selection
EJ,
Great news! I've also filed a feature request for the 120MHz MCR to keep
things moving on that front. I'm glad you found an intermediate solution!
-Daniel
On Wed, Oct 24, 2018 at 5:07 PM EJ Kreinar wrote:
> Hi Daniel and others interested,
>
> To follow up on our discussion: I ended up making a "quick and dirty"
> rfnoc block to do rational resampling (integer upsample, fractional
> downsample). It's implemented by simply repackaging the existing duc and
> ddc blocks into a new combined noc_block. I've tested the FPGA and software
> targeting the n3xx and I can now hit my target rates of 2, 3, 6, & 10 MHz.
>
> I'm planning to use this block for now, and in case anyone else is
> interested I set up a couple PRs for the changes:
> - uhd: https://github.com/EttusResearch/fpga/pull/32/commits
> - fpga: https://github.com/EttusResearch/uhd/pull/219/commits
> - gr-ettus: https://github.com/EttusResearch/gr-ettus/pull/29/commits
>
> Cheers!
> EJ
>
> On Thu, Oct 18, 2018 at 5:56 PM EJ Kreinar wrote:
>
>> Hi Scott,
>>
>> Thanks for the pointers! I actually tried making these changes this
>> afternoon... This is what I came up with for the LMK table (it appears the
>> sysref_divider wants to be 500 for this rate based on the other
>> calculations):
>>
>> ```
>> clkout_divider = {120e6: 25, 122.88e6: 25, 125e6: 24, 153.6e6: 20}
>> pll1_n_divider = {120e6: 125, 122.88e6: 128, 125e6: 125, 153.6e6: 128}
>> sysref_divider = {120e6: 500, 122.88e6: 500, 125e6: 480, 153.6e6: 400}
>> pll2_prescaler = {120e6:5, 122.88e6:2, 125e6:5, 153.6e6:2}
>> pll2_n_divider = {120e6: 25, 122.88e6: 64, 125e6: 25, 153.6e6: 64}
>> ```
>>
>> And then the obvious changes in ad937x_device::set_master_clock_rate. As
>> expected, some plumbing was required in both magnesium.py and tdc_sync.py
>> to allow a 120MHz master clock rate.
>>
>> The next roadblock comes down to the JESD configuration, specified here:
>> https://github.com/EttusResearch/uhd/blob/master/mpm/python/usrp_mpm/dboard_manager/mg_init.py#L249
>> ... And the JESD configuration is probably where I'm going to leave it for
>> now, since this configuration now appears to involve potentially generating
>> IP and calculating more magic numbers. Hope this can help anyone else
>> looking down this path to this point.
>>
>> I'm not a fan of the "fixed" fractional resampler from xilinx. Since I'm
>> looking at going through the effort of a new noc_block spinup anyway, I
>> would much prefer something programmable. I think I'll chase down the
>> "noc_block_fractional_resampler" instead and see where that leads.
>>
>> Cheers,
>> EJ
>>
>> On Thu, Oct 18, 2018 at 3:41 PM Daniel Jepson via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> EJ,
>>>
>>> We are continuing to investigate the rate selection and possibility of
>>> adding 120 MHz as an MCR option. Our initial choices were (in large part)
>>> driven by the available options and example code provided through their
>>> evaluation software. It appears there is leeway in choosing MCRs, although
>>> anything lower than 122.88 MHz will begin sacrificing BW. The JESD204b core
>>> throughput requirements must typically match exactly the data rates inside
>>> the AD9371, so it is simply a matter of configuring both the AD9371 and the
>>> FPGA with the correct parameters (nothing seems too impossible, just work
>>> to be done). Note there is a difference between the DEVCLK (reference
>>> clock) input to the AD9371 and the actual sampling rate inside the device.
>>> To facilitate synchronization, we match the reference clock rate to the
>>> actual sampling rate.
>>>
>>> To get you going in the mean time, Xilinx provides a free, fixed
>>> fractional resampler through the FIR Compiler that might be helpful and is
>>> fairly lightweight. It's AXI-Stream, so building it into the signal path
>>> shouldn't be too difficult.
>>>
>>> I'll report back when we have more information on the 120 MHz feature
>>> request.
>>>
>>> -Daniel
>>>
>>> On Wed, Oct 17, 2018 at 7:46 PM EJ Kreinar wrote:
>>>
So, I'm trying to understand the fundamental clock rate selection
limitations for the 9371... From what I understand, this is plausibly due
to some limitations of the JESD interface (?).
This wiki answer suggests possible rates of 122.88M, 153.6M, 184.32M,
245.76M, or 307.2M:
https://ez.analog.com/wide-band-rf-transceivers/design-support-ad9371/f/q-a/100289/ad9371-sync-clock-frequencies
Then the 9371 datasheet also shows example rates of 122.88, 153.6,
245.76, and 307.2 MHz: https://www.analog.com/en/products/ad9371.html
So how is it that there's a master clock rate at 125MHz??
EJ
On Wed, Oct 17, 2018, 5:49 PM EJ Kreinar wrote:
> Hi Daniel,
>
> Sad to hear that! By the way, I forgot to mention another important
> rate I need, 3 MHz, that also has an integer relationship to 120 MHz...
> Perhaps I'd like to
Re: [USRP-users] Differences between LOs: companion, internal, external.
On 10/25/2018 05:24 AM, Anabel Almodovar via USRP-users wrote:
Hello,
I would like to know how local oscillators work when they are in
COMPANION mode.
I'm working with an x310 and my intention is that channel 0 exports
its LO to the rest of the channels and to itself. In this way the
signal from all the LOs go the same way.
When I configure the x310 so that the CH0 exports its LO at the same
time that it is as external I get the following error.
/*
*/
/*Actual RX Bandwidth: 100.00 MHz...
Setting LO source...
Unexpected Standard exception from MEX file.
What() is:ValueError: Cannot export an external LO for channel 0
..
*/
This is my code:
/*std::string lo_src = "companion", lo_src1 = "internal", lo_src2 =
"external";
std::cout << boost::format("Setting LO source...") << std::endl <<
std::endl;
usrp->set_rx_lo_export_enabled(true ,uhd::usrp::multi_usrp::ALL_LOS,
0); //habilitar la exportacion de LO
usrp->set_rx_lo_source(lo_src2, uhd::usrp::multi_usrp::ALL_LOS, 0);
usrp->set_rx_lo_source(lo_src2, uhd::usrp::multi_usrp::ALL_LOS, 1);*/
When I use the companion mode in the CH0 instead of external I don't
get any error. However, I don't know exactly how LOs work internally.
I would appreciate if someone could explain me how the companion mode
works.
Regards,
Anabel Almodóvar
The gr-doa application does just this with TwinRX cards--
https://github.com/EttusResearch/gr-doa
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Differences between LOs: companion, internal, external.
Hello,
I would like to know how local oscillators work when they are in COMPANION
mode.
I'm working with an x310 and my intention is that channel 0 exports its LO
to the rest of the channels and to itself. In this way the signal from all
the LOs go the same way.
When I configure the x310 so that the CH0 exports its LO at the same time
that it is as external I get the following error.
*Actual RX Bandwidth: 100.00 MHz...Setting LO source...Unexpected
Standard exception from MEX file.What() is:ValueError: Cannot export an
external LO for channel 0.. *
This is my code:
*std::string lo_src = "companion", lo_src1 = "internal", lo_src2 =
"external";std::cout << boost::format("Setting LO source...") << std::endl
<< std::endl;usrp->set_rx_lo_export_enabled(true
,uhd::usrp::multi_usrp::ALL_LOS, 0); //habilitar la exportacion de
LO usrp->set_rx_lo_source(lo_src2, uhd::usrp::multi_usrp::ALL_LOS, 0);
usrp->set_rx_lo_source(lo_src2, uhd::usrp::multi_usrp::ALL_LOS, 1);*
When I use the companion mode in the CH0 instead of external I don't get
any error. However, I don't know exactly how LOs work internally.
I would appreciate if someone could explain me how the companion mode works.
Regards,
Anabel Almodóvar
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
