Re: [Discuss-gnuradio] how to resolve the uhd warning of sample rate

[Marcus Müller]

Hi Alok,

usually, it should say something like "actual sampling rate: XXX". What
does it say? (actually, can you just copy&paste the whole warning?)

What program are you passing "-r" to?

Greetings,
Marcus

On 11/28/2014 08:57 AM, alok ranjan wrote:
> Dear All,
>
>
> I am using USRP1 having RF daughterboards WBX (50Mhz -2.2Ghz).  I have 
> gone through some basic details of the USRP1 product features but dont 
> know how to resolve the errors oh UHD warning saying the hardware 
> doesnot support the  target tx sample rate and same for the rx also.
>
>
> Below is the USRP1 supported features :
>
> ADC sample rate: 64MS/s
> DAC sample rate:128MS/s
> Host sample rate: 8 for usb2
> FPGA clock rate: 64Mhz
>
> Please help me to understand that what value of -r i should pass for the both 
> tx and for rx.
>
> I
>  have tried with -r 250e3 and 125e3 but it could not work and popping 
> the warning that target tx and rx rate is not supported by hardware.
>
> Thank you.  
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] how to resolve the uhd warning of sample rate

[Marcus Müller]

Hello Alok,

the problem here is that you implicitly request a lower sampling rate
than your USRP is able to provide:
"-r 250e3" specifies the bit rate. For "-m qam" (with a default number
of constellation points (-p) of 16=2^4) this means that the symbol rate
is 1/4 of that,
(250e3 b/s) / (4 b/sym) = 62500 sym/s. Now, the default setting for
samples per symbols (-S) is 2, so that you get 125e3 S/s, which is half
of what you can minimally do with your USRP.
You can either use a constellation with less points, increase your bit
rate, or increase your samples per symbol.

Greetings,
Marcus


PS: can you please generally reply to the mailing list and not to people
individually? It's a bit hard for me to keep track of this, and it might
be really frustrating for the others that follow these lists ;)


On 11/28/2014 11:20 AM, alok ranjan wrote:
> Hello Marcus,
>
> Thank you for your quick response.
>
> I am running the benchmark_tx.py and benchmark_rx.py for transmission and 
> reception. Below is the details what i am getting :
>
>
> python benchmark_tx.py -f 986M -m qam -r 250e3 -A TX/RX --tx-gain=30 -a 
> serial=49270a48
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.002-0-unknown
>
> Using Volk machine: sse4_2_64_orc
> -- Opening a USRP1 device...
> -- Using FPGA clock rate of 64.00MHz...
>
> UHD Warning:
> The hardware does not support the requested TX sample rate:
> Target sample rate: 0.125000 MSps
> Actual sample rate: 0.25 MSps
>
> Symbol Rate: 62500.00
> Requested sps:   2.00
> Given sample rate:   25.00
> Actual sps for rate: 4.00
>
> Requested sample rate: 125000.00
> Actual sample rate: 25.00
>
> Looking forward for your response.
>
> Regards!!
> Alok
>
>
>
>
>> Date: Fri, 28 Nov 2014 10:29:39 +0100
>> To: usrp-us...@lists.ettus.com
>> Subject: Re: [USRP-users] [Discuss-gnuradio] how to resolve the uhd warning  
>> of sample rate
>> From: usrp-us...@lists.ettus.com
>>
>> Hi Alok,
>>
>> usually, it should say something like "actual sampling rate: XXX". What
>> does it say? (actually, can you just copy&paste the whole warning?)
>>
>> What program are you passing "-r" to?
>>
>> Greetings,
>> Marcus
>>
>> On 11/28/2014 08:57 AM, alok ranjan wrote:
>>> Dear All,
>>>
>>>
>>> I am using USRP1 having RF daughterboards WBX (50Mhz -2.2Ghz).  I have 
>>> gone through some basic details of the USRP1 product features but dont 
>>> know how to resolve the errors oh UHD warning saying the hardware 
>>> doesnot support the  target tx sample rate and same for the rx also.
>>>
>>>
>>> Below is the USRP1 supported features :
>>>
>>> ADC sample rate: 64MS/s
>>> DAC sample rate:128MS/s
>>> Host sample rate: 8 for usb2
>>> FPGA clock rate: 64Mhz
>>>
>>> Please help me to understand that what value of -r i should pass for the 
>>> both tx and for rx.
>>>
>>> I
>>>  have tried with -r 250e3 and 125e3 but it could not work and popping 
>>> the warning that target tx and rx rate is not supported by hardware.
>>>
>>> Thank you.
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> ___
>> USRP-users mailing list
>> usrp-us...@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Latency of tcpip transmission

[zs]

Hi all:
 Thank you in advance.
 Environment: gnuradio 3.7.5
 The picture below shows the received signal.I will try my best to 
explain my problem.I use one usrp N210 to send signal and the other usrp 
receive the signal and then transmit the message by the tcpip to the 
transmitter.Then the transmitter re-send signal again.I think the way of tcpip 
transmission is so fast.But it has the latency as the below picture shows.Have 
some ideas to solve it?And have some tools in grc to solve it?Thanks so 
much.(the signal inside the blue circle while the latency is interval of 
signal).
Best regards,

xd


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Latency of tcpip transmission

[Marcus Müller]

Hello xd,

You're expecting us to guess what you know:
What are we seeing in that diagram? What are the axes and how are they
scaled? Also: some information of message length, the amount of data
you  need to pass through network, why latency is a problem etc would
always help.

Generally, GNU Radio can't do magic. If your data processing/forwarding
introduces latencies, there's nothing you can do.
"TCP/IP transmission" doesn't necessarily give you any indication on how
fast something happens -- generally, ack'ing protocols like TCP might be
a bad choice in limiting latency.

