[Discuss-gnuradio] How To Print Elements of Vector Tags?

[qiankun]

Hi,

I'm new to gnuradio and want to do some wireless communication experiments
with it. I runned OFDM examples(rx_ofdm.grc & tx_ofdm.grc) and tried to use
the *tag debug* block to retrieve the CIR information generated during
receiving procedure. Yet what tag debug block outputs is the key-value pair,
*Key:ofdm_sync_chan_taps Value:#*, but not the vector
elements. Is there any way to print out the vector? Further more, is there
any way to record down all tags in file?

Thanks.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/How-To-Print-Elements-of-Vector-Tags-tp47530.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] Resampling, filters, and CPU Usage.

[Jordan Johnson]

As most of you likely have seen, I've been working on a flowhraph for quite
some time. Using gr-drm and an external FM processor, I have made a sort of
open alternative to HD Radio...because fun.

Anyway, the DRM signals are sampled at 48khz and the FM portion at 192. The
remainder of the graph is 384k due to filters. 2 bandpass filters,  4 band
reject filters.

To help you help me, I have uploaded the flow graph to Google Drive. It
require gr-drm and for your audio to be set to Jack. (Or just use null
sinks).I'm still rather new to GNURadio soI'm sure there's some rookie
mistakes in there:

IBOC.grc -
https://drive.google.com/file/d/0B9lYGe4c92PnTDlVbkprVFRybnM/edit?usp=sharing

gr-drm - https://github.com/kit-cel/gr-drm

Stereo Tool (FM processor) - http://www.stereotool.com/download/


So, what is it supposed to do?

Two DRM signals are to sit on the outside of the FM envelope. There should
only be two, but as they are interpolated, they make a mess and that's why
I put the filters there.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Denver Area Meetup?

[John Ewan]

You can count me in too, even if I just sit back and listen, and learn.
I am at least good for a second round.


John


On Fri, Apr 11, 2014 at 11:15 AM, Michael Ossmann  wrote:

> On Thu, Apr 10, 2014 at 11:26:54AM -0600, Eric Schneider wrote:
> >
> > Is anyone doing a GnuRadio / SDR meetup in the Denver Area?
>
> Count me in, but it may just be the two of us as usual.  :-)
>
> ___
> 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] Where to start in learning to develop and contribute to GNU Radio?

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ken,
welcome to the community!

I'll go ahead and answer in-line, since this seems to make sense here:
On 11.04.2014 23:16, Ken Adams wrote:
> I recently graduated with my degree in Computer Engineering, and
> the GNU Radio project is by far the most complex thing I've desired
> to work on. I'm looking for tips on how to get started learning GNU
> Radio from the ground up, build custom modules, and help develop
> the source.
just go through the Information on the main wiki side
http://gnuradio.org . A lot of people make the mistake to skip the
first pages (what GNU Radio is etc), and end up having misconceptions
after weeks of development.

> For example, an known issue that I would like to eventually be able
> to work on is solving Message Passing blocks not terminating from
> head block (and similar) termination.
That's actually a rather complicated scheduler problem. A solution is
highly desirable, but to make it short: The GNU Radio asynchronous
message passing interface does not support specifying an "end of
usage" state for the message port. If GR stopped execution when the
synchronous sample stream flowgraph was finished, not all messages
might have been delivered...
I see this as an architectural challenge, actual.

> 
> So my question is, what type of road map should I construct for
> learning the in's and out's of gnu radio, from custom module
> writing, all the way down to the scheduler. I have the absolute
> basics down (writing blocks in python) and will move to the C API
> next. But I'm not sure on where to start understanding the
> foundation of how it all works together.

You'll learn by doing, actually.
"Official" written documentation is sparse (a little bit) and can be
found in some presentations and papers.
But the main source of information is of course the (luckily in most
parts nicely readable) source code.

> Through my journey, I'm looking to improve the Documentation of GNU
> Radio so it is easy for new people to join the project.
I like your attitude ;)


Greetings,
and: happy hacking!

Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTSGKkAAoJEBQ6EdjyzlHts+cH/i/DqWt0PujHlfGHln73B96p
dvY+hfeWmiJQTwgbc5gaPeG1eTxoWnoUMpxZPcVieP8Fb0o7q7YWmcH4a20a7Fuj
sKjpQ54Zg+JKZXQJqw5NekgG4+lidq3iZlgOk3P8M4ALqk125+smWWUxZ77FA/RX
AP6uorVY/lB6O6NgsqUNHLwFOMIi1mV4ZL6zqnunRxVmk+zGgt2wLQeEAbMSoN4J
hzP8J41VG7RTzLK/5s9ceivblUXsFo8NeM7e9+jbIPhSvqE2VpqBR1NS06lJbG5x
Oqw/tJS0VZHCnCrN9IHJ36SINETpJlW4ha9SF88+U/IS0Mf5ZvilQgc7B8IPOnM=
=Sntn
-END PGP SIGNATURE-

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

[Discuss-gnuradio] Where to start in learning to develop and contribute to GNU Radio?

[Ken Adams]

I recently graduated with my degree in Computer Engineering, and the GNU
Radio project is by far the most complex thing I've desired to work on. I'm
looking for tips on how to get started learning GNU Radio from the ground
up, build custom modules, and help develop the source.

For example, an known issue that I would like to eventually be able to work
on is solving Message Passing blocks not terminating from head block (and
similar) termination.

