Re: [USRP-users] getting GPS time from RFNoC bitfile on E310
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_position')
>
> But I get the error:
>
> print
> self.top_block.uhd_rfnoc_streamer_radio_0.get_mboard_sensor('gps_position')
> 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
Re: [USRP-users] E310 AGC activation
On 10/22/2018 06:41 PM, Steve Clift via USRP-users wrote: Newbie here with an E310. Is there any way to get to the AD9361 driver AGC enable/control methods (e.g. set_agc() and set_agc_mode()) from Python? -Steve --- CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com /uhd::usrp::multi_usrp::set_rx_agc(bool enable, size chan); / ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] E310 AGC activation
Newbie here with an E310. Is there any way to get to the AD9361 driver AGC enable/control methods (e.g. set_agc() and set_agc_mode()) from Python? -Steve --- CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] USRP 200 Square with Carrier Frequency Behaviour?
GB, What you are seeing I think is the Square wave generated in quadrature as a complex signal….imagine 2 square waves with pi/4 phase offset. Also I think you will find the square wave is [0,1] not [-1,1]. So when your modulated square waves are summed…you get what you see. Build it for your self in GRC as a simple flow graph using: a Signal Source and Null source both set to float output, and Float To Complex block to combine them and drive a UHD Sink. Like this you will see a OOK waveform if the signal source is configured as Amplitude:1, Offset:0. If you then re-configure as Amplitude:2 Offset: -1 you will see the PSK style signal you desire. If you drive the Signal Source as a complex signal straight to the UHD sink then you will see the same waveform you currently see. -Ian > On Oct 20, 2018, at 10:18 PM, G Broten via USRP-users > wrote: > > Ettus Users: > Hopefully someone can explain the behavoir I'm seeing when modulating a > square wave with a carrier frequency. I'm using the supplied Ettus example > software, tx_waveforms, that generates a waveform for the LFTX daughter board. > With the following command: > ./tx_waveforms --rate 1e6 --wave-type SQUARE --freq 0 --wave-freq 1e3 --ampl > 0.2 > I see a beautiful square wave of exactly 1 KHz, with an amplitude of -0.1 for > 500us and 0.1V for 550 us on my scope. > But when I add a carrier frequency to modulate the square wave as follows: > ./tx_waveforms --rate 1e6 --wave-type SQUARE --freq 50e3 --wave-freq 1e3 > --args --ampl 0.2 > I see unexpected behavoir. What I expect is a square wave where 500 us is > modulated with the 50 KHz carrier and then a phase shift due to the voltage > sign change, as the 50 KHz carrier continues. > What I get is odd: +/-0.2 V for 250 us, followed by 250 us of +/-0.3V, then > +/-0.2V for another 250 us and finally 0V for 250 us before the wave repeats > at 1 KHz. > > Can anyone enlighten me as to why I see this behavoir and not the expected > wave form? > I simulate this wave form, using what should be the same math under Octave, > and I get what I expect, so I'm confused. > > Thanks in advance, > > GB > ___ > 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] RFNoC block fpga control source issues
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
> > > > > >
> > > > > > ___
> > > > > > 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] getting GPS time from RFNoC bitfile on E310
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_position')
But I get the error:
print
self.top_block.uhd_rfnoc_streamer_radio_0.get_mboard_sensor('gps_position')
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