Best regards,
Marcus

On 11/28/2014 11:27 AM, zs wrote:
> Hi all:
>  Thank you in advance.
>  Environment: gnuradio 3.7.5
>  The picture below shows the received signal.I will try my best to 
> explain my problem.I use one usrp N210 to send signal and the other usrp 
> receive the signal and then transmit the message by the tcpip to the 
> transmitter.Then the transmitter re-send signal again.I think the way of 
> tcpip transmission is so fast.But it has the latency as the below picture 
> shows.Have some ideas to solve it?And have some tools in grc to solve 
> it?Thanks so much.(the signal inside the blue circle while the latency is 
> interval of signal).
> Best regards,
>
> xd
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] Fwd: RE: synchronize two USRP N 210

[Marcus Müller]

Hi Bashar,

I'll reply once you send your emails to the mailing list instead of me
individually.

Best regards,
Marcus Müller

On 11/28/2014 12:34 PM, Bashar Hussain wrote:
> Dear Marcus 
>
> Thanks for your reply. 
>
> So here is the code now  looks like:
>


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Latency of tcpip transmission

[zs]

Hi Marcus:
 Thank you for your reply.Sorry for my unclear introduction to 
my question.I apology for this.
 I just want to know whether someone encounter the similar 
question of mine.My question is this:I have two usrps.One is transmitter while 
the other is receiver.
1.I use the transmitter to send signals to the receiver.
2.And then receiver calculate the message (very shot).And 
through the tcpip,the receiver transmit the message to the transmitter.

3.The transmitter resend again.
Because the receiver keep receiving during this processing.So 
in the interval of the transmitter sending,the receiver receive some noise.I 
don't want receive the noise.
   Have some ideas about this?Experts.Thank you.
Best regards,
zs






At 2014-11-28 19:21:15, "Marcus Müller"  wrote:
Hello xd,

You're expecting us to guess what you know:
What are we seeing in that diagram? What are the axes and how are they scaled? 
Also: some information of message length, the amount of data you  need to pass 
through network, why latency is a problem etc would always help.

Generally, GNU Radio can't do magic. If your data processing/forwarding 
introduces latencies, there's nothing you can do.
"TCP/IP transmission" doesn't necessarily give you any indication on how fast 
something happens -- generally, ack'ing protocols like TCP might be a bad 
choice in limiting latency.

Best regards,
Marcus


On 11/28/2014 11:27 AM, zs wrote:

Hi all:
 Thank you in advance.
 Environment: gnuradio 3.7.5
 The picture below shows the received signal.I will try my best to 
explain my problem.I use one usrp N210 to send signal and the other usrp 
receive the signal and then transmit the message by the tcpip to the 
transmitter.Then the transmitter re-send signal again.I think the way of tcpip 
transmission is so fast.But it has the latency as the below picture shows.Have 
some ideas to solve it?And have some tools in grc to solve it?Thanks so 
much.(the signal inside the blue circle while the latency is interval of 
signal).
Best regards,

xd






___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] Fwd: RE: synchronize two USRP N 210

[Marcus Müller]

Hi Bashar,
thanks for following up on this :)

So, the idea was to replace "set_command_time()" by "set_start_time()",
and to generally omit the clearing of command times (as you then don't
even set any):

-initialize all three USRP_sink/source objects
-set the time
-set_start_time on all three of them
-start your flowgraph.

Best regards,
Marcus

On 11/28/2014 12:44 PM, Bashar Hussain wrote:
> Dear Marcus 
>
>
>
>
>
> Thanks for your reply. 
>
>
>
>
>
> So here is the code now  looks like:
>
>
>
>
>
> self.uhd_usrp_source_1 = uhd.usrp_source(
>
>
> device_addr="addr=192.168.1.211",
>
>
> stream_args=uhd.stream_args(
>
>
> cpu_format="fc32",
>
>
> channels=range(1),
>
>
> ),
>
>
> )
>
>
> self.uhd_usrp_source_1.set_clock_source("external", 0)
>
>
> self.uhd_usrp_source_1.set_time_source("external", 0)
>
>
> self.uhd_usrp_source_1.set_time_unknown_pps(uhd.time_spec())
>
>
> self.uhd_usrp_source_1.set_samp_rate(100e6/dec_rate)
>
>
> self.uhd_usrp_source_1.set_center_freq(freq, 0)
>
>
> self.uhd_usrp_source_1.set_gain(rx_gain, 0)
>
>
> self.uhd_usrp_source_1.set_antenna("RX2", 0)
>
>
> 
>
>
> 
>
>
> self.uhd_usrp_source_0 = uhd.usrp_source(
>
>
> device_addr="addr=192.168.1.221",
>
>
> stream_args=uhd.stream_args(
>
>
> cpu_format="fc32",
>
>
> channels=range(1),
>
>
> ),
>
>
> )
>
>
> self.uhd_usrp_source_0.set_clock_source("external", 0)
>
>
> self.uhd_usrp_source_0.set_time_source("external", 0)
>
>
> self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
>
>
> self.uhd_usrp_source_0.set_samp_rate(100e6/dec_rate)
>
>
> self.uhd_usrp_source_0.set_center_freq(freq, 0)
>
>
> self.uhd_usrp_source_0.set_gain(rx_gain, 0)
>
>
> self.uhd_usrp_source_0.set_antenna("RX2", 0)
>
>
> 
>
>
> time.sleep(1);
>
>
>
>
>
> 
>
>
> cmd_time = self.uhd_usrp_source_1.get_time_last_pps()
>
>
> cmd_time0 = self.uhd_usrp_source_0.get_time_last_pps()
>
>
>
>
>
> 
>
>
> real_seconds = uhd.time_spec_t.get_real_secs(cmd_time)
>
>
> real_seconds0 = uhd.time_spec_t.get_real_secs(cmd_time0)
>
>
>
>
>
> 
>
>
> future_real_seconds = real_seconds + 1
>
>
> future_real_seconds0 = real_seconds0 + 1 
>
>
>
>
>
> 
>
>
> future_cmd_time = uhd.time_spec_t(future_real_seconds)
>
>
> future_cmd_time0 = uhd.time_spec_t(future_real_seconds0)
>
>
>
>
>
>  
>
>
> self.uhd_usrp_source_1.set_command_time(future_cmd_time)
>
>
> self.uhd_usrp_source_0.set_command_time(future_cmd_time0)
>
>
>
>
>
>
>
>
> self.uhd_usrp_source_1.set_start_time(future_cmd_time)
>
>
> self.uhd_usrp_source_0.set_start_time(future_cmd_time0)
>
>
>
>
>
> self.uhd_usrp_source_1.clear_command_time()
>
>
> self.uhd_usrp_source_0.clear_command_time()
>
>
>
>
>
>
>
>
> Or I have to delete the clear_command_time lines ?
>
>
>  
>
>
> Regards ..
>
>
>
>
>
> Bashar Mufid 
>
>
> Eng.Bashar Mufid 
> Research & Teaching Assistant
> Al-Quds University
> Faculty Of Engineering / Department of Electronics Engineering 
> Al-Quds - West Bank - Palestine 
> Tel:00972-56-8585085 
>
>
>> Date: Fri, 28 Nov 2014 12:42:27 +0100
>> From: marcus.muel...@ettus.com
>> To: eng.bashar.1...@hotmail.com; discuss-gnuradio@gnu.org
>> Subject: Re: [USRP-users] Fwd: RE:  synchronize two USRP N 210
>>
>> Hi Bashar,
>>
>> I'll reply once you send your emails to the mailing list instead of me
>> individually.
>>
>> Best regards,
>> Marcus Müller
>>
>> On 11/28/2014 12:34 PM, Bashar Hussain wrote:
>>> Dear Marcus 
>>>
>>> Thanks for your reply. 
>>>
>>> So here is the code now  looks like:
>>>
> 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Latency of tcpip transmission

