Re: [USRP-users] RFNoC block fpga control source issues
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
> > > > > > > block clock domain crossing to axi_wrapper.v). I have tried the
> > > > > > > latest master branch (4f25ed1) with no success.
> > > > > > >
> > > > > > > Is this a known issue? Can anyone shed light on what might have
> > > > > > > caused this?
> > > > > > >
> > > > > > > The control packets are generated in my block as follows:
> > > > > > >
> > > > > > > wire eob = 1’b0;
> > > > > > > wire [1:0] pkt_type = 2'b10;
> > > > > > > wire [11:0] seqnum = 12'd0; // don't care
> > > > > > > wire [15:0] payload_length = 16'd16; //don't care (payload length
> > > > > > > in bytes)
> > > > > > > assign cmd_tdata = {24’d0,set_bus_addr[7:0], set_bus_val[31:0]};
> > > > > > >
> > > > > > > cvita_hdr_encoder cvita_hdr_encoder(
> > > > > > > .pkt_type(pkt_type),.eob(eob), .has_time(1'b0),
> > > > > > > .seqnum(seqnum),
> > > > > > > .payload_length(payload_length),
> > > > > > > .src_sid(src_sid), .dst_sid(dst_sid),
> > > > > > > .vita_time(vita_time),
> > > > > > > .header(cmd_tuser)
> > > > > > > );
> > > > > > >
> > > > > > > chdr_framer #(.SIZE(FIFO_SIZE), .WIDTH(64)) chdr_framer (
> > > > > > > .clk(clk), .reset(reset), .clear(clear),
> > > > > > > .i_tdata(cmd_tdata), .i_tuser(cmd_tuser), .i_tlast(cmd_tlast),
> > > > > > > .i_tvalid(cmd_tvalid), .i_tready(cmd_tready),
> > > > > > > .o_tdata(cmdout_tdata), .o_tlast(cmdout_tlast),
> > > > > > > .o_tvalid(cmdout_tvalid), .o_tready(cmdout_tready));
> > > > > > >
> > > > > > > The command packets appear to never reach the destination rfnoc
> > > > > > > block, but I am at a loss for the cause.
> > > > > > >
> > > > > > > Is anyone currently using the control source functionality of the
> > > > > > > noc_shell? I would really appreciate any pointers on how to fix
> > > > > > > this.
> > > > > > >
> > > > > > > Thank you,
> > > > > > >
> > > > > > > Sam
>
Re: [USRP-users] gr-doa
Hello Arun: The gr-doa OOT was tested with UHD 3.10.1.0 and GNU Radio 3.7.10.1, but it should work with the latest releases, UHD 3.13.0.2 and GNU Radio 3.7.13.4. It uses the default FPGA image that comes with whichever version of UHD that you're using. It does not require any custom or special FPGA image. Please let me know if you have any further questions. --Neel Pandeya On 23 October 2018 at 13:35, Arun kumar Verma via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi > > I am working on Direction of Arrival application using X310, just need > information which FPGA image was used for gr-DOA demo application? > > Arun > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] gr-doa
Hi I am working on Direction of Arrival application using X310, just need information which FPGA image was used for gr-DOA demo application? Arun ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Virtual Test Environment for E310
I am developing RFNoC blocks and looking for options for regression test suites. Is anyone aware of work towards being able to virtualize/model/simulate (or co-simulate) GNURadio with RFNoC? I have some simulations running with Vivado, but that does not directly tie into GNURadio. Ideally, I'd like to be able to setup some VMs to run the regression suite in parallel. Thanks, - Brendon smime.p7s Description: S/MIME cryptographic signature ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Messaging the DDC
I wanted to close this link for others in case they stumble upon this thread (I forgot to do this earlier). The messages were indeed working fine, the problem was that I was tuning to the wrong place, and couldn't see my signal, so I didn't realize it was working. Since it is a CORDIC, if you are off by -2.5MHz (negative 2.5) say, you need to tune positive 2.5MHz to offset the negative spin (and vice-versa). All you need to do is send a dict with freq and the frequency you wantand it will work like a champ. - Original Message - Subject: RE: Re: [USRP-users] Messaging the DDC From: "Jason Matusiak" Date: 10/3/18 2:58 pm To: "Marcus Mller" , usrp-users@lists.ettus.com Marcus, Looking a little closer, I am a little confused. I can make the change, and that allows the message block to appear in GRC, but I am thinking that I need to uncomment the argument commands that set the DDS value, right? I don't see how it would work otherwise (Though it can be poked in via a variable, so I am not sure why that would work). - Original Message - Subject: RE: Re: [USRP-users] Messaging the DDC From: "Jason Matusiak" Date: 10/3/18 9:27 am To: "Marcus Mller" , usrp-users@lists.ettus.com Sorry, Marcus, I was out yesterday and then missed these responses. That is great! I'll give it a try today and report back! - Original Message - Subject: Re: [USRP-users] Messaging the DDC From: "Marcus Mller via USRP-users" Date: 9/30/18 4:47 pm To: usrp-users@lists.ettus.com Hi Jason, I was about to write code, but then realized: gr-ettus' Block impl already has what you need, the message port "rfnoc", which'll accept messages in the PMT dict format. You can extract the shape of information you need to send in from the tags in uhd_rfnoc_ddc.xml. I'm attaching what I hope will fix your problem as a patch (use with `git apply` from within gr-ettus). We'll most likely upstream a more general changeset. Best regards, Marcus On Wed, 2018-09-26 at 19:45 -0400, Jason Matusiak via USRP-users wrote: > I have a block that outputs a message with a frequency. I would love > to be able to set the frequency adjustment in the RFNoC DDC, but I > don't see a way to do it it automagically. > > I am guessing that there is no way to do it even though it can be set > from a variable slider easily. Is there an option I am missing? > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] getting GPS time from RFNoC bitfile on E310
Thank you Marcus.
At the end of the day I ended up doing something similar yesterday. I kick off
the gps2udp app on boot, and then in my python block I do a udp receive and
pull in a GPRMC sentence. So pretty much what you are recommending.
Also, thanks EJ for your idea as well, might look into that for the future.
~Jason
- Original Message - Subject: Re: [USRP-users] getting GPS time
from RFNoC bitfile on E310
From: "Marcus Mller"
Date: 10/23/18 3:44 am
To: "EJ Kreinar" , "Jason Matusiak"
Cc: "USRP-users@lists.ettus.com"
Correct me, but wouldn't the rfnoc'ed E310 still be feeding its GPS
data into the gpsd running on the linux so that getting GPS location
from python would amount to using gpsd?
Best regards,
Marcus
On Mon, 2018-10-22 at 20:40 -0400, EJ Kreinar via USRP-users wrote:
> Hi Jason,
>
> I don't have that change available now, but you can pretty easily
> make a mod to add the get_mboard_sensor functionally into an rfnoc
> block.
>
> I'd recommend starting with gr-ettus... take a look through the
> updates to radio_block_impl.cc and .h to see how to add new
> functionality (Darek Kozel has a particularly relevant commit about a
> year ago):
> https://github.com/EttusResearch/gr-ettus/commits/master/lib/rfnoc_radio_impl.cc
>
> You'll also need to update some software in uhd to make things happy.
> Hope this helps! I agree it's one of those things that might be nice
> to have in the main tree.
>
> EJ
>
> On Mon, Oct 22, 2018, 11:08 AM Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> > I was trying to get GPS from a python OOT module block, but it
> > doesn't look like it is possible when running RFNoC mode.
> >
> > I have top_block passed in, and I tried the command:
> >
> > print
> > self.top_block.uhd_rfnoc_streamer_radio_0.get_mboard_sensor('gps_po
> > sition')
> >
> > But I get the error:
> > print
> > self.top_block.uhd_rfnoc_streamer_radio_0.get_mboard_sensor('gps_po
> > sition')
> > AttributeError: 'rfnoc_radio_sptr' object has no attribute
> > 'get_mboard_sensor'
> > thread[thread-per-block[0]: ]: SWIG
> > director method error. Error detected when calling 'feval_ll.eval'
> >
> > Any idea how to do this? I tried poking through the mailing list
> > as well as the USRP manual, but I don't see any way to do it when
> > you are an RFNoC radio.
> >
> > ~Jason
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Need Help setting up X310 for two channels
Hi I am trying to receive data from X310 ( 2 channels), in my case I am giving RF input to RF-B port (channel-0 and Channel-1), i am able to see the FFT to one channel only whether i give input to channel-0 or channel-1. so what i feel that i am not able to set the stream arguments properly. attaching a image file for that. Arun Verma 1234 Description: Binary data ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Frequency offset estimation between two USRPs (B210)
Hi Inkyu, wow, that is *awesome* frequency accuracy! You see a frequency offset range of 17 Hz in your example. Relative to 2.4 GHz (which I assume you're using as carrier frequency), that's 17 / 2.4e9, so approximately 7 ppb. Two unlinked oscillators that are not atomic clocks running this close together is so unlikely, you should be starting to play the lottery! So, my guess is that your IEEE802.11 receiver already does frequency correction, and you're observing residual frequency error after frequency correction, or that your two USRPs are sharing a 10 MHz reference. Is that possible? Also, how do you estimate single-digit Hertz accuracy with the amount of info in a WiFi preamble? Can you tell us how your estimator works? Best regards, Marcus On Mon, 2018-10-22 at 09:56 +0800, Inkyu Bang via USRP-users wrote: > Hi, all. > > (I recently shared this issue in USRP forum but it seems not properly > shared so I sent it again) > > I am testing frequency offset estimation by using the preamble of Wi- > Fi packet (IEEE 802.11). > > My setting is as follows: two USRPs are connected to one laptop (i7 > quad-core, SSD, 8GB ram). > > One is used for Tx. and the other for Rx. I chose 1MHz bandwidth and > set proper packet length and inter-packet time (50ms) so packets are > almost continuously transmitted. > > During the test (very stationary environment), 1.5 m distance between > Tx. and Rx. and good SNR is guaranteed (by checking constellation). > > At the receiver side, I estimated frequency offset value of every > packet using the preamble of each packet. > > I compared these values. Of course, I know that the frequency offset > between two USRP varies due to several reasons (e.g., temperature). > > Anyway, we can see similar frequency offset values during a given > period (e.g., 5 sec) and this is what I exactly expected. For > example, 2001 Hz (packet 1), 2003 Hz (packet 2), 1997 Hz (packet 3) > and so on. > > The problem is that, sometimes, I see unusually a high frequency > offset value for some packets. Then, frequency offset values return > back to the reasonable value again. For example, 2001 Hz (packet 1), > 2003 Hz (packet 2), 2307 Hz (packet 3), 2310 Hz (packet 4), 1997 Hz > (packet 5) and so on. > > Can anyone help me to understand this phenomenon? > > Thank you in advance. > > - Inkyu > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] getting GPS time from RFNoC bitfile on E310
Correct me, but wouldn't the rfnoc'ed E310 still be feeding its GPS
data into the gpsd running on the linux so that getting GPS location
from python would amount to using gpsd?
Best regards,
Marcus
On Mon, 2018-10-22 at 20:40 -0400, EJ Kreinar via USRP-users wrote:
> Hi Jason,
>
> I don't have that change available now, but you can pretty easily
> make a mod to add the get_mboard_sensor functionally into an rfnoc
> block.
>
> I'd recommend starting with gr-ettus... take a look through the
> updates to radio_block_impl.cc and .h to see how to add new
> functionality (Darek Kozel has a particularly relevant commit about a
> year ago):
> https://github.com/EttusResearch/gr-ettus/commits/master/lib/rfnoc_radio_impl.cc
>
> You'll also need to update some software in uhd to make things happy.
> Hope this helps! I agree it's one of those things that might be nice
> to have in the main tree.
>
> EJ
>
> On Mon, Oct 22, 2018, 11:08 AM Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> > I was trying to get GPS from a python OOT module block, but it
> > doesn't look like it is possible when running RFNoC mode.
> >
> > I have top_block passed in, and I tried the command:
> >
> > print
> > self.top_block.uhd_rfnoc_streamer_radio_0.get_mboard_sensor('gps_po
> > sition')
> >
> > But I get the error:
> > print
> > self.top_block.uhd_rfnoc_streamer_radio_0.get_mboard_sensor('gps_po
> > sition')
> > AttributeError: 'rfnoc_radio_sptr' object has no attribute
> > 'get_mboard_sensor'
> > thread[thread-per-block[0]: ]: SWIG
> > director method error. Error detected when calling 'feval_ll.eval'
> >
> > Any idea how to do this? I tried poking through the mailing list
> > as well as the USRP manual, but I don't see any way to do it when
> > you are an RFNoC radio.
> >
> > ~Jason
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
