[Discuss-gnuradio] calculate frequency offset from phase offset

[zhenhua han]

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_diff = compute_phase_diff(input[ii], input[ii-1]) - (M_PI /
2) / d_OSR;
phase_sum += phase_diff;
  }

  double phase_offset = phase_sum / (last_sample - first_sample);
  double freq_offset = phase_offset * 1625000.0 / (12.0 * M_PI);
  return freq_offset;
}




It calculates the frequency offset with "freq_offset = phase_offset *
1625000.0 / (12.0 * M_PI);" I guess the (1625000.0/12*pi) equals
(1625000/6)/(2pi) and 1625/6 kbit/s is the modulation rate of GSM.

So, what is the principle of this calculation? How to calculate the
freq_offset with phase_offset. I tried some derivation but failed. Can
anyone help me to find out the derivation ?

Best wishes,
Zhenhua
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RuntimeError: audio_oss_sink

[ikjtel]

>>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 
reporting it - many users would not be in a position to diagnose and repair 
this, so it would be better if we could automate it.  To me it's not so much an 
issue specific to OSS, but rather a generic question of how to ensure that 
audio capability isn't omitted (whatever audio flavor the OS/distro happens to 
use for standard audio support).

The goal would I think be to get pybombs to build stuff in the correct order so 
that by the time it gets finished with gnuradio, audio is already done - that 
way it would not be necessary for the user to rebuild anything (which might be 
beyond the capability of many users).  Ideally we want to get to a place where 
the end user just clones pybombs and runs 'pybombs install gr-op25' and all the 
necessary stuff happens behind the scenes - including audio support...

Thx & Best Regards

Max
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] message port names

[Nowlan, Sean]

>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 (esp. the companion) 
>display port names alike and are able to save/generate a flowgraph into/from a 
>text file format
>- stepping away from pmt_symbol as port name type opens up the gate for people 
>doing stuff like assigning numeric values of different types (that could lead 
>to a nice monte carlo QA for pmt::eqv; corner cases like 
>pmt::eqv(pmt_uint64(x),pmt_int(x))==false will lead to problems)
>   - I guess the whole point of pmt_symbol is it being unique and provide 
> guaranteed identification**
>- comparatively very little overhead with the outK method, your workaround 
>seems feasible (also: you could consider keeping your own port name 
>std::vector and use that for later reference; if you just need a 
>(strangely sorted) list of your ports, it's basic_block::msg_queue)
>- hashing overhead negligible for short strings and it speeds up the std::map 
>operations when adding/using message ports (hashing will probably even pay 
>during runtime)
>+Ok, I admit it's strange to use PMTs if you'd actually wanted to use strings 
>(and have the type safety)

>Greetings,
>Marcus

I don't see a need to change how it's currently being done, i.e., using 
string_to_symbol. I had just asked the question because I was curious, and I 
think the outK "workaround" is useful because it corresponds with how GRC 
automates naming with .


>* valid for gcc 4.3+, clang and C++14 ;)
>** Tom: why is there a d_next member in pmt_symbol?
>On 02/28/2014 09:19 AM, Martin Braun wrote:
>> 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 something?
 Tom
>>> In a certain block I'm registering N ports, where N is a constructor
>>> argument to the block. I was hoping I could call them
>>> pmt::from_long(0) through pmt::from_long(N-1), but that didn't work.
>>> I ended up creating string names "out0" through "outK" (where K =
>>> N-1) and then used pmt::string_to_symbol.
>> I doubt anyone implemented that to limit names, it was more likely that
>> we didn't think of this use case. If you see this is a small,
>> non-invasive change that would allow other PMTs to be port names, that
>> would be interesting to see.
>>
>> M
>>

___
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] The GMSK demodulation

[Tom Tsou]

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 of synchronization
>> loops (or lack thereof) in the demod is really the separating factor.
>
> Sample tagging in GR makes it easier to have it both ways in this case. If
> you have a correlator block that outputs timing phase estimates based on the
> preamble (or whatever), this should be used to initialize a closed-loop
> timing recovery block's phase. For bursty transmissions this lets you keep
> the loop gain pretty low and still acquire quickly. This is what Tom (R) is
> doing with the correlate_and_sync and polyphase_clock_sync blocks, and it's
> what I'm doing in my MSK timing recovery block, although I'm still dealing
> with a bug in that estimate. If you want to rely strictly on the timing
> phase estimate of the preamble as in GMSK's case you could just turn the
> loop gain of your favorite timing sync block to zero and let it act as a
> naive (and inefficient) decimator.

