date:20180420

Re: [USRP-users] RFNoC: FIR Filter final tap never gets written to settings register

2018-04-20 Thread Jon Pendlum via USRP-users

Hey Andrew,

The next line in fir_block_ctrl_impl.cpp sends the final tap:
sr_write(SR_RELOAD_TLAST, uint32_t(taps.back()));

The half a sample shift is odd though.

On Sat, Apr 21, 2018, 6:23 AM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 04/20/2018 12:01 PM, switchlanez via USRP-users wrote:
>
> Hello,
>
>
>
> An oddity regarding the RFNoC FIR Filter block. fir_block_ctrl_impl.cpp
> writes tap values to the settings registers with:
>
>
>
> for (size_t i = 0; i < taps.size() - 1; i++) {
> sr_write(SR_RELOAD, uint32_t(taps[i]));
>
> }
>
>
>
> which loops from 0 to taps.size() - 1. So if I define 41 taps from GRC, it
> only takes taps indexed from 0 to 39 and never writes tap index 40 (the
> 41st tap) to the settings register.
>
>
>
> I sort of confirmed this by comparing the RFNoC FIR Filter output
> against the GNU Radio Decimating FIR Filter (with Decimation=1) output with
> the same 41 taps and same input fed to both. Output gets shifted by half
> of a complex sample:
>
>
>
> GR FIR:
>
> 1 + .997j
>
> .994 + .991j
>
> .988 + ...
>
>
>
> RFNoC FIR:
>
> 0 + 1j
>
> .997 +.994j
>
> .991 + .988j
>
>
>
> Which is an effect of a FIR filter that has an even number of taps (40
> instead of 41).
>
>
>
> So I modified the condition in the FIR driver file to write from 0
> to taps.size() instead of taps.size()-1. Defined the 1st tap value to
> be 1000 with all remaining 40 taps as 0s. Viewed output on a spec an and
> saw nothing on output. Then moved the non-zero tap to the middle (21st
> index) with leading 20 and trailing 20 taps being 0s and saw the input fed
> to output. Now if I didn't modify the FIR driver file so it stops at
> taps.size()-1 and writes only 40 of my 41 taps and set the first tap to
> 1000 with 40 trailing zeros, I see input fed to output. Was the
> taps.size()-1 check intentional?
>
>
>
> Andrew
>
> This definitely looks to me like a subtle bug in the "off by one" error
> category.
>
> One of our RFNoC devs will probably chime in at this point, and provide an
> opinion
>
>
>
> ___
> 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: FIR Filter final tap never gets written to settings register

2018-04-20 Thread Marcus D. Leech via USRP-users


On 04/20/2018 12:01 PM, switchlanez via USRP-users wrote:


Hello,

An oddity regarding the RFNoC FIR Filter 
block. fir_block_ctrl_impl.cpp writes tap values to the settings 
registers with:


for (size_t i = 0; i < taps.size() - 1; i++) {
sr_write(SR_RELOAD, uint32_t(taps[i]));

}

which loops from 0 to taps.size() - 1. So if I define 41 taps from 
GRC, it only takes taps indexed from 0 to 39 and never writes tap 
index 40 (the 41st tap) to the settings register.


I sort of confirmed this by comparing the RFNoC FIR Filter output 
against the GNU Radio Decimating FIR Filter (with Decimation=1) output 
with the same 41 taps and same input fed to both. Output gets shifted 
by half of a complex sample:


GR FIR:

1 + .997j

.994 + .991j

.988 + ...

RFNoC FIR:

0 + 1j

.997 +.994j

.991 + .988j

Which is an effect of a FIR filter that has an even number of taps (40 
instead of 41).


So I modified the condition in the FIR driver file to write from 0 
to taps.size() instead of taps.size()-1. Defined the 1st tap value to 
be 1000 with all remaining 40 taps as 0s. Viewed output on a spec an 
and saw nothing on output. Then moved the non-zero tap to the middle 
(21st index) with leading 20 and trailing 20 taps being 0s and saw 
the input fed to output. Now if I didn't modify the FIR driver file so 
it stops at taps.size()-1 and writes only 40 of my 41 taps and set the 
first tap to 1000 with 40 trailing zeros, I see input fed to output. 
Was the taps.size()-1 check intentional?


Andrew


This definitely looks to me like a subtle bug in the "off by one" error 
category.


One of our RFNoC devs will probably chime in at this point, and provide 
an opinion




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] RFNoC: FIR Filter final tap never gets written to settings register

2018-04-20 Thread switchlanez via USRP-users

Hello,



An oddity regarding the RFNoC FIR Filter block. fir_block_ctrl_impl.cpp
writes tap values to the settings registers with:



for (size_t i = 0; i < taps.size() - 1; i++) {
sr_write(SR_RELOAD, uint32_t(taps[i]));

}



which loops from 0 to taps.size() - 1. So if I define 41 taps from GRC, it
only takes taps indexed from 0 to 39 and never writes tap index 40 (the
41st tap) to the settings register.



I sort of confirmed this by comparing the RFNoC FIR Filter output
against the GNU Radio Decimating FIR Filter (with Decimation=1) output with
the same 41 taps and same input fed to both. Output gets shifted by half
of a complex sample:



GR FIR:

1 + .997j

.994 + .991j

.988 + ...



RFNoC FIR:

0 + 1j

.997 +.994j

.991 + .988j



Which is an effect of a FIR filter that has an even number of taps (40
instead of 41).



So I modified the condition in the FIR driver file to write from 0
to taps.size() instead of taps.size()-1. Defined the 1st tap value to
be 1000 with all remaining 40 taps as 0s. Viewed output on a spec an and
saw nothing on output. Then moved the non-zero tap to the middle (21st
index) with leading 20 and trailing 20 taps being 0s and saw the input fed
to output. Now if I didn't modify the FIR driver file so it stops at
taps.size()-1 and writes only 40 of my 41 taps and set the first tap to
1000 with 40 trailing zeros, I see input fed to output. Was the
taps.size()-1 check intentional?



Andrew
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

2018-04-20 Thread switchlanez via USRP-users

I have an issue that may be related. Using LFTX and LFRX boards in an X310,
anytime I use the RFNoC Radio block in Rx mode the run terminates with:

terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at

Following for updates.

Andrew

On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Louis:
>
> Thanks for the detailed feedback. We have reproduced this issue, and are
> debugging it now. We will get back to you and post an update shortly.
>
> --Neel Pandeya
>
>
>
>
> On 12 April 2018 at 18:46, Louis Brown via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Could it be something to do with this commit for address offsets?
>>
>> https://github.com/EttusResearch/uhd/commit/8ee22529f33a63c2
>> 064b0dc6fbcc04c2ded94b4a
>>
>> Lou
>>
>>
>> On Apr 12, 2018, at 16:38, Louis Brown  wrote:
>>
>>
>> Did something change with respect to daughter board addressing in UHD
>> 3.11?
>> I have an X310 with LFTX and LFRX  in motherboard slot A.
>> When I run benchmark_rate it core dumps as follows:
>>
>> /*
>> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
>> "addr=192.168.40.2" --tx_rate=10E6
>>
>> [INFO] [UHD] linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5);
>> Boost_106400; UHD_3.11.0.1-0-unknown
>> [00:00:00.06] Creating the usrp device with: addr=192.168.40.2...
>> [INFO] [X300] X300 initialization sequence...
>> [INFO] [X300] Determining maximum frame size...
>> [INFO] [X300] Maximum frame size: 8000 bytes.
>> [INFO] [X300] Setup basic communication...
>> [INFO] [X300] Loading values from EEPROM...
>> [INFO] [X300] Setup RF frontend clocking...
>> [INFO] [X300] Radio 1x clock:200
>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0...
>> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1299 MB/s)
>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1...
>> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1302 MB/s)
>> [WARNING] [RFNOC] [0/Radio_0] defines 2 input buffer sizes, but 1 input
>> ports
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [WARNING] [RFNOC] [0/Radio_1] defines 2 input buffer sizes, but 1 input
>> ports
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [CORES] Performing timer loopback test...
>> [INFO] [CORES] Timer loopback test passed
>> [INFO] [CORES] Performing timer loopback test...
>> [INFO] [CORES] Timer loopback test passed
>> Using Device: Single USRP:
>> Device: X-Series Device
>> Mboard 0: X310
>> RX Channel: 0
>> RX DSP: 0
>> RX Dboard: A
>> RX Subdev: LFRX (AB)
>> RX Channel: 1
>> RX DSP: 0
>> RX Dboard: B
>> RX Subdev: Unknown (0x) - 0
>> TX Channel: 0
>> TX DSP: 0
>> TX Dboard: A
>> TX Subdev: LFTX (AB)
>> TX Channel: 1
>> TX DSP: 0
>> TX Dboard: B
>> TX Subdev: Unknown (0x) - 0
>>
>> [00:00:02.623786] Setting device timestamp to 0...
>> terminate called after throwing an instance of 'std::out_of_range'
>> what(): map::at
>> Aborted (core dumped)
>> */
>>
>>
>> If I specify tx_channels "1" it runs, lighting up the slot B TX/RX LED,
>> or course I have no boards installed there.
>>
>> /*
>> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
>> "addr=192.168.40.2" --tx_rate=100E6 --tx_channels "1"
>> */
>>
>> If I specify tx_channels "0" it core dumps with the same std::out_of_range
>>
>> Flow graphs that ran in UHD 3.10 with sub-device "A:AB" no longer run:
>>
>> /*
>> [INFO] [CORES] Timer loopback test passed
>> terminate called after throwing an instance of 'std::out_of_range'
>> what(): map::at
>> */
>>
>> If I try benchmark_rate with another X310 with the UBX card in slot A,
>> things work fine.  So maybe it's specific to the use of LF cards with UHD
>> 3.11.
>>
>> Thanks,
>> Lou
>>
>>
>>
>>
>> ___
>> 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

