Re: [USRP-users] set_tx_freq is not functioning properly

[voonna santosh via USRP-users]

FYI:Does something like tx_waveforms[1] output a signal at the expected 
frequency? - Yes, both tx_wavefrom and benchmark_rate works fine. I took 
benchamark rate and extended it to get tx_freq configured. This is not working.

With respect to the 10MHz, this is the frequency of signals used to discipline 
the internal timebase to an external source. I wouldn't expect artifacts from 
this signal to be present at the TX port under normal circumstances. Are you 
using an external reference? What about the GPSDO? 
  - Since my base line is benchmark_rate, the default frequency is 10MHz which 
always works fine. But when I change the frequency, thats when I see the issue. 
I couldn't trace where it is getting set, but it does. Can you please let me 
know where in the code, it sets the frequency to 10MHz ? 

BR,Santosh





   On Tuesday, December 17, 2019, 11:45:29 PM GMT, Sam Reiter 
 wrote:  
 
 Does something like tx_waveforms[1] output a signal at the expected frequency?
What are you using to measure the frequency output?
With respect to the 10MHz, this is the frequency of signals used to discipline 
the internal timebase to an external source. I wouldn't expect artifacts from 
this signal to be present at the TX port under normal circumstances. Are you 
using an external reference? What about the GPSDO? 
[1] 
https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_waveforms.cpp

Sam Reiter Ettus Research

On Mon, Dec 16, 2019 at 9:01 AM voonna santosh via USRP-users 
 wrote:

Hi There,   I have bench marked X300 against my development PC. Then I took 
benchmark_rate code and modified a bit. Everything works fine except setting 
the center freq.   When ever I set the center frequency, there is no error 
returned by the call. But when I transmit the data, it doesn't appear in scope. 
Whenever I remove the code to set the center frequency, things work fine and I 
cann see a spike at 10Mhz which is default frequency I guess. Any clues?
std::cout << boost::format("Setting TX Freq: %f MHz...") % (freq/1e6) << 
std::endl;
uhd::tune_request_t tune_request(freq);
//usrp->set_tx_freq(tune_request, 0); - This line also doesn't work
usrp->set_tx_freq(freq, 0);
std::cout << boost::format("Actual TX Freq: %f MHz...") % 
(usrp->get_tx_freq(0)/1e6) << std::endl << std::endl;

Thanks and Regards
___
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] set_tx_freq is not functioning properly

[voonna santosh via USRP-users]

 One more thing to add:If I run benchmark_rate with out any modifications, then 
the output in scope if perfect. 

I have added the following code snippet to configure the tx_freq and there is 
nothing observed in scope.
if (vm.count("tx_freq")){
  for(size_t ch = 0; ch < tx_channel_nums.size(); ch++) {
    std::cout << boost::format("Setting TX Freq: %f MHz...") % 
(tx_freq/1e6) << std::endl;
    uhd::tune_request_t tune_request(tx_freq);
    if(vm.count("int-n")) tune_request.args = 
uhd::device_addr_t("mode_n=integer");
    usrp->set_tx_freq(tune_request, tx_channel_nums[ch]);
    std::cout << boost::format("Actual TX Freq: %f MHz...") % 
(usrp->get_tx_freq(tx_channel_nums[ch])/1e6) << std::endl << std::endl;
    }
}
Command used for testing: ./benchmark_rate --args="addr=192.168.40.2" 
--channels="0" --tx_rate 50e6 --tx_freq 20e6 --duration 50


NOTE: I am using Agilent E4402B to analyze the spectrum (9KHz to 3 GHz)

Thanks,Santosh





On Wednesday, December 18, 2019, 11:20:10 AM GMT, voonna santosh 
 wrote:  
 
 FYI:Does something like tx_waveforms[1] output a signal at the expected 
frequency? - Yes, both tx_wavefrom and benchmark_rate works fine. I took 
benchamark rate and extended it to get tx_freq configured. This is not working.

With respect to the 10MHz, this is the frequency of signals used to discipline 
the internal timebase to an external source. I wouldn't expect artifacts from 
this signal to be present at the TX port under normal circumstances. Are you 
using an external reference? What about the GPSDO? 
  - Since my base line is benchmark_rate, the default frequency is 10MHz which 
always works fine. But when I change the frequency, thats when I see the issue. 
I couldn't trace where it is getting set, but it does. Can you please let me 
know where in the code, it sets the frequency to 10MHz ? 

BR,Santosh





   On Tuesday, December 17, 2019, 11:45:29 PM GMT, Sam Reiter 
 wrote:  
 
 Does something like tx_waveforms[1] output a signal at the expected frequency?
What are you using to measure the frequency output?
With respect to the 10MHz, this is the frequency of signals used to discipline 
the internal timebase to an external source. I wouldn't expect artifacts from 
this signal to be present at the TX port under normal circumstances. Are you 
using an external reference? What about the GPSDO? 
[1] 
https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_waveforms.cpp

Sam Reiter Ettus Research

On Mon, Dec 16, 2019 at 9:01 AM voonna santosh via USRP-users 
 wrote:

Hi There,   I have bench marked X300 against my development PC. Then I took 
benchmark_rate code and modified a bit. Everything works fine except setting 
the center freq.   When ever I set the center frequency, there is no error 
returned by the call. But when I transmit the data, it doesn't appear in scope. 
Whenever I remove the code to set the center frequency, things work fine and I 
cann see a spike at 10Mhz which is default frequency I guess. Any clues?
std::cout << boost::format("Setting TX Freq: %f MHz...") % (freq/1e6) << 
std::endl;
uhd::tune_request_t tune_request(freq);
//usrp->set_tx_freq(tune_request, 0); - This line also doesn't work
usrp->set_tx_freq(freq, 0);
std::cout << boost::format("Actual TX Freq: %f MHz...") % 
(usrp->get_tx_freq(0)/1e6) << std::endl << std::endl;

Thanks and Regards
___
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] Building RFNoC Image with OOT Module on X310 - Module not found

[Felix Greiwe via USRP-users]

Hello together,

recently I installed the whole UHD/GNU-Radio Toolchain on a fresh install
of Kubuntu 18.04 LTS. I followed the instructions from
https://kb.ettus.com/Getting_Started_with_RFNoC_Development
and used the Pybombs install.

(I ran into a lot of problems there and had to install a lot of stuff
manually because most of the commands were not working properly. Maybe the
Pybombs Tutorial Section needs an update?)

Finally I managed to install it successfully and the command
uhd_config_version -- info prints: UHD 3.15.0.0-124-geb448043
(I also installed Vivado 2018.3 and added the License which seems to work.)

After the install I wanted to validate it by creating an OOT Module and
OOT Block named noc_block_checkdevprocess.v. I did not edit the Verilog
Code because I only wanted to know if I was able to build an Image
properly.
(I ran the default Testbench too, which worked without errors.)

The command to build my image is:

./uhd_image_builder.py checkdevprocess digital_gain -t X310_RFNOC_HG -d
X310 -I /home/lskt/rfnoc-blocks_lskt/rfnoc

with "rfnoc-blocks_lskt" beeing my OOT Module and "checkdevprocess" beeing
my  custom block.
(I also tried the paths home/lskt/rfnoc-blocks_lskt/rfnoc/;
home/lskt/rfnoc-blocks_lskt/; home/lskt/rfnoc-blocks_lskt/rfnoc/fpga-src )

Every single time I get the same error message:
ERROR: [Synth 8-439] module 'noc_block_checkdevprocess' not found
[/home/lskt/rfnoc/src/uhd-fpga/usrp3/top/x300/rfnoc_ce_auto_inst_x310.v:22]

and I don't know why.

I also tried the the uhd_image_builder_gui.py which did not even pop up
until I uncommented the Line at row 149. I can see my OOT Block here after
adding the Module in the gui, but it prints the same error message as the
non-gui version.

If you need further information to help please ask.

Any help is appreciated.

Felix





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

Re: [USRP-users] UHD Versions for N310

[Jeff S via USRP-users]

Just to kind of close out this thread since there wasn't an answer, I ended up 
installing the following version to a Virtualbox VM so I didn't mess up my X310 
environment I currently have.  The VM host version shows:

$ uhd_config_info --version
UHD 3.14.1.HEAD-0-g0347a6d8

I updated my SD card by using the "$ dd" method, then updated the image using 
the Mender method.  The N310 now has:

# uhd_config_info --version
UHD 3.14.1.1-0-g0347a6d8

Seemed to get the N310 up and running, although I'm not positive that's what I 
really wanted yet.  I'll have additional questions on another thread--I have no 
shortage of questions...

Jeff


From: USRP-users  on behalf of Jeff S via 
USRP-users 
Sent: Wednesday, December 11, 2019 7:04 AM
To: usrp-users@lists.ettus.com 
Subject: [USRP-users] UHD Versions for N310

For an X310, I am currently using:

