Re: [Discuss-gnuradio] Multiplying the inputs with a scalar/vector in my own block

[Pavan Yedavalli]

Hi Marcus,

After doing more analysis, it seems pretty clear that the signal keeps
coming down whenever U is printed out, though I'm not sure how to explain
the wrong multiplication aspect - perhaps the USRP is doing a multiply on
whatever samples it receives, which is fewer than what it needs to run the
process in full?

Anyway, I am reading on various mailing lists that my host CPU should be
powerful, which I believe it is (Intel® Core™ i7-4600U CPU @ 2.10GHz × 4),
but I'm not sure. I guess what are my options for eliminating these
underruns (and *hopefully* the multiplication error and fluctuation that
I'm seeing)? Thanks again for the help.

Also, it appears that the master clock rate on the USRP N210 is 100 MHz,
which is even higher than what I had at 30.72 MHz. I tried experimenting
with that value (bringing it down to as low as 1 Hz), but after 2 Us are
displayed at the beginning, it doesn't seem to transmit again. This is the
case for basically everything below 30.72 MHz. At the default 100 MHz, it
shows a stream of Ls. I'm guessing that adjusting this rate is probably not
the right approach.

Thanks.

On Wed, Jun 8, 2016 at 10:34 AM, Pavan Yedavalli 
wrote:

> Hi Marcus,
>
> Thanks for getting back to me. To address both things you mentioned:
>
> (1) Yes, that was a typo. One of them should have said in0; I made a
> mistake while copying over; the code was correct, however, and that
> behavior still existed.
>
> (2) This is interesting. I am seeing Us on the output basically every
> time. So, this means the block isn't fast enough to handle 30.72 million
> samples per second? Should I lower that sampling rate? And to what value?
> How do we know? And I guess what is the "correct" thing to see on the
> output? This is very likely my problem. Please keep me posted! Thanks.
>
> --
> Pavan
>



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

Re: [Discuss-gnuradio] B200/mini GPIO

[Santos Campos]

Hmm so I tried it out an realized my solution doesn't quite get me what I
needed.
By invoking uhd::device::sptr usrp = dummy_usrp->get_device() I put my usrp
pointer in the wrong namespace since I wanted access to set_gpio_attr(...)
Going to go think about this more

On Wed, Jun 8, 2016 at 2:06 PM, Santos Campos  wrote:

> Ah sorry, I meant to mention I'm writing it in c++ not python.
> Yes, I saw that get_device() returns a sptr. I think I had a poor choice
> of words.
> I was unclear on how to even pass the existing usrp into my oot module,
> BUT I think I have a better idea now.
>
> Would something this work?:
>   std::string args = "";
>   ...
>   uhd::usrp::multi_usrp::sptr dummy_usrp =
> uhd::usrp::multi_usrp::make(args); //okay to pass an empty string address?
>   uhd::device::sptr usrp = dummy_usrp->get_device(); //creates a
> shared pointer to a usrp device created in an earlier block (usrp source,
> etc..)
>   //reference usrp like normal
> This DID compile, but it'd be great to have reassurance from the gurus.
> I'm about to try it out as well.
> Although I'm a bit confused as to why I don't have to define get_device()
> since it's a virtual function. Did the layers of wrappers take care of it?
> (hopefully it's not embarrassingly obvious. My c++ fu is a little rusty)
>
> Y'all are awesome :),
> -Santos
>
> On Wed, Jun 8, 2016 at 12:12 PM, Martin Braun 
> wrote:
>
>> get_device() returns a shared pointer. Note this function is not exposed
>> in Python -- you need to pass the object into another C++ object, and
>> there call get_device().
>>
>> M
>>
>> On 06/08/2016 06:38 AM, Santos Campos wrote:
>> > Hi, Martin!
>> > I tried taking a peek at how the usrp sink might handle a preceding usrp
>> > source (for inspiration).
>> > Does it (and the way you described) declare a usrp device and do some
>> > kind of shallow copy with the get_device() method?
>> >
>> > On Mon, Jun 6, 2016 at 5:54 PM, Martin Braun > > > wrote:
>> >
>> > Nah, you can just pass in the existing one into your module and
>> grab a
>> > reference to the multi_usrp from there.
>> >
>> > M
>> >
>> > On 06/03/2016 12:57 PM, Santos Campos wrote:
>> > > Hello again again!
>> > > So I'm trying to write an OOT module to control the gpio from GRC.
>> > > Would I have to create a usrp device in the module's code if I am
>> using
>> > > a usrp source?
>> > > My gut says to probably not re-declare it since it's already in
>> use, but
>> > > I'm not sure how I could bring it into scope if I don't have to
>> > > re-declare it.
>> > > I tried poking around for the usrp sink code to see what it did
>> but
>> > > couldn't find it.
>> > >
>> > > On Wed, Jun 1, 2016 at 11:45 AM, Santos Campos <
>> santo...@umich.edu 
>> > > >> wrote:
>> > >
>> > > Worked like a charm! Thanks for the helpful comments!
>> > > Like I said originally, I'm trying to use the gpio to remotely
>> > > switch between 2 antennas.
>> > > Currently trying to familiarize myself with boost and the uhd
>> api.
>> > > Will undoubtedly be back to the listserv with questions on
>> those.
>> > >
>> > >
>> > > On Wed, Jun 1, 2016 at 11:23 AM, Marcus D. Leech <
>> mle...@ripnet.com 
>> > > >> wrote:
>> > >
>> > > On 06/01/2016 10:23 AM, Santos Campos wrote:
>> > >> Hello again, all! I've finally come back to this after a
>> while.
>> > >> I'm trying to get the example code to compile but having
>> some
>> > >> trouble. Does anyone have any experience with using the
>> uhd
>> > >> gpio api?
>> > >> I tried using this to compile:
>> > >>
>> > >> $ gcc -I/usr/include/boost
>> > >> -I/home/santosec/uhd/host/include/uhd gpio.cpp -o gpio
>> > >>
>> > >> but I got a whole mess of compiler errors.
>> > >>
>> > >>
>> > > And, to follow-up with details:
>> > >
>> > > http://files.ettus.com/manual/page_build_guide.html
>> > >
>> > > Also:
>> > >
>> > > AN-445 and AN-204 from here:
>> > >
>> > > https://kb.ettus.com/Application_Notes
>> > >
>> > >
>> > >> On Wed, May 4, 2016 at 11:25 AM, Marcus D. Leech
>> > >> 
>> > >> wrote:
>> > >>
>> > >> On 05/04/2016 11:18 AM, Santos Campos wrote:
>> > >>> Hello! I am curious if it is possible to use a pin
>> or
>> > >>> something on either the B200 or B200 mini to send 

Re: [Discuss-gnuradio] Using USRP Clock for Timers

[Marcus Müller]

Hi Devin,

this won't work out for the simple reason that timed commands happen in
the FPGA on the USRP, and C++ happens in your PC, and the coupling
between both is loose at best – there's always some random latency bus
(network, USB,…) between the USRP and the host, and hence, these two
clocks never agree on how fast time progresses, or how late it actually is.

Now, in my experience, things like these work out if one approaches them
differently; could you hence explain what you need to be called, and why
that has to happen at a specific "radio time" (as opposed to "CPU time")?

Best regards,
Marcus

On 08.06.2016 22:22, devin kelly wrote:
> Hello,
>
> For my applications the MAC layer of my waveform requires me to
> implement a few timers (e.g. for slot and frame times, etc).
>
> What I'd like to do is exclusively use the USRP clock for these
> timers.  I've tried mixing the system clock and the USRP clock before
> (see a few messages on this list from a few months ago) and I couldn't
> get the accuracy I needed.
>
> Is there any way to setup a callback using the USRP clock. Sort of
> like a UHD timed_command except instead of changing the gain,
> frequency, etc. I want to call some C++ function.
>
> Also, I think I could try to sync my PC clock with the USRP clock but
> it seems using "Unknown PPS" or "Don't Sync" are usually recommended
> but I don't understand why.
>
> Thanks,
> Devin
>
>
> ___
> 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] Using USRP Clock for Timers

[devin kelly]

Hello,

For my applications the MAC layer of my waveform requires me to implement a
few timers (e.g. for slot and frame times, etc).

What I'd like to do is exclusively use the USRP clock for these timers.
I've tried mixing the system clock and the USRP clock before (see a few
messages on this list from a few months ago) and I couldn't get the
accuracy I needed.

