[Discuss-gnuradio] Announcing new gr-gsm project
Dear all, I was working for some time on a project of a set of GNU Radio tools for receiving GSM transmissions. As the project reached the point where it might be useful for the community I have decided to officially announce it. It is available on github with short installation and usage guides: https://github.com/ptrkrysik Currently there is one gr-gsm application that should work out of the box and it is a more reliable replacement of Airprobe. The gr-gsm has some similarities with it. The GSM receiver that I used is considerably corrected version of the receiver that I've long time ago written for the Airprobe project but with removed Airprobe's stuff that shouldn't be mixed with the receiver (like decryption, decoding). However the goal of the project is broader and it is to provide a set of tools for people interested in processing of GSM signal in GNU Radio. For example - another possible applications of gr-gsm are GSM network monitor or frequency offset calibrator. For people who want to see the application in action without installing it I've prepared a short video presentation: https://www.youtube.com/watch?v=Eofnb7zr8QE&feature=youtu.be If anyone is interested in developing something for/with use of the project I can provide help and information about the project's internals by e-mail. -- Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Idea of a USRP UHD block that fills gaps in transmission from USRP
Hi all, Interruptions transmission over Gigabit Ethernet when receiving samples from USRP can happen at highest data rates no matter how many tricks you use with your network card (I have experience with N200/N210). The loss of part of the signal results with synchronization loss in data transmission systems. There is possibility to handle this problem by catching rx_time stream tags. But there might be a solution to keep synchronization that might work quite well with gr-blocks that don't handle stream tags. What if USRP UHD Source gave user an option to fill all of the gaps in signal with exact number of lost samples (for example with zeros). Additionally it could produce stream tags with position and length of each gap so it would be easy to store a file with continuous signal stream paired with a file containing metadata describing where and for how long the signal samples were lost. Is it possible to do exactly what I'm describing with current gnuradio blocks? In my case it would often make many things I do easier. -- Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The GMSK demodulation
W dniu 28.02.2014 15:31, zhenhua han pisze: > Hi, > > As I have known, GSM uses GMSK modulation which BT = 0.3 and it > uses Viterbi algorithm for demodulation. And I took a look at the code > of GMSK demod code in GNU Radio, it use quadrature_demod but not > Viterbi as demodulation method. So which one is better in doing > demodulating GMSK? > > Moreover, GSM uses Viterbi algorithm to decode the convolution > encoding. Would it be possible to use quadrature_demod to demodulate > GSM signal instead of Viterbi? What about the convolution decoding > part (maybe by some other method)? > > Cheers, > Zhenhua > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Hello all, Regarding usage of viterbi algorithm for maximum likelihood sequence estimation in GSM - you may look at and try gsm-receiver that I once submitted to airprobe. I've prepared version where I thrown out all of decoding stuff and left only synchronization, channel estimation and detection of GMKS symbols with viterbi algorithm. It's available for download in here: https://github.com/Jakotako/gr-gsm It compiles with newest gnu-radio and it has gnuradio companion xml file as well. It can be easily connected to different sources in gnuradio (file, rtl-sdr, usrp). I've corrected some issues with synchronization and turned off frequency offset correction that introduced instability of the receiver. There are examples of in the "examples" directory. P.S. If someone applied Achilleas's implementation of viterbi algorithm from gnu-radio in GSM I'm very interested to see how it can be done. -- Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The GMSK demodulation
W dniu 28.02.2014 15:31, zhenhua han pisze: > Hi, > > As I have known, GSM uses GMSK modulation which BT = 0.3 and it > uses Viterbi algorithm for demodulation. And I took a look at the code > of GMSK demod code in GNU Radio, it use quadrature_demod but not > Viterbi as demodulation method. So which one is better in doing > demodulating GMSK? > > Moreover, GSM uses Viterbi algorithm to decode the convolution > encoding. Would it be possible to use quadrature_demod to demodulate > GSM signal instead of Viterbi? What about the convolution decoding > part (maybe by some other method)? > > Cheers, > Zhenhua > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Hello all, Regarding usage of viterbi algorithm for maximum likelihood sequence estimation in GSM - you may look at and try gsm-receiver that I once submitted to airprobe. I've prepared version where I thrown out all of decoding stuff and left only synchronization, channel estimation and detection of bits with viterbi algorithm. It's available for download in here: https://github.com/Jakotako/gr-gsm It compiles with newest gnu-radio and it has gnuradio companion xml file as well. It can be easily connected to different sources in gnuradio (file, rtl-sdr, usrp) and it has a message sink where burst bits and gsmtap headers are sent. I've corrected some issues with synchronization and turned off frequency offset correction that introduced instability of the receiver. After compiling and installing you can start with examples. -- Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The GMSK demodulation
> Hi Perper, > > I took a look at your code, and I found this > > //set_frequency(d_freq_offset); > > It seems you have turned off the the frequency offset correction as > you said. > Do you know the reason of the introduced instability by this part? > > Best, > Zhenhua Hi Zhenhua, The reason of instability is in the method of correction of the frequency offset. The offset is computed inside of gsm-receiver gnuradio block and it is fed to a frequency shifting fir filter. The connection of the blocks look like this: __freq. offset_ || v | xlating_fir_filter -> gsm-receiver There is lact of synchronization between computation of frequency offset and its correction inside of xlating_fir_filter. Synchronisation in this case is needed because the moment of computation of the estimate affects it. When new estimate of frequency correction is computed before previous is applied the connection with frequency offset becomes additive feedback loop. This problem can be corrected by integration frequency correction inside of the gsm-receiver or with use of stream tags. Generally I would like to split gr-gsm into smaller blocks that are easier to test but it will happen only if I find enough time for this. P.S. for some reason I didn't get your reply through my mailing list subscription (together with many more missing messages)... I've found it through the webpage lists.gnu.org/archive/html/discuss-gnuradio/ . -- Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSoC gr-gsm OOT module
W dniu 23.02.2014 17:12, Martin Braun pisze: > On 02/23/2014 09:39 AM, Sriram Damodharan wrote: >> I am currently working on a proof of concept system, and for which, I >> am using a patched version of airprobe, for GSM reception, using >> GNURadio. >> >> I want to contribute along side to the mainline and would like to know >> these, regarding GSoC: >> >> 1) can the proposed gr-gsm module use existing code from airprobe? > It's not forbidden, but I doubt it makes sense -- airprobe code is > highly convoluted and revolves around one monolithic block. > >> 2) Whom should I contact for further information, regarding the GSoC? > Post questions here. Remember that org applications are not done yet -- > we might not even be participating. Although I sure hope we do :) > > M > > Hi, Since I have written gsm-receiver for airprobe there was huge progress made by open source community (by Osmocom, OpenBTS, UmTRX) in implementations of different elements of GSM standard. However in my opinion there is still enough space for a modular and simple to understand implementation of a gsm receiver (frequency offset correction, synchronization, channel equalization, detection) that will take advantage of wideband hardware (wideband=whole GSM900 band) in order to receive symbols from multiple GSM channels. There is also space for gnuradio blocks that will implement gsm specific decoding or for a clever application of current gnuradio blocks for this task. I've prepared version of the gsm-receiver that doesn't have all decoding stuff that wasn't meant to be part of the receiver. It compiles with the newest version of GNU Radio and there are examples as well: https://github.com/Jakotako/gr-gsm Maybe you'll find it helpful. Best Regards, Piot Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The GMSK demodulation
W dniu 07.03.2014 06:06, zhenhua han pisze: > > 2014-03-04 21:55 GMT+08:00 Perper mailto:per...@o2.pl>>: > > > Hi Perper, > > > > I took a look at your code, and I found this > > > > //set_frequency(d_freq_offset); > > > > It seems you have turned off the the frequency offset correction as > > you said. > > Do you know the reason of the introduced instability by this part? > > > > Best, > > Zhenhua > Hi Zhenhua, > > The reason of instability is in the method of correction of the > frequency offset. > > The offset is computed inside of gsm-receiver gnuradio block and it is > fed to a frequency shifting fir filter. > > The connection of the blocks look like this: > > __freq. offset_ > || > v | > xlating_fir_filter -> gsm-receiver > > There is lact of synchronization between computation of frequency > offset > and its correction inside of xlating_fir_filter. Synchronisation > in this > case is needed because the moment of computation of the estimate > affects it. > When new estimate of frequency correction is computed before > previous is > applied the connection with frequency offset becomes additive > feedback loop. > > This problem can be corrected by integration frequency correction > inside > of the gsm-receiver or with use of stream tags. > > Generally I would like to split gr-gsm into smaller blocks that are > easier to test but it will happen only if I find enough time for this. > > P.S. for some reason I didn't get your reply through my mailing list > subscription (together with many more missing messages)... > I've found it through the webpage > lists.gnu.org/archive/html/discuss-gnuradio/ > <http://lists.gnu.org/archive/html/discuss-gnuradio/> . > > -- > Best Regards, > Piotr Krysik > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > Hi Perper, > > I'm writing the proposal to gr-gsm in GSoC. > Would it be possible to let me to fix the frequency correction as a > deliverable in my proposal ? > No matter if I get accepted in GSoC, I will finish this as a practice > of coding. > > Best, > Zhenhua > Hi Zhenhua, I'm not a member of GNU Radio developers team, so I'm not deciding about anything being accepted for GSoC. In my opinion fixing frequency correction on its own is a too simple task. I think that what is really needed is to solve the same problem that the airprobe's gsm-receiver tried to solve in more modular and easier to understand fashion by taking advantage of GNU Radio capabilities such as stream tags and message inputs/outputs. What gsm-receiver does is frequency offset correction, synchronization, channel estimation and detetection of bits. You can think about clever ways to separate those tasks into smaller blocks. As of now only broadcasting channel can be received by airprobe. Possible improvement would be implementation of reception of multiple frequency channels transmitted by a given GSM BTS. On a little higher level - you can also implement gnuradio blocks that decode channel codes used in gsm using available sources such as airprobe and osmocom. Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] "Run to completion" not working with message passing blocks
Hi all, I want to use message passing blocks for operations where strict synchronization is not necessary. However in flowgraphs using message passing with "Run to completion" option turned on the program doesn't exit on last processed sample. Is this a bug? I want to use message passing in my programs (mainly in https://github.com/Jakotako/gr-gsm) but completion after processing of all input data is also very important for me. -- Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Out of Tree Encryption block
Hi all, The system configuration proposed by Dushyant with encryption after channel coding can work in case of stream ciphers. This is how it is done in GSM. But encryption GSM is a very bad example of application of cryptography. Channel coding will add some known relations between information bits and it will be source weaknesses in the overall cryptosystem. Best Regards, Piotr Krysik W dniu 28.05.2014 22:45, Marcus Müller pisze: > Hi Dushyant, > > A side note: > I'm going to go assume that with "encoder" and "decoder" you mean > Channel Coding. > You *must* do channel coding after encryption, otherwise you won't get > decryptable bits > as soon as you don't have infinite SNR. This is not optional, because > with proper > encryption a single flipped bit will damage your signal in several places. > This thread reminds me of > http://lists.gnu.org/archive/html/discuss-gnuradio/2014-04/msg00277.html > so there might a solution to your problem there; Ralph has posted some > interesting insights > back then. > > Usually, you'll want to have something that applies something like a > block cipher on packetized data. > Although I'm not aware of any existing Modules that do this, using > stream tagged blocks, and the > gr-digital header demux infrastructure, you should be able to packetize > your data and encrypt the payload > en bloc, for example using AES. > > Greetings, > Marcus > > > On 28.05.2014 15:25, dushyant.marathe wrote: >> I want to simulate a voice transmission system in GNURadio Companion (GRC). >> >> My system configuration is as follows: >> >> TRANSMITTER : Wav file source --> encoder --> encryption --> modulator --> >> RF >> >> RECEIVER : speaker/Wav file sink <-- decoder <-- decryption <-- demodulator >> <-- RF >> >> I have simulated the above configuration in Ubuntu 12.04 machine but >> without >> encryption/decryption blocks. >> >> If you can point me to an existing OoTM of digital encryption, it would be >> nice. >> >> Thanks and Regards, >> Dushyant >> >> >> >> -- >> View this message in context: >> http://gnuradio.4.n7.nabble.com/Out-of-Tree-Encryption-block-tp48595.html >> Sent from the GnuRadio mailing list archive at Nabble.com. >> >> ___ >> 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 > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question regarding frequency offset correction
Hi all, In many applications very good synchronization of carrier and sampling frequencies is required. Available sources of signal not always have good clock reference. One of the examples is cheap RTL SDR receiver based on a DVB-T dongle. Without any additional effort to correct frequency offset it is impossible to decode GPS or GSM transmissions with such receivers. The frequency offset cannot be calibrated once as it changes with time and temperature. Good way to fight with it is to implement some correction algorithm that continuously computes frequency offset estimates and applies correction by: - performing frequency shifting and re-sampling in software, - or changing some hardware parameter that enables tuning of the frequency of an internal oscillator (like 'ppm' option in RTL SDR source). My question: is it possible to build working frequency correction with available GNU Radio blocks? Can you point some successful example? Or if not - can you share some ideas how it can be done? I'm especially interested in situations where frequency offset correction and estimation are in separate blocks i.e: __freq. offset_ | | v | |sig.source|-->|freq.offset|-->(processing)-->|freq. offset| |correction | |estimation | -- Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Message passing - issue with messages left in queues after running top block
Hi all,
I've noticed that "Run to completion" works now in situation when
message passing is used, which is great!
I have a related question. I'm creating a block which uses message
passing, and run it once:
tb = some_block(fname="file1")
tb.start()
tb.wait()
#at this moment tb has still some unprocessed messages in message queues
#so if I run the block again on another file ...
tb.set_fname("file2")
tb.start()
tb.wait()
I can see messages that were result of processing of file1. Do you know
how to avoid this?
One of acceptable solutions can be flushing msg queues after processing
of file1, but I don't know how to achieve this.
Best Regards,
Piotr Krysik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Clarification
W dniu 08.08.2014 o 11:53, 奕佑 pisze: > Hello, > > I have the same problem before. After adding the virtual function in > include directory and other are done. > > You need to "make clean" and after that you just make and make > install. The "AttributeError: 'module' object has no attribute" will > solve. > > I have no idea why the swig won't update when you add new virtual > function in include file if you have done make. > > Jeff Guo > Hi, I also ran into this problem that SWIG files aren't generated again when I change a block interface in a header from "include/" directory. I always have to make clean when I do that in order to successfully compile. Can it be easily corrected by editing cmake files? Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Clarification
W dniu 08.08.2014 o 15:25, Tom Rondeau pisze: > On Fri, Aug 8, 2014 at 6:22 AM, Perper <mailto:per...@o2.pl>> wrote: > > W dniu 08.08.2014 o 11:53, 奕佑 pisze: > > Hello, > > > > I have the same problem before. After adding the virtual function in > > include directory and other are done. > > > > You need to "make clean" and after that you just make and make > > install. The "AttributeError: 'module' object has no attribute" will > > solve. > > > > I have no idea why the swig won't update when you add new virtual > > function in include file if you have done make. > > > > Jeff Guo > > > > Hi, > > I also ran into this problem that SWIG files aren't generated > again when > I change a block interface in a header from "include/" directory. I > always have to make clean when I do that in order to successfully > compile. Can it be easily corrected by editing cmake files? > > Piotr Krysik > > > > Are you guys sure about that behavior? Any change to an include file > that's referenced by SWIG (if you're using gr_modtool to add new > blocks, then this is always true), then any change, even just adding a > space, to the public header file will trigger a rerun of swig. You > should /not/ have to run "make clean" ever time you update your header > file. > > In fact, I often find this problematic if, for instance, I > accidentally save a silly change in block.h that launches a rebuild of > everything. > > If you're honestly seeing this happen, we'll definitely try to track > down the reason why. > > Tom > Hi Tom, I created the project with gr_modtool. Now I cannot confirm that there was any error in gr_modtool as build system in projects created with current version of this tool act as you describe. It's probable that I accidentally changed something that resulted with such changed behaviour of build system in relation to SWIG generated files. Best Regards, Piotr ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Mistake in fmdet_cf_impl.cc:109?
Hello all, I was reading the c++ code of FM demodulators in gnuradio and I encountered this in fmdet_cf_impl.cc:109: - Sdot = d_scl * (-S0+d_8*S1-d_8*S1+S4); - I don't know according to what principle this demodulator work exactly but it doesn't seem to make too much sense to first add d_8*S1 and then subtract it. -- Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
