date:20100219

Re: [Discuss-gnuradio] FLEX900 RX2 Port

2010-02-19 Thread Firas Abbas

Hi,


> From: Matt Ettus 
> 
> 
> Yes, you can do full duplex, but you should not connect the ports 
> directly or you will blow out the receiver.  There will be enough 
> leakage that you can just put attenuators.
> 
> Matt


Is USRP2 Antenna selection (TX/RX , RX2) works for the current firmware ?

Best Regards,

Firas



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

[Discuss-gnuradio] Custom block problem on OSX 10.6

2010-02-19 Thread Kunal Kandekar

Hi,

I am having trouble getting a custom block to run with a GNU Radio 3.2.2
install on my 64-bit Intel-based Macbook Pro running Snow Leopard 10.6. I
installed GNU Radio through MacPorts about a week ago. After some trial and
error with ./configure options, I got my custom block to compile and
install, but it breaks on make check with this error:

...
Eswig/python detected a memory leak of type 'gr_basic_block_sptr *', no
destructor found.

==
ERROR: test_ple_trx_ff (__main__.qa_ple)
--
Traceback (most recent call last):
  File "./qa_ple.py", line 110, in test_ple_trx_ff
self.fg.connect(self.sig_src1, self.ple_tx_ff)
  File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/top_block.py",
line 124, in connect
self._connect(points[i-1], points[i])
  File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/top_block.py",
line 130, in _connect
dst_block.basic_block(), dst_port)
  File
"/opt/local/lib/python2.6/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py",
line 1487, in connect
return _gnuradio_swig_py_runtime.gr_top_block_sptr_connect(self, *args)
NotImplementedError: Wrong number of arguments for overloaded function
'gr_top_block_sptr_connect'.
  Possible C/C++ prototypes are:
connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr)
connect(boost::shared_ptr< gr_top_block >
*,gr_basic_block_sptr,int,gr_basic_block_sptr,int)


--
Ran 1 test in 0.061s

FAILED (errors=1)
FAIL: run_tests

... etc. etc...

This same script used to run fine on my 32-bit build on OSX 10.5. I can get
example scripts like dial_tone.py to run without any problems. I get the
same error after building and running make check for the howto-write-a...
block from the gr-howto-write-a-block-3.2.2 tar ball:

...
make  check-TESTS
Eswig/python detected a memory leak of type 'gr_basic_block_sptr *', no
destructor found.
Eswig/python detected a memory leak of type 'gr_basic_block_sptr *', no
destructor found.

==
ERROR: test_001_square_ff (__main__.qa_howto)
--
Traceback (most recent call last):
  File "./qa_howto.py", line 40, in test_001_square_ff
self.tb.connect (src, sqr)
  File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/top_block.py",
line 124, in connect
self._connect(points[i-1], points[i])
  File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/top_block.py",
line 130, in _connect
dst_block.basic_block(), dst_port)
  File
"/opt/local/lib/python2.6/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py",
line 1487, in connect
return _gnuradio_swig_py_runtime.gr_top_block_sptr_connect(self, *args)
NotImplementedError: Wrong number of arguments for overloaded function
'gr_top_block_sptr_connect'.
  Possible C/C++ prototypes are:
connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr)
connect(boost::shared_ptr< gr_top_block >
*,gr_basic_block_sptr,int,gr_basic_block_sptr,int)


==
ERROR: test_002_square2_ff (__main__.qa_howto)
--
Traceback (most recent call last):
  File "./qa_howto.py", line 52, in test_002_square2_ff
self.tb.connect (src, sqr)
  File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/top_block.py",
line 124, in connect
self._connect(points[i-1], points[i])
  File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/top_block.py",
line 130, in _connect
dst_block.basic_block(), dst_port)
  File
"/opt/local/lib/python2.6/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py",
line 1487, in connect
return _gnuradio_swig_py_runtime.gr_top_block_sptr_connect(self, *args)
NotImplementedError: Wrong number of arguments for overloaded function
'gr_top_block_sptr_connect'.
  Possible C/C++ prototypes are:
connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr)
connect(boost::shared_ptr< gr_top_block >
*,gr_basic_block_sptr,int,gr_basic_block_sptr,int)


--
Ran 2 tests in 0.002s

FAILED (errors=2)
FAIL: run_tests

... etc. etc

So I suspect it is a problem with either the install or my configuration
rather than my code. Searching the archives turned up a few previous
mentions of the same problem, but solutions for those don't seem to help
here. I don't understand the "no destructor found" error, since I do have
virtual destructors implemented for my blocks (as do the howto examples, of
course).

Anyone manage to get any custom blocks running on 64-bit OSX 10.6? Any tips
would be appreciated!

Thanks,
Kunal
___
Discuss-gnuradio mailin

Re: [Discuss-gnuradio] Timestamp value

2010-02-19 Thread Tim Pearce

Ulrika,

The rx_handler thing is if its implemented to create a seperate stream of
timestamps in python (i.e gr-usrp2) rather than C++ - I ran into the problem
due to not fully understanding the code/checking base classes before I
modified it, it shouldnt be an issue with pure C++ or if you dont bother
incrementing the timestamp for each sample in a packet.

I think they are the same size, but contain x samples. I'd ignore that bit I
was confusing myself I think :)
Its been ages since I double checked stuff with wireshark/print statements
though so i might be wrong on whether they can vary.

Cheers,

Tim

2010/2/19 Ulrika Uppman 

>  Tim,
> thanks for your reply.
>
> I thought the packets always had the same size (specified by
> U2_MAX_SAMPLES), or am I wrong here? I also do get the very same timestamp
> diff when running rx_streaming_samples with N= 400, 4000, 6000, 6 etc.
>
> I don't quite follow you on what will happen when calling the handler
> multiple times? I print the timestamps in usrp2_impl handle_data_packet
> which I thought would be run every time (once) a new ethernet packet arrives
> which isn't a control packet?
>
> (And yes the timestamps are treated as uint32's.)
>
> Regards,
> /Ulrika
>
>  --
> *From:* Tim Pearce [mailto:timothy.pea...@gmail.com]
> *Sent:* Thursday, February 18, 2010 9:35 PM
> *To:* Ulrika Uppman
> *Cc:* Discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Timestamp value
>
> Ulrika,
>
> I agree with how you think the timestamps are generated -- it seems to work
> for me that way anyway!
>
> I did it with a custom source block that added the counter*decimation rate
> after the first sample, the trap I fell into there is that (particuarly at
> lower decimation rates) rx_*_handler() can be called multiple times per
> instance of it.
>
> Are the timestamps being treated as UINT32's?
>
> 400 samples is quite low, I think the packets are usually bigger than that
> (I might be wrong, its been a while since I looked into that).
>
> Cheers,
>
> Tim
>
> On Thu, Feb 18, 2010 at 4:10 PM, Ulrika Uppman wrote:
>
>> Hi,
>> I wonder how the timestamps are being generated for each ethernet-packet
>> sent from the USRP2 to the host? My initial idea about how it works was that
>> timestamps are generated at 100MHz (same as the samples) and then the
>> timestamp associated with the first sample in an ethernet data packet will
>> be put in the metadata which could then be unpacked in the host. I then
>> would assume that the next packet after the first one will have a timestamp
>> value that is proportional to the number of samples per packet times the
>> decimation rate. However I get timestamp values that increase much much more
>> for each received packet, so I wonder if my idea of how timestamps are
>> generated is wrong?
>>
>> I run the stable 3.2 version of gnuradio on Ubuntu 9.04 and I have an
>> USRP2 with the RFX2400. (I also was going to try the gnuradio trunk but I
>> got problems with building, see my other post "Error on make from git
>> development trunk"). I tried both an old version of the fpga bin-file and
>> one that I just recently downloaded (but both gave the same result).
>>
>> I put some printouts in usrp2_impl.cc in the handle_data_packet function
>> and the output when I run rx_streaming_samples then looks like this:
>> ./rx_streaming_samples -f 2457e6 -d 16 -N 400 -v
>>
>> ...
>> Daughterboard configuration:
>>  baseband_freq=245625.00
>>   ddc_freq=-75.00
>>  residual_freq=-0.016764
>>   inverted=no
>>
>> USRP2 using decimation rate of 16
>> Receiving 400 samples
>>
>> ts_in = 1435221596, ts_last = 0, diff = 1435221596
>> ts_in = 2560802396, ts_last = 1435221596, diff = 1125580800
>> ts_in = 3367616092, ts_last = 2560802396, diff = 806813696
>> ts_in = 4174429788, ts_last = 3367616092, diff = 806813696
>> ts_in = 686341724, ts_last = 4174429788, diff = 806879232
>> ts_in = 1493155420, ts_last = 686341724, diff = 806813696
>> ts_in = 2283192156, ts_last = 1493155420, diff = 790036736
>> ts_in = 3090005852, ts_last = 2283192156, diff = 806813696
>> ts_in = 3896819548, ts_last = 3090005852, diff = 806813696
>> ts_in = 408731484, ts_last = 3896819548, diff = 806879232
>>
>> Copy handler called 2 times.
>> Copy handler called with 2968 bytes.
>>
>> Elapsed time was 0.000 seconds.
>> Packet rate was 10 pkts/sec.
>> Approximate throughput was 148.40 MB/sec.
>> Total instances of overruns was 0.
>> Total missing frames was 0.
>>
>> ...
>>
>> ts_in is the timestamp found in the metadata of the packet just received,
>> ts_last is the one from previous packet and diff is just the difference them
>> between. Since there seems to be no missing frames I'm guessing the big
>> value of diff can't be related to lost packets?
>> If I try different decimation

Re: [Discuss-gnuradio] GNU Radio and OS X installation - path problem?

2010-02-19 Thread Michael Dickens

Hi Fabrizio - Glad to hear you had success using MacPorts to install  
GNU Radio on your 10.5 box.  That's the goal!


On Feb 19, 2010, at 1:19 PM, Fabrizio Tappero wrote:

seem (to me) to indicate the wrong path (at least for my
installation). To have all working I had to change:

if [ ${PYTHON_ROOT} != "/usr/include" ]; then
#export PYTHONPATH=${PYTHONPATH}:/usr/local/lib/python$ 
{PYTHON_VERSION}/site-packages
export PYTHONPATH=${PYTHONPATH}:/opt/local/lib/python$ 
{PYTHON_VERSION}/site-packages

fi

at the end of my .bashrc

Does anybody know why?


The install guide was written for when one installs GNU Radio from  
source by hand, not using MacPorts.  I think that, so long as you've  
done:


sudo port install python_select
sudo python_select python26

then I don't think you need that "if" statement at all -- it's  
designed to make sure the default install ${prefix} for GNU Radio (/ 
usr/local) is included in the PYTHON search path.  Since you installed  
from MacPorts, the ${prefix} is /opt/local, which should be covered by  
previous lines in the script:


setenv PYTHON_VERSION `python -V |& sed -e 's...@\.@ @2' | awk '{ print  
$2 }'` setenv

PYTHON_ROOT `which python | sed -e 's@/bin/python@@g'` setenv PYTHONPATH
${PYTHON_ROOT}/lib/python${PYTHON_VERSION}/site-packages

You might try commenting out the whole "if" statement (then "source  
~/.bashrc") & seeing if GNU Radio still works. - MLD




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

[Discuss-gnuradio] how to set the bit time ?

2010-02-19 Thread Arturo Rinaldi

Is it possible to set the *bit time* (i.e. the time of "0" and "1") 
arbitrarily in gnuradio, so to have an integer multiple of the default 
one used by gnuradio itself ?


  thx in advance, Arturo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio and OS X installation - path problem?

2010-02-19 Thread Fabrizio Tappero

Following the link below, in successfully installed GNU radio (with
all its dependencies) on OSX 10.5 using macport (sudo port install
gnuradio).

the indications in here:
https://radioware.nd.edu/documentation/install-guides/mac-os-x/preliminaries#section-3

seem (to me) to indicate the wrong path (at least for my
installation). To have all working I had to change:

if [ ${PYTHON_ROOT} != "/usr/include" ]; then
#export 
PYTHONPATH=${PYTHONPATH}:/usr/local/lib/python${PYTHON_VERSION}/site-packages
 export 
PYTHONPATH=${PYTHONPATH}:/opt/local/lib/python${PYTHON_VERSION}/site-packages
fi

at the end of my .bashrc

Does anybody know why?

cheers
Fabrizio
Ps for whoever is interested in installing GNURadio on OS X ... well
for me it took over 3 hours... in fact the boost lib took 2 hours to
install. But macport (and GNURadio) worked absolutely great ! Just my
experience.


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

Re: [Discuss-gnuradio] RE: Timestamp value

2010-02-19 Thread Josh Blum

You need to flash the sd card with fpga and firmware images from 
http://www.ettus.com/usrp2_vrt


Then you must install the host code from this branch: 
http://gnuradio.org/cgit/jblum.git/log/?h=usrp2_vrt


Alternatively, you can also build the firmware and fpga images from that 
branch as well.


One way to know that the host code is properly installed is to run 
wireshark. When you run the command find_usrps, you should see an 
ethernet packet going out with protocol id "0xbef0". If it shows 
protocol id "0xbeef" than you are not running the vrt branch.


-Josh

On 02/19/2010 06:47 AM, Ulrika Uppman wrote:

Sorry I made a mistake, I used the wrong fpga-build and firmware when I ran the vrt 
branch. When I discovered my mistake I downloaded the files from 
http://www.ettus.com/usrp2_vrt but I cannot get the USRP2 to work with these files. The 
leds go on just as normal, but when I try to run ./find_usrps I just get "No USRP2 
found". Does anyone know where to get the proper image files for the fpga and 
firmware?

Regards,
/Ulrika


-Original Message-
From: discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org
[mailto:discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org]
  On Behalf Of Ulrika Uppman
Sent: Friday, February 19, 2010 11:48 AM
To: Per Zetterberg
Cc: Discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] RE: Timestamp value

Hi,
I have now tried both the git master and the vrt branch and
the results there are similar to those in the 3.2 version.

I was guessing that the timestamps would be generated/handled
differently in the vrt branch but at a first glance I didn't
see any major differences in the code. What is the difference
with regard to timestamps and timing when using the vrt branch?

Regards,
/Ulrika


-Original Message-
From: Per Zetterberg [mailto:per.zetterb...@ee.kth.se]
Sent: Thursday, February 18, 2010 6:16 PM
To: Ulrika Uppman
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] RE: Timestamp value



Do anyone know why the difference in timestamp value

between received

packets is so big? What am I missing here?

Thanks,
/Ulrika


Have you tried the vrt branch by jblum ?

BR/
Per




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



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



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

Re: [Discuss-gnuradio] UCLA zigbee libraries problem

2010-02-19 Thread Daniele Bertussi


I have solved: the install path of UCLA zigbee libraries is by default 
/usr/local/lib/python2.6/site-packages/gnuradio but others gnuradio libraries 
are in /usr/lib/python2.6/site-packages/gnuradio.
Thanks a lot!

Bertussi Daniele

Citando daniele.bertu...@ing.unibs.it:



Hi Mike,
i have only one version of python installed:

linux-ul3s:/usr/local/lib/python2.6/site-packages/gnuradio # python --version
Python 2.6

linux-ul3s:/usr/local/lib # ls -al
totale 32864
drwxr-xr-x  4 root root 4096 18 feb 16:29 .
drwxr-xr-x 17 root root 4096 16 feb 15:19 ..
-rwxr-xr-x  1 root root 1262 18 feb 16:29 libgnuradio-audio-alsa.la
lrwxrwxrwx  1 root root   31 18 feb 16:29 libgnuradio-audio-alsa.so -> 
libgnuradio-audio-alsa.so.0.0.0
lrwxrwxrwx  1 root root   31 18 feb 16:29 libgnuradio-audio-alsa.so.0 -> 
libgnuradio-audio-alsa.so.0.0.0
-rwxr-xr-x  1 root root   215209 18 feb 16:29 libgnuradio-audio-alsa.so.0.0.0
-rwxr-xr-x  1 root root 1167 18 feb 16:29 libgnuradio-core.la
-rwxr-xr-x  1 root root 1248 18 feb 16:29 libgnuradio-core-qa.la
lrwxrwxrwx  1 root root   28 18 feb 16:29 libgnuradio-core-qa.so -> 
libgnuradio-core-qa.so.0.0.0
lrwxrwxrwx  1 root root   28 18 feb 16:29 libgnuradio-core-qa.so.0 -> 
libgnuradio-core-qa.so.0.0.0
-rwxr-xr-x  1 root root  2605751 18 feb 16:29 libgnuradio-core-qa.so.0.0.0
lrwxrwxrwx  1 root root   25 18 feb 16:29 libgnuradio-core.so -> 
libgnuradio-core.so.0.0.0
lrwxrwxrwx  1 root root   25 18 feb 16:29 libgnuradio-core.so.0 -> 
libgnuradio-core.so.0.0.0
-rwxr-xr-x  1 root root 20161776 18 feb 16:29 libgnuradio-core.so.0.0.0
-rwxr-xr-x  1 root root 1235 18 feb 16:29 libgnuradio-usrp2.la
lrwxrwxrwx  1 root root   26 18 feb 16:29 libgnuradio-usrp2.so -> 
libgnuradio-usrp2.so.0.0.0
lrwxrwxrwx  1 root root   26 18 feb 16:29 libgnuradio-usrp2.so.0 -> 
libgnuradio-usrp2.so.0.0.0
-rwxr-xr-x  1 root root   461125 18 feb 16:29 libgnuradio-usrp2.so.0.0.0
-rwxr-xr-x  1 root root 1234 18 feb 16:29 libgnuradio-usrp.la
lrwxrwxrwx  1 root root   25 18 feb 16:29 libgnuradio-usrp.so -> 
libgnuradio-usrp.so.0.0.0
lrwxrwxrwx  1 root root   25 18 feb 16:29 libgnuradio-usrp.so.0 -> 
libgnuradio-usrp.so.0.0.0
-rwxr-xr-x  1 root root   500172 18 feb 16:29 libgnuradio-usrp.so.0.0.0
-rwxr-xr-x  1 root root  995 18 feb 16:29 libgromnithread.la
lrwxrwxrwx  1 root root   24 18 feb 16:29 libgromnithread.so -> 
libgromnithread.so.0.0.0
lrwxrwxrwx  1 root root   24 18 feb 16:29 libgromnithread.so.0 -> 
libgromnithread.so.0.0.0
-rwxr-xr-x  1 root root65466 18 feb 16:29 libgromnithread.so.0.0.0
-rwxr-xr-x  1 root root  982 18 feb 16:29 libgruel.la
lrwxrwxrwx  1 root root   17 18 feb 16:29 libgruel.so -> libgruel.so.0.0.0
lrwxrwxrwx  1 root root   17 18 feb 16:29 libgruel.so.0 -> libgruel.so.0.0.0
-rwxr-xr-x  1 root root   373925 18 feb 16:29 libgruel.so.0.0.0
-rwxr-xr-x  1 root root 1018 18 feb 16:29 libmblock.la
-rwxr-xr-x  1 root root 1082 18 feb 16:29 libmblock-qa.la
-rwxr-xr-x  1 root root  1981252 18 feb 16:29 libmblock-qa.so
lrwxrwxrwx  1 root root   18 18 feb 16:29 libmblock.so -> libmblock.so.0.0.0
lrwxrwxrwx  1 root root   18 18 feb 16:29 libmblock.so.0 -> 
libmblock.so.0.0.0
-rwxr-xr-x  1 root root  1552783 18 feb 16:29 libmblock.so.0.0.0
-rwxr-xr-x  1 root root  975 18 feb 16:29 libpmt.la
-rwxr-xr-x  1 root root 1046 18 feb 16:29 libpmt-qa.la
lrwxrwxrwx  1 root root   18 18 feb 16:29 libpmt-qa.so -> libpmt-qa.so.0.0.0
lrwxrwxrwx  1 root root   18 18 feb 16:29 libpmt-qa.so.0 -> 
libpmt-qa.so.0.0.0
-rwxr-xr-x  1 root root  1078904 18 feb 16:29 libpmt-qa.so.0.0.0
lrwxrwxrwx  1 root root   15 18 feb 16:29 libpmt.so -> libpmt.so.0.0.0
lrwxrwxrwx  1 root root   15 18 feb 16:29 libpmt.so.0 -> libpmt.so.0.0.0
-rwxr-xr-x  1 root root  1077696 18 feb 16:29 libpmt.so.0.0.0
lrwxrwxrwx  1 root root   15 16 feb 14:25 libqwt.so -> libqwt.so.5.2.0
lrwxrwxrwx  1 root root   15 16 feb 14:25 libqwt.so.5 -> libqwt.so.5.2.0
lrwxrwxrwx  1 root root   15 16 feb 14:25 libqwt.so.5.2 -> libqwt.so.5.2.0
-rwxr-xr-x  1 root root   827064 16 feb 14:25 libqwt.so.5.2.0
-rwxr-xr-x  1 root root 1043 18 feb 16:29 libusrp2.la
lrwxrwxrwx  1 root root   17 18 feb 16:29 libusrp2.so -> libusrp2.so.0.0.0
lrwxrwxrwx  1 root root   17 18 feb 16:29 libusrp2.so.0 -> libusrp2.so.0.0.0
-rwxr-xr-x  1 root root   874936 18 feb 16:29 libusrp2.so.0.0.0
-rwxr-xr-x  1 root root  982 18 feb 16:29 libusrp.la
lrwxrwxrwx  1 root root   16 18 feb 16:29 libusrp.so -> libusrp.so.0.0.0
lrwxrwxrwx  1 root root   16 18 feb 16:29 libusrp.so.0 -> libusrp.so.0.0.0
-rwxr-xr-x  1 root root  1697156 18 feb 16:29 libusrp.so.0.0.0
drwxr-xr-x  2 root root 4096 18 feb 16:30 pkgconfig
drwxr-xr-x  3 root root 4096 16 feb 15:19 python2.6


and the topline of scripts is:

#!/usr/bin/env python

and i import ucla library with the command "from gnuradio import ucla" in the 
head of my scripts.

Others scrip

Re: [Discuss-gnuradio] Lost packet problem

2010-02-19 Thread Tom Rondeau

On Fri, Feb 19, 2010 at 12:50 AM, abbasi  wrote:
>
> Thanks a lot for your reply,
> sorry for my bad english...
>
>
> Tom Rondeau wrote:
>>
>>
>> Which modulation are you using? Are you using the
>> digita/benchmark_*.py files or is this OFDM. I'm not quite getting
>> what you mean when you're talking about the PN code (which makes it
>> sound like the OFDM code we have in the examples).
>>
>>
>
> I'm using dbpsk, through a file based on tunnel.py.
> As far as i know, the receiver is using gr_correlate_access_code_bb to slide
> the given access code (usually an M-sequence) across the demodulated bits,
> and produces two bits of output for each input bit. This is done for
> synchronization.

The access code correlator is just there to determine when the packet
start happens by looking for the preamble access code. I'm not sure if
this is what you mean by synchronization. I just always think of
synchronization in the symbol domian; that is, it does the frequency,
phase, and timing synchronization to be able to slice the symbols into
bits.

> Tom Rondeau wrote:
>>
>> Sorry, I'm really not understanding what you're doing. Are you
>> checking the CRC and sending an ACK if the CRC doesn't check out? If
>> so, that requires that you get enough good bits of the packet through
>> to first detect that it's a packet and then be able to parse it. If
>> you miss the header and length fields, you won't be able to see the
>> CRC.
>>
>
> i check the CRC, if it returns correct i send ACK, if it is not correct i
> send LOST-ACK,

Yeah, ok. But like I said, I really don't think this is a very good
way to determine when a packet is missed since this will only work
when at least most of the packet has been received. If a packet is
corrupted in the header or access code such that it is completely
overlooked by the demodulator, you'll never know it with just an
ACK/NACK scheme.

> Tom Rondeau wrote:
>>
>> This is usually solved, like in TCP, with a sequence number. You can
>> tell if you missed a packet because the sequence numbers from two
>> consecutive packets received will not match up. This way, the receiver
>> can completely drop a packet and still know it after then next packet
>> arrives.
>>
>
> I understand what are you saying. but the point is there any scheme (already
> implemented in GNURADIO) which solve this problem. or i have to do it
> manually?
>
> regards,

There has been some work done on MAC layer implementation in GNU
Radio, but there is nothing in the main repo that will do what you
want.

Tom

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

RE: [Discuss-gnuradio] RE: Timestamp value

2010-02-19 Thread Ulrika Uppman

Sorry I made a mistake, I used the wrong fpga-build and firmware when I ran the 
vrt branch. When I discovered my mistake I downloaded the files from 
http://www.ettus.com/usrp2_vrt but I cannot get the USRP2 to work with these 
files. The leds go on just as normal, but when I try to run ./find_usrps I just 
get "No USRP2 found". Does anyone know where to get the proper image files for 
the fpga and firmware?

Regards,
/Ulrika

> -Original Message-
> From: discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org 
> [mailto:discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org]
>  On Behalf Of Ulrika Uppman
> Sent: Friday, February 19, 2010 11:48 AM
> To: Per Zetterberg
> Cc: Discuss-gnuradio@gnu.org
> Subject: RE: [Discuss-gnuradio] RE: Timestamp value
> 
> Hi,
> I have now tried both the git master and the vrt branch and 
> the results there are similar to those in the 3.2 version.
> 
> I was guessing that the timestamps would be generated/handled 
> differently in the vrt branch but at a first glance I didn't 
> see any major differences in the code. What is the difference 
> with regard to timestamps and timing when using the vrt branch?
> 
> Regards,
> /Ulrika
> 
> > -Original Message-
> > From: Per Zetterberg [mailto:per.zetterb...@ee.kth.se]
> > Sent: Thursday, February 18, 2010 6:16 PM
> > To: Ulrika Uppman
> > Cc: Discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] RE: Timestamp value
> > 
> > >>
> > >> Do anyone know why the difference in timestamp value
> > between received
> > >> packets is so big? What am I missing here?
> > >>
> > >> Thanks,
> > >> /Ulrika
> > 
> > Have you tried the vrt branch by jblum ?
> > 
> > BR/
> > Per
> > 
> > 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] UCLA zigbee libraries problem

2010-02-19 Thread daniele . bertussi



Hi Mike,
i have only one version of python installed:

linux-ul3s:/usr/local/lib/python2.6/site-packages/gnuradio # python --version
Python 2.6

linux-ul3s:/usr/local/lib # ls -al
totale 32864
drwxr-xr-x  4 root root 4096 18 feb 16:29 .
drwxr-xr-x 17 root root 4096 16 feb 15:19 ..
-rwxr-xr-x  1 root root 1262 18 feb 16:29 libgnuradio-audio-alsa.la
lrwxrwxrwx  1 root root   31 18 feb 16:29 libgnuradio-audio-alsa.so -> 
libgnuradio-audio-alsa.so.0.0.0
lrwxrwxrwx  1 root root   31 18 feb 16:29 libgnuradio-audio-alsa.so.0 -> 
libgnuradio-audio-alsa.so.0.0.0
-rwxr-xr-x  1 root root   215209 18 feb 16:29 libgnuradio-audio-alsa.so.0.0.0
-rwxr-xr-x  1 root root 1167 18 feb 16:29 libgnuradio-core.la
-rwxr-xr-x  1 root root 1248 18 feb 16:29 libgnuradio-core-qa.la
lrwxrwxrwx  1 root root   28 18 feb 16:29 libgnuradio-core-qa.so -> 
libgnuradio-core-qa.so.0.0.0
lrwxrwxrwx  1 root root   28 18 feb 16:29 libgnuradio-core-qa.so.0 -> 
libgnuradio-core-qa.so.0.0.0
-rwxr-xr-x  1 root root  2605751 18 feb 16:29 libgnuradio-core-qa.so.0.0.0
lrwxrwxrwx  1 root root   25 18 feb 16:29 libgnuradio-core.so -> 
libgnuradio-core.so.0.0.0
lrwxrwxrwx  1 root root   25 18 feb 16:29 libgnuradio-core.so.0 -> 
libgnuradio-core.so.0.0.0
-rwxr-xr-x  1 root root 20161776 18 feb 16:29 libgnuradio-core.so.0.0.0
-rwxr-xr-x  1 root root 1235 18 feb 16:29 libgnuradio-usrp2.la
lrwxrwxrwx  1 root root   26 18 feb 16:29 libgnuradio-usrp2.so -> 
libgnuradio-usrp2.so.0.0.0
lrwxrwxrwx  1 root root   26 18 feb 16:29 libgnuradio-usrp2.so.0 -> 
libgnuradio-usrp2.so.0.0.0
-rwxr-xr-x  1 root root   461125 18 feb 16:29 libgnuradio-usrp2.so.0.0.0
-rwxr-xr-x  1 root root 1234 18 feb 16:29 libgnuradio-usrp.la
lrwxrwxrwx  1 root root   25 18 feb 16:29 libgnuradio-usrp.so -> 
libgnuradio-usrp.so.0.0.0
lrwxrwxrwx  1 root root   25 18 feb 16:29 libgnuradio-usrp.so.0 -> 
libgnuradio-usrp.so.0.0.0
-rwxr-xr-x  1 root root   500172 18 feb 16:29 libgnuradio-usrp.so.0.0.0
-rwxr-xr-x  1 root root  995 18 feb 16:29 libgromnithread.la
lrwxrwxrwx  1 root root   24 18 feb 16:29 libgromnithread.so -> 
libgromnithread.so.0.0.0
lrwxrwxrwx  1 root root   24 18 feb 16:29 libgromnithread.so.0 -> 
libgromnithread.so.0.0.0
-rwxr-xr-x  1 root root65466 18 feb 16:29 libgromnithread.so.0.0.0
-rwxr-xr-x  1 root root  982 18 feb 16:29 libgruel.la
lrwxrwxrwx  1 root root   17 18 feb 16:29 libgruel.so -> libgruel.so.0.0.0
lrwxrwxrwx  1 root root   17 18 feb 16:29 libgruel.so.0 -> libgruel.so.0.0.0
-rwxr-xr-x  1 root root   373925 18 feb 16:29 libgruel.so.0.0.0
-rwxr-xr-x  1 root root 1018 18 feb 16:29 libmblock.la
-rwxr-xr-x  1 root root 1082 18 feb 16:29 libmblock-qa.la
-rwxr-xr-x  1 root root  1981252 18 feb 16:29 libmblock-qa.so
lrwxrwxrwx  1 root root   18 18 feb 16:29 libmblock.so -> libmblock.so.0.0.0
lrwxrwxrwx  1 root root   18 18 feb 16:29 libmblock.so.0 -> 
libmblock.so.0.0.0
-rwxr-xr-x  1 root root  1552783 18 feb 16:29 libmblock.so.0.0.0
-rwxr-xr-x  1 root root  975 18 feb 16:29 libpmt.la
-rwxr-xr-x  1 root root 1046 18 feb 16:29 libpmt-qa.la
lrwxrwxrwx  1 root root   18 18 feb 16:29 libpmt-qa.so -> libpmt-qa.so.0.0.0
lrwxrwxrwx  1 root root   18 18 feb 16:29 libpmt-qa.so.0 -> 
libpmt-qa.so.0.0.0
-rwxr-xr-x  1 root root  1078904 18 feb 16:29 libpmt-qa.so.0.0.0
lrwxrwxrwx  1 root root   15 18 feb 16:29 libpmt.so -> libpmt.so.0.0.0
lrwxrwxrwx  1 root root   15 18 feb 16:29 libpmt.so.0 -> libpmt.so.0.0.0
-rwxr-xr-x  1 root root  1077696 18 feb 16:29 libpmt.so.0.0.0
lrwxrwxrwx  1 root root   15 16 feb 14:25 libqwt.so -> libqwt.so.5.2.0
lrwxrwxrwx  1 root root   15 16 feb 14:25 libqwt.so.5 -> libqwt.so.5.2.0
lrwxrwxrwx  1 root root   15 16 feb 14:25 libqwt.so.5.2 -> libqwt.so.5.2.0
-rwxr-xr-x  1 root root   827064 16 feb 14:25 libqwt.so.5.2.0
-rwxr-xr-x  1 root root 1043 18 feb 16:29 libusrp2.la
lrwxrwxrwx  1 root root   17 18 feb 16:29 libusrp2.so -> libusrp2.so.0.0.0
lrwxrwxrwx  1 root root   17 18 feb 16:29 libusrp2.so.0 -> libusrp2.so.0.0.0
-rwxr-xr-x  1 root root   874936 18 feb 16:29 libusrp2.so.0.0.0
-rwxr-xr-x  1 root root  982 18 feb 16:29 libusrp.la
lrwxrwxrwx  1 root root   16 18 feb 16:29 libusrp.so -> libusrp.so.0.0.0
lrwxrwxrwx  1 root root   16 18 feb 16:29 libusrp.so.0 -> libusrp.so.0.0.0
-rwxr-xr-x  1 root root  1697156 18 feb 16:29 libusrp.so.0.0.0
drwxr-xr-x  2 root root 4096 18 feb 16:30 pkgconfig
drwxr-xr-x  3 root root 4096 16 feb 15:19 python2.6


and the topline of scripts is:

#!/usr/bin/env python

and i import ucla library with the command "from gnuradio import ucla" in the 
head of my scripts.

Others scripts work normally, i import libraries with classical commands like "from 
gnuradio import gr" etc.

what's wrong?



Citando Mike Jameson :


Hi Daniele,

Do you have two versions of python installed?

the line at the top of the script you are trying to run may have:

# /usr/

Re: [Discuss-gnuradio] GNURadio fresh Linux installation and usrp_benchmark_usb.py error

2010-02-19 Thread Alexandru Csete

On 19 February 2010 12:05, Fabrizio Tappero  wrote:
> Hello,
> I just would like to clarified for others that I figured out what the
> problem was but I have no solution for it.
> The problem "usrp: failed to find usrp[0]" is (I think) caused by
> Virtual Box and the way the control of USB connections is passed (or
> not passed) through. I do not know how to tell Virtual Box to pass,
> for instance, all USB connections to the guest OS.
>
> If anybody uses Virtual Box and a Linux guest OS with GNURadio please advise.

Hi Fabrizio,

I tried this some time ago with Ubuntu 9.04 as guest OS. I remember I
had to explicitly enable USB devices individually. I did that via
Devices->USB Devices in the main menubar after I plugged in the USRP
(I think you can also do that if you click on the small USB connector
icon at the bottom of the VM window).
It was running (http://twitpic.com/wyylv) but performance on my iMac
was very slow. I couldn't make 3D acceleration work and the VM
couldn't keep up with USRP data rates except with decimation rates >
250, so I abandoned that experiment.

Alex

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

[Discuss-gnuradio] UCLA zigbee libraries problem

2010-02-19 Thread daniele . bertussi



Good morning,
i have installed on OpenSUSE 11.1  first gnuradio 3.2 and then the project 
ucla_zigbee_phy using the official installation guide: 
https://www.cgran.org/wiki/UCLAZigBee#ProjectDescription

but when a try to run an example, python return this error:

linux-ul3s:/home/sdr3/ucla_zigbee_phy/src/examples # python cc1k_rxtest.py
Traceback (most recent call last):
  File "cc1k_rxtest.py", line 46, in 
from gnuradio import ucla
ImportError: cannot import name ucla


but the "ucla library" is in the same directory like others gnuradio libraries:

linux-ul3s:/home/sdr3/ucla_zigbee_phy/src/examples # echo $PYTHONPATH
/usr/local/lib/python2.6/site-packages

linux-ul3s:/usr/local/lib/python2.6/site-packages/gnuradio # ls -al
totale 1124
drwxr-xr-x 14 root root   4096 19 feb 11:46 .
drwxr-xr-x  4 root root   4096 16 feb 15:19 ..
drwxr-xr-x  2 root root   4096 18 feb 09:18 blks
drwxr-xr-x  2 root root   4096 18 feb 09:18 blks2
drwxr-xr-x  2 root root   4096 18 feb 09:18 blks2impl
drwxr-xr-x  2 root root   4096 18 feb 09:18 blksimpl
drwxr-xr-x  2 root root   4096 18 feb 09:18 gpio
drwxr-xr-x  2 root root   4096 18 feb 09:18 gr
drwxr-xr-x  2 root root   4096 18 feb 09:18 gru
drwxr-xr-x  2 root root   4096 18 feb 09:18 gruimpl
drwxr-xr-x  2 root root   4096 18 feb 09:18 pager
drwxr-xr-x  2 root root   4096 18 feb 16:34 ucla_blks
-rwxr-xr-x  1 root root   1194 18 feb 16:34 _ucla.la
-rw-r--r--  1 root root  26768 18 feb 16:34 ucla.py
-rw-r--r--  1 root root  45786 18 feb 16:34 ucla.pyc
-rw-r--r--  1 root root  45786 18 feb 16:34 ucla.pyo
-rwxr-xr-x  1 root root 956207 18 feb 16:34 _ucla.so
drwxr-xr-x  2 root root   4096 18 feb 09:18 vocoder
drwxr-xr-x  2 root root   4096 18 feb 09:18 wxgui



Others gnuradio's example scripts  seem run normally.
What can i do? Thanks a lot

Daniele Bertussi - University of Brescia

P.S. I add the results of ./configure of gnuradio and ucla_zigbee_phy:

---
linux-ul3s:/home/sdr3/gnuradio-3.2 # ./configure
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for library containing strerror... none required
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking whether C++ has std::isnan... yes
checking gr_libdir_suffix...
checking whether to append 64 to libdir... no
checking whether gcc accepts -Wall... yes
checking whether gcc accepts -Werror-implicit-function-declaration... yes
checking whether g++ accepts -Wall... yes
checking whether g++ accepts -Woverloaded-virtual... yes
checking whether user wants gprof... no
checking whether user wants prof... no
checking dependency style of gcc... gcc3
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for rm... /bin/rm
checking for a sed that does not truncate output... /usr/bin/sed
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/i586-suse-linux/bin/ld
checking if the linker (/usr/i586-suse-linux/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI construct

[Discuss-gnuradio] UCLA zigbee libraries problem

2010-02-19 Thread daniele . bertussi



Good morning,
i have installed on OpenSUSE 11.1  first gnuradio 3.2 and then the project 
ucla_zigbee_phy using the official installation guide: 
https://www.cgran.org/wiki/UCLAZigBee#ProjectDescription

but when a try to run an example, python return this error:

linux-ul3s:/home/sdr3/ucla_zigbee_phy/src/examples # python cc1k_rxtest.py
Traceback (most recent call last):
  File "cc1k_rxtest.py", line 46, in 
from gnuradio import ucla
ImportError: cannot import name ucla


but the "ucla library" is in the same directory like others gnuradio libraries:

linux-ul3s:/home/sdr3/ucla_zigbee_phy/src/examples # echo $PYTHONPATH
/usr/local/lib/python2.6/site-packages

linux-ul3s:/usr/local/lib/python2.6/site-packages/gnuradio # ls -al
totale 1124
drwxr-xr-x 14 root root   4096 19 feb 11:46 .
drwxr-xr-x  4 root root   4096 16 feb 15:19 ..
drwxr-xr-x  2 root root   4096 18 feb 09:18 blks
drwxr-xr-x  2 root root   4096 18 feb 09:18 blks2
drwxr-xr-x  2 root root   4096 18 feb 09:18 blks2impl
drwxr-xr-x  2 root root   4096 18 feb 09:18 blksimpl
drwxr-xr-x  2 root root   4096 18 feb 09:18 gpio
drwxr-xr-x  2 root root   4096 18 feb 09:18 gr
drwxr-xr-x  2 root root   4096 18 feb 09:18 gru
drwxr-xr-x  2 root root   4096 18 feb 09:18 gruimpl
drwxr-xr-x  2 root root   4096 18 feb 09:18 pager
drwxr-xr-x  2 root root   4096 18 feb 16:34 ucla_blks
-rwxr-xr-x  1 root root   1194 18 feb 16:34 _ucla.la
-rw-r--r--  1 root root  26768 18 feb 16:34 ucla.py
-rw-r--r--  1 root root  45786 18 feb 16:34 ucla.pyc
-rw-r--r--  1 root root  45786 18 feb 16:34 ucla.pyo
-rwxr-xr-x  1 root root 956207 18 feb 16:34 _ucla.so
drwxr-xr-x  2 root root   4096 18 feb 09:18 vocoder
drwxr-xr-x  2 root root   4096 18 feb 09:18 wxgui



Others gnuradio's example scripts  seem run normally.
What can i do? Thanks a lot

Daniele Bertussi - University of Brescia

P.S. I add the results of ./configure of gnuradio and ucla_zigbee_phy:

---
linux-ul3s:/home/sdr3/gnuradio-3.2 # ./configure
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for library containing strerror... none required
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking whether C++ has std::isnan... yes
checking gr_libdir_suffix...
checking whether to append 64 to libdir... no
checking whether gcc accepts -Wall... yes
checking whether gcc accepts -Werror-implicit-function-declaration... yes
checking whether g++ accepts -Wall... yes
checking whether g++ accepts -Woverloaded-virtual... yes
checking whether user wants gprof... no
checking whether user wants prof... no
checking dependency style of gcc... gcc3
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for rm... /bin/rm
checking for a sed that does not truncate output... /usr/bin/sed
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/i586-suse-linux/bin/ld
checking if the linker (/usr/i586-suse-linux/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI construct

Re: [Discuss-gnuradio] GNURadio fresh Linux installation and usrp_benchmark_usb.py error

2010-02-19 Thread Fabrizio Tappero

Hello,
I just would like to clarified for others that I figured out what the
problem was but I have no solution for it.
The problem "usrp: failed to find usrp[0]" is (I think) caused by
Virtual Box and the way the control of USB connections is passed (or
not passed) through. I do not know how to tell Virtual Box to pass,
for instance, all USB connections to the guest OS.

If anybody uses Virtual Box and a Linux guest OS with GNURadio please advise.

Thanks
Fabrizio
PS btw, I installed GNURadio and USRP in a normal Linux machine and
everything works beautifully, well done you all (especially the main
developers) for this incredible tool !


On Thu, Feb 18, 2010 at 12:50 PM, Fabrizio Tappero
 wrote:
> Hello,
> I believe I am.
> fabri...@ftdev:~$ id fabrizio
> uid=1000(fabrizio) gid=1000(fabrizio)
> groups=1000(fabrizio),4(adm),20(dialout),24(cdrom),46(plugdev),104(lpadmin),115(admin),120(sambashare),1001(usrp)
>
> Could you please suggest what can be the most basic technique to
> understand whether the whole GNU radio installation plus USRP HW is
> properly functioning? Right now I am having the basicTx connected to
> an oscilloscope and I am  trying to generate a simple signal with this
> python code:
>
> #!/usr/bin/python
> # Title       : BasicTX.py
> # Function    : Create test signal on the BasicTX / BasicHF  Daughter board
> # Author      : Pascal Schiks (C) 2008 gnu/gpl
> # explanation : http://www.gnuradio.eu/examples/BasicHF/BasicTx.html
>
> from gnuradio import gr
> from gnuradio import usrp
> from gnuradio.wxgui import stdgui2, fftsink2
>
> # Main Graph
> class pmr_graph(stdgui2.std_top_block):
>
>        # Constructor
>        def __init__(self, frame, panel, vbox, argv):
>                stdgui2.std_top_block.__init__(self, frame, panel, vbox, argv)
>
>                tx_frequency = 705
>                usrp_tx_rate = 12800
>                usrp_tx_interpolation = 400
>                tx_side = 1
>                tx_dev = 1
>
>                # Transmitter
>                usrp_tx_sample_rate = usrp_tx_rate / usrp_tx_interpolation
>                usrp_tx = usrp.sink_c(which=0, 
> interp_rate=usrp_tx_interpolation)
>                mux = usrp.determine_tx_mux_value(usrp_tx,(tx_side,tx_dev))
>                usrp_tx.set_mux(mux)
>
>                usrp_tx_subdev = usrp.selected_subdev(usrp_tx,(tx_side,tx_dev))
>                usrp_tx.tune(0,usrp_tx_subdev, tx_frequency)
>
>                # rf
>                rf = gr.sig_source_c(usrp_tx_sample_rate, 
> gr.GR_SIN_WAVE,500,16000, 0)
>
>                # Connect all
>                self.connect(rf, usrp_tx)
>
> # Main caller program
> if __name__ == '__main__':
>        aplication = stdgui2.stdapp(pmr_graph,"BasicTX")
>        aplication.MainLoop()
>
>
> This is the error I get:
>
> fabri...@ftdev:~/GNURadio/tmp$ ./BasicTX.py
> usrp: failed to find usrp[0]
> Traceback (most recent call last):
>  File "./BasicTX.py", line 41, in 
>    aplication = stdgui2.stdapp(pmr_graph,"BasicTX")
>  File "/usr/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py",
> line 36, in __init__
>    wx.App.__init__ (self, redirect=False)
>  File "/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
> line 7978, in __init__
>    self._BootstrapApp()
>  File "/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
> line 7552, in _BootstrapApp
>    return _core_.PyApp__BootstrapApp(*args, **kwargs)
>  File "/usr/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py",
> line 39, in OnInit
>    frame = stdframe (self.top_block_maker, self.title, self._nstatus)
>  File "/usr/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py",
> line 60, in __init__
>    self.panel = stdpanel (self, self, top_block_maker)
>  File "/usr/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py",
> line 81, in __init__
>    self.top_block = top_block_maker (frame, self, vbox, sys.argv)
>  File "./BasicTX.py", line 26, in __init__
>    usrp_tx = usrp.sink_c(which=0, interp_rate=usrp_tx_interpolation)
>  File "/usr/lib/python2.6/dist-packages/gnuradio/usrp/usrp_swig.py",
> line 2412, in sink_c
>    return _usrp_swig.sink_c(*args, **kwargs)
> RuntimeError: can't open usrp
>
>
> Here is what I have noticed:
> 1) the green led in the USRP is still blinking fast => proper firmware
> is no properly uploaded. In fact the ID of the USB port is still the
> generic one.
> 2) Command ls -lR /dev/bus/usb | grep usrp does not work anymore
> 3) unlike what suggested in GNU Radio website installation
> (http://gnuradio.org/redmine/wiki/1/DebianPackages), the command
> usrper seems to be missing in the ubuntu installation (that you get
> using deb http://gnuradio.org/ubuntu stable main)
> 4) I tried the command "lsusrp" nd the result is:
>
> usrp_open_interface:usb_set_alt_interface: failed
> could not set alt intf 0/0: Connection timed out
> open_nth_cmd_interface: open_cmd_interface failed
> usrp: failed to load firmware /usr/share/usrp/rev4/std.ihx.
> usrp: failed to find

RE: [Discuss-gnuradio] Timestamp value

2010-02-19 Thread Ulrika Uppman

Tim,
thanks for your reply.

I thought the packets always had the same size (specified by U2_MAX_SAMPLES), 
or am I wrong here? I also do get the very same timestamp diff when running 
rx_streaming_samples with N= 400, 4000, 6000, 6 etc.

I don't quite follow you on what will happen when calling the handler multiple 
times? I print the timestamps in usrp2_impl handle_data_packet which I thought 
would be run every time (once) a new ethernet packet arrives which isn't a 
control packet?

(And yes the timestamps are treated as uint32's.)

Regards,
/Ulrika


From: Tim Pearce [mailto:timothy.pea...@gmail.com]
Sent: Thursday, February 18, 2010 9:35 PM
To: Ulrika Uppman
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Timestamp value

Ulrika,

I agree with how you think the timestamps are generated -- it seems to work for 
me that way anyway!

I did it with a custom source block that added the counter*decimation rate 
after the first sample, the trap I fell into there is that (particuarly at 
lower decimation rates) rx_*_handler() can be called multiple times per 
instance of it.

Are the timestamps being treated as UINT32's?

400 samples is quite low, I think the packets are usually bigger than that (I 
might be wrong, its been a while since I looked into that).

Cheers,

Tim

On Thu, Feb 18, 2010 at 4:10 PM, Ulrika Uppman 
mailto:ulrika.upp...@foi.se>> wrote:
Hi,
I wonder how the timestamps are being generated for each ethernet-packet sent 
from the USRP2 to the host? My initial idea about how it works was that 
timestamps are generated at 100MHz (same as the samples) and then the timestamp 
associated with the first sample in an ethernet data packet will be put in the 
metadata which could then be unpacked in the host. I then would assume that the 
next packet after the first one will have a timestamp value that is 
proportional to the number of samples per packet times the decimation rate. 
However I get timestamp values that increase much much more for each received 
packet, so I wonder if my idea of how timestamps are generated is wrong?

I run the stable 3.2 version of gnuradio on Ubuntu 9.04 and I have an USRP2 
with the RFX2400. (I also was going to try the gnuradio trunk but I got 
problems with building, see my other post "Error on make from git development 
trunk"). I tried both an old version of the fpga bin-file and one that I just 
recently downloaded (but both gave the same result).

I put some printouts in usrp2_impl.cc in the handle_data_packet function and 
the output when I run rx_streaming_samples then looks like this:
./rx_streaming_samples -f 2457e6 -d 16 -N 400 -v
...
Daughterboard configuration:
 baseband_freq=245625.00
  ddc_freq=-75.00
 residual_freq=-0.016764
  inverted=no

USRP2 using decimation rate of 16
Receiving 400 samples

ts_in = 1435221596, ts_last = 0, diff = 1435221596
ts_in = 2560802396, ts_last = 1435221596, diff = 1125580800
ts_in = 3367616092, ts_last = 2560802396, diff = 806813696
ts_in = 4174429788, ts_last = 3367616092, diff = 806813696
ts_in = 686341724, ts_last = 4174429788, diff = 806879232
ts_in = 1493155420, ts_last = 686341724, diff = 806813696
ts_in = 2283192156, ts_last = 1493155420, diff = 790036736
ts_in = 3090005852, ts_last = 2283192156, diff = 806813696
ts_in = 3896819548, ts_last = 3090005852, diff = 806813696
ts_in = 408731484, ts_last = 3896819548, diff = 806879232

Copy handler called 2 times.
Copy handler called with 2968 bytes.

Elapsed time was 0.000 seconds.
Packet rate was 10 pkts/sec.
Approximate throughput was 148.40 MB/sec.
Total instances of overruns was 0.
Total missing frames was 0.
...

ts_in is the timestamp found in the metadata of the packet just received, 
ts_last is the one from previous packet and diff is just the difference them 
between. Since there seems to be no missing frames I'm guessing the big value 
of diff can't be related to lost packets?
If I try different decimation rates, I see no obvious relation between the 
difference in value between two timestamps...

Do anyone know why the difference in timestamp value between received packets 
is so big? What am I missing here?

Thanks,
/Ulrika

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

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

RE: [Discuss-gnuradio] RE: Timestamp value

2010-02-19 Thread Ulrika Uppman

Hi, 
I have now tried both the git master and the vrt branch and the results there 
are similar to those in the 3.2 version.

I was guessing that the timestamps would be generated/handled differently in 
the vrt branch but at a first glance I didn't see any major differences in the 
code. What is the difference with regard to timestamps and timing when using 
the vrt branch?

Regards,
/Ulrika

> -Original Message-
> From: Per Zetterberg [mailto:per.zetterb...@ee.kth.se] 
> Sent: Thursday, February 18, 2010 6:16 PM
> To: Ulrika Uppman
> Cc: Discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] RE: Timestamp value
> 
> >>
> >> Do anyone know why the difference in timestamp value 
> between received 
> >> packets is so big? What am I missing here?
> >>
> >> Thanks,
> >> /Ulrika
> 
> Have you tried the vrt branch by jblum ?
> 
> BR/
> Per
> 
> 

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

RE: [Discuss-gnuradio] Error on make from git development trunk

2010-02-19 Thread Ulrika Uppman

As also hinted I probably could have managed without the gr-pager and just 
configured with --disable-gr-pager, but now when the problem is fixed 
everything compiles fine without any errors!

Thanks!

> -Original Message-
> From: Johnathan Corgan [mailto:jcor...@corganenterprises.com] 
> Sent: Thursday, February 18, 2010 8:17 PM
> To: Veljko Pejovic
> Cc: Ulrika Uppman; Discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Error on make from git 
> development trunk
> 
> On Thu, 2010-02-18 at 11:07 -0800, Veljko Pejovic wrote:
> 
> > Although I got it working sometimes, the method didn't work 
> on every 
> > machine I tried it on. And yes, make sure you don't have 
> any previous 
> > gnuradio builds in the path.
> 
> This has been fixed in git master by using an absolute path 
> instead of a relative path in the Makefile.am.  Thanks.
> 
> Johnathan
> 
> 

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

[Discuss-gnuradio] Rx/Tx with XCVR2450 over one antenna

2010-02-19 Thread Christian Kisters

Hi All

I have a USRP2 with the XCVR2450 daughterboard and want to sent and receive
data over the same antenna (TDD). 
I write my application in C and want to know if it's possible to change the
settings in my application to receive over one antenna or must I rewrite the
firmware? 
When I must rewrite the firmware, where are the needed settings? I don't
have found any by searching the code.
I'm using the newest firmware and fpga _3.3git-594-g02616cf8.bin. 

Thanks.
Best Regards 
Christian




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

Re: [Discuss-gnuradio] FLEX900 RX2 Port

[Discuss-gnuradio] Custom block problem on OSX 10.6

Re: [Discuss-gnuradio] Timestamp value

Re: [Discuss-gnuradio] GNU Radio and OS X installation - path problem?

[Discuss-gnuradio] how to set the bit time ?

[Discuss-gnuradio] GNU Radio and OS X installation - path problem?

Re: [Discuss-gnuradio] RE: Timestamp value

Re: [Discuss-gnuradio] UCLA zigbee libraries problem

Re: [Discuss-gnuradio] Lost packet problem

RE: [Discuss-gnuradio] RE: Timestamp value

Re: [Discuss-gnuradio] UCLA zigbee libraries problem

Re: [Discuss-gnuradio] GNURadio fresh Linux installation and usrp_benchmark_usb.py error

[Discuss-gnuradio] UCLA zigbee libraries problem

[Discuss-gnuradio] UCLA zigbee libraries problem

Re: [Discuss-gnuradio] GNURadio fresh Linux installation and usrp_benchmark_usb.py error

RE: [Discuss-gnuradio] Timestamp value

RE: [Discuss-gnuradio] RE: Timestamp value

RE: [Discuss-gnuradio] Error on make from git development trunk

[Discuss-gnuradio] Rx/Tx with XCVR2450 over one antenna

19 matches

Site Navigation

Mail list logo

Footer information