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
<usrp-users@lists.ettus.com> 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 to the time it hands
>back a
>> sequence of complex numbers.
>>
>> Yes, Marcus is correct not only because he is an expert/professional
>but
>> because what he says aligns with what I have learned. The USRP does
>not
>> provide dBm. All it provides is a complex vector of 32-bits (16-bit)
>or
>> 16-bits (8-bit). This is then normalized and scaled between 0.0 and
>1.0.
>> That 16-bit I and Q are what the ADC outputs - although I know it is
>> manipulated by the FPGA with filters and decimation but for what it
>is
>> worth that is where they come from. The ADC and FPGA really have no
>idea
>> what the original signal power/voltage level was before being
>amplified
>> unless they calculate it. You *can* do your own calculation but then
>the
>> accuracy is questionable unless you calibrate it. I also know the
>FPGA can
>> control various amplifiers so it is not just a single component,
>therefore,
>> that must be what makes it difficult to know for certain the
>accuracy.
>>
>> I think calibration is difficult because of lots of complex factors.
>I
>> could only suspect this would be in relation to distortions and
>> interactions between components with different gains, temperatures,
>and ...
>> well that is what I think.
>>
>> But, if you used a loop back you could see why you get units less
>than
>> makes sense. As in, you could see that the antenna had little effect
>at the
>> same gain and such, or maybe the antenna is making a big difference.
>>
>> Kevin, thanks for your input.
>>
>> But I see below that you made the recommendation to DIRECTLY CONNECT
>a
>> receiver to a transmitter. This is NEVER a good idea, as you can
>easily
>> exceed
>> the maximum safe input levels for the receiver. When you are
>doing
>> such direct loopback tests, ALWAYS have at least 40dB of attenuation
>> in-line.
>>
>> The amplifiers used in receivers are sensitive. Structurally, they
>are
>> usually GaAsFET transistors with an exceedingly-thin gate region (a
>few
>> molecules thick). It's very easy to destroy that gate region with
>too-much
>> input power.
>>
>> A receiver is, after all, designed to receive signals from an antenna
>> "through the air". A quick look at standard path-loss models means
>that
>> levels that one might reasonably describe as "a flea sneezing" are
>> more-than-adequate to drive a receiver. Transmitters, on the other
>hand,
>> produce power that ranges from "can drive a tiny electric motor" to
>"boil a
>> mug of coffee".
>>
>> Here's a f'rexample. Consider a satellite in low-earth orbit,
>producing,
>> let's say, +20dBm into a dipole, and transmitting at 2.3GHz. Let's
>say its
>> in an orbit 180km above the earth. We ascribe 3dB gain to the
>antennae on
>> each end, although in reality, at least the ground segment will have
>a
>> high-gain antenna. Plugging this in to a path-loss calculator,
>there's
>> 139dB of path-loss between the satellite and ground station. So,
>that
>> +20dBm signal is now at about -121dBm coming into your receiver.
>That's
>> within reach of a typical SDR receiver. Add some gain on the ground
>end,
>> and you have an even better signal. Now, -121dBm is 1.0e-15 *watts*.
>> Putting, let's say, +10dBm into that same receiver means that it is
>trying
>> to process a signal that is 130dB louder than the faintest
>"reasonable"
>> signal that it can process. The very *best* outcome is that the
>receiver
>> will become non-linear. The very-worst is that it will become
>damaged.
>>
>> Folks who have heretofore "grown up digital" may have almost no
>intuitive
>> feel for how the analog electronics world works, and that it is
>dominated
>> by the physics of the real-world, and thus governed by laws that you
>cannot
>> easily "get around". This takes some getting used to....
>>
>> Cheers
>> Marcus
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