Re: [USRP-users] problem to work witth source file and RFnoC block and FIR block

2018-04-20 Thread switchlanez via USRP-users

Build should fail with 1000 coefficients and a Window Block instance. The
most taps I've gotten is 334 with a DUC and DDC instantiated along with the
FIR. If I instantiate 2 Digital Gain blocks with 2 FIR blocks, the most
taps I could build was 186 taps for each FIR. These were found through
trial and error.

Andrew

On Thu, Apr 19, 2018 at 9:48 PM, Jon Pendlum via USRP-users <
usrp-users@lists.ettus.com> wrote:

> > I want to use this block with 1,000 coefficients, but when I tried to do
> so
> > I saw that the maximum possible is only 41 coefficients.
> >
> > Does anybody know if Ettus has any solution to use FIR with 1,000
> > coefficients?
>
> The number of taps is an adjustable parameter in the FIR filter
> block's Verilog code. Take a look at noc_block_fir_filter.v. Be warned
> though, 1000 is a large number of taps and the build may fail.
>
> Jonathon
>
> ___
> 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] SDX 18.1.6 - RC3

2018-04-20 Thread Serge Malo via USRP-users

Hi all,

Please ignore this e-mail thread, it was unintentionally sent to usrp-users
by an "auto-completion" error.

Sorry for this,
Serge
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] DC Offset Calibration Issue for Rev. C UBX-40 daughter cards

2018-04-20 Thread Stanley, John P. via USRP-users

Thanks for the insight. Is this publicly documented anywhere? The USRP web 
manual (https://files.ettus.com/manual/page_calibration.html) still explicitly 
states to leave RF ports disconnected for calibration. Updating that page ASAP 
could save folks out there a lot of grief…

From: Michael West 
Date: Thursday, April 19, 2018 at 9:20 PM
To: "Stanley, John P." 
Cc: ROBIN TORTORA , "Stanley, John P. via USRP-users" 

Subject: Re: [USRP-users] DC Offset Calibration Issue for Rev. C UBX-40 
daughter cards

Hi John/Robin:
The calibration utilities rely on leakage across the RF switch.  The newer UBX 
boards (rev C and later) have RF switches with much higher isolation.  The 
benefit is a lot less leakage from TX onto RX.  The drawback is that the 
calibration utilities will only work if you connect the TX/RX to the RX2 port 
with a 30 dB attenuator in line.
Regards,
Michael

On Thu, Apr 19, 2018 at 11:12 AM, Stanley, John P. via USRP-users 
> wrote:
While uncalibrated LO leakage has never been great in the UBX for us, the dc 
offset calibration procedure has given us adequate enough improvement.  We’re 
generally using offset tuning, but we still need that extra 15-20 dB 
suppression we get from the calibration procedure.

The issue we’re seeing with these newer Rev C boards, though, is that the 
calibration doesn’t just fail to improve LO suppression; it actively makes it 
worse. Offset tuning is pretty fruitless when the LO spur alone is >0 dBm at 
the mid-point of available RF gain.

From: ROBIN TORTORA >
Reply-To: ROBIN TORTORA >
Date: Thursday, April 19, 2018 at 1:44 PM
To: "Stanley, John P. via USRP-users" 
>, "Stanley, John 
P." >
Subject: Re: [USRP-users] DC Offset Calibration Issue for Rev. C UBX-40 
daughter cards

___
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] DC Offset Calibration Issue for Rev. C UBX-40 daughter cards

2018-04-20 Thread The Tilla via USRP-users

Well, that is super awesome news 

Glad you guys made these improvements.

How would I know this, I don’t think I have seen this information anywhere?

From: Michael West  
Sent: Thursday, April 19, 2018 9:21 PM
To: Stanley, John P. 
Cc: ROBIN TORTORA ; Stanley, John P. via USRP-users 

Subject: Re: [USRP-users] DC Offset Calibration Issue for Rev. C UBX-40 
daughter cards

Hi John/Robin:

The calibration utilities rely on leakage across the RF switch.  The newer UBX 
boards (rev C and later) have RF switches with much higher isolation.  The 
benefit is a lot less leakage from TX onto RX.  The drawback is that the 
calibration utilities will only work if you connect the TX/RX to the RX2 port 
with a 30 dB attenuator in line.

Regards,

Michael

On Thu, Apr 19, 2018 at 11:12 AM, Stanley, John P. via USRP-users 
 > wrote:

