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. RFNOC: Testbench stalling when simulating block with multiple
ports, bug in sim_rfnoc_lib.svh? (Templin, Josh)
2. Re: Overflow (Yang Liu)
3. Re: Overflow (Yang Liu)
4. Re: B205i transient behavior (Michael West)
5. Re: RFNOC: Testbench stalling when simulating block with
multiple ports, bug in sim_rfnoc_lib.svh? (Jonathon Pendlum)
6. Re: RFNOC: Testbench stalling when simulating block with
multiple ports, bug in sim_rfnoc_lib.svh? (Templin, Josh)
7. Modifying AD9361 Driver (Jessica Iwamoto)
8. Re: RFNOC: Testbench stalling when simulating block with
multiple ports, bug in sim_rfnoc_lib.svh? (Templin, Josh)
9. E310 Audio Jack (???)
10. Re: E310 Audio Jack (Robin Coxe)
11. install gr-doa via pybombs - how? (Haile Berhe)
12. Install NFS server on E310 (Crozzoli Maurizio)
13. Re: RuntimeError: basic_string::_M_construct null not valid
when using RFNoC:Radio (Sebastian Mueller)
14. Re: Install NFS server on E310 (Derek Kozel)
15. Re: install gr-doa via pybombs - how? (Nicolas Cuervo)
16. R: Install NFS server on E310 (Crozzoli Maurizio)
17. Re: Install NFS server on E310 (Philip Balister)
18. R: Install NFS server on E310 (Crozzoli Maurizio)
19. Re: R: Install NFS server on E310 (Philip Balister)
20. Re: B205i transient behavior (Dominik Eyerly)
21. usrp b210 problem (=?UTF-8?B?7ISg6rK966+4?=)
22. B210 and Simulink sample times (Mihkel M)
----------------------------------------------------------------------
Message: 1
Date: Tue, 25 Apr 2017 16:11:07 +0000
From: "Templin, Josh" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RFNOC: Testbench stalling when simulating block
with multiple ports, bug in sim_rfnoc_lib.svh?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi all,
I am developing a multi-port RFNOC block with UHD 3.10.1.1 and simulating using
XSim in Vivado 2015.4 on Ubuntu 16.04 targeting an X300. When I simulate, the
simulation stalls whenever I connect the second port on my module as the
destination, as in the testbench line:
`RFNOC_CONNECT_BLOCK_PORT(noc_block_tb,0,noc_block_test,1,SC16,SPP);
Looking at the xbar transactions in the simulation, the last transaction is a
command transaction from the tb_config crossbar port (port 0.3.0 in my
testbench) to the noc_block_test crossbar port (port 0.1.1 in my testbench).
The command packet is:
8093001000300011
0000007d00c1ea12
Which looks fine and seems to correspond to the second write_reg command in the
RFNOC_CONNECT_BLOCK_PORT macro found in sim_rfnoc_lib.svh:
// Setup RFNoC block flow control per block port
//
// Usage: `RFNOC_CONNECT_BLOCK_PORT()
// - from_noc_block_name: Name of producer (or upstream) RFNoC block
// - from_block_port: Block port of producer RFNoC block
// - to_noc_block_name: Name of consumer (or downstream) RFNoC block
// - to_block_port: Block port of consumer RFNoC block
// - data_type: Data type for data stream (i.e. SC16, FC32, etc)
// - spp: Samples per packet
//
`define
RFNOC_CONNECT_BLOCK_PORT(from_noc_block_name,from_block_port,to_noc_block_name,to_block_port,data_type,spp)
\
$display("Connecting %s (SID: %0d:%0d) to %s (SID: %0d:%0d)", \
`"from_noc_block_name`",sid_``from_noc_block_name >>
4,from_block_port, \
`"to_noc_block_name`",sid_``to_noc_block_name >> 4,to_block_port); \
// Clear block, write be any value \
tb_config.write_reg(sid_``from_noc_block_name, SR_CLEAR_TX_FC, 32'hC1EA12,
from_block_port); \
>> tb_config.write_reg(sid_``from_noc_block_name, SR_CLEAR_RX_FC, 32'hC1EA12,
>> to_block_port); \
The pairing of "from_noc_block_name" with "to_block_port" seems to be causing
the problem, since the source block has only 1 port but I am connecting to the
destination block's 2nd port. It seems like this should be
sid_``to_noc_block_name? Is this a bug or am I misunderstanding how to connect
and use multi-port blocks?
I encountered this problem earlier when connecting to my testbench and was able
to workaround it by declaring my testbench to have 2 ports and ignoring the
second port. Now, I am connecting to another rfnoc block from the library and
I cannot trivially change its number of ports, so my workaround fails.
Thanks,
Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170425/006da061/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 25 Apr 2017 13:08:53 -0400
From: Yang Liu <[email protected]>
To: Nicolas Cuervo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Overflow
Message-ID:
<cad4vfmh1jp6yqhpyvxxmnxfxqib-hbs2kcxaml_ho7rwynw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Nicolas,
Thanks a lot for your help.
We need to keep this high sample rate . After running a process viewer, we
found that fir_filter_fff and fir_filter_ccf in
gr::digital::ofdm_sync_sc_cfb should be the bottleneck (we use this block
to achieve synchronization in our 1024 OFDM design).
Best,
Yang
On Tue, Apr 25, 2017 at 8:47 AM, Nicolas Cuervo <[email protected]>
wrote:
> Hello Yang Liu,
>
> You can have a look at the transport notes [1] for different ways of
> tweaking the interfaces in such ways that the performance can be improved.
> When these settings are not enough, then varying the sampling rate is also
> an option. When the sample rate has to be fixed because of application and
> design constraints, then your implementation itself may have some
> bottlenecks that are generating the overflows. You can see if your
> application is having a heavy load on the CPU by running a process viewer
> (such as 'top' or 'htop', if you are using a Unix machine), and if that is
> the case, then you could also optimize your design (with the help of tools
> such as Valgrind).
>
> Regards,
> - Nicolas
>
> [1] https://files.ettus.com/manual/page_transport.html
>
> On Mon, Apr 24, 2017 at 10:44 PM, Yang Liu via USRP-users <
> [email protected]> wrote:
>
>> Hello,
>>
>> We have an ofdm recevier at 25Msps and we notice oveflow "O", which from
>> uhd documentation means that device buffer shuts off streaming due to back
>> pressure.
>>
>> Results of overflow: while the transmitter keeps sending data (4000
>> packets in total), packets gets dropped after around 500 packets, then the
>> receiver will pick up again at around 3000 packets, that is, around 2500
>> packets gets dropped!
>>
>> Is there any buffer size that we can increase so that "O" doesn't happen?
>> We have increased Linux kernel buffers for tcp, but we still see the "O".
>>
>> Thanks a lot for your help.
>>
>> Yang
>>
>>
>> _______________________________________________
>> 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/20170425/10312e7b/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 25 Apr 2017 13:13:11 -0400
From: Yang Liu <[email protected]>
To: Derek Kozel <[email protected]>
Cc: Nicolas Cuervo <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Overflow
Message-ID:
<CAD4vFMHO0g_6hFCOzkYHydkboET=4tkdrjlqoquoetatyom...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Derek,
We are using USRP X310 with 10 Gigabit Eithernet connection. We have
reviewed the CPU usage and found that the fir_filter used in
gr::digital::sync_sc_cfb should be the bottleneck (we use this block to do
the frame synchronization in our 1024 OFDM design). We are looking at the
manual page to find the useful information.
Best,
Yang
On Tue, Apr 25, 2017 at 9:40 AM, Derek Kozel <[email protected]> wrote:
> Hello Yang Liu,
>
> What connection are you using to the USRP? And what type of USRP are you
> connected to? 25 MS/s is right at the edge of what 1 Gigabit Ethernet can
> sustain. Nicholas' recommendation of reviewing the CPU usage and the manual
> page on transport tuning has recommendations for a variety of transport
> types and operating systems.
>
> Regards,
> Derek
>
> On Tue, Apr 25, 2017 at 1:47 PM, Nicolas Cuervo via USRP-users <
> [email protected]> wrote:
>
>> Hello Yang Liu,
>>
>> You can have a look at the transport notes [1] for different ways of
>> tweaking the interfaces in such ways that the performance can be improved.
>> When these settings are not enough, then varying the sampling rate is also
>> an option. When the sample rate has to be fixed because of application and
>> design constraints, then your implementation itself may have some
>> bottlenecks that are generating the overflows. You can see if your
>> application is having a heavy load on the CPU by running a process viewer
>> (such as 'top' or 'htop', if you are using a Unix machine), and if that is
>> the case, then you could also optimize your design (with the help of tools
>> such as Valgrind).
>>
>> Regards,
>> - Nicolas
>>
>> [1] https://files.ettus.com/manual/page_transport.html
>>
>> On Mon, Apr 24, 2017 at 10:44 PM, Yang Liu via USRP-users <
>> [email protected]> wrote:
>>
>>> Hello,
>>>
>>> We have an ofdm recevier at 25Msps and we notice oveflow "O", which from
>>> uhd documentation means that device buffer shuts off streaming due to back
>>> pressure.
>>>
>>> Results of overflow: while the transmitter keeps sending data (4000
>>> packets in total), packets gets dropped after around 500 packets, then the
>>> receiver will pick up again at around 3000 packets, that is, around 2500
>>> packets gets dropped!
>>>
>>> Is there any buffer size that we can increase so that "O" doesn't
>>> happen? We have increased Linux kernel buffers for tcp, but we still see
>>> the "O".
>>>
>>> Thanks a lot for your help.
>>>
>>> Yang
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170425/4f99167c/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 25 Apr 2017 11:25:01 -0700
From: Michael West <[email protected]>
To: Dominik Eyerly <[email protected]>
Cc: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] B205i transient behavior
Message-ID:
<CAM4xKrpbCsnSgALY09tzkNRG=NnL5Z9Yp6WK=nhqm+fswfn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Dominik,
To keep the PA on all the time on the B205mini, change STATE_OFF to
TX_ENABLE1 on this line:
https://github.com/EttusResearch/uhd/blob/maint/host/lib/usrp/b200/b200_impl.cpp#L1178
I am still not convinced that is the main source of long ramp up in power.
Some transient due to PA warm up is expected, but it is usually on the
order of microseconds and not milliseconds.
Regards,
Michael
On Mon, Apr 24, 2017 at 12:44 AM, Dominik Eyerly <
[email protected]> wrote:
> Hi Michael,
>
> Would you be able to point out where in the code I need to make this
> modification to keep the PA on at all times? Padding with zeros is a very
> undesirable workaround for my application. I will set the tx gain down to
> minimize the switch isolation issue.
> Thanks,
> dominik
>
>
> On 04/15/2017 12:37 AM, Michael West wrote:
>
> Hi Dominik,
>
> Creating the streamer connects the blocks in the FPGA, creates the
> transports, and does some initialization for the stream. It shouldn't (and
> probably doesn't) matter whether you create the streamer or do the other
> operations first. I just recommend creating the streamers first as a best
> practice to be on the safe side.
>
> As for the PA, 100ms is longer than I would expect for the warm up time.
> I suspect the slow rise is partially due to PA warm up, but there may be
> other factors involved as well. I recommend trying varying amounts of
> leading zeros to see what the minimum amount is to see a clear signal.
> Keeping the PA on all the time should be possible, but it will take UHD
> code changes and could have side effects like higher noise on the RX side
> due to leakage across the RF switch.
>
> Regards,
> Michael
>
> On Wed, Apr 12, 2017 at 6:29 AM, Dominik Eyerly <
> [email protected]> wrote:
>
>> Hi Michael,
>>
>> Thank you for your response. Padding the end with zeros clears some of
>> the garbage that is played at the beginning of the waveform.
>>
>> Creating the streams at the beginning should be no problem for me. One
>> follow up question, you mentioned explicitly to create the streamer prior
>> to tuning, setting bandwidth etc, do these operations have a specific
>> effect on the streamer? Or in other words, what adverse effects, if any,
>> exist if I perform these operations before creating the streamer?
>>
>> As per the PA behavior, this is an issue that is extremely undesirable
>> for my application. I understand all PAs will have some rise time, however,
>> 100ms seems excessive. Is it perhaps possible to power up the PA earlier
>> via some modification to the host / fpga code? Simply pre-pending 100ms of
>> zeros to my waveform won't work because I need the waveform to play with
>> minimal delay. I don't have any low power constraints so it would not be a
>> problem to keep the PA permanently enabled, if that is possible.
>>
>> cheers,
>> dominik
>> On 04/11/2017 08:40 PM, Michael West wrote:
>>
>> Hi Dominik,
>>
>> I can confirm that the creation of the streamers is very intrusive. It
>> changes the active chains in the AD9364 and reconfigures the interface
>> between the AD9364 and FPGA as Marcus has pointed out. For that reason, it
>> is recommended to create all streamers before starting any streaming.
>>
>> Looking at the images you posted, the gap and first spur correlate to the
>> creation of the TX streamer, so that should be eliminated if the streamers
>> are created first. The next significant spur seems to align with the start
>> of the TX streaming. My suspicion is that it is from garbage samples left
>> in the DUC from initialization, but some testing is needed to prove that.
>> Finally, the ramp and elevated power level during the transmission of the
>> zeros is due to the TX PA being enabled when the stream starts.
>>
>> My suggestions:
>>
>> 1) Create the streamers right after creating the multi_usrp object
>> (before any tuning, setting bandwidth, setting sample rate, etc...).
>> 2) Pad the end of the TX burst with zeros. The first few samples
>> transmitted are always the residual samples in the DUC. This means the
>> last few samples of the burst will not actually make it to the AD9364
>> unless you pad with zeros to flush them. Zero padding the end of every
>> burst will make sure all desired samples are transmitted and that the next
>> burst will start by transmitting the residual zeros. The amount of the
>> group delay will vary depending on master clock rate and sample rate, but
>> it is usually on the order of a few to a couple hundred microseconds.
>>
>> Regards,
>> Michael
>>
>> On Tue, Apr 11, 2017 at 1:11 AM, Dominik Eyerly via USRP-users <
>> [email protected]> wrote:
>>
>>> Hello,
>>>
>>> A couple of days has gone by so I wanted to follow up on my questions..
>>>
>>> *"OK, so, with the zeros, I think I understand what's going on. When
>>> you create a new streamer, the hardware has to be configured to the new
>>> state.*
>>> * In the case of the AD9361, this means the data path between the
>>> AD9361 and the FPGA, which unavoidably means that the RX samples are
>>> interrupted*
>>> * while the interface is reconfigured. I believe this is the reason
>>> for a lump of zeros when you configure for TX--someone in engineering can
>>> correct*
>>> * my understanding if it's wrong."*
>>>
>>> So this is confirmed behavior then? It is inherently due to the AD chip
>>> and not a bug in the code somewhere (host / fpga)?
>>>
>>> *"In terms of the rather-long transient time--is this only immediately
>>> after configuring the TX streamer, or for any TX burst? If it's just
>>> immediately*
>>> * after configuring a TX streamer, then this may be expected. If it's
>>> at the start of every burst, then something is very wrong. Again, I'm
>>> awaiting*
>>> * comment from someone in Ettus R&D."*
>>>
>>> This is at the start of *every* burst that is initiated when rx is
>>> running. Even when the tx_streamer is kept alive. Have you had a chance to
>>> run my example program, or modify the existing loopback example in the way
>>> I described in my previous email to reproduce the issue? I don't believe I
>>> am doing something that is incorrect, however, if I am, I would be happy to
>>> have someone point out my mistake.
>>>
>>> Best regards,
>>> Dominik
>>>
>>> On 04/06/2017 05:51 PM, Marcus D. Leech wrote:
>>>
>>> On 04/06/2017 05:07 AM, Dominik Eyerly wrote:
>>>
>>> I'm using 1M for both rx and tx. I've seen that example but it does not
>>> have the correct setup to display this behavior. As I mentioned before, the
>>> acquisition has to be running BEFORE transmit begins. In the example code
>>> there is no synchronization between rx start and tx start so you don't get
>>> to see the beginning of the transmit in the capture. I added a simple
>>> atomic bool to the example to ensure rx is running before tx starts. This
>>> is sufficient to display the issue. Also, the issue of having zeros in rx
>>> when creating a streamer will also not be displayed in this example code
>>> because the tx_streamer is created before the acquisition starts.
>>>
>>> Here is a plot of the txrx loopback example with my minor
>>> synchronization addition.
>>>
>>> http://imgur.com/a/0FjeI
>>>
>>> Would you be able to run the code that I posted in my previous email to
>>> see if you have the same issues on your end?
>>>
>>>
>>> cheers,
>>> dominik
>>>
>>> OK, so, with the zeros, I think I understand what's going on. When you
>>> create a new streamer, the hardware has to be configured to the new state.
>>> In the case of the AD9361, this means the data path between the AD9361
>>> and the FPGA, which unavoidably means that the RX samples are interrupted
>>> while the interface is reconfigured. I believe this is the reason
>>> for a lump of zeros when you configure for TX--someone in engineering can
>>> correct
>>> my understanding if it's wrong.
>>>
>>>
>>> In terms of the rather-long transient time--is this only immediately
>>> after configuring the TX streamer, or for any TX burst? If it's just
>>> immediately
>>> after configuring a TX streamer, then this may be expected. If it's
>>> at the start of every burst, then something is very wrong. Again, I'm
>>> awaiting
>>> comment from someone in Ettus R&D.
>>>
>>>
>>>
>>> On 04/06/2017 04:10 AM, Marcus D. Leech wrote:
>>>
>>> On 04/05/2017 10:18 AM, Dominik Eyerly wrote:
>>>
>>> Hello,
>>>
>>> UHD: linux; GNU C++ version 5.2.1 20151005; Boost_106100;
>>> UHD_3.11.0.git-release, compiled for ARM
>>> B205 running on USB3.
>>>
>>> Doesn't matter if the port is terminated or if it has a signal, recv
>>> returns hard 0s, (not 1e-10 or the like) when a tx streamer is created.
>>> I've uploaded a simple bit of code that illustrates the behavior quite
>>> clearly.
>>>
>>> https://pastebin.com/ZAccunUe
>>>
>>> Please note that this code assumes you have 20dB of attenuation between
>>> rx and tx. However you can adjust the gain values appropriately if you do
>>> not.
>>>
>>> I compiled with: g++ streamissue.cpp -o streamtest -lboost_thread
>>> -lboost_system -luhd
>>>
>>> But honestly, this issue is not my primary concern. My primary concern
>>> is the ramp behavior. Note that the code I posted also illustrates the
>>> ramping behavior. For this it needs to be in loopback with 20dB attenuation
>>> (or more). I included a little helper function which performs a quick dump
>>> to a python file. If you have matplotlib for python you can uncomment the
>>> "dump_to_py" line in the rx thread and then simply run the generated file
>>> with python to see a quick plot of the iq data.
>>>
>>> What else could I do to further troubleshoot this?
>>>
>>> cheers,
>>> Dominik
>>>
>>> There is an example program, called txrx_loopback_to_file that does
>>> something similar to your test.
>>>
>>> I wonder if it would be possible to do your tests with that, and see if
>>> there is any change in behavior.
>>>
>>> Also, what sample rates are you using?
>>>
>>>
>>>
>>> On 04/05/2017 02:25 PM, Marcus D. Leech wrote:
>>>
>>> On 04/05/2017 05:57 AM, Dominik Eyerly wrote:
>>>
>>> Hello,
>>>
>>> Thanks for the reply. I should add I am doing this test at 3.8G.
>>>
>>> Response to (A)
>>>
>>> Are you saying that regardless of my tx gain setting, I need 40dB of
>>> attenuation? I believe at max tx gain the board outputs around 10-15dBm
>>> @3.8G. I currently have a 6dB pad on tx port, cabled to a splitter which is
>>> cabled to the rx port with an inline 10dB pad. The other splitter port is
>>> going directly into my VSA. Also, my tx gain is around 50dB. My
>>> understanding was that the max input power of the rx port is -15dBm. With
>>> this configuration I should be well under that, as shown on my VSA capture
>>> (~-35dBm).
>>>
>>> Response to (B)
>>>
>>> According to the rough specifications posted here:
>>> https://kb.ettus.com/B200/B210/B200mini/B205mini#RF_Specifications
>>>
>>> The IIP3 is -15dBm. As you can see on my VSA capture, it received -35dBm
>>> and that doesn't even include the extra 10dB pad on the ettus rx port. I
>>> should be good on linearity, should I not? The reason the power capture
>>> looks so wavy is probably because I have the LO's tuned to the same spot.
>>> When I move tx off by 100kHz the capture looks "nicer" but the ramp up
>>> behavior is still there. Also, on the link I posted above, the max input
>>> power is called out as 0 dBm... is that correct?
>>>
>>> Could you provide some input on the questions I brought up in my
>>> previous email? Namely:
>>>
>>> (1) recv returning 0s when a tx_streamer is created while receiving
>>> continuously.
>>>
>>> Could you try a simple experiment here? Place a terminator on the
>>> input to the RX side, and see if you get 0s in the recv buffer. I want to
>>> distinguish
>>> between an analog situation and a digital one.
>>>
>>> (2) The ramp up behavior that is only present when transmitting during
>>> an active acquisition.
>>>
>>> That's odd. What version of UHD are you using?
>>>
>>>
>>> I also want to mention that the first burst of power in my captures
>>> coincides with changing the frequency of the tx LO. This triggers an
>>> internal calibration of the AD chip which in turn outputs this brief burst.
>>> So at least this mystery is solved. I am curious, however, is it possible
>>> to allow the chip to perform its cal without actually seeing this signal at
>>> the tx port?
>>>
>>> I'm not certain of exactly how it performs its calibration, but likely
>>> there will always be some leakage when it is doing so.
>>>
>>>
>>> cheers,
>>> Dominik
>>>
>>> On 04/04/2017 04:54 PM, [email protected] wrote:
>>>
>>> How are you doing the physical loop-back? If directly-cabled, you'll
>>> need about 40dB of attenuation in-line, to keep the receiver from:
>>>
>>> (A) Being damaged
>>>
>>> (B) Remaining linear
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2017-04-04 09:14, Dominik Eyerly via USRP-users wrote:
>>>
>>> Hello all,
>>>
>>>
>>>
>>> My questions concern the B205i. I've uploaded some pictures to simplify
>>> the explaining process.
>>>
>>> http://imgur.com/a/XMAv6
>>>
>>> Basically, I want to transmit and receive a FSK waveform on one board
>>> (loopback). This means I've tuned both LOs to the same frequency. I've also
>>> inserted a splitter to be able to look at the signal on my VSA. This has
>>> allowed me to identify several problems.
>>>
>>>
>>>
>>> Let's start on the left:
>>> (B205i Receive - no zeros)
>>> Here you see the received power drop from the noise floor to -infinity
>>> because the rx_streamer was returning 0's. I've tracked this problem to the
>>> creation of a tx_streamer while an acquisition is running. This seems
>>> completely unacceptable; that calling a command on a chain (tx) that has
>>> nothing to do with rx, has an effect on rx. I could understand that the
>>> sample rate performance of rx is affected because they share a
>>> communication link, but not to actually alter the data that is returned by
>>> the recv call. Is this a known bug? Is there a workaround other than "don't
>>> do that"? Is this bug slated for a fix next release?
>>>
>>>
>>>
>>> Next:
>>> Right after all of the 0's, a strong but brief tone is blasted into the
>>> tx path. The power of this tone is not affected by the tx gain setting.
>>> This is quite a significant problem because we may use this module to test
>>> sensitive devices that may not be able to withstand such a transient. Any
>>> idea what is causing this? Again, any workarounds or fixes known?
>>>
>>>
>>>
>>> I don't care much for the spur at -83dBm. But it would be interesting to
>>> understand it.
>>>
>>>
>>>
>>> Lastly:
>>> The actual waveform is transmitted. Since this is an FSK waveform, I
>>> would expect a constant power envelope. Unfortunately, what I capture with
>>> the B205i is not even close. I performed the test again, but this time
>>> transmitting 200ms of 0s before my actual FSK waveform. You can still see
>>> the "warm up" looking behavior, however, by the time the actual waveform
>>> hits, the output seems settled. Is that what is happening (warm up)?
>>> Preloading every waveform with 200ms of zeroes is extremely undesirable. Is
>>> there a way to keep the chip always ready to go from both a Rx and Tx
>>> perspective?
>>>
>>>
>>>
>>> Tx only with no zeros:
>>> I performed the no zeros test again, this time without doing an
>>> acquisition with the B205i. Now the warm up behavior is completely gone.
>>> Why is Rx influencing the Tx RF performance?
>>>
>>>
>>>
>>> Any insight into these issues I am experiencing would be very
>>> appreciated.
>>>
>>> Best regards,
>>> Dominik
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>> --
>>>
>>> i.A. Dominik Eyerly
>>> Software
>>>
>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>> Email: [email protected]
>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>> *Support Telefon: +49 (0) 7732 9815 100
>>> <+49%207732%209815100>*[email protected][image: sig]
>>> Gesch?ftsleitung: Michael Konrad
>>> Handelsregisternr: HRB 550593 in Freiburg
>>> Ust-Id-Nr. DE 206693267
>>>
>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den
>>> Absender bitte umgehend. Danke
>>>
>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>> it, contains information from Konrad GmbH, which is intended only for the
>>> use of the individual or entity to which it is addressed, and which may
>>> contain information that is privileged, confidential, and/or otherwise
>>> exempt from disclosure under applicable law. If the reader of this message
>>> is not the intended recipient, any disclosure, dissemination, distribution,
>>> copying or other use of this communication or its substance is prohibited.
>>> If you have received this communication in error, please contact us
>>> immediately. Thank you.
>>>
>>> _______________________________________________ USRP-users mailing list
>>> [email protected] http://lists.ettus.com/mailman
>>> /listinfo/usrp-users_lists.ettus.com
>>>
>>> --
>>>
>>> --
>>>
>>> i.A. Dominik Eyerly
>>> Software
>>>
>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>> Email: [email protected]
>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>> *Support Telefon: +49 (0) 7732 9815 100
>>> <+49%207732%209815100>*[email protected][image: sig]
>>> Gesch?ftsleitung: Michael Konrad
>>> Handelsregisternr: HRB 550593 in Freiburg
>>> Ust-Id-Nr. DE 206693267
>>>
>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den
>>> Absender bitte umgehend. Danke
>>>
>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>> it, contains information from Konrad GmbH, which is intended only for the
>>> use of the individual or entity to which it is addressed, and which may
>>> contain information that is privileged, confidential, and/or otherwise
>>> exempt from disclosure under applicable law. If the reader of this message
>>> is not the intended recipient, any disclosure, dissemination, distribution,
>>> copying or other use of this communication or its substance is prohibited.
>>> If you have received this communication in error, please contact us
>>> immediately. Thank you.
>>>
>>> --
>>>
>>> --
>>>
>>> i.A. Dominik Eyerly
>>> Software
>>>
>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>> Email: [email protected]
>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>> *Support Telefon: +49 (0) 7732 9815 100
>>> <+49%207732%209815100>*[email protected][image: sig]
>>> Gesch?ftsleitung: Michael Konrad
>>> Handelsregisternr: HRB 550593 in Freiburg
>>> Ust-Id-Nr. DE 206693267
>>>
>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den
>>> Absender bitte umgehend. Danke
>>>
>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>> it, contains information from Konrad GmbH, which is intended only for the
>>> use of the individual or entity to which it is addressed, and which may
>>> contain information that is privileged, confidential, and/or otherwise
>>> exempt from disclosure under applicable law. If the reader of this message
>>> is not the intended recipient, any disclosure, dissemination, distribution,
>>> copying or other use of this communication or its substance is prohibited.
>>> If you have received this communication in error, please contact us
>>> immediately. Thank you.
>>>
>>> --
>>>
>>> --
>>>
>>> i.A. Dominik Eyerly
>>> Software
>>>
>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>> Email: [email protected]
>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>> *Support Telefon: +49 (0) 7732 9815 100
>>> <+49%207732%209815100>*[email protected][image: sig]
>>> Gesch?ftsleitung: Michael Konrad
>>> Handelsregisternr: HRB 550593 in Freiburg
>>> Ust-Id-Nr. DE 206693267
>>>
>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den
>>> Absender bitte umgehend. Danke
>>>
>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>> it, contains information from Konrad GmbH, which is intended only for the
>>> use of the individual or entity to which it is addressed, and which may
>>> contain information that is privileged, confidential, and/or otherwise
>>> exempt from disclosure under applicable law. If the reader of this message
>>> is not the intended recipient, any disclosure, dissemination, distribution,
>>> copying or other use of this communication or its substance is prohibited.
>>> If you have received this communication in error, please contact us
>>> immediately. Thank you.
>>>
>>> --
>>>
>>> --
>>>
>>> i.A. Dominik Eyerly
>>> Software
>>>
>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>> Email: [email protected]
>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>> *Support Telefon: +49 (0) 7732 9815 100
>>> <+49%207732%209815100>*[email protected][image: sig]
>>> Gesch?ftsleitung: Michael Konrad
>>> Handelsregisternr: HRB 550593 in Freiburg
>>> Ust-Id-Nr. DE 206693267
>>>
>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den
>>> Absender bitte umgehend. Danke
>>>
>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>> it, contains information from Konrad GmbH, which is intended only for the
>>> use of the individual or entity to which it is addressed, and which may
>>> contain information that is privileged, confidential, and/or otherwise
>>> exempt from disclosure under applicable law. If the reader of this message
>>> is not the intended recipient, any disclosure, dissemination, distribution,
>>> copying or other use of this communication or its substance is prohibited.
>>> If you have received this communication in error, please contact us
>>> immediately. Thank you.
>>>
>>> _______________________________________________ USRP-users mailing list
>>> [email protected] http://lists.ettus.com/mailman
>>> /listinfo/usrp-users_lists.ettus.com
>>
>> --
>>
>> --
>>
>> i.A. Dominik Eyerly
>> Software
>>
>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>> Email: [email protected]
>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>> *Support Telefon: +49 (0) 7732 9815 100
>> <+49%207732%209815100>*[email protected][image: sig]
>> Gesch?ftsleitung: Michael Konrad
>> Handelsregisternr: HRB 550593 in Freiburg
>> Ust-Id-Nr. DE 206693267
>>
>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
>> bitte umgehend. Danke
>>
>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>> it, contains information from Konrad GmbH, which is intended only for the
>> use of the individual or entity to which it is addressed, and which may
>> contain information that is privileged, confidential, and/or otherwise
>> exempt from disclosure under applicable law. If the reader of this message
>> is not the intended recipient, any disclosure, dissemination, distribution,
>> copying or other use of this communication or its substance is prohibited.
>> If you have received this communication in error, please contact us
>> immediately. Thank you.
>>
>> --
>
> --
>
> i.A. Dominik Eyerly
> Software
>
> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
> Email: [email protected]
> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
> *Support Telefon: +49 (0) 7732 9815 100
> <+49%207732%209815100>*[email protected][image: sig]
> Gesch?ftsleitung: Michael Konrad
> Handelsregisternr: HRB 550593 in Freiburg
> Ust-Id-Nr. DE 206693267
>
> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
> bitte umgehend. Danke
>
> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it,
> contains information from Konrad GmbH, which is intended only for the use of
> the individual or entity to which it is addressed, and which may contain
> information that is privileged, confidential, and/or otherwise exempt from
> disclosure under applicable law. If the reader of this message is not the
> intended recipient, any disclosure, dissemination, distribution, copying or
> other use of this communication or its substance is prohibited. If you have
> received this communication in error, please contact us immediately. Thank
> you.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170425/6f9f9822/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170425/6f9f9822/attachment-0006.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170425/6f9f9822/attachment-0007.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170425/6f9f9822/attachment-0008.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170425/6f9f9822/attachment-0009.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170425/6f9f9822/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170425/6f9f9822/attachment-0010.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170425/6f9f9822/attachment-0011.jpe>
------------------------------
Message: 5
Date: Tue, 25 Apr 2017 14:13:01 -0500
From: Jonathon Pendlum <[email protected]>
To: "Templin, Josh" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC: Testbench stalling when simulating
block with multiple ports, bug in sim_rfnoc_lib.svh?
Message-ID:
<cagdo0urakdni+msna7a0-5+5j6i_thrzk-wvvihevgdztr3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Josh,
That is a bug and you are correct, it should be "sid_``to_noc_block_name".
If you make that change, does your testbench work?
Jonathon
On Tue, Apr 25, 2017 at 11:11 AM, Templin, Josh via USRP-users <
[email protected]> wrote:
> Hi all,
>
>
>
> I am developing a multi-port RFNOC block with UHD 3.10.1.1 and simulating
> using XSim in Vivado 2015.4 on Ubuntu 16.04 targeting an X300. When I
> simulate, the simulation stalls whenever I connect the second port on my
> module as the destination, as in the testbench line:
>
>
>
> `RFNOC_CONNECT_BLOCK_PORT(noc_block_tb,0,noc_block_test,1,
> SC16,SPP);
>
>
>
> Looking at the xbar transactions in the simulation, the last transaction
> is a command transaction from the tb_config crossbar port (port 0.3.0 in my
> testbench) to the noc_block_test crossbar port (port 0.1.1 in my
> testbench). The command packet is:
>
>
>
> 8093001000300011
>
> 0000007d00c1ea12
>
>
>
> Which looks fine and seems to correspond to the second write_reg command
> in the RFNOC_CONNECT_BLOCK_PORT macro found in sim_rfnoc_lib.svh:
>
>
>
> // Setup RFNoC block flow control per block port
>
> //
>
> // Usage: `RFNOC_CONNECT_BLOCK_PORT()
>
> // - from_noc_block_name: Name of producer (or upstream) RFNoC block
>
> // - from_block_port: Block port of producer RFNoC block
>
> // - to_noc_block_name: Name of consumer (or downstream) RFNoC block
>
> // - to_block_port: Block port of consumer RFNoC block
>
> // - data_type: Data type for data stream (i.e. SC16, FC32,
> etc)
>
> // - spp: Samples per packet
>
> //
>
> `define RFNOC_CONNECT_BLOCK_PORT(from_noc_block_name,from_block_
> port,to_noc_block_name,to_block_port,data_type,spp) \
>
> $display("Connecting %s (SID: %0d:%0d) to %s (SID: %0d:%0d)", \
>
> `"from_noc_block_name`",sid_``from_noc_block_name >>
> 4,from_block_port, \
>
> `"to_noc_block_name`",sid_``to_noc_block_name >>
> 4,to_block_port); \
>
> // Clear block, write be any value \
>
> tb_config.write_reg(sid_``from_noc_block_name, SR_CLEAR_TX_FC,
> 32'hC1EA12, from_block_port); \
>
> >> tb_config.write_reg(sid_``from_noc_block_name, SR_CLEAR_RX_FC,
> 32'hC1EA12, to_block_port); \
>
>
>
> The pairing of ?from_noc_block_name? with ?to_block_port? seems to be
> causing the problem, since the source block has only 1 port but I am
> connecting to the destination block?s 2nd port. It seems like this should
> be sid_``to_noc_block_name? Is this a bug or am I misunderstanding how to
> connect and use multi-port blocks?
>
>
>
> I encountered this problem earlier when connecting to my testbench and was
> able to workaround it by declaring my testbench to have 2 ports and
> ignoring the second port. Now, I am connecting to another rfnoc block from
> the library and I cannot trivially change its number of ports, so my
> workaround fails.
>
>
>
> Thanks,
>
> Josh
>
>
>
>
>
> _______________________________________________
> 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/20170425/1bb9f5f7/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 25 Apr 2017 21:04:41 +0000
From: "Templin, Josh" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC: Testbench stalling when simulating
block with multiple ports, bug in sim_rfnoc_lib.svh?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
It progresses further, but the connect does not succeed yet. I?ll do some more
investigating and report back.
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Tuesday, April 25, 2017 1:13 PM
To: Templin, Josh
Cc: [email protected]
Subject: [EXTERNAL] Re: [USRP-users] RFNOC: Testbench stalling when simulating
block with multiple ports, bug in sim_rfnoc_lib.svh?
Hi Josh,
That is a bug and you are correct, it should be "sid_``to_noc_block_name". If
you make that change, does your testbench work?
Jonathon
On Tue, Apr 25, 2017 at 11:11 AM, Templin, Josh via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi all,
I am developing a multi-port RFNOC block with UHD 3.10.1.1 and simulating using
XSim in Vivado 2015.4 on Ubuntu 16.04 targeting an X300. When I simulate, the
simulation stalls whenever I connect the second port on my module as the
destination, as in the testbench line:
`RFNOC_CONNECT_BLOCK_PORT(noc_block_tb,0,noc_block_test,1,SC16,SPP);
Looking at the xbar transactions in the simulation, the last transaction is a
command transaction from the tb_config crossbar port (port 0.3.0 in my
testbench) to the noc_block_test crossbar port (port 0.1.1 in my testbench).
The command packet is:
8093001000300011
0000007d00c1ea12
Which looks fine and seems to correspond to the second write_reg command in the
RFNOC_CONNECT_BLOCK_PORT macro found in sim_rfnoc_lib.svh:
// Setup RFNoC block flow control per block port
//
// Usage: `RFNOC_CONNECT_BLOCK_PORT()
// - from_noc_block_name: Name of producer (or upstream) RFNoC block
// - from_block_port: Block port of producer RFNoC block
// - to_noc_block_name: Name of consumer (or downstream) RFNoC block
// - to_block_port: Block port of consumer RFNoC block
// - data_type: Data type for data stream (i.e. SC16, FC32, etc)
// - spp: Samples per packet
//
`define
RFNOC_CONNECT_BLOCK_PORT(from_noc_block_name,from_block_port,to_noc_block_name,to_block_port,data_type,spp)
\
$display("Connecting %s (SID: %0d:%0d) to %s (SID: %0d:%0d)", \
`"from_noc_block_name`",sid_``from_noc_block_name >>
4,from_block_port, \
`"to_noc_block_name`",sid_``to_noc_block_name >> 4,to_block_port); \
// Clear block, write be any value \
tb_config.write_reg(sid_``from_noc_block_name, SR_CLEAR_TX_FC, 32'hC1EA12,
from_block_port); \
>> tb_config.write_reg(sid_``from_noc_block_name, SR_CLEAR_RX_FC, 32'hC1EA12,
>> to_block_port); \
The pairing of ?from_noc_block_name? with ?to_block_port? seems to be causing
the problem, since the source block has only 1 port but I am connecting to the
destination block?s 2nd port. It seems like this should be
sid_``to_noc_block_name? Is this a bug or am I misunderstanding how to connect
and use multi-port blocks?
I encountered this problem earlier when connecting to my testbench and was able
to workaround it by declaring my testbench to have 2 ports and ignoring the
second port. Now, I am connecting to another rfnoc block from the library and
I cannot trivially change its number of ports, so my workaround fails.
Thanks,
Josh
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20170425/1fdc7736/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 25 Apr 2017 22:02:02 +0000
From: Jessica Iwamoto <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Modifying AD9361 Driver
Message-ID:
<sn1pr09mb10088c59ca2b4a47b99e420f9b...@sn1pr09mb1008.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi all,
I am trying to implement fast lock on the AD9361 in the E310. So far, I've
written code to modify the AD9361 driver and perform the SPI writes to
implement fast lock, but I am having trouble seeing how to connect this
functionality to the API (i.e. how would I call my SPI writing function from
the API). I noticed that the property tree seems to provide a way to connect
the driver and API, though I'm not sure if this is the correct/best way to do
this and how I would do this, or if there is a better way. Can anyone give me
more information about the property tree and/or advice on how to implement this?
Thank you,
Jessica
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170425/d0cb3e40/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 25 Apr 2017 22:09:32 +0000
From: "Templin, Josh" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC: Testbench stalling when simulating
block with multiple ports, bug in sim_rfnoc_lib.svh?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
The connection does complete. It appeared not to before because sometimes the
TCL Console in XSim drops/doesn?t fully flush print statements before it
terminates, but a second run of the testbench verified the connection completed
and the testbench proceeded.
Thanks,
Josh
From: USRP-users [mailto:[email protected]] On Behalf Of
Templin, Josh via USRP-users
Sent: Tuesday, April 25, 2017 3:05 PM
To: Jonathon Pendlum
Cc: [email protected]
Subject: [EXTERNAL] Re: [USRP-users] RFNOC: Testbench stalling when simulating
block with multiple ports, bug in sim_rfnoc_lib.svh?
It progresses further, but the connect does not succeed yet. I?ll do some more
investigating and report back.
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Tuesday, April 25, 2017 1:13 PM
To: Templin, Josh
Cc: [email protected]<mailto:[email protected]>
Subject: [EXTERNAL] Re: [USRP-users] RFNOC: Testbench stalling when simulating
block with multiple ports, bug in sim_rfnoc_lib.svh?
Hi Josh,
That is a bug and you are correct, it should be "sid_``to_noc_block_name". If
you make that change, does your testbench work?
Jonathon
On Tue, Apr 25, 2017 at 11:11 AM, Templin, Josh via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi all,
I am developing a multi-port RFNOC block with UHD 3.10.1.1 and simulating using
XSim in Vivado 2015.4 on Ubuntu 16.04 targeting an X300. When I simulate, the
simulation stalls whenever I connect the second port on my module as the
destination, as in the testbench line:
`RFNOC_CONNECT_BLOCK_PORT(noc_block_tb,0,noc_block_test,1,SC16,SPP);
Looking at the xbar transactions in the simulation, the last transaction is a
command transaction from the tb_config crossbar port (port 0.3.0 in my
testbench) to the noc_block_test crossbar port (port 0.1.1 in my testbench).
The command packet is:
8093001000300011
0000007d00c1ea12
Which looks fine and seems to correspond to the second write_reg command in the
RFNOC_CONNECT_BLOCK_PORT macro found in sim_rfnoc_lib.svh:
// Setup RFNoC block flow control per block port
//
// Usage: `RFNOC_CONNECT_BLOCK_PORT()
// - from_noc_block_name: Name of producer (or upstream) RFNoC block
// - from_block_port: Block port of producer RFNoC block
// - to_noc_block_name: Name of consumer (or downstream) RFNoC block
// - to_block_port: Block port of consumer RFNoC block
// - data_type: Data type for data stream (i.e. SC16, FC32, etc)
// - spp: Samples per packet
//
`define
RFNOC_CONNECT_BLOCK_PORT(from_noc_block_name,from_block_port,to_noc_block_name,to_block_port,data_type,spp)
\
$display("Connecting %s (SID: %0d:%0d) to %s (SID: %0d:%0d)", \
`"from_noc_block_name`",sid_``from_noc_block_name >>
4,from_block_port, \
`"to_noc_block_name`",sid_``to_noc_block_name >> 4,to_block_port); \
// Clear block, write be any value \
tb_config.write_reg(sid_``from_noc_block_name, SR_CLEAR_TX_FC, 32'hC1EA12,
from_block_port); \
>> tb_config.write_reg(sid_``from_noc_block_name, SR_CLEAR_RX_FC, 32'hC1EA12,
>> to_block_port); \
The pairing of ?from_noc_block_name? with ?to_block_port? seems to be causing
the problem, since the source block has only 1 port but I am connecting to the
destination block?s 2nd port. It seems like this should be
sid_``to_noc_block_name? Is this a bug or am I misunderstanding how to connect
and use multi-port blocks?
I encountered this problem earlier when connecting to my testbench and was able
to workaround it by declaring my testbench to have 2 ports and ignoring the
second port. Now, I am connecting to another rfnoc block from the library and
I cannot trivially change its number of ports, so my workaround fails.
Thanks,
Josh
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20170425/014e36d8/attachment-0001.html>
------------------------------
Message: 9
Date: Wed, 26 Apr 2017 11:12:09 +0900
From: ??? <[email protected]>
To: [email protected] <[email protected]>
Subject: [USRP-users] E310 Audio Jack
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi all
Is it OK to plug 25mm 3p plug on E310 audio jack?
It looks like 25mm 4p plug is not popular
Regards
Kim taeyeong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/0adf69a0/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 26 Apr 2017 02:41:03 +0000
From: Robin Coxe <[email protected]>
To: "[email protected]" <[email protected]>, "???"
<[email protected]>
Subject: Re: [USRP-users] E310 Audio Jack
Message-ID:
<by2pr14mb079000a3eecaf7ec7190f73df2...@by2pr14mb0790.namprd14.prod.outlook.com>
Content-Type: text/plain; charset="ks_c_5601-1987"
You can try your plug, but your may get a mono (instead of a stereo) output and
the microphone may or may not work.
The pinout of this jack is non-standard:
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_hw_audio
Very few customers use it for anything useful and we have had reliability
problems with the USB audio codec. In fact, the audio jack will be
disappearing altogether from new E310 and E312 units by the end of 2017.
-Robin
_____________________________
From: ??? via USRP-users
<[email protected]<mailto:[email protected]>>
Sent: Tuesday, April 25, 2017 7:13 PM
Subject: [USRP-users] E310 Audio Jack
To: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Hi all
Is it OK to plug 2.5mm 3p plug on E310 audio jack?
It looks like 2.5mm 4p plug is not popular.
Regards
Kim taeyeong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/fb1dcfd7/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 26 Apr 2017 12:20:58 +0300
From: Haile Berhe <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] install gr-doa via pybombs - how?
Message-ID:
<CAHr+hkEOMLu_WGW7JZrB=iiphd5vunezk_hazfewccn6spx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
I have successfully installed gnuradio and many useful OOT modules using
pybombs thanks to [1]. However, I could not install gr-doa in the same
fashion I did to other OOT modules.
When I run 'pybombs install gr-doa', pybombs display the following error:
PyBOMBS.get_recipe - ERROR - Error fetching recipe `gr-doa':
Package gr-doa has no recipe file!
I don't want to risk my clean installation by trying to add recipe or
something like that as the error suggests.
Any suggestion please!
Thanks
Haile
[1] https://www.gnuradio.org/blog/pybombs-the-what-the-how-and-the-why/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/d3843741/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 26 Apr 2017 10:07:11 +0000
From: Crozzoli Maurizio <[email protected]>
To: "[email protected]" <[email protected]>
Cc: Disco Daniele <[email protected]>, Quasso Roberto
<[email protected]>
Subject: [USRP-users] Install NFS server on E310
Message-ID:
<10adeafc450f4f7a8fe5979d5d9f8133@TELMBXD10BA020.telecomitalia.local>
Content-Type: text/plain; charset="iso-8859-1"
Hi!
We need to install an NFS server on E310 (in order to get data out of it after
their acquisition).
Given that the Linux in the image provided by Ettus does not seem to be a
Debian-like system, so no "apt" tool seems to be available, we do not know how
to proceed: could anyone suggest the easiest way out?
TIA!
BR,
Maurizio.
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
Grazie.
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the sender
by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non ? necessario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/0703d238/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 26 Apr 2017 12:15:37 +0200
From: Sebastian Mueller <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RuntimeError: basic_string::_M_construct
null not valid when using RFNoC:Radio
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Martin,
thanks for the feedback, I hope I did this the way you intended. The
backtrace when the exception occurs is the following:
-----------------------------------------------------------------------------
Thread 1 "python" hit Catchpoint 1 (exception thrown),
0x00007ffff4e198bd in __cxa_throw () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#0 0x00007ffff4e198bd in __cxa_throw () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x00007fffc9251954 in uhd::dict<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
boost::weak_ptr<uhd::wb_iface> >::pop(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&) () from
/usr/local/lib/libuhd.so.004
#2 0x00007fffc92368b2 in x300_impl::~x300_impl() () from
/usr/local/lib/libuhd.so.004
#3 0x00007fffc92519c5 in
boost::detail::sp_counted_impl_p<x300_impl>::dispose() () from
/usr/local/lib/libuhd.so.004
#4 0x00007fffc296bb30 in boost::detail::sp_counted_base::release
(this=0x1844420) at
/usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146
#5 0x00007fffc296bbc3 in boost::detail::shared_count::~shared_count
(this=0xaca300, __in_chrg=<optimized out>) at
/usr/include/boost/smart_ptr/detail/shared_count.hpp:443
#6 0x00007fffc296c08a in boost::shared_ptr<uhd::device3>::~shared_ptr
(this=0xaca2f8, __in_chrg=<optimized out>) at
/usr/include/boost/smart_ptr/shared_ptr.hpp:323
#7 0x00007fffc296c419 in device3_impl::~device3_impl (this=0xaca2f0,
__in_chrg=<optimized out>) at /home/senpo/src/gr-ettus/lib/device3.cc:50
#8 0x00007fffc296c48a in device3_impl::~device3_impl (this=0xaca2f0,
__in_chrg=<optimized out>) at /home/senpo/src/gr-ettus/lib/device3.cc:52
#9 0x00007fffc2972d23 in boost::checked_delete<device3_impl>
(x=0xaca2f0) at /usr/include/boost/core/checked_delete.hpp:34
#10 0x00007fffc2978ab6 in
boost::detail::sp_counted_impl_p<device3_impl>::dispose (this=0x1c1c3f0)
at /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:78
#11 0x00007fffc2cf3eac in boost::detail::sp_counted_base::release
(this=0x1c1c3f0) at
/usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146
#12 0x00007fffc2cf3f75 in boost::detail::shared_count::~shared_count
(this=0x1bdf3f8, __in_chrg=<optimized out>) at
/usr/include/boost/smart_ptr/detail/shared_count.hpp:443
#13 0x00007fffc2cf5988 in
boost::shared_ptr<gr::ettus::device3>::~shared_ptr (this=0x1bdf3f0,
__in_chrg=<optimized out>) at
/usr/include/boost/smart_ptr/shared_ptr.hpp:323
#14 0x00007fffc2c8d566 in _wrap_delete_device3_sptr
(args=0x7fffc9eb8d10) at
/home/senpo/src/gr-ettus/build/swig/ettus_swigPYTHON_wrap.cxx:21306
#15 0x00000000004b0cb3 in PyObject_Call ()
#16 0x00000000004b97fa in PyObject_CallFunctionObjArgs ()
#17 0x00007fffc2c52463 in SwigPyObject_dealloc (v=0x7fffc2906b10) at
/home/senpo/src/gr-ettus/build/swig/ettus_swigPYTHON_wrap.cxx:1721
#18 0x00000000004fd4e6 in ?? ()
#19 0x00000000004d9197 in ?? ()
#20 0x00000000004df80b in ?? ()
#21 0x00000000004df7db in ?? ()
#22 0x00000000004df7db in ?? ()
#23 0x00000000004a0d22 in PyDict_SetItem ()
#24 0x00000000004a46ac in PyDict_SetItemString ()
#25 0x00000000005026bd in PyImport_Cleanup ()
#26 0x0000000000500489 in Py_Finalize ()
#27 0x000000000049df2f in Py_Main ()
#28 0x00007ffff7811830 in __libc_start_main (main=0x49dab0 <main>,
argc=2, argv=0x7fffffffdfe8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>,
stack_end=0x7fffffffdfd8) at ../csu/libc-start.c:291
#29 0x000000000049d9d9 in _start ()
Single stepping until exit from function __cxa_throw,
which has no line number information.
[Switching to Thread 0x7fffc0759700 (LWP 18100)]
-----------------------------------------------------------------------------
Hope this helps. I won't have any further access to the hardware from
now on (dropping out of CEL), but the good news is that the error does
not need to be solved for me now. Maybe just a misconfiguration on my
machine.
Best,
Sebastian
On 11.04.2017 22:51, Martin Braun via USRP-users wrote:
> Sorry to send you down that rabbit hole, but can you run this with debug
> symbols enabled through gdb, and breakpoint on all exceptions? You will
> have to skip a few (normal) exceptions before you get to this one.
>
> -- M
>
> On Fri, Mar 03, 2017 at 12:58:41PM +0100, Sebastian Mueller via USRP-users
> wrote:
>> Hello Martin,
>>
>> This is what I get from uhd_usrp_probe after flashing it with my custom
>> FPGA image. In addition, I still get the same error with the default
>> FPGA image regardless:
>>
>>
>> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>> UHD_004.000.000.rfnoc-devel-641-g8773fb2c
>>
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 1472 bytes.
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- Detecting internal GPSDO.... No GPSDO found
>>
>> UHD Error:
>> get_stat(): unsupported GPS or no GPS detected
>> -- [RFNOC] ------- Block Setup -----------
>> -- Setting up NoC-Shell Control for port #0 (SID: 00:00>02:30)...OK
>> -- Port 48: Found NoC-Block with ID F1F0D00000000000.
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/dma_fifo.xml
>> -- Setting up NoC-Shell Control for port #1 (SID: 00:01>02:31)...OK
>> -- [RFNoC Factory] block_ctrl_base::make()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/dma_fifo.xml
>> -- [RFNoC Factory] Using controller key 'DmaFIFO' and block name 'DmaFIFO'
>> -- block_ctrl_base()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/dma_fifo.xml
>> -- Found valid blockdef
>> -- NOC ID: 0xF1F0D00000000000 Block ID: 0/DmaFIFO_0
>> -- [0/DmaFIFO_0] block_ctrl_base::clear()
>> -- [0/DmaFIFO_0] node_ctrl_base::clear()
>> -- [0/DmaFIFO_0] block_ctrl_base::_clear()
>> -- [0/DmaFIFO_0] block_ctrl_base::_clear()
>> -- [0/DmaFIFO_0] Adding port definition at xbar/DmaFIFO_0/ports/in/0:
>> type = '' pkt_size = '0' vlen = '0'
>> -- [0/DmaFIFO_0] Adding port definition at xbar/DmaFIFO_0/ports/in/1:
>> type = '' pkt_size = '0' vlen = '0'
>> -- [0/DmaFIFO_0] Adding port definition at xbar/DmaFIFO_0/ports/out/0:
>> type = '' pkt_size = '0' vlen = '0'
>> -- [0/DmaFIFO_0] Adding port definition at xbar/DmaFIFO_0/ports/out/1:
>> type = '' pkt_size = '0' vlen = '0'
>> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1296.1MB/s)
>> -- [NocScript] Executing and asserting code: EQUAL($base_addr, 0) OR
>> IS_PWR_OF_2($base_addr)
>> -- [NocScript] Executing and asserting code: IS_PWR_OF_2($depth)
>> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1293.4MB/s)
>> -- [NocScript] Executing and asserting code: EQUAL($base_addr, 0) OR
>> IS_PWR_OF_2($base_addr)
>> -- [NocScript] Executing and asserting code: IS_PWR_OF_2($depth)
>> -- [RFNOC] ------- Block Setup -----------
>> -- Setting up NoC-Shell Control for port #0 (SID: 00:02>02:40)...OK
>> -- Port 64: Found NoC-Block with ID 12AD100000000001.
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
>> -- Setting up NoC-Shell Control for port #1 (SID: 00:03>02:41)...OK
>> -- [RFNoC Factory] block_ctrl_base::make()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
>> -- [RFNoC Factory] Using controller key 'X300Radio' and block name 'Radio'
>> -- block_ctrl_base()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
>> -- Found valid blockdef
>> -- NOC ID: 0x12AD100000000001 Block ID: 0/Radio_0
>> -- [0/Radio_0] block_ctrl_base::clear()
>> -- [0/Radio_0] node_ctrl_base::clear()
>> -- [0/Radio_0] block_ctrl_base::_clear()
>> -- [0/Radio_0] block_ctrl_base::_clear()
>> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/1: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type
>> = 'sc16' pkt_size = '0' vlen = '0'
>> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/1: type
>> = 'sc16' pkt_size = '0' vlen = '0'
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [0/Radio_0] radio_ctrl_impl::_update_spp(): Requested spp: 364
>> -- [0/Radio_0] radio_ctrl_impl::_update_spp(): Setting spp to: 364
>> -- [0/Radio_0] x300_radio_ctrl_impl::ctor()
>> -- [0/Radio_0] radio_ctrl_impl::_update_spp(): Requested spp: 364
>> -- [0/Radio_0] radio_ctrl_impl::_update_spp(): Setting spp to: 364
>> -- [RFNOC] ------- Block Setup -----------
>> -- Setting up NoC-Shell Control for port #0 (SID: 00:04>02:50)...OK
>> -- Port 80: Found NoC-Block with ID 12AD100000000001.
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
>> -- Setting up NoC-Shell Control for port #1 (SID: 00:05>02:51)...OK
>> -- [RFNoC Factory] block_ctrl_base::make()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
>> -- [RFNoC Factory] Using controller key 'X300Radio' and block name 'Radio'
>> -- block_ctrl_base()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
>> -- Found valid blockdef
>> -- NOC ID: 0x12AD100000000001 Block ID: 0/Radio_1
>> -- [0/Radio_1] block_ctrl_base::clear()
>> -- [0/Radio_1] node_ctrl_base::clear()
>> -- [0/Radio_1] block_ctrl_base::_clear()
>> -- [0/Radio_1] block_ctrl_base::_clear()
>> -- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/in/0: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/in/1: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/out/0: type
>> = 'sc16' pkt_size = '0' vlen = '0'
>> -- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/out/1: type
>> = 'sc16' pkt_size = '0' vlen = '0'
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [0/Radio_1] radio_ctrl_impl::_update_spp(): Requested spp: 364
>> -- [0/Radio_1] radio_ctrl_impl::_update_spp(): Setting spp to: 364
>> -- [0/Radio_1] x300_radio_ctrl_impl::ctor()
>> -- [0/Radio_1] radio_ctrl_impl::_update_spp(): Requested spp: 364
>> -- [0/Radio_1] radio_ctrl_impl::_update_spp(): Setting spp to: 364
>> -- [RFNOC] ------- Block Setup -----------
>> -- Setting up NoC-Shell Control for port #0 (SID: 00:06>02:60)...OK
>> -- Port 96: Found NoC-Block with ID 000000000000514C.
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/sync.xml
>> -- [RFNoC Factory] block_ctrl_base::make()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/sync.xml
>> -- [RFNoC Factory] Using controller key 'Block' and block name 'sync'
>> -- block_ctrl_base()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/sync.xml
>> -- Found valid blockdef
>> -- NOC ID: 0x000000000000514C Block ID: 0/sync_0
>> -- [0/sync_0] block_ctrl_base::clear()
>> -- [0/sync_0] node_ctrl_base::clear()
>> -- [0/sync_0] block_ctrl_base::_clear()
>> -- [0/sync_0] Adding port definition at xbar/sync_0/ports/in/0: type =
>> '' pkt_size = '0' vlen = '0'
>> -- [0/sync_0] Adding port definition at xbar/sync_0/ports/out/0: type =
>> '' pkt_size = '0' vlen = '0'
>> -- [RFNOC] ------- Block Setup -----------
>> -- Setting up NoC-Shell Control for port #0 (SID: 00:07>02:70)...OK
>> -- Port 112: Found NoC-Block with ID DDC0000000000000.
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/ddc.xml
>> -- Setting up NoC-Shell Control for port #1 (SID: 00:08>02:71)...OK
>> -- [RFNoC Factory] block_ctrl_base::make()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/ddc.xml
>> -- [RFNoC Factory] Using controller key 'DDC' and block name 'DDC'
>> -- block_ctrl_base()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/ddc.xml
>> -- Found valid blockdef
>> -- NOC ID: 0xDDC0000000000000 Block ID: 0/DDC_0
>> -- [0/DDC_0] block_ctrl_base::clear()
>> -- [0/DDC_0] node_ctrl_base::clear()
>> -- [0/DDC_0] block_ctrl_base::_clear()
>> -- [0/DDC_0] block_ctrl_base::_clear()
>> -- [0/DDC_0] Adding port definition at xbar/DDC_0/ports/in/0: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [0/DDC_0] Adding port definition at xbar/DDC_0/ports/in/1: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [0/DDC_0] Adding port definition at xbar/DDC_0/ports/out/0: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [0/DDC_0] Adding port definition at xbar/DDC_0/ports/out/1: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
>> -- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
>> -- [NocScript] Executing and asserting code: GE($fullscale, 0.0)
>> -- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
>> -- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
>> -- [NocScript] Executing and asserting code: GE($fullscale, 0.0)
>> -- [0/DDC_0] sr_write(CORDIC_FREQ, 00000000) ==>
>> -- [0/DDC_0] sr_write(DECIM_WORD, 00000001) ==>
>> -- [0/DDC_0] sr_write(N, 00000001) ==>
>> -- [0/DDC_0] sr_write(M, 00000001) ==>
>> -- [0/DDC_0] sr_write(SCALE_IQ, 00004DAB) ==>
>> -- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
>> -- [0/DDC_0] sr_write(N, 00000001) ==>
>> -- [0/DDC_0] sr_write(M, 00000001) ==>
>> -- [0/DDC_0] sr_write(CONFIG, 00000001) ==>
>> -- [0/DDC_0] sr_write(CORDIC_FREQ, 00000000) ==>
>> -- [0/DDC_0] sr_write(DECIM_WORD, 00000001) ==>
>> -- [0/DDC_0] sr_write(N, 00000001) ==>
>> -- [0/DDC_0] sr_write(M, 00000001) ==>
>> -- [0/DDC_0] sr_write(SCALE_IQ, 00004DAB) ==>
>> -- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
>> -- [0/DDC_0] sr_write(N, 00000001) ==>
>> -- [0/DDC_0] sr_write(M, 00000001) ==>
>> -- [0/DDC_0] sr_write(CONFIG, 00000001) ==>
>> -- [RFNOC] ------- Block Setup -----------
>> -- Setting up NoC-Shell Control for port #0 (SID: 00:09>02:80)...OK
>> -- Port 128: Found NoC-Block with ID DDC0000000000000.
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/ddc.xml
>> -- Setting up NoC-Shell Control for port #1 (SID: 00:0a>02:81)...OK
>> -- [RFNoC Factory] block_ctrl_base::make()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/ddc.xml
>> -- [RFNoC Factory] Using controller key 'DDC' and block name 'DDC'
>> -- block_ctrl_base()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/ddc.xml
>> -- Found valid blockdef
>> -- NOC ID: 0xDDC0000000000000 Block ID: 0/DDC_1
>> -- [0/DDC_1] block_ctrl_base::clear()
>> -- [0/DDC_1] node_ctrl_base::clear()
>> -- [0/DDC_1] block_ctrl_base::_clear()
>> -- [0/DDC_1] block_ctrl_base::_clear()
>> -- [0/DDC_1] Adding port definition at xbar/DDC_1/ports/in/0: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [0/DDC_1] Adding port definition at xbar/DDC_1/ports/in/1: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [0/DDC_1] Adding port definition at xbar/DDC_1/ports/out/0: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [0/DDC_1] Adding port definition at xbar/DDC_1/ports/out/1: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
>> -- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
>> -- [NocScript] Executing and asserting code: GE($fullscale, 0.0)
>> -- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
>> -- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
>> -- [NocScript] Executing and asserting code: GE($fullscale, 0.0)
>> -- [0/DDC_1] sr_write(CORDIC_FREQ, 00000000) ==>
>> -- [0/DDC_1] sr_write(DECIM_WORD, 00000001) ==>
>> -- [0/DDC_1] sr_write(N, 00000001) ==>
>> -- [0/DDC_1] sr_write(M, 00000001) ==>
>> -- [0/DDC_1] sr_write(SCALE_IQ, 00004DAB) ==>
>> -- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
>> -- [0/DDC_1] sr_write(N, 00000001) ==>
>> -- [0/DDC_1] sr_write(M, 00000001) ==>
>> -- [0/DDC_1] sr_write(CONFIG, 00000001) ==>
>> -- [0/DDC_1] sr_write(CORDIC_FREQ, 00000000) ==>
>> -- [0/DDC_1] sr_write(DECIM_WORD, 00000001) ==>
>> -- [0/DDC_1] sr_write(N, 00000001) ==>
>> -- [0/DDC_1] sr_write(M, 00000001) ==>
>> -- [0/DDC_1] sr_write(SCALE_IQ, 00004DAB) ==>
>> -- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
>> -- [0/DDC_1] sr_write(N, 00000001) ==>
>> -- [0/DDC_1] sr_write(M, 00000001) ==>
>> -- [0/DDC_1] sr_write(CONFIG, 00000001) ==>
>> -- [RFNOC] ------- Block Setup -----------
>> -- Setting up NoC-Shell Control for port #0 (SID: 00:0b>02:90)...OK
>> -- Port 144: Found NoC-Block with ID D0C0000000000000.
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/duc.xml
>> -- [RFNoC Factory] block_ctrl_base::make()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/duc.xml
>> -- [RFNoC Factory] Using controller key 'DUC' and block name 'DUC'
>> -- block_ctrl_base()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/duc.xml
>> -- Found valid blockdef
>> -- NOC ID: 0xD0C0000000000000 Block ID: 0/DUC_0
>> -- [0/DUC_0] block_ctrl_base::clear()
>> -- [0/DUC_0] node_ctrl_base::clear()
>> -- [0/DUC_0] block_ctrl_base::_clear()
>> -- [0/DUC_0] Adding port definition at xbar/DUC_0/ports/in/0: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [0/DUC_0] Adding port definition at xbar/DUC_0/ports/out/0: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
>> -- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
>> -- [NocScript] Executing and asserting code: GE($fullscale, 0.0)
>> -- [0/DUC_0] sr_write(CORDIC_FREQ, 00000000) ==>
>> -- [0/DUC_0] sr_write(INTERP_WORD, 00000001) ==>
>> -- [0/DUC_0] sr_write(N, 00000001) ==>
>> -- [0/DUC_0] sr_write(M, 00000001) ==>
>> -- [0/DUC_0] sr_write(SCALE_IQ, 00006DEE) ==>
>> -- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
>> -- [0/DUC_0] sr_write(N, 00000001) ==>
>> -- [0/DUC_0] sr_write(M, 00000001) ==>
>> -- [0/DUC_0] sr_write(CONFIG, 00000001) ==>
>> -- [RFNOC] ------- Block Setup -----------
>> -- Setting up NoC-Shell Control for port #0 (SID: 00:0c>02:a0)...OK
>> -- Port 160: Found NoC-Block with ID D0C0000000000000.
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/duc.xml
>> -- [RFNoC Factory] block_ctrl_base::make()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/duc.xml
>> -- [RFNoC Factory] Using controller key 'DUC' and block name 'DUC'
>> -- block_ctrl_base()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/duc.xml
>> -- Found valid blockdef
>> -- NOC ID: 0xD0C0000000000000 Block ID: 0/DUC_1
>> -- [0/DUC_1] block_ctrl_base::clear()
>> -- [0/DUC_1] node_ctrl_base::clear()
>> -- [0/DUC_1] block_ctrl_base::_clear()
>> -- [0/DUC_1] Adding port definition at xbar/DUC_1/ports/in/0: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [0/DUC_1] Adding port definition at xbar/DUC_1/ports/out/0: type =
>> 'sc16' pkt_size = '0' vlen = '0'
>> -- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
>> -- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
>> -- [NocScript] Executing and asserting code: GE($fullscale, 0.0)
>> -- [0/DUC_1] sr_write(CORDIC_FREQ, 00000000) ==>
>> -- [0/DUC_1] sr_write(INTERP_WORD, 00000001) ==>
>> -- [0/DUC_1] sr_write(N, 00000001) ==>
>> -- [0/DUC_1] sr_write(M, 00000001) ==>
>> -- [0/DUC_1] sr_write(SCALE_IQ, 00006DEE) ==>
>> -- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
>> -- [0/DUC_1] sr_write(N, 00000001) ==>
>> -- [0/DUC_1] sr_write(M, 00000001) ==>
>> -- [0/DUC_1] sr_write(CONFIG, 00000001) ==>
>> -- [RFNOC] ------- Block Setup -----------
>> -- Setting up NoC-Shell Control for port #0 (SID: 00:0d>02:b0)...OK
>> -- Port 176: Found NoC-Block with ID F1F0000000000000.
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
>> -- [RFNoC Factory] block_ctrl_base::make()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
>> -- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
>> -- block_ctrl_base()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
>> -- Found valid blockdef
>> -- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_0
>> -- [0/FIFO_0] block_ctrl_base::clear()
>> -- [0/FIFO_0] node_ctrl_base::clear()
>> -- [0/FIFO_0] block_ctrl_base::_clear()
>> -- [0/FIFO_0] Adding port definition at xbar/FIFO_0/ports/in/0: type =
>> '' pkt_size = '0' vlen = '0'
>> -- [0/FIFO_0] Adding port definition at xbar/FIFO_0/ports/out/0: type =
>> '' pkt_size = '0' vlen = '0'
>> -- [RFNOC] ------- Block Setup -----------
>> -- Setting up NoC-Shell Control for port #0 (SID: 00:0e>02:c0)...OK
>> -- Port 192: Found NoC-Block with ID F1F0000000000000.
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
>> -- [RFNoC Factory] block_ctrl_base::make()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
>> -- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
>> -- block_ctrl_base()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
>> -- Found valid blockdef
>> -- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_1
>> -- [0/FIFO_1] block_ctrl_base::clear()
>> -- [0/FIFO_1] node_ctrl_base::clear()
>> -- [0/FIFO_1] block_ctrl_base::_clear()
>> -- [0/FIFO_1] Adding port definition at xbar/FIFO_1/ports/in/0: type =
>> '' pkt_size = '0' vlen = '0'
>> -- [0/FIFO_1] Adding port definition at xbar/FIFO_1/ports/out/0: type =
>> '' pkt_size = '0' vlen = '0'
>> -- [RFNOC] ------- Block Setup -----------
>> -- Setting up NoC-Shell Control for port #0 (SID: 00:0f>02:d0)...OK
>> -- Port 208: Found NoC-Block with ID F1F0000000000000.
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
>> -- [RFNoC Factory] block_ctrl_base::make()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
>> -- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
>> -- block_ctrl_base()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
>> -- Found valid blockdef
>> -- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_2
>> -- [0/FIFO_2] block_ctrl_base::clear()
>> -- [0/FIFO_2] node_ctrl_base::clear()
>> -- [0/FIFO_2] block_ctrl_base::_clear()
>> -- [0/FIFO_2] Adding port definition at xbar/FIFO_2/ports/in/0: type =
>> '' pkt_size = '0' vlen = '0'
>> -- [0/FIFO_2] Adding port definition at xbar/FIFO_2/ports/out/0: type =
>> '' pkt_size = '0' vlen = '0'
>> -- [RFNOC] ------- Block Setup -----------
>> -- Setting up NoC-Shell Control for port #0 (SID: 00:10>02:e0)...OK
>> -- Port 224: Found NoC-Block with ID F1F0000000000000.
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
>> -- [RFNoC Factory] block_ctrl_base::make()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
>> -- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
>> -- block_ctrl_base()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
>> -- Found valid blockdef
>> -- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_3
>> -- [0/FIFO_3] block_ctrl_base::clear()
>> -- [0/FIFO_3] node_ctrl_base::clear()
>> -- [0/FIFO_3] block_ctrl_base::_clear()
>> -- [0/FIFO_3] Adding port definition at xbar/FIFO_3/ports/in/0: type =
>> '' pkt_size = '0' vlen = '0'
>> -- [0/FIFO_3] Adding port definition at xbar/FIFO_3/ports/out/0: type =
>> '' pkt_size = '0' vlen = '0'
>> -- [RFNOC] ------- Block Setup -----------
>> -- Setting up NoC-Shell Control for port #0 (SID: 00:11>02:f0)...OK
>> -- Port 240: Found NoC-Block with ID F1F0000000000000.
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
>> -- [RFNoC Factory] block_ctrl_base::make()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
>> -- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
>> -- block_ctrl_base()
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
>> -- Found valid blockdef
>> -- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_4
>> -- [0/FIFO_4] block_ctrl_base::clear()
>> -- [0/FIFO_4] node_ctrl_base::clear()
>> -- [0/FIFO_4] block_ctrl_base::_clear()
>> -- [0/FIFO_4] Adding port definition at xbar/FIFO_4/ports/in/0: type =
>> '' pkt_size = '0' vlen = '0'
>> -- [0/FIFO_4] Adding port definition at xbar/FIFO_4/ports/out/0: type =
>> '' pkt_size = '0' vlen = '0'
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>> _____________________________________________________
>> /
>> | Device: X-Series Device
>> | _____________________________________________________
>> | /
>> | | Mboard: X310
>> | | revision: 6
>> | | product: 30410
>> | | mac-addr0: 00:80:2f:21:37:a6
>> | | mac-addr1: 00:80:2f:21:37:a7
>> | | gateway: 192.168.10.1
>> | | ip-addr0: 192.168.10.3
>> | | subnet0: 255.255.255.0
>> | | ip-addr1: 192.168.20.2
>> | | subnet1: 255.255.255.0
>> | | ip-addr2: 192.168.30.2
>> | | subnet2: 255.255.255.0
>> | | ip-addr3: 192.168.40.2
>> | | subnet3: 255.255.255.0
>> | | serial: 30907F1
>> | | FW Version: 5.1
>> | | FPGA Version: 33.0
>> | | RFNoC capable: Yes
>> | |
>> | | Time sources: internal, external, gpsdo
>> | | Clock sources: internal, external, gpsdo
>> | | Sensors: ref_locked
>> | | _____________________________________________________
>> | | /
>> | | | RX Dboard: A
>> | | | _____________________________________________________
>> | | | /
>> | | | | RX Frontend: 0
>> | | | | Name: Unknown (0xffff) - 0
>> | | | | Antennas:
>> | | | | Sensors:
>> | | | | Freq range: 0.000 to 0.000 MHz
>> | | | | Gain Elements: None
>> | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
>> | | | | Connection Type: IQ
>> | | | | Uses LO offset: No
>> | | | _____________________________________________________
>> | | | /
>> | | | | RX Codec: A
>> | | | | Name: ads62p48
>> | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
>> | | _____________________________________________________
>> | | /
>> | | | RX Dboard: B
>> | | | ID: UBX-160 v1 (0x007a)
>> | | | Serial: 3090F8A
>> | | | _____________________________________________________
>> | | | /
>> | | | | RX Frontend: 0
>> | | | | Name: UBX RX
>> | | | | Antennas: TX/RX, RX2, CAL
>> | | | | Sensors: lo_locked
>> | | | | Freq range: 10.000 to 6000.000 MHz
>> | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
>> | | | | Bandwidth range: 160000000.0 to 160000000.0 step 0.0 Hz
>> | | | | Connection Type: IQ
>> | | | | Uses LO offset: No
>> | | | _____________________________________________________
>> | | | /
>> | | | | RX Codec: B
>> | | | | Name: ads62p48
>> | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
>> | | _____________________________________________________
>> | | /
>> | | | TX Dboard: A
>> | | | _____________________________________________________
>> | | | /
>> | | | | TX Frontend: 0
>> | | | | Name: Unknown (0xffff) - 0
>> | | | | Antennas:
>> | | | | Sensors:
>> | | | | Freq range: 0.000 to 0.000 MHz
>> | | | | Gain Elements: None
>> | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
>> | | | | Connection Type: IQ
>> | | | | Uses LO offset: No
>> | | | _____________________________________________________
>> | | | /
>> | | | | TX Codec: A
>> | | | | Name: ad9146
>> | | | | Gain Elements: None
>> | | _____________________________________________________
>> | | /
>> | | | TX Dboard: B
>> | | | ID: UBX-160 v1 (0x0079)
>> | | | Serial: 3090F8A
>> | | | _____________________________________________________
>> | | | /
>> | | | | TX Frontend: 0
>> | | | | Name: UBX TX
>> | | | | Antennas: TX/RX, CAL
>> | | | | Sensors: lo_locked
>> | | | | Freq range: 10.000 to 6000.000 MHz
>> | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
>> | | | | Bandwidth range: 160000000.0 to 160000000.0 step 0.0 Hz
>> | | | | Connection Type: QI
>> | | | | Uses LO offset: No
>> | | | _____________________________________________________
>> | | | /
>> | | | | TX Codec: B
>> | | | | Name: ad9146
>> | | | | Gain Elements: None
>> | | _____________________________________________________
>> | | /
>> | | | RFNoC blocks on this device:
>> | | |
>> | | | * DmaFIFO_0
>> | | | * Radio_0
>> | | | * Radio_1
>> | | | * sync_0
>> | | | * DDC_0
>> | | | * DDC_1
>> | | | * DUC_0
>> | | | * DUC_1
>> | | | * FIFO_0
>> | | | * FIFO_1
>> | | | * FIFO_2
>> | | | * FIFO_3
>> | | | * FIFO_4
>>
>> You can notice that this X310 device has only one db (UBX-160) in the B
>> slot, which I thought was the source of the problem. In that case I made
>> myself sure to select 'B' in the RFNoC:Radio Block, but the error kept
>> appearing.
>>
>> Just as a test, I tried the same flowgraph with the same .bit in another
>> computer (with the latest UHD, GNURadio and gr-ettus as well) that we
>> have at the lab and the same X310, so that I could check if the
>> enumeration of the daughterboards was being an issue. However in that
>> computer I can run the fg without any problem, even when selecting 'A'
>> in radio, where no db is present, which resulted even more confusing.
>>
>> Please let me know if there is any more information I can provide.
>>
>> - N
>> On 03.03.2017 01:55, Martin Braun via USRP-users wrote:
>>> Can you please post the output of uhd_usrp_probe?
>>>
>>> -- M
>>>
>>> On 03/01/2017 09:14 AM, Sebastian Mueller via USRP-users wrote:
>>>> Hi list,
>>>>
>>>> I'm currently trying to get a very basic RFNoC flowgraph running that
>>>> looks like this:
>>>>
>>>> [RFNoC: Radio] -> [RFNoC: DDC] -> [RFNoC: DmaFIFO] -> [QT GUI Frequency
>>>> Sink]
>>>>
>>>> When I try to run it, I get the following error:
>>>>
>>>> Traceback (most recent call last):
>>>> File "/home/user/src/rfnoc/examples/top_block.py", line 307, in <module>
>>>> main()
>>>> File "/home/user/src/rfnoc/examples/top_block.py", line 295, in main
>>>> tb = top_block_cls()
>>>> File "/home/user/src/rfnoc/examples/top_block.py", line 90, in __init__
>>>> 0, -1
>>>> File "/usr/local/lib/python2.7/dist-packages/ettus/ettus_swig.py",
>>>> line 2706, in make
>>>> return _ettus_swig.rfnoc_radio_make(dev, tx_stream_args,
>>>> rx_stream_args, radio_select, device_select)
>>>> RuntimeError: basic_string::_M_construct null not valid
>>>>
>>>> I have tried with Swig version 2.0.4 as well as 3.0.8 with the same
>>>> result. Also, I have switched DDC with DmaFIFO with no success.
>>>> UHD, gr-ettus and fpga are all newest versions from GitHub repos. Any
>>>> idea how I can fix this error?
>>>>
>>>> Cheers,
>>>> Sebastian
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/6d4e853f/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 26 Apr 2017 11:55:41 +0100
From: Derek Kozel <[email protected]>
To: Crozzoli Maurizio <[email protected]>
Cc: "[email protected]" <[email protected]>, Quasso
Roberto <[email protected]>
Subject: Re: [USRP-users] Install NFS server on E310
Message-ID:
<CAA+K=tu8hhskm5qbbyva3yw0qk85wvh4q8s3xfbtjp6gnqe...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Maurizio,
Could you use SCP instead of NFS? SSHFS would be an option as well.
The Linux environment of the E310 is created using the Yocto build system.
We supply an SDK which allows code, such as NFS utilities, to be cross
compiled and installed on the system.
Information about cross compiling and building full filesystem images can
be found at the following links.
https://kb.ettus.com/Software_Development_on_the_E310_and_E312
https://github.com/EttusResearch/e300-manifest/tree/Release-4
Regards,
Derek
On Wed, Apr 26, 2017 at 11:07 AM, Crozzoli Maurizio via USRP-users <
[email protected]> wrote:
> Hi!
>
> We need to install an NFS server on E310 (in order to get data out of it
> after their acquisition).
>
>
>
> Given that the Linux in the image provided by Ettus does not seem to be a
> Debian-like system, so no ?apt? tool seems to be available, we do not know
> how to proceed: could anyone suggest the easiest way out?
>
>
>
> TIA!
>
>
>
> BR,
>
> Maurizio.
>
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> * This e-mail and any attachments is confidential and may contain
> privileged information intended for the addressee(s) only. Dissemination,
> copying, printing or use by anybody else is unauthorised. If you are not
> the intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks. *
>
> *Rispetta l'ambiente. Non stampare questa mail se non ? necessario.*
>
> _______________________________________________
> 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/20170426/4b3d908d/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 26 Apr 2017 13:17:58 +0200
From: Nicolas Cuervo <[email protected]>
To: Haile Berhe <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] install gr-doa via pybombs - how?
Message-ID:
<caoupcvh9cqffvcq9u1g9zbozqdkcdapvxmtk8ygchb76csr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Haile,
it seems that there is no recipe (yet, I'm going to create one) for gr-doa
in the PyBombs recipes. You can however install it by hand:
For that, you need to install "Armadillo" in your system, as it is a basic
dependency (the testing and documentation dependencies are recommended as
well). Thereafter, you can follow the steps that are listed in the gr-doa
wiki [1]
For it to be installed into the PyBombs prefix of your choice, be sure to
tell CMake about it. I.e. instead of running only
$ cmake ..
you should run
$ cmake -DCMAKE_INSTALL_PREFIX=/path/to/your/prefix/ ..
and the rest of the steps should be followed as usual (you should not need
'sudo' for installing into your own pybombs prefix).
Regards,
- Nicolas
[1] https://github.com/EttusResearch/gr-doa
On Wed, Apr 26, 2017 at 11:20 AM, Haile Berhe via USRP-users <
[email protected]> wrote:
> Dear all,
> I have successfully installed gnuradio and many useful OOT modules using
> pybombs thanks to [1]. However, I could not install gr-doa in the same
> fashion I did to other OOT modules.
> When I run 'pybombs install gr-doa', pybombs display the following error:
> PyBOMBS.get_recipe - ERROR - Error fetching recipe `gr-doa':
> Package gr-doa has no recipe file!
> I don't want to risk my clean installation by trying to add recipe or
> something like that as the error suggests.
> Any suggestion please!
> Thanks
>
> Haile
>
> [1] https://www.gnuradio.org/blog/pybombs-the-what-the-how-and-the-why/
>
> _______________________________________________
> 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/20170426/d57468fb/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 26 Apr 2017 12:07:53 +0000
From: Crozzoli Maurizio <[email protected]>
To: "[email protected]" <[email protected]>
Cc: Quasso Roberto <[email protected]>, Derek Kozel
<[email protected]>
Subject: [USRP-users] R: Install NFS server on E310
Message-ID:
<f0e589d1410b43b79220b2c31d08775b@TELMBXD10BA020.telecomitalia.local>
Content-Type: text/plain; charset="utf-8"
Da: Derek Kozel [mailto:[email protected]]
Inviato: mercoled? 26 aprile 2017 12:56
A: Crozzoli Maurizio
Cc: [email protected]; Quasso Roberto
Oggetto: Re: [USRP-users] Install NFS server on E310
Hello Maurizio,
Could you use SCP instead of NFS? SSHFS would be an option as well.
We need to access our data on the E310 as a ?shared? directory so that we do
not need to copy/move (big) files around. That is why we were thinking of the
NFS way but any other suggestions which allow to avoid moving data around.
The Linux environment of the E310 is created using the Yocto build system. We
supply an SDK which allows code, such as NFS utilities, to be cross compiled
and installed on the system.
Information about cross compiling and building full filesystem images can be
found at the following links.
https://kb.ettus.com/Software_Development_on_the_E310_and_E312
https://github.com/EttusResearch/e300-manifest/tree/Release-4
Good to know. Not an easy task as installing an already built package. Let us
see what we can do. In the meantime, if already prepared recipes could be
suggested, they would be more than welcome.
Regards,
Derek
Thanks!
______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
Grazie.
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the sender
by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non ? necessario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/2fa141e5/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 26 Apr 2017 08:07:57 -0400
From: Philip Balister <[email protected]>
To: Derek Kozel <[email protected]>, Crozzoli Maurizio
<[email protected]>
Cc: Quasso Roberto <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Install NFS server on E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/26/2017 06:55 AM, Derek Kozel via USRP-users wrote:
> Hello Maurizio,
>
> Could you use SCP instead of NFS? SSHFS would be an option as well.
Also look into sshfs, I think you'll find it works better than NFS.
Philip
>
> The Linux environment of the E310 is created using the Yocto build system.
> We supply an SDK which allows code, such as NFS utilities, to be cross
> compiled and installed on the system.
> Information about cross compiling and building full filesystem images can
> be found at the following links.
>
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312
> https://github.com/EttusResearch/e300-manifest/tree/Release-4
>
> Regards,
> Derek
>
> On Wed, Apr 26, 2017 at 11:07 AM, Crozzoli Maurizio via USRP-users <
> [email protected]> wrote:
>
>> Hi!
>>
>> We need to install an NFS server on E310 (in order to get data out of it
>> after their acquisition).
>>
>>
>>
>> Given that the Linux in the image provided by Ettus does not seem to be a
>> Debian-like system, so no ?apt? tool seems to be available, we do not know
>> how to proceed: could anyone suggest the easiest way out?
>>
>>
>>
>> TIA!
>>
>>
>>
>> BR,
>>
>> Maurizio.
>>
>>
>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
>> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
>> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
>> abbiate ricevuto questo documento per errore siete cortesemente pregati di
>> darne immediata comunicazione al mittente e di provvedere alla sua
>> distruzione, Grazie.
>>
>> * This e-mail and any attachments is confidential and may contain
>> privileged information intended for the addressee(s) only. Dissemination,
>> copying, printing or use by anybody else is unauthorised. If you are not
>> the intended recipient, please delete this message and any attachments and
>> advise the sender by return e-mail, Thanks. *
>>
>> *Rispetta l'ambiente. Non stampare questa mail se non ? necessario.*
>>
>> _______________________________________________
>> 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: 18
Date: Wed, 26 Apr 2017 12:46:18 +0000
From: Crozzoli Maurizio <[email protected]>
To: "[email protected]" <[email protected]>
Cc: Quasso Roberto <[email protected]>, Derek Kozel
<[email protected]>, Philip Balister <[email protected]>
Subject: [USRP-users] R: Install NFS server on E310
Message-ID:
<da34e28595284aa3b17dd6095fa61c6d@TELMBXD10BA020.telecomitalia.local>
Content-Type: text/plain; charset="ISO-8859-1"
Also look into sshfs, I think you'll find it works better than NFS.
For sure we will give it a try!
I am just a bit worried that encryption could make data sharing a bit slower
but it is worth trying.
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
Grazie.
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the sender
by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non ? necessario.
------------------------------
Message: 19
Date: Wed, 26 Apr 2017 09:03:21 -0400
From: Philip Balister <[email protected]>
To: Crozzoli Maurizio <[email protected]>,
"[email protected]" <[email protected]>
Cc: Quasso Roberto <[email protected]>, Derek Kozel
<[email protected]>
Subject: Re: [USRP-users] R: Install NFS server on E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/26/2017 08:46 AM, Crozzoli Maurizio wrote:
> Also look into sshfs, I think you'll find it works better than NFS.
>
>
> For sure we will give it a try!
>
> I am just a bit worried that encryption could make data sharing a bit slower
> but it is worth trying.
NFS isn't so fast either :) Also, I'm pretty sure the E310 can mount a
remote NFS server, so you could compare speeds that way.
Philip
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the intended
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks.
>
> Rispetta l'ambiente. Non stampare questa mail se non ? necessario.
>
------------------------------
Message: 20
Date: Wed, 26 Apr 2017 15:16:38 +0200
From: Dominik Eyerly <[email protected]>
To: Michael West <[email protected]>
Cc: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] B205i transient behavior
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
Unfortunately, this did not resolve the issue. It seemed to have no
effect on the waveform. What else could be causing this behavior? Would
you be able to test this on a board you have available to rule out the
possibility that I have a bad batch?
cheers,
Dominik
On 04/25/2017 08:25 PM, Michael West wrote:
> Hi Dominik,
>
> To keep the PA on all the time on the B205mini, change STATE_OFF to
> TX_ENABLE1 on this line:
> https://github.com/EttusResearch/uhd/blob/maint/host/lib/usrp/b200/b200_impl.cpp#L1178
>
> I am still not convinced that is the main source of long ramp up in
> power. Some transient due to PA warm up is expected, but it is
> usually on the order of microseconds and not milliseconds.
>
> Regards,
> Michael
>
> On Mon, Apr 24, 2017 at 12:44 AM, Dominik Eyerly
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Michael,
>
> Would you be able to point out where in the code I need to make
> this modification to keep the PA on at all times? Padding with
> zeros is a very undesirable workaround for my application. I will
> set the tx gain down to minimize the switch isolation issue.
>
> Thanks,
> dominik
>
>
> On 04/15/2017 12:37 AM, Michael West wrote:
>> Hi Dominik,
>>
>> Creating the streamer connects the blocks in the FPGA, creates
>> the transports, and does some initialization for the stream. It
>> shouldn't (and probably doesn't) matter whether you create the
>> streamer or do the other operations first. I just recommend
>> creating the streamers first as a best practice to be on the safe
>> side.
>>
>> As for the PA, 100ms is longer than I would expect for the warm
>> up time. I suspect the slow rise is partially due to PA warm up,
>> but there may be other factors involved as well. I recommend
>> trying varying amounts of leading zeros to see what the minimum
>> amount is to see a clear signal. Keeping the PA on all the time
>> should be possible, but it will take UHD code changes and could
>> have side effects like higher noise on the RX side due to leakage
>> across the RF switch.
>>
>> Regards,
>> Michael
>>
>> On Wed, Apr 12, 2017 at 6:29 AM, Dominik Eyerly
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi Michael,
>>
>> Thank you for your response. Padding the end with zeros
>> clears some of the garbage that is played at the beginning of
>> the waveform.
>>
>> Creating the streams at the beginning should be no problem
>> for me. One follow up question, you mentioned explicitly to
>> create the streamer prior to tuning, setting bandwidth etc,
>> do these operations have a specific effect on the streamer?
>> Or in other words, what adverse effects, if any, exist if I
>> perform these operations before creating the streamer?
>>
>> As per the PA behavior, this is an issue that is extremely
>> undesirable for my application. I understand all PAs will
>> have some rise time, however, 100ms seems excessive. Is it
>> perhaps possible to power up the PA earlier via some
>> modification to the host / fpga code? Simply pre-pending
>> 100ms of zeros to my waveform won't work because I need the
>> waveform to play with minimal delay. I don't have any low
>> power constraints so it would not be a problem to keep the PA
>> permanently enabled, if that is possible.
>>
>> cheers,
>> dominik
>>
>> On 04/11/2017 08:40 PM, Michael West wrote:
>>> Hi Dominik,
>>>
>>> I can confirm that the creation of the streamers is very
>>> intrusive. It changes the active chains in the AD9364 and
>>> reconfigures the interface between the AD9364 and FPGA as
>>> Marcus has pointed out. For that reason, it is recommended
>>> to create all streamers before starting any streaming.
>>>
>>> Looking at the images you posted, the gap and first spur
>>> correlate to the creation of the TX streamer, so that should
>>> be eliminated if the streamers are created first. The next
>>> significant spur seems to align with the start of the TX
>>> streaming. My suspicion is that it is from garbage samples
>>> left in the DUC from initialization, but some testing is
>>> needed to prove that. Finally, the ramp and elevated power
>>> level during the transmission of the zeros is due to the TX
>>> PA being enabled when the stream starts.
>>>
>>> My suggestions:
>>>
>>> 1) Create the streamers right after creating the multi_usrp
>>> object (before any tuning, setting bandwidth, setting sample
>>> rate, etc...).
>>> 2) Pad the end of the TX burst with zeros. The first few
>>> samples transmitted are always the residual samples in the
>>> DUC. This means the last few samples of the burst will not
>>> actually make it to the AD9364 unless you pad with zeros to
>>> flush them. Zero padding the end of every burst will make
>>> sure all desired samples are transmitted and that the next
>>> burst will start by transmitting the residual zeros. The
>>> amount of the group delay will vary depending on master
>>> clock rate and sample rate, but it is usually on the order
>>> of a few to a couple hundred microseconds.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Tue, Apr 11, 2017 at 1:11 AM, Dominik Eyerly via
>>> USRP-users <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Hello,
>>>
>>> A couple of days has gone by so I wanted to follow up on
>>> my questions..
>>>
>>> /"OK, so, with the zeros, I think I understand what's
>>> going on. When you create a new streamer, the hardware
>>> has to be configured to the new state.//
>>> // In the case of the AD9361, this means the data path
>>> between the AD9361 and the FPGA, which unavoidably means
>>> that the RX samples are interrupted//
>>> // while the interface is reconfigured. I believe
>>> this is the reason for a lump of zeros when you
>>> configure for TX--someone in engineering can correct//
>>> // my understanding if it's wrong."/
>>>
>>> So this is confirmed behavior then? It is inherently due
>>> to the AD chip and not a bug in the code somewhere (host
>>> / fpga)?
>>>
>>> /"In terms of the rather-long transient time--is this
>>> only immediately after configuring the TX streamer, or
>>> for any TX burst? If it's just immediately//
>>> // after configuring a TX streamer, then this may be
>>> expected. If it's at the start of every burst, then
>>> something is very wrong. Again, I'm awaiting//
>>> // comment from someone in Ettus R&D."/
>>>
>>> This is at the start of _every_ burst that is initiated
>>> when rx is running. Even when the tx_streamer is kept
>>> alive. Have you had a chance to run my example program,
>>> or modify the existing loopback example in the way I
>>> described in my previous email to reproduce the issue? I
>>> don't believe I am doing something that is incorrect,
>>> however, if I am, I would be happy to have someone point
>>> out my mistake.
>>>
>>> Best regards,
>>> Dominik
>>>
>>>
>>> On 04/06/2017 05:51 PM, Marcus D. Leech wrote:
>>>> On 04/06/2017 05:07 AM, Dominik Eyerly wrote:
>>>>>
>>>>> I'm using 1M for both rx and tx. I've seen that
>>>>> example but it does not have the correct setup to
>>>>> display this behavior. As I mentioned before, the
>>>>> acquisition has to be running BEFORE transmit begins.
>>>>> In the example code there is no synchronization
>>>>> between rx start and tx start so you don't get to see
>>>>> the beginning of the transmit in the capture. I added
>>>>> a simple atomic bool to the example to ensure rx is
>>>>> running before tx starts. This is sufficient to
>>>>> display the issue. Also, the issue of having zeros in
>>>>> rx when creating a streamer will also not be displayed
>>>>> in this example code because the tx_streamer is
>>>>> created before the acquisition starts.
>>>>>
>>>>> Here is a plot of the txrx loopback example with my
>>>>> minor synchronization addition.
>>>>>
>>>>> http://imgur.com/a/0FjeI
>>>>>
>>>>> Would you be able to run the code that I posted in my
>>>>> previous email to see if you have the same issues on
>>>>> your end?
>>>>>
>>>>>
>>>>> cheers,
>>>>> dominik
>>>>>
>>>>>
>>>> OK, so, with the zeros, I think I understand what's
>>>> going on. When you create a new streamer, the hardware
>>>> has to be configured to the new state.
>>>> In the case of the AD9361, this means the data path
>>>> between the AD9361 and the FPGA, which unavoidably
>>>> means that the RX samples are interrupted
>>>> while the interface is reconfigured. I believe this
>>>> is the reason for a lump of zeros when you configure
>>>> for TX--someone in engineering can correct
>>>> my understanding if it's wrong.
>>>>
>>>>
>>>> In terms of the rather-long transient time--is this
>>>> only immediately after configuring the TX streamer, or
>>>> for any TX burst? If it's just immediately
>>>> after configuring a TX streamer, then this may be
>>>> expected. If it's at the start of every burst, then
>>>> something is very wrong. Again, I'm awaiting
>>>> comment from someone in Ettus R&D.
>>>>
>>>>
>>>>
>>>>> On 04/06/2017 04:10 AM, Marcus D. Leech wrote:
>>>>>> On 04/05/2017 10:18 AM, Dominik Eyerly wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> UHD: linux; GNU C++ version 5.2.1 20151005;
>>>>>>> Boost_106100; UHD_3.11.0.git-release, compiled for ARM
>>>>>>> B205 running on USB3.
>>>>>>>
>>>>>>> Doesn't matter if the port is terminated or if it
>>>>>>> has a signal, recv returns hard 0s, (not 1e-10 or
>>>>>>> the like) when a tx streamer is created. I've
>>>>>>> uploaded a simple bit of code that illustrates the
>>>>>>> behavior quite clearly.
>>>>>>>
>>>>>>> https://pastebin.com/ZAccunUe
>>>>>>>
>>>>>>> Please note that this code assumes you have 20dB of
>>>>>>> attenuation between rx and tx. However you can
>>>>>>> adjust the gain values appropriately if you do not.
>>>>>>>
>>>>>>> I compiled with: g++ streamissue.cpp -o streamtest
>>>>>>> -lboost_thread -lboost_system -luhd
>>>>>>>
>>>>>>> But honestly, this issue is not my primary concern.
>>>>>>> My primary concern is the ramp behavior. Note that
>>>>>>> the code I posted also illustrates the ramping
>>>>>>> behavior. For this it needs to be in loopback with
>>>>>>> 20dB attenuation (or more). I included a little
>>>>>>> helper function which performs a quick dump to a
>>>>>>> python file. If you have matplotlib for python you
>>>>>>> can uncomment the "dump_to_py" line in the rx thread
>>>>>>> and then simply run the generated file with python
>>>>>>> to see a quick plot of the iq data.
>>>>>>>
>>>>>>> What else could I do to further troubleshoot this?
>>>>>>>
>>>>>>> cheers,
>>>>>>> Dominik
>>>>>>>
>>>>>> There is an example program, called
>>>>>> txrx_loopback_to_file that does something similar
>>>>>> to your test.
>>>>>>
>>>>>> I wonder if it would be possible to do your tests
>>>>>> with that, and see if there is any change in behavior.
>>>>>>
>>>>>> Also, what sample rates are you using?
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On 04/05/2017 02:25 PM, Marcus D. Leech wrote:
>>>>>>>> On 04/05/2017 05:57 AM, Dominik Eyerly wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Thanks for the reply. I should add I am doing this
>>>>>>>>> test at 3.8G.
>>>>>>>>>
>>>>>>>>> Response to (A)
>>>>>>>>>
>>>>>>>>> Are you saying that regardless of my tx gain
>>>>>>>>> setting, I need 40dB of attenuation? I believe at
>>>>>>>>> max tx gain the board outputs around 10-15dBm
>>>>>>>>> @3.8G. I currently have a 6dB pad on tx port,
>>>>>>>>> cabled to a splitter which is cabled to the rx
>>>>>>>>> port with an inline 10dB pad. The other splitter
>>>>>>>>> port is going directly into my VSA. Also, my tx
>>>>>>>>> gain is around 50dB. My understanding was that the
>>>>>>>>> max input power of the rx port is -15dBm. With
>>>>>>>>> this configuration I should be well under that, as
>>>>>>>>> shown on my VSA capture (~-35dBm).
>>>>>>>>>
>>>>>>>>> Response to (B)
>>>>>>>>>
>>>>>>>>> According to the rough specifications posted here:
>>>>>>>>>
>>>>>>>>> https://kb.ettus.com/B200/B210/B200mini/B205mini#RF_Specifications
>>>>>>>>>
>>>>>>>>> <https://kb.ettus.com/B200/B210/B200mini/B205mini#RF_Specifications>
>>>>>>>>>
>>>>>>>>> The IIP3 is -15dBm. As you can see on my VSA
>>>>>>>>> capture, it received -35dBm and that doesn't even
>>>>>>>>> include the extra 10dB pad on the ettus rx port. I
>>>>>>>>> should be good on linearity, should I not? The
>>>>>>>>> reason the power capture looks so wavy is probably
>>>>>>>>> because I have the LO's tuned to the same spot.
>>>>>>>>> When I move tx off by 100kHz the capture looks
>>>>>>>>> "nicer" but the ramp up behavior is still there.
>>>>>>>>> Also, on the link I posted above, the max input
>>>>>>>>> power is called out as 0 dBm... is that correct?
>>>>>>>>>
>>>>>>>>> Could you provide some input on the questions I
>>>>>>>>> brought up in my previous email? Namely:
>>>>>>>>>
>>>>>>>>> (1) recv returning 0s when a tx_streamer is
>>>>>>>>> created while receiving continuously.
>>>>>>>>>
>>>>>>>> Could you try a simple experiment here? Place a
>>>>>>>> terminator on the input to the RX side, and see if
>>>>>>>> you get 0s in the recv buffer. I want to distinguish
>>>>>>>> between an analog situation and a digital one.
>>>>>>>>
>>>>>>>>> (2) The ramp up behavior that is only present when
>>>>>>>>> transmitting during an active acquisition.
>>>>>>>>>
>>>>>>>> That's odd. What version of UHD are you using?
>>>>>>>>
>>>>>>>>
>>>>>>>>> I also want to mention that the first burst of
>>>>>>>>> power in my captures coincides with changing the
>>>>>>>>> frequency of the tx LO. This triggers an internal
>>>>>>>>> calibration of the AD chip which in turn outputs
>>>>>>>>> this brief burst. So at least this mystery is
>>>>>>>>> solved. I am curious, however, is it possible to
>>>>>>>>> allow the chip to perform its cal without actually
>>>>>>>>> seeing this signal at the tx port?
>>>>>>>>>
>>>>>>>> I'm not certain of exactly how it performs its
>>>>>>>> calibration, but likely there will always be some
>>>>>>>> leakage when it is doing so.
>>>>>>>>
>>>>>>>>
>>>>>>>>> cheers,
>>>>>>>>> Dominik
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 04/04/2017 04:54 PM, [email protected]
>>>>>>>>> <mailto:[email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>> How are you doing the physical loop-back? If
>>>>>>>>>> directly-cabled, you'll need about 40dB of
>>>>>>>>>> attenuation in-line, to keep the receiver from:
>>>>>>>>>>
>>>>>>>>>> (A) Being damaged
>>>>>>>>>>
>>>>>>>>>> (B) Remaining linear
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2017-04-04 09:14, Dominik Eyerly via
>>>>>>>>>> USRP-users wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello all,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> My questions concern the B205i. I've uploaded
>>>>>>>>>>> some pictures to simplify the explaining process.
>>>>>>>>>>>
>>>>>>>>>>> http://imgur.com/a/XMAv6
>>>>>>>>>>>
>>>>>>>>>>> Basically, I want to transmit and receive a FSK
>>>>>>>>>>> waveform on one board (loopback). This means
>>>>>>>>>>> I've tuned both LOs to the same frequency. I've
>>>>>>>>>>> also inserted a splitter to be able to look at
>>>>>>>>>>> the signal on my VSA. This has allowed me to
>>>>>>>>>>> identify several problems.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Let's start on the left:
>>>>>>>>>>> (B205i Receive - no zeros)
>>>>>>>>>>> Here you see the received power drop from the
>>>>>>>>>>> noise floor to -infinity because the rx_streamer
>>>>>>>>>>> was returning 0's. I've tracked this problem to
>>>>>>>>>>> the creation of a tx_streamer while an
>>>>>>>>>>> acquisition is running. This seems completely
>>>>>>>>>>> unacceptable; that calling a command on a chain
>>>>>>>>>>> (tx) that has nothing to do with rx, has an
>>>>>>>>>>> effect on rx. I could understand that the sample
>>>>>>>>>>> rate performance of rx is affected because they
>>>>>>>>>>> share a communication link, but not to actually
>>>>>>>>>>> alter the data that is returned by the recv
>>>>>>>>>>> call. Is this a known bug? Is there a workaround
>>>>>>>>>>> other than "don't do that"? Is this bug slated
>>>>>>>>>>> for a fix next release?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Next:
>>>>>>>>>>> Right after all of the 0's, a strong but brief
>>>>>>>>>>> tone is blasted into the tx path. The power of
>>>>>>>>>>> this tone is not affected by the tx gain
>>>>>>>>>>> setting. This is quite a significant problem
>>>>>>>>>>> because we may use this module to test sensitive
>>>>>>>>>>> devices that may not be able to withstand such a
>>>>>>>>>>> transient. Any idea what is causing this? Again,
>>>>>>>>>>> any workarounds or fixes known?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I don't care much for the spur at -83dBm. But it
>>>>>>>>>>> would be interesting to understand it.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Lastly:
>>>>>>>>>>> The actual waveform is transmitted. Since this
>>>>>>>>>>> is an FSK waveform, I would expect a constant
>>>>>>>>>>> power envelope. Unfortunately, what I capture
>>>>>>>>>>> with the B205i is not even close. I performed
>>>>>>>>>>> the test again, but this time transmitting 200ms
>>>>>>>>>>> of 0s before my actual FSK waveform. You can
>>>>>>>>>>> still see the "warm up" looking behavior,
>>>>>>>>>>> however, by the time the actual waveform hits,
>>>>>>>>>>> the output seems settled. Is that what is
>>>>>>>>>>> happening (warm up)? Preloading every waveform
>>>>>>>>>>> with 200ms of zeroes is extremely undesirable.
>>>>>>>>>>> Is there a way to keep the chip always ready to
>>>>>>>>>>> go from both a Rx and Tx perspective?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Tx only with no zeros:
>>>>>>>>>>> I performed the no zeros test again, this time
>>>>>>>>>>> without doing an acquisition with the B205i. Now
>>>>>>>>>>> the warm up behavior is completely gone. Why is
>>>>>>>>>>> Rx influencing the Tx RF performance?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Any insight into these issues I am experiencing
>>>>>>>>>>> would be very appreciated.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Dominik
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> i.A. Dominik Eyerly
>>>>>>>>>>> Software
>>>>>>>>>>>
>>>>>>>>>>> Tel: +49 (0) 351 7958019 233
>>>>>>>>>>> <tel:+49%20351%207958019233>
>>>>>>>>>>> Fax: +49 (0) 351 7958019 232
>>>>>>>>>>> <tel:+49%20351%207958019232>
>>>>>>>>>>> Email: [email protected]
>>>>>>>>>>> <mailto:[email protected]>
>>>>>>>>>>>
>>>>>>>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>>>>>>>>>> Radolfzell*
>>>>>>>>>>> www.konrad-technologies.de
>>>>>>>>>>> <http://www.konrad-technologies.de>
>>>>>>>>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>>>>>>>>
>>>>>>>>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>>>>>>>>> <tel:+49%207732%209815100>*
>>>>>>>>>>> [email protected]
>>>>>>>>>>> <mailto:[email protected]>
>>>>>>>>>>> sig
>>>>>>>>>>> Gesch?ftsleitung: Michael Konrad
>>>>>>>>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>>>>>>>>> Ust-Id-Nr. DE 206693267
>>>>>>>>>>>
>>>>>>>>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle
>>>>>>>>>>> anh?ngenden Dokumente, enthalten Informationen der Konrad GmbH und
>>>>>>>>>>> sind nur f?r die adressierte Person bestimmt. Diese k?nnen
>>>>>>>>>>> vertraulich und/oder von Ver?ffentlichungen ausgenommen sein. Das
>>>>>>>>>>> Kopieren und die Weitergabe an nicht autorisierte Dritte sind
>>>>>>>>>>> verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht werden.
>>>>>>>>>>> Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den
>>>>>>>>>>> Absender bitte umgehend. Danke
>>>>>>>>>>>
>>>>>>>>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents
>>>>>>>>>>> which may accompany it, contains information from Konrad GmbH,
>>>>>>>>>>> which is intended only for the use of the individual or entity to
>>>>>>>>>>> which it is addressed, and which may contain information that is
>>>>>>>>>>> privileged, confidential, and/or otherwise exempt from disclosure
>>>>>>>>>>> under applicable law. If the reader of this message is not the
>>>>>>>>>>> intended recipient, any disclosure, dissemination, distribution,
>>>>>>>>>>> copying or other use of this communication or its substance is
>>>>>>>>>>> prohibited. If you have received this communication in error,
>>>>>>>>>>> please contact us immediately. Thank you.
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> USRP-users mailing list
>>>>>>>>>>> [email protected]
>>>>>>>>>>> <mailto:[email protected]>
>>>>>>>>>>>
>>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>>>
>>>>>>>>>>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> i.A. Dominik Eyerly
>>>>>>>>> Software
>>>>>>>>>
>>>>>>>>> Tel: +49 (0) 351 7958019 233
>>>>>>>>> <tel:+49%20351%207958019233>
>>>>>>>>> Fax: +49 (0) 351 7958019 232
>>>>>>>>> <tel:+49%20351%207958019232>
>>>>>>>>> Email: [email protected]
>>>>>>>>> <mailto:[email protected]>
>>>>>>>>>
>>>>>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>>>>>>>> Radolfzell*
>>>>>>>>> www.konrad-technologies.de
>>>>>>>>> <http://www.konrad-technologies.de>
>>>>>>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>>>>>>
>>>>>>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>>>>>>> <tel:+49%207732%209815100>*
>>>>>>>>> [email protected]
>>>>>>>>> <mailto:[email protected]>
>>>>>>>>> sig
>>>>>>>>> Gesch?ftsleitung: Michael Konrad
>>>>>>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>>>>>>> Ust-Id-Nr. DE 206693267
>>>>>>>>>
>>>>>>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle
>>>>>>>>> anh?ngenden Dokumente, enthalten Informationen der Konrad GmbH und
>>>>>>>>> sind nur f?r die adressierte Person bestimmt. Diese k?nnen
>>>>>>>>> vertraulich und/oder von Ver?ffentlichungen ausgenommen sein. Das
>>>>>>>>> Kopieren und die Weitergabe an nicht autorisierte Dritte sind
>>>>>>>>> verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht werden.
>>>>>>>>> Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
>>>>>>>>> bitte umgehend. Danke
>>>>>>>>>
>>>>>>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents
>>>>>>>>> which may accompany it, contains information from Konrad GmbH, which
>>>>>>>>> is intended only for the use of the individual or entity to which it
>>>>>>>>> is addressed, and which may contain information that is privileged,
>>>>>>>>> confidential, and/or otherwise exempt from disclosure under
>>>>>>>>> applicable law. If the reader of this message is not the intended
>>>>>>>>> recipient, any disclosure, dissemination, distribution, copying or
>>>>>>>>> other use of this communication or its substance is prohibited. If
>>>>>>>>> you have received this communication in error, please contact us
>>>>>>>>> immediately. Thank you.
>>>>>>> --
>>>>>>>
>>>>>>> --
>>>>>>> i.A. Dominik Eyerly
>>>>>>> Software
>>>>>>>
>>>>>>> Tel: +49 (0) 351 7958019 233
>>>>>>> <tel:+49%20351%207958019233>
>>>>>>> Fax: +49 (0) 351 7958019 232
>>>>>>> <tel:+49%20351%207958019232>
>>>>>>> Email: [email protected]
>>>>>>> <mailto:[email protected]>
>>>>>>>
>>>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>>>>>> Radolfzell*
>>>>>>> www.konrad-technologies.de
>>>>>>> <http://www.konrad-technologies.de>
>>>>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>>>>
>>>>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>>>>> <tel:+49%207732%209815100>*
>>>>>>> [email protected]
>>>>>>> <mailto:[email protected]>
>>>>>>> sig
>>>>>>> Gesch?ftsleitung: Michael Konrad
>>>>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>>>>> Ust-Id-Nr. DE 206693267
>>>>>>>
>>>>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle
>>>>>>> anh?ngenden Dokumente, enthalten Informationen der Konrad GmbH und sind
>>>>>>> nur f?r die adressierte Person bestimmt. Diese k?nnen vertraulich
>>>>>>> und/oder von Ver?ffentlichungen ausgenommen sein. Das Kopieren und die
>>>>>>> Weitergabe an nicht autorisierte Dritte sind verboten. F?r
>>>>>>> Zuwiderhandlungen k?nnen Sie haftbar gemacht werden. Falls Sie nicht
>>>>>>> der Empf?nger sind, benachrichtigen Sie den Absender bitte umgehend.
>>>>>>> Danke
>>>>>>>
>>>>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which
>>>>>>> may accompany it, contains information from Konrad GmbH, which is
>>>>>>> intended only for the use of the individual or entity to which it is
>>>>>>> addressed, and which may contain information that is privileged,
>>>>>>> confidential, and/or otherwise exempt from disclosure under applicable
>>>>>>> law. If the reader of this message is not the intended recipient, any
>>>>>>> disclosure, dissemination, distribution, copying or other use of this
>>>>>>> communication or its substance is prohibited. If you have received this
>>>>>>> communication in error, please contact us immediately. Thank you.
>>>>> --
>>>>>
>>>>> --
>>>>> i.A. Dominik Eyerly
>>>>> Software
>>>>>
>>>>> Tel: +49 (0) 351 7958019 233 <tel:+49%20351%207958019233>
>>>>> Fax: +49 (0) 351 7958019 232 <tel:+49%20351%207958019232>
>>>>> Email: [email protected]
>>>>> <mailto:[email protected]>
>>>>>
>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>>>> www.konrad-technologies.de
>>>>> <http://www.konrad-technologies.de>
>>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>>
>>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>>> <tel:+49%207732%209815100>*
>>>>> [email protected]
>>>>> <mailto:[email protected]>
>>>>> sig
>>>>> Gesch?ftsleitung: Michael Konrad
>>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>>> Ust-Id-Nr. DE 206693267
>>>>>
>>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle
>>>>> anh?ngenden Dokumente, enthalten Informationen der Konrad GmbH und sind
>>>>> nur f?r die adressierte Person bestimmt. Diese k?nnen vertraulich
>>>>> und/oder von Ver?ffentlichungen ausgenommen sein. Das Kopieren und die
>>>>> Weitergabe an nicht autorisierte Dritte sind verboten. F?r
>>>>> Zuwiderhandlungen k?nnen Sie haftbar gemacht werden. Falls Sie nicht der
>>>>> Empf?nger sind, benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>>
>>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which
>>>>> may accompany it, contains information from Konrad GmbH, which is
>>>>> intended only for the use of the individual or entity to which it is
>>>>> addressed, and which may contain information that is privileged,
>>>>> confidential, and/or otherwise exempt from disclosure under applicable
>>>>> law. If the reader of this message is not the intended recipient, any
>>>>> disclosure, dissemination, distribution, copying or other use of this
>>>>> communication or its substance is prohibited. If you have received this
>>>>> communication in error, please contact us immediately. Thank you.
>>> --
>>>
>>> --
>>>
>>> i.A. Dominik Eyerly
>>> Software
>>>
>>> Tel: +49 (0) 351 7958019 233 <tel:+49%20351%207958019233>
>>> Fax: +49 (0) 351 7958019 232 <tel:+49%20351%207958019232>
>>> Email: [email protected]
>>> <mailto:[email protected]>
>>>
>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>> www.konrad-technologies.de
>>> <http://www.konrad-technologies.de>
>>> www.abexstandard.org <http://www.abexstandard.org>
>>>
>>> *Support Telefon: +49 (0) 7732 9815 100
>>> <tel:+49%207732%209815100>*
>>> [email protected]
>>> <mailto:[email protected]>
>>> sig
>>> Gesch?ftsleitung: Michael Konrad
>>> Handelsregisternr: HRB 550593 in Freiburg
>>> Ust-Id-Nr. DE 206693267
>>>
>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle
>>> anh?ngenden Dokumente, enthalten Informationen der Konrad GmbH und sind nur
>>> f?r die adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind, benachrichtigen
>>> Sie den Absender bitte umgehend. Danke
>>>
>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may
>>> accompany it, contains information from Konrad GmbH, which is intended only
>>> for the use of the individual or entity to which it is addressed, and which
>>> may contain information that is privileged, confidential, and/or otherwise
>>> exempt from disclosure under applicable law. If the reader of this message
>>> is not the intended recipient, any disclosure, dissemination, distribution,
>>> copying or other use of this communication or its substance is prohibited.
>>> If you have received this communication in error, please contact us
>>> immediately. Thank you.
>>>
>>> _______________________________________________
>>> USRP-users mailing list [email protected]
>>> <mailto:[email protected]>
>>>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>>
>>>
>> --
>>
>> --
>>
>> i.A. Dominik Eyerly
>> Software
>>
>> Tel: +49 (0) 351 7958019 233 <tel:+49%20351%207958019233>
>> Fax: +49 (0) 351 7958019 232 <tel:+49%20351%207958019232>
>> Email: [email protected]
>> <mailto:[email protected]>
>>
>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>> www.konrad-technologies.de <http://www.konrad-technologies.de>
>> www.abexstandard.org <http://www.abexstandard.org>
>>
>> *Support Telefon: +49 (0) 7732 9815 100
>> <tel:+49%207732%209815100>*
>> [email protected]
>> <mailto:[email protected]>
>> sig
>> Gesch?ftsleitung: Michael Konrad
>> Handelsregisternr: HRB 550593 in Freiburg
>> Ust-Id-Nr. DE 206693267
>>
>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind, benachrichtigen
>> Sie den Absender bitte umgehend. Danke
>>
>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may
>> accompany it, contains information from Konrad GmbH, which is intended only
>> for the use of the individual or entity to which it is addressed, and which
>> may contain information that is privileged, confidential, and/or otherwise
>> exempt from disclosure under applicable law. If the reader of this message
>> is not the intended recipient, any disclosure, dissemination, distribution,
>> copying or other use of this communication or its substance is prohibited.
>> If you have received this communication in error, please contact us
>> immediately. Thank you.
>>
> --
>
> --
>
> i.A. Dominik Eyerly
> Software
>
> Tel: +49 (0) 351 7958019 233 <tel:+49%20351%207958019233>
> Fax: +49 (0) 351 7958019 232 <tel:+49%20351%207958019232>
> Email: [email protected]
> <mailto:[email protected]>
>
> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
> www.konrad-technologies.de <http://www.konrad-technologies.de>
> www.abexstandard.org <http://www.abexstandard.org>
>
> *Support Telefon: +49 (0) 7732 9815 100 <tel:+49%207732%209815100>*
> [email protected] <mailto:[email protected]>
> sig
> Gesch?ftsleitung: Michael Konrad
> Handelsregisternr: HRB 550593 in Freiburg
> Ust-Id-Nr. DE 206693267
>
> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an nicht
> autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar
> gemacht werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den
> Absender bitte umgehend. Danke
>
> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
> it, contains information from Konrad GmbH, which is intended only for the use
> of the individual or entity to which it is addressed, and which may contain
> information that is privileged, confidential, and/or otherwise exempt from
> disclosure under applicable law. If the reader of this message is not the
> intended recipient, any disclosure, dissemination, distribution, copying or
> other use of this communication or its substance is prohibited. If you have
> received this communication in error, please contact us immediately. Thank
> you.
>
>
--
--
i.A. Dominik Eyerly
Software
Tel: +49 (0) 351 7958019 233
Fax: +49 (0) 351 7958019 232
Email: [email protected]
<mailto:[email protected]>
*Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
www.konrad-technologies.de <http://www.konrad-technologies.de>
www.abexstandard.org <http://www.abexstandard.org>
*Support Telefon: +49 (0) 7732 9815 100*
[email protected] <mailto:[email protected]>
sig
Gesch?ftsleitung: Michael Konrad
Handelsregisternr: HRB 550593 in Freiburg
Ust-Id-Nr. DE 206693267
VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte Person
bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen ausgenommen
sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind
verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht werden. Falls Sie
nicht der Empf?nger sind, benachrichtigen Sie den Absender bitte umgehend. Danke
CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it,
contains information from Konrad GmbH, which is intended only for the use of
the individual or entity to which it is addressed, and which may contain
information that is privileged, confidential, and/or otherwise exempt from
disclosure under applicable law. If the reader of this message is not the
intended recipient, any disclosure, dissemination, distribution, copying or
other use of this communication or its substance is prohibited. If you have
received this communication in error, please contact us immediately. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/65291c1c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ddojlpbmdhnigbcj.png
Type: image/png
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/65291c1c/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/65291c1c/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/65291c1c/attachment-0001.asc>
------------------------------
Message: 21
Date: Wed, 26 Apr 2017 15:10:28 +0900
From: "=?UTF-8?B?7ISg6rK966+4?="<[email protected]>
To: <[email protected]>
Subject: [USRP-users] usrp b210 problem
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/bb257f7d/attachment-0001.html>
------------------------------
Message: 22
Date: Wed, 26 Apr 2017 10:25:50 +0000
From: Mihkel M <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B210 and Simulink sample times
Message-ID:
<he1pr0402mb2715312ab56b62d1aff5c567de...@he1pr0402mb2715.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello!
I am trying to generate GPS signals with USRP B210 SDR. I have made a source
"from workspace" where are values ones and zeros. There are 30690000 values,
with sample time 1/1023000, which is the GPS L1 signal rate (1,023 MHz). Next
block is "ideal rectangular pulse filter" with Pulse Length=4, which i have
left in from examples i have found online( i'm not sure, if i really need
this). Next block is BPSK modulator baseband with default settings. Next block
is "Buffer" with size 1000 and final block is "SDRu Transmitter", with
Fc-1575.42e6 Hz, LO offset-0 Hz, Gain-5 dB, Master Clock Rate- 20.95104e6 Hz,
Interpolation- 512 and everything else is default.
When i run the model, my GPS evaluation software (U-center) receives gibberish.
Intermittent signal and pseudo satellites. Occasionally, it finds the satellite
code, which i generate. (In the source block there is PRN #01 and NavData for
30 seconds)
My question is, that why my simulation transmits such gibberish signal? As far
as i have searched for this answer, the problem should be with mismatching
sample rates? Anyone could explain me, how the DSP and SDR Tx sample times are
related? How should i configure them? Also i have issues with running the
simulation in real time, as i need to acquire the generated signal with
u-center, where it should "see" legit GPS satellite information.
Mihkel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/b3bdcaed/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 80, Issue 26
******************************************
