[USRP-users] check_fpga_compat signature register readback failed
Hi,list today , I find a problem when run usrp b205mini: b200::check_fpga_compat signature register readback failed is the board go bad? Thanks! Carry ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Questions regarding BasicTX Daughterboard
Hua,
Yes to both questions.
If you drive a constant DC amplitude into a USRP sink in GR then you can
observe the frequency and phase of the FPGA “digital LO” on an oscilloscope
easily.
-ian
> On Nov 16, 2018, at 9:40 PM, Huacheng Zeng via USRP-users
> wrote:
>
> Dear All:
>
> I have some questions regarding BasicTX Daughterboard. It seems that this
> board does not have complex design such as analog mixer. But it can be set
> with a carrier frequency in GNU Radio. My questions are:
>
> 1) When I use this daughterboard and set its carrier frequency to nonzero
> (e.g., 50 MHz), is the frequency up-conversion done in the digital domain by
> the motherboard's FPGA?
>
> 2) If I use this daughterboard in IQ mode (i.e., setting frontend to AB),
> what are the output signal at antenna ports Tx-A and Tx-B? Denote S(t) as the
> digital baseband signal and fc as the carrier frequency specified in GNU
> Radio, are the output signals at Tx-A and Tx-B ports Re{S(t)}*cos(2*pi*fc*t)
> and Im{S(t)}*sin(2*pi*fc*t), respectively? If not, what is the output signals
> at those two antenna ports?
>
> Thank you in advance!
>
> Hua
>
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC FFT block scaling
Thanks. Much appreciated. Rob On Mon, Nov 19, 2018 at 2:54 PM Brian Padalino wrote: > On Mon, Nov 19, 2018 at 2:47 PM Rob Kossler via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi, >> Can anyone offer advice regarding the RFNoC FFT scaling argument? It is >> not clear to me if this argument should always be left alone or if it >> should be adjusted as needed by the user for various signal types and FFT >> lengths. I was expecting the latter, but my experimentation today gives me >> no confidence in doing so. >> >> The default value is 1706. I have been trying other values with bizarre >> results. Using the example "rfnoc_fft" that comes in the gr-ettus/examples >> folder, I get seemingly normal results with this set to 1706. But, if I >> change it to 1705, I get very strange behavior. And, look out if you >> choose 2048. See attached. In all cases, the signal source was a 125kHz >> exponential with Gaussian noise (which is the default behavior of this GR >> flowgraph). >> > > Look at the value in hex not decimal. It's telling the FFT algorithm > which stages to prune back the output. 1706 = 0x6aa = 0b011010101010. > > If you run with all 0's, you risk overflowing internally. An overflow > error comes out, but I am not sure it's captured really well with the FFT. > > If you want to be ultra conservative, then scale back every stage and you > won't get the integration gain that the FFT provides on the block size. > > It definitely does depend on the FFT length, but it seems like every other > stage with a radix-4 works decently well? > > It's the SCALE_SCH parameter in the IP block: > > > https://www.xilinx.com/support/documentation/ip_documentation/xfft/v9_0/pg109-xfft.pdf > > Hope this helps. Good luck! > > Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC FFT block scaling
On Mon, Nov 19, 2018 at 2:47 PM Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > Can anyone offer advice regarding the RFNoC FFT scaling argument? It is > not clear to me if this argument should always be left alone or if it > should be adjusted as needed by the user for various signal types and FFT > lengths. I was expecting the latter, but my experimentation today gives me > no confidence in doing so. > > The default value is 1706. I have been trying other values with bizarre > results. Using the example "rfnoc_fft" that comes in the gr-ettus/examples > folder, I get seemingly normal results with this set to 1706. But, if I > change it to 1705, I get very strange behavior. And, look out if you > choose 2048. See attached. In all cases, the signal source was a 125kHz > exponential with Gaussian noise (which is the default behavior of this GR > flowgraph). > Look at the value in hex not decimal. It's telling the FFT algorithm which stages to prune back the output. 1706 = 0x6aa = 0b011010101010. If you run with all 0's, you risk overflowing internally. An overflow error comes out, but I am not sure it's captured really well with the FFT. If you want to be ultra conservative, then scale back every stage and you won't get the integration gain that the FFT provides on the block size. It definitely does depend on the FFT length, but it seems like every other stage with a radix-4 works decently well? It's the SCALE_SCH parameter in the IP block: https://www.xilinx.com/support/documentation/ip_documentation/xfft/v9_0/pg109-xfft.pdf Hope this helps. Good luck! Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Bug in timed switching of sample rate
On 11/19/2018 06:35 AM, Fabian Schwartau via USRP-users wrote: Anyone? This is a quite annoying bug and I am having trouble working around it as I cannot meet my timing requirements. I'm only about 50% certain that sample-rate setting is covered by timed commands. I'll talk to R&D and get back to you on this. Am 20.07.2018 um 11:05 schrieb Fabian Schwartau via USRP-users: Hello everyone, I am experencing some issues when switching the sample rate. I have two synchronized USRP X310 with a total of 4 TwinRX. I am doing timed commands to jump around in the spectrum with all receivers at the same frequency (SIMO stuff). I also need to switch sample rates in between. When I keep the sample rate constant, everything works fine, but once I switch it between two timed receptions, I get very strange errors. Like I get an end-of-frame after just a part of the samples I requested. It seems like it is not possible to time the sample rate switch command. Here is a debug output of my code which makes it quite clear what happens: (1) Changed sample rate from 1e+07 to 5e+07 (2) Requested 32768 Samples (3) Requested 32768 Samples (4) Requested 32768 Samples (5) Changed sample rate from 5e+07 to 1e+07 (6) Reading 32768 Samples (7) Got only 6553 of 32768 samples at EOF Commands 1-5 are transmitted to the USRP right away using its command buffer. Then my program starts reading the first requested 32768 but gets only 6553, which is precisely 1/5th of the requested samples. I guess this is because he switched sample rate to 1/5th right before executing the first stream command. But the sample rate switch is also timed and should be executed after the three stream commands. I attached the part of the code which is responsible for sending the timed commands to the USRPs. This runs basically in a while(1) in a seperate thread, while there is a seconds thread receiving the data blocks, which produced the lines 6-7 of above output. Is this a bug or feature I don't get? Are set_rx_rate commands not timed when using set_command_time? How can I solve this isse? I need very precise timing and also fast switching between frequencies and sample rates. Best regards, Fabian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] RFNoC cannot keep up on large DDC deltas
I have a problem that I think I have a workaround for, but I would like to understand what is going on if I could. I am guessing that it is a DSPish issue with the way that the DDC is implemented, but I can't quite figure it out. My design had been working on an E310 and I was trying to move it over to the X310 and just kept running into issues. I finally narrowed it down to the large DDC delta. On the E310, I was taking a 45MHz sample rate and having an OOT sample rate of 50khz (I am re-tuning via the CORDIC as well so I can look at a signal of interest). I tried to bump up the sample rate some more, but it had issues. I ignored it at the time, but I have a feeling that it is because of the same issue. When I moved to the X310, I want to use the max sample rate I can, but because I was having issues, I dropped down to 120MHz and still had issues. Things would run for a bit, then I get the dreaded timeout 0 error and things are shot from there. Stumbling on a 3 year old post, it sent me down some different testing rabbit hole: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-September/043819.html So what I did was to have two DDCs and take the first from 120MHz down to 45MHz, and then the second from 45MHz to 50kHz. And low-and-behold, everything works again. So I can do this, but it certainly will start to increase the FPGA resource usage. In the end, I am thinking that it is what it is, but I would like to understand what is going on here. I was thinking that it probably has something to do with the larger drop needing to go through more paths and the buffers slowly fill up until it can't handle it anymore. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] X310, basicRX - using all channels in real mode with DDC
Hello, No ideas, advice or anything else to solve my problem? Thank Gwen On Tue, 6 Nov 2018 22:34:27 +0100 Gwenhael Goavec-Merou via USRP-users wrote: > On Tue, 06 Nov 2018 15:42:10 -0500 > "Marcus D. Leech" wrote: > > > On 11/06/2018 12:23 PM, Gwenhael Goavec-Merou wrote: > > > On Tue, 06 Nov 2018 12:09:02 -0500 > > > "Marcus D. Leech" wrote: > > > > > >> On 11/06/2018 10:24 AM, Gwenhael Goavec-Merou wrote: > > >>> On Tue, 06 Nov 2018 09:40:09 -0500 > > >>> "Marcus D. Leech via USRP-users" wrote: > > >>> > > On 11/06/2018 04:12 AM, Gwenhael Goavec-Merou via USRP-users wrote: > > > Hi, > > > > > > My environment is: > > > USRP: X310 with basicRX (currently one but 6 in a near future) > > > UHD: 3.13.1.0-rc1 > > > GNURadio: 3.7.13.4-r2 > > > gr-ettus: master branch, up to date > > > > > > I need to sample 4 real signal / USRP and to demodulate / decimate > > > before transfer to the PC. > > > > > > I have created a GNURadio flow with: > > > - 2 Radio (id 0 and 1), configured with 2 channels > > > - 2 DDC (id 0 and 1), with 2 channels, with a center frequency fixed > > > to XX MHz > > > - 4 complex To Real; > > > - 1 QT Gui with 4 inputs. > > > > > > Each channel of each radio is connected to an DDC input (radio0 > > > channel 0 to DDC0 input 0, radio0 channel 1 to DDC0 input 1, etc.) > > > > > > With this setup and with an input configured as XX + YY MHz (to have a > > > beatnote) I'm able to see a sinusoid on the qt for all channels (if I > > > plug / unplug an input signal the corresponding plot is equal to 0 or > > > displays the signal). > > > But: > > > 1/ the console panel display continuouly messages about channels > > > overrun 2/ the data flow is not continuous (visible in qt plot) (I > > > suppose is due to 1/ ) > > > 3/ channels are not aligned (I suppose is due to 1/ and/or 2/ > > > > > > Theorically, by reading HDL files for the X310 firmware it's seems > > > possible to use this configuration. > > > > > > Then, how to fix my issue? > > > - Is it a USRP/UHD limitation? > > > - gr-ettus seems not heavily upgraded, is something must be modified > > > in this repository? > > > - I am just wrong somewhere on my design? > > > > > > Thank you very much > > > > > > Gwen > > > > > What is the sample rate as delivered to the PC? What kind of PC? > > >>> The sample rate is 3MS/s for each channels after DDC (200MS/s before due > > >>> to the ADC). > > >>> My PC is a Lenovo thinkpad x230 with a 1Gb ethernet card. > > Overrun means that your PC isn't keeping up with the sample flow. > > > > >>> I've just done several test with only 2 channels : > > >>> - 2 radio, 1 channel/radio and 2 DDC with 1 input (first on radio0, a > > >>> second radio1) : > > >>> - data continuous (but not synchronized) > > >>> - no message on display panel > > >>> - 2 radio, 1 channel/radio and 1 DDC with 2 input : > > >>> - console panel displays continuouly "Ooverrun on chan 0" > > >>> - data not continuous > > >>> - after a short time : freeze > > >>> - 1 radio with 2 channels and 1 DDC with 2 input : > > >>> - console panel displays continuouly "Ooverrun on chan 0" and > > >>> "Ooverrun on chan 1" > > >>> - data not continuous. > > >>> - 1 radio with 2 channels and 2 DDC with 1 input : > > >>> - console panel displays continuouly "Ooverrun on chan 0" > > >>> - data not continuous. > > >>> > > >>> So, the first test seems to show it's possible with my computer to > > >>> receive 2 channel 3MS/s without overrun. Other tests seems to show a > > >>> problem for radio and/or for DDC to send or receive the full speed ADC > > >>> flow. > > >>> > > >>> Thank. > > >>> > > >>> Gwen > > >> The only immediate comment I have is that 3Msps is not a valid rate for > > >> the DDC with a 200Msps input--rates must be an integer fraction > > >> of the input sample rate. > > > Tested with 2Msps this the same result... > > >> It would be helpful if you shared your flow-graph for the cases that > > >> don't work. > > > joined > > > > > > Gwen > > Also, in your Radio BLock, you have "E310: 2 channels" selected, which > > very likely doesn't work with X310. > > > I've checked multiple time the flow-graph, top_block.py, do grep in gr-ettus, > uhd, gnuradio sources and I'm unable to find this option... Maybe we have > different version of one piece of code... > > I've forget to specify : to be able to select antennas according to basicRX > requierement (A or B) I've modified uhd_rfnoc_radio.xml to add this entry (I > must to sent a patch to fix this). > > Gwen > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/lis
[USRP-users] Increasing X310 command buffer
Hello everyone, is there a way to increase the number of timed commands the X310 can buffer at once? In the default firmware are only a few (can remember exactly, but I think like 5) commands in the queue at maximum which is not enough for my application. Or at least it would be much easier if the FPGA could hold like 10-20 commands. I hope I just have to change some constant in the code, synthesize it and bring it on the FPGA. Best regards, Fabian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Bug in timed switching of sample rate
Anyone? This is a quite annoying bug and I am having trouble working around it as I cannot meet my timing requirements. Am 20.07.2018 um 11:05 schrieb Fabian Schwartau via USRP-users: Hello everyone, I am experencing some issues when switching the sample rate. I have two synchronized USRP X310 with a total of 4 TwinRX. I am doing timed commands to jump around in the spectrum with all receivers at the same frequency (SIMO stuff). I also need to switch sample rates in between. When I keep the sample rate constant, everything works fine, but once I switch it between two timed receptions, I get very strange errors. Like I get an end-of-frame after just a part of the samples I requested. It seems like it is not possible to time the sample rate switch command. Here is a debug output of my code which makes it quite clear what happens: (1) Changed sample rate from 1e+07 to 5e+07 (2) Requested 32768 Samples (3) Requested 32768 Samples (4) Requested 32768 Samples (5) Changed sample rate from 5e+07 to 1e+07 (6) Reading 32768 Samples (7) Got only 6553 of 32768 samples at EOF Commands 1-5 are transmitted to the USRP right away using its command buffer. Then my program starts reading the first requested 32768 but gets only 6553, which is precisely 1/5th of the requested samples. I guess this is because he switched sample rate to 1/5th right before executing the first stream command. But the sample rate switch is also timed and should be executed after the three stream commands. I attached the part of the code which is responsible for sending the timed commands to the USRPs. This runs basically in a while(1) in a seperate thread, while there is a seconds thread receiving the data blocks, which produced the lines 6-7 of above output. Is this a bug or feature I don't get? Are set_rx_rate commands not timed when using set_command_time? How can I solve this isse? I need very precise timing and also fast switching between frequencies and sample rates. Best regards, Fabian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
