[Discuss-gnuradio] GRC: UHD USRP Source Block (complex - short)

[luca cucchi]

Hi everybody,
Very simple issue...
I'm using GRC in order to save signal from N210 + WBX.
No problems when I set the Output Type as "Complex" in the UHD:USRP Source
block. The signal is properly saved as Complex float32.
..I'm a bit confused when I select "Short" as Output Type of the Source.
I expect the signal as complex int16 but it seems to me that GRC doesn't
support this scenario...

Any suggestions ? 

thanks
Luca

-- 
View this message in context: 
http://old.nabble.com/GRC%3A-UHD-USRP-Source-Block-%28complex---short%29-tp32771906p32771906.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] gmsk on GRC

[ahmad]

Hi all
I am new on working with GRC. I am researching on gmsk modulators.I could not
make a proper GRC model or example. anybody has a working example?
thanks all
Ahmad


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

Re: [Discuss-gnuradio] gmsk on GRC

[Marcus Müller]

Hi Ahmad,

please consider the amount of blocks coming with your gnuradio 
installation, usually found in your gnuradio directory,

somewhere like gnuradio/grc/blocks/*.xml
I'd also like to point you to the gnuradio.org wiki, specifically the 
GNURadioCompanion page, which the front page links to, containing 
precise instructions and information on the GRC.


Sincerly
M Müller

Am 03.11.2011 14:14, schrieb ahmad:

Hi all
I am new on working with GRC. I am researching on gmsk modulators.I could not
make a proper GRC model or example. anybody has a working example?
thanks all
Ahmad


___
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] gmsk on GRC

[Ed Criscuolo]

Have a look at the GMSK Spacecraft Groundstation Project
on CGRAN:

https://cgran.org/wiki/GMSKSpacecraftGroundstation

@(^.^)@  Ed


On 11/3/11 9:14 AM, ahmad wrote:

Hi all
I am new on working with GRC. I am researching on gmsk modulators.I could not
make a proper GRC model or example. anybody has a working example?
thanks all
Ahmad


___
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] UMTS scanner

[Miguel Sanz]

Hi!
I am trying to implement an UMTS uplink scanner with GRC. My purpose is to
detect the activity of channels by sensing the spectrum and comparing the
measured power against a certain threshold. The blocks that I am using are:
uhd_usrp_source--->root raised cosine filter---power
squelch--rmslog10---filesink

So far I am just attempting to calculate rssi values on a specific channel,
and save them into a file using the above chain. but the file that is
created after the whole chain is unreadable in Matlab or Octave.

There must be something wrong in the chain of blocks, but I cannot see it.
Any comments are welcome!

Br,

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

Re: [Discuss-gnuradio] UMTS scanner

[Marcus D. Leech]

On 03/11/2011 9:59 AM, Miguel Sanz wrote:

Hi!
I am trying to implement an UMTS uplink scanner with GRC. My purpose 
is to detect the activity of channels by sensing the spectrum and 
comparing the measured power against a certain threshold. The blocks 
that I am using are:
uhd_usrp_source--->root raised cosine filter---power 
squelch--rmslog10---filesink


So far I am just attempting to calculate rssi values on a specific 
channel, and save them into a file using the above chain. but the file 
that is created after the whole chain is unreadable in Matlab or Octave.


There must be something wrong in the chain of blocks, but I cannot see 
it. Any comments are welcome!


Br,

Miguel 
The files are stored in native complex-float format.  Someone posted a 
macro about a week ago on the list to deal with this for

  Matlab.





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

[Discuss-gnuradio] E100 Simultaneous Transmit and Receive

[Daniel Dekst]

Hi, All,

Can I make E100 transmit and receive simultaneously?
Basically, I want to receive what I'm transmitting.
I'm using XCVR2450 daughterboard.
Is there any example code?

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

Re: [Discuss-gnuradio] E100 Simultaneous Transmit and Receive

[Marcus D. Leech]

On 03/11/2011 10:12 AM, Daniel Dekst wrote:

Hi, All,

Can I make E100 transmit and receive simultaneously?
Basically, I want to receive what I'm transmitting.
I'm using XCVR2450 daughterboard.
Is there any example code?

Thanks,
dekst

The E100 should have no problem doing that.   The XCVR2450, however, is 
half-duplex only.  The hardware simply won't do full-duplex.




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

Re: [Discuss-gnuradio] E100 Simultaneous Transmit and Receive

[dekst]

Hi, Marcus,

If I use WBX, it will work?
How to start coding? Is there any example or similar code?

Thanks,
dekst



Marcus D. Leech wrote:
> 
> On 03/11/2011 10:12 AM, Daniel Dekst wrote:
>> Hi, All,
>>
>> Can I make E100 transmit and receive simultaneously?
>> Basically, I want to receive what I'm transmitting.
>> I'm using XCVR2450 daughterboard.
>> Is there any example code?
>>
>> Thanks,
>> dekst
>>
> The E100 should have no problem doing that.   The XCVR2450, however, is 
> half-duplex only.  The hardware simply won't do full-duplex.
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/E100-Simultaneous-Transmit-and-Receive-tp32773165p32773309.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] A wrong power adapter connected to USRP and now it doesn't work (LED doesn't blink)

[Marcus M]

My adviser accidentally plugged in a laptop's power adapter into a USRP for
a few seconds and now it doesn't respond and GNU Radio doesn't detect it
either after connecting to the laptop and testing it. What do I do? I hope
that there must be a fuse that is replaceable or some sort of mechanism to
prevent the USRP from being fried. Any help will be greatly appreciated.

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

Re: [Discuss-gnuradio] GRC: UHD USRP Source Block (complex - short)

[Josh Blum]

On 11/03/2011 03:57 AM, luca cucchi wrote:
> 
> Hi everybody,
> Very simple issue...
> I'm using GRC in order to save signal from N210 + WBX.
> No problems when I set the Output Type as "Complex" in the UHD:USRP Source
> block. The signal is properly saved as Complex float32.
> ..I'm a bit confused when I select "Short" as Output Type of the Source.
> I expect the signal as complex int16 but it seems to me that GRC doesn't
> support this scenario...
> 
> Any suggestions ? 
> 
> thanks
> Luca
> 

I have only recently added support in grc for all floating point and
integer types (real and complex). The USRP blocks have not been updated
to reflect this, meaning the output is still a vector of short (size 2).

However, in recent versions of grc, you can connect any inputs to any
outputs so long as their IO size matches. So, the type does not matter
in this case as much as the IO size does. So none of this should be an
issue.

When I get around to merging my uhd_next branch, the types will be
changed to sc16, which is the volk naming convention for signed complex
16bit integers.

-Josh

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

Re: [Discuss-gnuradio] A wrong power adapter connected to USRP and now it doesn't work (LED doesn't blink)

[Thomas Tsou]

On Thu, Nov 3, 2011 at 12:15 PM, Marcus M  wrote:
> My adviser accidentally plugged in a laptop's power adapter into a USRP for
> a few seconds and now it doesn't respond and GNU Radio doesn't detect it
> either after connecting to the laptop and testing it. What do I do? I hope
> that there must be a fuse that is replaceable or some sort of mechanism to
> prevent the USRP from being fried. Any help will be greatly appreciated.

Do the LED's work? If not, check the fuse on F501.

  Thomas

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

Re: [Discuss-gnuradio] gmsk on GRC

[Martin Braun]

Besides everything my pre-posters have said, there's a GMSK modulator
including GRC bindings in gr-digital. Which version are you using?

MB

On Thu, Nov 03, 2011 at 01:14:09PM +, ahmad wrote:
> Hi all
> I am new on working with GRC. I am researching on gmsk modulators.I could not
> make a proper GRC model or example. anybody has a working example?
> thanks all
> Ahmad
> 
> 
> ___
> 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. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association



pgpqOfcp4Cyyn.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] A wrong power adapter connected to USRP and now it doesn't work (LED doesn't blink)

[Marcus D. Leech]

On 03/11/2011 12:15 PM, Marcus M wrote:
My adviser accidentally plugged in a laptop's power adapter into a 
USRP for a few seconds and now it doesn't respond and GNU Radio 
doesn't detect it either after connecting to the laptop and testing 
it. What do I do? I hope that there must be a fuse that is replaceable 
or some sort of mechanism to prevent the USRP from being fried. Any 
help will be greatly appreciated.


Thanks,
John
For a USRP1, F501 will provide some protection.  Not guaranteed or 
anything, but some.  Check F501 for continuity.


For a USRP2, F101

For an N2XX, F101




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

Re: [Discuss-gnuradio] A wrong power adapter connected to USRP and now it doesn't work (LED doesn't blink)

[Philip Balister]

On 11/03/2011 12:15 PM, Marcus M wrote:
> My adviser accidentally plugged in a laptop's power adapter into a USRP for
> a few seconds and now it doesn't respond and GNU Radio doesn't detect it
> either after connecting to the laptop and testing it. What do I do? I hope
> that there must be a fuse that is replaceable or some sort of mechanism to
> prevent the USRP from being fried. Any help will be greatly appreciated.

In the future, be aware of your Advisor's Negation Field:

http://www.phdcomics.com/comics.php?f=821

Philip

> 
> Thanks,
> John
> 
> 
> 
> 
> ___
> 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] Interesting document

[Marcus D. Leech]

While this document isn't about Gnu Radio, it's a great introduction to 
many of the topics that are of interest on this list, along with

  code examples.

http://superb-dca2.dl.sourceforge.net/project/cutesdr/doc/CuteSDR101.pdf

I tripped over it and found it well written.




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

Re: [Discuss-gnuradio] gr_delay

[Johnathan Corgan]

On Wed, Nov 2, 2011 at 19:20, Marcus D. Leech  wrote:


> OK, so here's a new attemp, with dynamic selection of taps for the FIR
> filter.  It also appears to not work.  Only filter taps that exist on
>   startup are working properly.  Gulp.
>

Won't be able to look at this 'till the weekend.

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

Re: [Discuss-gnuradio] gr_delay

[Marcus D. Leech]

On 03/11/2011 2:44 PM, Johnathan Corgan wrote:
On Wed, Nov 2, 2011 at 19:20, Marcus D. Leech > wrote:


OK, so here's a new attemp, with dynamic selection of taps for the
FIR filter.  It also appears to not work.  Only filter taps that
exist on
  startup are working properly.  Gulp.


Won't be able to look at this 'till the weekend.

Johnathan

Fair enough.

I went through ./runtime  last night, and indeed d_history seems to 
only be "looked at" on initialization.  So, how are dynamically-changeable

  FIR filters working at all?  I await your weekendly wisdom.


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

[Discuss-gnuradio] make check errors in release candidate 3.5.0rc0

[Don Ward]

I have one or two errors in "make check" when building 3.5.0rc0 on Debian 
Linux (under VirtualBox on Windows XP):


(1) in gr-trellis:

make[7]: Entering directory 
`/home/don/gnuradio-3.5.0rc0/build-debian/gr-trellis/src/python'

Traceback (most recent call last):
 File "../../../../gr-trellis/src/python/qa_trellis.py", line 32, in 


   import digital_swig
ImportError: No module named digital_swig
FAIL: run_tests

It works ok if I add "export PYTHONPATH" after PYTHONPATH is set in
gr-trellis/src/python/run_tests.

(2) in gnuradio-core/src/python/gnuradio/gr:

Ran 6 tests in 0.466s

OK
gr_vmcircbuf_sysv_shm: shmat (5): Invalid argument
gr_buffer::allocate_buffer: failed to allocate buffer of size 64 KB
..
--
Ran 2 tests in 3.042s

OK
..
--
Ran 2 tests in 0.007s

OK
...
--
Ran 3 tests in 0.013s

OK
PASS: run_tests

It says "OK" and "PASS" despite the error messages.  Is this normal?

Thanks,

-- Don W.



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

[Discuss-gnuradio] Strange behavior in digital benchmark examples

[Tuan (Johnny) Ta]

Hello all,

I just came across a strange behavior in the digital benchmark examples
that I haven't seen before. The transmitter wouldn't stop itself after it
finishes sending the requested data size (specified by -M argument).
Keyboard interrupt (ctrl+C) has no effect. I had to stop it with ctrl+Z and
kill the job after.

This behavior starts when bitrate exceeds 1M.

If I ran benchmark_rx2.py then a short period after receiving all packets
(~30 sec), the receiver would continuously spill out "O" (overrun). This
didn't happen if I ran benchmark_rx.py. (I ran the corresponding tx code.)

I'm not sure what could be causing it. I was able to run digital benchmark
code on my older machine at 1.5Mbps prior to UHD (I used Ethernet driver)
so I'm sure CPU speed isn't a problem.

To make it work with UHD driver, I made some changes to the usrp_options.py
and generic_usrp.py.

I'm quite puzzled right now. I'd appreciate any insights!

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

[Discuss-gnuradio] gnuradio library linking error

[Marcus M]

Hi,
I have a test application that I want to link with the gnuradio library. I
user the proper link variables but I always get the error of the following
type.

fatal error: gr_complex.h: No such file or directory
compilation terminated.

In this test application I am using the gr_complex data type and I am
including the proper header variable. I checked my $PATH variable and it
includes the proper header directories and the library. I tried including
the whole path in #include but I still get the same error. What's happening
here?

I am compiling the application as
gcc -o test test.cc -lgnuradio-core

I even tried this but it throws the same error. Somehow it's unable to find
the header even thought the path are included in the $PATH variable.
gcc -o test test.cc `pkg-config --libs gnuradio-core`

Any help will be greatly appreciated.

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

Re: [Discuss-gnuradio] gnuradio library linking error

[Josh Blum]

On 11/03/2011 01:48 PM, Marcus M wrote:
> Hi,
> I have a test application that I want to link with the gnuradio library. I
> user the proper link variables but I always get the error of the following
> type.
> 
> fatal error: gr_complex.h: No such file or directory
> compilation terminated.
> 
> In this test application I am using the gr_complex data type and I am
> including the proper header variable. I checked my $PATH variable and it
> includes the proper header directories and the library. I tried including
> the whole path in #include but I still get the same error. What's happening
> here?
> 
> I am compiling the application as
> gcc -o test test.cc -lgnuradio-core
> 
> I even tried this but it throws the same error. Somehow it's unable to find
> the header even thought the path are included in the $PATH variable.
> gcc -o test test.cc `pkg-config --libs gnuradio-core`
> 
> Any help will be greatly appreciated.
> 
> Thanks
> 
> 

You are missing cflags, use pkg-config --cflags

the environment variable "PATH" is not related

-josh

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

Re: [Discuss-gnuradio] Strange behavior in digital benchmark examples

[Josh Blum]

On 11/03/2011 01:28 PM, Tuan (Johnny) Ta wrote:
> Hello all,
> 
> I just came across a strange behavior in the digital benchmark examples
> that I haven't seen before. The transmitter wouldn't stop itself after it
> finishes sending the requested data size (specified by -M argument).
> Keyboard interrupt (ctrl+C) has no effect. I had to stop it with ctrl+Z and
> kill the job after.
> 
> This behavior starts when bitrate exceeds 1M.
> 
> If I ran benchmark_rx2.py then a short period after receiving all packets
> (~30 sec), the receiver would continuously spill out "O" (overrun). This
> didn't happen if I ran benchmark_rx.py. (I ran the corresponding tx code.)
> 
> I'm not sure what could be causing it. I was able to run digital benchmark
> code on my older machine at 1.5Mbps prior to UHD (I used Ethernet driver)
> so I'm sure CPU speed isn't a problem.
> 
> To make it work with UHD driver, I made some changes to the usrp_options.py
> and generic_usrp.py.
> 

I believe that tom ported all of the gnuradio "classic" example
applications in 3.5 release. You may want to try those examples, because
I know that he has tested them recently.

I hope that helps,
-Josh

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

Re: [Discuss-gnuradio] gnuradio library linking error

[Marcus M]

On Thu, Nov 3, 2011 at 3:52 PM, Josh Blum  wrote:

>
>
> On 11/03/2011 01:48 PM, Marcus M wrote:
> > Hi,
> > I have a test application that I want to link with the gnuradio library.
> I
> > user the proper link variables but I always get the error of the
> following
> > type.
> >
> > fatal error: gr_complex.h: No such file or directory
> > compilation terminated.
> >
> > In this test application I am using the gr_complex data type and I am
> > including the proper header variable. I checked my $PATH variable and it
> > includes the proper header directories and the library. I tried including
> > the whole path in #include but I still get the same error. What's
> happening
> > here?
> >
> > I am compiling the application as
> > gcc -o test test.cc -lgnuradio-core
> >
> > I even tried this but it throws the same error. Somehow it's unable to
> find
> > the header even thought the path are included in the $PATH variable.
> > gcc -o test test.cc `pkg-config --libs gnuradio-core`
> >
> > Any help will be greatly appreciated.
> >
> > Thanks
> >
> >
>
> You are missing cflags, use pkg-config --cflags
>
> the environment variable "PATH" is not related
>

I tried this and it didn't work either.

gcc -o test test.c -pthread -I/usr/local/include/gnuradio
-I/usr/local/include  -L/usr/local/lib -lgnuradio-core -lgruel -lfftw3f
-lgsl -lgslcblas -lm

Any other suggestion?

Thanks


>
> -josh
>
> ___
> 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] gnuradio library linking error

[Alexandru Csete]

On Thu, Nov 3, 2011 at 10:04 PM, Marcus M  wrote:
>
> On Thu, Nov 3, 2011 at 3:52 PM, Josh Blum  wrote:
>>
>> On 11/03/2011 01:48 PM, Marcus M wrote:
>> > Hi,
>> > I have a test application that I want to link with the gnuradio library.
>> > I
>> > user the proper link variables but I always get the error of the
>> > following
>> > type.
>> >
>> > fatal error: gr_complex.h: No such file or directory
>> > compilation terminated.
>> >
>> > In this test application I am using the gr_complex data type and I am
>> > including the proper header variable. I checked my $PATH variable and it
>> > includes the proper header directories and the library. I tried
>> > including
>> > the whole path in #include but I still get the same error. What's
>> > happening
>> > here?
>> >
>> > I am compiling the application as
>> > gcc -o test test.cc -lgnuradio-core
>> >
>> > I even tried this but it throws the same error. Somehow it's unable to
>> > find
>> > the header even thought the path are included in the $PATH variable.
>> > gcc -o test test.cc `pkg-config --libs gnuradio-core`
>> >
>> > Any help will be greatly appreciated.
>> >
>> > Thanks
>> >
>> >
>>
>> You are missing cflags, use pkg-config --cflags
>>
>> the environment variable "PATH" is not related
>
> I tried this and it didn't work either.
>
> gcc -o test test.c -pthread -I/usr/local/include/gnuradio
> -I/usr/local/include  -L/usr/local/lib -lgnuradio-core -lgruel -lfftw3f
> -lgsl -lgslcblas -lm
>
> Any other suggestion?
>

Maybe you are using quoted form include instead of angle-bracket, i.e.
you should use:

#include 

Alex

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

Re: [Discuss-gnuradio] gnuradio library linking error

[Marcus M]

No Alex I am using the right form. What's strange is that I did the same
thing before on a different computer and it worked.

On Thu, Nov 3, 2011 at 4:25 PM, Alexandru Csete  wrote:

> On Thu, Nov 3, 2011 at 10:04 PM, Marcus M  wrote:
> >
> > On Thu, Nov 3, 2011 at 3:52 PM, Josh Blum  wrote:
> >>
> >> On 11/03/2011 01:48 PM, Marcus M wrote:
> >> > Hi,
> >> > I have a test application that I want to link with the gnuradio
> library.
> >> > I
> >> > user the proper link variables but I always get the error of the
> >> > following
> >> > type.
> >> >
> >> > fatal error: gr_complex.h: No such file or directory
> >> > compilation terminated.
> >> >
> >> > In this test application I am using the gr_complex data type and I am
> >> > including the proper header variable. I checked my $PATH variable and
> it
> >> > includes the proper header directories and the library. I tried
> >> > including
> >> > the whole path in #include but I still get the same error. What's
> >> > happening
> >> > here?
> >> >
> >> > I am compiling the application as
> >> > gcc -o test test.cc -lgnuradio-core
> >> >
> >> > I even tried this but it throws the same error. Somehow it's unable to
> >> > find
> >> > the header even thought the path are included in the $PATH variable.
> >> > gcc -o test test.cc `pkg-config --libs gnuradio-core`
> >> >
> >> > Any help will be greatly appreciated.
> >> >
> >> > Thanks
> >> >
> >> >
> >>
> >> You are missing cflags, use pkg-config --cflags
> >>
> >> the environment variable "PATH" is not related
> >
> > I tried this and it didn't work either.
> >
> > gcc -o test test.c -pthread -I/usr/local/include/gnuradio
> > -I/usr/local/include  -L/usr/local/lib -lgnuradio-core -lgruel -lfftw3f
> > -lgsl -lgslcblas -lm
> >
> > Any other suggestion?
> >
>
> Maybe you are using quoted form include instead of angle-bracket, i.e.
> you should use:
>
> #include 
>
> Alex
>
> ___
> 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] measure the impulse response of the channel

[峰周]

Hi all,
I am new on GNU Radio.I want to measure the impulse response of the
channel.
I transmit a known m-sequence using BPSK modulation(dbpsk.py)at 2.4G,
USRP1.

At the receiver set, where should I cross-correlate the received signal
with the known m-sequence to give the (complex) impulse response of the
channel?

Since I don't need to probe the channel at the Rx continuously , I think
the gr-sounder is not suitable.

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

Re: [Discuss-gnuradio] Strange behavior in digital benchmark examples

[Tuan (Johnny) Ta]

Josh,

I've upgraded to 3.5rc0. The same thing happened. I got some more details:

When I ran benchmark_tx on 1 machine, at low bitrate (0.1Mbps or 0.2MSps -
I'm using bpsk) the CPU utilization is roughly 9%.
But the receiver, running benchmark_rx showed 110% CPU utilization.

If I up the bitrate to 1Mbps,
the transmitter showed 90% CPU utilization so it scaled linearly.
the receiver starts out showing 110% CPU utilization, so I guess it
processed noise also, which makes sense because there's no carrier-sense.
It did nothing for a while (~30 sec), then started showing correct
receptions. Until a point, it started to show overrun. Here's part of the
output on the receiver:

ok =  True  pktno =  859  n_rcvd =  859  n_right =  859
ok =  True  pktno =  860  n_rcvd =  860  n_right =  860
ok =  True  pktno =  861  n_rcvd =  861  n_right =  861
ok =  True  pktno =  862  n_rcvd =  862  n_right =  862
ok =  True  pktno =  863  n_rcvd =  863  n_right =  863
ok =  True  pktno =  864  n_rcvd =  864  n_right =  864
ok =  True  pktno =  865  n_rcvd =  865  n_right =  865
ok =  True  pktno =  866  n_rcvd =  866  n_right =  866
ok =  True  pktno =  867  n_rcvd =  867  n_right =  867
Ook =  True  pktno =  868  n_rcvd =  868  n_right =  868
OOOok = False  pktno =  869  n_rcvd =  869  n_right =  868
OOOok = False  pktno =  879  n_rcvd =  870  n_right =  868
Ook = False  pktno =  902  n_rcvd =  871  n_right =  868
OOOok = False  pktno =  914  n_rcvd =  872  n_right =  868
ok = False  pktno =  929  n_rcvd =  873  n_right =  868
OOOok = False  pktno =  950  n_rcvd =  874  n_right =  868
OOOok = False  pktno =  970  n_rcvd =  875  n_right =  868
OOok = False  pktno =  983  n_rcvd =  876  n_right
=  868
OOOok = False  pktno =  987  n_rcvd =  877  n_right =  868
OOok = False  pktno =  990  n_rcvd =  878  n_right =  868
OOok = False  pktno =  993  n_rcvd =  879  n_right =  868
OOok = False  pktno =  996  n_rcvd =  880  n_right =  868


Another thing is when I started the transmitter first, then the receiver
started to show received samples right away. If I started the receiver
first, then it had the 30 sec delay mentioned above.

Before I used to run these code on the old gnuradio version (3.2.2) and
Ethernet driver and didn't have this problem. Could this be related to the
new implementation of gnuradio and/or the UHD driver? Or is there any other
possible explanation?

Thank you,
Johnny


On Thu, Nov 3, 2011 at 4:54 PM, Josh Blum  wrote:

>
>
> On 11/03/2011 01:28 PM, Tuan (Johnny) Ta wrote:
> > Hello all,
> >
> > I just came across a strange behavior in the digital benchmark examples
> > that I haven't seen before. The transmitter wouldn't stop itself after it
> > finishes sending the requested data size (specified by -M argument).
> > Keyboard interrupt (ctrl+C) has no effect. I had to stop it with ctrl+Z
> and
> > kill the job after.
> >
> > This behavior starts when bitrate exceeds 1M.
> >
> > If I ran benchmark_rx2.py then a short period after receiving all packets
> > (~30 sec), the receiver would continuously spill out "O" (overrun). This
> > didn't happen if I ran benchmark_rx.py. (I ran the corresponding tx
> code.)
> >
> > I'm not sure what could be causing it. I was able to run digital
> benchmark
> > code on my older machine at 1.5Mbps prior to UHD (I used Ethernet driver)
> > so I'm sure CPU speed isn't a problem.
> >
> > To make it work with UHD driver, I made some changes to the
> usrp_options.py
> > and generic_usrp.py.
> >
>
> I believe that tom ported all of the gnuradio "classic" example
> applications in 3.5 release. You may want to try those examples, because
> I know that he has tested them recently.
>
> I hope that helps,
> -Josh
>
> ___
> 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] Strange behavior in digital benchmark examples

[Tuan (Johnny) Ta]

Just a thought. Could this be the overhead of the new stream tags? Since I
didn't see it before.

On Thu, Nov 3, 2011 at 10:23 PM, Tuan (Johnny) Ta wrote:

> Josh,
>
> I've upgraded to 3.5rc0. The same thing happened. I got some more details:
>
> When I ran benchmark_tx on 1 machine, at low bitrate (0.1Mbps or 0.2MSps -
> I'm using bpsk) the CPU utilization is roughly 9%.
> But the receiver, running benchmark_rx showed 110% CPU utilization.
>
> If I up the bitrate to 1Mbps,
> the transmitter showed 90% CPU utilization so it scaled linearly.
> the receiver starts out showing 110% CPU utilization, so I guess it
> processed noise also, which makes sense because there's no carrier-sense.
> It did nothing for a while (~30 sec), then started showing correct
> receptions. Until a point, it started to show overrun. Here's part of the
> output on the receiver:
>
> ok =  True  pktno =  859  n_rcvd =  859  n_right =  859
> ok =  True  pktno =  860  n_rcvd =  860  n_right =  860
> ok =  True  pktno =  861  n_rcvd =  861  n_right =  861
> ok =  True  pktno =  862  n_rcvd =  862  n_right =  862
> ok =  True  pktno =  863  n_rcvd =  863  n_right =  863
> ok =  True  pktno =  864  n_rcvd =  864  n_right =  864
> ok =  True  pktno =  865  n_rcvd =  865  n_right =  865
> ok =  True  pktno =  866  n_rcvd =  866  n_right =  866
> ok =  True  pktno =  867  n_rcvd =  867  n_right =  867
> Ook =  True  pktno =  868  n_rcvd =  868  n_right =  868
> OOOok = False  pktno =  869  n_rcvd =  869  n_right =  868
> OOOok = False  pktno =  879  n_rcvd =  870  n_right =  868
> Ook = False  pktno =  902  n_rcvd =  871  n_right =  868
> OOOok = False  pktno =  914  n_rcvd =  872  n_right =  868
> ok = False  pktno =  929  n_rcvd =  873  n_right =  868
> OOOok = False  pktno =  950  n_rcvd =  874  n_right =  868
> OOOok = False  pktno =  970  n_rcvd =  875  n_right =  868
> OOok = False  pktno =  983  n_rcvd =  876  n_right
> =  868
> OOOok = False  pktno =  987  n_rcvd =  877  n_right =  868
> OOok = False  pktno =  990  n_rcvd =  878  n_right =  868
> OOok = False  pktno =  993  n_rcvd =  879  n_right =  868
> OOok = False  pktno =  996  n_rcvd =  880  n_right =  868
>
>
> Another thing is when I started the transmitter first, then the receiver
> started to show received samples right away. If I started the receiver
> first, then it had the 30 sec delay mentioned above.
>
> Before I used to run these code on the old gnuradio version (3.2.2) and
> Ethernet driver and didn't have this problem. Could this be related to the
> new implementation of gnuradio and/or the UHD driver? Or is there any other
> possible explanation?
>
> Thank you,
> Johnny
>
>
> On Thu, Nov 3, 2011 at 4:54 PM, Josh Blum  wrote:
>
>>
>>
>> On 11/03/2011 01:28 PM, Tuan (Johnny) Ta wrote:
>> > Hello all,
>> >
>> > I just came across a strange behavior in the digital benchmark examples
>> > that I haven't seen before. The transmitter wouldn't stop itself after
>> it
>> > finishes sending the requested data size (specified by -M argument).
>> > Keyboard interrupt (ctrl+C) has no effect. I had to stop it with ctrl+Z
>> and
>> > kill the job after.
>> >
>> > This behavior starts when bitrate exceeds 1M.
>> >
>> > If I ran benchmark_rx2.py then a short period after receiving all
>> packets
>> > (~30 sec), the receiver would continuously spill out "O" (overrun). This
>> > didn't happen if I ran benchmark_rx.py. (I ran the corresponding tx
>> code.)
>> >
>> > I'm not sure what could be causing it. I was able to run digital
>> benchmark
>> > code on my older machine at 1.5Mbps prior to UHD (I used Ethernet
>> driver)
>> > so I'm sure CPU speed isn't a problem.
>> >
>> > To make it work with UHD driver, I made some changes to the
>> usrp_options.py
>> > and generic_usrp.py.
>> >
>>
>> I believe that tom ported all of the gnuradio "classic" example
>> applications in 3.5 release. You may want to try those examples, because
>> I know that he has tested them recently.
>>
>> I hope that helps,
>> -Josh
>>
>> ___
>> 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] How can Receiver separate between two different frequency's input

[niaz ahmed]

Thanks Marcus,
 I appreciate your approach and i guess i will need goertzel transform over
these frequencies.

On Wed, Nov 2, 2011 at 2:25 AM, Marcus D. Leech  wrote:

>
>> I am working on an application where i receive input at audio_sink and
>> check for tone or data.
>> Data is FSK modulated at 1k and 3k whereas Tone is of 2k (i.e Tone lies
>> in the middle).
>>
>> I have written a flow graph which consists of two heirarichal flow graphs
>> (tone_rx and data_rx).
>> Input is received at audio_sink and then forwarded to both sub-graphs.
>>
>> My code works fine when tone is received but there is a problem when Data
>> is received.
>> Because Data consists of FSK code and it has 2k components in it which
>> also triggers Tone graph.
>>
>> So i want to ask is there any GnuRadio Block by using which i can avoid
>> triggering of tone while receiving Data
>> as i need to eliminate 2k component for Data but retain it when input it
>> is  Tone. OR
>> is there any such method by which we identify at the start whether it is
>> data or tone.
>> i am using laptop sound card (not usrp).
>>
>>  Simple first approximation.  Use the short-term-average power calculated
> over the data channels (1KHz and 3KHz), to drive a squelch
>  function on the 2KHz channel.  I'll leave the details up to you, but I'd
> basically have some logic that said "if energy at 1KHz and energy at 3KHz,
>  squelch the 2KHz tone channel."
>
>
>
>
> --
> 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
>



-- 
*Niaz Ahmed*



“We are always more anxious to be distinguished for a talent which we do
not possess, than to be praised for the fifteen which we do possess”*
  :  Mark
Twain *

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

[Discuss-gnuradio] gr.file_sink, want to end the sensing after a while

[Hasan Rajib Imam]

Hello all,

I am using the gr.file_sink() function to catch the raw data in GNC
platform. I have created a frequency list (with 10 frequncies) in a .txt
format and want to catch the raw data for each frequency. However, the
problem is, when the first frequency is selected, it continues to sense and
the file gets bigger and bigger. The sensing does not stop automatically.
Probably I have to limit the sensing time so that after that time period,
the second frequency is automatically selected.
I dont know how to do that.
Any idea?
-- 
Hasan Rajib Imam
University of Electro-Communication, Japan
1st year Masters Student
Email: shuvo1...@gmail.com
Contact No: (+81)80-5004-5931
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio