Capturing Uplink Traffic

[David Fox]

Hello,

I'm trying to capture simultaneous DL/UL traffic with the Multi-RTL Source. I'm running my own network with OpenBTS for simplicity, and have 1 MS connected. Currently, I am correctly capturing the downlink. Wireshark is getting messages as expected. However, I'm getting nothing out of the uplink. I've attached an FFT to the input to make sure my levels are good, and I can visually see the energy from bursts on that the uplink, but the GSM Receiver w/ Uplink block isn't producing any outputs on CX. Is this where uplink burst detections should be seen?

I've synchronized the RTL inputs to the GSM downlink at 947.2MHz.

I did notice in the Multi-RTL instructions there's a section on hardware hacking, but I also recall reading on some posts that with the new Multi-RTL source block you don't need to do that and software does the work. Do I need to do any hardware hacking to synchronize the clocks?

As far as I can tell, the receiver is just failing to see the bursts on the uplink, which points to a synchronization issue. But I don't know a good method to detect what that problem is. Any help would be greatly appreciated.

Thank you!

[Vasil Velichkov]

Hi David,

On Tuesday, May 22, 2018 at 5:46:53 PM UTC+3, David Fox wrote:

but the GSM Receiver w/ Uplink block isn't producing any outputs on CX. Is this where uplink burst detections should be seen?

No, the uplink bursts of the first uplink channel are sent to the C0. Here is the corresponding code

https://github.com/ptrkrysik/gr-gsm/blob/development/lib/receiver/receiver_impl.cc#L1030-L1031

https://github.com/ptrkrysik/gr-gsm/blob/development/lib/receiver/receiver_impl.cc#L1068-L1070

Also see uplink_decoding_multi_rtl.grc, you could test this flowgraph with sms_multirtl_downlink_tail.cfile and sms_multirtl_uplink_tail.cfile from the https://github.com/ptrkrysik/test_data repository.

I've synchronized the RTL inputs to the GSM downlink at 947.2MHz.

I did notice in the Multi-RTL instructions there's a section on hardware hacking, but I also recall reading on some posts that with the new Multi-RTL source block you don't need to do that and software does the work. Do I need to do any hardware hacking to synchronize the clocks?

Looking at the code I doubt that it's going to work without the hardware modification, see also https://ptrkrysik.github.io/

Regards

Vasil

[David Fox]

Thank you, Vasil! That saves me a lot of headache.

[Piotr Krysik]

W dniu 22.05.2018 o 16:46, David Fox pisze:

Hi David,

As Vasil have written CX output is not place where you should expect the
uplink bursts in your case, where you have only C0 channel. You can
connect Up/Down-link splitter to C0 output and see what comes out of
uplink output. Probably you will see bursts even for parts with noise
(as I disabled burst detection in the GSM Receiver) so to make sure that
there is something really you will also need to connect some demapper
and decoder.

Regarding Multi-RTL - you need the hardware modification so RTL-SDR
receivers are synchronized in frequency and they keep the time
synchronization over time.

Best Regards,
Piotr Krysik

[David Fox]

The Up/Downlink splitter is showing received bursts from the receiver. I'm able to see messages from the demapper following, but the decoder blocks aren't producing anything and wireshark gets no uplink packets. Is there anything special that needs to be done in order to get the packets to traverse all the way through wireshark?

[Vasil Velichkov]

Hi David,

On 4.06.2018 22:26, David Fox wrote:

Is there anything special that needs to be done in order to get the packets to traverse all the way through wireshark?

Nothing special as far as I know.
Could you share your cfiles?
Are you using the uplink_decoding_multi_rtl.grc and are you able to get the uplink messages from sms_multirtl_downlink_tail.cfile and sms_multirtl_uplink_tail.cfile?

[David Fox]

I have successfully run the example graph with those data files, and I do get the uplink packets in wireshark.

I'm not using that particular graph, currently. I'm using a graph more based on the 'get_bcch_msgs_from_cfile'. I do notice that there is only a single clock offset control for both GSM Input Adapters in the 'uplink_decoding_multi_rtl' flowgraph, whereas I've been running with a separate one for uplink and downlink. I just did a run where I used a single one pointed at the downlink frequency, but I didn't notice any significant changes, and I'm still not getting any decodings. Should I be using a single clock offset control block, or is 1 for uplink and 1 for downlink okay?

I'm attaching an uplink/downlink pair of files. There should be 1 SMS in there. Downlink is at 947.2MHz

​

 GSM

​

--
You received this message because you are subscribed to the Google Groups "gr-gsm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gr-gsm+unsubscribe@googlegroups.com.
To post to this group, send email to gr-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gr-gsm/81b051dd-9feb-32c6-7e88-05c682612ed3%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Vasil Velichkov]

Hi David,

On Tuesday, June 5, 2018 at 5:27:28 PM UTC+3, David Fox wrote:

I have successfully run the example graph with those data files, and I do get the uplink packets in wireshark.

That's good to know.

 

I'm not using that particular graph, currently. I'm using a graph more based on the 'get_bcch_msgs_from_cfile'.

Could you share your flowgraph?

 

I do notice that there is only a single clock offset control for both GSM Input Adapters in the 'uplink_decoding_multi_rtl' flowgraph, whereas I've been running with a separate one for uplink and downlink. I just did a run where I used a single one pointed at the downlink frequency, but I didn't notice any significant changes, and I'm still not getting any decodings. Should I be using a single clock offset control block, or is 1 for uplink and 1 for downlink okay?

I believe you should use 1 GSM clock offset control block. 

I'm attaching an uplink/downlink pair of files. There should be 1 SMS in there. Downlink is at 947.2MHz

What sample rate you have used?

[David Fox]

Sample rate is 200.0e6/174.0 or ~ 1.14943M

I'm attaching my flowgraph. It's a bit of a mess, but everything disabled was disabled when I took those captures.​

 get_bcch_msgs_from_rtlsdr.grc

​

--

You received this message because you are subscribed to the Google Groups "gr-gsm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gr-gsm+unsubscribe@googlegroups.com.
To post to this group, send email to gr-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gr-gsm/951604ed-eef7-4acf-b529-62464ca4e575%40googlegroups.com.

[Vasil Velichkov]

Hi David,

On Tuesday, June 5, 2018 at 8:42:04 PM UTC+3, David Fox wrote:

Sample rate is 200.0e6/174.0 or ~ 1.14943M

Is there any particular reason to use this rather odd sampling rate and not 1M for example like in uplink_decoding_multi_rtl.grc? 

I'm attaching my flowgraph. It's a bit of a mess, but everything disabled was disabled when I took those captures.​

 get_bcch_msgs_from_rtlsdr.grc

Ch1: RF Gain (dB) is set to -20 while Ch0: RF Gain (db) is 40, why is that ?

Could you try to set both to the same value as in the multi-rtl/examples/mutlirtl_rx_to_cfile_2chan.grc

In the second GSM Input Adaptor (the uplink one) you have to set the center frequency to fc - 45e6 and not to fc.

Cheers,

Vasil

[David Fox]

Is there any particular reason to use this rather odd sampling rate and not 1M for example like in uplink_decoding_multi_rtl.grc? 

That's just what the example (that comes with gr-gsm) had it set to. I'm trying with 1M now, and I'm able to get downlink just fine, but still no decoded uplink.

  Ch1: RF Gain (dB) is set to -20 while Ch0: RF Gain (db) is 40, why is that ?

I'm running the downlink hardware at extremely low power without an​​y antenna gain, but the uplink is, well, a phone. Hence, the disparity. Those numbers are giving reasonable power levels, based on the visuals in the FFT and time-series plots. I can certainly play with gain settings, but I think they're okay. I'm attaching a screenshot showing as much.

​

 Screenshot from 2018-06-05 16-23-19.png

​

In the second GSM Input Adaptor (the uplink one) you have to set the center frequency to fc - 45e6 and not to fc.

That was 100% an error, but when running with that corrected, I'm still not seeing the uplink get past the decoder. I was really hoping that was the critical problem, but alas, it isn't. Thanks for finding that oversight though. 

 

--

You received this message because you are subscribed to the Google Groups "gr-gsm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gr-gsm+unsubscribe@googlegroups.com.
To post to this group, send email to gr-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gr-gsm/8b4d8de4-75f8-4b7a-a5ae-928f5aa495c3%40googlegroups.com.

[Vasil Velichkov]

Hi David,

On Tuesday, June 5, 2018 at 11:27:24 PM UTC+3, David Fox wrote:

Is there any particular reason to use this rather odd sampling rate and not 1M for example like in uplink_decoding_multi_rtl.grc? 

That's just what the example (that comes with gr-gsm) had it set to. I'm trying with 1M now, and I'm able to get downlink just fine, but still no decoded uplink.

Ok.

 

  Ch1: RF Gain (dB) is set to -20 while Ch0: RF Gain (db) is 40, why is that ?

I'm running the downlink hardware at extremely low power without an​​y antenna gain, but the uplink is, well, a phone. Hence, the disparity. Those numbers are giving reasonable power levels, based on the visuals in the FFT and time-series plots. I can certainly play with gain settings, but I think they're okay. I'm attaching a screenshot showing as much.

​

 Screenshot from 2018-06-05 16-23-19.png

I have no formal RF training and I don't really understand the "low level" stuff and I can't confirm whether the signal levels are good or not.

 

In the second GSM Input Adaptor (the uplink one) you have to set the center frequency to fc - 45e6 and not to fc.

That was 100% an error, but when running with that corrected, I'm still not seeing the uplink get past the decoder. I was really hoping that was the critical problem, but alas, it isn't. Thanks for finding that oversight though.

I'm also not able to get any uplink messages from your cfiles no matter what I try but I have another idea - try to capture a voice call, the voice is in TCH/F channel and the problem could be in demapping/decoding the SDCCH4 thats used for SMS.

In another thread we were able to decode the uplink and downlink voice captured from openbts. Download the cfiles and the flowgraphs from that thread and try to decode them.

Cheers,

Vasil

[David Fox]

I did see that thread previously, but I didn't run the data files through the flowgraph at the time.

I did that now, and I do see uplink messages generated in wireshark, but only for the FACCH. I will play around with the example some more to see if I can get other uplink channels to decode.

--

You received this message because you are subscribed to the Google Groups "gr-gsm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gr-gsm+unsubscribe@googlegroups.com.
To post to this group, send email to gr-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gr-gsm/fad573fb-be15-4ec0-9d77-279a5afd554a%40googlegroups.com.

[David Fox]

I found a SDCCH uplink burst on timeslot 2 in the files/flowgraph from that thread. I haven't had any luck with my files nor live captures, even trying to emulate the setup from that flowgraph. I will look at capturing from the TCH/F channel now.

[Piotr Krysik]

Hi David,

I looked at the uplink capture file. I can definitely see uplink bursts
there (just by looking at the signal amplitude). What is wrong is that
some part of the bursts saturated your receiver. Look at the screenshot
of signal plot of the signal's IQ data. For GMSK signal the plot should
have circular shape, but it is square (because of saturating both I and
Q channels' ADCs).

If you used Multi-RTL for the capture, reduce the gain for the uplink
channel.

Best Regards,
Piotr Krysik

W dniu 07.06.2018 o 00:57, David Fox pisze:

>  Screenshot from 2018-06-05 16-23-19.png
> <https://drive.google.com/file/d/1KSFFTakUOb-2xIuxvhx-5qZzS2yw5O-l/view?usp=drive_web>

>
>
> I have no formal RF training and I don't really understand the
> "low level" stuff and I can't confirm whether the signal levels
> are good or not.
>  
>
>
> In the second GSM Input Adaptor (the uplink one) you
> have to set the center frequency to fc - 45e6 and not to
> fc.
>
>
> That was 100% an error, but when running with that
> corrected, I'm still not seeing the uplink get past the
> decoder. I was really hoping that was the critical problem,
> but alas, it isn't. Thanks for finding that oversight though.
>
>
> I'm also not able to get any uplink messages from your cfiles no
> matter what I try but I have another idea - try to capture a
> voice call, the voice is in TCH/F channel and the problem could
> be in demapping/decoding the SDCCH4 thats used for SMS.
>
> In another thread

> <https://groups.google.com/d/msg/gr-gsm/6VJ6N1YZcHA/tJUHcvYQAQAJ>we

> were able to decode the uplink and downlink voice captured from
> openbts. Download the cfiles and the flowgraphs

> <https://groups.google.com/group/gr-gsm/attach/18f8508701dbf/uplink_decoding_openbts_ts2_ts3.grc?part=0.1&authuser=0>

> from that thread and try to decode them.
>
> Cheers,
> Vasil
>
> --
> You received this message because you are subscribed to the
> Google Groups "gr-gsm" group.
> To unsubscribe from this group and stop receiving emails from

> it, send an email to gr-gsm+un...@googlegroups.com
> <mailto:gr-gsm+un...@googlegroups.com>.

> To post to this group, send email to gr-...@googlegroups.com

> <mailto:gr-...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gr-gsm/fad573fb-be15-4ec0-9d77-279a5afd554a%40googlegroups.com

> <https://groups.google.com/d/msgid/gr-gsm/fad573fb-be15-4ec0-9d77-279a5afd554a%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.
>
>
>

[David Fox]

That makes sense. I thought I was okay because the time-series looked alright, but I guess that wasn't showing the whole picture. I'll see about reducing gain and hopefully the bits start flowing.

>         it, send an email to gr-gsm+unsubscribe@googlegroups.com
>         <mailto:gr-gsm+unsubscribe@googlegroups.com>.

>         To post to this group, send email to gr-...@googlegroups.com

>         <mailto:gr-gsm@googlegroups.com>.

>         To view this discussion on the web visit
>         https://groups.google.com/d/msgid/gr-gsm/fad573fb-be15-4ec0-9d77-279a5afd554a%40googlegroups.com
>         <https://groups.google.com/d/msgid/gr-gsm/fad573fb-be15-4ec0-9d77-279a5afd554a%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
>         For more options, visit https://groups.google.com/d/optout
>         <https://groups.google.com/d/optout>.

>
>
>

--
You received this message because you are subscribed to the Google Groups "gr-gsm" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gr-gsm+unsubscribe@googlegroups.com.
To post to this group, send email to gr-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gr-gsm/03938802-98bb-7722-36b2-a07c04159061%40gmail.com.

For more options, visit https://groups.google.com/d/optout.