$ uhd_config_info --version
UHD 4.0.0.rfnoc-devel-702-geec24d7b

I would like to update my N310 to the same version  as my X310 so I can use it 
in Network mode like the X310 without having multiple versions of UHD.  Since 
I've had some version configuration issues in the past, I thought I'd get a 
jump on it and ask before trying.

Will the above version work for my N310?

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

Re: [USRP-users] Api to call rfnoc split stream

[Ettus Research Support via USRP-users]

Hello Snehasish:

The Split Stream Block uses the generic block controller, so there should
not be anything "extra" that you have to do.

Are you getting any errors or warnings when you build your C++ program?

--Neel Pandeya



On Tue, Dec 17, 2019 at 1:00 PM Snehasish Kar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello
>
> Please let me know ho do we use the rfnoc split stream from C++ I am not
> able to find the concerned header file.
>
> Regards
> Snehasish
> ___
> 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] Xlating filter delay

[Angilberto Muniz Sb via USRP-users]

Hi all,
I have a dual tone signal that I down converte and split into two signals with 
a common frequency with the Xlating-fir filter. So far so good. 

However I noticed there is a phase shift between the signals generated (I 
assume this is due the filter delay). I have to compensate for that.
The question: How to determine or estimate that delay?
Thank you,

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

Re: [USRP-users] Pulsations on a QPSK transmission

[Sam Reiter via USRP-users]

Just to be clear, you see these pulsations when transmitting with a
b205mini, but *not* with the b210?

Is the b205mini a bare board or an industrial model with a case and
aluminum heat sync?

Sam Reiter
Ettus Research


On Wed, Dec 11, 2019 at 11:48 PM Геннадий Казачёк via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello!
> I'm trying to build QPSK based system on GNURadio.
> I'm using two USRP B205-mini boards as transmitter and receiver, also I
> got B210 board that I run gqrx on to watch what is really going on.
> I noticed a strange behaviour on my tests, so I began to investigate it
> and ended to a very simple graph, that is in attachment. On a frequencies
> that are multiple of 10Mhz, like 1020Mhz all works like expected and
> sonogram looks good. If I tune to any other frequency, even 1Hz more or
> less, the sonogram is full of pulsations and frequency of that pulsation is
> depends of exact tune frequency. I attached some screenshots of that
> pulsations.
> On receiving part that pulsations cause many errors while decoding.
> I got another board, LimeSDR-Mini, and no such behaviour observed while
> running graph on it.
> I wonder what is going on, and how can I fix this problem.
> Thank you.
> ___
> 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] Config USRP Source/Sink integer-N mode and timed commans via messages

[Lukas Haase via USRP-users]

Hi,

I just wanted to follow up on the question below.
I am currently (ab)using the "Function Probe" to execute the tuning code at the 
"Poll Rate". But I'd like to avoid this because it does not seem reliable.

My main concerns are (a) setting integer-N mode via the messages port and (b) 
obtaining the current USRP time (get_time_now) for the timed commands when 
using the message port.

If this is something that's just not possible, that would be a valuable answer 
as well.


Thanks,
Luke



> Gesendet: Freitag, 13. Dezember 2019 um 22:50 Uhr
> Von: "Lukas Haase" 
> An: usrp-users@lists.ettus.com
> Betreff: Config USRP Source/Sink integer-N mode and timed commans via messages
>
> Hi,
>
> The UHD interface supports messages to change center frequency etc [1].
> I would want to send the following commands via messages to the USRP Sink and 
> USRP Source, respectively:
>
> now = self.uhd_usrp_sink_0.get_time_now()
> timeStamp = now + uhd.time_spec(0.1)
>
> tune_req_tx = uhd.tune_request(fcenter-1e6, 1e6)
> tune_req_tx.args=uhd.device_addr(','.join(["mode_n=integer", 
> "int_n_step=1000e3",]))
> self.uhd_usrp_sink_0.set_command_time(timeStamp)
> res1 = self.uhd_usrp_sink_0.set_center_freq(  tune_req_tx, 0)
> self.uhd_usrp_sink_0.clear_command_time()
>
> tune_req_rx = uhd.tune_request(2*fcenter)
> tune_req_rx.args=uhd.device_addr(','.join(["mode_n=integer", 
> "int_n_step=1000e3",]))
> now = self.uhd_usrp_sink_0.get_time_now()
> self.uhd_usrp_source_0.set_command_time(timeStamp)
> res2 = self.uhd_usrp_source_0.set_center_freq(tune_req_rx, 0)
> self.uhd_usrp_source_0.clear_command_time()
>
> The first issue is that the "tune_request" described in [1] is a simple pair. 
> However, the real uhd::tune_request_t is more comprehensive and includes the 
> "args" element that I need to set to "mode_n=integer", "int_n_step=1000e3" 
> for integer N PLL.
>
> The second issue is the timed command. It seems usrp_block::set_command_time 
> translates into "time" with "timestamp" and usrp_block::clear_command_time 
> translates into "time" with PMT_NIL. However, how to I obtain the current UHD 
> time (uhd_usrp_sink_0.get_time_now)?
>
> Thanks,
> Luke
>
>
> [1] https://www.gnuradio.org/doc/doxygen/page_uhd.html




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

Re: [USRP-users] Pulsations on a QPSK transmission

[Геннадий Казачёк via USRP-users]

Hello, Sam!
No, I use two devices as transmitter and receiver and third board I use
just to observe sonogram.
Pulsations exist on both b205 and b210 devices if I use them as a
transmitter and not exist if I use as transmitter another vendor's device -
LimeSDR.

All 3 USRP devices are industrial with metal case, and LimeSDR is not.

On Wed, 18 Dec 2019 at 21:26, Геннадий Казачёк 
wrote:

> All 3 USRP devices are industrial with metal case, and LimeSDR is not.
>
> On Wed, 18 Dec 2019 at 21:25, Геннадий Казачёк 
> wrote:
>
>> Hello, Sam!
>> No, I use two devices as transmitter and receiver and third board I use
>> just to observe sonogram.
>> Pulsations exist on both b205 and b210 devices if I use them as a
>> transmitter and not exist if I use as transmitter another vendor's device -
>> LimeSDR.
>>
>> On Wed, 18 Dec 2019 at 18:49, Sam Reiter  wrote:
>>
>>> Just to be clear, you see these pulsations when transmitting with a
>>> b205mini, but *not* with the b210?
>>>
>>> Is the b205mini a bare board or an industrial model with a case and
>>> aluminum heat sync?
>>>
>>> Sam Reiter
>>> Ettus Research
>>>
>>>
>>> On Wed, Dec 11, 2019 at 11:48 PM Геннадий Казачёк via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hello!
 I'm trying to build QPSK based system on GNURadio.
 I'm using two USRP B205-mini boards as transmitter and receiver, also I
 got B210 board that I run gqrx on to watch what is really going on.
 I noticed a strange behaviour on my tests, so I began to investigate it
 and ended to a very simple graph, that is in attachment. On a frequencies
 that are multiple of 10Mhz, like 1020Mhz all works like expected and
 sonogram looks good. If I tune to any other frequency, even 1Hz more or
 less, the sonogram is full of pulsations and frequency of that pulsation is
 depends of exact tune frequency. I attached some screenshots of that
 pulsations.
 On receiving part that pulsations cause many errors while decoding.
 I got another board, LimeSDR-Mini, and no such behaviour observed while
 running graph on it.
 I wonder what is going on, and how can I fix this problem.
 Thank you.
 ___
 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] Xlating filter delay

[Marcus D Leech via USRP-users]

This is clearly a question for the discuss-GnURadio mailing list, not here. 

But there are delay blocks in GR. And you can effect a simple phase shift with 
a complex multiply. 

Sent from my iPhone

> On Dec 18, 2019, at 10:16 AM, Angilberto Muniz Sb via USRP-users 
>  wrote:
> 
> 
> Hi all,
> 
> I have a dual tone signal that I down converte and split into two signals 
> with a common frequency with the Xlating-fir filter. So far so good. 
> 
> However I noticed there is a phase shift between the signals generated (I 
> assume this is due the filter delay). I have to compensate for that.
> 
> The question: How to determine or estimate that delay?
> 
> Thank you,
> 
> Angilberto.
> ___
> 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] Api to call rfnoc split stream

[Snehasish Kar via USRP-users]

Ok that answers my question.

Regards
Snehasish

On 18-Dec-2019, at 7:55 PM, Ettus Research Support 
mailto:supp...@ettus.com>> wrote:

Hello Snehasish:

The Split Stream Block uses the generic block controller, so there should not 
be anything "extra" that you have to do.

Are you getting any errors or warnings when you build your C++ program?

--Neel Pandeya



On Tue, Dec 17, 2019 at 1:00 PM Snehasish Kar via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hello

Please let me know ho do we use the rfnoc split stream from C++ I am not able 
to find the concerned header file.

Regards
Snehasish
___
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] E312 RX_B issue

[Sam Reiter via USRP-users]

Isaac,

What version of UHD are you using to elicit this behavior?

Sam Reiter
Ettus Research


On Mon, Dec 9, 2019 at 9:21 PM Beeman, Isaac L. via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello group,
>
>
>
> I have run into an issue with the RX_B port (channel 1) on the E312 that I
> haven’t been able to make any sense of.
>
>
>
> RX_A (channel 0) works great: I get clear in-phase and quadrature
> components that I have been able to graph .
> When I do the same thing with RX_B (channel 1), I get something
> completely unexpected . I am using the same
> rate (=0.5 Msps) frequency (=900 MHz), gain (=50 dB), bandwidth (=200 kHz)
> on each and have had this happen whether I use both channels at the same
> time or read from RX_B individually.
>
>
>
> I haven’t had anything like this happen when I transmit on both TX_A and
> TX_B, and I have tested this on multiple USRP E312 radios and 900 MHz
> antennas to make sure it wasn’t something unrelated to the channel/port
> itself.
>
>
>
> Does anyone know what could be happening?
>
>
>
> -Isaac Beeman
> ___
> 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] DPDK build with N310

[Sam Reiter via USRP-users]

Hey Akis,

What version of DPDK are you using? What version of UHD do you have on the
host? I'm not sure that mode of failure is something I'd chalk up to the
DPDK install.

Could you give some detail on your config file, DPDK install version(s),
and hardware setup as well?

Best,

Sam Reiter
Ettus Research


On Mon, Dec 9, 2019 at 6:21 PM Akis Kourtis via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello all,
>
>
>
> I am trying to build the oai-5g-gNB. I have managed to build the DPDK with
> uhd successfully, however when I run the probe command I receive the
> following error.
>
>
>
> EAL: Starting I/O threads!
>
> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
> UHD_3.14.1.HEAD-0-g0347a6d8
>
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=10.30.0.218,type=n3xx,product=n310,serial=3177E48,claimed=False,addr=192.168.20.2,second_addr=192.168.20.2,use_dpdk=1
>
> [ERROR] [MPMD] No viable transport path found!
>
> [ERROR] [MPMD] Failure during block enumeration: RuntimeError: No viable
> transport path found!
>
> [INFO] [MPM.PeriphManager] init() called with device args
> `time_source=internal,clock_source=internal,second_addr=192.168.20.2,mgmt_addr=10.30.0.218,product=n310,use_dpdk=1'.
>
> [WARNING] [MPM.PeriphManager.UDP] Number of detected CHDR devices is
> inconsistent. Dropped from 1 to 0.
>
> [INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
>
> Error: RuntimeError: Failed to run enumerate_rfnoc_blocks()
>
>
>
> My guess from reading back posts from the forum, is that the proper DPDK
> file is not read.
>
> I can see a /etc/conf/uhd.conf file, but no /root/.uhd/uhd.conf file.
>
> Am I in the right direction, and if so, how do I enable the user conf file?
>
>
>
> If not, is there a direction I should head towards?
>
>
>
> Thank you,
>
>
>
> Akis
>
>
>
> *Akis Kourtis*
>
> M.Sc, Ph.D
>
> Research Associate
>
> Media Networks Laboratory
>
> Institute of Information & Telecommunications
>
> National Centre for Scientific Research “DEMOKRITOS”
>
>
>
> akis.kourtis@ iit.demokritos.gr
>
> +306948386769
>
> [image: engl LOGOTYPO XORIS ETHNOSIMO ME DIEYTHINSI_3]
>
>
> ___
> 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] Xlating filter delay

[Angilberto Muniz Sb via USRP-users]

Oops!, sent to wrong list -- sorry...

Angilberto. 92-9-8151-3151 

On Wednesday, December 18, 2019, 3:29:43 PM GMT-3, Marcus D Leech 
 wrote:  
 
 This is clearly a question for the discuss-GnURadio mailing list, not here. 
But there are delay blocks in GR. And you can effect a simple phase shift with 
a complex multiply. 

Sent from my iPhone

On Dec 18, 2019, at 10:16 AM, Angilberto Muniz Sb via USRP-users 
 wrote:



Hi all,
I have a dual tone signal that I down converte and split into two signals with 
a common frequency with the Xlating-fir filter. So far so good. 

However I noticed there is a phase shift between the signals generated (I 
assume this is due the filter delay). I have to compensate for that.
The question: How to determine or estimate that delay?
Thank you,

Angilberto.___
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