Re: [Discuss-gnuradio] Converting from #ifndef/#define include guards to #pragma once globally

On 02/27/2014 11:42 PM, Marcus Müller wrote: > As I see things now, I'd just not convert the files to #pragma once. > However, I do see usefulness in the possibility to analyze headers to > find 'convertible' include guards, because it is a feasible method of > ensuring that files don't have errone

Re: [Discuss-gnuradio] block is requesting more input data than it can provide

On 02/28/2014 01:17 AM, Rob Miller wrote: > Rather than posting a rather complicated flowgraph, I was able to > re-create the error that I'm seeing with a much simpler flowgraph. A > screen cap from from grc file, and the grc file itself are attached. In > the example, there are still two data pa

Re: [Discuss-gnuradio] message port names

On 02/28/2014 01:39 AM, Nowlan, Sean wrote: >> Hey Sean, > >> I /think/ so. I'd have to double check, but at some point it's >> likely to go through a symbol_to_string conversion. > >> Can you think of a need for a port name to be something other than >> a symbol/string? Maybe an enumeration or s

Re: [Discuss-gnuradio] Converting from #ifndef/#define include guards to #pragma once globally

Hi Martin, "optimizable guards": #ifndef at start, matching #endif at semantic end-of-file; sorry to be unclear on that. These are the include guards gcc cpp recognizes as such, which suppresses repeated opening & parsing of that header. Agreeing, though, that this is least priority. Also, alm

Re: [Discuss-gnuradio] Converting from #ifndef/#define include guards to #pragma once globally

On 02/28/2014 10:02 AM, Marcus Müller wrote: > Hi Martin, > > "optimizable guards": #ifndef at start, matching #endif at semantic > end-of-file; sorry to be unclear on that. > These are the include guards gcc cpp recognizes as such, which > suppresses repeated opening & parsing of that header. Agr

Re: [Discuss-gnuradio] Converting from #ifndef/#define include guards to #pragma once globally

Hi Martin, do not worry: No discouragement took place, and I've just added a few lines of doc to https://github.com/marcusmueller/include-guard-convert, and I'm totally happy about how much constructive feedback I've got from everyone! I really just agree with you that we shouldn't put to much e

[Discuss-gnuradio] Frequency response from fading simulator block not working as expected

Hello, In order to simulate a multi-path scenario, I´m trying to validate the "Frequency Selective Fading Model" block, but the results I found are not the ones I would expect. The set up consisted of 2 taps delayed 20 microseconds each other, so that the frequency response should have very deep f

[Discuss-gnuradio] The GMSK demodulation

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,

Re: [Discuss-gnuradio] The GMSK demodulation

> > > 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? > >

Re: [Discuss-gnuradio] message port names

Hi Sean, Tom and Martin, basic_block enforces using a symbol in its message_port_register_in method, so that's where you'd have to start changing things. But to add my 0b0010* ct to this: - using strings as port names keeps consistency - using strings is the "proper" way to ensure all tools (es

Re: [Discuss-gnuradio] The GMSK demodulation

What confused me is the Viterbi algorithm. I saw it can be used to demodulate GMSK in more than one place (such as here: http://www.mathworks.cn/cn/help/comm/ref/comm.gmskdemodulatorclass.html ) I think it's better for me to read some materials of Viterbi and find out what really it is. Cheers Zh

Re: [Discuss-gnuradio] The GMSK demodulation

Hi Zhenhua, as Aditya pointed out: Viterby is /not/ a demodulator. You should read something on digital communication that explains the difference between channel coding and modulation, then everything will be clearer to you. Greetings, Marcus On 02/28/2014 04:04 PM, zhenhua han wrote: What co

Re: [Discuss-gnuradio] The GMSK demodulation

On Fri, Feb 28, 2014 at 10:12 AM, Marcus Müller wrote: > Hi Zhenhua, > as Aditya pointed out: Viterby is /not/ a demodulator. > You should read something on digital communication that explains the > difference between channel coding and modulation, then everything will be > clearer to you. > > Gre

Re: [Discuss-gnuradio] The GMSK demodulation

Also as a side note, you can't demod GSM and then slice it. You have to demod it burst by burst so that you can lock to the training sequence of each. So the demod block of GR is pretty much useless here. airprobe has a viterbi demod (which is probably one of the few good part of airprobe to re-us

[Discuss-gnuradio] Modifying gr-air-modes to work with Nutaq's Zepto/Pico

Hello, I'm currently working on a project where I need to install gr-air-modes on a Zepto then a Pico from Nutaq. The problem is that gr-air-modes is working with UHD/Osmocom. I wondered if somebody had any ideas about how to modify gr-air-modes ? Thank you

Re: [Discuss-gnuradio] GSoC2014 Turbo Equalizer

Dear Jan Krämer, I am very interested in your proposal. However, to my best of knowledge, turbo equalizer (TB) is pretty complicated and computationally heavy, then it is challenging to have an effective real-time implementation of TB. I would like to have some questions as follows: 1. Your ISI

Re: [Discuss-gnuradio] The GMSK demodulation

I'm working on a generalized CPM demod based on Achilleas's previous work in gr-trellis/src/examples/test_cpm.py, and I have it more or less working although there are plenty of little bugs to work out. Since the Viterbi part was more or less worked out for me, synchronization is the hard part; my

Re: [Discuss-gnuradio] The GMSK demodulation

It's already a separate block, so yes. On Fri, Feb 28, 2014 at 9:15 AM, Dan CaJacob wrote: > Nick, > > Are you going to release the non-coherent timing recovery improvement as a > separate block too (not baked into a GMSK hier block)? Thanks! > > Very Respectfully, > > Dan CaJacob > > > On Fri

[Discuss-gnuradio] Piped Video Streaming Crash

Hi Marcus Hopefully your seeing this, for some reason that other threadis no long in my mail inbox or trash.. My problem was: VLC - Named Pipe 1 - File Source GRC - OFDM MOD - USRP Sink- USRP -Source - OFDM DEMOD - File Si

Re: [Discuss-gnuradio] The GMSK demodulation

Nick, Are you going to release the non-coherent timing recovery improvement as a separate block too (not baked into a GMSK hier block)? Thanks! Very Respectfully, Dan CaJacob On Fri, Feb 28, 2014 at 11:51 AM, Nick Foster wrote: > I'm working on a generalized CPM demod based on Achilleas's p

[Discuss-gnuradio] Reminder: Call for Proposals for GRCon14

Greetings GNU Radio and USRP Communities, It has been a couple of weeks since the first announcement of GNU Radio Conference 2014 (GRCon14 [0]) [1], so I'm sending this email as a reminder for everyone interested in presenting at GRCon14 to submit your abstract [2]. We already have one submiss

Re: [Discuss-gnuradio] The GMSK demodulation

On Fri, Feb 28, 2014 at 11:51 AM, Nick Foster wrote: > I'm working on a generalized CPM demod based on Achilleas's previous work in > gr-trellis/src/examples/test_cpm.py, and I have it more or less working > although there are plenty of little bugs to work out. Since the Viterbi part > was more or

Re: [Discuss-gnuradio] The GMSK demodulation

On Fri, Feb 28, 2014 at 10:21 AM, Tom Tsou wrote: > On Fri, Feb 28, 2014 at 11:51 AM, Nick Foster > wrote: > > I'm working on a generalized CPM demod based on Achilleas's previous > work in > > gr-trellis/src/examples/test_cpm.py, and I have it more or less working > > although there are plenty

Re: [Discuss-gnuradio] The GMSK demodulation

On Fri, Feb 28, 2014 at 1:54 PM, Nick Foster wrote: > On Fri, Feb 28, 2014 at 10:21 AM, Tom Tsou wrote: >> I don't have much to add, but Nick and Sylvain touched on the largest >> difference between the Gnuradio GMSK demod and GSM/TDMA type burst >> processing - and it's not the Viterbi. The use

Re: [Discuss-gnuradio] message port names

>Hi Sean, Tom and Martin, >basic_block enforces using a symbol in its message_port_register_in method, so >that's where you'd have to start changing things. >But to add my 0b0010* ct to this: >- using strings as port names keeps consistency >- using strings is the "proper" way to ensure all too

Re: [Discuss-gnuradio] RuntimeError: audio_oss_sink

>>missing dependency for audio support for Ubuntu Hi Tom op25 is more or less out of business without GR audio support - is there a way to add something in the gr-op25 pybombs recipe to specify that audio should be included as a 'depends' prerequisite? Thx to Scott for finding this and report

[Discuss-gnuradio] calculate frequency offset from phase offset

Hi guys, I'm reading the code of Airprobe and I found this function. double gsm_receiver_cf::compute_freq_offset(const gr_complex * input, unsigned first_sample, unsigned last_sample) { double phase_sum = 0; unsigned ii; for (ii = first_sample; ii < last_sample; ii++) { double phase_di