Is there any way to setup a callback using the USRP clock. Sort of like a
UHD timed_command except instead of changing the gain, frequency, etc. I
want to call some C++ function.

Also, I think I could try to sync my PC clock with the USRP clock but it
seems using "Unknown PPS" or "Don't Sync" are usually recommended but I
don't understand why.

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

Re: [Discuss-gnuradio] Runnig GNU Radio in Windows

[Marcus Müller]

Hi Marcin,

uh-oh.

So two things:
I've reworked the gr-prefs system lately, because it was broken (no only
under windows) wildly. I don't think this is part of the 3.7.9.2 maint
version yet. Would you share the output of "gnuradio-config-info --version"?

Then:
You seem to have found a bug in our build system, of which I'm pretty
sure I didn't address :( So, even if my code inhibts that crash (which
would be lucky, because I don't know whether "checking if that directory
exists before accessing it", which is what my code does, checks for the
path being sensible at all or the Z: drive being available etc), this is
still a bug that I'll have to address.

So: yes, your installation is broken. Sorry. I don't know whether any
hacks will fix it –  I don't have a windows system to test right now.
But for the heck of it, you could try "faking" a drive Z: … However one
does that. Maybe by adding a mounted network share? Then at least the
program would just not find the directory, but not fail due to the drive
not being there. Windows is *weird*, to me.

Best regards,
Marcus

On 08.06.2016 14:54, Marcin wrote:
> Hi,
>
> I've installed GNURadio 3.7.9.2 Win64 Binaries from
> http://www.gcndevelopment.com/gnuradio/downloads.htm using full
> Windows Installer.
>
> On the first run I can only read:
>
> setting gnuradio environment
> Traceback (most recent call last):
>   File "gnuradio-companion.py", line 130, in 
> main()
>   File "gnuradio-companion.py", line 98, in main
> check_gnuradio_import()
>   File "gnuradio-companion.py", line 79, in check_gnuradio_import
> from gnuradio import gr
>   File "D:\Programy\GNURadio\lib\site-packages\gnuradio\gr\__init__.py", line 
> 53, in 
> log.set_level(prefs().get_string("LOG", "log_level", "notset"))
>   File "D:\Programy\GNURadio\lib\site-packages\gnuradio\gr\runtime_swig.py", 
> line 4678, in singleton
> return _runtime_swig.prefs_singleton()
> RuntimeError: boost::filesystem::status: Wolumin nie zawiera rozpoznawanego 
> systemu plików.
> Sprawdź, czy załadowano wszystkie wymagane sterowniki systemu plików i czy 
> wolumin nie jest uszkodzony: 
> "Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d"
>
> I work on Windows 7 x64 PL so the part of the above message is in
> Polish. I don't know how this message sounds exactly in English, but
> the translation is:
>
> "The volume does not contain a recognizable file system.
> "Check that you have loaded all required file system drivers and the
> volume is not corrupt:"
>
> ---
>
> I found something similar in the discuss-gnuradio group:
>
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-05/msg00123.html
>
> But I still don't know how to repair it in my installation. The
> command:
>
> gnuradio-config-info --prefsdir --sysconfdir
>
> returns:
>
> Z:gr-buildsrc-stage3staged_installReleaseetc
> Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
>


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

Re: [Discuss-gnuradio] Multiplying the inputs with a scalar/vector in my own block

[Marcus Müller]

Hi Pavan,

> I am seeing Us on the output basically every time.
That means the USRP ran out of samples to transmit when they were due to
be transmitted!
> So, this means the block isn't fast enough to handle 30.72 million
> samples per second? 
It seems like it, yes.
> Should I lower that sampling rate? And to what value? How do we know?
Well, usually, sampling rate is a demand of your application that you
need to meet, not the other way around.
You'd know you've reduced the sampling rate enough as soon as you stop
seeing "U"s. You could approach this problem with benchmarking, but to
be honest: just a bit of trial and error will get you there faster.
> And I guess what is the "correct" thing to see on the output? This is
> very likely my problem.
Well, multiplication with 1 really is a no-op, so you should be seeing
your normal spectrum. However, the repeated underruns mean that there's
discontinuities in your signal, which inherently have high bandwidth.
So, I'd expect that as soon as we fix the "U" issue, your signal would
be fine.

So, Python blocks are really not what I'd recommend at high rates. The
Python handling overhead is substantial.
Try implementing things in C++ blocks; that should give you a solid
boost. Ideally, you'd do things like multiplications and additions with
VOLK kernels [1], but don't optimize too early, and just write readable
C++ first.

Best regards,
Marcus

[1] http://libvolk.org

On 08.06.2016 19:34, Pavan Yedavalli wrote:
> Hi Marcus,
>
> Thanks for getting back to me. To address both things you mentioned:
>
> (1) Yes, that was a typo. One of them should have said in0; I made a
> mistake while copying over; the code was correct, however, and that
> behavior still existed.
>
> (2) This is interesting. I am seeing Us on the output basically every
> time. So, this means the block isn't fast enough to handle 30.72
> million samples per second? Should I lower that sampling rate? And to
> what value? How do we know? And I guess what is the "correct" thing to
> see on the output? This is very likely my problem. Please keep me
> posted! Thanks.
>
> -- 
> Pavan
>
>
> ___
> 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] B200/mini GPIO

[Santos Campos]

Ah sorry, I meant to mention I'm writing it in c++ not python.
Yes, I saw that get_device() returns a sptr. I think I had a poor choice of
words.
I was unclear on how to even pass the existing usrp into my oot module, BUT
I think I have a better idea now.

Would something this work?:
  std::string args = "";
  ...
  uhd::usrp::multi_usrp::sptr dummy_usrp =
uhd::usrp::multi_usrp::make(args); //okay to pass an empty string address?
  uhd::device::sptr usrp = dummy_usrp->get_device(); //creates a shared
pointer to a usrp device created in an earlier block (usrp source, etc..)
  //reference usrp like normal
This DID compile, but it'd be great to have reassurance from the gurus. I'm
about to try it out as well.
Although I'm a bit confused as to why I don't have to define get_device()
since it's a virtual function. Did the layers of wrappers take care of it?
(hopefully it's not embarrassingly obvious. My c++ fu is a little rusty)

Y'all are awesome :),
-Santos

On Wed, Jun 8, 2016 at 12:12 PM, Martin Braun 
wrote:

> get_device() returns a shared pointer. Note this function is not exposed
> in Python -- you need to pass the object into another C++ object, and
> there call get_device().
>
> M
>
> On 06/08/2016 06:38 AM, Santos Campos wrote:
> > Hi, Martin!
> > I tried taking a peek at how the usrp sink might handle a preceding usrp
> > source (for inspiration).
> > Does it (and the way you described) declare a usrp device and do some
> > kind of shallow copy with the get_device() method?
> >
> > On Mon, Jun 6, 2016 at 5:54 PM, Martin Braun  > > wrote:
> >
> > Nah, you can just pass in the existing one into your module and grab
> a
> > reference to the multi_usrp from there.
> >
> > M
> >
> > On 06/03/2016 12:57 PM, Santos Campos wrote:
> > > Hello again again!
> > > So I'm trying to write an OOT module to control the gpio from GRC.
> > > Would I have to create a usrp device in the module's code if I am
> using
> > > a usrp source?
> > > My gut says to probably not re-declare it since it's already in
> use, but
> > > I'm not sure how I could bring it into scope if I don't have to
> > > re-declare it.
> > > I tried poking around for the usrp sink code to see what it did but
> > > couldn't find it.
> > >
> > > On Wed, Jun 1, 2016 at 11:45 AM, Santos Campos  
> > > >> wrote:
> > >
> > > Worked like a charm! Thanks for the helpful comments!
> > > Like I said originally, I'm trying to use the gpio to remotely
> > > switch between 2 antennas.
> > > Currently trying to familiarize myself with boost and the uhd
> api.
> > > Will undoubtedly be back to the listserv with questions on
> those.
> > >
> > >
> > > On Wed, Jun 1, 2016 at 11:23 AM, Marcus D. Leech <
> mle...@ripnet.com 
> > > >> wrote:
> > >
> > > On 06/01/2016 10:23 AM, Santos Campos wrote:
> > >> Hello again, all! I've finally come back to this after a
> while.
> > >> I'm trying to get the example code to compile but having
> some
> > >> trouble. Does anyone have any experience with using the
> uhd
> > >> gpio api?
> > >> I tried using this to compile:
> > >>
> > >> $ gcc -I/usr/include/boost
> > >> -I/home/santosec/uhd/host/include/uhd gpio.cpp -o gpio
> > >>
> > >> but I got a whole mess of compiler errors.
> > >>
> > >>
> > > And, to follow-up with details:
> > >
> > > http://files.ettus.com/manual/page_build_guide.html
> > >
> > > Also:
> > >
> > > AN-445 and AN-204 from here:
> > >
> > > https://kb.ettus.com/Application_Notes
> > >
> > >
> > >> On Wed, May 4, 2016 at 11:25 AM, Marcus D. Leech
> > >> 
> > >> wrote:
> > >>
> > >> On 05/04/2016 11:18 AM, Santos Campos wrote:
> > >>> Hello! I am curious if it is possible to use a pin or
> > >>> something on either the B200 or B200 mini to send a
> > >>> control signal.
> > >>>
> > >>> We were hoping to be able to switch between 2
> antennas if
> > >>> the board received some signal. It looks like there
> could
> > >>> be some available pins, but we were unsure if they
> would
> > >>> be able to fulfill our purpose. If not, any ideas
> around
> > >>> this issue would be welcome!
> > >>>
> > >>> Any help 

Re: [Discuss-gnuradio] Multiplying the inputs with a scalar/vector in my own block

[Pavan Yedavalli]

Hi Marcus,

Thanks for getting back to me. To address both things you mentioned:

(1) Yes, that was a typo. One of them should have said in0; I made a
mistake while copying over; the code was correct, however, and that
behavior still existed.

(2) This is interesting. I am seeing Us on the output basically every time.
So, this means the block isn't fast enough to handle 30.72 million samples
per second? Should I lower that sampling rate? And to what value? How do we
know? And I guess what is the "correct" thing to see on the output? This is
very likely my problem. Please keep me posted! Thanks.

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

[Discuss-gnuradio] gnuradio hdmi

[Raj Bhattacharjea]

The same flow graph and the same SDR hardware with the same settings and
same drivers should produce the same results (if samples are not being
dropped by the host computer or something else). That said, I've seen weird
things like this pop up due to variations in the driver versions for the
hardware between an embedded and desktop device.

To figure out what's going on specifically, we'd have to see your flowgraph
here to see if people can help. Also, providing GNU Radio version numbers
and how you installed from source (git master some day in the past, git
release tag checkout, release tarball, etc.) on both the Odroid and the
netbook would help. Also maybe provide a link the the Odroid Forum
discussion for some context?

-- 
Raj Bhattacharjea, PhD
Georgia Tech Research Institute
Information and Communications Laboratory
http://www.prism.gatech.edu/~rb288/
404.407.6622
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] B200/mini GPIO

[Martin Braun]

get_device() returns a shared pointer. Note this function is not exposed
in Python -- you need to pass the object into another C++ object, and
there call get_device().

M

On 06/08/2016 06:38 AM, Santos Campos wrote:
> Hi, Martin!
> I tried taking a peek at how the usrp sink might handle a preceding usrp
> source (for inspiration). 
> Does it (and the way you described) declare a usrp device and do some
> kind of shallow copy with the get_device() method?
> 
> On Mon, Jun 6, 2016 at 5:54 PM, Martin Braun  > wrote:
> 
> Nah, you can just pass in the existing one into your module and grab a
> reference to the multi_usrp from there.
> 
> M
> 
> On 06/03/2016 12:57 PM, Santos Campos wrote:
> > Hello again again!
> > So I'm trying to write an OOT module to control the gpio from GRC.
> > Would I have to create a usrp device in the module's code if I am using
> > a usrp source?
> > My gut says to probably not re-declare it since it's already in use, but
> > I'm not sure how I could bring it into scope if I don't have to
> > re-declare it.
> > I tried poking around for the usrp sink code to see what it did but
> > couldn't find it.
> >
> > On Wed, Jun 1, 2016 at 11:45 AM, Santos Campos  
> > >> wrote:
> >
> > Worked like a charm! Thanks for the helpful comments!
> > Like I said originally, I'm trying to use the gpio to remotely
> > switch between 2 antennas.
> > Currently trying to familiarize myself with boost and the uhd api.
> > Will undoubtedly be back to the listserv with questions on those.
> >
> >
> > On Wed, Jun 1, 2016 at 11:23 AM, Marcus D. Leech  
> > >> wrote:
> >
> > On 06/01/2016 10:23 AM, Santos Campos wrote:
> >> Hello again, all! I've finally come back to this after a while.
> >> I'm trying to get the example code to compile but having some
> >> trouble. Does anyone have any experience with using the uhd
> >> gpio api?
> >> I tried using this to compile:
> >>
> >> $ gcc -I/usr/include/boost
> >> -I/home/santosec/uhd/host/include/uhd gpio.cpp -o gpio
> >>
> >> but I got a whole mess of compiler errors.
> >>
> >>
> > And, to follow-up with details:
> >
> > http://files.ettus.com/manual/page_build_guide.html
> >
> > Also:
> >
> > AN-445 and AN-204 from here:
> >
> > https://kb.ettus.com/Application_Notes
> >
> >
> >> On Wed, May 4, 2016 at 11:25 AM, Marcus D. Leech
> >> 
> >> wrote:
> >>
> >> On 05/04/2016 11:18 AM, Santos Campos wrote:
> >>> Hello! I am curious if it is possible to use a pin or
> >>> something on either the B200 or B200 mini to send a
> >>> control signal.
> >>>
> >>> We were hoping to be able to switch between 2 antennas if
> >>> the board received some signal. It looks like there could
> >>> be some available pins, but we were unsure if they would
> >>> be able to fulfill our purpose. If not, any ideas around
> >>> this issue would be welcome!
> >>>
> >>> Any help would be much appreciated!
> >>>
> >>>
> >>> ___
> >>> Discuss-gnuradio mailing list
> >>> Discuss-gnuradio@gnu.org
>   >
> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >> The API for the B2xx GPIO is the same as for X3xx.
> >>
> >> There's example code:
> >>
> >> .../uhd/examples/gpio.cpp
> >>
> >>
> >>
> >> ___
> >> 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] Need help with calculation of channel impulse response

[Rush]

Hi @all.

Maybe I should introduce my project first: I want to make a flowgraph that
prints the channel impulse response of an OFDM(DAB) ensemble on a Scope
Sink.

CIR = IFFT {Received PRS x PRS*}

What I have done is:
1. wrote a matlab script that generates a binary file with samples of the
phase reference symbol described in
http://www.etsi.org/deliver/etsi_en/300400_300499/300401/01.04.01_40/en_300401v010401o.pdf
page 147

2. made a FlowGraph that takes the samples from the file and does the
calculation described above. For testing purposes I made CIR = IFFT {PRS x
PRS*}. My supposition was, that I will get a signal of 0 because the
multiplication eleminiates it. But there is one high and zwo smaller peaks
on the right and left.

3. The sample file contains 1536 float samples, one for each carrier
frequency. So, if I put all these samples into one Vector, does the FFT,
multiplication and IFFT my Scope Sink should print a line at 0 right ?
The same but with a real received phase reference symbol should generate one
single peak when there is no phase difference. Or am I wrong?

What am I doing wrong. Why don't I get a constant 0 signal at the Scope? And
how to calculate the time axis on the scope that it does not "roll"?

prs_float_ReIm.bin is the sample file of the PRS. first 4 bytes -> real
part; next 4 bytes -> imaginary part and so on

prs_mal_prs.grc
  
prs_float_ReIm.bin
  




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Need-help-with-calculation-of-channel-impulse-response-tp60375.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] Runnig GNU Radio in Windows

[Marcin]

Hi,

I've installed GNURadio 3.7.9.2 Win64 Binaries from
http://www.gcndevelopment.com/gnuradio/downloads.htm using full
Windows Installer.

On the first run I can only read:

setting gnuradio environment
Traceback (most recent call last):
  File "gnuradio-companion.py", line 130, in 
main()
  File "gnuradio-companion.py", line 98, in main
check_gnuradio_import()
  File "gnuradio-companion.py", line 79, in check_gnuradio_import
from gnuradio import gr
  File "D:\Programy\GNURadio\lib\site-packages\gnuradio\gr\__init__.py", line 
53, in 
log.set_level(prefs().get_string("LOG", "log_level", "notset"))
  File "D:\Programy\GNURadio\lib\site-packages\gnuradio\gr\runtime_swig.py", 
line 4678, in singleton
return _runtime_swig.prefs_singleton()
RuntimeError: boost::filesystem::status: Wolumin nie zawiera rozpoznawanego 
systemu plików.
Sprawdź, czy załadowano wszystkie wymagane sterowniki systemu plików i czy 
wolumin nie jest uszkodzony: 
"Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d"

I work on Windows 7 x64 PL so the part of the above message is in
Polish. I don't know how this message sounds exactly in English, but
the translation is:

"The volume does not contain a recognizable file system.
"Check that you have loaded all required file system drivers and the
volume is not corrupt:"

---

I found something similar in the discuss-gnuradio group:

https://lists.gnu.org/archive/html/discuss-gnuradio/2016-05/msg00123.html

But I still don't know how to repair it in my installation. The
command:

gnuradio-config-info --prefsdir --sysconfdir

returns:

Z:gr-buildsrc-stage3staged_installReleaseetc
Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d

-- 
Pozdrowienia,
 Marcin Kucharczyk


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

[Discuss-gnuradio] OOT idea

[Gregory W. Ratcliff]

I was reminded about some of Michael Ossmann's work with yardstick one: Great 
Scott Gadgets - YARD Stick One
|   |
|   |  |   |   |   |   |   |
| Great Scott Gadgets - YARD Stick OneYARD Stick One YARD Stick One is a sub-1 
GHz wireless test tool controlled by your computer. YARD Stick One is available 
from: Hacker Warehouse (US) HakShop (U... |
|  |
| View on greatscottgadgets.com | Preview by Yahoo |
|  |
|   |


Has anyone considered creating an RFCAT "in a module" (for RTL or HackRFone)? 
Gregory W. Ratcliff




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

Re: [Discuss-gnuradio] B200/mini GPIO

[Santos Campos]

Hi, Martin!
I tried taking a peek at how the usrp sink might handle a preceding usrp
source (for inspiration).
Does it (and the way you described) declare a usrp device and do some kind
of shallow copy with the get_device() method?

On Mon, Jun 6, 2016 at 5:54 PM, Martin Braun  wrote:

> Nah, you can just pass in the existing one into your module and grab a
> reference to the multi_usrp from there.
>
> M
>
> On 06/03/2016 12:57 PM, Santos Campos wrote:
> > Hello again again!
> > So I'm trying to write an OOT module to control the gpio from GRC.
> > Would I have to create a usrp device in the module's code if I am using
> > a usrp source?
> > My gut says to probably not re-declare it since it's already in use, but
> > I'm not sure how I could bring it into scope if I don't have to
> > re-declare it.
> > I tried poking around for the usrp sink code to see what it did but
> > couldn't find it.
> >
> > On Wed, Jun 1, 2016 at 11:45 AM, Santos Campos  > > wrote:
> >
> > Worked like a charm! Thanks for the helpful comments!
> > Like I said originally, I'm trying to use the gpio to remotely
> > switch between 2 antennas.
> > Currently trying to familiarize myself with boost and the uhd api.
> > Will undoubtedly be back to the listserv with questions on those.
> >
> >
> > On Wed, Jun 1, 2016 at 11:23 AM, Marcus D. Leech  > > wrote:
> >
> > On 06/01/2016 10:23 AM, Santos Campos wrote:
> >> Hello again, all! I've finally come back to this after a while.
> >> I'm trying to get the example code to compile but having some
> >> trouble. Does anyone have any experience with using the uhd
> >> gpio api?
> >> I tried using this to compile:
> >>
> >> $ gcc -I/usr/include/boost
> >> -I/home/santosec/uhd/host/include/uhd gpio.cpp -o gpio
> >>
> >> but I got a whole mess of compiler errors.
> >>
> >>
> > And, to follow-up with details:
> >
> > http://files.ettus.com/manual/page_build_guide.html
> >
> > Also:
> >
> > AN-445 and AN-204 from here:
> >
> > https://kb.ettus.com/Application_Notes
> >
> >
> >> On Wed, May 4, 2016 at 11:25 AM, Marcus D. Leech
> >> > wrote:
> >>
> >> On 05/04/2016 11:18 AM, Santos Campos wrote:
> >>> Hello! I am curious if it is possible to use a pin or
> >>> something on either the B200 or B200 mini to send a
> >>> control signal.
> >>>
> >>> We were hoping to be able to switch between 2 antennas if
> >>> the board received some signal. It looks like there could
> >>> be some available pins, but we were unsure if they would
> >>> be able to fulfill our purpose. If not, any ideas around
> >>> this issue would be welcome!
> >>>
> >>> Any help would be much appreciated!
> >>>
> >>>
> >>> ___
> >>> Discuss-gnuradio mailing list
> >>> Discuss-gnuradio@gnu.org 
> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >> The API for the B2xx GPIO is the same as for X3xx.
> >>
> >> There's example code:
> >>
> >> .../uhd/examples/gpio.cpp
> >>
> >>
> >>
> >> ___
> >> 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

[Discuss-gnuradio] CPFSK mod/demod + strange behavior

[Olivier Goyette]

Hello dear community !

I'm actually trying to develop an application with GRC that does CPFSK
mod/demod but I haven't got some satisfying results yet and I hope you will
be able to get me back in the right way.

The flowgraph i've made (
https://www.dropbox.com/s/6vuyleerbwl3df2/UAT.png?dl=0) is based upon the
many forums (Gnu radio, stack overflow etc ) i've visited during the last 3
weeks. The blocks i've integrated are those who came back often in the
discussions i've read and as far as i've been able to understand the
theory, I think they are really necessary. You'll see that i'm using
reed-solomon blocks, but i'm pretty sure they are no problem cuz i've
tested them and they work :).

Now, I have many concerns and I will try to make them as clear as possible.
For your information, let me show you what are my parameters :

sample_rate : 6.25M
baud_rate : 1.041667M
sample_per_symbols : 6
fsk_deviation_hz : 312.5K
center_freq : 978 MHz

1st concern : when I enable the rational resampler with Interpolation set
to : baud_rate and Decimation set to : sample_rate, GRC seems to not
execute the flowgraph at all as if the calculations were too big ?! Since
*sample_rate* / *baud_rate* = *sample_per_symbol*s, I tried to put
Interpolation to 1 and Decimation to 6, but GRC freezes for about a minute
after execution of the flowgraph. So, what should I do to keep my
parameters valid if I really need to use a rational resampler block?

2nd concern : If you look at the other picture I included (
https://www.dropbox.com/s/0lw4o0941kodj0o/20160607_144649.jpg?dl=0), it's
the actual output of the CPFSK mod block that I captured on an
oscilloscope. From what I've understand about FSK is that we should be
seeing a change in frequency whether it's a binary '1' or a binary '0'
we're transmitting. From what we see, it looks a lot more like an Amplitude
Modulation or something like that. Do someone has an explanation about
that? Have you ever look at CPFSK with an oscilloscope ? Have you seen the
same thing ? In this application, the fsk_deviation_hz shall be +312.5K for
a '1' and -312.5K for a '0'. How may I be sure to respect this
specification by using the CPFSK block ?

3rd concern : On every forum I've been, people have been using a "Frequency
Xlating FIR filter" on Rx side. What is it used for ? I don't understand
why we need to use this block. I must admit that Rx side is a bit of
mystery for me right now as I've been working with GRC for only 4-5 weeks
up until now. The other aspect of this block that confuses me is the filter
taps we need to specify. I've specified a low pass filter tap for this
block, but i'm not sure what parameters do I need to put in it and if I
really need a "low-pass" tap?!

4th concern : Same as #3 but for the polyphase clock sync. I've understand
with my readings that on the receiver side we need something to "lock-on"
the carrier and that's why people have been using this block. The thing is
that I don't understand any of the parameters we need to set except for
samples/symbols hehe :). Again, I've seen people using Root Raised Cosine
taps for this block, but what parameters would I need to set in order to
fit with my application ?

5th concern : Should the sample_rate on Rx side be twice the sample_rate on
Tx ? If I have 6.25M on Tx should I set it to 12.5M on Tx?

Thank you for your time and your support.

Olivier

P.S : I'll leave my personal e-mail address if someone would like to stay
in touch and help me with it. It's sometime simpler than posting directly
on the forum

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

Re: [Discuss-gnuradio] USRP Spectrum Sensing - Power in dB or dBm??

[Marcus Müller]

Hi Ingen,

On 08.06.2016 07:58, ingen wrote:
> I'm a beginner working in Spectrum Sensing. I have been checking the
> code given in the /usrp_spectrum_sense.py/ file in GNU Radio.
> (https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/examples/python/usrp_spectrum_sense.py)
>
> The power calculated (at line 303) is in dB as given below :
>
> /power_db = 10*math.log10(m.data[i_bin]/tb.usrp_rate) - noise_floor_db/
>
> My query is whether the power calculated in dB is in reference to 1
> Watt??
No, it is not! It is dB relative to a digital 1.
> Can we convert this power to dBm??
Only if you calibrate your receiver externally. The USRPs are not
calibrated measurement devices, so the digital 1 (read: full ADC output)
maps to different powers depending on individual device, frequency,
bandwidth, …
Hence, there's no other solution than to take a source of known power
and calculate the digital power of what you observe.
Do a couple of measurement points with different powers. The USRPs are
typically pretty linear, but every linear region has its limits.
Also, be sure to never feed more than -15dBm into the antenna ports of a
USRP – you risk irreparable damages.
> What parameters are needed to be
> checked or tuned in this program??
None, as far as I know. Calibration has to be done by you
> Also, how can we calculate the Power Spectral Density (PSD) from power
> in dB with reference to given frequency??
Strictly mathematically speaking: not at all. You might estimate the
PSD, but you cannot measure it this way. Technically speaking: You've
got something that pretty much looks like a density of how power is
distributed; is that maybe already what you're looking for?

Either you stick with a very "technical" definition of PSD being just
what power you can observe in small bandwidths, or you go with the
scientific notion that PSD is the expectation value of the magnitude
square of the Fourier transform of your signal – and as that, it is a
random entity and can only be estimated from observation, not directly
observed. I've wrote a short paragraph on that in [1]; see under where I
cite "is my understanding of PSD wrong?".

Assuming this is some kind of thesis, from own experience I can say that
it's probably worth getting a very precise, well-worded theory chapter
written down. That will always make it easier for you to refer to the
theory beneath when you're working on the implementation – I'm pretty
sure running a ready-to-use script to give you a few numbers per
frequency is not the whole scope of your work :)

Best regards,
Marcus

[1] http://dsp.stackexchange.com/a/31336/13320
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/USRP-Spectrum-Sensing-Power-in-dB-or-dBm-tp60372.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

[Discuss-gnuradio] USRP Spectrum Sensing - Power in dB or dBm??

[ingen]

I'm a beginner working in Spectrum Sensing. I have been checking the
code given in the /usrp_spectrum_sense.py/ file in GNU Radio.
(https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/examples/python/usrp_spectrum_sense.py)

The power calculated (at line 303) is in dB as given below :

/power_db = 10*math.log10(m.data[i_bin]/tb.usrp_rate) - noise_floor_db/

My query is whether the power calculated in dB is in reference to 1
Watt??
Can we convert this power to dBm?? What parameters are needed to be
checked or tuned in this program??

Also, how can we calculate the Power Spectral Density (PSD) from power
in dB with reference to given frequency??



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/USRP-Spectrum-Sensing-Power-in-dB-or-dBm-tp60372.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