I wasn't implying that a combined method couldn't be done. But for
GSM, the assumption is that frequency sync is acquired separately
(with embedded tones), timing is derived from frequency, and Doppler
effects restricted (i.e. high speed train is not a supported use
case). Add in short durations before/after mid-amble and the benefits
of closed-loop timing begin to diminish.

Of course, these assumptions from GSM specification don't extend to
the generalized case and collapse when we handle continuous signals.
That was really the only point I was trying to make.

  -TT

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] The GMSK demodulation

[Nick Foster]

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 of little bugs to work out. Since the Viterbi
> part
> > was more or less worked out for me, synchronization is the hard part; my
> > application isn't GSM, and I'd like the solution in Gnuradio to be
> > applicable to a wide range of systems -- this means closed-loop timing
> and
> > freq synchronization instead of just doing data-aided estimates from the
> > preamble.
>
> 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 of synchronization
> loops (or lack thereof) in the demod is really the separating factor.
>

Sample tagging in GR makes it easier to have it both ways in this case. If
you have a correlator block that outputs timing phase estimates based on
the preamble (or whatever), this should be used to initialize a closed-loop
timing recovery block's phase. For bursty transmissions this lets you keep
the loop gain pretty low and still acquire quickly. This is what Tom (R) is
doing with the correlate_and_sync and polyphase_clock_sync blocks, and it's
what I'm doing in my MSK timing recovery block, although I'm still dealing
with a bug in that estimate. If you want to rely strictly on the timing
phase estimate of the preamble as in GMSK's case you could just turn the
loop gain of your favorite timing sync block to zero and let it act as a
naive (and inefficient) decimator.

--n


>
>   -TT
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] The GMSK demodulation

[Tom Tsou]

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 less worked out for me, synchronization is the hard part; my
> application isn't GSM, and I'd like the solution in Gnuradio to be
> applicable to a wide range of systems -- this means closed-loop timing and
> freq synchronization instead of just doing data-aided estimates from the
> preamble.

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 of synchronization
loops (or lack thereof) in the demod is really the separating factor.

  -TT

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Michael Dickens]

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 submission; please keep them coming!  The submission period 
will close on 04 April 2014, and we will announce the selected presentations on 
14 April 2014.  Tom Rondeau and I will be leading the selection process.

Best Regards,

Michael Dickens
GNU Radio Conference 2014 Co-Organizer (one of a few)

[0] GRCon14 : Main Website
http://gnuradio.squarespace.com/gnu-radio-conference-2014/

[1] GRCon14 : First Announcement (12 Feb 2014)
http://lists.gnu.org/archive/html/discuss-gnuradio/2014-02/msg00230.html
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-February/008588.html

[2] GRCon14 : Call For Presentations
http://gnuradio.squarespace.com/grc2014-call-for-presentations/


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] The GMSK demodulation

[Dan CaJacob]

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 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 application isn't GSM, and I'd like the solution in Gnuradio to be
> applicable to a wide range of systems -- this means closed-loop timing and
> freq synchronization instead of just doing data-aided estimates from the
> preamble. I've implemented a timing synchronizer based on the D'andrea,
> Mengali, Reggiannini paper following MATLAB's example, and I'm using an
> adaptation of the correlate_and_sync block to synchronize to (G)MSK
> preambles.
>
> Don't know when I'll have it ready to release (i.e. when the code isn't an
> embarrassment to look at) but it's Working In The Lab (TM). It also takes
> quite a bit of setup to apply to each use case.
>
> If you don't need those extra few dB, it's a whole heck of a lot simpler
> both in implementation complexity and CPU cycles to just stick with the
> existing noncoherent GMSK block. When I release code I'll also release an
> updated noncoherent GMSK receiver block which uses the new timing
> estimator, as the primary weakness of the existing GMSK block is timing
> recovery.
>
> --n
>
>
> On Fri, Feb 28, 2014 at 7:31 AM, Sylvain Munaut <246...@gmail.com> wrote:
>
>> 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-use).
>>
>> Cheers,
>>
>> Sylvain
>>
>>
>> On Fri, Feb 28, 2014 at 4:27 PM, Tom Rondeau  wrote:
>> > 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.
>> >>
>> >> Greetings,
>> >> Marcus
>> >>
>> >> On 02/28/2014 04:04 PM, zhenhua han wrote:
>> >>
>> >> 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
>> >> Zhenhua
>> >>
>> >> 2014-2-28 下午10:40于 "Aditya Dhananjay"  写道：
>> 
>> 
>>  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)?
>> 
>> >>>
>> >>> I think you are mixing up the modulation and coding components.
>> >>>
>> >>> At the transmitter, you first code (convolutional code), and then you
>> >>> modulate (GMSK).
>> >>>
>> >>> At the receiver, you first demodulate (quadrature demodulate) and
>> then you
>> >>> decode (Viterbi).
>> >>>
>> >>> Coding takes a stream of bits and converts it to another stream of
>> bits.
>> >>> Modulation refers to the process of converting the post-coded bits
>> into
>> >>> "symbols" that you will then send over-the-air.
>> >>>
>> >>> best,
>> >>> aditya
>> >
>> >
>> > Actually, guys
>> >
>> > http://www.ittc.ku.edu/~prescott/kcp/HPRC-GMSK-Demod.pdf
>> >
>> > You can demodulate GMSK using the Viterbi algorithm.
>> >
>> > Zhenhua,
>> >
>> > We don't implement this method in our GMSK demodulator, though I have
>> > wanted to see someone do it. The Viterbi is the maximum likelihood
>> > detector for GMSK, but it's more complicated to implement. The
>> > quadrature method we use is simple and intuitive but suboptimal.
>> >
>> > Tom
>> >
>> > ___
>> > 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] Piped Video Streaming Crash

[Alexander Buckley]

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 Sink GRC - Named Pipe 2 - Mplayer
> (FAILS!!). Reports: Segfault (core dumped).  GRC file is running, VLC is
streaming. Fail occurs as soon as I open Named Pipe 2 with Mplayer

using:
cvlc v4l2:///dev/video0 :v4l2-width=160 :v4l2-height=120
:v4l2-aspect-ratio=4/3 --noaudio
--sout="#transcode{vcodec=h264,vb=1024}:file{dst=./txPIPE.ts}" :sout-keep
 and reading with mplayer, where the error only occurs when I introduce the
USRP N210 to the circuit.

You had asked what was crashing, the play or the grc produced python set up.

It is the python/GNU radio that is crashing.

I have also had it report the following:
*** glibc detected *** python: realloc(): invalid pointer: 0x0a9c9450 ***
or
*** glibc detected *** python: malloc(): smallbin double linked list
corrupted: 0x0a9efcb8 ***

I have trouble seeing how this should be failing like this as I have used
the same set up to send a text file, with the only difference being that
the file read is set to repeat.

I have been thinking there could be trouble with data rates, though I had
expected that would all be taken care of by back pressure if nothing is
really specified.

I really am following the set up Alexandru Csete's. The only differences
being is that he is using a mac book, older usrp1 and gstreamer.
But i don't any of that should be the difference, the commands are quite
straight forward.

I had to try quite a few combinations of streamers/players to get it
to work initially without GRC stuff in the loop. The errors presented along
the way getting to that point were very different. But now that I have that
part sorted, the players don't complain or crash with what I am trying to
do.

It is the GRC-python file when the USRP is added. I am using my USRP for
all sorts of other things just fine though.
So again I keep coming back to data rates, buffers etc.

I do have this always displayed when i run my USRP, I have just always been
ignoring it:

UHD Warning:
The send buffer could not be resized sufficiently.
Target sock buff size: 1048576 bytes.
Actual sock buff size: 131071 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=1048576


Running sudo sysctl -w net.core.wmem_max=1048576 doesn't stop this warning.

But if I do have USRP buffer size problem, that does relate to segfaults,
malloc etc...
This is rather beyond my USRP knowledge level though


cheers
Alexander Buckley
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] The GMSK demodulation

[Nick Foster]

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, 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 less worked out for me, synchronization is the hard part;
>> my application isn't GSM, and I'd like the solution in Gnuradio to be
>> applicable to a wide range of systems -- this means closed-loop timing and
>> freq synchronization instead of just doing data-aided estimates from the
>> preamble. I've implemented a timing synchronizer based on the D'andrea,
>> Mengali, Reggiannini paper following MATLAB's example, and I'm using an
>> adaptation of the correlate_and_sync block to synchronize to (G)MSK
>> preambles.
>>
>> Don't know when I'll have it ready to release (i.e. when the code isn't
>> an embarrassment to look at) but it's Working In The Lab (TM). It also
>> takes quite a bit of setup to apply to each use case.
>>
>> If you don't need those extra few dB, it's a whole heck of a lot simpler
>> both in implementation complexity and CPU cycles to just stick with the
>> existing noncoherent GMSK block. When I release code I'll also release an
>> updated noncoherent GMSK receiver block which uses the new timing
>> estimator, as the primary weakness of the existing GMSK block is timing
>> recovery.
>>
>> --n
>>
>>
>> On Fri, Feb 28, 2014 at 7:31 AM, Sylvain Munaut <246...@gmail.com> wrote:
>>
>>> 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-use).
>>>
>>> Cheers,
>>>
>>> Sylvain
>>>
>>>
>>> On Fri, Feb 28, 2014 at 4:27 PM, Tom Rondeau  wrote:
>>> > 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.
>>> >>
>>> >> Greetings,
>>> >> Marcus
>>> >>
>>> >> On 02/28/2014 04:04 PM, zhenhua han wrote:
>>> >>
>>> >> 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
>>> >> Zhenhua
>>> >>
>>> >> 2014-2-28 下午10:40于 "Aditya Dhananjay"  写道：
>>> 
>>> 
>>>  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)?
>>> 
>>> >>>
>>> >>> I think you are mixing up the modulation and coding components.
>>> >>>
>>> >>> At the transmitter, you first code (convolutional code), and then you
>>> >>> modulate (GMSK).
>>> >>>
>>> >>> At the receiver, you first demodulate (quadrature demodulate) and
>>> then you
>>> >>> decode (Viterbi).
>>> >>>
>>> >>> Coding takes a stream of bits and converts it to another stream of
>>> bits.
>>> >>> Modulation refers to the process of converting the post-coded bits
>>> into
>>> >>> "symbols" that you will then send over-the-air.
>>> >>>
>>> >>> best,
>>> >>> aditya
>>> >
>>> >
>>> > Actually, guys
>>> >
>>> > http://www.ittc.ku.edu/~prescott/kcp/HPRC-GMSK-Demod.pdf
>>> >
>>> > You can demodulate GMSK using the Viterbi algorithm.
>>> >
>>> > Zhenhua,
>>> >
>>> > We don't implement this method in our GMSK demodulator, though I have
>>> > wanted to see someone do it. The Viterbi is the maximum likelihood
>>> > detector for GMSK, but it's more complicated to implement. The
>>> > quadrature method we use is simple and intuitive but suboptimal.
>>> >
>>> > Tom
>>> >
>>> > ___
>>> > Discuss-gnuradio mailing list
>>> > Discuss-gnuradio@gnu.org
>>> > https://lists.gnu.org/mailman/

Re: [Discuss-gnuradio] The GMSK demodulation

[Nick Foster]

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 application isn't GSM, and I'd like the solution in Gnuradio to be
applicable to a wide range of systems -- this means closed-loop timing and
freq synchronization instead of just doing data-aided estimates from the
preamble. I've implemented a timing synchronizer based on the D'andrea,
Mengali, Reggiannini paper following MATLAB's example, and I'm using an
adaptation of the correlate_and_sync block to synchronize to (G)MSK
preambles.

Don't know when I'll have it ready to release (i.e. when the code isn't an
embarrassment to look at) but it's Working In The Lab (TM). It also takes
quite a bit of setup to apply to each use case.

If you don't need those extra few dB, it's a whole heck of a lot simpler
both in implementation complexity and CPU cycles to just stick with the
existing noncoherent GMSK block. When I release code I'll also release an
updated noncoherent GMSK receiver block which uses the new timing
estimator, as the primary weakness of the existing GMSK block is timing
recovery.

--n


On Fri, Feb 28, 2014 at 7:31 AM, Sylvain Munaut <246...@gmail.com> wrote:

> 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-use).
>
> Cheers,
>
> Sylvain
>
>
> On Fri, Feb 28, 2014 at 4:27 PM, Tom Rondeau  wrote:
> > 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.
> >>
> >> Greetings,
> >> Marcus
> >>
> >> On 02/28/2014 04:04 PM, zhenhua han wrote:
> >>
> >> 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
> >> Zhenhua
> >>
> >> 2014-2-28 下午10:40于 "Aditya Dhananjay"  写道：
> 
> 
>  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)?
> 
> >>>
> >>> I think you are mixing up the modulation and coding components.
> >>>
> >>> At the transmitter, you first code (convolutional code), and then you
> >>> modulate (GMSK).
> >>>
> >>> At the receiver, you first demodulate (quadrature demodulate) and then
> you
> >>> decode (Viterbi).
> >>>
> >>> Coding takes a stream of bits and converts it to another stream of
> bits.
> >>> Modulation refers to the process of converting the post-coded bits into
> >>> "symbols" that you will then send over-the-air.
> >>>
> >>> best,
> >>> aditya
> >
> >
> > Actually, guys
> >
> > http://www.ittc.ku.edu/~prescott/kcp/HPRC-GMSK-Demod.pdf
> >
> > You can demodulate GMSK using the Viterbi algorithm.
> >
> > Zhenhua,
> >
> > We don't implement this method in our GMSK demodulator, though I have
> > wanted to see someone do it. The Viterbi is the maximum likelihood
> > detector for GMSK, but it's more complicated to implement. The
> > quadrature method we use is simple and intuitive but suboptimal.
> >
> > Tom
> >
> > ___
> > 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

Re: [Discuss-gnuradio] GSoC2014 Turbo Equalizer

[Anh Duc Nguyen]

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 channels' characteristics: fixed/ known beforehand or
time-variant, how dispersive they are
2. which techniques do you wish to use for equalizer part: MMSE, MAP, or
MLSE?
3. coding: as you presented above - it may be a convolutional or turbo
code, and others?
4. Some special hardware platform may require
5. why do you select 2. and 3. to have the best performance in terms of
complexity or quality, and that combination is realistic to be real-time
implemented in GnuRadio plus 4.

To be honest, I have desperately struggled these question for quite a long
time, then you and some others can help work together to find the answers,

Best regards,
Nguyen Anh Duc


On Tue, Feb 25, 2014 at 8:59 PM, Jan Krämer wrote:

>  Hi everyone,
>
> I am a student at Communications Engineering Lab (CEL) at Karlsruhe
> Institute of Technology. I major in "communication systems" and I am
> currently doing my masterthesis on "Parallel log-map decoders for manycore
> architectures". I am interested in participating in GSoC 2014.
>
> There is an older GNURadio GSoC proposal from 2013 to implement a turbo
> equalizer module in GNURadio in which i am particularly interested working
> on, as it is closely connected to my current field of study.
> So i would like to share my thoughts on a possible Update of the old turbo
> equalizer proposal (and maybe upgrading it to a current proposal ?).
>
> -
> *Turbo Equalizer*
>
> A Turbo Equalizer is a receiver component that is highly effective when
> receiving messages corrupted by Intersymbol Interference (ISI). To archive
> this, the turbo equalizer uses an Equalizer to eliminate the ISI and a
> Log-Map Decoder for Forward Error Correction. Both components pass soft
> information to each other to increase the performance.
>
> *Objectives*
>
> Possible (sub-)projects:
> 1. Implement the Log-Map decoder
> - preferably it can be fully configurable (constraint length, number
> of states, trellis structure)
> - preferably optimized for real time applications
> 2. Implement the linear equalizer
> - preferably optimized for real time applications
>
> *Skills*
> Knowledge of digital signal processing, C/C++, Python
>
> *Potential mentor(s)*
> Sebastian Koslowski, Michael Schwall
>
>
> --
>
> That would be a project I think would be really interesting to work on and
> i think it fits well with some of the other proposals for new GNU Radio
> Modules. As the turbo eq itself is a highly complex architecture, it could
> also be beneficial to split the tasks in this project. It would be great to
> get some feedback from you, if this was a proposal that would benefit
> GNURadio and if it has the potential to be included in the GSoC list of
> ideas.
>
> Thanks and regards,
> Jan Krämer
>
>
> ___
> 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] Modifying gr-air-modes to work with Nutaq's Zepto/Pico

[Adrien Dubedat]

  
  
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 !

Kind regards,


  
  
  
  

  

  


  
  
Adrien Dubedat |  Stagiaire
  
Laboratoire LASSENA
École de Technologie Supérieure  |  1100, rue
Notre-Dame Ouest  |  Montréal (Qc) Canada  |  H3C
1K3
Tel.: 514 430-9342, poste 7750 |  Bureau : A-2451 |  www.etsmtl.ca
Email : adrien.dubeda...@ens.etsmtl.ca
LASSENA : lassena.etsmtl.ca 
  
---
  L’ÉTS est une constituante du réseau de
  l’Université du Québec

Intéressé à joindre le laboratoire de
recherche, remplir ce formulaire svp : http://profs.etsmtl.ca/rlandry/landry/avis.asp?lang=fr
Interested to join the research laboratory, please
fill this form: http://profs.etsmtl.ca/rlandry/landry/avis.asp?lang=en
  

  

--
  Avis: L'information contenue dans ce courriel est strictement
  confidentielle. Toute utilisation par une personne autre que
  le destinataire est illégale.
  Si vous recevez ce courriel par erreur, veuillez svp le
  détruire et nous en aviser.
---
  Notice: The information contained in this message is strictly
  confidential. Any use thereof by any person other than the
  named recipient(s) is illegal.
  If you are not the intended recipient please advise sender and
  delete this message.
---
  

  

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] The GMSK demodulation

[Sylvain Munaut]

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-use).

Cheers,

Sylvain


On Fri, Feb 28, 2014 at 4:27 PM, Tom Rondeau  wrote:
> 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.
>>
>> Greetings,
>> Marcus
>>
>> On 02/28/2014 04:04 PM, zhenhua han wrote:
>>
>> 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
>> Zhenhua
>>
>> 2014-2-28 下午10:40于 "Aditya Dhananjay"  写道：


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

>>>
>>> I think you are mixing up the modulation and coding components.
>>>
>>> At the transmitter, you first code (convolutional code), and then you
>>> modulate (GMSK).
>>>
>>> At the receiver, you first demodulate (quadrature demodulate) and then you
>>> decode (Viterbi).
>>>
>>> Coding takes a stream of bits and converts it to another stream of bits.
>>> Modulation refers to the process of converting the post-coded bits into
>>> "symbols" that you will then send over-the-air.
>>>
>>> best,
>>> aditya
>
>
> Actually, guys
>
> http://www.ittc.ku.edu/~prescott/kcp/HPRC-GMSK-Demod.pdf
>
> You can demodulate GMSK using the Viterbi algorithm.
>
> Zhenhua,
>
> We don't implement this method in our GMSK demodulator, though I have
> wanted to see someone do it. The Viterbi is the maximum likelihood
> detector for GMSK, but it's more complicated to implement. The
> quadrature method we use is simple and intuitive but suboptimal.
>
> Tom
>
> ___
> 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] The GMSK demodulation

[Tom Rondeau]

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.
>
> Greetings,
> Marcus
>
> On 02/28/2014 04:04 PM, zhenhua han wrote:
>
> 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
> Zhenhua
>
> 2014-2-28 下午10:40于 "Aditya Dhananjay"  写道：
>>>
>>>
>>> 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)?
>>>
>>
>> I think you are mixing up the modulation and coding components.
>>
>> At the transmitter, you first code (convolutional code), and then you
>> modulate (GMSK).
>>
>> At the receiver, you first demodulate (quadrature demodulate) and then you
>> decode (Viterbi).
>>
>> Coding takes a stream of bits and converts it to another stream of bits.
>> Modulation refers to the process of converting the post-coded bits into
>> "symbols" that you will then send over-the-air.
>>
>> best,
>> aditya


Actually, guys

http://www.ittc.ku.edu/~prescott/kcp/HPRC-GMSK-Demod.pdf

You can demodulate GMSK using the Viterbi algorithm.

Zhenhua,

We don't implement this method in our GMSK demodulator, though I have
wanted to see someone do it. The Viterbi is the maximum likelihood
detector for GMSK, but it's more complicated to implement. The
quadrature method we use is simple and intuitive but suboptimal.

Tom

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] The GMSK demodulation

[Marcus Müller]

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

2014-2-28 ??10:40? "Aditya Dhananjay" mailto:adi...@cs.nyu.edu>> ??:


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


I think you are mixing up the modulation and coding components.

At the transmitter, you first code (convolutional code), and then you 
modulate (GMSK).

At the receiver, you first demodulate (quadrature demodulate) and then you 
decode (Viterbi).

Coding takes a stream of bits and converts it to another stream of bits. Modulation 
refers to the process of converting the post-coded bits into "symbols" that you 
will then send over-the-air.

best,
aditya



___
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] The GMSK demodulation

[zhenhua han]

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
Zhenhua
2014-2-28 下午10:40于 "Aditya Dhananjay" 写道：

>
>> 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)?
>>
>>
> I think you are mixing up the modulation and coding components.
>
> At the transmitter, you first code (convolutional code), and then you
> modulate (GMSK).
>
> At the receiver, you first demodulate (quadrature demodulate) and then you
> decode (Viterbi).
>
> Coding takes a stream of bits and converts it to another stream of bits.
> Modulation refers to the process of converting the post-coded bits into
> "symbols" that you will then send over-the-air.
>
> best,
> aditya
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] message port names

[Marcus Müller]

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 (esp. the companion) 
display port names alike and are able to save/generate a flowgraph into/from a text file 
format
- stepping away from pmt_symbol as port name type opens up the gate for people 
doing stuff like assigning numeric values of different types (that could lead 
to a nice monte carlo QA for pmt::eqv; corner cases like 
pmt::eqv(pmt_uint64(x),pmt_int(x))==false will lead to problems)
  - I guess the whole point of pmt_symbol is it being unique and provide 
guaranteed identification**
- comparatively very little overhead with the outK method, your workaround seems 
feasible (also: you could consider keeping your own port name 
std::vector and use that for later reference; if you just need a 
(strangely sorted) list of your ports, it's basic_block::msg_queue)
- hashing overhead negligible for short strings and it speeds up the std::map 
operations when adding/using message ports (hashing will probably even pay 
during runtime)
+Ok, I admit it's strange to use PMTs if you'd actually wanted to use strings 
(and have the type safety)

Greetings,
Marcus

* valid for gcc 4.3+, clang and C++14 ;)
** Tom: why is there a d_next member in pmt_symbol?
On 02/28/2014 09:19 AM, Martin Braun wrote:

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

In a certain block I'm registering N ports, where N is a constructor
argument to the block. I was hoping I could call them
pmt::from_long(0) through pmt::from_long(N-1), but that didn't work.
I ended up creating string names "out0" through "outK" (where K =
N-1) and then used pmt::string_to_symbol.

I doubt anyone implemented that to limit names, it was more likely that
we didn't think of this use case. If you see this is a small,
non-invasive change that would allow other PMTs to be port names, that
would be interesting to see.

M

___
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] The GMSK demodulation

[Aditya Dhananjay]

>
>
> 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)?
>
>
I think you are mixing up the modulation and coding components.

At the transmitter, you first code (convolutional code), and then you
modulate (GMSK).

At the receiver, you first demodulate (quadrature demodulate) and then you
decode (Viterbi).

Coding takes a stream of bits and converts it to another stream of bits.
Modulation refers to the process of converting the post-coded bits into
"symbols" that you will then send over-the-air.

best,
aditya
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] The GMSK demodulation

[zhenhua han]

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

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

[Ricardo Yoshimura]

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 fadings spaced regularly in
frequency. The results I got showed a flat frequency response, as well as
in other standardized power delay profile scenarios.
The blocks I used were a random source -> OFDM Mod -> Throttle -> Frequency
Selective Fading Model -> WX GUI FFT Sink. Sample rate was set as 1MHz, so
that in Freq. Selective block I set PDP Delays as [0, 20] and PDP
Magnitudes as [1, 1].
Please tell me if I misunderstood any of these parameters or this block
could be really improved.


Thanks and Regards,
Ricardo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Marcus Müller]

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 energy in the 
dead-end discussion whether to migrate to #pragma once, since there are none in 
favour anymore :)

Marcus

On 02/28/2014 10:59 AM, Martin Braun wrote:

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. Agreeing, though,
that this is least priority. Also, almost all our include guards are
like this.

I think you're right on the "enough energy put into this" -- maybe I
should've been more careful when explicitely asking for discussion...
I guess  this kind of ends the discussion, then :) I'll put up a github
repo for the tools I've generated so far, and leave the GR tree alone
(as long as I don't find anything wildly disturbing).

Hey, I don't want to discourage discussions of any kind! Nothing wrong
at all with bringing things like this up.

M


Thank you all for your thought, extensive feedback and time!

Greetings,
Marcus


On 02/28/2014 08:58 AM, Martin Braun wrote:

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 erroneous include guards.
Basically, with a little tweaking my conversion script could be used to
do some QA on header files (and generate a report, or be run in a
post-receive hook etc)
- checking for include guards (are there any headers that shouldn't have
'em?)
- checking for unique include guard names
- checking if include guards GCC-optimizable.

I think we're already putting more energy into this than it deserves :)
At least for blocks, gr_modtool creates header guards that consist of
the module- and the block name, which you should choose wisely anyway.
Little chance of collisions here.

A script that would check for unique header guards wouldn't hurt. But
what are "optimizable guards"? I think we have much bigger cookies to
bake right now.

M

___
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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Martin Braun]

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. Agreeing, though,
> that this is least priority. Also, almost all our include guards are
> like this.
> 
> I think you're right on the "enough energy put into this" -- maybe I
> should've been more careful when explicitely asking for discussion...
> I guess  this kind of ends the discussion, then :) I'll put up a github
> repo for the tools I've generated so far, and leave the GR tree alone
> (as long as I don't find anything wildly disturbing).

Hey, I don't want to discourage discussions of any kind! Nothing wrong
at all with bringing things like this up.

M

> 
> Thank you all for your thought, extensive feedback and time!
> 
> Greetings,
> Marcus
> 
> 
> On 02/28/2014 08:58 AM, Martin Braun wrote:
>> 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 erroneous include guards.
>>> Basically, with a little tweaking my conversion script could be used to
>>> do some QA on header files (and generate a report, or be run in a
>>> post-receive hook etc)
>>> - checking for include guards (are there any headers that shouldn't have
>>> 'em?)
>>> - checking for unique include guard names
>>> - checking if include guards GCC-optimizable.
>> I think we're already putting more energy into this than it deserves :)
>> At least for blocks, gr_modtool creates header guards that consist of
>> the module- and the block name, which you should choose wisely anyway.
>> Little chance of collisions here.
>>
>> A script that would check for unique header guards wouldn't hurt. But
>> what are "optimizable guards"? I think we have much bigger cookies to
>> bake right now.
>>
>> M
>>
>> ___
>> 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

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

[Marcus Müller]

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, almost all our include guards are like this.

I think you're right on the "enough energy put into this" -- maybe I should've 
been more careful when explicitely asking for discussion...
I guess  this kind of ends the discussion, then :) I'll put up a github repo 
for the tools I've generated so far, and leave the GR tree alone (as long as I 
don't find anything wildly disturbing).

Thank you all for your thought, extensive feedback and time!

Greetings,
Marcus


On 02/28/2014 08:58 AM, Martin Braun wrote:

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 erroneous include guards.
Basically, with a little tweaking my conversion script could be used to
do some QA on header files (and generate a report, or be run in a
post-receive hook etc)
- checking for include guards (are there any headers that shouldn't have
'em?)
- checking for unique include guard names
- checking if include guards GCC-optimizable.

I think we're already putting more energy into this than it deserves :)
At least for blocks, gr_modtool creates header guards that consist of
the module- and the block name, which you should choose wisely anyway.
Little chance of collisions here.

A script that would check for unique header guards wouldn't hurt. But
what are "optimizable guards"? I think we have much bigger cookies to
bake right now.

M

___
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] message port names

[Martin Braun]

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 something?
> 
>> Tom
> 
> In a certain block I'm registering N ports, where N is a constructor
> argument to the block. I was hoping I could call them
> pmt::from_long(0) through pmt::from_long(N-1), but that didn't work.
> I ended up creating string names "out0" through "outK" (where K =
> N-1) and then used pmt::string_to_symbol.

I doubt anyone implemented that to limit names, it was more likely that
we didn't think of this use case. If you see this is a small,
non-invasive change that would allow other PMTs to be port names, that
would be interesting to see.

M

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Martin Braun]

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 paths, coming from two sources.
>  In one path, the two sources are simply summed.  In the other path, the
> two sources go through keep_m_in_n blocks before being multiplied
> together (this path mimics the more computationaly complex path).  In
> this example, the 'm' is set to 750e3, and the 'n' is an integer
> multiple of 'm'.  'NBUF' is the multiplier used in the flow graph, such
> that 'n = m*NBUF'.  When I set NBUF to 2 or below, things run.  When
> NBUF is set to 3 (or higher) the flowgraph does not run, and I get the
> following error for each keep_m_in_n block (for NBUF=3):

You get that same error even if you just connect the keep-block to a
null sink and source.

> sched:  is requesting more input data
>   than we can provide.
>   ninput_items_required = 225
>   max_possible_items_available = 1500159
>   If this is a filter, consider reducing the number of taps.
> 
> So, it seems that the max items available can accommodate just over
> NBUF=2 (which would be 1.5e6 samples).  As a note, I'm running GNU Radio
> 3.7 under Ubuntu 12.04 (64-bit).  I've also double-checked my
> sysctl.conf settings (e.g. shmmax) and they appear to be ok (I'm using a
> very capable, multi-core server).  Searching through some old posts, I
> happened upon:

Even with a large shmmax, buffer sizes are ultimately limited.

> http://gnuradio.4.n7.nabble.com/sched-is-requesting-more-input-data-than-we-can-provide-td45898.html
> 
> , which shows a similar problem.  The resolution was to use
> set_relative_rate, but I'm not sure how I would do that within grc?
>  Further, when I replace the keep_m_in_n blocks with decimators
> (specifically the Decimating FIR Filter), and use NBUF as the
> decimation, then everything runs just fine.  Am I simply doing something
> very silly?  Is there a better recommendation for the flowgraph
> architecture?

keep_m_in_n uses set_output_multiple() and hardcodes the relative rate
in forecast(). This makes the general_work() function very easy to
implement, since both the input and output buffer are already aligned to
the data.
The block wasn't designed for massive buffers like you need. This would
require rewriting the block to keep states, and simply operate on as
much buffer space is available. For small n and m, that might be
inefficient.
If you want to try this, I recommend creating your own keep-block in an
OOT, copying the code, switching set_output_multiple() to
set_relative_rate() and then adding states to your work function.

I can't see an easy way to do that with stock GR blocks right now.

M


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Martin Braun]

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 erroneous include guards.
> Basically, with a little tweaking my conversion script could be used to
> do some QA on header files (and generate a report, or be run in a
> post-receive hook etc)
> - checking for include guards (are there any headers that shouldn't have
> 'em?)
> - checking for unique include guard names
> - checking if include guards GCC-optimizable.

I think we're already putting more energy into this than it deserves :)
At least for blocks, gr_modtool creates header guards that consist of
the module- and the block name, which you should choose wisely anyway.
Little chance of collisions here.

A script that would check for unique header guards wouldn't hurt. But
what are "optimizable guards"? I think we have much bigger cookies to
bake right now.

M

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio