[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=Eofnb7zr8QEfeature=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] Sampling slowly
Looking for help I have written a source block to do satellite predictions. It acts as a source of a float representing the input parameter - e.g. elevation. The block probes predict via UDP, looks at the string returned and selects the asked for parameter. So far fine, but I would like to probe it slowly, not on every sample. This appears to be impossible. If I use a probe and function probe and ask it to update each second, the probe grabs data from the source runs at full sample rate. Unfortunately probe seems to have almost no documentation and I don't understand the source but I assume it goes as fast as it can get input samples. If I try combining say an add block with a decimated version of the sample rate (coming from a USRP) and probe again, it still runs too fast. It is as if it is trying to cache a set values. Logically I can see that might be useful to maintain a constant rate where blocks take different times. Is there a simple fix or do I need to implement some form of trigger port - and if I do will it still cache data? Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sampling slowly
I would suggest looking at the message-strobe block and using messages. - Seth Sent from my iPhone On Nov 30, 2014, at 10:11 AM, Mike Willis willis...@gmail.com wrote: Looking for help I have written a source block to do satellite predictions. It acts as a source of a float representing the input parameter – e.g. elevation. The block probes predict via UDP, looks at the string returned and selects the asked for parameter. So far fine, but I would like to probe it slowly, not on every sample. This appears to be impossible. If I use a probe and function probe and ask it to update each second, the probe grabs data from the source runs at full sample rate. Unfortunately probe seems to have almost no documentation and I don’t understand the source but I assume it goes as fast as it can get input samples. If I try combining say an add block with a decimated version of the sample rate (coming from a USRP) and probe again, it still runs too fast. It is as if it is trying to cache a set values. Logically I can see that might be useful to maintain a constant rate where blocks take different times. Is there a simple fix or do I need to implement some form of trigger port – and if I do will it still cache data? Mike ___ 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
Re: [Discuss-gnuradio] Sampling slowly
I looked at that but I don’t know how to and it’s extremely difficult to understand. It is probably possible to bodge using the system timer to avoid a re-calculation if called within less than a specific time, e.g. 10 seconds. This is what I am thinking at the moment. Basically reduce the workload. Mike From: Seth Hitefield [mailto:sd...@vt.edu] Sent: 30 November 2014 15:35 To: Mike Willis Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Sampling slowly I would suggest looking at the message-strobe block and using messages. - Seth Sent from my iPhone On Nov 30, 2014, at 10:11 AM, Mike Willis willis...@gmail.com mailto:willis...@gmail.com wrote: Looking for help I have written a source block to do satellite predictions. It acts as a source of a float representing the input parameter – e.g. elevation. The block probes predict via UDP, looks at the string returned and selects the asked for parameter. So far fine, but I would like to probe it slowly, not on every sample. This appears to be impossible. If I use a probe and function probe and ask it to update each second, the probe grabs data from the source runs at full sample rate. Unfortunately probe seems to have almost no documentation and I don’t understand the source but I assume it goes as fast as it can get input samples. If I try combining say an add block with a decimated version of the sample rate (coming from a USRP) and probe again, it still runs too fast. It is as if it is trying to cache a set values. Logically I can see that might be useful to maintain a constant rate where blocks take different times. Is there a simple fix or do I need to implement some form of trigger port – and if I do will it still cache data? Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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
Re: [Discuss-gnuradio] Sampling slowly
That may work, but it may cause problems with the scheduler if you are using stream ports. - Seth Sent from my iPhone On Nov 30, 2014, at 10:47 AM, Mike Willis willis...@gmail.com wrote: I looked at that but I don’t know how to and it’s extremely difficult to understand. It is probably possible to bodge using the system timer to avoid a re-calculation if called within less than a specific time, e.g. 10 seconds. This is what I am thinking at the moment. Basically reduce the workload. Mike From: Seth Hitefield [mailto:sd...@vt.edu] Sent: 30 November 2014 15:35 To: Mike Willis Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Sampling slowly I would suggest looking at the message-strobe block and using messages. - Seth Sent from my iPhone On Nov 30, 2014, at 10:11 AM, Mike Willis willis...@gmail.com wrote: Looking for help I have written a source block to do satellite predictions. It acts as a source of a float representing the input parameter – e.g. elevation. The block probes predict via UDP, looks at the string returned and selects the asked for parameter. So far fine, but I would like to probe it slowly, not on every sample. This appears to be impossible. If I use a probe and function probe and ask it to update each second, the probe grabs data from the source runs at full sample rate. Unfortunately probe seems to have almost no documentation and I don’t understand the source but I assume it goes as fast as it can get input samples. If I try combining say an add block with a decimated version of the sample rate (coming from a USRP) and probe again, it still runs too fast. It is as if it is trying to cache a set values. Logically I can see that might be useful to maintain a constant rate where blocks take different times. Is there a simple fix or do I need to implement some form of trigger port – and if I do will it still cache data? Mike ___ 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
Re: [Discuss-gnuradio] Sampling slowly
Yes, it worked but the CPU load is immense as the function probe is probing about as fast as it can and of course there is still overhead in looking up the time. Basically if the time in seconds is the same as last time it just returns the previous sample without repeating any calculations. I will try and sync it to the sample rate to see if that slows it down. Mike From: Seth Hitefield [mailto:sd...@vt.edu] Sent: 30 November 2014 16:25 To: Mike Willis Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Sampling slowly That may work, but it may cause problems with the scheduler if you are using stream ports. - Seth Sent from my iPhone On Nov 30, 2014, at 10:47 AM, Mike Willis willis...@gmail.com mailto:willis...@gmail.com wrote: I looked at that but I don’t know how to and it’s extremely difficult to understand. It is probably possible to bodge using the system timer to avoid a re-calculation if called within less than a specific time, e.g. 10 seconds. This is what I am thinking at the moment. Basically reduce the workload. Mike From: Seth Hitefield [mailto:sd...@vt.edu] Sent: 30 November 2014 15:35 To: Mike Willis Cc: discuss-gnuradio@gnu.org mailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Sampling slowly I would suggest looking at the message-strobe block and using messages. - Seth Sent from my iPhone On Nov 30, 2014, at 10:11 AM, Mike Willis willis...@gmail.com mailto:willis...@gmail.com wrote: Looking for help I have written a source block to do satellite predictions. It acts as a source of a float representing the input parameter – e.g. elevation. The block probes predict via UDP, looks at the string returned and selects the asked for parameter. So far fine, but I would like to probe it slowly, not on every sample. This appears to be impossible. If I use a probe and function probe and ask it to update each second, the probe grabs data from the source runs at full sample rate. Unfortunately probe seems to have almost no documentation and I don’t understand the source but I assume it goes as fast as it can get input samples. If I try combining say an add block with a decimated version of the sample rate (coming from a USRP) and probe again, it still runs too fast. It is as if it is trying to cache a set values. Logically I can see that might be useful to maintain a constant rate where blocks take different times. Is there a simple fix or do I need to implement some form of trigger port – and if I do will it still cache data? Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] uhd driver
I want to check some signal in fpga, so generate the bit stream file, and burn it by JTAG, Moinitor some signal in the chipscope Then, burning is finished, receiver program (gnuradio) in computer is running well, but chipscope signal can be triggered I do not why? Thank you for your help!! hzc191...@gmail.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] Fwd: RE: synchronize two USRP N 210
Hi Bashar, It was a bit hard to read, and I'm trying not to debug too much of your code, but you should definitely set the start time for all your USRPs, not just for one. Best regards, Marcus On 11/29/2014 12:10 AM, Bashar Hussain wrote: Dear Marcus Thanks for you. Actually I started to get better results now, I have one more question . In my scenario I am using two USRPs: - USRP 1 : TX/RX as transmitter , RX2 as RX0- USRP 2 : RX2 as RX1 now for the timing of both RX I followed your suggestion and I got a better results but still not stable, it seems that I do not make the timing for the TX/RX correctly. Please kindly check the piece of code about the TX/RX which is the same USRP as for RX0 : self.uhd_usrp_sink_0 = uhd.usrp_sink( device_addr=addr=192.168.1.221, stream_args=uhd.stream_args( cpu_format=fc32, channels=range(1), ), ) self.uhd_usrp_sink_0.set_samp_rate(128e6/interp_rate) self.uhd_usrp_sink_0.set_clock_source(external, 0) self.uhd_usrp_sink_0.set_time_source(external, 0) self.uhd_usrp_sink_0.set_time_unknown_pps(uhd.time_spec()) self.uhd_usrp_sink_0.set_center_freq(freq, 0) self.uhd_usrp_sink_0.set_gain(30, 0) self.uhd_usrp_sink_0.set_antenna(TX/RX, 0) time.sleep(1); cmd_time2 = self.uhd_usrp_sink_0.get_time_last_pps() real_seconds2 = uhd.time_spec_t.get_real_secs(cmd_time2)future_real_seconds2 = real_seconds2 + 1future_cmd_time2 = uhd.time_spec_t(future_real_seconds2) self.uhd_usrp_sink_0.set_start_time(future_cmd_time2) Regards Bashar Date: Fri, 28 Nov 2014 13:14:34 +0100 From: marcus.muel...@ettus.com To: eng.bashar.1...@hotmail.com; discuss-gnuradio@gnu.org Subject: Re: [USRP-users] Fwd: RE: synchronize two USRP N 210 Hi Bashar, thanks for following up on this :) So, the idea was to replace set_command_time() by set_start_time(), and to generally omit the clearing of command times (as you then don't even set any): -initialize all three USRP_sink/source objects -set the time -set_start_time on all three of them -start your flowgraph. Best regards, Marcus On 11/28/2014 12:44 PM, Bashar Hussain wrote: Dear Marcus Thanks for your reply. So here is the code now looks like: self.uhd_usrp_source_1 = uhd.usrp_source( device_addr=addr=192.168.1.211, stream_args=uhd.stream_args( cpu_format=fc32, channels=range(1), ), ) self.uhd_usrp_source_1.set_clock_source(external, 0) self.uhd_usrp_source_1.set_time_source(external, 0) self.uhd_usrp_source_1.set_time_unknown_pps(uhd.time_spec()) self.uhd_usrp_source_1.set_samp_rate(100e6/dec_rate) self.uhd_usrp_source_1.set_center_freq(freq, 0) self.uhd_usrp_source_1.set_gain(rx_gain, 0) self.uhd_usrp_source_1.set_antenna(RX2, 0) self.uhd_usrp_source_0 = uhd.usrp_source( device_addr=addr=192.168.1.221, stream_args=uhd.stream_args( cpu_format=fc32, channels=range(1), ), ) self.uhd_usrp_source_0.set_clock_source(external, 0) self.uhd_usrp_source_0.set_time_source(external, 0) self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec()) self.uhd_usrp_source_0.set_samp_rate(100e6/dec_rate) self.uhd_usrp_source_0.set_center_freq(freq, 0) self.uhd_usrp_source_0.set_gain(rx_gain, 0) self.uhd_usrp_source_0.set_antenna(RX2, 0) time.sleep(1); cmd_time = self.uhd_usrp_source_1.get_time_last_pps() cmd_time0 = self.uhd_usrp_source_0.get_time_last_pps() real_seconds = uhd.time_spec_t.get_real_secs(cmd_time) real_seconds0 = uhd.time_spec_t.get_real_secs(cmd_time0) future_real_seconds = real_seconds + 1 future_real_seconds0 = real_seconds0 + 1 future_cmd_time = uhd.time_spec_t(future_real_seconds) future_cmd_time0 = uhd.time_spec_t(future_real_seconds0) self.uhd_usrp_source_1.set_command_time(future_cmd_time) self.uhd_usrp_source_0.set_command_time(future_cmd_time0) self.uhd_usrp_source_1.set_start_time(future_cmd_time) self.uhd_usrp_source_0.set_start_time(future_cmd_time0) self.uhd_usrp_source_1.clear_command_time() self.uhd_usrp_source_0.clear_command_time() Or I have to delete the clear_command_time lines ? Regards .. Bashar Mufid Eng.Bashar Mufid Research Teaching Assistant Al-Quds University Faculty Of Engineering / Department of Electronics Engineering Al-Quds - West Bank - Palestine Tel:00972-56-8585085 Date: Fri, 28 Nov 2014 12:42:27 +0100 From: marcus.muel...@ettus.com To:
Re: [Discuss-gnuradio] uhd driver
Hi hzc, that's not nearly enough information for anyone to guess what's going on. What USRP device (there's around a dozen publicly available USRP types)? Which signal? Why are you doing things in the FPGA? What are you doing? What is your problem with the chipscope signal? Generally: [1]! Also: Far too often people start working on the FPGA before specifying wisely why and what they can't do on the host and have to do in the FPGA. Before asking any questions relating private FPGA modifications, please consider if the GNU Radio mailing list is the right one. There's also the USRP-users list[2], but to be completely fair: It's almost impossible to diagnose things that go wrong in a modified FPGA image without standing right next to the person. Best regards, Marcus [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors [2] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com On 11/30/2014 06:48 PM, hzc191...@gmail.com wrote: I want to check some signal in fpga, so generate the bit stream file, and burn it by JTAG, Moinitor some signal in the chipscope Then, burning is finished, receiver program (gnuradio) in computer is running well, but chipscope signal can be triggered I do not why? Thank you for your help!! hzc191...@gmail.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
Re: [Discuss-gnuradio] segfault
Hi Michele, if you built GNU Radio/gqrx with gcc, then the GNU Debugger might be of immensive help. First make sure you've built GNU Radio with debugging symbols (cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo [...]), then start gqrx in the debugger: ? gdb $(which gqrx) [lots of text from gdb] (gdb) run [enter] should start gqrx and run until it segfaults. then use the backtrace command in gdb: (gdb) bt [enter] which should show you in which function call hierarchy the fault occurred. Greetings, Marcus PS: don't worry about your English, it's quite fine :) On 11/29/2014 07:30 PM, michele wrote: Hi to all. This is my first post here...i hope to have choosen the right place to ask I'm currently trying to compile gqrx and gnuradio...everything went well, but when i run gqrx it won't start and give me this error: gqrx[5865]: segfault at 12d0 ip 7f570ee76d2f sp 7fff60fd9000 error 4 in libgnuradio-pmt-3.7.6git.so.0.0.0[7f570ee44000+5] I've asked on the gqrx group and the author (hi csete!!!) told me that most probably it's a bug/problem on gnuradio. I've no idea what's wrong... PS: it was running ok before i updated with git pull gnuradio (didn't do that since 2 months...). PSS: Sorry for my english ___ 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] Best Resample Method For Resampling LTE Data
Hi, I'm currently using the Rational Resampler in GUNURADIO to resample LTE data, for example from 30.72MHz to 15.36MHz and 50MHz to 15.36MHz. I`m able to decode the data, so every thing seems to be well. I chose the Rational Resampler, simply because it is easy to use. However I noticed, GNURADIO has a number of resample modules, Fractional Resampler, Polyphase Arbitrary Resampler etc... I'm guessing each resampler has it`s strengths and weaknesses. Perhaps one is better for audio, another is better for LTE data etc.. At this stage, I have found the equations for the various resamplers, but have no practical experience, with regards to the merits or demerits of the different modules. Any pointers to any online resources or offline books would be appreciated. -- View this message in context: http://gnuradio.4.n7.nabble.com/Best-Resample-Method-For-Resampling-LTE-Data-tp51496.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
Re: [Discuss-gnuradio] Best Resample Method For Resampling LTE Data
The PFB Arb Resampler is the newest. I've been using it to do all my resampling for every application because it's dead simple - handles all the nyquist filtering for you and allows fractional resampling. On Sunday, November 30, 2014, Paul Creaser drpaulcrea...@gmail.com wrote: Hi, I'm currently using the Rational Resampler in GUNURADIO to resample LTE data, for example from 30.72MHz to 15.36MHz and 50MHz to 15.36MHz. I`m able to decode the data, so every thing seems to be well. I chose the Rational Resampler, simply because it is easy to use. However I noticed, GNURADIO has a number of resample modules, Fractional Resampler, Polyphase Arbitrary Resampler etc... I'm guessing each resampler has it`s strengths and weaknesses. Perhaps one is better for audio, another is better for LTE data etc.. At this stage, I have found the equations for the various resamplers, but have no practical experience, with regards to the merits or demerits of the different modules. Any pointers to any online resources or offline books would be appreciated. -- View this message in context: http://gnuradio.4.n7.nabble.com/Best-Resample-Method-For-Resampling-LTE-Data-tp51496.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org javascript:; https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Very Respectfully, Dan CaJacob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
