Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Building FPGA image for an Schmidl-Cox Synchronization block
(OFDM Receiver) (Torres Figueroa, Luis Angel)
2. Phase alignment for multiple USRP (Jack Yang)
3. Cross-compiling and running custom software from windows and
linux (Cho, Daniel J (332C))
4. Re: Cross-compiling and running custom software from windows
and linux (Philip Balister)
5. Re: Cross-compiling and running custom software from windows
and linux (Nate Temple)
6. Re: Phase alignment for multiple USRP (Michael West)
7. X300 timing (Jacob Knoles)
8. Re: E310 Rfnoc clocking guidelines/ performance issues
(Samuel Prager)
----------------------------------------------------------------------
Message: 1
Date: Fri, 16 Jun 2017 17:02:44 +0000
From: "Torres Figueroa, Luis Angel"
<[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Building FPGA image for an Schmidl-Cox
Synchronization block (OFDM Receiver)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi all,
I am trying to synthesize a Schmidl-Cox block using the UHD image builder, so I
can use it in a NI USRP-2953R device (Xilinx part: xc7k410tffg900-2) along with
GNU Radio Companion. For this purpose, I am using the latest commit of the
rfnoc-devel branch (commit 74d1448e375d4b9e30d762976d20d2378112576f, April 11th
2017), and I have added some of the missing verilog files listed in the
schmidl_cox.v module that are available from the rfnoc-ofdm branch (commit
6467d4b48a8ac76bff7bf5380c00b039182e5ef7, April 11th 2016). I have made a
comparison of the latest commits on both branches and added the latest versions
to my RTL design, and I have additionally made a couple of modifications in the
arguments of some modules (so updated version of the modules in the rfnoc-ofdm
branch are compatible with older ones in the rfnoc-devel branch). The list of
changes that I have done can be found below:
1. Schmidl_cox.v (rfnoc-ofdm branch)
* Replaced by ofdm version (devel v2014, ofdm v2015)
* Lines 42, 51, 114 modified: parameter FIFOSIZE is now called FIFO_SIZE
* Lines 79, 86, 138, 162: parameter MAX_LEN_LOG2 and argument 8 changed
to MAX_LEN and 255, respectively, so they are compatible with devel version.
* Lines 188, 189: divide_int32.v is the same in all branches. The bus
m_axis_dout_tuser listed in schmidl_cox.v is disabled since it was not
implemented in the module.
2. split_stream_fifo.v (rfnoc-devel branch)
* The verilog file in the rfnoc-devel branch is the most recent, the
only difference is the size of the FIFO (5 in devel, 6 in ofdm) [However this
is an input parameter, which is set upon calling the module].
3. ofdm_plateau_detector.v (rfnoc-ofdm branch)
* Non-existent in devel, rfnoc-ofdm version copied.
* line 94, modified: divide_int16 changed to divide_int16_int32
* line 68, 107,211 modified: MAX_LENGTH instead of MAX_LENGTH_LOG2 and
argument modified be consistent (substracted by one to obtain the correct log2).
* Line 185: FIFOSIZE changed by FIFO_SIZE as defined in updated module.
4. multiply.v (ofdm)
* Non-existent, rfnoc-ofdm version copied
5. moving_sum.v (rfnoc-devel branch)
* rfnoc-devel version used, since it is the most recent one
6. complex_to_mag_approx.v (rfnoc-ofdm branch)
* lines 78, 98, 118: rfnoc-ofdm version has more relevant changes,
though an update of the axi_fifo_flop to axi_fifo_flop2 is needed, since the
rfnoc-devel version included that one later.
7. periodic_framer.v (rfnoc-ofdm branch)
* copied from rfnoc-ofdm branch, this was the latest version.
I have also taken into consideration the recommendations given in the previous
post:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-March/019341.html
However, I cannot build the FPGA image. When using the UHD image builder
command, I am getting the following errors. I am using
UHD_4.0.0.rfnoc-devel-348-g2c2e1a99.
$ python2 uhd_image_builder.py schmidl_cox -I ../../lib/rfnoc -d x310 -t
X310_RFNOC_HG -m3 --fill-with-fifos
ERROR: [Synth 8-448] named port connection 's_axis_phase_tlast' does not exist
for instance 'cordic_freq_offset_correction' of module 'cordic_rotator'
[/home/ltorresf/uhd/fpga-src/usrp3/lib/rfnoc/schmidl_cox.v:235]
ERROR: [Synth 8-285] failed synthesizing module 'setting_reg__parameterized26'
[/home/ltorresf/uhd/fpga-src/usrp3/lib/control/setting_reg.v:12]
ERROR: [Synth 8-285] failed synthesizing module 'periodic_framer'
[/home/ltorresf/uhd/fpga-src/usrp3/lib/rfnoc/periodic_framer.v:5]
ERROR: [Synth 8-285] failed synthesizing module 'schmidl_cox'
[/home/ltorresf/uhd/fpga-src/usrp3/lib/rfnoc/schmidl_cox.v:5]
ERROR: [Synth 8-285] failed synthesizing module 'noc_block_schmidl_cox'
[/home/ltorresf/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_schmidl_cox.v:5]
ERROR: [Synth 8-285] failed synthesizing module 'x300_core'
[/home/ltorresf/uhd/fpga-src/usrp3/top/x300/x300_core.v:2]
ERROR: [Synth 8-285] failed synthesizing module 'x300'
[/home/ltorresf/uhd/fpga-src/usrp3/top/x300/x300.v:15]
ERROR: [Common 17-69] Command failed: Synthesis failed - please see the console
or run log file for details
The list of previous changes were done using Vivado v2015.4, where I was
actually able to synthesize the schmidl_cox.v module and obtain the schematics,
but when running the implementation I run into the following errors:
[DRC 23-20] Rule violation (INBB-3) Black Box Instances - Cell 'cmult1/cmult1'
of type 'cmult1/cmult1/complex_multiplier' has undefined contents and is
considered a black box. The contents of this cell must be defined for
opt_design to complete successfully.
[DRC 23-20] Rule violation (INBB-3) Black Box Instances - Cell
'complex_to_magphase_int32' of type
'complex_to_magphase_int32/complex_to_magphase' has undefined contents and is
considered a black box. The contents of this cell must be defined for
opt_design to complete successfully.
[DRC 23-20] Rule violation (INBB-3) Black Box Instances - Cell
'cordic_freq_offset_correction' of type
'cordic_freq_offset_correction/cordic_rotator' has undefined contents and is
considered a black box. The contents of this cell must be defined for
opt_design to complete successfully.
[DRC 23-20] Rule violation (INBB-3) Black Box Instances - Cell
'corr_sqr_div_energy_sqr' of type 'corr_sqr_div_energy_sqr/divide_int32' has
undefined contents and is considered a black box. The contents of this cell
must be defined for opt_design to complete successfully.
[DRC 23-20] Rule violation (INBB-3) Black Box Instances - Cell
'ofdm_plateau_detector/divide_gain' of type
'ofdm_plateau_detector/divide_gain/divide_int16_int32' has undefined contents
and is considered a black box. The contents of this cell must be defined for
opt_design to complete successfully.
[Vivado_Tcl 4-78] Error(s) found during DRC. Opt_design not run.
I am now looking into the details of the specific blocks (UHD image building
errors, highlighted), however since this block worked in the past, could you
provide me with some information why they are not working anymore? Or let me
know whether the approach I am taking is the correct one?
Here you can find some printscreens: https://goo.gl/HZqAS8. Any insight on how
to make it work will be appreciated.
Best,
Luis A. Torres
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170616/bfc66dfc/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 16 Jun 2017 13:06:07 -0400
From: Jack Yang <[email protected]>
To: [email protected], Jack Yang via USRP-users
<[email protected]>
Subject: [USRP-users] Phase alignment for multiple USRP
Message-ID:
<CAD-njKY85COtGJsim6uC_+WuK1dTe9UA9hc0B4aRe2Jo=4+...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am trying to build a coherent phase array receiver. I am using two X310
with four UBX-160 and a ocotoclock (10MHz and 1PPS) to have 4 Rx coherent
receiver. However, every time when the machine is on, the phase offset
between each receiver is aways random. I used the python to write my system
and I have the following setups. Could anyone give some hint or suggestion
how to make coherent phase arrayed receiver work without non-consistent
phase offset every time?
Many thanks for your time!
All Best,
Jack
"""
self.uhd_usrp_source_0.set_clock_source('external', 0)
self.uhd_usrp_source_0.set_time_source('external', 0)
self.uhd_usrp_source_0.set_subdev_spec('A:0 B:0', 0)
self.uhd_usrp_source_0.set_clock_source('external', 1)
self.uhd_usrp_source_0.set_time_source('external', 1)
self.uhd_usrp_source_0.set_subdev_spec('A:0 B:0', 1)
self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
cmd_time = uhd.time_spec_t(0.1)
timenow = self.uhd_usrp_source_0.get_time_now()
self.uhd_usrp_source_0.set_command_time(timenow + cmd_time)
self.uhd_usrp_source_0.set_center_freq(freq, 0)
self.uhd_usrp_source_0.set_gain(gain, 0)
self.uhd_usrp_source_0.set_antenna('TX/RX', 0)
self.uhd_usrp_source_0.set_center_freq(freq, 1)
self.uhd_usrp_source_0.set_gain(gain, 1)
self.uhd_usrp_source_0.set_antenna('TX/RX', 1)
self.uhd_usrp_source_0.set_center_freq(freq, 2)
self.uhd_usrp_source_0.set_gain(gain, 2)
self.uhd_usrp_source_0.set_antenna('TX/RX', 2)
self.uhd_usrp_source_0.set_center_freq(freq, 3)
self.uhd_usrp_source_0.set_gain(gain, 3)
self.uhd_usrp_source_0.set_antenna('TX/RX', 3)
self.uhd_usrp_source_0.clear_command_time()
"""
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170616/ba647fd3/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 16 Jun 2017 17:19:29 +0000
From: "Cho, Daniel J (332C)" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Cross-compiling and running custom software from
windows and linux
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello,
I am using a windows 10 PC and I would like to compile and run my own custom
code on a USRP E310/E312. I am having issues with finding a guide to compile
the software code then mount it (through sshfs from linux -> PC).
Is there an easy way to do this cross compiling using a windows 10 PC?
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170616/04bd589f/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 16 Jun 2017 13:32:44 -0400
From: Philip Balister <[email protected]>
To: "Cho, Daniel J (332C)" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Cross-compiling and running custom software
from windows and linux
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 06/16/2017 01:19 PM, Cho, Daniel J (332C) via USRP-users wrote:
> Hello,
>
> I am using a windows 10 PC and I would like to compile and run my own custom
> code on a USRP E310/E312. I am having issues with finding a guide to compile
> the software code then mount it (through sshfs from linux -> PC).
> Is there an easy way to do this cross compiling using a windows 10 PC?
Sorry, the only available sdk is for Linux.
Philip
>
> Thanks
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 5
Date: Fri, 16 Jun 2017 10:35:58 -0700
From: Nate Temple <[email protected]>
To: Philip Balister <[email protected]>
Cc: "Cho, Daniel J (332C)" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Cross-compiling and running custom software
from windows and linux
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Daniel,
The easiest way would be to setup VirtualBox and run a Ubuntu virtual machine
to cross compile. I can send you additional information off list on the
process. We will be posting a new Application Note on the subject in the near
future.
Regards,
Nate Temple
> On Jun 16, 2017, at 10:32 AM, Philip Balister via USRP-users
> <[email protected]> wrote:
>
> On 06/16/2017 01:19 PM, Cho, Daniel J (332C) via USRP-users wrote:
>> Hello,
>>
>> I am using a windows 10 PC and I would like to compile and run my own custom
>> code on a USRP E310/E312. I am having issues with finding a guide to
>> compile the software code then mount it (through sshfs from linux -> PC).
>> Is there an easy way to do this cross compiling using a windows 10 PC?
>
> Sorry, the only available sdk is for Linux.
>
> Philip
>
>>
>> Thanks
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 6
Date: Fri, 16 Jun 2017 15:39:19 -0700
From: Michael West <[email protected]>
To: Jack Yang <[email protected]>
Cc: [email protected], Jack Yang via USRP-users
<[email protected]>
Subject: Re: [USRP-users] Phase alignment for multiple USRP
Message-ID:
<CAM4xKrp9ddPf=8+nt0uedwdhp9fnhgvss3rkujfnkyqyh2h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jack,
The set/clear_command_time() functions have a parameter for the mboard that
defaults to 0 in gr-uhd. Try adding calls for the other mboard. Also, if
using frequencies between 500 MHz and 950 MHz on the UBX, you need to add
"dboard_clock_rate=20e6" to the device arguments.
Regards,
Michael
On Fri, Jun 16, 2017 at 10:06 AM, Jack Yang via USRP-users <
[email protected]> wrote:
> I am trying to build a coherent phase array receiver. I am using two X310
> with four UBX-160 and a ocotoclock (10MHz and 1PPS) to have 4 Rx coherent
> receiver. However, every time when the machine is on, the phase offset
> between each receiver is aways random. I used the python to write my system
> and I have the following setups. Could anyone give some hint or suggestion
> how to make coherent phase arrayed receiver work without non-consistent
> phase offset every time?
>
>
> Many thanks for your time!
>
> All Best,
> Jack
>
> """
> self.uhd_usrp_source_0.set_clock_source('external', 0)
> self.uhd_usrp_source_0.set_time_source('external', 0)
> self.uhd_usrp_source_0.set_subdev_spec('A:0 B:0', 0)
> self.uhd_usrp_source_0.set_clock_source('external', 1)
> self.uhd_usrp_source_0.set_time_source('external', 1)
> self.uhd_usrp_source_0.set_subdev_spec('A:0 B:0', 1)
> self.uhd_usrp_source_0.set_samp_rate(samp_rate)
> self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
>
> cmd_time = uhd.time_spec_t(0.1)
> timenow = self.uhd_usrp_source_0.get_time_now()
> self.uhd_usrp_source_0.set_command_time(timenow + cmd_time)
> self.uhd_usrp_source_0.set_center_freq(freq, 0)
> self.uhd_usrp_source_0.set_gain(gain, 0)
> self.uhd_usrp_source_0.set_antenna('TX/RX', 0)
> self.uhd_usrp_source_0.set_center_freq(freq, 1)
> self.uhd_usrp_source_0.set_gain(gain, 1)
> self.uhd_usrp_source_0.set_antenna('TX/RX', 1)
> self.uhd_usrp_source_0.set_center_freq(freq, 2)
> self.uhd_usrp_source_0.set_gain(gain, 2)
> self.uhd_usrp_source_0.set_antenna('TX/RX', 2)
> self.uhd_usrp_source_0.set_center_freq(freq, 3)
> self.uhd_usrp_source_0.set_gain(gain, 3)
> self.uhd_usrp_source_0.set_antenna('TX/RX', 3)
> self.uhd_usrp_source_0.clear_command_time()
>
> """
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170616/94f39514/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 16 Jun 2017 15:08:11 -0700
From: Jacob Knoles <[email protected]>
To: [email protected]
Subject: [USRP-users] X300 timing
Message-ID:
<CA+z4yFHmNyT2C7xpBtSYEMWNuj=y3be7dkegzdbryscmadc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I am developing a frequency hopper that must transmit a specified number of
pulses on each frequency, then change frequencies within a short and
specific window of time.
I am currently achieving this using the timed commands of the X300, I load
the buffer with frequency tune requests all increasingly offset from a
reference start point.
For example (pseudo-code):
set usrp time = 0
reference time = get usrp time
change frequency at reference time + (hop time * 1)
change frequency at reference time + (hop time * 2)
change frequency at reference time + (hop time * 3)
.... and so on.
Meanwhile in a helper thread I have the tx_streamer that replays the pulse
sequence the specified number of times.
So far this is working out very well, but I have noticed that with more
hops, the timing becomes less accurate, there is more time between each
frequency change.
And since my ultimate goal is 100 frequency hops this is an issue.
My initial thought is that this could be remedied by utilizing the GPSDO
option, thus giving the X300 a much better clock source. Could someone
please confirm this for me as I do not have the GPSDO option.
Or if anyone has any better ideas I am open to suggestions.
Note: I am using the UHD C++ API directly (not using GNU-Radio).
Thanks!
-- Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170616/c5e9fb3e/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 16 Jun 2017 21:04:25 -0700
From: Samuel Prager <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Ryan Marlow via USRP-users <[email protected]>, Samuel
Prager <[email protected]>
Subject: Re: [USRP-users] E310 Rfnoc clocking guidelines/ performance
issues
Message-ID: <8d94ce1e-4022-425c-8c8a-79fb2cd99df4@Spark>
Content-Type: text/plain; charset="utf-8"
Hello,
I was able to sort out this issue and figured I would reply with the fix just
in case it is helpful to anyone else ? I think that getting the
noc_block_siggen to work on the E310 might require the same workaround.
It looks like in order to have the radio tx samples that originate on the fpga
for E3xx devices w/ rfnoc, you have to create
a?uhd::tx_streamer::sptr?tx_stream = usrp->get_tx_stream(stream_args)
with?streamer_args["block_id"] = <signal_generator_blockid> so that the tx
graph begins with a tx streamer.
Maybe someone from Ettus can provide further clarification, but from what I can
tell, uhd
a) enables the tx frontend the E310?s radio by counting active tx streamers and
b) performs some vital flow control setup when the tx streamer is created,
without which the fpga will eventually lock up.
Sam
On Jun 8, 2017, 11:48 PM -0700, Samuel Prager <[email protected]>, wrote:
> Hi Jonathon,
>
> Thanks for the response.
>
> > Issue 1)
> > When you receive a pulse, are you only calling recv() or are you doing
> > anything else? This looks like UHD expected the response packet to have a
> > sequence number of 0, but the radio replied with a sequence number of 890.
> > This could happen if the radio block got reset. You said this code works
> > fine when running on the X300 though right?
>
> Yes, I am only calling recv() when receiving a pulse. The only time I call
> usrp->clear() is when the blocks are initially connected. Yes, this code
> works on the X300.
>
> Additionally, if I do not attempt any settings reg reads, but instead
> immediately call recv() a second time, I receive a few hundred samples before
> getting a timeout due to drops.
>
> I have had a chance to run a few more test cases with the following results:
>
> case 1)
> If I upload a length zero waveform to my AWG noc block (won?t transmit
> anything) and call recv(), everything works fine and the (timed) samples are
> received as expected for multiple pulses.
>
> case 2)
> If I send/receive immediately, I am able to receive approximately 8 pulses
> with ~4096 samples before the E312 freezes up or begins to report the errors
> described previously. It does not seems to matter how long I wait between
> pulses or what rate I set.
>
> So if I utilize the timekeeper, I always crash after the first pulse, but if
> I ignore the timekeeper, I get a few more pulses, but crash eventually?
>
> I am not sure what could possibly be causing this behavior so any guidance is
> greatly appreciated.
>
> A few other things:
> I have been doing some additional tests using uhd::device3 tx_streamer?s and
> rx_streamer?s and have noticed that depending on the buffer size of the
> tx_streamer, I will get an ERROR_CODE_LATE_COMMAND when simulateously sending
> and receiving.
>
> Additionally, I have been getting the following error when any program built
> against the latest commit to the rfnoc-devel branch of uhd exits (even if
> successful). Not sure whether this is of any consequence:
>
> > [ERROR] [UHD] Exception caught in safe-call.
> > ? in virtual ctrl_iface_impl::~ctrl_iface_impl()
> > ? at
> > /home/prager/Projects/e312cross/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
> > this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
> > ? in typename T::sptr e300_transport::get_buff(double) [with T =
> > uhd::transport::managed_send_buffer; typename T::sptr =
> > boost::intrusive_ptr<uhd::transport::managed_send_buffer>]
> > ? at
> > /home/prager/Projects/e312cross/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:250
>
> For reference: UHD_4.0.0.rfnoc-devel-902-gbf23c7ad
>
> Regards,
>
> Sam
>
> On May 18, 2017, 10:28 AM -0700, Jonathon Pendlum
> <[email protected]>, wrote:
> > > Hi Sam,
> > >
> > > > Issue 1)
> > > >
> > > > When I run the application, rfnoc appears to initialize correctly and I
> > > > can sr_read sr_write. However, after receiving one pulse (4096
> > > > samples), I begin to see errors similar to:
> > > >
> > > > Error: EnvironmentError: IOError: 0/Radio_0 user_reg_read64() failed:
> > > > EnvironmentError: IOError: [0/Radio_0] sr_read64() failed:
> > > > EnvironmentError: IOError: Block ctrl (CE_00_Port_10) packet parse
> > > > error - EnvironmentError: IOError: Expected packet index: 0? Received
> > > > index: 890
> > > >
> > > > If I do not read/write any FPGA registers before sending another pulse,
> > > > I see timeouts after a few thousand samples have been received.
> > > >
> > > > I have tried changing the rate (as low as 1 MHz) and increasing the
> > > > wait time between pulses ? neither has any effect. After the first
> > > > pulse, the usrp starts to freeze up. I have also tried adding a FIFO
> > > > block between the Radio RX and host with no improvement.
> > >
> > > When you receive a pulse, are you only calling recv() or are you doing
> > > anything else? This looks like UHD expected the response packet to have a
> > > sequence number of 0, but the radio replied with a sequence number of
> > > 890. This could happen if the radio block got reset. You said this code
> > > works fine when running on the X300 though right?
> > >
> > > > Issue 2)
> > > >
> > > > The data I am receiving in the analog loopback configuration is
> > > > essentially junk. However, if I set the ?loopback? register in the
> > > > radio_core (SR_LOOPBACK = 132), ?I receive the exact samples that are
> > > > being send by the AWG with the correct time coherence, etc. So the tx
> > > > samples going out of the radio_core appear to be correct.
> > >
> > > Can you do an external loopback with something simple like a tone? The
> > > AD9361 is a fairly complicated device and starting off with a simpler
> > > test case might give us a better clue.
> > >
> > > > Questions:
> > > >
> > > > Are there additional uhd calls needed to setup the E310 RF frontend
> > > > beyond what is necessary for the X300?
> > >
> > > Not that I'm aware of.
> > >
> > > > I am sort of scratching my head here because I have been using
> > > > noc_block on the X300 successfully for a while and the E310 fpga image
> > > > I built met timing, etc.
> > > >
> > > > Are there any obvious culprits for this sort of behavior? My noc_block
> > > > uses a timekeeper (and the sync_in and pps signals on the X300). On the
> > > > E310, however there is no sync_in signal and the pps generation is
> > > > different.? Could this be the source of the issues that I am seeing?
> > >
> > > I wouldn't completely rule it out, but I doubt it. Have you tried sending
> > > the pulse immediately / ignoring the timekeeper?
> > >
> > > > What is the proper way to set the gpsdo as the time and clock source
> > > > for a device3 based usrp? Is there anything analogous to what is used
> > > > for multi_usrp in the sync_to_gps.cpp example?
> > >
> > > I believe we expose what you need in the radio block controller
> > > (radio_ctrl_impl.cpp). Take a look
> > > at?https://github.com/EttusResearch/uhd/blob/rfnoc-devel/host/examples/rfnoc_rx_to_file.cpp
> > >
> > > > And lastly, is it possible to use a dma_fifo block directly on the
> > > > E310? Or does custom firmware have to be written in order to use the
> > > > dram memory on board?
> > >
> > > The DmaFIFO block would be compatible, but you need to generate a MIG
> > > with an AXI4 interface. Luckily, we already have IP for the MIG that is
> > > built when you run the 'E310_dram_test' make target. You could try
> > > starting with that.
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170616/ee464aa8/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 82, Issue 17
******************************************