[Marcus Müller]

Hi zs/xd,

On 11/28/2014 12:58 PM, zs wrote:
> Hi Marcus:
>  Thank you for your reply.Sorry for my unclear introduction 
> to my question.I apology for this.
>  I just want to know whether someone encounter the similar 
> question of mine.My question is this:I have two usrps.One is transmitter 
> while the other is receiver.
> 1.I use the transmitter to send signals to the receiver.
> 2.And then receiver calculate the message (very shot).And 
> through the tcpip,the receiver transmit the message to the transmitter.
What is "very short"? Numbers, please. Also, sample rate, modulation,
carrier frequency etc might be of interest.
> 3.The transmitter resend again.
> Because the receiver keep receiving during this processing.So 
> in the interval of the transmitter sending,the receiver receive some noise.I 
> don't want receive the noise.
>Have some ideas about this?Experts.Thank you.
well, you'll always receive noise. What's the problem with that? it's
the same noise you will see whilst actually receiving data, and to know
when to receive, you'll need some way of synchronization, anyway.

Best regards,
Marcus
> Best regards,
> zs
>
>
>
>
>
>
> At 2014-11-28 19:21:15, "Marcus Müller"  wrote:
> Hello xd,
>
> You're expecting us to guess what you know:
> What are we seeing in that diagram? What are the axes and how are they 
> scaled? Also: some information of message length, the amount of data you  
> need to pass through network, why latency is a problem etc would always help.
>
> Generally, GNU Radio can't do magic. If your data processing/forwarding 
> introduces latencies, there's nothing you can do.
> "TCP/IP transmission" doesn't necessarily give you any indication on how fast 
> something happens -- generally, ack'ing protocols like TCP might be a bad 
> choice in limiting latency.
>
> Best regards,
> Marcus
>
>
> On 11/28/2014 11:27 AM, zs wrote:
>
> Hi all:
>  Thank you in advance.
>  Environment: gnuradio 3.7.5
>  The picture below shows the received signal.I will try my best to 
> explain my problem.I use one usrp N210 to send signal and the other usrp 
> receive the signal and then transmit the message by the tcpip to the 
> transmitter.Then the transmitter re-send signal again.I think the way of 
> tcpip transmission is so fast.But it has the latency as the below picture 
> shows.Have some ideas to solve it?And have some tools in grc to solve 
> it?Thanks so much.(the signal inside the blue circle while the latency is 
> interval of signal).
> Best regards,
>
> xd
>
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Latency of tcpip transmission

[zs]

Hi Marcus:
 Thank you for your reply.

>What is "very short"? Numbers, please. Also, sample rate, 
modulation,
>carrier frequency etc might be of interest.
   1.Just 128 complex numbers.The receivers send the 128 complex 
numbers to the transmitter through the tcpip.
   sample rate=250e3,carrier frequency=3e9

>well, you'll always receive noise. What's the problem with 
that? it's
>the same noise you will see whilst actually receiving data, 
and to know
>when to receive, you'll need some way of synchronization, 
anyway.
   2.I know,I will always receive noise.But during the interval of 
the transmitter sending,the receive keep receiving.In the interval,no signal 
shows,only noise.As shows in the picture,"latency".I want to detect this,and 
just receive the signal to the next block(writing in the gnuradio).
   Thanks.
Best regards,
zs









At 2014-11-28 20:17:32, "Marcus Müller"  wrote:
>Hi zs/xd,
>
>On 11/28/2014 12:58 PM, zs wrote:
>> Hi Marcus:
>>  Thank you for your reply.Sorry for my unclear introduction 
>> to my question.I apology for this.
>>  I just want to know whether someone encounter the similar 
>> question of mine.My question is this:I have two usrps.One is transmitter 
>> while the other is receiver.
>> 1.I use the transmitter to send signals to the receiver.
>> 2.And then receiver calculate the message (very shot).And 
>> through the tcpip,the receiver transmit the message to the transmitter.
>What is "very short"? Numbers, please. Also, sample rate, modulation,
>carrier frequency etc might be of interest.
>> 3.The transmitter resend again.
>> Because the receiver keep receiving during this 
>> processing.So in the interval of the transmitter sending,the receiver 
>> receive some noise.I don't want receive the noise.
>>Have some ideas about this?Experts.Thank you.
>well, you'll always receive noise. What's the problem with that? it's
>the same noise you will see whilst actually receiving data, and to know
>when to receive, you'll need some way of synchronization, anyway.
>
>Best regards,
>Marcus
>> Best regards,
>> zs
>>
>>
>>
>>
>>
>>
>> At 2014-11-28 19:21:15, "Marcus Müller"  wrote:
>> Hello xd,
>>
>> You're expecting us to guess what you know:
>> What are we seeing in that diagram? What are the axes and how are they 
>> scaled? Also: some information of message length, the amount of data you  
>> need to pass through network, why latency is a problem etc would always help.
>>
>> Generally, GNU Radio can't do magic. If your data processing/forwarding 
>> introduces latencies, there's nothing you can do.
>> "TCP/IP transmission" doesn't necessarily give you any indication on how 
>> fast something happens -- generally, ack'ing protocols like TCP might be a 
>> bad choice in limiting latency.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 11/28/2014 11:27 AM, zs wrote:
>>
>> Hi all:
>>  Thank you in advance.
>>  Environment: gnuradio 3.7.5
>>  The picture below shows the received signal.I will try my best to 
>> explain my problem.I use one usrp N210 to send signal and the other usrp 
>> receive the signal and then transmit the message by the tcpip to the 
>> transmitter.Then the transmitter re-send signal again.I think the way of 
>> tcpip transmission is so fast.But it has the latency as the below picture 
>> shows.Have some ideas to solve it?And have some tools in grc to solve 
>> it?Thanks so much.(the signal inside the blue circle while the latency is 
>> interval of signal).
>> Best regards,
>>
>> xd
>>
>>
>>
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Latency of tcpip transmission

[Marcus Müller]

Hi zs,

On 11/28/2014 01:25 PM, zs
> >What is "very short"? Numbers, please. Also, sample rate, carrier frequency 
> >etc might be of 

> 1.Just 128 complex numbers.The receivers send the 128 complex numbers to the 
> transmitter through the tcpip.
>sample rate=250e3,carrier frequency=3e9
128 samples is not really long, and might in fact be so short that
you'll see things like the analog amplifiers ramp up, depending on what
you do in between these bursts.
>
> >well, you'll always receive noise. What's the problem with 
> that? it's
> >the same noise you will see whilst actually receiving data, 
> and to know
> >when to receive, you'll need some way of synchronization, 
> anyway.
>2.I know,I will always receive noise.But during the interval 
> of the transmitter sending,the receive keep receiving.In the interval,no 
> signal shows,only noise.As shows in the picture,"latency".I want to detect 
> this,and just receive the signal to the next block(writing in the gnuradio).
I still don't understand. Since this latency is all but deterministic,
you already have some signal detection, right?

Greetings,
Marcus

>Thanks.
> Best regards,
> zs
>
>
>
>
>
>
>
>
>
> At 2014-11-28 20:17:32, "Marcus Müller"  wrote:
>> Hi zs/xd,
>>
>> On 11/28/2014 12:58 PM, zs wrote:
>>> Hi Marcus:
>>>  Thank you for your reply.Sorry for my unclear introduction 
>>> to my question.I apology for this.
>>>  I just want to know whether someone encounter the similar 
>>> question of mine.My question is this:I have two usrps.One is transmitter 
>>> while the other is receiver.
>>> 1.I use the transmitter to send signals to the receiver.
>>> 2.And then receiver calculate the message (very shot).And 
>>> through the tcpip,the receiver transmit the message to the transmitter.
>> What is "very short"? Numbers, please. Also, sample rate, modulation,
>> carrier frequency etc might be of interest.
>>> 3.The transmitter resend again.
>>> Because the receiver keep receiving during this 
>>> processing.So in the interval of the transmitter sending,the receiver 
>>> receive some noise.I don't want receive the noise.
>>>Have some ideas about this?Experts.Thank you.
>> well, you'll always receive noise. What's the problem with that? it's
>> the same noise you will see whilst actually receiving data, and to know
>> when to receive, you'll need some way of synchronization, anyway.
>>
>> Best regards,
>> Marcus
>>> Best regards,
>>> zs
>>>
>>>
>>>
>>>
>>>
>>>
>>> At 2014-11-28 19:21:15, "Marcus Müller"  wrote:
>>> Hello xd,
>>>
>>> You're expecting us to guess what you know:
>>> What are we seeing in that diagram? What are the axes and how are they 
>>> scaled? Also: some information of message length, the amount of data you  
>>> need to pass through network, why latency is a problem etc would always 
>>> help.
>>>
>>> Generally, GNU Radio can't do magic. If your data processing/forwarding 
>>> introduces latencies, there's nothing you can do.
>>> "TCP/IP transmission" doesn't necessarily give you any indication on how 
>>> fast something happens -- generally, ack'ing protocols like TCP might be a 
>>> bad choice in limiting latency.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 11/28/2014 11:27 AM, zs wrote:
>>>
>>> Hi all:
>>>  Thank you in advance.
>>>  Environment: gnuradio 3.7.5
>>>  The picture below shows the received signal.I will try my best to 
>>> explain my problem.I use one usrp N210 to send signal and the other usrp 
>>> receive the signal and then transmit the message by the tcpip to the 
>>> transmitter.Then the transmitter re-send signal again.I think the way of 
>>> tcpip transmission is so fast.But it has the latency as the below picture 
>>> shows.Have some ideas to solve it?And have some tools in grc to solve 
>>> it?Thanks so much.(the signal inside the blue circle while the latency is 
>>> interval of signal).
>>> Best regards,
>>>
>>> xd
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How to correct for the drift in an (FMCW) Rx signal?

[khalid.el-darymli]

Hi,

Given a set of synced *(i.e., using external GPS REF/PPS)*, time-commanded
and calibrated *(i.e., through compensating for the phase/mag offset
between digital Tx chirp prior to transmission and ADC'ed Rx signals) *N200
devices with LFTX/LFRX daughterboards, that work with coherent LFMCW
chirps, I am still seeing a tiny drift (both in the magnitude and
frequency) of the calibrated  back-scatter Rx chirp received at time t1
when compared to an Rx chirp received at an earlier time t0.

The more the N200 device runs (e.g., 5 hours), the greater the drift is.
Obviously, this drift is pertinent to both the DAC and ADCs and the GPS
referenced clocks of the N200 devices.

My questions are:

1- Why I still see such drift although my devices are synced with an
external GPS? and how do I correct for it?

2- Can the *PLL Carrier Tracking *block in GRC be used to track and correct
for such a drift? If so, how do I set the max/min freq inputs for this
block?

3- Can *AGC2* or *AGC3 *block be useful in this regard? If so, are there
any examples to explain how the input parameters of these blocks can be set
up?


Thanks.

Best regards,
Khalid
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] How to correct for the drift in an (FMCW) Rx signal?

[mleech]

 

What is the magnitude of the frequency drift? 

What is the magnitude of the gain drift? 

What are you measuring backscatter *from*? 

On 2014-11-28 10:14, khalid.el-darymli via USRP-users wrote: 

> Hi,
> 
> Given a set of synced _(i.e., using external GPS REF/PPS)_, time-commanded 
> and calibrated _(i.e., through compensating for the phase/mag offset between 
> digital Tx chirp prior to transmission and ADC'ed Rx signals) _N200 devices 
> with LFTX/LFRX daughterboards, that work with coherent LFMCW chirps, I am 
> still seeing a tiny drift (both in the magnitude and frequency) of the 
> calibrated back-scatter Rx chirp received at time t1 when compared to an Rx 
> chirp received at an earlier time t0. 
> 
> The more the N200 device runs (e.g., 5 hours), the greater the drift is. 
> Obviously, this drift is pertinent to both the DAC and ADCs and the GPS 
> referenced clocks of the N200 devices. 
> 
> My questions are:
> 
> 1- Why I still see such drift although my devices are synced with an external 
> GPS? and how do I correct for it? 
> 
> 2- Can the PLL CARRIER TRACKING block in GRC be used to track and correct for 
> such a drift? If so, how do I set the max/min freq inputs for this block?
> 
> 3- Can AGC2 or AGC3 block be useful in this regard? If so, are there any 
> examples to explain how the input parameters of these blocks can be set up?
> 
> Thanks.
> 
> Best regards, 
> Khalid
> 
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
 

Links:
--
[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fractional delay in fractional resampler block

[Carlos Alberto Ruiz Naranjo]

Hi Marcus,

I spent a week doing tests and do not know what can be the fault. Did you
see any mistake? [1]
If I transmit the signal with no delay (signal -> FFT -> IFFT -> USRP) I
have a small variable delay unwanted in the receiver.

Greetings.

[1] Now use powers of two in the FFT lenght (128,256...)

2014-11-19 14:57 GMT+01:00 Carlos Alberto Ruiz Naranjo <
carlosruiznara...@gmail.com>:

> *** The bandwidth of the signal is 4 MHz.
>
>
>
> Greetings,
> Carlos Alberto Ruiz Naranjo.
>
> Área de Aviónica y Sistemas No Tripulados/Avionics and Unmanned Systems
> Department
>
> Parque Tecnológico y Aeronáutico de Andalucía
> C/ Wilbur y Orville Wright, 17-19-21
> 41309 La Rinconada
> Sevilla (Spain)
> (+34) 954179002
> http://www.catec.aero/
>
> 2014-11-19 9:03 GMT+01:00 Carlos Alberto Ruiz Naranjo <
> carlosruiznara...@gmail.com>:
>
>> Hello!
>>
>> I have done the fractional delay block ( http://pastebin.com/cEDfTh9m ).
>> Have you seen some error? I have used the proposed filter in "Closed
>> Form Variable Fractional Time Delay Using FFT" [1][2]
>> This is my flowgraph:
>>
>>
>>
>> ​
>> - My signal sample rate is 1023 samples per second and I want a
>> variable delay of 1ns of precision. What is the relationship between the
>> maximum precision of fractional delay and the length of the FFT? What is
>> the limit?
>>
>> - Is it a problem the fractional resampler of 1.023? Can it distort my
>> signal? [3]
>>
>>
>> Greetings,
>> Carlos Alberto Ruiz Naranjo.
>>
>> Área de Aviónica y Sistemas No Tripulados/Avionics and Unmanned Systems
>> Department
>>
>> Parque Tecnológico y Aeronáutico de Andalucía
>> C/ Wilbur y Orville Wright, 17-19-21
>> 41309 La Rinconada
>> Sevilla (Spain)
>> (+34) 954179002
>> http://www.catec.aero/
>>
>>
>>
>>
>>
>>
>> [1]
>> https://www.deepdyve.com/lp/institute-of-electrical-and-electronics-engineers/comments-on-closed-form-variable-fractional-time-delay-using-fft-tNk7X6CH9c
>> [2] http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6171834
>> [3] I use the fractional resampler because I can't put a sample rate of
>> 1023 in the USRP block.
>>
>>
>>
>>
>> 2014-11-17 14:26 GMT+01:00 Marcus Müller :
>>
>>> Hi Carlos,
>>> yes, your formular looks correct, scalar multiplication aside.
>>>
>>> Regarding your problem:
>>> It's not a problem, it's a feature :)
>>> you're using window functions in your FFT, that's what's changing your
>>> signal.
>>> The FFT is but an implementation of the DFT (discrete fourier
>>> transform), which is, considering the input as element of a
>>> n_fft-dimensional vector space, is but a base change, and thus has an
>>> inverse -- the IDFT (incarnated by the IFFT).
>>>
>>> what you see is something like the norm of the square of the window
>>> function; use "rectangular" to avoid this.
>>>
>>> Greetings,
>>> Marcus
>>>
>>> On 11/17/2014 12:23 PM, Carlos Alberto Ruiz Naranjo wrote:
>>> > I have some questions about FFT method.
>>> >
>>> > - I have done a test with my signal ( [Signal] -> [FFT] -> [IFFT] ->
>>> [Signal]
>>> > ) and I have a problem with the spectrum (central lobe):
>>> >
>>> >
>>> >
>>> > ​
>>> >
>>> > - To insert a delay I multiply the FFT by [1], right?
>>> >
>>> > Can I insert a delay (no variable) if I multiply the FFT by GNURadio
>>> sine
>>> > complex block?
>>> >
>>> >
>>> >
>>> >
>>> > Greetings,
>>> > Carlos Alberto Ruiz Naranjo.
>>> >
>>> > Área de Aviónica y Sistemas No Tripulados/Avionics and Unmanned Systems
>>> > Department
>>> >
>>> > Parque Tecnológico y Aeronáutico de Andalucía
>>> > C/ Wilbur y Orville Wright, 17-19-21
>>> > 41309 La Rinconada
>>> > Sevilla (Spain)
>>> > (+34) 954179002
>>> > http://www.catec.aero/
>>> >
>>> >
>>> > [1] N: length of FFT, m: delay, k: position
>>> >
>>> >
>>> >
>>> > 2014-11-12 15:32 GMT+01:00 Marcus Müller :
>>> >
>>> >>  well, yes, you could, but that sounds ugly:
>>> >> 1. a sample rate of 1e9Hz implies --for complex float-- a memory
>>> >> consumption of 1e9*8B~=8GB per second...
>>> >> 2. unwieldy fractional resampling, because 10.23e6 and 1e9 don't have
>>> a
>>> >> very large common divisor; you'll be interpolating by a factor of
>>> 10
>>> >> just to decimate by 1023... That is effectively just very very many
>>> samples
>>> >> in-between.
>>> >> 3. you're sampling at 10.23MS/s, but you want to do something with a
>>> >> temporal resolution of 10 times that rate; that's a phase shift, for
>>> sure,
>>> >> but I'm afraid that it sounds like you're trying to harm Nyquist in
>>> some
>>> >> way or another.
>>> >>
>>> >> When were talking on how to simulate delay introduced by radar range
>>> in
>>> >> GNU Radio, a wise[1] elder[2] told me to do time shifting in frequency
>>> >> domain:
>>> >>
>>> >> The idea is that a time shift corresponds to frequency shift in
>>> frequency
>>> >> domain, so you can, within the spectral precision defined by the
>>> length of
>>> >> your DFT, have arbitrary shifts by doing [time
>>> signal]->[DFT]->[multiply
>>> >> with complex sine]->[IDFT] 

Re: [Discuss-gnuradio] Fractional delay in fractional resampler block

[Marcus Müller]

Hello Carlos,

I don't really think that what you built really reflects what you're
trying to achieve: I thought you needed a really small delay in time
domain, and a sampling rate conversion from 10MHz to 10.23MHz.

Why are you doing a delay in frequency domain? That will simply be a
frequency shift in time domain, which you could easily realize (and with
much smaller computational error) by multiplying with a complex sine in
time domain.

I don't really understand what you mean with "small variable delay in
the receiver": Do you mean your system is not somehow synchronized?

Best regards,
Marcus Müller

On 11/28/2014 05:16 PM, Carlos Alberto Ruiz Naranjo wrote:
> Hi Marcus,
>
> I spent a week doing tests and do not know what can be the fault. Did you
> see any mistake? [1]
> If I transmit the signal with no delay (signal -> FFT -> IFFT -> USRP) I
> have a small variable delay unwanted in the receiver.
>
> Greetings.
>
> [1] Now use powers of two in the FFT lenght (128,256...)
>
> 2014-11-19 14:57 GMT+01:00 Carlos Alberto Ruiz Naranjo <
> carlosruiznara...@gmail.com>:
>
>> *** The bandwidth of the signal is 4 MHz.
>>
>>
>>
>> Greetings,
>> Carlos Alberto Ruiz Naranjo.
>>
>> Área de Aviónica y Sistemas No Tripulados/Avionics and Unmanned Systems
>> Department
>>
>> Parque Tecnológico y Aeronáutico de Andalucía
>> C/ Wilbur y Orville Wright, 17-19-21
>> 41309 La Rinconada
>> Sevilla (Spain)
>> (+34) 954179002
>> http://www.catec.aero/
>>
>> 2014-11-19 9:03 GMT+01:00 Carlos Alberto Ruiz Naranjo <
>> carlosruiznara...@gmail.com>:
>>
>>> Hello!
>>>
>>> I have done the fractional delay block ( http://pastebin.com/cEDfTh9m ).
>>> Have you seen some error? I have used the proposed filter in "Closed
>>> Form Variable Fractional Time Delay Using FFT" [1][2]
>>> This is my flowgraph:
>>>
>>>
>>>
>>> ​
>>> - My signal sample rate is 1023 samples per second and I want a
>>> variable delay of 1ns of precision. What is the relationship between the
>>> maximum precision of fractional delay and the length of the FFT? What is
>>> the limit?
>>>
>>> - Is it a problem the fractional resampler of 1.023? Can it distort my
>>> signal? [3]
>>>
>>>
>>> Greetings,
>>> Carlos Alberto Ruiz Naranjo.
>>>
>>> Área de Aviónica y Sistemas No Tripulados/Avionics and Unmanned Systems
>>> Department
>>>
>>> Parque Tecnológico y Aeronáutico de Andalucía
>>> C/ Wilbur y Orville Wright, 17-19-21
>>> 41309 La Rinconada
>>> Sevilla (Spain)
>>> (+34) 954179002
>>> http://www.catec.aero/
>>>
>>>
>>>
>>>
>>>
>>>
>>> [1]
>>> https://www.deepdyve.com/lp/institute-of-electrical-and-electronics-engineers/comments-on-closed-form-variable-fractional-time-delay-using-fft-tNk7X6CH9c
>>> [2] http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6171834
>>> [3] I use the fractional resampler because I can't put a sample rate of
>>> 1023 in the USRP block.
>>>
>>>
>>>
>>>
>>> 2014-11-17 14:26 GMT+01:00 Marcus Müller :
>>>
 Hi Carlos,
 yes, your formular looks correct, scalar multiplication aside.

 Regarding your problem:
 It's not a problem, it's a feature :)
 you're using window functions in your FFT, that's what's changing your
 signal.
 The FFT is but an implementation of the DFT (discrete fourier
 transform), which is, considering the input as element of a
 n_fft-dimensional vector space, is but a base change, and thus has an
 inverse -- the IDFT (incarnated by the IFFT).

 what you see is something like the norm of the square of the window
 function; use "rectangular" to avoid this.

 Greetings,
 Marcus

 On 11/17/2014 12:23 PM, Carlos Alberto Ruiz Naranjo wrote:
> I have some questions about FFT method.
>
> - I have done a test with my signal ( [Signal] -> [FFT] -> [IFFT] ->
 [Signal]
> ) and I have a problem with the spectrum (central lobe):
>
>
>
> ​
>
> - To insert a delay I multiply the FFT by [1], right?
>
> Can I insert a delay (no variable) if I multiply the FFT by GNURadio
 sine
> complex block?
>
>
>
>
> Greetings,
> Carlos Alberto Ruiz Naranjo.
>
> Área de Aviónica y Sistemas No Tripulados/Avionics and Unmanned Systems
> Department
>
> Parque Tecnológico y Aeronáutico de Andalucía
> C/ Wilbur y Orville Wright, 17-19-21
> 41309 La Rinconada
> Sevilla (Spain)
> (+34) 954179002
> http://www.catec.aero/
>
>
> [1] N: length of FFT, m: delay, k: position
>
>
>
> 2014-11-12 15:32 GMT+01:00 Marcus Müller :
>
>>  well, yes, you could, but that sounds ugly:
>> 1. a sample rate of 1e9Hz implies --for complex float-- a memory
>> consumption of 1e9*8B~=8GB per second...
>> 2. unwieldy fractional resampling, because 10.23e6 and 1e9 don't have
 a
>> very large common divisor; you'll be interpolating by a factor of
 10
>> just to decimate by 1023... That is effectively just very ver

Re: [Discuss-gnuradio] Fractional delay in fractional resampler block

[Marcus Müller]

Hi Carlos,
I just realized that maybe the core problem here is that I don't really
understand what you're trying to do --
could you explain what this system will be used for, and why you need
that particular sampling rate etc?

Best regards,
Marcus
On 11/28/2014 05:59 PM, Marcus Müller wrote:
> Hello Carlos,
>
> I don't really think that what you built really reflects what you're
> trying to achieve: I thought you needed a really small delay in time
> domain, and a sampling rate conversion from 10MHz to 10.23MHz.
>
> Why are you doing a delay in frequency domain? That will simply be a
> frequency shift in time domain, which you could easily realize (and with
> much smaller computational error) by multiplying with a complex sine in
> time domain.
>
> I don't really understand what you mean with "small variable delay in
> the receiver": Do you mean your system is not somehow synchronized?
>
> Best regards,
> Marcus Müller
>
> On 11/28/2014 05:16 PM, Carlos Alberto Ruiz Naranjo wrote:
>> Hi Marcus,
>>
>> I spent a week doing tests and do not know what can be the fault. Did you
>> see any mistake? [1]
>> If I transmit the signal with no delay (signal -> FFT -> IFFT -> USRP) I
>> have a small variable delay unwanted in the receiver.
>>
>> Greetings.
>>
>> [1] Now use powers of two in the FFT lenght (128,256...)
>>
>> 2014-11-19 14:57 GMT+01:00 Carlos Alberto Ruiz Naranjo <
>> carlosruiznara...@gmail.com>:
>>
>>> *** The bandwidth of the signal is 4 MHz.
>>>
>>>
>>>
>>> Greetings,
>>> Carlos Alberto Ruiz Naranjo.
>>>
>>> Área de Aviónica y Sistemas No Tripulados/Avionics and Unmanned Systems
>>> Department
>>>
>>> Parque Tecnológico y Aeronáutico de Andalucía
>>> C/ Wilbur y Orville Wright, 17-19-21
>>> 41309 La Rinconada
>>> Sevilla (Spain)
>>> (+34) 954179002
>>> http://www.catec.aero/
>>>
>>> 2014-11-19 9:03 GMT+01:00 Carlos Alberto Ruiz Naranjo <
>>> carlosruiznara...@gmail.com>:
>>>
 Hello!

 I have done the fractional delay block ( http://pastebin.com/cEDfTh9m ).
 Have you seen some error? I have used the proposed filter in "Closed
 Form Variable Fractional Time Delay Using FFT" [1][2]
 This is my flowgraph:



 ​
 - My signal sample rate is 1023 samples per second and I want a
 variable delay of 1ns of precision. What is the relationship between the
 maximum precision of fractional delay and the length of the FFT? What is
 the limit?

 - Is it a problem the fractional resampler of 1.023? Can it distort my
 signal? [3]


 Greetings,
 Carlos Alberto Ruiz Naranjo.

 Área de Aviónica y Sistemas No Tripulados/Avionics and Unmanned Systems
 Department

 Parque Tecnológico y Aeronáutico de Andalucía
 C/ Wilbur y Orville Wright, 17-19-21
 41309 La Rinconada
 Sevilla (Spain)
 (+34) 954179002
 http://www.catec.aero/






 [1]
 https://www.deepdyve.com/lp/institute-of-electrical-and-electronics-engineers/comments-on-closed-form-variable-fractional-time-delay-using-fft-tNk7X6CH9c
 [2] http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6171834
 [3] I use the fractional resampler because I can't put a sample rate of
 1023 in the USRP block.




 2014-11-17 14:26 GMT+01:00 Marcus Müller :

> Hi Carlos,
> yes, your formular looks correct, scalar multiplication aside.
>
> Regarding your problem:
> It's not a problem, it's a feature :)
> you're using window functions in your FFT, that's what's changing your
> signal.
> The FFT is but an implementation of the DFT (discrete fourier
> transform), which is, considering the input as element of a
> n_fft-dimensional vector space, is but a base change, and thus has an
> inverse -- the IDFT (incarnated by the IFFT).
>
> what you see is something like the norm of the square of the window
> function; use "rectangular" to avoid this.
>
> Greetings,
> Marcus
>
> On 11/17/2014 12:23 PM, Carlos Alberto Ruiz Naranjo wrote:
>> I have some questions about FFT method.
>>
>> - I have done a test with my signal ( [Signal] -> [FFT] -> [IFFT] ->
> [Signal]
>> ) and I have a problem with the spectrum (central lobe):
>>
>>
>>
>> ​
>>
>> - To insert a delay I multiply the FFT by [1], right?
>>
>> Can I insert a delay (no variable) if I multiply the FFT by GNURadio
> sine
>> complex block?
>>
>>
>>
>>
>> Greetings,
>> Carlos Alberto Ruiz Naranjo.
>>
>> Área de Aviónica y Sistemas No Tripulados/Avionics and Unmanned Systems
>> Department
>>
>> Parque Tecnológico y Aeronáutico de Andalucía
>> C/ Wilbur y Orville Wright, 17-19-21
>> 41309 La Rinconada
>> Sevilla (Spain)
>> (+34) 954179002
>> http://www.catec.aero/
>>
>>
>> [1] N: length of FFT, m: delay, k: position
>>
>>
>>
>

Re: [Discuss-gnuradio] [USRP-users] How to correct for the drift in an (FMCW) Rx signal?

[Marcus D. Leech]

On 11/28/2014 03:41 PM, khalid.el-darymli wrote:



Back to my original question, what should I do to correct for this?

Thanks in advance.

Best,
Khalid



Khalid:

Thanks very much for the very-extensive data.  My main concern, as one 
of the Ettus support team, was that there was something wrong with
  the hardware, but the magnitude of both the apparent phase and 
magnitude drift is entirely consistent with analog-hardware temperature

  effects, unrelated to clock stability, etc.

Coax cables, for example, will change their loss characteristics and 
*effective length* with temperature, so with precise hardware like 
USRPs, it's

  easy to see these effects.

FMCW radar isn't my area of expertise, so hopefully others can comment 
on RX-processing strategies to deal with this, as it *must* also be a 
problem

  with non-SDR FMCW radar implementations.







On Fri, Nov 28, 2014 at 12:08 PM, > wrote:


What is the magnitude of the frequency drift?

What is the magnitude of the gain drift?

What are you measuring backscatter *from*?

On 2014-11-28 10:14, khalid.el-darymli via USRP-users wrote:


Hi,

Given a set of synced /(i.e., using external GPS REF/PPS)/,
time-commanded and calibrated /(i.e., through compensating for
the phase/mag offset between digital Tx chirp prior to
transmission and ADC'ed Rx signals) /N200 devices with LFTX/LFRX
daughterboards, that work with coherent LFMCW chirps, I am still
seeing a tiny drift (both in the magnitude and frequency) of the
calibrated  back-scatter Rx chirp received at time t1 when
compared to an Rx chirp received at an earlier time t0.

The more the N200 device runs (e.g., 5 hours), the greater the
drift is. Obviously, this drift is pertinent to both the DAC and
ADCs and the GPS referenced clocks of the N200 devices.

My questions are:

1- Why I still see such drift although my devices are synced with
an external GPS? and how do I correct for it?

2- Can the *PLL Carrier Tracking *block in GRC be used to track
and correct for such a drift? If so, how do I set the max/min
freq inputs for this block?

3- Can *AGC2* or *AGC3 *block be useful in this regard? If so,
are there any examples to explain how the input parameters of
these blocks can be set up?


Thanks.

Best regards,
Khalid


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







--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio