[Discuss-gnuradio] Strange overflow problem on USRP N2XX
Hi all, Now I'm using several USRP N200 and N210 to build an observation network. I have bought several new computers, which are exactly the same. When I connect a USRP N210 with one computer, it has overflow problem (occasionally print 'O'). However, when I connect the same USRP with another computer (exactly the same model), it does not have such problem. Several months ago, when I used a USRP N200, it also had similar problem. When I connect the USRP to a laptop (a very new and fast one), it occasionally has overflow problem. However, when I connect it to other computers (some of them are very old and slow), it did not have the problem. This really bothers me because I don't know what is the reason of this problem, so we are not sure what computers we should buy in future operation. Does anyone have any clue? Wu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio on OS X 10.8.1: 'make test' does fail on many tests
Hi all
I'm trying to use GNU Radio (3.6.2) on OS X 10.8.1. It does
build with some warnings and 'make test' does create many errors.
It
seems that python crashes while performing 'make test' as I do receive
Mac OS X crash reports
I'm not sure if python is setup correctly as
'cmake ../' does find the PyhtonLibs at /usr/lib/libpython2.7.dylib
(macports does install everything below /opt).
Running python from
console does work ok. Also I'm able to execute help('modules') in the
python console to verify all the dependencies.
I've red all the OSX
Installation Guides available, but in my case they are not suitable for
the new cmake type.
I did install all the dependencies through macports
and then I followed the installation instructions "Installing manually
from source".
What do you suggest? Shall I try an installation via
homebrew-gnuradio or is there a chance to fix this issue?
I hope it is
not to specific to OS X 10.8.1... But all the software like clang was
installed through macports, which seems to be compiled from source.
I
did receive my first radio (Elecraft KX3) some days ago and am looking
forward to operate this SDR using GNU Radio.
Below are some details
about my setup. Let me know if I shall provide other information.
Best
wishes
Luca HB9FFE
--
MacBookPro:build$ uname -a
Darwin
MacBookPro.local 12.1.0 Darwin Kernel Version 12.1.0: Tue Aug 14
13:29:55 PDT 2012; root:xnu-2050.9.2~1/RELEASE_X86_64
x86_64
MacBookPro:build$ arch
i386
MacBookPro:build$ clang -v
clang
version 3.1 (branches/release_31)
Target:
x86_64-apple-darwin12.1.0
Thread model: posix
MacBookPro:gnuradio$
cmake --version
cmake version 2.8.9
MacBookPro:gnuradio$ python
Python 2.7.3 (default, Sep 16 2012, 00:02:58)
[GCC 4.2.1 Compatible
Apple Clang 4.0 ((tags/Apple/clang-421.0.60))] on darwin
Type "help",
"copyright", "credits" or "license" for more information.
>>> quit()
MacBookPro:build$ more ~/.bash_profile
export
PATH=/opt/local/bin:/opt/local/sbin:$PATH
export
MANPATH=/opt/local/share/man:${MANPATH}
export
INFOPATH=/opt/local/share/info:${INFOPATH}
export
PKG_CONFIG_PATH=/opt/local/lib/pkgconfig:${PKG_CONFIG_PATH}
export
CC=clang
export CXX=clang++
export F77=gfortran-mp-4.5
export
LDFLAGS="-L/opt/local/lib ${LDFLAGS}"
export PYTHON_VERSION=`python -V
2>&1 | sed -e 's@.@ @2' | awk '{ print $2 }'`
export PYTHON_ROOT=`which
python | sed -e 's@/bin/python@@g'`
export
PYTHONPATH=${PYTHON_ROOT}/lib/python${PYTHON_VERSION}/site-packages
if
[ ${PYTHON_ROOT} != "/usr/include" ]; then
export
PYTHONPATH=${PYTHONPATH}:/usr/local/lib/python${PYTHON_VERSION}/site-packages
fi MacBookPro:build$ cmake ../
-- The CXX compiler identification is
Clang 3.1.0
-- The C compiler identification is Clang 3.1.0
-- Check
for working CXX compiler: /opt/local/bin/clang++
-- Check for working
CXX compiler: /opt/local/bin/clang++ -- works
-- Detecting CXX compiler
ABI info
-- Detecting CXX compiler ABI info - done
-- Check for
working C compiler: /opt/local/bin/clang
-- Check for working C
compiler: /opt/local/bin/clang -- works
-- Detecting C compiler ABI
info
-- Detecting C compiler ABI info - done
-- Build type not
specified: defaulting to release.
-- Found Git: /usr/bin/git
--
Extracting version information from git describe...
-- Found
PythonLibs: /usr/lib/libpython2.7.dylib (found version "2.7.2")
--
Found SWIG: /opt/local/bin/swig (found version "2.0.8")
-- Minimum SWIG
version required is 1.3.31
--
##
-- # Gnuradio
enabled components
--
##
-- *
python-support
-- * testing-support
-- * volk
-- * doxygen
-- *
gruel
-- * gnuradio-core
-- * gnuradio-companion
-- * gr-fft
-- *
gr-filter
-- * gr-atsc
-- * gr-audio
-- * gr-digital
-- * gr-noaa
-- * gr-pager
-- * gr-qtgui
-- * gr-trellis
-- * gr-utils
-- *
gr-video-sdl
-- * gr-vocoder
-- * gr-fcd
-- * gr-wavelet
-- *
gr-wxgui
--
-- ##
-- # Gnuradio disabled components
--
##
-- * sphinx
--
* gr-comedi
-- * gr-uhd
-- * gr-shd --
-- Using install prefix:
/usr/local
-- Building for version: v3.6.2-3-gc85bd69a / 3.6.3git
--
Configuring done
-- Generating done
MacBookPro:build$ make test
4% tests passed, 137 tests failed out of 143
Total Test time (real)
= 65.74 sec
The following tests FAILED:
3 - qa_pmt (Failed)
6 -
qa_add_and_friends (Failed)
7 - qa_add_v_and_friends (Failed)
8 -
qa_agc (Failed)
9 - qa_argmax (Failed)
10 - qa_bin_statistics
(Failed)
11 - qa_boolean_operators (Failed)
12 - qa_complex_to_xxx
(Failed)
13 - qa_conjugate (Failed)
14 - qa_copy (Failed)
15 -
qa_dc_blocker (Failed)
16 - qa_delay (Failed)
17 - qa_diff_encoder
(Failed)
18 - qa_diff_phasor_cc (Failed)
19 - qa_ecc_ccsds_27
(Failed)
20 - qa_endian_swap (Failed)
21 - qa_feval (Failed)
22 -
qa_fft (Failed)
2
Re: [Discuss-gnuradio] Strange overflow problem on USRP N2XX
Hi,
I made more tests, and even stranger things happened. Let me clarify this
problem all over again.
I have two USRP (N210 Rev.4) (Let's say U1 and U2) with LFRX daughterboard,
and two computers (Endeavo ST160E) (Let's say P1 and P2).
First, U1 is connected with P1 and running test code (see below) works well.
U2 is connected with P2, and running the code below prints 'O', indicating
overflow problem.
Then, I connect U1 to P2. Overflow problem happens again, and printing of
'O' becomes more frequent.
Then, I connect U2 to P2. Same as above, frequent printing of 'O'.
Then I rebooted P2, and connect it with U1. No overflow problem.
Then I connect P2 with U2. Again there is overflow problem.
Then I rebooted P2 again, and connect it to U2. No overflow problem again.
For P1, there is always overflow problem even if I reboot it and no matter
it is connected with U1 or U2.
This is the code for making tests:
###code##
#!/usr/bin/env python
from gnuradio import gr
from gnuradio import uhd
import time
from time import sleep
from struct import unpack
samp_rate = 4e6
gain = 0
class trig_with_pretrig(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
self.source = uhd.usrp_source(device_addr="",
stream_args=uhd.stream_args('sc16', 'sc16', args="scalar=1024"))
self.source.set_samp_rate(samp_rate)
self.source.set_gain(gain)
self.source.set_center_freq(0)
self.queue = gr.msg_queue()
self.sink = gr.message_sink(gr.sizeof_short*2, self.queue,
False)
self.connect(self.source, self.sink)
if __name__=="__main__":
tb = trig_with_pretrig()
tb.start()
while True:
#Test speed of computer
tb.queue.flush()
for i in range(1000):
msg = tb.queue.delete_head()
payload = msg.to_string()
loadLen = int(msg.arg2())
format = str(loadLen*2)+'h'
data = unpack(format, payload)
datach1 = data[0::2]
dataMax = max(datach1)
wait_len = tb.queue.count()
sleep(1)
##code
When there is overflow problem, it is like this:
lrg@lrg:~$ ./test_overflow.py
linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.003-224-gc2e197c0
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1448 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO Found a Jackson Labs GPS
-- found
-- Setting references to the internal GPSDO
-- Initializing time to the internal GPSDO
OO
Anyone has any clue what might be the reason for this overflow problem?
Any suggestion is appreciated.
Wu
From: discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.org
[mailto:discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.or
g] On Behalf Of Ting Wu
Sent: Tuesday, September 18, 2012 5:36 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Strange overflow problem on USRP N2XX
Hi all,
Now I'm using several USRP N200 and N210 to build an observation network.
I have bought several new computers, which are exactly the same.
When I connect a USRP N210 with one computer, it has overflow problem
(occasionally print 'O').
However, when I connect the same USRP with another computer (exactly the
same model), it does not have such problem.
Several months ago, when I used a USRP N200, it also had similar problem.
When I connect the USRP to a laptop (a very new and fast one), it
occasionally has overflow problem.
However, when I connect it to other computers (some of them are very old and
slow), it did not have the problem.
This really bothers me because I don't know what is the reason of this
problem, so we are not sure what computers we should buy in future
operation.
Does anyone have any clue?
Wu
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio on OS X 10.8.1: 'make test' does fail on many tests
Hi Gian - You are probable encountering the PYTHON issue many of us OSX users
have had as well. If you do "grep PYTHON CMakeCache.txt" in the top-level
build directory, you should see included the following variables, set to
something:
PYTHON_EXECUTABLE:FILEPATH=
PYTHON_INCLUDE_DIR:PATH=
PYTHON_LIBRARY:FILEPATH=
These 3 variables need to refer to the same Python install. For example, I'm
using Python 2.7 from MacPorts set specifically, and so I get back:
PYTHON_EXECUTABLE:FILEPATH=/opt/local/bin/python
PYTHON_INCLUDE_DIR:PATH=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
PYTHON_LIBRARY:FILEPATH=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib
If yours do not match up, then you can change that behavior by setting them on
the cmake command line; for example, what I use is (watching wrap):
cmake .. -DPYTHON_EXECUTABLE=/opt/local/bin/python
-DPYTHON_INCLUDE_DIR=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
-DPYTHON_LIBRARY=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib
If this doesn't help, then email me off-list and I'll help you debug the issue.
- MLD
On Sep 18, 2012, at 5:12 AM, Gian Luca Decurtins wrote:
> Hi all
>
> I'm trying to use GNU Radio (3.6.2) on OS X 10.8.1. It does build with some
> warnings and 'make test' does create many errors.
>
> It seems that python crashes while performing 'make test' as I do receive Mac
> OS X crash reports
>
> I'm not sure if python is setup correctly as 'cmake ../' does find the
> PyhtonLibs at /usr/lib/libpython2.7.dylib (macports does install everything
> below /opt).
> Running python from console does work ok. Also I'm able to execute
> help('modules') in the python console to verify all the dependencies.
>
> I've red all the OSX Installation Guides available, but in my case they are
> not suitable for the new cmake type.
> I did install all the dependencies through macports and then I followed the
> installation instructions "Installing manually from source".
>
> What do you suggest? Shall I try an installation via homebrew-gnuradio or is
> there a chance to fix this issue?
> I hope it is not to specific to OS X 10.8.1... But all the software like
> clang was installed through macports, which seems to be compiled from source.
>
> I did receive my first radio (Elecraft KX3) some days ago and am looking
> forward to operate this SDR using GNU Radio.
>
> Below are some details about my setup. Let me know if I shall provide other
> information.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Weird noise using RFX2400
Hi All, I have used RFX2400+N210 to sample real-time OFDM signal, and found that there are two suspicious noises, which are shown in attachment or http://uploadpie.com/vcX3j . One suspicious noise appears at the start-up stage of N210, and the other suspicious noise appears at the end of a packet. The unwanted noise may ruin my ofdm_sync algorithm. So I am wondering that is it possible to get rid of these noises? How do they come? BTW, I use GNURadio v3.6.3 and UHD driver cloned at Sep. 11. Any comments are appreciated. Thanks! Regards, Lizhao ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Strange overflow problem on USRP N2XX
On 09/18/2012 05:36 AM, Ting Wu wrote:
> Hi,
>
>
>
> I made more tests, and even stranger things happened. Let me clarify this
> problem all over again.
>
>
Well, here is a description of overflow:
http://files.ettus.com/uhd_docs/manual/html/general.html#overflow-underflow-notes
So, its usually a factor of buffering, interrupts, and CPU performance.
It looks like you are connecting a USRP source to a gr messsage queue
and reading the queue in python. The python processing might be a
serious performance bottleneck
-josh
>
> I have two USRP (N210 Rev.4) (Let's say U1 and U2) with LFRX daughterboard,
> and two computers (Endeavo ST160E) (Let's say P1 and P2).
>
> First, U1 is connected with P1 and running test code (see below) works well.
>
> U2 is connected with P2, and running the code below prints 'O', indicating
> overflow problem.
>
>
>
> Then, I connect U1 to P2. Overflow problem happens again, and printing of
> 'O' becomes more frequent.
>
> Then, I connect U2 to P2. Same as above, frequent printing of 'O'.
>
> Then I rebooted P2, and connect it with U1. No overflow problem.
>
> Then I connect P2 with U2. Again there is overflow problem.
>
> Then I rebooted P2 again, and connect it to U2. No overflow problem again.
>
>
>
> For P1, there is always overflow problem even if I reboot it and no matter
> it is connected with U1 or U2.
>
>
>
> This is the code for making tests:
>
> ###code##
>
>
>
> #!/usr/bin/env python
>
>
>
> from gnuradio import gr
>
> from gnuradio import uhd
>
> import time
>
> from time import sleep
>
> from struct import unpack
>
>
>
> samp_rate = 4e6
>
> gain = 0
>
>
>
> class trig_with_pretrig(gr.top_block):
>
> def __init__(self):
>
> gr.top_block.__init__(self)
>
> self.source = uhd.usrp_source(device_addr="",
> stream_args=uhd.stream_args('sc16', 'sc16', args="scalar=1024"))
>
>
>
> self.source.set_samp_rate(samp_rate)
>
> self.source.set_gain(gain)
>
> self.source.set_center_freq(0)
>
>
>
> self.queue = gr.msg_queue()
>
> self.sink = gr.message_sink(gr.sizeof_short*2, self.queue,
> False)
>
> self.connect(self.source, self.sink)
>
>
>
>
>
> if __name__=="__main__":
>
> tb = trig_with_pretrig()
>
> tb.start()
>
>
>
> while True:
>
>
>
> #Test speed of computer
>
> tb.queue.flush()
>
> for i in range(1000):
>
> msg = tb.queue.delete_head()
>
> payload = msg.to_string()
>
> loadLen = int(msg.arg2())
>
> format = str(loadLen*2)+'h'
>
> data = unpack(format, payload)
>
> datach1 = data[0::2]
>
> dataMax = max(datach1)
>
> wait_len = tb.queue.count()
>
> sleep(1)
>
>
>
> ##code
>
>
>
> When there is overflow problem, it is like this:
>
>
>
> lrg@lrg:~$ ./test_overflow.py
>
> linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.003-224-gc2e197c0
>
>
>
> -- Opening a USRP2/N-Series device...
>
> -- Current recv frame size: 1448 bytes
>
> -- Current send frame size: 1472 bytes
>
> -- Detecting internal GPSDO Found a Jackson Labs GPS
>
> -- found
>
> -- Setting references to the internal GPSDO
>
> -- Initializing time to the internal GPSDO
>
>
> OO
>
>
>
> Anyone has any clue what might be the reason for this overflow problem?
>
> Any suggestion is appreciated.
>
>
>
> Wu
>
>
>
> From: discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.org
> [mailto:discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.or
> g] On Behalf Of Ting Wu
> Sent: Tuesday, September 18, 2012 5:36 PM
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] Strange overflow problem on USRP N2XX
>
>
>
> Hi all,
>
>
>
> Now I'm using several USRP N200 and N210 to build an observation network.
>
> I have bought several new computers, which are exactly the same.
>
> When I connect a USRP N210 with one computer, it has overflow problem
> (occasionally print 'O').
>
> However, when I connect the same USRP with another computer (exactly the
> same model), it does not have such problem.
>
>
>
> Several months ago, when I used a USRP N200, it also had similar problem.
>
> When I connect the USRP to a laptop (a very new and fast one), it
> occasionally has overflow problem.
>
> However, when I connect it to other computers (some of them are very old and
> slow), it did not have the problem.
>
>
>
> This really bothers me because I don't know what is the reason of this
> problem, so we ar
Re: [Discuss-gnuradio] Weird noise using RFX2400
On 09/18/2012 09:27 AM, You Lizhao wrote: > Hi All, > > I have used RFX2400+N210 to sample real-time OFDM signal, and found that > there are two suspicious noises, which are shown in attachment or > http://uploadpie.com/vcX3j . > > One suspicious noise appears at the start-up stage of N210, and the other > suspicious noise appears at the end of a packet. The unwanted noise may > ruin my ofdm_sync algorithm. So I am wondering that is it possible to get > rid of these noises? How do they come? > > BTW, I use GNURadio v3.6.3 and UHD driver cloned at Sep. 11. Any comments > are appreciated. Thanks! I couldnt see the upload pie link. Perhaps you are seeing transients when TX stops. I guess I have 2 suggestions: 1) make sure you are ending the transmit burst with the EOB tag http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n59 http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/examples/c++ 2) Also its good to pad out the burst/ofdm frame to push the frame through the TX DSP filters, and also to mitigate transients. -josh > > > Regards, > Lizhao > > > > ___ > 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] build and install UHD+GNUradio on Ubuntu
Hello, I am really new to USRP and just starting to install the GnuRadio. From the ettus website it says the easiest way to compile UHD +GNUradio is using the build-gnuradio script. I tried running it, but the very first thing (line 46 or 47) it starts to complain is on the syntax. Here is an excerpt towards the part of the error below: ... ... mod_udev- add UDEV rule for USRP1 mod_sysctl - modify SYSCTL for larger net buffers build-gnuradio: 46: build-gnuradio: Syntax error: "}" unexpected I did not change anything in the script. What am I doing wrong? Thanks, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio Screencast for Absolute Beginners
Hi Community, Just created a new playlist on my channel. Its about random experiments with gnuradio for fun. I hope the new comers will enjoy it. Here is the link to the playlist. http://www.youtube.com/playlist?list=PLwRhd5DzzaXA-poBmKgWv1BQYJT_i6VO2 More videos are coming soon. -- View this message in context: http://gnuradio.4.n7.nabble.com/Gnuradio-Screencast-for-Absolute-Beginners-tp14542p37643.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] build and install UHD+GNUradio on Ubuntu
Hello, I am really new to USRP and just starting to install the GnuRadio. From the ettus website it says the easiest way to compile UHD +GNUradio is using the build-gnuradio script. I tried running it, but the very first thing (line 46 or 47) it starts to complain is on the syntax. Here is an excerpt towards the part of the error below: ... ... mod_udev- add UDEV rule for USRP1 mod_sysctl - modify SYSCTL for larger net buffers build-gnuradio: 46: build-gnuradio: Syntax error: "}" unexpected I did not change anything in the script. What am I doing wrong? Thanks, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio How did you try running it? It looks like whatever shell you're handing it to isn't /bin/bash. -- 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
Re: [Discuss-gnuradio] UHD replacement for write_fpga_reg
On 09/15/2012 01:33 AM, Josh Blum wrote: > The TX GPIO setting kicks in when packets sent into the USB. You can > override the GPIO setting though with the dboard iface (all swigged up > into python as well) > http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1dboard__iface.html My revised FPGA design always advertises that it has space in the transmitter buffer, that the buffer never underflows, and that it is never empty. This should force the ATR mechanism to keep the transmitter on, since there is always data to transmit. The signal that the master_control.v block uses to determine whether or not there is data to transmit, tx_empty, is a constant 1'b0. If I read the logic right, this should satisfy the ATR. I am hesitant to use the GPIO interface without a good example of what I'm trying to do, since I've read that the GPIO controls can burn up the USRP. The culprit responsible for turning the transmitter off periodically is in uhd/host/lib/usrp/usrp1/io_impl.cpp line 275, which shuts off the transmitter if nothing has been sent to the USRP recently. I can get around this by sending a stream of 1s to the USRP, which are unceremoniously and deliberately discarded by the FPGA. Debug logs show that the host is instructing the transmitter to enable (i.e., via usrp_tx_enable(true) in fx2_ctrl.cpp). As expected, the daughterboard transmitter now turns on. The USRP only transmits a pure sinusoidal carrier at the transmitter's center frequency, however. It should be transmitting chirps, and either the chirp generator isn't working or the signal is not making it to the daughterboard. This exact same FPGA image works perfectly with libusrp. I'm not sure what has changed with the interface. As far as I know, for the USRP1 the standard UHD FPGA image is identical to the libusrp FPGA image. I'll write some debugging functionality for my FPGA image and let you know what I find. Colin signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How can I know which USRP is installed GPS?
Hi My PC is connected with 2 USRPs and one of them is connected with GPS and the other one is using the MIMO cable to share the GPS. My question is, is it possible to use the Python code to detect which USRP is equipped with GPS, and which is not? Thanks， -- Alex, *Dreams can come true – just believe.* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How can I know which USRP is installed GPS?
On 09/18/2012 07:02 PM, Alex Zhang wrote: > Hi > > My PC is connected with 2 USRPs and one of them is connected with GPS and > the other one is using the MIMO cable to share the GPS. > My question is, is it possible to use the Python code to detect which USRP > is equipped with GPS, and which is not? > There are a few things you can query: 1) the sensors list will have new things in it like gpsdo_locked, and nmea strings: http://files.ettus.com/uhd_docs/manual/html/gpsdo.html#using-the-gpsdo-in-your-application 2) The available time and clock sources list should also include gpsdo (on the master branch) Both of these things should be exposed in the python source/sink blocks. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Creation of a block (PSDU 29 octets) using message passing technique
Hi,
I'm trying to use "message passing" technique in order to create a block
that generates 29 Octets. Currently, I'm using a block that generates 29
Octets and then use tag streaming. In the .cc file, IO signature looks like:
gr_sync_block ("st1_pktsrc_dummy_b",
gr_make_io_signature (0, 0, 0),
gr_make_io_signature (MIN_OUT, MAX_OUT, sizeof (unsigned char)))
While, the stream tags looks like this:
add_item_tag(0, tag_pos,
d_burst_start_key,
pmt_sob,
d_my_unique_id)
Now, I want to change this approach to message passing as it is explained
here: https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide.
So, I changed the lines indicated above, for the following:
: gr_sync_block ("test_temporal",
gr_make_io_signature(0, 0, 0),
gr_make_io_signature(0, 0, 0),
msg_signature(false, 1))
and I am passing the message as follows:
this->post_msg(0, tag_pos,
d_burst_start_key,
pmt_sob,
d_my_unique_id);
However, when I compile my code after these changes, it complains about the
class 'asrp_test_temporal' does not have any field named block (see the
errors attached below).
'
asrp_test_temporal.cc:113:5: error: class 'asrp_test_temporal' does not
have any field named 'block'
asrp_test_temporal.cc:120:42: error: 'msg_signature' was not declared in
this scope
asrp_test_temporal.cc:120:42: note: suggested alternative:
/usr/local/include/gnuradio/block.h:58:22: note: 'gnuradio::msg_signature'
So, I would like to ask you:
1. Do I need to use the IO signature for message passing?, because in the
example provide in the
https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide only
uses msg_signature, but not gr_make_io_signature (0, 0, 0).
I would really appreciate your help, sorry for the punctuation or grammar
mistake, English is my second language. Please let me know if you need more
information, I will be happy to provide it.
Regards,
Jose
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ofdm block
Hi,
I get the following output with dir(Umbrella), and I can't see anything
called dftsofdm
['SwigPyIterator', 'SwigPyIterator_swigregister',
'Umbrella_bin2dec_ff_sptr', 'Umbrella_bin2dec_ff_sptr_swigregister',
'Umbrella_dec2bin_ff_sptr', 'Umbrella_dec2bin_ff_sptr_swigregister',
'Umbrella_decodconv_vff_sptr', 'Umbrella_decodconv_vff_sptr_swigregister',
'Umbrella_encodconv_vff_sptr', 'Umbrella_encodconv_vff_sptr_swigregister',
'Umbrella_swig', '_RTLD_GLOBAL', '__builtins__', '__doc__', '__file__',
'__name__', '__package__', '__path__', '_dlopenflags', 'bin2dec_ff',
'dec2bin_ff', 'decodconv_vff', 'encodconv_vff', 'sys']
How can I install my component correctly into Umbrella?
Ivan
2012/9/15 Tom Rondeau
> On Thu, Sep 13, 2012 at 1:29 AM, wrote:
> > Hi,
> >
> > First I delete all the files in the build folder, later I run the follow
> comands in the build folder:
> > 1) cmake ../
> > 2) make
> > 3) sudo make install
> > 4) sudo ldconfig
> >
> > Ivan
> > Enviado desde mi oficina móvil BlackBerry® de Telcel
>
> Well, that's doing the right thing. My guess is that it's some minor
> error somewhere in your build system or something. It sounds like one
> of those things that'll be very difficult to debug via email this way.
>
> Here's one place to start, though. Forget GRC for the time being and
> just make sure that you are installing your component correctly. So
> first build and install your component, Umbrella. Then simply pop open
> a Python interpreter ('python' or 'ipython' if you have the latter
> installed):
>
> import Umbrella
> dir(Umbrella)
>
> The output of the dir() command should show you what blocks are
> actually installed as part of this component. That'll give you a clue
> how your installation process is working.
>
> Tom
>
>
>
> > -Original Message-
> > From: Tom Rondeau
> > Sender: trond...@trondeau.com
> > Date: Wed, 12 Sep 2012 20:45:26
> > To: Viktor Ivan Rodriguez Abdala
> > Cc:
> > Subject: Re: [Discuss-gnuradio] ofdm block
> >
> > On Mon, Sep 10, 2012 at 1:12 PM, Viktor Ivan Rodriguez Abdala
> > wrote:
> >> Hi
> >>
> >> In the python folder, the CMakeLists.txt has
> >>
> >> GR_PYTHON_INSTALL(
> >> FILES
> >> __init__.py dftsofdm.py DESTINATION ${GR_PYTHON_DIR}/Umbrella
> >> )
> >>
> >> In the grc folder
> >>
> >> install(FILES
> >> Umbrella_bin2dec_ff.xml
> >> Umbrella_dec2bin_ff.xml
> >> Umbrella_encodconv_vff.xml
> >> Umbrella_decodconv_vff.xml
> >> Umbrella_dftsofdm_mod.xml
> >> Umbrella_dftsofdm_demod.xml DESTINATION share/gnuradio/grc/blocks
> >> )
> >>
> >>
> >> I delete all build files and rerun cmake ../ I think the problem is in
> the
> >> xml file with the make section.
> >>
> >> Ivan Rodriguez
> >
> >
> > After rerunning cmake, did you also 'make' and 'make install'?
> >
> > Tom
> >
> >
> >> On 09/07/2012 07:26 AM, Tom Rondeau wrote:
> >>>
> >>> On Thu, Sep 6, 2012 at 3:59 PM, Viktor Ivan Rodriguez Abdala
> >>> wrote:
>
> Hi all,
>
> I'm looking to develop a block called dfts ofdm, based in a similar
> block
> called ofdm mod, I change the .xml and .py to a new name called
> DFTSOFDM,
> but I can't make it work. In GRC I have the following error:
>
> Traceback (most recent call last):
> File "/home/administrador/Simulacion/top_block.py", line 86, in
>
> tb = top_block()
> File "/home/administrador/Simulacion/top_block.py", line 55, in
> __init__
> self.Umbrella_dftsofdm_mod_0 =
> grc_blks2.packet_mod_f(Umbrella.dftsofdm_mod(
> AttributeError: 'module' object has no attribute 'dftsofdm_mod'
> >>>
> >>> Is everything properly in the CMakeLists.txt files? Did you make sure
> >>> to rebuild and reinstall? Also, if that doesn't help, rerun cmake on
> >>> the project to make sure everything is properly reconfigured.
> >>>
> >>> Tom
> >>>
> >>>
> >>>
> The new python file es dftsofdm.py, and I change the classes with
>
> class dftsofdm_mod(gr.hier_block2):
>
> class dftsofdm_demod(gr.hier_block2):
>
> The .xml files have this changes:
>
> Umbrella_dftsofdm_demod.xml
>
> DFTSOFDM Demod
> Umbrella_dftsofdm_demod
> Umbrella
> import Umbrella
> from grc_gnuradio import blks2 as grc_blks2
> from gnuradio import digital
> grc_blks2.packet_demod_$(type.fcn)(Umbrella.dftsofdm_demod(
> options=grc_blks2.options(
> modulation="$modulation",
> fft_length=$fft_length,
> occupied_tones=$occupied_tones,
> cp_length=$cp_length,
> snr=$snr,
> log=None,
> verbose=None,
> ),
> callback=lambda ok, payload: self.$(id).recv_pkt(ok,
> payload),
> ),
> )
>
>
> Umbrella_dftsofdm_mod.xml
>
>
> DFTSOFDM Mod
> Umbrella_dftsofdm
Re: [Discuss-gnuradio] Creation of a block (PSDU 29 octets) using message passing technique
On 09/19/2012 01:11 AM, Jose Torres Diaz wrote:
> Hi,
>
> I'm trying to use "message passing" technique in order to create a block
> that generates 29 Octets. Currently, I'm using a block that generates 29
> Octets and then use tag streaming. In the .cc file, IO signature looks like:
>
> gr_sync_block ("st1_pktsrc_dummy_b",
>gr_make_io_signature (0, 0, 0),
>gr_make_io_signature (MIN_OUT, MAX_OUT, sizeof (unsigned char)))
>
> While, the stream tags looks like this:
>
> add_item_tag(0, tag_pos,
> d_burst_start_key,
> pmt_sob,
> d_my_unique_id)
>
> Now, I want to change this approach to message passing as it is explained
> here: https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide.
> So, I changed the lines indicated above, for the following:
>
> : gr_sync_block ("test_temporal",
>gr_make_io_signature(0, 0, 0),
>gr_make_io_signature(0, 0, 0),
>msg_signature(false, 1))
>
Careful here, check the coding guide,
you need to #include
and inherit from gnuradio::block
-josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
