1
$\begingroup$

I have this app in my phone which tells me the LTE UL frequency and power:

enter image description here

so I went with my SDR and measured the received signal at that frequency:

enter image description here

Now, how can I be sure this is the transmitted signal from my phone? As I made a call to and from this phone and nothing changed.

I did a second experiment when the phone switched to LTE band 20 and the spectrum looks quite different:

enter image description here

I also recorded this video when the phone is just in "standby" and this other video when the phone is sending an email with an attachment.

I have the feeling I'm not seeing the correct information in the LTE band 3 because my dongle (this one) is not actually receiving anything there, although it shows an spectrum? My goal here is to be able to detect my phone's transmitted signal and then, to make sure I can distinguish it before I invest in a more expensive SDR to be able to monitor higher bands.

$\endgroup$
8
  • $\begingroup$ Is it still LTE when you make a call or it is switched to 3G/2G? Try uploading something, a video to youtube for example. $\endgroup$
    – AlexTP
    Sep 8, 2018 at 16:33
  • $\begingroup$ @AlexTP hey!! thank you very much!! I didn't know it would change to HSPA+ when making a call! why is that so? I did it and looked for that frequency (about 900MHz) and the power raised! :D for the uploading experiment, I attached a video in an email and send it, and it was LTE all the time, but I couldn't see anything. $\endgroup$ Sep 9, 2018 at 8:13
  • $\begingroup$ this is called circuit switch fallback sharetechnote.com/html/Handbook_LTE_CS_Fallback.html. It seems that your operator has not implemented Voice over LTE yet. About your video uploading experiment, sorry no idea. $\endgroup$
    – AlexTP
    Sep 9, 2018 at 13:44
  • $\begingroup$ what is your SDR, and what is it's sampling rate? Your PSD plot is lacking a frequency axis... $\endgroup$ Sep 9, 2018 at 14:20
  • 1
    $\begingroup$ @MarcusMüller it was! just marked it as the correct answer :) I added a few comments below it in case you can have a look too, please. Thank you! $\endgroup$ Oct 16, 2018 at 20:57

1 Answer 1

3
$\begingroup$

There's a lot of different domains of knowledge coming together here, so I'll split my answer into multiple sections, each answering an implicit question that you raise in your explicit question. Hope that helps!

Can your RTL-Dongle actually receive at 1.72 GHz?

So, first the bitter pill: There's a lot of sellers out there that offer RTL dongles and claim that they've got an R820T tuner, but actually ship an Fitipower tuner that covers far less spectrum. I find that the most likely explanation here, especially considering the product description and the "tech specs" table disagree. Said table only claims:

Receiving Frequency:48.25-863.25 MHz Tuning Range

So, possibly you've got an RTL-Dongle with a fitipower FC0012, not a R820T (which went out of production a while ago). RTL-SDR comes with the rtl_test utility, but possibly your software can show you the tuner installed in that device, too.

However, considering your display shows the right frequencies, let's assume it actually tuned to ~1.720 GHz when you instructed the device to tune there.

Are you using an antenna that's suitable for these frequencies?

Just mentioning that, because I've supported far too many people that told me after a couple of hours that they were trying to receive FM broadcast radio at 100 MHz using a Wifi antenna, and vice versa.

Are the powers in these different applications related?

Then, first thing to notice: The powers displayed in your SDR software are not related to the power your App shows for reasons:

  • The power shown is the downlink power. You're observing uplink. Uplink should probably have significantly more power than downlink at your handset.
  • I don't know where the app gets that data. But, I'll go out on a limb and say it's not really an RX power estimate, at all. LTE specifies a whole set of quality metrics, all of which are useful to assess the error probability of a receiver. None of these is a pure power measurement (because that doesn't matter to a device, actually. What matters are SNR measures that incorporate noise, but also things like adjacent channel interference, clock errors, …).
  • An RTL dongle doesn't even remotely give calibrated values. What it sends to the computer are simply 8 bit numbers, relative to the ADC's full scale, whatever that means at any given gain, frequency, rate, filter setting, temperature, component tolerances, moon phase, amount of black cats in neighborhood… .
    I don't know why your program shows you "dBm", but unless you have run some calibration on your dongle for exactly your gain, frequency, and sampling rate settings, these numbers mean nothing. All you can say is that 3dB more means twice as much power.

Can I analyze LTE signals using an RTL Dongle, at all?

LTE uses a total bandwidth much larger than 3 MHz, so, if at all, you're looking at a small excerpt of your uplink; possibly even one where your handset doesn't even get an allocation of resources.
LTE is very flexible about assigning resources to different user equipment in the same cell, and very quick – unless you have a very aggressive means of holding spectral peaks, it might be pretty impossible to spot your own contribution in a cell.

Especially the downlink uses OFDM, and usually also power control, so if your handset is the main downlink user in a cell, all that you should be seeing if you had an SDR that could actually see the whole LTE downlink channel, would be what would look like a "flat-top" section of spectrum that is basically elevated white noise, possibly exhibiting non-flatness due to frequency-selectivity of the channel.

If you look at a section of OFDM, all you'll see is a noise floor, unless you manage, by luck or synchronization, use an FFT that exactly "hits" (integer factors) of the subcarrier spacings (in which case you'd be lucky to see staggered sinc spectra of the OFDM subcarriers). You'd need a very long FFT and very good SNR (which you don't seem to have) to see the sinc carriers unsynchronized.

Are you actually observing your phone's LTE signals in your pictures?

Doesn't look like it.

Your 800 MHz spectrum shows something 200 kHz wide with a rectangular shape; that might be a bunch of LTE subcarriers (those have 15 kHz spacing), but it's definitely not coming out of the noise floor far enough to be your phone's resource blocks (also, questionable whether you'd get a resource block allocation that's static for that long).

Considering the periodic spurs and the intereferer at ~1719.35 MHz that looks a lot like a mixed-up rectangular wave, I'll go with no, you're likely not looking at LTE here; there should be far more dynamics in the waterfall.

Is your ultimate goal achievable?

My goal here is to be able to detect my phone's transmitted signal and then, to make sure I can distinguish it before I invest in a more expensive SDR to be able to monitor higher bands.

Detecting activity of any one phone in vicinity

As said, your TX signal should be much stronger close to your handset than it's RX (which really is just the simple physics of spatial power density going down with the square of distance). Especially when your phone displays "few bars" (i.e. it has low receive SNR), it will have to use a lot of power when transmitting (which is why I'm pretty sure you're not observing your phone in either screenshot).

A simple power detector with a high-enough threshold should do an approximately good enough job. You'd still not be sure whether it's your phone, or the phone in the next room. LTE relies on power control, i.e. your phone will only use as much power as necessary to achieve the rate it needs (that's not something that your phone is allowed to choose – it's necessary to keep the dynamic range of the receiver on the base station side manageable and to keep interference at bay).

Detecting activity of a specific phone

Now, this get's a lot more complicated, as you'll have to analyze the LTE signal. Not quite sure from the top of my head, but I'd go with "no, from the uplink signal alone, you can't say which phone is currently transmitting".

LTE is a cellular infrastructure network, not an ad-hoc burst network; hence, stations are assigned times when they should be transmitting by the base station using the downlink. Inherently, that means that the station doesn't need to indicate who it is when using the uplink; the base station knows because it assigned the uplink resources, who's using the uplink. Thus, you'd have to observe the downlink more than the uplink to know when you're phone's talking. Luckily, LTE is generally pretty well-encrypted, so you shouldn't be trivially able to extract very specific information from the downlink about your phone, but you might at least be getting unencrypted local IDs of the different stations in the cell from the downlink, if your SDR receiver software is able to demodulate the signal.

$\endgroup$
2
  • $\begingroup$ wow! Thank you very much!! That was really useful! A bit dissapointing too...just have a doubt: when I sent an email (the second video linked), I saw the power raising up in the SDR Console software. As you mentioned, the LTE bandwith is bigger (I think it's about 25MHz) and I actually didn't see the full spectrum when that happened, so was that the uplink or downlink? $\endgroup$ Sep 9, 2018 at 19:45
  • $\begingroup$ also, in order to detect a phone, if I create a base station, using an USRP B210 and one of the available softwares such use openLTE, would I be able to detect it all phones attached to this base station? There is also a cheaper option which would be bladeRF and openBTS, but before getting this hardware, I want to know if it's possible at all...because the phones may be attached to another base station but if the "emulated" base station provides better quality, I guess the phones should attach? $\endgroup$ Sep 9, 2018 at 19:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.