While uncalibrated LO leakage has never been great in the UBX for us, the dc 
offset calibration procedure has given us adequate enough improvement.  We’re 
generally using offset tuning, but we still need that extra 15-20 dB 
suppression we get from the calibration procedure.

The issue we’re seeing with these newer Rev C boards, though, is that the 
calibration doesn’t just fail to improve LO suppression; it actively makes it 
worse. Offset tuning is pretty fruitless when the LO spur alone is >0 dBm at 
the mid-point of available RF gain. 

From: ROBIN TORTORA  >
Reply-To: ROBIN TORTORA  >
Date: Thursday, April 19, 2018 at 1:44 PM
To: "Stanley, John P. via USRP-users"  >, "Stanley, John P." 
 >
Subject: Re: [USRP-users] DC Offset Calibration Issue for Rev. C UBX-40 
daughter cards

___
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] SDX 18.1.6 - RC3

2018-04-20 Thread Serge Malo via USRP-users

Salut,

Voici la spread-sheet pour logguer vos résultats:
https://docs.google.com/spreadsheets/d/1ndyGP2aOAh4j8wHXpKN5hgqTBGn_ogYFJ6k329E-r9M/edit?usp=sharing

Merci !


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - -
*Serge Malo *
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com
Twitter: @skydelsol 

2018-04-19 17:10 GMT-04:00 Serge Malo :

> Salut,
>
> Voici SDX 18.1.6 RC3:
> Ubuntu: skydel-sdx-18.1.6-7aaee92-RC3.deb
> 
> Windows: (sera prêt dans 20 minutes)
>
> À mon avis, tout est prêt dans ce build pour la relâche.
> Voici les derniers "sanity" tests que j'aimerais qu'on fasse:
>
> (Serge) Replace sleeps with something that is not system-clock dependant
> 
> (Pierre-Marie): PPS out VS RF (Un seul cas à ton choix, pour s'assurer que
> mes mesures sont bonnes)
> (Yuri) Lock test sur Novatel, tous les signaux, Windows
> (Irène) Lock test sur Ubuntu, X300, U-Blox, tous les signaux L1
> (Julien) GPIO trigger out DLL (Windows)
> (Stéphane): Fixer le unit test fail (glonass)
> (Serge): CPU and Lock test with Dektec
>
> MERCI !
>
>
>
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - -
> *Serge Malo *
> CDO & Co-founder, Skydel Solutions
> Cell: 1-514-294-4017
> www.skydelsolutions.com
> Twitter: @skydelsol 
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Configuring FIR filters for b210

2018-04-20 Thread Victor Petrescu via USRP-users

Hi all.

I have a b210 device on which i want to make a transceiver. I managed to
replicate 15Mhz bandwidth, but now i want to configure the FIR filters, to
eliminate 10 Mhz from the bandwidth from RX and transmit only 5 Mhz on TX.

I tried to make a low pass filter, to configure the taps, using the scripts
from filter_tool, but the thing is that the filter is applied to the right
of the center frequency, but also to the left, it is just mirrored having
the center frequency as reference.

I want to know if is there any possibility to elimitate the filter from the
left size of the center frequency, or this is a result due to the existence
of two FIR filters, each one applied to I and Q paramters.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] UHD Open Source Method

2018-04-20 Thread Yeo Jin Kuang Alvin (IA) via USRP-users

Hi all,

I followed the ettus research guide 
https://kb.ettus.com/Building_and_Installing_the_USRP_Open_Source_Toolchain_(UHD_and_GNU_Radio)_on_Windows
 and start building the *ALL_Build* file. The error I keep getting is LNK1181 
cannot open input file '..\lib\Release\uhd.lib' . I checked the folder and it 
is empty, may I know how do I get the uhd.lib or what is the problem here that 
I am facing?

I am using boost_1_67_0_b1_rc2 (64 bit and version 14), libusb-1.0.21, 
UHD_3.10.1.1_release, Python 2.7, Mako and CMake 3.11.0. Windows 10, Visual 
Studio Community 2015. Is there something I missed out? Help would be 
appreciated.

Thanks in advance!
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC: FIR Filter final tap never gets written to settings register

Re: [USRP-users] RFNoC: FIR Filter final tap never gets written to settings register

[USRP-users] RFNoC: FIR Filter final tap never gets written to settings register

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

Re: [USRP-users] problem to work witth source file and RFnoC block and FIR block

Re: [USRP-users] SDX 18.1.6 - RC3

Re: [USRP-users] DC Offset Calibration Issue for Rev. C UBX-40 daughter cards

Re: [USRP-users] DC Offset Calibration Issue for Rev. C UBX-40 daughter cards

Re: [USRP-users] SDX 18.1.6 - RC3

[USRP-users] Configuring FIR filters for b210

[USRP-users] UHD Open Source Method

11 matches

Site Navigation

Mail list logo

Footer information