Channelizer block
933 views
Skip to first unread message
Pieter Robyns
Oct 1, 2015, 5:08:18 AM10/1/15
to gr-gsm
Hi all,
A number of days ago, I created a standalone app for channelizing a multiband capture into multiple smaller files (https://github.com/ptrkrysik/gr-gsm/blob/master/apps/gsm_channelize.py). This script allows the user to decode hopping channels as shown in the lefmost figure below. As you can see, the flowgraph involves quite a lot of blocks. For that reason, I merged the channelization functionality into one block (GSM multiband input adaptor), where the user can configure the channels to decode.
In theory, this new block also allows real-time channelization and hopping, but currently that requires a lot of computing power and I would not consider it practically feasible on a regular machine. Using a file block instead of an actual source (USRP) it is possible to decode hopping channels -- albeit slow -- on one machine, but it is still a lot slower than the multiple file approach because the files are already channelized there.
My question is now whether, given the disadvantages, this block would still be interesting for inclusion in the gr-gsm project.
A number of days ago, I created a standalone app for channelizing a multiband capture into multiple smaller files (https://github.com/ptrkrysik/gr-gsm/blob/master/apps/gsm_channelize.py). This script allows the user to decode hopping channels as shown in the lefmost figure below. As you can see, the flowgraph involves quite a lot of blocks. For that reason, I merged the channelization functionality into one block (GSM multiband input adaptor), where the user can configure the channels to decode.
In theory, this new block also allows real-time channelization and hopping, but currently that requires a lot of computing power and I would not consider it practically feasible on a regular machine. Using a file block instead of an actual source (USRP) it is possible to decode hopping channels -- albeit slow -- on one machine, but it is still a lot slower than the multiple file approach because the files are already channelized there.
My question is now whether, given the disadvantages, this block would still be interesting for inclusion in the gr-gsm project.
roman khassraf
Oct 4, 2015, 4:43:57 AM10/4/15
to gr-gsm
Hi Pieter,
I vote for adding your second block.
Even if slower, we can still use it for experiments, and it may be useful in the future.
Better having it and not needing it, than needing it and not having it.
Best regards
Roman
I vote for adding your second block.
Even if slower, we can still use it for experiments, and it may be useful in the future.
Better having it and not needing it, than needing it and not having it.
Best regards
Roman
Piotr Krysik
Oct 4, 2015, 5:56:59 AM10/4/15
to gr-...@googlegroups.com
W dniu 01.10.2015 o 11:08, Pieter Robyns pisze:
Hi Pieter,
Making channelization in form of a block - even if it won't be working
in realtime - is valuable. This way we will be able to drop it in
flowgraphs processing data from multiple channels without cluttering
them too much. In future the block can be changed internally to make it
faster (for example by putting GNU Radio's PFB channelizer inside) but
the interface can stay.
--
Best Regards,
Piotr Krysik
Making channelization in form of a block - even if it won't be working
in realtime - is valuable. This way we will be able to drop it in
flowgraphs processing data from multiple channels without cluttering
them too much. In future the block can be changed internally to make it
faster (for example by putting GNU Radio's PFB channelizer inside) but
the interface can stay.
--
Best Regards,
Piotr Krysik
Ajay Fuloria
Oct 4, 2015, 3:11:00 PM10/4/15
to gr-gsm
Hi all,
I have a query. if I try and capture the different hopping frequencies with different rtl-sdrs and then give that as input to a program can I decode the hopping signal.
Problem is I can not afford a USRP and I still want to decode the hopping GSM channel, if the above approach is conceptually right, then I will give it a try first using different rtl sdrs and then using rtl- tcp
Please let me know your comments.
Thanksv and regards
Ajay.
Tomcsányi, Domonkos
Oct 4, 2015, 5:14:01 PM10/4/15
to Ajay Fuloria, gr-gsm
Hi Ajay
Capturing with multiple rtlsdr devices poses a really tricky challenge: synchronizing the clock of the devices. Bogdan did that once, but according to his blogpost it is quite hard.
To decode hopping stuff you might want to look at osmocomBB - I know it is complicated but it does have the capability to follow a hopping call just the code isn't out for that.
This was my opinion only, maybe others on this list have better suggestions.
Cheers,
Domi
Capturing with multiple rtlsdr devices poses a really tricky challenge: synchronizing the clock of the devices. Bogdan did that once, but according to his blogpost it is quite hard.
To decode hopping stuff you might want to look at osmocomBB - I know it is complicated but it does have the capability to follow a hopping call just the code isn't out for that.
This was my opinion only, maybe others on this list have better suggestions.
Cheers,
Domi
> --
> Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie „gr-gsm”.
>
> Aby anulować subskrypcję tej grupy i przestać otrzymywać od niej wiadomości, wyślij e-maila na gr-gsm+un...@googlegroups.com.
> Aby zamieszczać posty w tej grupie, wyślij e-mail na adres gr-...@googlegroups.com.
> Aby wyświetlić tę dyskusję w internecie, odwiedź stronę https://groups.google.com/d/msgid/gr-gsm/83d16e96-6263-4d22-bde4-c381eb2277eb%40googlegroups.com.
> Więcej opcji znajdziesz na https://groups.google.com/d/optout
> Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie „gr-gsm”.
>
> Aby anulować subskrypcję tej grupy i przestać otrzymywać od niej wiadomości, wyślij e-maila na gr-gsm+un...@googlegroups.com.
> Aby zamieszczać posty w tej grupie, wyślij e-mail na adres gr-...@googlegroups.com.
> Aby wyświetlić tę dyskusję w internecie, odwiedź stronę https://groups.google.com/d/msgid/gr-gsm/83d16e96-6263-4d22-bde4-c381eb2277eb%40googlegroups.com.
> Więcej opcji znajdziesz na https://groups.google.com/d/optout
Piotr Krysik
Oct 5, 2015, 3:47:48 AM10/5/15
to gr-...@googlegroups.com
Hi all,
We started implementing frequency hopping with USRPs because these
devices are much easier to use for this purpose (they have stable and
accurate clock and support wide bandwidths). Implementing frequency
hopping on cheap devices like RTL-SDR would be of course very cool.
However it is not that simple as you have to overcome two problems first:
-synchronization of RTL-SDRs in frequency,
-synchronization of RTL-SDRs in time.
Clocks of the devices can be synchronized in frequency by connecting
them to the same clock reference. It requires hardware change and
probably it would be good to have an additional clock generator.
Here is an example:
http://www.rtl-sdr.com/rtl-sdr-based-coherent-multichannel-receiver/
To synchronize the devices in time is more tricky. I can imagine that it
could be done completely in software if the devices keep synchronization
over carrier frequency changes. They could be tuned to the same GSM or
DVB-T channel and signals from different devices could be correlated to
compute time offsets.
So I have some idea how it can be done but I don't have plans to work on
this issue in the nearest future as we still have some way to go with
our hopping implementation using USRPs. We can add proposition of
enhancement to the project and see if there is someone willing to
implement it.
Best Regards,
Piotr
W dniu 04.10.2015 o 23:13, Tomcsányi, Domonkos pisze:
> --
> Otrzymujesz tę wiadomość, bo subskrybujesz grupę „gr-gsm” w Grupach
> dyskusyjnych Google.
> Aby opublikować wpis w tej grupie, wyślij e-maila na
> gr-...@googlegroups.com <mailto:gr-...@googlegroups.com>.
> Aby wyświetlić tę dyskusję w internecie, otwórz
> https://groups.google.com/d/msgid/gr-gsm/CF4A2621-A125-4ABD-8CED-632B8618A7B9%40tomcsanyi.net
> <https://groups.google.com/d/msgid/gr-gsm/CF4A2621-A125-4ABD-8CED-632B8618A7B9%40tomcsanyi.net?utm_medium=email&utm_source=footer>.
> Więcej opcji znajdziesz na https://groups.google.com/d/optout.
--
Piotr Krysik
We started implementing frequency hopping with USRPs because these
devices are much easier to use for this purpose (they have stable and
accurate clock and support wide bandwidths). Implementing frequency
hopping on cheap devices like RTL-SDR would be of course very cool.
However it is not that simple as you have to overcome two problems first:
-synchronization of RTL-SDRs in frequency,
-synchronization of RTL-SDRs in time.
Clocks of the devices can be synchronized in frequency by connecting
them to the same clock reference. It requires hardware change and
probably it would be good to have an additional clock generator.
Here is an example:
http://www.rtl-sdr.com/rtl-sdr-based-coherent-multichannel-receiver/
To synchronize the devices in time is more tricky. I can imagine that it
could be done completely in software if the devices keep synchronization
over carrier frequency changes. They could be tuned to the same GSM or
DVB-T channel and signals from different devices could be correlated to
compute time offsets.
So I have some idea how it can be done but I don't have plans to work on
this issue in the nearest future as we still have some way to go with
our hopping implementation using USRPs. We can add proposition of
enhancement to the project and see if there is someone willing to
implement it.
Best Regards,
Piotr
W dniu 04.10.2015 o 23:13, Tomcsányi, Domonkos pisze:
> Otrzymujesz tę wiadomość, bo subskrybujesz grupę „gr-gsm” w Grupach
> dyskusyjnych Google.
> Aby anulować subskrypcję tej grupy i przestać otrzymywać od niej
> wiadomości, wyślij e-maila na gr-gsm+un...@googlegroups.com
> <mailto:gr-gsm+un...@googlegroups.com>.
> wiadomości, wyślij e-maila na gr-gsm+un...@googlegroups.com
> Aby opublikować wpis w tej grupie, wyślij e-maila na
> gr-...@googlegroups.com <mailto:gr-...@googlegroups.com>.
> Aby wyświetlić tę dyskusję w internecie, otwórz
> https://groups.google.com/d/msgid/gr-gsm/CF4A2621-A125-4ABD-8CED-632B8618A7B9%40tomcsanyi.net
> <https://groups.google.com/d/msgid/gr-gsm/CF4A2621-A125-4ABD-8CED-632B8618A7B9%40tomcsanyi.net?utm_medium=email&utm_source=footer>.
> Więcej opcji znajdziesz na https://groups.google.com/d/optout.
--
Piotr Krysik
Tomcsányi Domonkos
Oct 5, 2015, 3:57:02 AM10/5/15
to Piotr Krysik, gr-...@googlegroups.com
Hi all,
I totally agree with Piotr on this one. Although I need to add, that a single RTL-SDR can listen to about 10 frequencies - ARFCNs (2 MHz of bandwidth) simultaneously, so if the hopping happens in such range then you should be able to decode the traffic.
Also something different: I’m wondering if using the transceiver app of osmocomBB would be of any help - in that mode the phone kind of acts like an SDR, maybe with some patching we could follow the hopping instead of using an USRP - of course this would require knowledge of the hopping parameters before the call (having access to the session key Kc).
I’ll try to look into this maybe later this year, just out of curiosity.
Cheers,
Domi
> Aby wyświetlić tę dyskusję w internecie, odwiedź stronę https://groups.google.com/d/msgid/gr-gsm/56122B22.4030903%40gmail.com.
I totally agree with Piotr on this one. Although I need to add, that a single RTL-SDR can listen to about 10 frequencies - ARFCNs (2 MHz of bandwidth) simultaneously, so if the hopping happens in such range then you should be able to decode the traffic.
Also something different: I’m wondering if using the transceiver app of osmocomBB would be of any help - in that mode the phone kind of acts like an SDR, maybe with some patching we could follow the hopping instead of using an USRP - of course this would require knowledge of the hopping parameters before the call (having access to the session key Kc).
I’ll try to look into this maybe later this year, just out of curiosity.
Cheers,
Domi
Pieter Robyns
Oct 5, 2015, 4:15:10 AM10/5/15
to gr-gsm
Hi,
Okay, I will clean up the block code and create a pull request today :-).
@Ajay: I think if you manage to synchronise the clocks of your RTL-SDRs, you will still have the issue of requiring too much computing power to process them all at the same time. However, I'm currently looking at a different approach: I modified the SDR source blocks to include a control port, so the frequency can be changed dynamically in the (C++) code. If the hardware can change frequencies fast enough, this could allow us to hop in real time like a mobile phone does. I will report on my findings soon.
Cheers,
Pieter
Okay, I will clean up the block code and create a pull request today :-).
@Ajay: I think if you manage to synchronise the clocks of your RTL-SDRs, you will still have the issue of requiring too much computing power to process them all at the same time. However, I'm currently looking at a different approach: I modified the SDR source blocks to include a control port, so the frequency can be changed dynamically in the (C++) code. If the hardware can change frequencies fast enough, this could allow us to hop in real time like a mobile phone does. I will report on my findings soon.
Cheers,
Pieter
Tomcsányi, Domonkos
Oct 5, 2015, 4:30:18 AM10/5/15
to Pieter Robyns, gr-gsm
I'm sorry to kill your hopes but there is almost no way that an SDR can switch as fast as its needed for hopping.
GSM hops at every single burst, meaning that you would need to do this:
Tune, listen for 0,577 ms, tune again (for that you should have 7*0,577 ms, because there are 8 timeslots, so till your burst comes again there are 7 different ones), listen for 0,577 ms etc.
I don't think any SDR hardware is capable of doing this, but you could look at the datasheets and do some experiments of course, I might be wrong.
Cheers,
Domi
--
Otrzymujesz tę wiadomość, bo subskrybujesz grupę „gr-gsm” w Grupach dyskusyjnych Google.
Aby anulować subskrypcję tej grupy i przestać otrzymywać od niej wiadomości, wyślij e-maila na gr-gsm+un...@googlegroups.com.
Aby opublikować wpis w tej grupie, wyślij e-maila na gr-...@googlegroups.com.
Aby wyświetlić tę dyskusję w internecie, otwórz https://groups.google.com/d/msgid/gr-gsm/3595bed4-cb3f-41d7-8072-1da906d64fe3%40googlegroups.com.
Pieter Robyns
Oct 5, 2015, 7:39:24 AM10/5/15
to gr-gsm
Hi,
Yes that's true, I will do some experimenting with how fast we can change frequencies. Nevertheless, I have an idea that will probably work: use the control port to only change the FIR filter offset and not the entire center frequency. This will require a high sample rate, but it will eliminate the need for channelization and therefore hopping should be possible in real time if I'm not missing anything.
Cheers,
Pieter
Yes that's true, I will do some experimenting with how fast we can change frequencies. Nevertheless, I have an idea that will probably work: use the control port to only change the FIR filter offset and not the entire center frequency. This will require a high sample rate, but it will eliminate the need for channelization and therefore hopping should be possible in real time if I'm not missing anything.
Cheers,
Pieter
Tomcsányi Domonkos
Oct 5, 2015, 7:41:58 AM10/5/15
to Pieter Robyns, gr-gsm
This is actually a smart idea, nice!
Although it would still require a USRP, but it should work fine :).
It’s sad that uplink is so far away from downlink that we can’t keep switching between those (maybe an N210 with 100 MHz of BW could do that).
Again, good thinking, I like it!
Cheers,
Domi
Aby wyświetlić tę dyskusję w internecie, otwórz https://groups.google.com/d/msgid/gr-gsm/9494e8a8-bbcf-424d-9073-77bb7552645a%40googlegroups.com.
Piotr Krysik
Oct 9, 2015, 8:23:38 AM10/9/15
to gr-...@googlegroups.com
Hi all,
I did simple yet important test if RTL-SDR keeps time synchronization
across retunnings. I recorded signal on two different frequencies: one
with GSM signal, one with noise. Then I rearranged signal into matrix
with subsequent bursts amplitude in rows. The result for two recordings
is attached to this e-mail. What can be observed is that most probably
the time sync is kept.
This means that it will be possible to sync two devices by recording the
same signal, computing time offset (with use of correlation or GSM
synchronization bursts) and then switching them to working frequencies.
Best Regards,
Piotr
W dniu 05.10.2015 o 09:57, Tomcsányi Domonkos pisze:
--
Piotr Krysik
I did simple yet important test if RTL-SDR keeps time synchronization
across retunnings. I recorded signal on two different frequencies: one
with GSM signal, one with noise. Then I rearranged signal into matrix
with subsequent bursts amplitude in rows. The result for two recordings
is attached to this e-mail. What can be observed is that most probably
the time sync is kept.
This means that it will be possible to sync two devices by recording the
same signal, computing time offset (with use of correlation or GSM
synchronization bursts) and then switching them to working frequencies.
Best Regards,
Piotr
W dniu 05.10.2015 o 09:57, Tomcsányi Domonkos pisze:
Piotr Krysik
Tomcsányi, Domonkos
Oct 9, 2015, 8:45:00 AM10/9/15
to Piotr Krysik, gr-...@googlegroups.com
Hi,
Sounds absolutely great, but I don't see the attachment :).
Cheers
Domi
Sounds absolutely great, but I don't see the attachment :).
Cheers
Domi
>>>> .
>>>> Aby opublikować wpis w tej grupie, wyślij e-maila na
>>>> Aby opublikować wpis w tej grupie, wyślij e-maila na
>>>> gr-...@googlegroups.com .
>>>> Aby wyświetlić tę dyskusję w internecie, otwórz
>>>> https://groups.google.com/d/msgid/gr-gsm/CF4A2621-A125-4ABD-8CED-632B8618A7B9%40tomcsanyi.net
>>>> .
>>>> Więcej opcji znajdziesz na https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> Piotr Krysik
>>>
>>> --
>>> Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie „gr-gsm”.
>>>
>>> Aby anulować subskrypcję tej grupy i przestać otrzymywać od niej wiadomości, wyślij e-maila na gr-gsm+un...@googlegroups.com.
>>> Aby zamieszczać posty w tej grupie, wyślij e-mail na adres gr-...@googlegroups.com.
>>> Aby wyświetlić tę dyskusję w internecie, odwiedź stronę https://groups.google.com/d/msgid/gr-gsm/56122B22.4030903%40gmail.com.
>>> Więcej opcji znajdziesz na https://groups.google.com/d/optout
>
>
> --
> Piotr Krysik
>
>>>> Więcej opcji znajdziesz na https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> Piotr Krysik
>>>
>>> --
>>> Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie „gr-gsm”.
>>>
>>> Aby anulować subskrypcję tej grupy i przestać otrzymywać od niej wiadomości, wyślij e-maila na gr-gsm+un...@googlegroups.com.
>>> Aby zamieszczać posty w tej grupie, wyślij e-mail na adres gr-...@googlegroups.com.
>>> Aby wyświetlić tę dyskusję w internecie, odwiedź stronę https://groups.google.com/d/msgid/gr-gsm/56122B22.4030903%40gmail.com.
>>> Więcej opcji znajdziesz na https://groups.google.com/d/optout
>
>
> --
> Piotr Krysik
>
> --
> Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie „gr-gsm”.
>
> Aby anulować subskrypcję tej grupy i przestać otrzymywać od niej wiadomości, wyślij e-maila na gr-gsm+un...@googlegroups.com.
> Aby zamieszczać posty w tej grupie, wyślij e-mail na adres gr-...@googlegroups.com.
> Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie „gr-gsm”.
>
> Aby anulować subskrypcję tej grupy i przestać otrzymywać od niej wiadomości, wyślij e-maila na gr-gsm+un...@googlegroups.com.
> Aby zamieszczać posty w tej grupie, wyślij e-mail na adres gr-...@googlegroups.com.
> Aby wyświetlić tę dyskusję w internecie, odwiedź stronę https://groups.google.com/d/msgid/gr-gsm/5617B1C7.2080206%40gmail.com.
lion b.n
Apr 21, 2016, 6:38:02 PM4/21/16
to gr-gsm
I totally agree with Piotr on this one. Although I need to add, that a
single RTL-SDR can listen to about 10 frequencies - ARFCNs (2 MHz of
bandwidth) simultaneously, so if the hopping happens in such range then
you should be able to decode the traffic.
can u tell me how i can capture 2 MHz (10 ARFCN) then channelize
Reply all
Reply to author
Forward
0 new messages