Re: [Discuss-gnuradio] [USRP-users] minimum PPS voltage for N200

[khalid.el-darymli]

Thanks again Marcus. I really appreciate your help.

I am setting Ref Clock / PPS to external, etc. I get the syncing to work
properly around a year ago. Since then, we made various changes and I think
one or more change may be causing the issue. Among the changes are: buy
N200 units with a new revision (could that be a problem when syncing?),
upgrading GNU Radio / UHD, enabling Rs 232  echoing in the GPSDO, etc.

Similar to my last year tests (I entirely unplugged the RS 232 cable), and
now it is not detected as an Internal GPSDO. However, I am still having
issue syncing the two motherboards.

Attached are two figures for the phase drift between Rx1 vs. Rx2, and Rx1
vs. Rx3. This was generated through splitting the Tx and looping it back to
the Rx's. Signal processing was done properly (for dechirping, downsamplng,
etc). My application is LFMCW radar, so each 490 samples in the attachment
represents one sweep, and sweeping was done continuously.

angle(Rx1./Rx2) looks great. As to angle(Rx1./Rx3), I would expect a linear
phase offset between different motherboards. However, as .shown in the
attachment, Rx1 vs. Rx3 has weird phase spikes. I think this shows that,
for some reason, the Tx is not properly synced with the second motherboard.
Any ideas on what might be causing this issue?

I am using Starttech Ethernet Adapter (ST1000SPEX4). The problem I have
with this card is that it won't turn AUTONEG off, it is always on. Could
this cause the problem?

I tried this on two different Ubuntu machines, with similar results as
shown in the attachment.

For the first machine,

UBUNTU 14.04 LTS
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.002-80-ge28d7844

For the second machine,
UBUNTU 14.04 LTS
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.000-46-g5b706d29


I'll highly appreciate any suggestions to solve this problem.

Thank you.

Best wishes,
khalid







On Tue, May 3, 2016 at 1:45 PM,  wrote:

> The only way the USRP knows that there's a GPSDO present is if the serial
> data from the GSPDO is validated.  If it doesn't see that data, it
> concludes that there's no (internal) GPSDO present.
>
> There is no concept of "external GPSDO" -- only that *something* is
> providing 10MHz and 1PPS externally.  The N2xx has no idea what that might
> be.
>
> You should set both 1PPS and 10MHz clock to "external" in your flow-graph.
> The only time "GPSDO" is used is when you have a properly-installed
> internally-mounted, GPSDO unit.
>
>
>
>
>
>
> On 2016-05-03 12:02, khalid.el-darymli wrote:
>
> Thanks Marcus.
>
> OK, I'm communicating with the external Firefly-1A GPSDO unit using an RS
> 232 cable. I am able to do so after enabling echoing on RS 232 from the
> GPSDO. Would that be a problem? Do I need to completely disable the RS 232
> echoing, even while the RS 232 cable is completely unplugged?
>
> When the RS 232 cable is plugged-in, N200 DETECTs it as an INTERNAL GPSDO.
> When I completely unplug the RS 232 cable on both ends, I am not getting
> any messages for detecting neither external nor internal GPSDO. It only
> shows the following in the terminal for both N200 devices,
>
> (1) catch time transition at pps edge
> (2) set time next pps (synchronously).
>
> khalid
>
>
>
>
> On Tue, May 3, 2016 at 12:20 PM,  wrote:
>
>> The PPS input is conditioned with a:
>>
>> http://www.ti.com/product/SN74AUP1T57/description
>>
>> Looks to me like it should work just fine.
>>
>>
>>
>>
>>
>>
>> On 2016-05-03 10:23, khalid.el-darymli via USRP-users wrote:
>>
>> Hi,
>>
>> I'll appreciate any help on the following. According to the link below
>> [1], the PPS voltage for N200 should be in the range *[3.3, 5]* V p-p.
>> [1] http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds
>>
>> I am getting a PPS signal through fan-outs from an external Firefly-1A
>> GPSDO. I measured the output PPS voltage using a scope, and it is *2.52
>> V p-p* (terminated with 50 ohms).
>>
>> Would this relatively low PPS voltage work for N200?  I am having a
>> problem syncing two N200 units (2 LFRX/ 1 LFTX ), and I am not sure if this
>> would be the cause?
>>
>>
>> Thank you.
>>
>> Best wishes,
>> Khalid
>>
>> ___
>> 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

Re: [Discuss-gnuradio] [USRP-users] minimum PPS voltage for N200

[khalid.el-darymli]

Thanks Marcus.

OK, I'm communicating with the external Firefly-1A GPSDO unit using an RS
232 cable. I am able to do so after enabling echoing on RS 232 from the
GPSDO. Would that be a problem? Do I need to completely disable the RS 232
echoing, even while the RS 232 cable is completely unplugged?

When the RS 232 cable is plugged-in, N200 DETECTs it as an INTERNAL GPSDO.
When I completely unplug the RS 232 cable on both ends, I am not getting
any messages for detecting neither external nor internal GPSDO. It only
shows the following in the terminal for both N200 devices,

(1) catch time transition at pps edge
(2) set time next pps (synchronously).

khalid




On Tue, May 3, 2016 at 12:20 PM,  wrote:

> The PPS input is conditioned with a:
>
> http://www.ti.com/product/SN74AUP1T57/description
>
> Looks to me like it should work just fine.
>
>
>
>
>
>
> On 2016-05-03 10:23, khalid.el-darymli via USRP-users wrote:
>
> Hi,
>
> I'll appreciate any help on the following. According to the link below
> [1], the PPS voltage for N200 should be in the range *[3.3, 5]* V p-p.
> [1] http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds
>
> I am getting a PPS signal through fan-outs from an external Firefly-1A
> GPSDO. I measured the output PPS voltage using a scope, and it is *2.52 V
> p-p* (terminated with 50 ohms).
>
> Would this relatively low PPS voltage work for N200?  I am having a
> problem syncing two N200 units (2 LFRX/ 1 LFTX ), and I am not sure if this
> would be the cause?
>
>
> Thank you.
>
> Best wishes,
> Khalid
>
>
> ___
> 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] minimum PPS voltage for N200

[khalid.el-darymli]

Hi,

I'll appreciate any help on the following. According to the link below [1],
the PPS voltage for N200 should be in the range *[3.3, 5]* V p-p.
[1] http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds

I am getting a PPS signal through fan-outs from an external Firefly-1A
GPSDO. I measured the output PPS voltage using a scope, and it is *2.52 V
p-p* (terminated with 50 ohms).

Would this relatively low PPS voltage work for N200?  I am having a problem
syncing two N200 units (2 LFRX/ 1 LFTX ), and I am not sure if this would
be the cause?


Thank you.

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

[Discuss-gnuradio] How to set the time (y) axis duration (as desired) for the waterfall sink?

[khalid.el-darymli]

Hi,

Can the time axis (y-axis) of the qt-gui waterfall sink be set as desired?
By default, it only shows a duration of 20 seconds. I would like this to be
adjusted,  for example, to 1 minute or two minutes, etc.

I'm compiling the waterfall sink directly from C++ (I'm not using python or
GRC).

Thanks in advance.

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

Re: [Discuss-gnuradio] How to display a Qt Waterfall in C++?

[khalid.el-darymli]

Hi list,

FYI, I went through the documentation and I managed to get it to work :)
All what I need to do was to define a layout so that the waterfall widget
can be added to it.

Thanks,
khalid


-- Forwarded message --
From: khalid.el-darymli 
Date: Thu, Jul 30, 2015 at 9:37 AM
Subject: How to display a Qt Waterfall in C++?
To: "Discuss-gnuradio@gnu.org" 


Hi,

I have a simple flowgraph comprised of two channels (UHD: USRP Source)
connected to two separate Qt GUI Waterfall sinks.

This works perfectly in Python/GRC. However, I would like to convert this
into C++.

Previously, I did conversions successfully for various other flow-graphs
without GUIs. However, in this case, although the 'exe' file compiles fine
and it runs fine without any errors, I can't get it to display the
Waterfall plot.

In my current C++ code, the UHD Source Block and the Waterfall Sink block
are constructed, set-up and properly connected  to each other. I thought
this will automatically allow the Waterfall graph to display but it doesn't.

Following the python code in [1], I tried in my C++ code the following line,
[1] http://gnuradio.squarespace.com/examples/tag/qtgui


QApplication app(argc, argv);


I am not expert in Qt, but I think this is a constructor call that creates
an QApplication instance to process the Waterfall data, right? Can you
please give me a hint on how should I go about handling/displaying the
Waterfall data from there?

Thanks in advance for your help.


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

[Discuss-gnuradio] How to display a Qt Waterfall in C++?

[khalid.el-darymli]

Hi,

I have a simple flowgraph comprised of two channels (UHD: USRP Source)
connected to two separate Qt GUI Waterfall sinks.

This works perfectly in Python/GRC. However, I would like to convert this
into C++.

Previously, I did conversions successfully for various other flow-graphs
without GUIs. However, in this case, although the 'exe' file compiles fine
and it runs fine without any errors, I can't get it to display the
Waterfall plot.

In my current C++ code, the UHD Source Block and the Waterfall Sink block
are constructed, set-up and properly connected  to each other. I thought
this will automatically allow the Waterfall graph to display but it doesn't.

Following the python code in [1], I tried in my C++ code the following line,
[1] http://gnuradio.squarespace.com/examples/tag/qtgui


QApplication app(argc, argv);


I am not expert in Qt, but I think this is a constructor call that creates
an QApplication instance to process the Waterfall data, right? Can you
please give me a hint on how should I go about handling/displaying the
Waterfall data from there?

Thanks in advance for your help.


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

Re: [Discuss-gnuradio] How to "declare_sample_delay" in C++?

[khalid.el-darymli]

Hi Martin,

Thanks for the answer. My confusion is that when you generate, for example,
a multi-stage polyphase decimator in GRC, a 'declare_sample_delay(0)' code
will be generated for each decimation block. When I go from Python to C++ I
thought I should do the same. Now, since the default is zero, does that
mean the 'declare_sample_delay(0)' codes generated by GRC are redundant?


Thank you.

Best wishes,
Khalid



> Message: 7
> Date: Fri, 22 May 2015 12:00:39 -0700
> From: Martin Braun 
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] How to "declare_sample_delay" in C++?
> Message-ID: <555f7cd7.2040...@ettus.com>
> Content-Type: text/plain; charset=windows-1252
>
> Not sure what you're asking, the command is wrapped from C++ to Python,
> and hence the same in both domains (see also
>
> http://gnuradio.org/doc/doxygen/classgr_1_1block.html#acad5d6e62ea885cb77d19f72451581c2
> ).
>
> Also, 0 is the default.
>
> M
>
> On 22.05.2015 11:26, khalid.el-darymli wrote:
> > Hi list,
> >
> > I am doing some (polyphase) decimation with GNURadio in C++. I
> > constructed my filters, I wrote some wrapper, and my script compiles
> > perfectly. However, I am a bit unclear about "declare_sample_delay".
> >
> > Assume that I have the block: pfb_decimator_ccf_0_5. To set the sample
> > delay for this block to 0, in python, one uses:
> >
> > self.pfb_decimator_ccf_0_5.declare_sample_delay(0)
> >
> >
> > What is the proper way to do the same command in C++?
> >
> >
> > Thanks in advance.
> >
> > Best wishes,
> > Khalid
> >
> >
> >
> > ___
> > 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

[Discuss-gnuradio] How to "declare_sample_delay" in C++?

[khalid.el-darymli]

Hi list,

I am doing some (polyphase) decimation with GNURadio in C++. I constructed
my filters, I wrote some wrapper, and my script compiles perfectly.
However, I am a bit unclear about "declare_sample_delay".

Assume that I have the block: pfb_decimator_ccf_0_5. To set the sample
delay for this block to 0, in python, one uses:

self.pfb_decimator_ccf_0_5.declare_sample_delay(0)


What is the proper way to do the same command in C++?


Thanks in advance.

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

[Discuss-gnuradio] Multiplicative constant vector for multiply_const_vcc

[khalid.el-darymli]

Hi,

What is the proper way to set-up the multiplicative constant vector for
multiply_const_vcc?


I tried the code below and although it compiles, upon running the program I
get the following error:

*Segmentation fault (core dumped).*


The code:

std::vector k;
k[0]=0.1;

blocks::multiply_const_vcc::sptr multiply_const_0 =
blocks::multiply_const_vcc::make(k);


I'll appreciate your help.

Thank you.

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

Re: [Discuss-gnuradio] Max Output Power from the LFTX

[khalid.el-darymli]

I see. Is there someone we can contact at Ettus for this?

Khalid

On Fri, Jan 16, 2015 at 4:29 PM, Marcus D. Leech  wrote:

>  On 01/16/2015 02:54 PM, khalid.el-darymli wrote:
>
> I see. If you would like to diagnose the problem, we can ship you the
> malfunctioned daughterboard?
>
>  Thanks,
> Khalid
>
>   Thanks.  I personally wouldn't have time/equipment to really diagnose
> it.  So it would be up to Ettus R&D as to whether they want it back to see
>   what the failure mode is.
>
> I've been doing Ettus support for 6 years, and LF_TX are not generally
> items that show up with RMA requests very often.
>
>
>
>
> On Fri, Jan 16, 2015 at 4:17 PM, Marcus D. Leech 
> wrote:
>
>>  On 01/16/2015 02:42 PM, khalid.el-darymli wrote:
>>
>> We were using only one Tx channel with the Subdev Spec in the USRP Sink
>> is set to A:AB
>>
>>  Could the failure be due to that the other (idle) Tx channel is left
>> open circuit (i.e., not terminated by 50 ohms)?
>>
>>  That seems quite unlikely.  These aren't "precious princess" RF power
>> transistors, but reasonably-robust differential-to-unbalanced drivers.  I'd
>>   be very surprised if they couldn't handle an open-circuit condition.
>>
>>
>>
>>
>>
>>  Khalid
>>
>>
>> On Fri, Jan 16, 2015 at 3:41 PM, Marcus D. Leech 
>> wrote:
>>
>>>  On 01/16/2015 02:08 PM, khalid.el-darymli wrote:
>>>
>>> Hi All,
>>>
>>>  Just to update you in case somebody else comes across this problem.
>>> Following Mike's advice, we replaced the LFTX daughterboard with a new one.
>>> We're getting now 1 V p-p. This is around 4 dBm.
>>>
>>>  Thanks very much for your help.
>>>
>>>  Best regards,
>>> Khalid
>>>
>>>
>>>   Interesting.  The driver chip that's used, as a unity-gain
>>> differential-to-single-ended driver, is, according to the datasheets,
>>> pretty robust.  So, it would
>>>   be interesting to know exactly what the failure mode is.
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jan 6, 2015 at 2:38 PM, Michael Rahaim  wrote:
>>>
>>>> Hi Khalid,
>>>>
>>>>  I had a similar issue with an LFTX that I had been working with for
>>>> about two years. I actually had two boards running on separate USRP2's and
>>>> both were working fine for quite a while, but I recently noticed that one
>>>> had a drastically lower output range. I ended up replacing the LFTX and all
>>>> is working well now, so I'm assuming it was a hardware issue that came up
>>>> at some point.
>>>>
>>>>  I didn't take the time to look for the problem, but I figured I'd
>>>> share this info since what you're seeing might be a hardware issue rather
>>>> than something you can resolve with settings.
>>>>
>>>>  -Mike
>>>>
>>>>  On Tue, Jan 6, 2015 at 12:59 PM, khalid.el-darymli <
>>>> khalid.el-dary...@mun.ca> wrote:
>>>>
>>>>>
>>>>> >> Output power is determined largely by baseband signal magnitude in
>>>>> that case.
>>>>>  Yes, I understand. And I noticed that for baseband signal with an
>>>>> amplitude *> 1, * the pass-band signal gets clipped off. So I assume
>>>>> that an amplitude of 1 for the baseband signal should deliver the maximum
>>>>> output power (for the pass-band signal).
>>>>>
>>>>>  My question was, what is the maximum power one can get for the
>>>>> pass-band signal output from LFTX? In your earlier reply, you said it is
>>>>> around +7dBm, am I getting this right? In my case, for a baseband 
>>>>> amplitude
>>>>> of around 1, I am only getting *-28.13dBm*, much less than what you
>>>>> said, I am not sure,* why?*
>>>>>
>>>>>  Thanks,
>>>>>  Khalid
>>>>>
>>>>>
>>>>> On Tue, Jan 6, 2015 at 1:56 PM, Marcus D. Leech 
>>>>> wrote:
>>>>>
>>>>>>   Thanks Marcus for your reply.
>>>>>>
>>>>>> >> Probably somewhere in the neighborhood of +7dBm, maybe a little
>>>>>> more.
>>>>>>
>>>>>>  >> The LF/BASIC series have *no* gain in either path, so you're
>>>>>

Re: [Discuss-gnuradio] Max Output Power from the LFTX

[khalid.el-darymli]

I see. If you would like to diagnose the problem, we can ship you the
malfunctioned daughterboard?

Thanks,
Khalid


On Fri, Jan 16, 2015 at 4:17 PM, Marcus D. Leech  wrote:

>  On 01/16/2015 02:42 PM, khalid.el-darymli wrote:
>
> We were using only one Tx channel with the Subdev Spec in the USRP Sink is
> set to A:AB
>
>  Could the failure be due to that the other (idle) Tx channel is left
> open circuit (i.e., not terminated by 50 ohms)?
>
> That seems quite unlikely.  These aren't "precious princess" RF power
> transistors, but reasonably-robust differential-to-unbalanced drivers.  I'd
>   be very surprised if they couldn't handle an open-circuit condition.
>
>
>
>
>
>  Khalid
>
>
> On Fri, Jan 16, 2015 at 3:41 PM, Marcus D. Leech 
> wrote:
>
>>  On 01/16/2015 02:08 PM, khalid.el-darymli wrote:
>>
>> Hi All,
>>
>>  Just to update you in case somebody else comes across this problem.
>> Following Mike's advice, we replaced the LFTX daughterboard with a new one.
>> We're getting now 1 V p-p. This is around 4 dBm.
>>
>>  Thanks very much for your help.
>>
>>  Best regards,
>> Khalid
>>
>>
>>   Interesting.  The driver chip that's used, as a unity-gain
>> differential-to-single-ended driver, is, according to the datasheets,
>> pretty robust.  So, it would
>>   be interesting to know exactly what the failure mode is.
>>
>>
>>
>>
>>
>> On Tue, Jan 6, 2015 at 2:38 PM, Michael Rahaim  wrote:
>>
>>> Hi Khalid,
>>>
>>>  I had a similar issue with an LFTX that I had been working with for
>>> about two years. I actually had two boards running on separate USRP2's and
>>> both were working fine for quite a while, but I recently noticed that one
>>> had a drastically lower output range. I ended up replacing the LFTX and all
>>> is working well now, so I'm assuming it was a hardware issue that came up
>>> at some point.
>>>
>>>  I didn't take the time to look for the problem, but I figured I'd
>>> share this info since what you're seeing might be a hardware issue rather
>>> than something you can resolve with settings.
>>>
>>>  -Mike
>>>
>>>  On Tue, Jan 6, 2015 at 12:59 PM, khalid.el-darymli <
>>> khalid.el-dary...@mun.ca> wrote:
>>>
>>>>
>>>> >> Output power is determined largely by baseband signal magnitude in
>>>> that case.
>>>>  Yes, I understand. And I noticed that for baseband signal with an
>>>> amplitude *> 1, * the pass-band signal gets clipped off. So I assume
>>>> that an amplitude of 1 for the baseband signal should deliver the maximum
>>>> output power (for the pass-band signal).
>>>>
>>>>  My question was, what is the maximum power one can get for the
>>>> pass-band signal output from LFTX? In your earlier reply, you said it is
>>>> around +7dBm, am I getting this right? In my case, for a baseband amplitude
>>>> of around 1, I am only getting *-28.13dBm*, much less than what you
>>>> said, I am not sure,* why?*
>>>>
>>>>  Thanks,
>>>>  Khalid
>>>>
>>>>
>>>> On Tue, Jan 6, 2015 at 1:56 PM, Marcus D. Leech 
>>>> wrote:
>>>>
>>>>>   Thanks Marcus for your reply.
>>>>>
>>>>> >> Probably somewhere in the neighborhood of +7dBm, maybe a little
>>>>> more.
>>>>>
>>>>>  >> The LF/BASIC series have *no* gain in either path, so you're just
>>>>> looked
>>>>> at buffered ADC ouput.
>>>>>
>>>>> So, ~ *+7dBm* is the max output power I supposed to get from the LFTX
>>>>> daughterboard? How do I get that?
>>>>>
>>>>>  Since I am only getting -28.13 dBm, does that mean I have some issue
>>>>> with my LFTX daughterboard?
>>>>>
>>>>>
>>>>>  Khalid
>>>>>
>>>>>
>>>>>Output power is determined largely by baseband signal magnitude in
>>>>> that case.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Message: 2
>>>>> Date: Tue, 6 Jan 2015 10:13:45 -0330
>>>>> From: "khalid.el-darymli"

Re: [Discuss-gnuradio] Max Output Power from the LFTX

[khalid.el-darymli]

We were using only one Tx channel with the Subdev Spec in the USRP Sink is
set to A:AB

Could the failure be due to that the other (idle) Tx channel is left open
circuit (i.e., not terminated by 50 ohms)?

Khalid


On Fri, Jan 16, 2015 at 3:41 PM, Marcus D. Leech  wrote:

>  On 01/16/2015 02:08 PM, khalid.el-darymli wrote:
>
> Hi All,
>
>  Just to update you in case somebody else comes across this problem.
> Following Mike's advice, we replaced the LFTX daughterboard with a new one.
> We're getting now 1 V p-p. This is around 4 dBm.
>
>  Thanks very much for your help.
>
>  Best regards,
> Khalid
>
>
>   Interesting.  The driver chip that's used, as a unity-gain
> differential-to-single-ended driver, is, according to the datasheets,
> pretty robust.  So, it would
>   be interesting to know exactly what the failure mode is.
>
>
>
>
>
> On Tue, Jan 6, 2015 at 2:38 PM, Michael Rahaim  wrote:
>
>> Hi Khalid,
>>
>>  I had a similar issue with an LFTX that I had been working with for
>> about two years. I actually had two boards running on separate USRP2's and
>> both were working fine for quite a while, but I recently noticed that one
>> had a drastically lower output range. I ended up replacing the LFTX and all
>> is working well now, so I'm assuming it was a hardware issue that came up
>> at some point.
>>
>>  I didn't take the time to look for the problem, but I figured I'd share
>> this info since what you're seeing might be a hardware issue rather than
>> something you can resolve with settings.
>>
>>  -Mike
>>
>>  On Tue, Jan 6, 2015 at 12:59 PM, khalid.el-darymli <
>> khalid.el-dary...@mun.ca> wrote:
>>
>>>
>>> >> Output power is determined largely by baseband signal magnitude in
>>> that case.
>>>  Yes, I understand. And I noticed that for baseband signal with an
>>> amplitude *> 1, * the pass-band signal gets clipped off. So I assume
>>> that an amplitude of 1 for the baseband signal should deliver the maximum
>>> output power (for the pass-band signal).
>>>
>>>  My question was, what is the maximum power one can get for the
>>> pass-band signal output from LFTX? In your earlier reply, you said it is
>>> around +7dBm, am I getting this right? In my case, for a baseband amplitude
>>> of around 1, I am only getting *-28.13dBm*, much less than what you
>>> said, I am not sure,* why?*
>>>
>>>  Thanks,
>>>  Khalid
>>>
>>>
>>> On Tue, Jan 6, 2015 at 1:56 PM, Marcus D. Leech 
>>> wrote:
>>>
>>>>   Thanks Marcus for your reply.
>>>>
>>>> >> Probably somewhere in the neighborhood of +7dBm, maybe a little more.
>>>>
>>>>  >> The LF/BASIC series have *no* gain in either path, so you're just
>>>> looked
>>>> at buffered ADC ouput.
>>>>
>>>> So, ~ *+7dBm* is the max output power I supposed to get from the LFTX
>>>> daughterboard? How do I get that?
>>>>
>>>>  Since I am only getting -28.13 dBm, does that mean I have some issue
>>>> with my LFTX daughterboard?
>>>>
>>>>
>>>>  Khalid
>>>>
>>>>
>>>>Output power is determined largely by baseband signal magnitude in
>>>> that case.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Message: 2
>>>> Date: Tue, 6 Jan 2015 10:13:45 -0330
>>>> From: "khalid.el-darymli" 
>>>> To: "Discuss-gnuradio@gnu.org" 
>>>> Subject: [Discuss-gnuradio] Max Output Power from the LFTX
>>>> daughterboard
>>>> Message-ID:
>>>> >>> 5GQr0y=wksequrcajrtuv5...@mail.gmail.com>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> Hi,
>>>>
>>>> What is the maximum output power from the LFTX daughterboard when used
>>>> with
>>>> the USRP N200?
>>>>
>>>> According to this datasheet [1], the N200 with the WBX daughterbaord
>>>> provide an output power of 15 dBm. However, when using the LFTX
>>>> daughterboard, I am getting a much less output power.
>>>> [1]
>>>> http://www.ettus.com/content/files/07495_Ettus_N200-210_DS_Flyer_HR.pdf
>>>>
>>>> In GNU Radio with the USRP N200, we use a si

Re: [Discuss-gnuradio] Max Output Power from the LFTX

[khalid.el-darymli]

Hi All,

Just to update you in case somebody else comes across this problem.
Following Mike's advice, we replaced the LFTX daughterboard with a new one.
We're getting now 1 V p-p. This is around 4 dBm.

Thanks very much for your help.

Best regards,
Khalid




On Tue, Jan 6, 2015 at 2:38 PM, Michael Rahaim  wrote:

> Hi Khalid,
>
> I had a similar issue with an LFTX that I had been working with for about
> two years. I actually had two boards running on separate USRP2's and both
> were working fine for quite a while, but I recently noticed that one had a
> drastically lower output range. I ended up replacing the LFTX and all is
> working well now, so I'm assuming it was a hardware issue that came up at
> some point.
>
> I didn't take the time to look for the problem, but I figured I'd share
> this info since what you're seeing might be a hardware issue rather than
> something you can resolve with settings.
>
> -Mike
>
> On Tue, Jan 6, 2015 at 12:59 PM, khalid.el-darymli <
> khalid.el-dary...@mun.ca> wrote:
>
>>
>> >> Output power is determined largely by baseband signal magnitude in
>> that case.
>> Yes, I understand. And I noticed that for baseband signal with an
>> amplitude *> 1, * the pass-band signal gets clipped off. So I assume
>> that an amplitude of 1 for the baseband signal should deliver the maximum
>> output power (for the pass-band signal).
>>
>> My question was, what is the maximum power one can get for the pass-band
>> signal output from LFTX? In your earlier reply, you said it is around
>> +7dBm, am I getting this right? In my case, for a baseband amplitude of
>> around 1, I am only getting *-28.13dBm*, much less than what you said, I
>> am not sure,* why?*
>>
>> Thanks,
>> Khalid
>>
>>
>> On Tue, Jan 6, 2015 at 1:56 PM, Marcus D. Leech 
>> wrote:
>>
>>>Thanks Marcus for your reply.
>>>
>>> >> Probably somewhere in the neighborhood of +7dBm, maybe a little more.
>>>
>>>  >> The LF/BASIC series have *no* gain in either path, so you're just
>>> looked
>>> at buffered ADC ouput.
>>>
>>> So, ~ *+7dBm* is the max output power I supposed to get from the LFTX
>>> daughterboard? How do I get that?
>>>
>>>  Since I am only getting -28.13 dBm, does that mean I have some issue
>>> with my LFTX daughterboard?
>>>
>>>
>>>  Khalid
>>>
>>>
>>>   Output power is determined largely by baseband signal magnitude in
>>> that case.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Message: 2
>>> Date: Tue, 6 Jan 2015 10:13:45 -0330
>>> From: "khalid.el-darymli" 
>>> To: "Discuss-gnuradio@gnu.org" 
>>> Subject: [Discuss-gnuradio] Max Output Power from the LFTX
>>> daughterboard
>>> Message-ID:
>>> >> 5GQr0y=wksequrcajrtuv5...@mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Hi,
>>>
>>> What is the maximum output power from the LFTX daughterboard when used
>>> with
>>> the USRP N200?
>>>
>>> According to this datasheet [1], the N200 with the WBX daughterbaord
>>> provide an output power of 15 dBm. However, when using the LFTX
>>> daughterboard, I am getting a much less output power.
>>> [1]
>>> http://www.ettus.com/content/files/07495_Ettus_N200-210_DS_Flyer_HR.pdf
>>>
>>> In GNU Radio with the USRP N200, we use a sinusoid with a frequency of
>>> 150
>>> kHz and an amplitude of 0.98, fed into the LFTX daughterboard for a
>>> center
>>> frequency of 5 MHz. When the output of LFTX is plugged into a scope
>>> terminated with a 50-ohm terminator, the scope reads 24.8 mV
>>> (peak-to-peak). This is around -28.13 dBm.
>>>
>>> Is this the max power one can get out of the LFTX daughterboard?
>>>
>>>
>>> Thanks.
>>>
>>> Best regards,
>>> Khalid
>>> -- next part --
>>> An HTML attachment was scrubbed...
>>> URL: <
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150106/37846ff4/attachment.html
>>> >
>>>
>>> --
>>>
>>> Message: 3
>>> Date: Tue, 06 Jan 2015 08:48:08 -0500
>>> From: "Marcus D. Leech" 
>>> To: discuss-gnuradio@gnu.org
&

[Discuss-gnuradio] Two Tx channels, one motherboard (N200+LFTX)

[khalid.el-darymli]

Hi,

Is it possible to use two separate Tx channels (A:A A:B with two different
center frequencies) for the N200 with the LFTX daughterboard?

I tried to do this on the Rx side and it seems to work just fine. However,
on the Tx side, I am getting the following error message:


line 97, in __init__
self.uhd_usrp_sink_0.set_subdev_spec("A:A A:B", 0)
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3447, in set_subdev_spec
return _uhd_swig.usrp_sink_sptr_set_subdev_spec(self, *args, **kwargs)
RuntimeError: ValueError: The subdevice specification "A:A A:B" is too long.
The user specified 2 channels, but there are only 1 tx dsps on mboard 0.


Thanks.

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

Re: [Discuss-gnuradio] Issue with Virtual Sink/Source

[khalid.el-darymli]

Thanks Johnathan for the update.
BTW, with the recent installation, I am also getting the following warning
when running my GRC or the GRC-generated python script,

fft_impl_fftw: /home/ov/.gr_fftw_wisdom: Permission denied
fft_impl_fftw: /home/ov/.gr_fftw_wisdom: Permission denied
fft_impl_fftw: /home/ov/.gr_fftw_wisdom: Permission denied
.
.
.
fft_impl_fftw: /home/oceanview/.gr_fftw_wisdom: Permission denied

This warning is repeated in the terminal like 100 times before the script
actually runs. I am not sure why?

Thanks.

Best regards,
Khalid


On Mon, Jan 12, 2015 at 10:21 PM, Johnathan Corgan  wrote:

> On 01/12/2015 05:44 PM, Johnathan Corgan wrote:
> > On 01/12/2015 02:25 PM, Richard Clarke wrote:
> >
> >> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
> >> line 93, in __getattr__
> >> return getattr(self._impl, name)
> >> *AttributeError: 'top_block_sptr' object has no attribute
> >> 'virtual_source_0'*
> >
> > This may be related to a recent change that was done prior to the 3.7.6
> > release.  I'm investigating.
>
> I've replicated this problem locally, working on a fix.
>
> --
> Johnathan Corgan, Corgan Labs
> SDR/DSP Training and Consulting Services
> http://corganlabs.com
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] U's and L's when running GNU Radio

[khalid.el-darymli]

Hi Marcus, Hi Sylvain,


Thank you for your response. I continue to get these U
even on a PC with really high specs.

Please find below my answers to your questions.


>> Do you use timed_commands?

Yes, I do. In the python script, I simply use get_time_now() to query
the times of both the Sink and the Source. Then, I convert this to a
format understandable to python and I keep hold of the greater time of
the two, I call it start_delay. Then, using set_start_time(), I make
sure that both the Sink and the Source start at time start_delay.

Is there any problem with my timed_commands?


>> What are your RX and TX sampling rates?

It's 100e06/256 = 390,625 Hz for both Tx and Rx.


>> From your network throughput, I'd assume your using 4x 3.3MS/s, is that 
>> correct?

I am using four Rx channels, and just one Tx channel. Based on the NW
history in the link below,

https://lists.gnu.org/archive/html/discuss-gnuradio/2015-01/png5hOoJln6ra.png


My throughput is around 1.6 MB/s for each channel. This is set
automatically by GNU Radio. Do I need to adjust it?


Thank you.

Best regards,

Khalid









*Re: U's and L's when running GNU Radio
*
 [image: D17685d174fee4ca258c75cce7bc2202?d=identicon&s=25] Marcus Müller
(Guest)
 on 2015-01-07 15:24
[image: (Received via mailing list)]

Hello Sylvain, hello Khalid,

these could be underruns (U) and late (L) packets, as reported by UHD,
used via gr-uhd; however, seeing so many L's is a very uncommon pattern;
Do you use timed_commands? What are your RX and TX sampling rates? From
your network throughput, I'd assume your using 4x 3.3MS/s, is that
correct?

Could you share the whole output of your program's run, not only the
U... ?

Best regards,
Marcus






*Re: U's and L's when running GNU Radio
*
 [image: 0817fa933c74eec9b3fcf3a04e16f418?d=identicon&s=25] Sylvain Munaut
(Guest)
 on 2015-01-07 14:48
[image: (Received via mailing list)]

Hi,
> In the terminal and while using a powerful PC (please see the attachment), I> 
> am occasionally getting capital U's and L's when running GNU Radio with one> 
> Tx and 4 Rx channels (Here is a sample of what I am getting:> 
> ULLLUULLLULLLU).

I can't find anything in GNURadio itself that would print that.

The only thing it can print AFAICT is aU aO jU

So it must be an OOT block that display those ...

Cheers,

   Sylvain







*U's and L's when running GNU Radio
*
 [image: 03a87ab164b2170c1bb9750462ca0053?d=identicon&s=25] Khalid
Eldarymli (khalide )
 on 2015-01-05 17:50
[image: (Received via mailing list)]
Attachment: SystemMonitor.png
 (100 KB)


Hi,

In the terminal and while using a powerful PC (please see the
attachment),
I am occasionally getting capital U's and L's when running GNU Radio
with
one Tx and 4 Rx channels (Here is a sample of what I am getting:
ULLLUULLLULLLU).

Please note that I am using timed-commands to start both the Tx and Rx's
at
the same time. When I check the System Monitor while GNU Radio is
running
(please see the attachment), the CPU history and RAM usage seem to be
fine.
Also, swap memory is disabled as shown in the attachment. What causes
this
issue and how to handle it? Could it be due to some instability in the
writing speed to the hard drive?

BTW, I am having the same issue for my older PC (a PC with less specs).
The
System Monitor tells me that my CPU usage is around 60% and my RAM usage
is
around 45%, however, I am getting U's and L's when I try to use four Rx
channels. Please note that the system doesn't throw lots of U's and L's
at
once, it is a kind of frequent where a bunch of them are thrown out
every
many seconds or so.

Thanks in advance for your help.

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

Re: [Discuss-gnuradio] Max Output Power from the LFTX

[khalid.el-darymli]

Yes, it is 1 Mohm, and my probe is set to 1X.

Khalid


On Tue, Jan 6, 2015 at 3:33 PM, Nick Foster  wrote:

> Is the input impedance of your scope 1Mohm or 50 ohms? You sure you have
> the voltage multiplier (1x/10x) set correctly?
>
> On Tue, Jan 6, 2015 at 11:01 AM, khalid.el-darymli <
> khalid.el-dary...@mun.ca> wrote:
>
>> >> Trying setting a gain in your sink block of, let's say, 20dB, with a
>> magnitude of 0.9.  What power output do you get?   How are you measuring
>> power?
>>
>> This gives me 23.2 mV (peak to peak). This is the reading I get from a
>> scope connected to a T. For the input ends of the T, one end is connected
>> to a 50-ohm terminator and the other end is connected to the output from
>> LFTX. This gives a power of: 30+10 log_10[{23.2e-03/[2*sqrt(2)]}^2/50]=
>> *-28.711* dBm.
>>
>> >> What is your flow-graph actually doing?  Have you tried both
>> connectors on the LFTX?
>>
>> Simple, a signal source (Sine) block directly connected to a USRP Sink
>> block.
>> Yes, both connectors on the LFTX daughterboard give the same voltage
>> reading.
>>
>> Thanks,
>> Khalid
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Jan 6, 2015 at 2:34 PM, Marcus D. Leech 
>> wrote:
>>
>>>
>>> >> Output power is determined largely by baseband signal magnitude in
>>> that case.
>>>  Yes, I understand. And I noticed that for baseband signal with an
>>> amplitude *> 1, * the pass-band signal gets clipped off. So I assume
>>> that an amplitude of 1 for the baseband signal should deliver the maximum
>>> output power (for the pass-band signal).
>>>
>>>  My question was, what is the maximum power one can get for the
>>> pass-band signal output from LFTX? In your earlier reply, you said it is
>>> around +7dBm, am I getting this right? In my case, for a baseband amplitude
>>> of around 1, I am only getting *-28.13dBm*, much less than what you
>>> said, I am not sure,* why?*
>>>
>>>  Thanks,
>>>  Khalid
>>>
>>>   For a magnitude of ~1, you should see maximum amplitude signals
>>> coming out of it.
>>>
>>> You could try setting gain, but on any platforms with VGAs in the DAC,
>>> there's only about 6dB of gain range settable.  Trying setting a gain in
>>> your
>>>   sink block of, let's say, 20dB, with a magnitude of 0.9.  What power
>>> output do you get?   How are you measuring power?  What is your flow-graph
>>>   actually doing?  Have you tried both connectors on the LFTX?
>>>
>>>
>>>
>>>
>>> On Tue, Jan 6, 2015 at 1:56 PM, Marcus D. Leech 
>>> wrote:
>>>
>>>>Thanks Marcus for your reply.
>>>>
>>>> >> Probably somewhere in the neighborhood of +7dBm, maybe a little more.
>>>>
>>>>  >> The LF/BASIC series have *no* gain in either path, so you're just
>>>> looked
>>>> at buffered ADC ouput.
>>>>
>>>> So, ~ *+7dBm* is the max output power I supposed to get from the LFTX
>>>> daughterboard? How do I get that?
>>>>
>>>>  Since I am only getting -28.13 dBm, does that mean I have some issue
>>>> with my LFTX daughterboard?
>>>>
>>>>
>>>>  Khalid
>>>>
>>>>
>>>>Output power is determined largely by baseband signal magnitude in
>>>> that case.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Message: 2
>>>> Date: Tue, 6 Jan 2015 10:13:45 -0330
>>>> From: "khalid.el-darymli" 
>>>> To: "Discuss-gnuradio@gnu.org" 
>>>> Subject: [Discuss-gnuradio] Max Output Power from the LFTX
>>>> daughterboard
>>>> Message-ID:
>>>> >>> 5GQr0y=wksequrcajrtuv5...@mail.gmail.com>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> Hi,
>>>>
>>>> What is the maximum output power from the LFTX daughterboard when used
>>>> with
>>>> the USRP N200?
>>>>
>>>> According to this datasheet [1], the N200 with the WBX daughterbaord
>>>> provide an output power of 15 dBm. However, when using the LFTX
>>>> daughterboard, I am getting a much less output power.
&

Re: [Discuss-gnuradio] Max Output Power from the LFTX

[khalid.el-darymli]

>> Trying setting a gain in your sink block of, let's say, 20dB, with a
magnitude of 0.9.  What power output do you get?   How are you measuring
power?

This gives me 23.2 mV (peak to peak). This is the reading I get from a
scope connected to a T. For the input ends of the T, one end is connected
to a 50-ohm terminator and the other end is connected to the output from
LFTX. This gives a power of: 30+10 log_10[{23.2e-03/[2*sqrt(2)]}^2/50]=
*-28.711* dBm.

>> What is your flow-graph actually doing?  Have you tried both connectors
on the LFTX?

Simple, a signal source (Sine) block directly connected to a USRP Sink
block.
Yes, both connectors on the LFTX daughterboard give the same voltage
reading.

Thanks,
Khalid










On Tue, Jan 6, 2015 at 2:34 PM, Marcus D. Leech  wrote:

>
> >> Output power is determined largely by baseband signal magnitude in that
> case.
>  Yes, I understand. And I noticed that for baseband signal with an
> amplitude *> 1, * the pass-band signal gets clipped off. So I assume that
> an amplitude of 1 for the baseband signal should deliver the maximum output
> power (for the pass-band signal).
>
>  My question was, what is the maximum power one can get for the pass-band
> signal output from LFTX? In your earlier reply, you said it is around
> +7dBm, am I getting this right? In my case, for a baseband amplitude of
> around 1, I am only getting *-28.13dBm*, much less than what you said, I
> am not sure,* why?*
>
>  Thanks,
>  Khalid
>
>   For a magnitude of ~1, you should see maximum amplitude signals coming
> out of it.
>
> You could try setting gain, but on any platforms with VGAs in the DAC,
> there's only about 6dB of gain range settable.  Trying setting a gain in
> your
>   sink block of, let's say, 20dB, with a magnitude of 0.9.  What power
> output do you get?   How are you measuring power?  What is your flow-graph
>   actually doing?  Have you tried both connectors on the LFTX?
>
>
>
>
> On Tue, Jan 6, 2015 at 1:56 PM, Marcus D. Leech  wrote:
>
>>Thanks Marcus for your reply.
>>
>> >> Probably somewhere in the neighborhood of +7dBm, maybe a little more.
>>
>>  >> The LF/BASIC series have *no* gain in either path, so you're just
>> looked
>> at buffered ADC ouput.
>>
>> So, ~ *+7dBm* is the max output power I supposed to get from the LFTX
>> daughterboard? How do I get that?
>>
>>  Since I am only getting -28.13 dBm, does that mean I have some issue
>> with my LFTX daughterboard?
>>
>>
>>  Khalid
>>
>>
>>Output power is determined largely by baseband signal magnitude in
>> that case.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Message: 2
>> Date: Tue, 6 Jan 2015 10:13:45 -0330
>> From: "khalid.el-darymli" 
>> To: "Discuss-gnuradio@gnu.org" 
>> Subject: [Discuss-gnuradio] Max Output Power from the LFTX
>> daughterboard
>> Message-ID:
>> > 5GQr0y=wksequrcajrtuv5...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi,
>>
>> What is the maximum output power from the LFTX daughterboard when used
>> with
>> the USRP N200?
>>
>> According to this datasheet [1], the N200 with the WBX daughterbaord
>> provide an output power of 15 dBm. However, when using the LFTX
>> daughterboard, I am getting a much less output power.
>> [1]
>> http://www.ettus.com/content/files/07495_Ettus_N200-210_DS_Flyer_HR.pdf
>>
>> In GNU Radio with the USRP N200, we use a sinusoid with a frequency of 150
>> kHz and an amplitude of 0.98, fed into the LFTX daughterboard for a center
>> frequency of 5 MHz. When the output of LFTX is plugged into a scope
>> terminated with a 50-ohm terminator, the scope reads 24.8 mV
>> (peak-to-peak). This is around -28.13 dBm.
>>
>> Is this the max power one can get out of the LFTX daughterboard?
>>
>>
>> Thanks.
>>
>> Best regards,
>> Khalid
>> ------ next part --
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150106/37846ff4/attachment.html
>> >
>>
>> --
>>
>> Message: 3
>> Date: Tue, 06 Jan 2015 08:48:08 -0500
>> From: "Marcus D. Leech" 
>> To: discuss-gnuradio@gnu.org
>> Subject: Re: [Discuss-gnuradio] Max Output Power from the LFTX
>> daughterboard
>> Message-ID: <54abe798.5060...@ripnet.com>
>> Content-Type: text/plain; charset=UTF-8; format=flowed

Re: [Discuss-gnuradio] Max Output Power from the LFTX

[khalid.el-darymli]

Thanks Mike. I appreciate your comment.
I'll look into buying a new LFTX.

Khalid

On Tue, Jan 6, 2015 at 2:38 PM, Michael Rahaim  wrote:

> Hi Khalid,
>
> I had a similar issue with an LFTX that I had been working with for about
> two years. I actually had two boards running on separate USRP2's and both
> were working fine for quite a while, but I recently noticed that one had a
> drastically lower output range. I ended up replacing the LFTX and all is
> working well now, so I'm assuming it was a hardware issue that came up at
> some point.
>
> I didn't take the time to look for the problem, but I figured I'd share
> this info since what you're seeing might be a hardware issue rather than
> something you can resolve with settings.
>
> -Mike
>
> On Tue, Jan 6, 2015 at 12:59 PM, khalid.el-darymli <
> khalid.el-dary...@mun.ca> wrote:
>
>>
>> >> Output power is determined largely by baseband signal magnitude in
>> that case.
>> Yes, I understand. And I noticed that for baseband signal with an
>> amplitude *> 1, * the pass-band signal gets clipped off. So I assume
>> that an amplitude of 1 for the baseband signal should deliver the maximum
>> output power (for the pass-band signal).
>>
>> My question was, what is the maximum power one can get for the pass-band
>> signal output from LFTX? In your earlier reply, you said it is around
>> +7dBm, am I getting this right? In my case, for a baseband amplitude of
>> around 1, I am only getting *-28.13dBm*, much less than what you said, I
>> am not sure,* why?*
>>
>> Thanks,
>> Khalid
>>
>>
>> On Tue, Jan 6, 2015 at 1:56 PM, Marcus D. Leech 
>> wrote:
>>
>>>Thanks Marcus for your reply.
>>>
>>> >> Probably somewhere in the neighborhood of +7dBm, maybe a little more.
>>>
>>>  >> The LF/BASIC series have *no* gain in either path, so you're just
>>> looked
>>> at buffered ADC ouput.
>>>
>>> So, ~ *+7dBm* is the max output power I supposed to get from the LFTX
>>> daughterboard? How do I get that?
>>>
>>>  Since I am only getting -28.13 dBm, does that mean I have some issue
>>> with my LFTX daughterboard?
>>>
>>>
>>>  Khalid
>>>
>>>
>>>   Output power is determined largely by baseband signal magnitude in
>>> that case.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Message: 2
>>> Date: Tue, 6 Jan 2015 10:13:45 -0330
>>> From: "khalid.el-darymli" 
>>> To: "Discuss-gnuradio@gnu.org" 
>>> Subject: [Discuss-gnuradio] Max Output Power from the LFTX
>>> daughterboard
>>> Message-ID:
>>> >> 5GQr0y=wksequrcajrtuv5...@mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Hi,
>>>
>>> What is the maximum output power from the LFTX daughterboard when used
>>> with
>>> the USRP N200?
>>>
>>> According to this datasheet [1], the N200 with the WBX daughterbaord
>>> provide an output power of 15 dBm. However, when using the LFTX
>>> daughterboard, I am getting a much less output power.
>>> [1]
>>> http://www.ettus.com/content/files/07495_Ettus_N200-210_DS_Flyer_HR.pdf
>>>
>>> In GNU Radio with the USRP N200, we use a sinusoid with a frequency of
>>> 150
>>> kHz and an amplitude of 0.98, fed into the LFTX daughterboard for a
>>> center
>>> frequency of 5 MHz. When the output of LFTX is plugged into a scope
>>> terminated with a 50-ohm terminator, the scope reads 24.8 mV
>>> (peak-to-peak). This is around -28.13 dBm.
>>>
>>> Is this the max power one can get out of the LFTX daughterboard?
>>>
>>>
>>> Thanks.
>>>
>>> Best regards,
>>> Khalid
>>> -- next part --
>>> An HTML attachment was scrubbed...
>>> URL: <
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150106/37846ff4/attachment.html
>>> >
>>>
>>> --
>>>
>>> Message: 3
>>> Date: Tue, 06 Jan 2015 08:48:08 -0500
>>> From: "Marcus D. Leech" 
>>> To: discuss-gnuradio@gnu.org
>>> Subject: Re: [Discuss-gnuradio] Max Output Power from the LFTX
>>> daughterboard
>>> Message-ID: <54abe798.5060...@ripnet.com>
>&

Re: [Discuss-gnuradio] Max Output Power from the LFTX

[khalid.el-darymli]

>> Output power is determined largely by baseband signal magnitude in that
case.
Yes, I understand. And I noticed that for baseband signal with an amplitude *>
1, * the pass-band signal gets clipped off. So I assume that an amplitude
of 1 for the baseband signal should deliver the maximum output power (for
the pass-band signal).

My question was, what is the maximum power one can get for the pass-band
signal output from LFTX? In your earlier reply, you said it is around
+7dBm, am I getting this right? In my case, for a baseband amplitude of
around 1, I am only getting *-28.13dBm*, much less than what you said, I am
not sure,* why?*

Thanks,
Khalid


On Tue, Jan 6, 2015 at 1:56 PM, Marcus D. Leech  wrote:

>Thanks Marcus for your reply.
>
> >> Probably somewhere in the neighborhood of +7dBm, maybe a little more.
>
>  >> The LF/BASIC series have *no* gain in either path, so you're just
> looked
> at buffered ADC ouput.
>
> So, ~ *+7dBm* is the max output power I supposed to get from the LFTX
> daughterboard? How do I get that?
>
>  Since I am only getting -28.13 dBm, does that mean I have some issue with
> my LFTX daughterboard?
>
>
>  Khalid
>
>
>   Output power is determined largely by baseband signal magnitude in that
> case.
>
>
>
>
>
>
>
>
>
> Message: 2
> Date: Tue, 6 Jan 2015 10:13:45 -0330
> From: "khalid.el-darymli" 
> To: "Discuss-gnuradio@gnu.org" 
> Subject: [Discuss-gnuradio] Max Output Power from the LFTX
> daughterboard
> Message-ID:
>  5GQr0y=wksequrcajrtuv5...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> What is the maximum output power from the LFTX daughterboard when used with
> the USRP N200?
>
> According to this datasheet [1], the N200 with the WBX daughterbaord
> provide an output power of 15 dBm. However, when using the LFTX
> daughterboard, I am getting a much less output power.
> [1]
> http://www.ettus.com/content/files/07495_Ettus_N200-210_DS_Flyer_HR.pdf
>
> In GNU Radio with the USRP N200, we use a sinusoid with a frequency of 150
> kHz and an amplitude of 0.98, fed into the LFTX daughterboard for a center
> frequency of 5 MHz. When the output of LFTX is plugged into a scope
> terminated with a 50-ohm terminator, the scope reads 24.8 mV
> (peak-to-peak). This is around -28.13 dBm.
>
> Is this the max power one can get out of the LFTX daughterboard?
>
>
> Thanks.
>
> Best regards,
> Khalid
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150106/37846ff4/attachment.html
> >
>
> --
>
> Message: 3
> Date: Tue, 06 Jan 2015 08:48:08 -0500
> From: "Marcus D. Leech" 
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Max Output Power from the LFTX
> daughterboard
> Message-ID: <54abe798.5060...@ripnet.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 01/06/2015 08:43 AM, khalid.el-darymli wrote:
> > Hi,
> >
> > What is the maximum output power from the LFTX daughterboard when used
> > with the USRP N200?
> >
> > According to this datasheet [1], the N200 with the WBX daughterbaord
> > provide an output power of 15 dBm. However, when using the LFTX
> > daughterboard, I am getting a much less output power.
> > [1]
> > http://www.ettus.com/content/files/07495_Ettus_N200-210_DS_Flyer_HR.pdf
> >
> > In GNU Radio with the USRP N200, we use a sinusoid with a frequency of
> > 150 kHz and an amplitude of 0.98, fed into the LFTX daughterboard for
> > a center frequency of 5 MHz. When the output of LFTX is plugged into a
> > scope terminated with a 50-ohm terminator, the scope reads 24.8 mV
> > (peak-to-peak). This is around -28.13 dBm.
> >
> > Is this the max power one can get out of the LFTX daughterboard?
> >
> >
> > Thanks.
> >
> > Best regards,
> > Khalid
> Probably somewhere in the neighborhood of +7dBm, maybe a little more.
>
> The LF/BASIC series have *no* gain in either path, so you're just looked
> at buffered ADC ouput.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Max Output Power from the LFTX

[khalid.el-darymli]

Thanks Marcus for your reply.

>> Probably somewhere in the neighborhood of +7dBm, maybe a little more.

>> The LF/BASIC series have *no* gain in either path, so you're just looked
at buffered ADC ouput.

So, ~ *+7dBm* is the max output power I supposed to get from the LFTX
daughterboard? How do I get that?

Since I am only getting -28.13 dBm, does that mean I have some issue with
my LFTX daughterboard?


Khalid






Message: 2
Date: Tue, 6 Jan 2015 10:13:45 -0330
From: "khalid.el-darymli" 
To: "Discuss-gnuradio@gnu.org" 
Subject: [Discuss-gnuradio] Max Output Power from the LFTX
daughterboard
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hi,

What is the maximum output power from the LFTX daughterboard when used with
the USRP N200?

According to this datasheet [1], the N200 with the WBX daughterbaord
provide an output power of 15 dBm. However, when using the LFTX
daughterboard, I am getting a much less output power.
[1] http://www.ettus.com/content/files/07495_Ettus_N200-210_DS_Flyer_HR.pdf

In GNU Radio with the USRP N200, we use a sinusoid with a frequency of 150
kHz and an amplitude of 0.98, fed into the LFTX daughterboard for a center
frequency of 5 MHz. When the output of LFTX is plugged into a scope
terminated with a 50-ohm terminator, the scope reads 24.8 mV
(peak-to-peak). This is around -28.13 dBm.

Is this the max power one can get out of the LFTX daughterboard?


Thanks.

Best regards,
Khalid
-- next part --
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150106/37846ff4/attachment.html
>

--

Message: 3
Date: Tue, 06 Jan 2015 08:48:08 -0500
From: "Marcus D. Leech" 
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Max Output Power from the LFTX
daughterboard
Message-ID: <54abe798.5060...@ripnet.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 01/06/2015 08:43 AM, khalid.el-darymli wrote:
> Hi,
>
> What is the maximum output power from the LFTX daughterboard when used
> with the USRP N200?
>
> According to this datasheet [1], the N200 with the WBX daughterbaord
> provide an output power of 15 dBm. However, when using the LFTX
> daughterboard, I am getting a much less output power.
> [1]
> http://www.ettus.com/content/files/07495_Ettus_N200-210_DS_Flyer_HR.pdf
>
> In GNU Radio with the USRP N200, we use a sinusoid with a frequency of
> 150 kHz and an amplitude of 0.98, fed into the LFTX daughterboard for
> a center frequency of 5 MHz. When the output of LFTX is plugged into a
> scope terminated with a 50-ohm terminator, the scope reads 24.8 mV
> (peak-to-peak). This is around -28.13 dBm.
>
> Is this the max power one can get out of the LFTX daughterboard?
>
>
> Thanks.
>
> Best regards,
> Khalid
Probably somewhere in the neighborhood of +7dBm, maybe a little more.

The LF/BASIC series have *no* gain in either path, so you're just looked
at buffered ADC ouput.



--
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

[Discuss-gnuradio] Max Output Power from the LFTX daughterboard

[khalid.el-darymli]

Hi,

What is the maximum output power from the LFTX daughterboard when used with
the USRP N200?

According to this datasheet [1], the N200 with the WBX daughterbaord
provide an output power of 15 dBm. However, when using the LFTX
daughterboard, I am getting a much less output power.
[1] http://www.ettus.com/content/files/07495_Ettus_N200-210_DS_Flyer_HR.pdf

In GNU Radio with the USRP N200, we use a sinusoid with a frequency of 150
kHz and an amplitude of 0.98, fed into the LFTX daughterboard for a center
frequency of 5 MHz. When the output of LFTX is plugged into a scope
terminated with a 50-ohm terminator, the scope reads 24.8 mV
(peak-to-peak). This is around -28.13 dBm.

Is this the max power one can get out of the LFTX daughterboard?


Thanks.

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

[Discuss-gnuradio] Issue with Virtual Sink/Source

[khalid.el-darymli]

Hi,

We recently bought a new PC with some powerful specs. GNU Radio was built
from the source and it seems to be installed fine. However, when I try to
use the virtual sink and source blocks in my flow graph, I am getting the
following error:

Traceback (most recent call last):
  File "./test_skh.py", line 595, in 
tb = test_skh()
  File "./test_skh.py", line 486, in __init__
self.connect((self.virtual_source_0, 0),
(self.blocks_multiply_conjugate_cc_0, 0))
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 93, in __getattr__
return getattr(self._impl, name)
*AttributeError: 'top_block_sptr' object has no attribute
'virtual_source_0'*


Once I replace the virtual blocks with direct connections, things work just
fine. What is the cause for this problem and how to fix it?

Please note that on an older machine, GNU Radio was installed around a
month ago following the same procedure followed here, and the virtual
sink/source blocks work just fine.

Thank you.

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

[Discuss-gnuradio] U's and L's when running GNU Radio

[khalid.el-darymli]

Hi,

In the terminal and while using a powerful PC (please see the attachment),
I am occasionally getting capital U's and L's when running GNU Radio with
one Tx and 4 Rx channels (Here is a sample of what I am getting:
ULLLUULLLULLLU).

Please note that I am using timed-commands to start both the Tx and Rx's at
the same time. When I check the System Monitor while GNU Radio is running
(please see the attachment), the CPU history and RAM usage seem to be fine.
Also, swap memory is disabled as shown in the attachment. What causes  this
issue and how to handle it? Could it be due to some instability in the
writing speed to the hard drive?

BTW, I am having the same issue for my older PC (a PC with less specs). The
System Monitor tells me that my CPU usage is around 60% and my RAM usage is
around 45%, however, I am getting U's and L's when I try to use four Rx
channels. Please note that the system doesn't throw lots of U's and L's at
once, it is a kind of frequent where a bunch of them are thrown out every
many seconds or so.

Thanks in advance for your help.

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

Re: [Discuss-gnuradio] Slow GUI in GRC

[khalid.el-darymli]

Thanks very much Tom for your response. This issue is resolved after
replacing the graphic card driver installed by default with that provided
from the website of the card developer.

However, I am having two other issues now. One, in the terminal, I am
occasionally getting capital U's and L's when running GNU Radio with one Tx
and 4 Rx channels. Please note that I am using timed-commands to start both
the Tx and Rx's at the same time. When I check the system monitor while GNU
Radio is running (please see the attachment), the CPU history and RAM usage
seem to be fine. What causes  this issue and how to handle it? Could it be
due to some instability in the writing speed to the hard drive?

BTW, I am having the same issue for my older PC (a PC with less specs). The
System Monitor tells me that my CPU usage is around 60% and my RAM usage is
around 25 %, however, I am getting U's and L's when I try to use four Rx
channels. Please note that the system doesn't throw lots of U's and L's at
once, it is a kind of frequent where bunch of them are thrown out every few
seconds or so.

Two, although on my older machine I am able to use the' virtual source' and
'virtual sink' blocks without any problems, when I try to use them on the
new PC, I get the following error:

Traceback (most recent call last):
  File "./test_skh.py", line 595, in 
tb = test_skh()
  File "./test_skh.py", line 486, in __init__
self.connect((self.virtual_source_0, 0),
(self.blocks_multiply_conjugate_cc_0, 0))
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 93, in __getattr__
return getattr(self._impl, name)
*AttributeError: 'top_block_sptr' object has no attribute
'virtual_source_0'*

Things work fine if I replace the virtual blocks with direct connections. I
am not sure why?

Thanks in advance for your help.

Best regards,
Khalid


On Mon, Jan 5, 2015 at 12:11 PM, Tom Rondeau  wrote:

> On Wed, Dec 31, 2014 at 11:17 AM, khalid.el-darymli <
> khalid.el-dary...@mun.ca> wrote:
>
>> Hi,
>>
>> We recently bought a new machine with like 4 GHz processor, 16 GB of RAM.
>> For the graphic card, we use the Radeon R7 250 1000 MHz GDDR5.
>>
>> Latest version of Ubuntu (14.04 LTS) was installed along with GNU Radio
>> built from the source. Everything seems to be installed just fine. However,
>> when trying to use GNU Radio Companion (GRC), the GUI's are so slow. Every
>> time I try to place in or move the blocks in GRC, the whole GUI stuck for a
>> while and it gets so slow. Because of this, I am not able to run GRC.
>>
>>
>> Prior to this, GRC used to work just fine on another machine with a much
>> lower specs for the RAM and the processor but with RS880 [Radeon HD 4200]
>> graphic card.
>>
>>
>> What is the cause for this problem and how to fix it? Could it be the new
>> graphic card (Radeon R7 250 GDDR5)?
>>
>> Thank you.
>>
>> Best regards,
>> Khalid
>>
>
> Sorry, this sounds like a computer/os/configuration problem on your end.
> There were some slowdown issues with GRC that were patched a while ago, so
> if you've built from the latest source, things shouldn't be that bad.
>
> Tom
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Slow GUI in GRC

[khalid.el-darymli]

Hi,

We recently bought a new machine with like 4 GHz processor, 16 GB of RAM.
For the graphic card, we use the Radeon R7 250 1000 MHz GDDR5.

Latest version of Ubuntu (14.04 LTS) was installed along with GNU Radio
built from the source. Everything seems to be installed just fine. However,
when trying to use GNU Radio Companion (GRC), the GUI's are so slow. Every
time I try to place in or move the blocks in GRC, the whole GUI stuck for a
while and it gets so slow. Because of this, I am not able to run GRC.


Prior to this, GRC used to work just fine on another machine with a much
lower specs for the RAM and the processor but with RS880 [Radeon HD 4200]
graphic card.


What is the cause for this problem and how to fix it? Could it be the new
graphic card (Radeon R7 250 GDDR5)?

Thank you.

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?

[khalid.el-darymli]

Thank you Ralph and Marcus for this information. That is so helpful. One
final question on this, rather than having a standalone USB connection to
the computer, is there anyway to piggyback the temperature data from the
temp sensor onto the digital interface to the FPGA board of the N200?

Thank you.

Best regards,
Khalid


On Wed, Dec 3, 2014 at 3:36 AM, Ralph A. Schmid, dk5ras 
wrote:

> In my job we have learned that lesson and fitted on all our DSP systems
> (you could call them direct digitizing SDRs, although we do not radio
> stuff) a cheap I2C temperature sensor. No big thing by means of software,
> costs and PCB space, but already proved being very useful. Could be
> considered for future products…
>
>
>
> Ralph.
>
>
>
> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On Behalf
> Of *Marcus D. Leech via USRP-users
> *Sent:* Tuesday, December 2, 2014 4:11 PM
> *To:* khalid.el-darymli
> *Cc:* usrp-us...@lists.ettus.com; Discuss-gnuradio@gnu.org
> *Subject:* Re: [USRP-users] How to correct for the drift in an (FMCW) Rx
> signal?
>
>
>
> On 12/02/2014 10:06 AM, khalid.el-darymli wrote:
>
> Hi Marcus,
>
> Is there a temperature sensor on-board the N200 unit? If not, does it
> support installing any such sensor?
>
> Thanks.
>
> No, and no.
>
> But there are a tonne of USB-based temperature sensors out there.  Google
> is your friend, etc.
>
>
>
>
>
>
> Best regards,
> Khalid
>
>
>
> On Fri, Nov 28, 2014 at 5:44 PM, Marcus D. Leech 
> wrote:
>
> 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
>
>
>
>
>
>
>
>
>
>
> --
>
> 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

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

[khalid.el-darymli]

Hi Marcus,

Is there a temperature sensor on-board the N200 unit? If not, does it
support installing any such sensor?

Thanks.

Best regards,
Khalid


On Fri, Nov 28, 2014 at 5:44 PM, Marcus D. Leech  wrote:

>  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 
>> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
___
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

[Discuss-gnuradio] Conditional switching between two subroutines in real-time

[khalid.el-darymli]

Hi,

In GRC, I need to switch back and forth (in real time) between two
subroutines based on some conditional 'IF' statement. For example, 'after'
some preset lapse of time. Is it possible to do that?

Please note that I need the conditional switching to take place in
real-time while the USRP is running, without turning the USRP off and on.

Thanks in advance.

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

[Discuss-gnuradio] Downsampling in GNURadio

[khalid.el-darymli]

Hi,

I would like to downsample a signal from *390,625* Hz to *125 *Hz. *What is
the best way to do this in GNURadio? *


Please find below some issues I am having with this.

First, I used the Low Pass Filter block, in GNURadio, I set my Decimation
to 3125, my Cutoff Freq to 125/2. But I am not sure about *the recommended
value for the Transition Width parameter*?


On another note, to obtain accurate results for downsampling in Matlab (and
for DSP generally) it is often recommended to split the big decimation
factor into a cascade of smaller ones. If I was to do the downsampling from
390625 to 125 Hz in Matlab I would do something like 5*5*5*5*5 (i.e., five
separate downsamplers). *How to optimally do this in GNURadio?* By
'optimally' I mean with less computational resources given that I need to
do this for multiple channels simultaneously.


Finally, in another experiment for testing downsampling in GNURadio, I
tried to use the Rational Resampler block with the *default settings*.
However, my results were aliased. I think Low-Pass Filtering is not
included in the Rational Resampler by default. *Is this right?* *How do I
enable the low-pass filer? *and

*what kind of filter is recommended?*
Thanks in advance for your help.

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

Re: [Discuss-gnuradio] Issues with syncing two USRPs!

[khalid.el-darymli]

om the
>> two
>> motherboards (i.e., A:AB) without any success].
>>
>> Checking the system monitor on my computer confirms that one USRP is
>> transmitting all the time while no receive/incoming traffic whatsoever.
>>
>>
>> Besides this, I tried various diagnostics. I thought that the issue may
>> has
>> to do with the Ethernet controller/card on my computer, and that it may be
>> dropping/delaying some packets. Hence, I 'unmanaged' the Ethernet
>> connections, and I applied static configuration. I also tried to disable
>> some options in the network driver such as autoneg, adaptive, coalesce,
>> etc., without any success.
>>
>> Please find below some diagnoses that may give some clues on the FIFO ACK
>> error,
>>
>> T-UD2H:~$ sudo ethtool --show-coalesce eth4
>> Coalesce parameters for eth4:
>> Adaptive RX: off  TX: off
>> stats-block-usecs: 0
>> sample-interval: 0
>> pkt-rate-low: 0
>> pkt-rate-high: 0
>>
>> rx-usecs: 20
>> rx-frames: 5
>> rx-usecs-irq: 0
>> rx-frames-irq: 5
>>
>> tx-usecs: 72
>> tx-frames: 53
>> tx-usecs-irq: 0
>> tx-frames-irq: 5
>>
>> rx-usecs-low: 0
>> rx-frame-low: 0
>> tx-usecs-low: 0
>> tx-frame-low: 0
>>
>> rx-usecs-high: 0
>> rx-frame-high: 0
>> tx-usecs-high: 0
>> tx-frame-high: 0
>>
>>
>> T-UD2H:/etc/network$ sudo ethtool --show-coalesce eth3
>> Coalesce parameters for eth3:
>> Adaptive RX: off  TX: off
>> stats-block-usecs: 0
>> sample-interval: 0
>> pkt-rate-low: 0
>> pkt-rate-high: 0
>>
>> rx-usecs: 20
>> rx-frames: 5
>> rx-usecs-irq: 0
>> rx-frames-irq: 5
>>
>> tx-usecs: 72
>> tx-frames: 53
>> tx-usecs-irq: 0
>> tx-frames-irq: 5
>>
>> rx-usecs-low: 0
>> rx-frame-low: 0
>> tx-usecs-low: 0
>> tx-frame-low: 0
>>
>> rx-usecs-high: 0
>> rx-frame-high: 0
>> tx-usecs-high: 0
>> tx-frame-high: 0
>>
>>
>> T-UD2H:/etc/network$ ifconfig -a eth4
>> eth4  Link encap:Ethernet  HWaddr REMOVED
>>inet addr:192.168.10.1  Bcast:192.168.10.255
>>  Mask:255.255.255.0
>>inet6 addr: REMOVED_by_KE  Scope:Link
>>UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>RX packets:118227 errors:0 dropped:0 overruns:0 frame:0
>>TX packets:733915 errors:0 dropped:0 overruns:0 carrier:0
>>collisions:0 txqueuelen:1000
>>RX bytes:8366882 (8.3 MB)  TX bytes:930252111 (930.2 MB)
>>Interrupt:19
>>
>> GA-MA785GMT-UD2H:/etc/network$ ifconfig -a eth3
>> eth3  Link encap:Ethernet  HWaddr REMOVED
>>inet addr:192.168.20.1  Bcast:192.168.20.255
>>  Mask:255.255.255.0
>>    inet6 addr: REMOVED_by_KE   Scope:Link
>>UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>RX packets:40807 errors:0 dropped:0 overruns:0 frame:0
>>TX packets:11811 errors:0 dropped:0 overruns:0 carrier:0
>>collisions:0 txqueuelen:1000
>>RX bytes:3100954 (3.1 MB)  TX bytes:1076135 (1.0 MB)
>>Interrupt:18
>>
>>
>> We also sucessfuly upgraded the firmware for both the USRPs. We noticed
>> that (i.e., also shown form the stickers on the back of each device) one
>> N200 is rev 2.0 and the other is rev 4.0. Could that be the cause of the
>> problem?
>>
>> I will appreciate any help on fixing this issue.
>>
>> Thank you in advance.
>>
>> Khalid
>>
>>
>>
>>
>> On Wed, Jun 11, 2014 at 1:30 PM, 
>> wrote:
>>
>>  --
>>> Message: 9
>>> Date: Wed, 11 Jun 2014 15:20:32 +0200
>>> From: Martin Braun 
>>> To: discuss-gnuradio@gnu.org
>>> Subject: Re: [Discuss-gnuradio] Issues with syncing two USRPs!
>>> Message-ID: <539857a0.8020...@ettus.com>
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>
>>>
>>> On 10.06.2014 22:09, khalid.el-darymli wrote:
>>>
>>>> I am a new user of USRP/GNU Radio. I am  experimenting with a system
>>>> comprised of one transmitter and multiple receivers. For now, I have two
>>>> USRP N200. On the first USRP, I got one LFTX and one LFRX daughter
>>>> boards. On the other, I got one LFRX daughter board.
>>>>
>>>> In my application, it is important that the transmit and receive
>>>> channels are synchronize

Re: [Discuss-gnuradio] Issues with syncing two USRPs! (Discuss-gnuradio Digest, Vol 139, Issue 12)

[khalid.el-darymli]

 the stickers on the back of each device) one
N200 is rev 2.0 and the other is rev 4.0. Could that be the cause of the
problem?

I will appreciate any help on fixing this issue.

Thank you in advance.

Khalid




On Wed, Jun 11, 2014 at 1:30 PM,  wrote:

>
> --
> Message: 9
> Date: Wed, 11 Jun 2014 15:20:32 +0200
> From: Martin Braun 
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Issues with syncing two USRPs!
> Message-ID: <539857a0.8020...@ettus.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10.06.2014 22:09, khalid.el-darymli wrote:
> > I am a new user of USRP/GNU Radio. I am  experimenting with a system
> > comprised of one transmitter and multiple receivers. For now, I have two
> > USRP N200. On the first USRP, I got one LFTX and one LFRX daughter
> > boards. On the other, I got one LFRX daughter board.
> >
> > In my application, it is important that the transmit and receive
> > channels are synchronized (i.e., both device  time and channel phase).
> > For this, I am using my own GPS and PPS signals.
>
> What's the source of these signals? Have you made sure they are
> generating the right thing (i.e. 10 MHz ref)?
>
> Out of curiousity, do you have a MIMO cable and are willing to test that?
>
> > For the sake of testing, I am feeding the output of LFTX to all the
> > inputs in LFRX (i.e., four receive channels). The output/input type is
> > Complexfloat32. In GRC, when I use a separate USRP source block  for
> > each motherboard (i.e., without synchronization), the system is working
> > and I can receive four unsynchronised replicas of my transmitted signal.
>
> You're saying you get 2 channels per LFRX, correct? Also, are you
> attenuating the signal?
>
> > However, when I a use a single USRP source with two-motherboard and
> > four-channel options, I get the following error message:
> >
> >
> > linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-68-gc4b1f810
> >
> > -- Opening a USRP2/N-Series device...
> > -- Current recv frame size: 1472 bytes
> > -- Current send frame size: 1472 bytes
> > -- Opening a USRP2/N-Series device...
> > -- Current recv frame size: 1472 bytes
> > -- Current send frame size: 1472 bytes
> > -- 1) catch time transition at pps edge
> > -- 2) set times next pps (synchronously)
> > Using Volk machine: sse4_a_64_orc
> > *thread[thread-per-block[4]: ]:
> > RuntimeError: fifo ctrl timed out looking for acks*
> >  >>> Done
> >
> > My sample rate is 100e6/128 Hz. In the USRP source I set  synch to:
> > UnknownPPS, Mb0/1 clock source and Mb0/1 time source to EXTERNAL.  Mb0/1
> > subdev spec: A:A A:B. I tried to change the WireFormat from AUTOMATIC to
> > ComplexInt16 without any difference.
>
> Just to confirm: You're setting *both* clock and time sources to external?
>
> M
>
> >
> > I checked ./test_pps_input and I got a 'success'. I think the issue has
> > to do with the settings for syncing.  Any ideas on what causes this
> problem?
> >
> > BTW, I am also aware of this link
> > (http://files.ettus.com/uhd_docs/manual/html/sync.html), but I am not
> > sure where the commands of synchronizing the device time and channel
> > phase  should be applied?
> >
> >
> > Thank you.
> >
> > Best regards,
> > Khalid
> >
> >
> >
> >
> >
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Issues with syncing two USRPs!

[khalid.el-darymli]

Hi,

I am a new user of USRP/GNU Radio. I am  experimenting with a system
comprised of one transmitter and multiple receivers. For now, I have two
USRP N200. On the first USRP, I got one LFTX and one LFRX daughter boards.
On the other, I got one LFRX daughter board.

In my application, it is important that the transmit and receive channels
are synchronized (i.e., both device  time and channel phase). For this, I
am using my own GPS and PPS signals.

For the sake of testing, I am feeding the output of LFTX to all the inputs
in LFRX (i.e., four receive channels). The output/input type is
Complexfloat32. In GRC, when I use a separate USRP source block  for each
motherboard (i.e., without synchronization), the system is working and I
can receive four unsynchronised replicas of my transmitted signal.

However, when I a use a single USRP source with two-motherboard and
four-channel options, I get the following error message:


linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-68-gc4b1f810

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- 1) catch time transition at pps edge
-- 2) set times next pps (synchronously)
Using Volk machine: sse4_a_64_orc
*thread[thread-per-block[4]: ]: RuntimeError:
fifo ctrl timed out looking for acks*
>>> Done

My sample rate is 100e6/128 Hz. In the USRP source I set  synch to:
UnknownPPS, Mb0/1 clock source and Mb0/1 time source to EXTERNAL.  Mb0/1
subdev spec: A:A A:B. I tried to change the WireFormat from AUTOMATIC to
ComplexInt16 without any difference.

I checked ./test_pps_input and I got a 'success'. I think the issue has to
do with the settings for syncing.  Any ideas on what causes this problem?

BTW, I am also aware of this link (
http://files.ettus.com/uhd_docs/manual/html/sync.html), but I am not sure
where the commands of synchronizing the device time and channel phase
should be applied?


Thank you.

Best regards,
Khalid







On Tue, Jun 10, 2014 at 1:31 PM,  wrote:

> Send Discuss-gnuradio mailing list submissions to
> discuss-gnuradio@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> or, via email, send a message with subject or body 'help' to
> discuss-gnuradio-requ...@gnu.org
>
> You can reach the person managing the list at
> discuss-gnuradio-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
>1. Scanoo_rx: New GUI,   Center Freq Hopping & SSB Modulation
>   (Mike Jameson)
>2. Re: Help with wx-gui, window size error (Thilina Mallawa Arachchi)
>3. Re: post_guard and pre_guard in Pecog implementation
>   (Vanush Vaswani)
>4. Clock block slow in position satellitecalculation (caruiz.ext)
>5. Re: Clock block slow in position satellitecalculation
>   (Marcus M?ller)
>6. CMake error (sreena p h)
>7. Re: Clock block slow in position satellite calculation
>   (caruiz.ext)
>8. Re: CMake error (Martin Braun)
>9. Re: Ver 3.7 stable? (Martin Braun)
>   10. Re: tx_time tag accuraccy (Martin Braun)
>   11. Re: Error creating block with different input signature
>   (Martin Braun)
>   12. Re: Ver 3.7 stable? (Martin Braun)
>   13. Re: DPSK demodulator computational efficiency (Kevin Langer)
>   14. Time Limit (Bekir Sait ?iftler)
>   15. Re: DPSK demodulator computational efficiency (Tom Rondeau)
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio