usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsRFNoC FFT questions
Hello,
I am working with a x310 + 2 twin RXes. For the time being, I have a single RFNoC radio hooked to a RFNoC FFT (1024 points FFT) hooked to a RFNoC keep 1 in N block (N=1000, vector length=1024). The keep one in N verilog code leads me to believe that it is possible to do this correctly because the code counts packets until t_last is received, which in the case of FFT block would be 1024 samples. Note that I have changed the MTU size on my Ethernet port on the host to be 9000 so as to allow for the jumbo FFT frame to come through.
Here is my test setup:
- B210 is supplying a tone at 300MHz going into each of the 4 channels I have on the x310
- My RFNoC flowgraph defaults the tune frequency to 300MHz
When the GUI comes up, the FFT output looks as expected. There are some jumps in the noise floor. But things look as they should, generally. As soon as I tune the radio by 1MHz, the FFT output looks incorrect. I collected a file at the output of the Keep one in N to demonstrate this. I am attaching the images for your perusal. Note, also, that if the actual signal from the B210 is shifted to 301MHz, while the x310 is tuned to 300MHz, the results do not change. Note also that I am not seeing any overruns or timeouts when I am running the flowgraph.
Could you please shed some light on why this might be happening and how I can fix the issue?
Thank you.
PV
-----Original Message-----
From: USRP-users [mailto:usrp-users-bounces@lists.ettus.com] On Behalf Of usrp-users-request@lists.ettus.com
Sent: Wednesday, April 12, 2017 12:00 PM
To: usrp-users@lists.ettus.com
Subject: USRP-users Digest, Vol 80, Issue 12
Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
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
usrp-users-request@lists.ettus.com
You can reach the person managing the list at
usrp-users-owner@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
- Problem with GPS strings from X310 (Andy Walls)
- Re: B205i transient behavior (Michael West)
- Re: has_time_spec latency (Martin Braun)
- Re: E312 fpga-src(3.9.2) synth_design failed when doing make
E310_sg3 (Martin Braun) - Re: Logging Cmds to Catch Errors in Real-Time (Martin Braun)
- Re: How to compile changed uhd example on the E310/E312?
(Martin Braun) - Re: DRAM BIST state machine is in a bad state on UHD 3.10
(Martin Braun) - Re: Setting radio clock source with RFNoC (Martin Braun)
- Re: The FPGA build is not compatible (Martin Braun)
- Re: x310 with LFTX & LFRX (Martin Braun)
- Re: behavior of N200 with clock source=mimo but no mimo cable
(Martin Braun) - Re: RF component behaviour during tx/rx in Ettus B210
(Martin Braun) - Re: X310 Twin RX coherence (Martin Braun)
- Re: Changing system date and time with burst transmission
(Martin Braun) - Re: Driver installation failure on Windows 10 (Martin Braun)
- Re: Issues with E3xx SDK (Martin Braun)
- Re: RuntimeError: basic_string::_M_construct null not valid
when using RFNoC:Radio (Martin Braun) - Re: Issues with E3xx SDK (Philip Balister)
- RFNoC syntax error in gnuradio's generated python file
(James Dunn) - Error after many small captures from X300 (Perelman, Nathan)
- Re: Error after many small captures from X300 (Jonathon Pendlum)
- Re: OFDM Synch not producing output (Jonathon Pendlum)
- Re: Testbench with payload data from file (Jonathon Pendlum)
- Re: OFDM Synch not producing output (Manik Singhal)
- Re: Testbench with payload data from file (Jonathon Pendlum)
- Re: cmake error on GnuRadio (for cross compiling) (ThongLeng)
- Re: has_time_spec latency (Francisco Paisana)
- How fast the E310 write data on sd (Disco Daniele)
- RFNoC and Vivado versions (Sumit Kumar)
- Re: B205i transient behavior (Dominik Eyerly)
- Re: Error after many small captures from X300 (Perelman, Nathan)
- Re: How fast the E310 write data on sd (mleech@ripnet.com)
Message: 1
Date: Tue, 11 Apr 2017 14:32:12 -0400
From: Andy Walls andy@silverblocksystems.net
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Problem with GPS strings from X310
Message-ID: 1491935532.26954.19.camel@localhost
Content-Type: text/plain; charset="UTF-8"
Hi:
I have an application that polls an X310, with an LC_XO GPSDO installed,
every second at 102 msec after the PPS, which comes to the host on the
DCD pin of an RS-232 port.
The polling code looks like this:
while (!d_finished) {
// Wait for the next PPS.
timeout_ts.tv_sec = 1;
timeout_ts.tv_nsec = 1000000; /* 1.001 seconds */
if (::time_pps_fetch(d_pps_handle, PPS_TSFMT_TSPEC, &pps_info, &timeout_ts) < 0) {
// stuff
}
// Measuring with an oscilloscope, we know that the X310's GPSDO has finished
// outputting its NMEA sentences over its serial port by 17 msec after the PPS edge.
// Let's wait to be sure the X310 has received it internally.
boost::this_thread::sleep(boost::posix_time::milliseconds(17 * 6));
uhd::sensor_value_t gps_time = d_uhd_dev->get_mboard_sensor("gps_time", 0);
uhd::sensor_value_t rmc_string = d_uhd_dev->get_mboard_sensor("gps_gprmc", 0);
uhd::sensor_value_t gga_string = d_uhd_dev->get_mboard_sensor("gps_gpgga", 0);
// stuff
}
With the latest libuhd, I get lots of
"[WARNING] [GPS] update_cache: Short GPSDO string: [...]"
or
"[WARNING] [GPS] update_cache: Malformed GPSDO string: [...]"
warnings, when this used to work, over a year ago.
I chased the problem down to the _recv() being changed to _recv(0) here:
https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/gps_ctrl.cpp#L147
When I change it back, things appear to work for me again.
For the X310, the host rxcache for the X310 uart doesn't get updated
when the host still has some cached data:
https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/x300/x300_fw_uart.cpp#L126
But an X310 read_uart(double timeout) call, with a timeout of 0, won't
loop around and force a cache update to pull in new characters, even if
the update_cache() call knew there were extra characters sitting in the
X310's ring buffer:
https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/x300/x300_fw_uart.cpp#L142
Can someone at Ettus address this, so I don't have to carry a patch to
libuhd?
I'm not quite sure if my change is the right change across all USRPs
with GPSDO's, so I don't want to issue a pull request myself.
Thanks.
Regards,
Andy Walls
Message: 2
Date: Tue, 11 Apr 2017 11:40:30 -0700
From: Michael West michael.west@ettus.com
To: Dominik Eyerly d.eyerly@konrad-technologies.de
Cc: "Marcus D. Leech" mleech@ripnet.com,
"USRP-users@lists.ettus.com" usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B205i transient behavior
Message-ID:
CAM4xKrorOYMqifT5kDp3kx75k=4dcXBJ1fZMRNpqhEN4-2BaaA@mail.gmail.com
Content-Type: text/plain; charset="utf-8"
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:
- Create the streamers right after creating the multi_usrp object (before
any tuning, setting bandwidth, setting sample rate, etc...). - 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 <
usrp-users@lists.ettus.com> 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.
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.
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, mleech@ripnet.com 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.
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: dominik.eyerly@konrad-technologies.de
Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzellwww.konrad-technologies.dewww.abexstandard.org
*Support Telefon: +49 (0) 7732 9815 100 <+49%207732%209815100>*support@konrad-technologies.de[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
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 <+49%20351%207958019233>
Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
Email: dominik.eyerly@konrad-technologies.de
Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzellwww.konrad-technologies.dewww.abexstandard.org
*Support Telefon: +49 (0) 7732 9815 100 <+49%207732%209815100>*support@konrad-technologies.de[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: dominik.eyerly@konrad-technologies.de
Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzellwww.konrad-technologies.dewww.abexstandard.org
*Support Telefon: +49 (0) 7732 9815 100 <+49%207732%209815100>*support@konrad-technologies.de[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: dominik.eyerly@konrad-technologies.de
Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzellwww.konrad-technologies.dewww.abexstandard.org
*Support Telefon: +49 (0) 7732 9815 100 <+49%207732%209815100>*support@konrad-technologies.de[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
Email: dominik.eyerly@konrad-technologies.de
Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzellwww.konrad-technologies.dewww.abexstandard.org
*Support Telefon: +49 (0) 7732 9815 100 <+49%207732%209815100>*support@konrad-technologies.de[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
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Hi Parth,
Try reducing your RX and/or TX gain. It is possible for the FFT to
internally overflow if it receives too large of an input. If that is the
issue, there is a way to adjust the FFT internal scaling to compensate.
Jonathon
On Wed, Apr 12, 2017 at 4:29 PM, Parth Vakil via USRP-users <
usrp-users@lists.ettus.com> wrote:
Hello,
I am working with a x310 + 2 twin RXes. For the time being, I have a
single RFNoC radio hooked to a RFNoC FFT (1024 points FFT) hooked to a
RFNoC keep 1 in N block (N=1000, vector length=1024). The keep one in N
verilog code leads me to believe that it is possible to do this correctly
because the code counts packets until t_last is received, which in the case
of FFT block would be 1024 samples. Note that I have changed the MTU size
on my Ethernet port on the host to be 9000 so as to allow for the jumbo FFT
frame to come through.
Here is my test setup:
- B210 is supplying a tone at 300MHz going into each of the 4 channels I
have on the x310 - My RFNoC flowgraph defaults the tune frequency to 300MHz
When the GUI comes up, the FFT output looks as expected. There are some
jumps in the noise floor. But things look as they should, generally. As
soon as I tune the radio by 1MHz, the FFT output looks incorrect. I
collected a file at the output of the Keep one in N to demonstrate this. I
am attaching the images for your perusal. Note, also, that if the actual
signal from the B210 is shifted to 301MHz, while the x310 is tuned to
300MHz, the results do not change. Note also that I am not seeing any
overruns or timeouts when I am running the flowgraph.
Could you please shed some light on why this might be happening and how I
can fix the issue?
Thank you.
PV
-----Original Message-----
From: USRP-users [mailto:usrp-users-bounces@lists.ettus.com] On Behalf Of
usrp-users-request@lists.ettus.com
Sent: Wednesday, April 12, 2017 12:00 PM
To: usrp-users@lists.ettus.com
Subject: USRP-users Digest, Vol 80, Issue 12
Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
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
usrp-users-request@lists.ettus.com
You can reach the person managing the list at
usrp-users-owner@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Problem with GPS strings from X310 (Andy Walls)
2. Re: B205i transient behavior (Michael West)
3. Re: has_time_spec latency (Martin Braun)
4. Re: E312 fpga-src(3.9.2) synth_design failed when doing make
E310_sg3 (Martin Braun)
5. Re: Logging Cmds to Catch Errors in Real-Time (Martin Braun)
6. Re: How to compile changed uhd example on the E310/E312?
(Martin Braun)
7. Re: DRAM BIST state machine is in a bad state on UHD 3.10
(Martin Braun)
8. Re: Setting radio clock source with RFNoC (Martin Braun)
9. Re: The FPGA build is not compatible (Martin Braun)
- Re: x310 with LFTX & LFRX (Martin Braun)
- Re: behavior of N200 with clock source=mimo but no mimo cable
(Martin Braun) - Re: RF component behaviour during tx/rx in Ettus B210
(Martin Braun) - Re: X310 Twin RX coherence (Martin Braun)
- Re: Changing system date and time with burst transmission
(Martin Braun) - Re: Driver installation failure on Windows 10 (Martin Braun)
- Re: Issues with E3xx SDK (Martin Braun)
- Re: RuntimeError: basic_string::_M_construct null not valid
when using RFNoC:Radio (Martin Braun) - Re: Issues with E3xx SDK (Philip Balister)
- RFNoC syntax error in gnuradio's generated python file
(James Dunn) - Error after many small captures from X300 (Perelman, Nathan)
- Re: Error after many small captures from X300 (Jonathon Pendlum)
- Re: OFDM Synch not producing output (Jonathon Pendlum)
- Re: Testbench with payload data from file (Jonathon Pendlum)
- Re: OFDM Synch not producing output (Manik Singhal)
- Re: Testbench with payload data from file (Jonathon Pendlum)
- Re: cmake error on GnuRadio (for cross compiling) (ThongLeng)
- Re: has_time_spec latency (Francisco Paisana)
- How fast the E310 write data on sd (Disco Daniele)
- RFNoC and Vivado versions (Sumit Kumar)
- Re: B205i transient behavior (Dominik Eyerly)
- Re: Error after many small captures from X300 (Perelman, Nathan)
- Re: How fast the E310 write data on sd (mleech@ripnet.com)
Message: 1
Date: Tue, 11 Apr 2017 14:32:12 -0400
From: Andy Walls andy@silverblocksystems.net
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Problem with GPS strings from X310
Message-ID: 1491935532.26954.19.camel@localhost
Content-Type: text/plain; charset="UTF-8"
Hi:
I have an application that polls an X310, with an LC_XO GPSDO installed,
every second at 102 msec after the PPS, which comes to the host on the
DCD pin of an RS-232 port.
The polling code looks like this:
while (!d_finished) {
// Wait for the next PPS.
timeout_ts.tv_sec = 1;
timeout_ts.tv_nsec = 1000000; /* 1.001 seconds */
if (::time_pps_fetch(d_pps_handle, PPS_TSFMT_TSPEC, &pps_info,
&timeout_ts) < 0) {
// stuff
}
// Measuring with an oscilloscope, we know that the X310's GPSDO
has finished
// outputting its NMEA sentences over its serial port by 17 msec
after the PPS edge.
// Let's wait to be sure the X310 has received it internally.
boost::this_thread::sleep(boost::posix_time::milliseconds(17 *
6));
uhd::sensor_value_t gps_time = d_uhd_dev->get_mboard_sensor("gps_time",
0);
uhd::sensor_value_t rmc_string = d_uhd_dev->get_mboard_sensor("gps_gprmc",
0);
uhd::sensor_value_t gga_string = d_uhd_dev->get_mboard_sensor("gps_gpgga",
0);
// stuff
}
With the latest libuhd, I get lots of
"[WARNING] [GPS] update_cache: Short GPSDO string: [...]"
or
"[WARNING] [GPS] update_cache: Malformed GPSDO string: [...]"
warnings, when this used to work, over a year ago.
I chased the problem down to the _recv() being changed to _recv(0) here:
https://github.com/EttusResearch/uhd/blob/master/
host/lib/usrp/gps_ctrl.cpp#L147
When I change it back, things appear to work for me again.
For the X310, the host rxcache for the X310 uart doesn't get updated
when the host still has some cached data:
https://github.com/EttusResearch/uhd/blob/master/
host/lib/usrp/x300/x300_fw_uart.cpp#L126
But an X310 read_uart(double timeout) call, with a timeout of 0, won't
loop around and force a cache update to pull in new characters, even if
the update_cache() call knew there were extra characters sitting in the
X310's ring buffer:
https://github.com/EttusResearch/uhd/blob/master/
host/lib/usrp/x300/x300_fw_uart.cpp#L142
Can someone at Ettus address this, so I don't have to carry a patch to
libuhd?
I'm not quite sure if my change is the right change across all USRPs
with GPSDO's, so I don't want to issue a pull request myself.
Thanks.
Regards,
Andy Walls
Message: 2
Date: Tue, 11 Apr 2017 11:40:30 -0700
From: Michael West michael.west@ettus.com
To: Dominik Eyerly d.eyerly@konrad-technologies.de
Cc: "Marcus D. Leech" mleech@ripnet.com,
"USRP-users@lists.ettus.com" usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B205i transient behavior
Message-ID:
<CAM4xKrorOYMqifT5kDp3kx75k=4dcXBJ1fZMRNpqhEN4-2BaaA@mail.
gmail.com>
Content-Type: text/plain; charset="utf-8"
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:
- Create the streamers right after creating the multi_usrp object (before
any tuning, setting bandwidth, setting sample rate, etc...). - 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 <
usrp-users@lists.ettus.com> 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.
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.
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, mleech@ripnet.com 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.
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: dominik.eyerly@konrad-technologies.de
Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzellwww.konrad-
technologies.dewww.abexstandard.org
*Support Telefon: +49 (0) 7732 9815 100 <+49%207732%209815100>*support
@konrad-technologies.de[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
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 <+49%20351%207958019233>
Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
Email: dominik.eyerly@konrad-technologies.de
Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzellwww.konrad-
technologies.dewww.abexstandard.org
*Support Telefon: +49 (0) 7732 9815 100 <+49%207732%209815100>*support
@konrad-technologies.de[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: dominik.eyerly@konrad-technologies.de
Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzellwww.konrad-
technologies.dewww.abexstandard.org
*Support Telefon: +49 (0) 7732 9815 100 <+49%207732%209815100>*support
@konrad-technologies.de[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: dominik.eyerly@konrad-technologies.de
Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzellwww.konrad-
technologies.dewww.abexstandard.org
*Support Telefon: +49 (0) 7732 9815 100 <+49%207732%209815100>*support
@konrad-technologies.de[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
Email: dominik.eyerly@konrad-technologies.de
Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzellwww.konrad-
technologies.dewww.abexstandard.org
*Support Telefon: +49 (0) 7732 9815 100 <+49%207732%209815100>*support
@konrad-technologies.de[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
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
On 04/12/2017 07:29 PM, Parth Vakil via USRP-users wrote:
Hello,
I am working with a x310 + 2 twin RXes. For the time being, I have a single RFNoC radio hooked to a RFNoC FFT (1024 points FFT) hooked to a RFNoC keep 1 in N block (N=1000, vector length=1024). The keep one in N verilog code leads me to believe that it is possible to do this correctly because the code counts packets until t_last is received, which in the case of FFT block would be 1024 samples. Note that I have changed the MTU size on my Ethernet port on the host to be 9000 so as to allow for the jumbo FFT frame to come through.
Here is my test setup:
- B210 is supplying a tone at 300MHz going into each of the 4 channels I have on the x310
- My RFNoC flowgraph defaults the tune frequency to 300MHz
When the GUI comes up, the FFT output looks as expected. There are some jumps in the noise floor. But things look as they should, generally. As soon as I tune the radio by 1MHz, the FFT output looks incorrect. I collected a file at the output of the Keep one in N to demonstrate this. I am attaching the images for your perusal. Note, also, that if the actual signal from the B210 is shifted to 301MHz, while the x310 is tuned to 300MHz, the results do not change. Note also that I am not seeing any overruns or timeouts when I am running the flowgraph.
Could you please shed some light on why this might be happening and how I can fix the issue?
Thank you.
PV
I have used the attached .grc to produce FFTs for radio astronomy
purposes--it delivers integrated FFTs to the host at a fairly-lazy rate
(100 FFT/second or so),
without sensitivity loss in the frequency domain.