So my question is, what type of road map should I construct for learning
the in's and out's of gnu radio, from custom module writing, all the way
down to the scheduler. I have the absolute basics down (writing blocks in
python) and will move to the C API next. But I'm not sure on where to start
understanding the foundation of how it all works together.

Through my journey, I'm looking to improve the Documentation of GNU Radio
so it is easy for new people to join the project.

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

Re: [Discuss-gnuradio] ctrlport-monitor: radio.get threw exception (math domain error).

[Luke Berndt]

Not a problem - It was under a VM, so that is probably what was causing it.
I ran it at home on bare metal with a HackRF and didn't have any issues.


On Fri, Apr 11, 2014 at 4:10 PM, Tom Rondeau  wrote:

> On Wed, Mar 26, 2014 at 4:28 PM, Luke Berndt  wrote:
>
>> I get the following error when trying to the run gr-perf-monitorx against
>> a flow graph that has an RTL_SDR radio as the source. I recompiled both
>> rtl_sdr and gr_osmosdr after enabling performance counters in gnuradio.
>>
>> The odd thing is that it works fine when I do not have an RTL_SDR radio
>> attached. In that instance gr-osmosdr simply attaches a null source
>> instead. This seems to point to the RTL_SDR source. Has anyone succesfully
>> used gr-perf-monitorx with a RTL_SDR source?
>>
>> Thanks
>>
>> Luke
>>
>> PS - also just in case anyone else tries, 'perf top' doesn't work in a
>> VM...
>>
>
>
> Luke,
>
> This gut buried in my inbox. Any updates on your success with this? Are
> you running into this on a VM? It might be something related to that,
> anyways.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ctrlport-monitor: radio.get threw exception (math domain error).

[Tom Rondeau]

On Wed, Mar 26, 2014 at 4:28 PM, Luke Berndt  wrote:

> I get the following error when trying to the run gr-perf-monitorx against
> a flow graph that has an RTL_SDR radio as the source. I recompiled both
> rtl_sdr and gr_osmosdr after enabling performance counters in gnuradio.
>
> The odd thing is that it works fine when I do not have an RTL_SDR radio
> attached. In that instance gr-osmosdr simply attaches a null source
> instead. This seems to point to the RTL_SDR source. Has anyone succesfully
> used gr-perf-monitorx with a RTL_SDR source?
>
> Thanks
>
> Luke
>
> PS - also just in case anyone else tries, 'perf top' doesn't work in a
> VM...
>


Luke,

This gut buried in my inbox. Any updates on your success with this? Are you
running into this on a VM? It might be something related to that, anyways.

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

Re: [Discuss-gnuradio] ASK demodulation help

[Tom Rondeau]

On Fri, Apr 11, 2014 at 1:34 PM, Nick Foster  wrote:

> That's very likely it. It's effectively starting with a random guess as to
> the bit timing, and it locks exponentially faster the closer it is to
> correct. So for a worst-case guess, it'll take significantly longer to lock.
>
> --n
>

I would suggest downsampling before the clock sync block, too. IIRC, you're
using 16 samples per symbol, which is way higher than you need. Go through
a 4x down sampler to get 4 sps. That could help with this issue. Note that
you'll probably have to change your gains for the new sps value.

Tom




> On Fri, Apr 11, 2014 at 10:33 AM, Francois Gervais <
> francoisgerv...@gmail.com> wrote:
>
>> That could explain it. However most of the time it locks just fine even
>> for the preamble with the same block parameters. I'm not sure what causes
>> this variability and if I have control over it of not.
>>
>> Might be related to when the MM clock recovery starts sampling the
>> signal. Sometimes it's lucky and start sampling the bit close to a bit
>> frontier and sometimes not so it needs to adjust on the next bit. Could
>> that make sense?
>>
>>
>> On Fri, Apr 11, 2014 at 1:19 PM, Nick Foster wrote:
>>
>>> To me it looks like it's taking some time to acquire, which is normal
>>> for a closed-loop timing recovery algorithm. This is one reason packets
>>> have preambles. If you need it to lock faster and don't mind some
>>> self-noise, and if the SNR is high enough, you can turn up the gain of the
>>> M&M block (change 0.175 in both gain mu and gain omega to a larger number)
>>> to allow it to lock faster.
>>>
>>> --n
>>>
>>>
>>> On Fri, Apr 11, 2014 at 9:59 AM, Francois Gervais <
>>> francoisgerv...@gmail.com> wrote:
>>>
 Any idea on this? Should I post the images somewhere else?


 On Thu, Apr 10, 2014 at 11:11 PM, Francois Gervais <
 francoisgerv...@gmail.com> wrote:

> I tried using the M&M clock recovery block as suggested and I have a
> little fidelity problem. I added two screenshot links below which show the
> problem. I would say 70% of the time the recovered data is fine but for
> some reason it's sometimes badly distorted. By looking at it, the input
> signal looks always about the same. Is there something obviously wrong in
> what I'm doing?
>
> ASK demodulation GRC
>
> https://drive.google.com/file/d/0B_ApAHfP4naZaE5WRUJHWUtHUEU/edit?usp=sharing
>
> Signal in and out of Clock recovery block
>
> https://drive.google.com/file/d/0B_ApAHfP4naZY3Ryblp3cFlrdGs/edit?usp=sharing
>
>
> On Wed, Apr 9, 2014 at 5:27 PM, John Malsbury  > wrote:
>
>> I don't know if I would call it overkill.  It is just one of several
>> methods you can use to achieve synchronization.  Other options for
>> synchronization include correlate and sync (probably needs modification),
>> or possible the polyphase resync.  Others on the list would have more
>> expertise on these blocks.
>>
>> In my experience 10 samples per symbol seems to work well with M&M.
>> I've heard very high samp/sym (ie. >20) can cause problems, but I haven't
>> seen this myself.
>>
>> The amplitude going into M&M should be as close as possible to +/-
>> 1.0, which is why you want the scaling functions before this block.  The
>> AGC block assures you're working with something constant amplitude for
>> demodulation.
>>
>> -John
>>
>>
>> On Wed, Apr 9, 2014 at 2:04 PM, Francois Gervais <
>> francoisgerv...@gmail.com> wrote:
>>
>>> Thanks guys for the information,
>>>
>>> I looked a little about the M&M recovery block but it seemed to me
>>> like and advance algorithm, overkill for what I'm trying to achieve. 
>>> I'm I
>>> mistaken?
>>>
>>> If I'm using the M&M clock recovery block what is the quality of
>>> input signal I should aim to avoid translation errors? Should my signal 
>>> be
>>> filtered with a really narrow band and should I allow more harmonics in 
>>> to
>>> the signal is more square? Can the input signal have too much sample per
>>> bit? Right now I'm at 16. Is more better? Is it better to have more
>>> amplitude?
>>>
>>> Thanks
>>>
>>>
>>> On Wed, Apr 9, 2014 at 4:31 PM, John Malsbury <
>>> john.malsb...@ettus.com> wrote:
>>>
 Depending on various factors the implementation may vary, but you
 could probably start with a chain that looks something like this:

 I/q source -> filter -> AGC -> AM demod (complex to mag) -> scaling
 for am depth -> m&m clock recovery -> slicer -> do something with the 
 data

 Other, more advanced implementations might use correlation for
 synchronization.

 -John


 On Wed, Apr 9, 2014 at 1:27 PM, Francois Gervais <
 francoisgerv...@gmail.com> wrote

Re: [Discuss-gnuradio] ASK demodulation help

[Nick Foster]

That's very likely it. It's effectively starting with a random guess as to
the bit timing, and it locks exponentially faster the closer it is to
correct. So for a worst-case guess, it'll take significantly longer to lock.

--n


On Fri, Apr 11, 2014 at 10:33 AM, Francois Gervais <
francoisgerv...@gmail.com> wrote:

> That could explain it. However most of the time it locks just fine even
> for the preamble with the same block parameters. I'm not sure what causes
> this variability and if I have control over it of not.
>
> Might be related to when the MM clock recovery starts sampling the signal.
> Sometimes it's lucky and start sampling the bit close to a bit frontier and
> sometimes not so it needs to adjust on the next bit. Could that make sense?
>
>
> On Fri, Apr 11, 2014 at 1:19 PM, Nick Foster  wrote:
>
>> To me it looks like it's taking some time to acquire, which is normal for
>> a closed-loop timing recovery algorithm. This is one reason packets have
>> preambles. If you need it to lock faster and don't mind some self-noise,
>> and if the SNR is high enough, you can turn up the gain of the M&M block
>> (change 0.175 in both gain mu and gain omega to a larger number) to allow
>> it to lock faster.
>>
>> --n
>>
>>
>> On Fri, Apr 11, 2014 at 9:59 AM, Francois Gervais <
>> francoisgerv...@gmail.com> wrote:
>>
>>> Any idea on this? Should I post the images somewhere else?
>>>
>>>
>>> On Thu, Apr 10, 2014 at 11:11 PM, Francois Gervais <
>>> francoisgerv...@gmail.com> wrote:
>>>
 I tried using the M&M clock recovery block as suggested and I have a
 little fidelity problem. I added two screenshot links below which show the
 problem. I would say 70% of the time the recovered data is fine but for
 some reason it's sometimes badly distorted. By looking at it, the input
 signal looks always about the same. Is there something obviously wrong in
 what I'm doing?

 ASK demodulation GRC

 https://drive.google.com/file/d/0B_ApAHfP4naZaE5WRUJHWUtHUEU/edit?usp=sharing

 Signal in and out of Clock recovery block

 https://drive.google.com/file/d/0B_ApAHfP4naZY3Ryblp3cFlrdGs/edit?usp=sharing


 On Wed, Apr 9, 2014 at 5:27 PM, John Malsbury 
 wrote:

> I don't know if I would call it overkill.  It is just one of several
> methods you can use to achieve synchronization.  Other options for
> synchronization include correlate and sync (probably needs modification),
> or possible the polyphase resync.  Others on the list would have more
> expertise on these blocks.
>
> In my experience 10 samples per symbol seems to work well with M&M.
> I've heard very high samp/sym (ie. >20) can cause problems, but I haven't
> seen this myself.
>
> The amplitude going into M&M should be as close as possible to +/-
> 1.0, which is why you want the scaling functions before this block.  The
> AGC block assures you're working with something constant amplitude for
> demodulation.
>
> -John
>
>
> On Wed, Apr 9, 2014 at 2:04 PM, Francois Gervais <
> francoisgerv...@gmail.com> wrote:
>
>> Thanks guys for the information,
>>
>> I looked a little about the M&M recovery block but it seemed to me
>> like and advance algorithm, overkill for what I'm trying to achieve. I'm 
>> I
>> mistaken?
>>
>> If I'm using the M&M clock recovery block what is the quality of
>> input signal I should aim to avoid translation errors? Should my signal 
>> be
>> filtered with a really narrow band and should I allow more harmonics in 
>> to
>> the signal is more square? Can the input signal have too much sample per
>> bit? Right now I'm at 16. Is more better? Is it better to have more
>> amplitude?
>>
>> Thanks
>>
>>
>> On Wed, Apr 9, 2014 at 4:31 PM, John Malsbury <
>> john.malsb...@ettus.com> wrote:
>>
>>> Depending on various factors the implementation may vary, but you
>>> could probably start with a chain that looks something like this:
>>>
>>> I/q source -> filter -> AGC -> AM demod (complex to mag) -> scaling
>>> for am depth -> m&m clock recovery -> slicer -> do something with the 
>>> data
>>>
>>> Other, more advanced implementations might use correlation for
>>> synchronization.
>>>
>>> -John
>>>
>>>
>>> On Wed, Apr 9, 2014 at 1:27 PM, Francois Gervais <
>>> francoisgerv...@gmail.com> wrote:
>>>
 Hi,

 I'm new to gnu radio and I'm trying to demodulate a 125kpbs ASK
 signal from a device I have, as a first project. I'm using RTL-SDR as 
 the
 input device.

 I'm slowly getting there. I receive the signal, at 2Msample/s, I
 low-pass filter it to 300khz, I send it through the AM demodulation 
 block
 and then through the DC blocker.

 From there I have my 

Re: [Discuss-gnuradio] ASK demodulation help

[Francois Gervais]

That could explain it. However most of the time it locks just fine even for
the preamble with the same block parameters. I'm not sure what causes this
variability and if I have control over it of not.

Might be related to when the MM clock recovery starts sampling the signal.
Sometimes it's lucky and start sampling the bit close to a bit frontier and
sometimes not so it needs to adjust on the next bit. Could that make sense?


On Fri, Apr 11, 2014 at 1:19 PM, Nick Foster  wrote:

> To me it looks like it's taking some time to acquire, which is normal for
> a closed-loop timing recovery algorithm. This is one reason packets have
> preambles. If you need it to lock faster and don't mind some self-noise,
> and if the SNR is high enough, you can turn up the gain of the M&M block
> (change 0.175 in both gain mu and gain omega to a larger number) to allow
> it to lock faster.
>
> --n
>
>
> On Fri, Apr 11, 2014 at 9:59 AM, Francois Gervais <
> francoisgerv...@gmail.com> wrote:
>
>> Any idea on this? Should I post the images somewhere else?
>>
>>
>> On Thu, Apr 10, 2014 at 11:11 PM, Francois Gervais <
>> francoisgerv...@gmail.com> wrote:
>>
>>> I tried using the M&M clock recovery block as suggested and I have a
>>> little fidelity problem. I added two screenshot links below which show the
>>> problem. I would say 70% of the time the recovered data is fine but for
>>> some reason it's sometimes badly distorted. By looking at it, the input
>>> signal looks always about the same. Is there something obviously wrong in
>>> what I'm doing?
>>>
>>> ASK demodulation GRC
>>>
>>> https://drive.google.com/file/d/0B_ApAHfP4naZaE5WRUJHWUtHUEU/edit?usp=sharing
>>>
>>> Signal in and out of Clock recovery block
>>>
>>> https://drive.google.com/file/d/0B_ApAHfP4naZY3Ryblp3cFlrdGs/edit?usp=sharing
>>>
>>>
>>> On Wed, Apr 9, 2014 at 5:27 PM, John Malsbury 
>>> wrote:
>>>
 I don't know if I would call it overkill.  It is just one of several
 methods you can use to achieve synchronization.  Other options for
 synchronization include correlate and sync (probably needs modification),
 or possible the polyphase resync.  Others on the list would have more
 expertise on these blocks.

 In my experience 10 samples per symbol seems to work well with M&M.
 I've heard very high samp/sym (ie. >20) can cause problems, but I haven't
 seen this myself.

 The amplitude going into M&M should be as close as possible to +/- 1.0,
 which is why you want the scaling functions before this block.  The AGC
 block assures you're working with something constant amplitude for
 demodulation.

 -John


 On Wed, Apr 9, 2014 at 2:04 PM, Francois Gervais <
 francoisgerv...@gmail.com> wrote:

> Thanks guys for the information,
>
> I looked a little about the M&M recovery block but it seemed to me
> like and advance algorithm, overkill for what I'm trying to achieve. I'm I
> mistaken?
>
> If I'm using the M&M clock recovery block what is the quality of input
> signal I should aim to avoid translation errors? Should my signal be
> filtered with a really narrow band and should I allow more harmonics in to
> the signal is more square? Can the input signal have too much sample per
> bit? Right now I'm at 16. Is more better? Is it better to have more
> amplitude?
>
> Thanks
>
>
> On Wed, Apr 9, 2014 at 4:31 PM, John Malsbury  > wrote:
>
>> Depending on various factors the implementation may vary, but you
>> could probably start with a chain that looks something like this:
>>
>> I/q source -> filter -> AGC -> AM demod (complex to mag) -> scaling
>> for am depth -> m&m clock recovery -> slicer -> do something with the 
>> data
>>
>> Other, more advanced implementations might use correlation for
>> synchronization.
>>
>> -John
>>
>>
>> On Wed, Apr 9, 2014 at 1:27 PM, Francois Gervais <
>> francoisgerv...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm new to gnu radio and I'm trying to demodulate a 125kpbs ASK
>>> signal from a device I have, as a first project. I'm using RTL-SDR as 
>>> the
>>> input device.
>>>
>>> I'm slowly getting there. I receive the signal, at 2Msample/s, I
>>> low-pass filter it to 300khz, I send it through the AM demodulation 
>>> block
>>> and then through the DC blocker.
>>>
>>> From there I have my signal and it looks fine i.e I could retrieve
>>> the information manually by looking at it.
>>>
>>> Now I think the goal is to somehow synchronize with the bits and
>>> re-sample to get 1 sample per bit. This could then be sent to a file. Is
>>> that it?
>>>
>>> At first glance I'm thinking I should have a PLL which ouputs a
>>> clock at about 250khz (twice the bit rate) and synchronize the rising 
>>> edge
>>> with every bit transitioning from 0 

Re: [Discuss-gnuradio] ASK demodulation help

[Nick Foster]

To me it looks like it's taking some time to acquire, which is normal for a
closed-loop timing recovery algorithm. This is one reason packets have
preambles. If you need it to lock faster and don't mind some self-noise,
and if the SNR is high enough, you can turn up the gain of the M&M block
(change 0.175 in both gain mu and gain omega to a larger number) to allow
it to lock faster.

--n


On Fri, Apr 11, 2014 at 9:59 AM, Francois Gervais  wrote:

> Any idea on this? Should I post the images somewhere else?
>
>
> On Thu, Apr 10, 2014 at 11:11 PM, Francois Gervais <
> francoisgerv...@gmail.com> wrote:
>
>> I tried using the M&M clock recovery block as suggested and I have a
>> little fidelity problem. I added two screenshot links below which show the
>> problem. I would say 70% of the time the recovered data is fine but for
>> some reason it's sometimes badly distorted. By looking at it, the input
>> signal looks always about the same. Is there something obviously wrong in
>> what I'm doing?
>>
>> ASK demodulation GRC
>>
>> https://drive.google.com/file/d/0B_ApAHfP4naZaE5WRUJHWUtHUEU/edit?usp=sharing
>>
>> Signal in and out of Clock recovery block
>>
>> https://drive.google.com/file/d/0B_ApAHfP4naZY3Ryblp3cFlrdGs/edit?usp=sharing
>>
>>
>> On Wed, Apr 9, 2014 at 5:27 PM, John Malsbury wrote:
>>
>>> I don't know if I would call it overkill.  It is just one of several
>>> methods you can use to achieve synchronization.  Other options for
>>> synchronization include correlate and sync (probably needs modification),
>>> or possible the polyphase resync.  Others on the list would have more
>>> expertise on these blocks.
>>>
>>> In my experience 10 samples per symbol seems to work well with M&M.
>>> I've heard very high samp/sym (ie. >20) can cause problems, but I haven't
>>> seen this myself.
>>>
>>> The amplitude going into M&M should be as close as possible to +/- 1.0,
>>> which is why you want the scaling functions before this block.  The AGC
>>> block assures you're working with something constant amplitude for
>>> demodulation.
>>>
>>> -John
>>>
>>>
>>> On Wed, Apr 9, 2014 at 2:04 PM, Francois Gervais <
>>> francoisgerv...@gmail.com> wrote:
>>>
 Thanks guys for the information,

 I looked a little about the M&M recovery block but it seemed to me like
 and advance algorithm, overkill for what I'm trying to achieve. I'm I
 mistaken?

 If I'm using the M&M clock recovery block what is the quality of input
 signal I should aim to avoid translation errors? Should my signal be
 filtered with a really narrow band and should I allow more harmonics in to
 the signal is more square? Can the input signal have too much sample per
 bit? Right now I'm at 16. Is more better? Is it better to have more
 amplitude?

 Thanks


 On Wed, Apr 9, 2014 at 4:31 PM, John Malsbury 
 wrote:

> Depending on various factors the implementation may vary, but you
> could probably start with a chain that looks something like this:
>
> I/q source -> filter -> AGC -> AM demod (complex to mag) -> scaling
> for am depth -> m&m clock recovery -> slicer -> do something with the data
>
> Other, more advanced implementations might use correlation for
> synchronization.
>
> -John
>
>
> On Wed, Apr 9, 2014 at 1:27 PM, Francois Gervais <
> francoisgerv...@gmail.com> wrote:
>
>> Hi,
>>
>> I'm new to gnu radio and I'm trying to demodulate a 125kpbs ASK
>> signal from a device I have, as a first project. I'm using RTL-SDR as the
>> input device.
>>
>> I'm slowly getting there. I receive the signal, at 2Msample/s, I
>> low-pass filter it to 300khz, I send it through the AM demodulation block
>> and then through the DC blocker.
>>
>> From there I have my signal and it looks fine i.e I could retrieve
>> the information manually by looking at it.
>>
>> Now I think the goal is to somehow synchronize with the bits and
>> re-sample to get 1 sample per bit. This could then be sent to a file. Is
>> that it?
>>
>> At first glance I'm thinking I should have a PLL which ouputs a clock
>> at about 250khz (twice the bit rate) and synchronize the rising edge with
>> every bit transitioning from 0 to 1 so unless I receive only ones ou 
>> zeros
>> I should be quite in sync. Then I could toggle a sample every falling 
>> edge
>> of the clock which should be at about the middle of the bit.
>>
>> Is this a viable solution? Can it be done with gnuradio? Other
>> alternatives?
>>
>> Thanks
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 htt

Re: [Discuss-gnuradio] Denver Area Meetup?

[Michael Ossmann]

On Thu, Apr 10, 2014 at 11:26:54AM -0600, Eric Schneider wrote:
>
> Is anyone doing a GnuRadio / SDR meetup in the Denver Area?

Count me in, but it may just be the two of us as usual.  :-)

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

Re: [Discuss-gnuradio] GSOC 14 proposal for project "Vector Network Analyzer"

[Eric Schneider]

I'm not sure how the GSOC thing works, but if there is anything I can do 
to help make this project happen, let me know!


This very idea has been on my "some day" shelf for far to long...

--Eric

On 03/13/2014 11:41 AM, MITUL VEKARIYA wrote:

Hi
Here's the link for my proposal for the project "Vector Network Analyzer"
https://docs.google.com/file/d/0B5wp9A_w2B5scmVKOTlGbVFISm8/edit?pli=1

You can post comment on google doc also.
I am all ears to any suggestion.

Thanks
Mitul Vekariya
Institute of Technology
Nirma University
Ahmedabad 382350


___
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] ASK demodulation help

[Francois Gervais]

Any idea on this? Should I post the images somewhere else?


On Thu, Apr 10, 2014 at 11:11 PM, Francois Gervais <
francoisgerv...@gmail.com> wrote:

> I tried using the M&M clock recovery block as suggested and I have a
> little fidelity problem. I added two screenshot links below which show the
> problem. I would say 70% of the time the recovered data is fine but for
> some reason it's sometimes badly distorted. By looking at it, the input
> signal looks always about the same. Is there something obviously wrong in
> what I'm doing?
>
> ASK demodulation GRC
>
> https://drive.google.com/file/d/0B_ApAHfP4naZaE5WRUJHWUtHUEU/edit?usp=sharing
>
> Signal in and out of Clock recovery block
>
> https://drive.google.com/file/d/0B_ApAHfP4naZY3Ryblp3cFlrdGs/edit?usp=sharing
>
>
> On Wed, Apr 9, 2014 at 5:27 PM, John Malsbury wrote:
>
>> I don't know if I would call it overkill.  It is just one of several
>> methods you can use to achieve synchronization.  Other options for
>> synchronization include correlate and sync (probably needs modification),
>> or possible the polyphase resync.  Others on the list would have more
>> expertise on these blocks.
>>
>> In my experience 10 samples per symbol seems to work well with M&M.  I've
>> heard very high samp/sym (ie. >20) can cause problems, but I haven't seen
>> this myself.
>>
>> The amplitude going into M&M should be as close as possible to +/- 1.0,
>> which is why you want the scaling functions before this block.  The AGC
>> block assures you're working with something constant amplitude for
>> demodulation.
>>
>> -John
>>
>>
>> On Wed, Apr 9, 2014 at 2:04 PM, Francois Gervais <
>> francoisgerv...@gmail.com> wrote:
>>
>>> Thanks guys for the information,
>>>
>>> I looked a little about the M&M recovery block but it seemed to me like
>>> and advance algorithm, overkill for what I'm trying to achieve. I'm I
>>> mistaken?
>>>
>>> If I'm using the M&M clock recovery block what is the quality of input
>>> signal I should aim to avoid translation errors? Should my signal be
>>> filtered with a really narrow band and should I allow more harmonics in to
>>> the signal is more square? Can the input signal have too much sample per
>>> bit? Right now I'm at 16. Is more better? Is it better to have more
>>> amplitude?
>>>
>>> Thanks
>>>
>>>
>>> On Wed, Apr 9, 2014 at 4:31 PM, John Malsbury 
>>> wrote:
>>>
 Depending on various factors the implementation may vary, but you could
 probably start with a chain that looks something like this:

 I/q source -> filter -> AGC -> AM demod (complex to mag) -> scaling for
 am depth -> m&m clock recovery -> slicer -> do something with the data

 Other, more advanced implementations might use correlation for
 synchronization.

 -John


 On Wed, Apr 9, 2014 at 1:27 PM, Francois Gervais <
 francoisgerv...@gmail.com> wrote:

> Hi,
>
> I'm new to gnu radio and I'm trying to demodulate a 125kpbs ASK signal
> from a device I have, as a first project. I'm using RTL-SDR as the input
> device.
>
> I'm slowly getting there. I receive the signal, at 2Msample/s, I
> low-pass filter it to 300khz, I send it through the AM demodulation block
> and then through the DC blocker.
>
> From there I have my signal and it looks fine i.e I could retrieve the
> information manually by looking at it.
>
> Now I think the goal is to somehow synchronize with the bits and
> re-sample to get 1 sample per bit. This could then be sent to a file. Is
> that it?
>
> At first glance I'm thinking I should have a PLL which ouputs a clock
> at about 250khz (twice the bit rate) and synchronize the rising edge with
> every bit transitioning from 0 to 1 so unless I receive only ones ou zeros
> I should be quite in sync. Then I could toggle a sample every falling edge
> of the clock which should be at about the middle of the bit.
>
> Is this a viable solution? Can it be done with gnuradio? Other
> alternatives?
>
> Thanks
>
> ___
> 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] New GRC behavior request for comment

[Marcus Leech]

 





 
Yeah, I'll do the same; enter a variable I haven't created yet. I'm afraid of putting pop-up boxes like this, though. You'll still see the red text in the block and the GRC error button will be enabled to help you track things down, so there will be an indication that you've done something wrong, it might just be after you've closed the box and will have to reopen it. My problem with adding pop-up error boxes is the "Windows Vista" effect of just "dammit, I know what I'm doing!" and close it without necessarily reading the warning or error.
 
Tom
 
Agreed, as long as there's still some indication, I'm cool with that.
 







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

Re: [Discuss-gnuradio] How many multiple/simultaneous PLLs can I have running on USRP2?

[John Wilson]

Sorry to dig up an old thread, but does anyone know of anyone who's
implemented a polyphase filter bank on a USRP FPGA?

John


On Thu, May 9, 2013 at 12:02 AM, Marcus D. Leech  wrote:

>   Or am I wrong that the resource is in the computer and not in the USRP?
>
>
>
> LD
>
>
>
> It's all in the computer, unless you do an FPGA-based implementation.
> Gnu Radio blocks run on the host machine, not the USRP hardware.
>
> I admit to being a little bit surprised that you don't know that already,
> given how long you've been posting things to this list,
>   and using USRP hardware.
>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
> ___
> 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] New GRC behavior request for comment

[Tom Rondeau]

On Thu, Apr 10, 2014 at 7:00 PM, Marcus D. Leech  wrote:

> On 04/10/2014 04:13 PM, Ed Criscuolo wrote:
>
>>
>>
>> How hard would it be to pop up a bother box if you attempt
>> to enter with outstanding parameter error(s).  Give you
>> a chance to confirm or cancel the enter, because you may want to
>> deliberately enter something that's wrong now but will be
>> fixed later (for instance a variable name that you haven't
>> created yet).
>>
> I certainly like the "evaluate when you leave the box" paradigm, but I'm
> also the kind of developer who will enter a variable name, etc, that
>   hasn't actually been created yet.
>
> --
> Marcus Leech
>

Yeah, I'll do the same; enter a variable I haven't created yet. I'm afraid
of putting pop-up boxes like this, though. You'll still see the red text in
the block and the GRC error button will be enabled to help you track things
down, so there will be an indication that you've done something wrong, it
might just be after you've closed the box and will have to reopen it. My
problem with adding pop-up error boxes is the "Windows Vista" effect of
just "dammit, I know what I'm doing!" and close it without necessarily
reading the warning or error.

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

Re: [Discuss-gnuradio] New GRC behavior request for comment

[Tom Rondeau]

On Fri, Apr 11, 2014 at 3:29 AM, Koslowski, Sebastian (CEL) <
sebastian.koslow...@kit.edu> wrote:

> Same here. Thanks for reporting. I pushed a fix to the GRCWG repo,
> should make it into the mainline soon.
>
> Sebastian



I just merged and pushed Sebastian's quick fix for the issue.

Tom




>  On 04/11/2014 04:27 AM, Dan CaJacob wrote:
> > I think this change might be breaking a few things.  If anyone else can
> > check, please let me know if I'm nuts:
> >
> > I am running v3.7.4git-95-g24191d86 on Ubuntu 13.10 x64.  In GRC, when I
> > try to change the type associated with a block via the select box, it
> > changes (and the text turns blue), but when I close the parameter
> > window, nothing actually changes.  I also saw similar behavior with
> > combo boxes.  In that case, selecting an option did not take, but
> > overwriting it did.
> >
> > Very Respectfully,
> >
> > Dan CaJacob
> >
> >
> > On Thu, Apr 10, 2014 at 7:00 PM, Marcus D. Leech  > > wrote:
> >
> > On 04/10/2014 04:13 PM, Ed Criscuolo wrote:
> >
> >
> >
> > How hard would it be to pop up a bother box if you attempt
> > to enter with outstanding parameter error(s).  Give you
> > a chance to confirm or cancel the enter, because you may want to
> > deliberately enter something that's wrong now but will be
> > fixed later (for instance a variable name that you haven't
> > created yet).
> >
> > I certainly like the "evaluate when you leave the box" paradigm, but
> > I'm also the kind of developer who will enter a variable name, etc,
> that
> >   hasn't actually been created yet.
> >
> > --
> > Marcus Leech
> > Principal Investigator
> > Shirleys Bay Radio Astronomy Consortium
> > http://www.sbrac.org
> >
> >
> >
> > _
> > 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
> >
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Sebastian Koslowski
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe, Germany
>
> Phone: +49 721 608-46275
> Fax:   +49 721 608-46071
> Email: sebastian.koslow...@kit.edu
> Web:   http://www.cel.kit.edu/
>
> KIT - University of the State of Baden-Wuerttemberg and National
> Research Center of the Helmholtz Association
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM SNR

[Martin Braun]

On 04/10/2014 01:33 PM, Piotr Potocki wrote:
> First thanks for helping me out!
> 
> 1. I found out that in file 'ofdm_equalizer_simpledfe' there is a part
> concerning mapping samples into correct positions (-1,1).
> 
> //
> d_constellation->map_to_points(d_constellation->decision_maker(&sym_eq),
> &sym_est);
> 
> I commented out it but still the mapping didn’t stop. And i couldn’t
> find any other code that is doing this mapping.
> So where the mapping is taking place?

Hm, this won't work, I guess. Line 102 does the actual assignment...

> 2. Unfortunately commentating out this part is not only disabling
> equalization but also the phase correction and frequency correction.
> But i figure out that for SNR estimation i don't need phase and freq
> correction. The downside is that when i am trying to estimate SNR i
> don't receive correct data.

You definitely need the coarse freq offset correction. That also means
fiddling with your phase (which shouldn't matter for SNR estimation).
However, that's done in ofdm_frame_equalizer_vcvc.

And yeah, of course you don't get correct data if you don't equalize.

> 3. Thanks for it the scope sink in XY mode works perfect. And one small
> question, how to make constant X,Y coordinate system (set X value from
> -2 to 2 and Y -2 to 2)?

QT or WX? Have a look at the GRC property dialogues.

> And last question is abut transferring data to Matlab. To estimate SNR i
> need to take the complex value and 'take' them to mag^2.
> But i don't know how to read/open this .dat file in Matlab. First i was
> trying to use block 'complex to mag^2' in gnuradio and then write the
> data to a file (constellation3.dat). And then use Matlab simple function:
> fileID_rx=fopen('constellation3.dat');
> snr=fread(fileID_rx,'double');
> But the results are not correct.

Look at read_float_binary.m, also read the FAQ.


- Martin

> Also i don't know how to open complex file in matlab without block
> 'complex to mag^2. The data file from file_sink is really 'wired'
> (constellation3_no_mag2.dat).
> 
> Both files are written down with working equalizer, so the symbols are
> only place (-1,1).
> To see constellation3_no_mag2.dat samples simply use  gr_plot_iq
> constellation3_no_mag2.dat .
>  
> 
> 
> 
> 
> My specs of system:
> FFT length = 64
> Sample rate = 2M
> Packet length = 40 ( i tried with different packet length and 40 gave
> the best results) 
> Modulation = BPSK
> Carrier frequency = 2.4 Ghz
> Occupied carriers = 52
> 
> Best regards,
> Piotr Potocki
> 
> 
> 2014-03-31 15:35 GMT+02:00 Martin Braun  >:
> 
> On 03/31/2014 01:03 PM, Piotr Potocki wrote:
> > 1. I want to estimate SNR using IQ samples. But when I receive IQ
> > samples on the receiver (img iq_samples_eq) they are all "perfect". So
> > my first question is, is there some kind of "hard decision" in OFDM
> > Frame Equalizer? Without OFDM Frame Equalizer (img iq_samples_no_s)
> 
> Yes -- the current equalizer discards soft information. That's a clear
> shortcoming, but I simply haven't had the time to implement a proper
> equalizer so far, and if anyone else has, they haven't committed it
> upstream.
> 
> You can write your own equalizers by subclassing ofdm_equalizer_base.
> It's pretty simple, if you already have an algorithm in C++.
> 
> > 2. The second problem is, that I need to have a white noise not
> coloured
> > noise.
> > And to to that i need to get rid of the equalizer part of the OFDM
> Frame
> > Equalizer. The part of correction frequency shift on the symbols
> need to
> > stay.
> > Do You have some hints how to do that? (Just commented "//" this
> part ?
> > // Do the equalizing
> >   d_eq->reset();
> >   d_eq->equalize(out, frame_len, d_channel_state);
> >   d_eq->get_channel_state(d_channel_state);
> 
> That should work. The cleaner way would be to add a 'dummy' equalizer
> that can be dropped in.
> Note that if you leave the equalizer out, you will be able to do nothing
> but SNR estimation. I don't know the details of those algorithms by
> heart, but some might not work either, since symbols will be phase
> rotated.
> Maybe you can intercept the channel state PMT in a custom block, modify
> that to your needs, and use the ofdm_equalizer_static.
> 
> > 3. The 3 question is about Constellation Plot in Gnuradio. My
> system is
> > based on BPSK so on Constellation Plot I am expecting only the +1, -1
> > values. The IQ samples are showing me that this is correct +1,-1
> so why
> > on the plot i have the values (-0.7,-0.7),(0.7,0.7) (img Tx_snr_run) ?
> > Why Constellation Plot is shifting my values?
> 
> Use the scope sink in XY mode, not the constellation plot. That'll try
> and actually rx.
> 
> > 4. Last question is about the MPSK SNR Estimator. I am wondering is
> > there a possibility to appl

Re: [Discuss-gnuradio] New GRC behavior request for comment

[Koslowski, Sebastian (CEL)]

Same here. Thanks for reporting. I pushed a fix to the GRCWG repo,
should make it into the mainline soon.

Sebastian

On 04/11/2014 04:27 AM, Dan CaJacob wrote:
> I think this change might be breaking a few things.  If anyone else can
> check, please let me know if I'm nuts:
> 
> I am running v3.7.4git-95-g24191d86 on Ubuntu 13.10 x64.  In GRC, when I
> try to change the type associated with a block via the select box, it
> changes (and the text turns blue), but when I close the parameter
> window, nothing actually changes.  I also saw similar behavior with
> combo boxes.  In that case, selecting an option did not take, but
> overwriting it did.
> 
> Very Respectfully,
> 
> Dan CaJacob
> 
> 
> On Thu, Apr 10, 2014 at 7:00 PM, Marcus D. Leech  > wrote:
> 
> On 04/10/2014 04:13 PM, Ed Criscuolo wrote:
> 
> 
> 
> How hard would it be to pop up a bother box if you attempt
> to enter with outstanding parameter error(s).  Give you
> a chance to confirm or cancel the enter, because you may want to
> deliberately enter something that's wrong now but will be
> fixed later (for instance a variable name that you haven't
> created yet).
> 
> I certainly like the "evaluate when you leave the box" paradigm, but
> I'm also the kind of developer who will enter a variable name, etc, that
>   hasn't actually been created yet.
> 
> -- 
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
> 
> 
> 
> _
> 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
> 

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Sebastian Koslowski
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe, Germany

Phone: +49 721 608-46275
Fax:   +49 721 608-46071
Email: sebastian.koslow...@kit.edu
Web:   http://www.cel.kit.edu/

KIT – University of the State of Baden-Wuerttemberg and National
Research Center of the Helmholtz Association



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio