[Discuss-gnuradio] Unable to see GSM signals in USRP Spectrum Scanner (FFT)
Greetings everyone, I hope everyone is having a good day. I have installed GNURadio 3.7 and I wanted to see the GSM signals of my phone (when I call someone) with the application "USRP Spectrum Scanner (FFT)". But, I was unable to see any fluctiations in the spectrum from 890 MHz to 915 MHz & 1710 MHz to 1785 MHz. My location is in Germany and I own a sim card of Aldi Talk (MEDIONmobile). Then I tried with my phone's Bluetooth 5.0 and I could see the frequency hopping from 2.4 GHz to 2.44 GHz along with the light Wi-Fi signals in the spectrum. I have the Etttus Research USRP B210 with Bandwidth of 56 MHz (of the front-end filter) and thus I am setting the sampling rate to 40 MHz. The antenna also works from 850 MHz to 6.5 GHz. so no problem with that as well. What could be reason for me not able to see my phone's GSM signals in the spectrum scanner? Your help would be very valuable. Best regards, Amrit Zoad +49 177 8474550 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unable to see GSM signals in USRP Spectrum Scanner (FFT)
Hi Amrit, Well, usrp_spectrum_sense is a hopping observer, and GSM is a hopping system: your probability of intercept is rather low. Your probability of intercept is in fact, really zero, if your phone doesn't do GSM (2G), but uses 3G (UMTS) or 4G (LTE): these use other frequencies altogether. So, make sure your phone really does do GSM. You also don't even have to look at the GSM900 uplink at all: Telefonica (which Aldi resells) doesn't use that band at all. The spectrum sense application is really badly suited for this kind of task, as it hops: Instead, simply look at the whole band at once. A simple GNU Radio Companion flow graph connecting the USRP source (samp rate = total uplink bandwidth) to a Qt GUI Frequency Sink would make more sense. A word of secondary advice: If you're planning to experiment with 2G networks of your own, or doing something about the basic properties of microwave propagation and so on, observing spectrum of GSM is a worthwhile thing to do. Just be warned that it will be increasingly hard to find GSM signals "in the wild": T-Mobile will switch off GSM end-of-2020, and thus, up to then, all phones that can do both LTE and GSM will be instructed to use LTE whenever possible. Since there won't be much Machine-to-Machine GSM-only (which I assume are the primary users that won't be able to switch) user equipment in cities, you'll see that increasingly many phones don't use GSM anymore at all – even if the network still exists; the calculation is very simple: The amount of spectrum necessary to let a single user do a GSM phone call is worth MB/s for a lot of LTE users. Thus, everybody not using GSM is desirable for network operators. Best regards, Marcus On Mon, 2018-06-18 at 11:25 +0200, Amrit Zoad wrote: > Greetings everyone, > > I hope everyone is having a good day. > > I have installed GNURadio 3.7 and I wanted to see the GSM signals of my phone > (when I call someone) with the application "USRP Spectrum Scanner (FFT)". > But, I was unable to see any fluctiations in the spectrum from 890 MHz to 915 > MHz & 1710 MHz to 1785 MHz. My location is in Germany and I own a sim card of > Aldi Talk (MEDIONmobile). > > Then I tried with my phone's Bluetooth 5.0 and I could see the frequency > hopping from 2.4 GHz to 2.44 GHz along with the light Wi-Fi signals in the > spectrum. > > I have the Etttus Research USRP B210 with Bandwidth of 56 MHz (of the > front-end filter) and thus I am setting the sampling rate to 40 MHz. The > antenna also works from 850 MHz to 6.5 GHz. so no problem with that as well. > > What could be reason for me not able to see my phone's GSM signals in the > spectrum scanner? > Your help would be very valuable. > > Best regards, > Amrit Zoad > +49 177 8474550 > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UDP Re-transmission
Hello all, I need some advice. I'm trying to take UDP datagrams from one port, transport them over an RF link to a receiver, and then send them back over another UDP port. Sounds simple, but I'm having a difficult time with it. Originally I was doing this to transmit text and image files: [file source]-->[Packet Encoder]-->[GFSK Mod]-->[UHD USRP Sink (B200)] [Osmocom SDR Source (BladeRF)]-->[GFSK Demod]-->[Packet Decoder]-->[file sink] It worked great using files, but once I replaced the File source and sink blocks with UDP source (port 9003) and sink (port 9004), It wouldn't work. I also had to remove the packet encoder and decoder blocks. [UDP source 9003]-->[gfsk mod]-->[UHD USRP Sink (B200] [Osmocom SDR Source (BladeRF]-->[gfsk demod]-->[UDP sink 9004] Troubleshooting: Using Wireshark to sniff the source and sink ports, I could see that the data going to the UDP sink port (9004) was completely different from what was sent on the UDP source port. When I connect the UDP source/sinks together directly, UDP traffic is passed and the datagrams match. I removed the radios and connected the GFSK mod/demod blocks directly and the problem persists. Also, unless I decimated the received samples by 8, the datagrams on the UDP sink port were different sizes from those on the UDP source port. The UDP, IP, and Ethernet headers are intact, but the payload on the receive side is just random hex 01 and hex 00. Has anyone implemented something like this before? What am I doing wrong? Thank you, Dustin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UDP Re-transmission
Hi Dustin! Good thing you removed the Packet Encoder and Packet Decoder – these blocks are buggy, we don't know how to repair them, and thus, they will soon be gone from GNU Radio. That's why they are in the "deprecated" category. The fact that it works with a file source but not with a UDP source does coincide with the observation that the failure rate of these blocks is strongly dependent on the fine temporal aspects of how they get input. But without them, you don't have a packetizer – and thus, none of this works because your receiver simply can't know what the start of a transmission is, or what symbols belong to a byte and so on. I must admit I don't have an easy solution for this. Are you fixed on using GFSK? Best regards, Marcus On Mon, 2018-06-18 at 10:05 -0500, D J wrote: > Hello all, > > I need some advice. I'm trying to take UDP datagrams from one port, > transport them over an RF link to a receiver, and then send them back > over another UDP port. Sounds simple, but I'm having a difficult > time with it. > > Originally I was doing this to transmit text and image files: > > [file source]-->[Packet Encoder]-->[GFSK Mod]-->[UHD USRP Sink > (B200)] > > [Osmocom SDR Source (BladeRF)]-->[GFSK Demod]-->[Packet Decoder] > -->[file sink] > > It worked great using files, but once I replaced the File source and > sink blocks with UDP source (port 9003) and sink (port 9004), It > wouldn't work. I also had to remove the packet encoder and decoder > blocks. > > [UDP source 9003]-->[gfsk mod]-->[UHD USRP Sink (B200] > [Osmocom SDR Source (BladeRF]-->[gfsk demod]-->[UDP sink 9004] > > Troubleshooting: Using Wireshark to sniff the source and sink ports, > I could see that the data going to the UDP sink port (9004) was > completely different from what was sent on the UDP source port. When > I connect the UDP source/sinks together directly, UDP traffic is > passed and the datagrams match. I removed the radios and connected > the GFSK mod/demod blocks directly and the problem persists. Also, > unless I decimated the received samples by 8, the datagrams on the > UDP sink port were different sizes from those on the UDP source > port. The UDP, IP, and Ethernet headers are intact, but the payload > on the receive side is just random hex 01 and hex 00. > > Has anyone implemented something like this before? What am I doing > wrong? > > Thank you, > Dustin > ___ > 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
