Re: [USRP-users] interpretation of received signal

[Marcus Müller via USRP-users]

Niemals,

> The "faintest reasonable signal level" that a typical SDR can process!  
> (Typically  around -120  to  -130 dBm).!  

no! You can process much weaker signals, too, given enough processing gain. 
Marcus was just giving an example. Whether you can "see" what is in the air 
depends on the detector *you* write and how *you* configure the SDR.

If you know the tone you're looking for, you can corelate with that for a long 
time, considering only the signal within a very limited bandwidth, and this y 
capturing little noise. Them you can detect much weaker signals.
If you can't be sure on which frequency the tone is, or you can't corelate for 
a long time, that doesn't work, and you'll need more power to detect the tone.

But: for none of this the power in dBm plays a role. You only need SNR, and 
that is a dimensionless thing (in dB). You get the SNR you need from analytical 
error curves of the thing that uses that channel after probing, or via 
simulation.

Getting an example for some completely different supplication from "someone on 
the internet" and then using the numbers from that is certainly wrong. You're a 
student, so you will have to write a report of some kind in the end. Do some 
formal calculations for how much SNR you need for your application to work, 
then use that SNR to calculate for how long you'll need to observe a noisy tone 
to *reliably* (that means: set probabilities for false alarm and for missed 
detections, calculate based on these) assess the channel.
Discuss these steps with your team or advisor. Don't "hand-waive" detection; 
that's not how things work in a math-affine world like SDR.
 
> It cannot be in real time! 

I don't see why any of this wouldn't work in real time.

> the "power based approach" seems to "not stand in favor"!  Perhaps best would 
> be to send and receive known data and then declare the channel as healthy?

Well, the power of a single tone only gives you info about an infinitely narrow 
piece of bandwidth within your channel. That is indeed not a good channel state 
information estimator.

You'd typically want to send a signal that fills the whole bandwidth of the 
system you want to use the channel with. Depending on your receive software 
architecture, detection of packets before sync might be easy or not. So, that's 
up to *you* to decide.

But, really, things pretty much always boil down to "this detected something in 
the receive signal that looks like what I was expecting to get with a 
similarity (often: normalized correlation coefficient) of x", and then have a 
threshold for x, based on your signal model, noise estimate, receiver operating 
characteristics. When x above threshold, assume you saw a sufficiently good 
signal, if below, then not.

So, again, it's good that you engage with the community, but you really might 
want to take a piece of paper and draw a draft of a flow chart of how you want 
your receiver to work, and make bullet points in the things you need to figure 
out for that. Discuss that with your advisor. I have yet to meet one advisor 
that says "I wished my students would not occasionally approach me to discuss 
their well-structured plans".

Best regards,
Marcus

On 22 October 2017 2:10:05 AM GMT+02:00, Nirmala Soundararajan via USRP-users 
 wrote:
>Thanks for a very good explanation on power levels Marcus. Actually I
>think
>I got the answer to what I was looking for. The "faintest reasonable
>signal
>level" that a typical SDR can process!  (Typically  around -120  to 
>-130
>dBm).!
>
>In my application, I have a bunch of channels through which I can
>transmit
>and receive. I wanted to do a quick health check of transmit and
>receive
>and wanted to eliminate the overhead of creating a packet. So thought I
>would send some tones through the channels of "particular power level",
>then if I receive it within a "particular power level", then I could
>declare that a particular channel is 'Pass'!  Of course this is only
>for
>simulation purpose. It cannot be in real time!  But given all the
>explanation, the "power based approach" seems to "not stand in favor"!
>Perhaps best would be to send and receive known data and then declare
>the
>channel as healthy??
>
>regards
>
>Nirmala
>
>
>
>On Sat, Oct 21, 2017 at 12:39 PM, Marcus D. Leech via USRP-users <
>usrp-users@lists.ettus.com> wrote:
>
>> On 10/21/2017 11:59 AM, Kevin McGuire via USRP-users wrote:
>>
>> My knowledge is limited, therefore, read this with a grain of salt.
>> However, I wanted to try to help and if something I say does not make
>sense
>> then double-check it or someone else may come along and correct me.
>>
>> I had this same problem when I started with these types of systems. I
>had
>> trouble understanding what the numbers meant in terms of a physical
>> measurement. People would give me a short summary of it but I still
>failed
>> to completely understand until I dug down into what the system
>actually
>> does from the time the RF energy is presented

[USRP-users] Underflows with simple rx/tx GNU Radio flowgraph on USRP X310 under RFNOC UHD

[Piotr Krysik via USRP-users]

Hi all,

I'm prepared a basic GNU Radio flow-graph that does simultaneous
transmission and reception (see the attachment). For USRP X310 and RFNOC
UHD (version above 3.10.x) soon after starting the flow-graph there is a
lot of buffer underflows (even for low sample rate like 1MS/s). For
pre-RFNOC UHD (3.9.6) everything works fine.

What is a bit strange is that txrx_loopback_to_file UHD example works
fine for all versions of UHD.

Is anybody here able to run GNU Radio flow-graphs with simultaneous tx
and rx on X310 with RFNOC UHD and without underflows?

Best Regards,
Piotr Krysik

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

[USRP-users] interpretation of received signal

[Nirmala Soundararajan via USRP-users]

Hi Marcus,

I have no idea why you said that but I certainly did not mean to directly
take the values that Marcus L mentioned and straight away add it in my
report!. Since I am just learning about SDR, I just wanted an idea of what
could be the minimum power levels that an SDR receiver can fairly
comprehend and process. Of course I definitely have to co-relate with the
results that I get in the simulation. All said and done it certainly helps
when experts and professionals give their advise and feedback (due to their
vast experience) and I feel there is nothing wrong in checking with experts
just to see where we are heading or "are we in the right direction" !
Please excuse me if I am wrong!

Ettus has always recommended that all users including beginners post their
doubts in this forum and indeed this is the best place to learn more about
their product!  So we are all learning !

kind regards

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

[USRP-users] N210 Genarate OOK Signal With LFTX/RX

[???? via USRP-users]

I WANT to use my N210 with LFTX&LFRX to genarate OOK signal ,I used the  random 
source and follow
With a USRP sink ,it didn't work ,then i  try to use the BPSK demo, I set the 
center frequency to 0 but it also didn't work .So what's wrong with my 
methods?and How could I get OOK signal ?___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N210 Genarate OOK Signal With LFTX/RX

[Marcus Müller via USRP-users]

Hi!

So, you'll need to be a little more specific than "it didn't work". How
did you configure your random source? Did you use pulse shaping?

There's quite a bit, even to an OOK transmitter, that one can vary and
do right or wrong. With the info you're giving, I'm afraid it's
impossible to help you.

Best regards,

Marcus


On 22.10.2017 05:14,  via USRP-users wrote:
> I WANT to use my N210 with LFTX&LFRX to genarate OOK signal ,I used
> the  random source and follow
> With a USRP sink ,it didn't work ,then i  try to use the BPSK demo, I
> set the center frequency to 0 but it also didn't work .So what's wrong
> with my methods?and How could I get OOK signal ?
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

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

Re: [USRP-users] interpretation of received signal

[Marcus Müller via USRP-users]

Hi Nirmala,

On 22.10.2017 18:22, Nirmala Soundararajan via USRP-users wrote:
> Hi Marcus,
>
> I have no idea why you said that but I certainly did not mean to
> directly take the values that Marcus L mentioned and straight away add
> it in my report!. Since I am just learning about SDR, I just wanted an
> idea of what could be the minimum power levels that an SDR receiver
> can fairly comprehend and process.
And I explained why such a power does not exist.
> Of course I definitely have to co-relate with the results that I get
> in the simulation.
:)
> All said and done it certainly helps when experts and professionals
> give their advise and feedback (due to their vast experience) and I
> feel there is nothing wrong in checking with experts just to see where
> we are heading or "are we in the right direction" !  Please excuse me
> if I am wrong!
Absolutely right! That's a good idea, and I really just wanted to
suggest that you always keep the bigger picture of what you need to
achieve in mind, and coordinate the direction in which you look with
your advisor; I think we both agree that it was a bit of a bumpy ride
until you got the "the USRP does not give dBm", and the understanding of
that, and the understanding of dBm not actually mattering for what you
*want* to do in the long run, has led me to suggest you structure your
project formally. Hope that didn't upset you!
>
> Ettus has always recommended that all users including beginners post
> their doubts in this forum and indeed this is the best place to learn
> more about their product!  So we are all learning !
Indeed, it's a learning process for all of us, and I just want to
contributo to what you've learned being put to maximum use.

Best regards,
Marcus

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

[USRP-users] Property 'compxlib.compiled_library_dir' is deprecated for a Modelsim simulation for noc_block_skeleton_tb

[Swanson, Craig via USRP-users]

Support,

I am trying to simulate using Modelsim and I am getting the following warning:


WARNING: [Common 17-599] Property 'compxlib.compiled_library_dir' is deprecated 
for object type 'project'. Use 'compxlib._compiled_library_dir'.
# launch_simulation
INFO: [USF-ModelSim-47] Finding simulator installation...
INFO: [USF-ModelSim-49] Using simulator executables from 
'/opt/mentor/modelsim/modelsim_dlx/bin'
INFO: [SIM-utils-51] Simulation object is 'sim_1'
INFO: [USF-modelsim-7] Finding pre-compiled libraries...
CRITICAL WARNING: [USF-modelsim-8] Failed to find the pre-compiled simulation 
library!


This is found around line 110 of /tools/scripts/viv_sim_project.tcl


Is there a solution for this?


my branch is rfnoc-devel

HEAD detached at bbd81be

* GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
* Python 2.7.12
* Vivado v2016.4 (64-bit)



Who is replacing Jonathon Pendlum?  What is their email address?


Thanks,

Craig


Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu

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

Re: [USRP-users] Bug about for E312

[liu Jong via USRP-users]

Hi Marcus,
I am sorry,the first link as below:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-October/026761.html

2017-10-21 21:17 GMT+08:00 Marcus Müller via USRP-users <
usrp-users@lists.ettus.com>:

> Dear Jon,
>
> that first link points to your own GMail account. We can't do anything
> with that, I'm afraid.
>
> Please find the email you're referring to, cite it directly, or link to it
> on http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/
>
> Thank you!
> Marcus M
>
> On 20.10.2017 03:20, liu Jong via USRP-users wrote:
>
> HI all,
> For multiple E312 synchronizing,we did synchronous reception tests, and
> specific things as email descriptions:
> https://mail.google.com/mail/u/0/?pc=topnav-about-en#all/15f24798ac0bac0b
> I also noted that said it was a bug:
> http://permalink.gmane.org/gmane.comp.hardware.usrp.e100/16889
>
> Has this bug been repaired?  can E312 be used for TDOA measurement and,
> if possible, how to implement it in the program?
>
> best regards
> Jon
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com