Proposal: channel hopping

[rpp0]

Dear all,

I'm trying to implement real time channel hopping for gr-gsm. Here are some approaches that I considered:

• Capture a wide portion of the spectrum, channelize using the Polyphase Channelizer block and then parse all channels simultaneously similar to how it is done in this project: https://github.com/BogdanDIA/airprobe-hopping. The disadvantage of this approach is that doing this in real time is very expensive, and in my opinion infeasible. Could be handy though when decoding from a file instead of real time.
• Parse an Immediate Assignment, calculate the hopping sequence and "follow" it in the same way an ordinary phone would. Currently I have a basic implementation that does this by parsing the Immediate Assignment and communicating the frequency to the Source block over Unix domain sockets. However, I'm not sure whether this is fast enough considering the switch must happen in 1ms.

In any case, I'm currently stuck with parsing the first hop to a SDCCH channel. I tried using the TCH/F demapper from this branch but I'm not getting any data in Wireshark. I was expecting to see some control data or occasional packets from phones hopping to the channel in question. Is decoding the SDCCH already supported? If not I would be happy to help :).

[bluelightvision]

the input file that I am using is also of type int16, but still nothing gets decoded.

[ptrkrysik]

Did you set proper parameters: -carreir frequency fc, -sample rate, -decimation (where samp_rate/decim >=200e3), -carrier frequency offset (it there is any) ?

[bluelightvision]

I guess the parameters are set properly, but I think it might be because of my input file. For recording the file, I'm using the output of the RTL-SDR Source block and converting it to Ishort. Should there be some more conversions ?

[ptrkrysik]

Can you show the GRC file that you use to make recording?

[bluelightvision]

here is the GRC I am using:

[gtr5]

Hi, I was using gr-gsm to obtain data from a non-hopping frequency, it worked fine. But when I try to get data from another frequency nothing appears (none of the demapping and decoding blocks gave bit streams). So my question is does gr-gsm decode hopping frequencies (regardless of the order of bursts) ?

[romankh]

@bluelightvision: there is no need to convert to short, as gsm input adapter takes complex as input. Just save it as complex.

@gtr5: No, that won't work if you don't pay attention to the order of bursts. That's what rpp0's block is for, it takes the bursts from different frequencies according to the hopping params, so that the right bursts are grouped together.

[gtr5]

that explains why I can't get data! Thanks

[gtr5]

concerning the "CX channel hopper" block, does it work properly if one of the channels has some lost bursts? In some cases I receive nothing at its output although I can see CX bursts at its input.

for example I can get data bursts when MAIO is 4 but nothing when it is 3.

[ptrkrysik]

Currently any burst of a message that is lost means that the whole message is lost. The decoder might support decoding messages with one burst lost but it doesn't currently implement this functionality.

[gtr5]

If I remove a small part at the beginning of the capture would it still be able to decode the frames. Also, can't we give the channel hopper the frame number where it should start the frequency hopping algorithm?

[rpp0]

You should be able to decode frames regardless of when you started the capture. Perhaps something is wrong with your configuration; can you share your grc?

[gtr5]

The channel hopper block is working fine but not for all HSN and MAIO configurations for a given input capture. If I change the capture file, the same configuration that was not working will work for the new capture. I'm using the same grc that you had shared previously (only adjusted the channel values for my case).

[ptrkrysik]

If I remove a small part at the beginning of the capture would it still be able to decode the frames. Also, can't we give the channel hopper the frame number where it should start the frequency hopping algorithm? Single burst lost affects only single message - not whole capture. If you remove part from the beginning it won't affect the rest.

[ptrkrysik]

Do you have confirmation from Assignment Commands that all HSNs and MAIOs that you are trying to use are assigned to some channel during the capture?

[gtr5]

Yes, the configuration that I used is the same as obtained from Assignment Command.

[gtr5]

It seems that my "TSEQ numbers" value was not set correctly. For my case the training sequence is 3, so should I set it as [3] or [3,3,3,3,3,3] ?

[ptrkrysik]

It seems that my "TSEQ numbers" value was not set correctly. For my case the training sequence is 3, so should I set it as [3] or [3,3,3,3,3,3] ?

The detection algorithm might have not detected it correctly. [3] and vector containing repeating 3 should have the same effect.

[gtr5]

Thank you guys, its working perfectly now !

[rpp0]

As this block has been implemented, I think this issue can be closed.

[ptrkrysik]

I think you are right. I kept that issue as there are some things that need to be done in order to make frequency hopping more usable for general public. But it will be better to be more specific. What needs to be done is: -implementing channelization - for this gnuradio's pfb channelizer (or frequency xlating filter bank) can be used but ideally it would be best to have something that have chance of working in realtime, -preparing a tutorial that will make channel hopping more accessible.

We can add these things as proposals of enhancements.

[rpp0]

Yes I agree, that would be nice! I have created https://github.com/ptrkrysik/gr-gsm/issues/105 for these proposals.