Re: [Discuss-gnuradio] Install old version of gnuradio

[Ellen Apolinar]

Hey Loic,

when you install GNU Radio be sure that you made Prerequirements.

I did

> apt-get -y install libfontconfig1-dev libxrender-dev libpulse-dev swig g++
> automake autoconf python-dev libfftw3-dev libcppunit-dev libboost-all-dev
> libusb-dev fort77 sdcc sdcc-libraries libsdl1.2-dev python-wxgtk2.8
> git-core guile-1.8-dev libqt4-dev python-numpy ccache python-opengl
> libgsl0-dev python-cheetah python-lxml doxygen qt4-dev-tools
> libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools python-qwt5-qt4
>

before I installed GNU Radio. You have to know which of them you need for
your installation so there are no errors.

I installed GNU Radio for USRP1 with this:

./configure --disable-all-components --enable-usrp –enable-gruel
> make all
> make
> make check
> make install
> ldconfig
>

and all works without errors. (But I have an error if I want to start
usrp_fft.py since
I installed GR3.5, deleted it and installed GR3.3. But this is my mistake
and not an issue
from GNU Radio or Python.)

The Version from GNU Radio is important if you want to work with the USRP1
because since GR3.5 they stopped the support for it. But I think if you
have to use
UHD you won't work with the USRP1 (because with it UHD isn't needed) so you
can
choose a newer version from GR and if you are ubuntu user you could use
the building-script [1] which is very easy to install (including UHD, GRC
and all what
you need).
Really, I can recommend GR3.5 and using the building script if you don't
need an older version.
As I installed it there were no problems and as I started GRC it worked
fine.

Remember: If you want to use GNU Radio with UHD you have to install UHD
first.

I'm also new with GNU Radio so I don't know your error message but it shows
that
you have an error with Python. Are you working with Ubuntu? Which version do
you use? And can you see which version you have from Python?

Regards
Ellen


[1]
http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR#Using-the-build-gnuradio-script



2012/5/10 Loic Danceg 
>
> I try but i have these erros when i use the command make :
>
> python/uhd_swig.cc:14754:3: error: ‘stream_args_t’ was not declared in
this scope
> python/uhd_swig.cc:14754:18: error: ‘arg2’ was not declared in this scope
> python/uhd_swig.cc:14764:3: error: ‘rx_streamer’ has not been declared
> python/uhd_swig.cc:14764:21: error: expected ‘;’ before ‘result’
> python/uhd_swig.cc:14779:28: error: expected type-specifier before
‘stream_args_t’
> python/uhd_swig.cc:14779:28: error: expected ‘>’ before ‘stream_args_t’
> python/uhd_swig.cc:14779:28: error: expected ‘(’ before ‘stream_args_t’
> python/uhd_swig.cc:14779:44: error: expected primary-expression before
‘>’ token
> python/uhd_swig.cc:14779:52: error: expected ‘)’ before ‘;’ token
> python/uhd_swig.cc:14782:7: error: ‘result’ was not declared in this scope
> python/uhd_swig.cc:14782:53: error: expected ‘)’ before ‘const’
> python/uhd_swig.cc:14782:67: error: expected ‘)’ before ‘;’ token
> python/uhd_swig.cc:14792:15: error: expected type-specifier before
‘rx_streamer’
> python/uhd_swig.cc:14792:15: error: expected ‘)’ before ‘rx_streamer’
> python/uhd_swig.cc:14792:161: error: expected ‘)’ before ‘;’ token
> python/uhd_swig.cc: In function ‘PyObject*
_wrap_device_get_tx_stream(PyObject*, PyObject*, PyObject*)’:
> python/uhd_swig.cc:14802:3: error: ‘stream_args_t’ was not declared in
this scope
> python/uhd_swig.cc:14802:18: error: ‘arg2’ was not declared in this scope
> python/uhd_swig.cc:14812:3: error: ‘tx_streamer’ has not been declared
> python/uhd_swig.cc:14812:21: error: expected ‘;’ before ‘result’
> python/uhd_swig.cc:14827:28: error: expected type-specifier before
‘stream_args_t’
> python/uhd_swig.cc:14827:28: error: expected ‘>’ before ‘stream_args_t’
> python/uhd_swig.cc:14827:28: error: expected ‘(’ before ‘stream_args_t’
> python/uhd_swig.cc:14827:44: error: expected primary-expression before
‘>’ token
> python/uhd_swig.cc:14827:52: error: expected ‘)’ before ‘;’ token
> python/uhd_swig.cc:14830:7: error: ‘result’ was not declared in this scope
> python/uhd_swig.cc:14830:53: error: expected ‘)’ before ‘const’
> python/uhd_swig.cc:14830:67: error: expected ‘)’ before ‘;’ token
> python/uhd_swig.cc:14840:15: error: expected type-specifier before
‘tx_streamer’
> python/uhd_swig.cc:14840:15: error: expected ‘)’ before ‘tx_streamer’
> python/uhd_swig.cc:14840:161: error: expected ‘)’ before ‘;’ token
> make[5]: ** [_uhd_swig_la-uhd_swig.lo] Erro 1
> make[5]: Saindo do diretório `/home/sdr/gnuradio-3.4.0/gr-uhd/swig'
>
> And these errors with the command ./bootstrap
> chmod: impossível acessar "volk_register.py": Arquivo ou diretório não
encontrado
> aclocal: `configure.ac' or `configure.in' is required
> autoconf: error: no input file
> autoheader: `configure.ac' or `configure.in' is required
> automake: `configure.ac' or `configure.in' is required
>
> Someone know why?
>
> Thank you :-)
>
>
>
>
> 2012/5/10 Loic Danceg 
>>
>> Hi Ellen,
>>
>> Tha

Re: [Discuss-gnuradio] Samples/Symbol Help

[Patrik Tast]

Could this help?

http://en.wikipedia.org/wiki/Phase-shift_keying

Patrik

- Original Message - 
From: "sibar002" 

To: 
Sent: Friday, May 11, 2012 3:50
Subject: [Discuss-gnuradio] Samples/Symbol Help




Hello

I am working with the different digital modulators in grc, and I am having
trouble understanding some of the parameters. I don't understand the 
effect

that the samples/symbol or bits/symbol has on the sampling rate. I would
greatly appreciate any help or advice. Thank you for your time.

Sam
--
View this message in context: 
http://old.nabble.com/Samples-Symbol-Help-tp33763690p33763690.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] SWIG, current gr-howto structure and exception specifiers

[Martin Braun]

In the current state of gr-howto (which is also used in gr_modtool), the
SWIG stuff is done pretty intelligently by using the header files as
.i-files, which means there is no need to write a SWIG header for every
block.

One advantage of this was the possibility to add stuff in the .i-file
which weren't in the .h-file; specifically, exception specifiers.

Example (from gr-specest, specest_welch.i):

GR_SWIG_BLOCK_MAGIC(specest,welch);

specest_welch_sptr
specest_make_welch(unsigned fft_len, int overlap, int ma_len, bool fft_shift, 
const std::vector &window)
throw(std::invalid_argument);

// And so on .


If I don't declare the exception specifier, I can't catch the exception
in Python. If I simply include specest_welch.h in specest_swig.i, I need
to add the specifiers in the C++-code, which is not very popular (and I
think not future-compatible, and gcc doesn't handle that well).

Here's my question: is there a cool way to have SWIG know about the
exceptions without having to write a .i-file for every block that uses
exceptions? Can I 'tag' the source code in a way that gcc doesn't care,
but SWIG does?

Thanks for any nice ideas!

MB


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


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

Re: [Discuss-gnuradio] Package libusrp-dev on Ubuntu Precise 12.04

[Vanessa Quaranta]

Hi Tom,

Thanks a lot for your response.
Do you know approximately when this new package will be available?

Cheers,

Vanessa

2012/5/4 Tom Rondeau 

> On Fri, May 4, 2012 at 9:04 AM, Vanessa Quaranta
>  wrote:
> > Hi!
> >
> > Where can I find libusrp-dev for Ubuntu 12.04?
> >
> > This packet has been removed of the repository...
> > I  really need this packet for my app with OpenBTS and USRP1
> >
> > Hope you can help me. Thanks,
> >
> > Vanessa
>
> Vanessa,
>
> We (in GNU Radio) have completely moved away from using libusrp, and
> the packaging in Ubuntu was ancient at this point, anyways. I'm
> actually glad it's been removed from 12.04. We are actively working to
> get new releases as part of apt-get in Debian/Ubuntu and are almost
> there.
>
> For your needs, though, the best thing to do is probably check out a
> copy of GNU Radio BEFORE version 3.5.0. Version 3.4.2 can be found:
> http://gnuradio.org/redmine/attachments/download/279/gnuradio-3.4.2.tar.gz
>
> You can use this to just build libusrp if you want. I _think_ this
> command while configuring should work:
> ./configure --disable-all --enable-usrp
>
> But it's been a while; you might need to do a bit more than just that.
> It should tell you what you need, though.
>
> Tom
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Working at 20 MS/s

[frankist]

Hi,

In fact I have underruns in the transmitter which means according to the
website you gave me, my transmitter is not producing data fast enough. I
guess I need a better computer for that.

Just one more question:
Are sampling rates of 20 and 25 MS/s too much for devices, more
especifically, for cognitive radio?


Josh Blum-3 wrote:
> 
> 
> 
> On 05/01/2012 08:55 AM, frankist wrote:
>> 
>> Hi,
>> 
>> I was interested in working with detectors for OFDM 802.11b in my USRP2.
>> I've read on the internet about this and it seems that there are people
>> able to use sampling rates of 20 MS/s.
>> 
>> However, when I try to send an OFDM signal with 20 MHz of bandwidth, at
>> the USRP2 receiver board the FFT plot shows the signal blinking.
>> 
> 
> I think you are seeing the result of an FFT over a sample discontinuity.
> This discontinuity is due to overflow, in other words, your computer is
> not able to process at this rate.
> 
> http://files.ettus.com/uhd_docs/manual/html/general.html#overflow-underflow-notes
> Are you seeing overflow (O's are being printed)?
> 
> Are there any warnings printed by the driver?
> (Answering some of those warnings can help with performance)
> 
> Usually running an FFT display on RX data is not a big performance hit.
> Any information about your PC that you can share? CPU? OS?
> 
> -Josh
> 
> ___
> 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/Working-at-20-MS-s-tp33763341p33779586.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

Re: [Discuss-gnuradio] Samples/Symbol Help

[wayne roberts]

maybe better?
http://en.wikipedia.org/wiki/Symbol_rate

When you change samples_per_symbol, you aren't changing the sample rate,
but instead the divider of sample rate which gives clock for symbol rate.

On Fri, May 11, 2012 at 1:40 AM, Patrik Tast wrote:

> Could this help?
>
> http://en.wikipedia.org/wiki/**Phase-shift_keying
>
> Patrik
>
> - Original Message - From: "sibar002" 
> To: 
> Sent: Friday, May 11, 2012 3:50
> Subject: [Discuss-gnuradio] Samples/Symbol Help
>
>
>
>
>> Hello
>>
>> I am working with the different digital modulators in grc, and I am having
>> trouble understanding some of the parameters. I don't understand the
>> effect
>> that the samples/symbol or bits/symbol has on the sampling rate. I would
>> greatly appreciate any help or advice. Thank you for your time.
>>
>> Sam
>> --
>> View this message in context: http://old.nabble.com/Samples-**
>> Symbol-Help-**tp33763690p33763690.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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] aUaUaUaUaUaU and requested rx frequency not supported problem

[sakulkar]

Hi Everybody,
I am using USRP with daugherboard of range 1MHz to 250MHz. I am running
the program with gnu-radio 3.6.0 on Ubuntu 11.10. I am trying to run the
basic fm receiver program as shown in the video.
http://www.youtube.com/watch?v=KWeY2yqwVA0

Whenever I try to execute the code, I get following things on grc. I have
double checked that the daughterboard works for the range. When I see the
fft plot of the received signal I see that I have just noise all around.
The hardware does not support the requested RX frequency:
   Target frequency: 100.00 MHz
   Actual frequency: -28.00 MHz
aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU

I have also tried to see if the antenna choices are correct. I checked it
with uhd_usrp_probe
The important part of the result was
  RX Subdev: AB
|   |   |   |   Name: Basic RX (0x0001) - AB
|   |   |   |   Antennas:
|   |   |   |   Sensors:
|   |   |   |   Freq range: -250.000 to 250.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Subdev: BA
|   |   |   |   Name: Basic RX (0x0001) - BA
|   |   |   |   Antennas:
|   |   |   |   Sensors:
|   |   |   |   Freq range: -250.000 to 250.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: QI
|   |   |   |   Uses LO offset: No

So, when I try to work with uhd_fft. I got same problem with following
results
uhd_fft --spec B:AB

linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.001-39-unstable

-- Opening a USRP1 device...
-- Using FPGA clock rate of 64.00MHz...
Using Volk machine: ssse3_64

UHD Warning:
   The hardware does not support the requested RX frequency:
   Target frequency: 100.00 MHz
   Actual frequency: -28.00 MHz

Could you help me out here?
Thanks in advance.

-- Pranav Sakulkar



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

Re: [Discuss-gnuradio] aUaUaUaUaUaU and requested rx frequency not supported problem

[mleech]

  

On Fri, 11 May 2012 19:08:38 +0200 (CEST),
sakul...@ti.rwth-aachen.de wrote: 

> Hi Everybody,
> I am using USRP
with daugherboard of range 1MHz to 250MHz. I am running
> the program
with gnu-radio 3.6.0 on Ubuntu 11.10. I am trying to run the
> basic fm
receiver program as shown in the video.
>
http://www.youtube.com/watch?v=KWeY2yqwVA0 [1]
> 
> Whenever I try to
execute the code, I get following things on grc. I have
> double checked
that the daughterboard works for the range. When I see the
> fft plot of
the received signal I see that I have just noise all around.
> The
hardware does not support the requested RX frequency:
> Target
frequency: 100.00 MHz
> Actual frequency: -28.00 MHz
>
aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU
>

> I have also tried to see if the antenna choices are correct. I
checked it
> with uhd_usrp_probe
> The important part of the result
was
> RX Subdev: AB
> | | | | Name: Basic RX (0x0001) - AB
> | | | |
Antennas:
> | | | | Sensors:
> | | | | Freq range: -250.000 to 250.000
Mhz
> | | | | Gain Elements: None
> | | | | Connection Type: IQ
> | | |
| Uses LO offset: No
> | | |
_
> | | | /
> | | |
| RX Subdev: BA
> | | | | Name: Basic RX (0x0001) - BA
> | | | |
Antennas:
> | | | | Sensors:
> | | | | Freq range: -250.000 to 250.000
Mhz
> | | | | Gain Elements: None
> | | | | Connection Type: QI
> | | |
| Uses LO offset: No
> 
> So, when I try to work with uhd_fft. I got
same problem with following
> results
> uhd_fft --spec B:AB
> 
> linux;
GNU C++ version 4.6.1; Boost_104601; UHD_003.004.001-39-unstable
> 
> --
Opening a USRP1 device...
> -- Using FPGA clock rate of
64.00MHz...
> Using Volk machine: ssse3_64
> 
> UHD Warning:
> The
hardware does not support the requested RX frequency:
> Target
frequency: 100.00 MHz
> Actual frequency: -28.00 MHz
> 
> Could
you help me out here?
> Thanks in advance.
> 
> -- Pranav Sakulkar
> 
>
___
> Discuss-gnuradio
mailing list
> Discuss-gnuradio@gnu.org [2]
>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]

The aU is
because your audio subsystem is experiencing underruns, probably because
you have a sample-rate issue in your flow-graph. 

The UHD warning is
because the BASIC_RX has no downconversion hardware at all, which means
that any frequency above Nyquist (32Mhz for USRP1 and 50Mhz for N2XX)
requires that the FPGA/ADCs sample the appropriate alias frequency, and
UHD is warning you that's what it's doing. But without analog filtering
in the front-end, you'll end up with *unwanted* aliases as well. The
BASIC_RX is very "BASIC", and it's really intended as an interface card
to "proper" RF front-ends, with filtering, and probably downconversion
to an IF. 

  

Links:
--
[1]
http://www.youtube.com/watch?v=KWeY2yqwVA0
[2]
mailto:Discuss-gnuradio@gnu.org
[3]
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] pulse signal generation

[wayne roberts]

Something to try: byte file source with one byte of 0xff, and the other 9
is 0x00.

grc is attatched, but Gaussian filter is very strongly filtering it and i
really dont understand it very well, which is needed for bandwidth limiting.
But if you dont want any filtering, you could feed file source directly to
real input of float-to-complex (with only type conversion).

also attached is file you can use xxd to convert binary file to & from text
file.
I dont know if binary file attaches to email, but you can put this into xxd
-r:
000: ff00    



On Thu, May 10, 2012 at 11:50 PM, S'dir  wrote:

> Hi,
>
> I am a starter. How to generate 100Hz (10% duty) pulsed signal using
> gnuradio & usrp1
>
> Any help would be highly appreciated.
>
> Thanks & Regds,
> Sudhir.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


10percent
Description: Binary data


ook_filesrc.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC: New xml tags

[Josh Blum]

> Please watch a sample recording
> http://www.youtube.com/watch?v=aqLIPHXCM1M (kindly switch to high
> resolution). In my implementation I tried to update grc block
> parametes by handling stdout of an external program and from a file
> too.
> 

This is pretty cool stuff. I bet the same modification/idea could be
used to launch a gui designer tool as well.

> I would mainly like to add two features a) launching of an external
> application and handling the out (may be via stdout or using plugs
> and sockets) b) File loader so that block parameters can be directly
> imported from an standard xml file.
> 

You might consider, rather than launching an external application,
rather, calling into a python module/function that returns some result.

Now it might be that calling into the module launches an external
application, but the idea is that the difficulty of launching and
parsing program specific output is encapsulated into the module.

All GRC properties dialog has to know is how to call a function and
process its return values.

-josh

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

Re: [Discuss-gnuradio] Phase shift correction in Bpsk!!

[sreeraj r]

Hi Sreenath,

In the case of BPSK the costas loop is properly locked when the quadrature 
component of the signal is close to zero ( ie lpf[data * cos 
(2*pi*f_c*t)*sin(2*pi*f_c*t)] = 0). I am not sure how you will implement this 
in GRC as you have to call 'advance_loop' in the plls (inherited from 
gri_control_loop) to correct the error in phase and frequency. You can directly 
use MPSK receiver block in grc which incorporates all of this. Please go 
through MPSK receiver block's implementation for more details. 

 
---
Regards
Sreeraj Rajendran
http://home.iitb.ac.in/~rsreeraj




 From: sreenath kambala 
To: Discuss-gnuradio@gnu.org 
Sent: Thursday, 10 May 2012 1:25 PM
Subject: [Discuss-gnuradio]  Phase shift correction in Bpsk!!
 

Hello All,

I have designed BPSK transmitter and receiver in grc.
But Costas loop can able to correct frequency offset, not phase offset.

Here, I attached both transmitter and receiver files.



Transmitter :

1). File sink contains Bpsk symbols {-1,1}  (repeat = yes)
2). Samples per symbol : 20
3). RRC pulse lasts for 2 symbol periods

Receiver   :

1). Matched filtering
2). Costas loop & Timing recovery
3). saving samples in File sink

and final Symbols are recovered from the samples in matlab.


I'm using uhd + gnuradio + USRP1 + RFX 2400 daughter boards.

Can somebody suggest me how to deal with Phase offset ?
(especially when the gain of Rx is low phase shifts are happening
frequently)

One more Question : Is Rms value sufficient in SNR Calculation ?






Thanks & Regards
http://old.nabble.com/file/p33763663/Transmitter.grc Transmitter.grc 
http://old.nabble.com/file/p33763663/Receiver.grc Receiver.grc 
http://old.nabble.com/file/p33763663/Rcvd_data.png Rcvd_data.png 
http://old.nabble.com/file/p33763663/Bpsk_data.dat Bpsk_data.dat 
-- 
View this message in context: 
http://old.nabble.com/Phase-shift-correction-in-Bpsk%21%21-tp33763663p33763663.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] USRP2 Ethernet port does not work

[Yong J. Chang]

I've been using many USRP2s for my project. Today one of the USRP2s cannot be
recognized through Ethernet.
Only the green LED on the Ethernet port lights up. 

I hooked up the Serial debug port and it says,

ethernet flow control: SYMMETRIC
LANSR: 
  LINK_GOOD
ethernet flow control: SYMMETRIC
LANSR: 
  LINK_GOOD
ethernet flow control: SYMMETRIC
LANSR: 
  LINK_GOOD
ethernet flow control: SYMMETRIC
LANSR: 
  LINK_GOOD
.
.
.

keeps going...

Any help will be appreciated!!!

Yong
-- 
View this message in context: 
http://old.nabble.com/USRP2-Ethernet-port-does-not-work-tp33783419p33783419.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

Re: [Discuss-gnuradio] Phase shift correction in Bpsk!!

[Tom Rondeau]

On Thu, May 10, 2012 at 3:55 AM, sreenath kambala
 wrote:
>
> Hello All,
>
> I have designed BPSK transmitter and receiver in grc.
> But Costas loop can able to correct frequency offset, not phase offset.
>
> Here, I attached both transmitter and receiver files.
>
> Transmitter :
>
> 1). File sink contains Bpsk symbols {-1,1}  (repeat = yes)
> 2). Samples per symbol : 20
> 3). RRC pulse lasts for 2 symbol periods
>
> Receiver   :
>
> 1). Matched filtering
> 2). Costas loop & Timing recovery
> 3). saving samples in File sink
>
> and final Symbols are recovered from the samples in matlab.
>
>
> I'm using uhd + gnuradio + USRP1 + RFX 2400 daughter boards.
>
> Can somebody suggest me how to deal with Phase offset ?
> (especially when the gain of Rx is low phase shifts are happening
> frequently)
>
> One more Question : Is Rms value sufficient in SNR Calculation ?


There is a Costas loop in GRC that will handle the phase and small
frequency offsets properly. But make sure that you use the timing
recovery loop BEFORE the Costas loop. The output of the timing loop
will output 1 sample/symbol at the right timing location, which will
aid the Costas loop in its recovery.

Look at the code in gr-digital/python/generic_mod_demod.py for how
we've done this.

Tom

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

Re: [Discuss-gnuradio] GRC: New xml tags

[Tom Rondeau]

On Fri, May 11, 2012 at 1:59 PM, Josh Blum  wrote:
>
>> Please watch a sample recording
>> http://www.youtube.com/watch?v=aqLIPHXCM1M (kindly switch to high
>> resolution). In my implementation I tried to update grc block
>> parametes by handling stdout of an external program and from a file
>> too.
>>
>
> This is pretty cool stuff. I bet the same modification/idea could be
> used to launch a gui designer tool as well.
>
>> I would mainly like to add two features a) launching of an external
>> application and handling the out (may be via stdout or using plugs
>> and sockets) b) File loader so that block parameters can be directly
>> imported from an standard xml file.
>>
>
> You might consider, rather than launching an external application,
> rather, calling into a python module/function that returns some result.

I think this suggestions of Josh's makes sense. It seems something
like this would make it easy for us to do something similar in
straight Python to design and pull in results from the GUI app.

Tom

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

Re: [Discuss-gnuradio] Reorganization and restructuring on 3.6 (master) and 3.7 (next) branches

[Andrew Davis]

> free weekend
I had one once!

So any plans for the application specific top-level blocks ( noaa,
pager, atsc )? I feel these could be moved to the CGRAN, or better yet
there could be a separate top-level folder for projects like this and
some of the GCRAN projects could be merged back into the main Gnuradio
git for better maintenance. ( A lot still use USRP instead of UHD and
even more still use autotools, this is giving me non-stop problems,
I'm working on updating a few ) Never hurts to have some well working
example projects showcasing Gnuradio!

On Thu, May 3, 2012 at 12:10 AM, Marcus D. Leech  wrote:
> On 03/05/12 12:07 AM, Josh Blum wrote:
>>
>> Just another free weekend, and I will have VOLK capable of generating
>> code to handle head and tail cases.
>>
>>
>>
> I once heard tell of this mythical "free weekend".  I don't believe in
> it.  It must be some kind of
>  fairy tale.
>
>
>
> --
> 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