[Discuss-gnuradio] Re: Importerror _gnuradio_swig_py_runtime on Cygwin
Yong J. Chang schrieb:
Thanks Don for previous question!
I successfully configured and compiled GNURadio trunk on Cygwin and tried to
run example.
But I'm getting following error:
Traceback (most recent call last):
File "./benchmark_tx.py", line 23, in
from gnuradio import gr, gru, modulation_utils
File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/__init__.py",
line 43, in
from gnuradio_swig_python import *
File
"/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_python.py",
line 23, in
from gnuradio_swig_py_runtime import *
File
"/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py",
line 6, in
import _gnuradio_swig_py_runtime
ImportError: No such file or directory
Hi Yong J.
make sure that your needed Python Modul is in your
. Try this
$python
>>>import sys
>>>print sys.path
And watch if your PATH to the swig directory is listed, if not
than anything went wrong.
Try,
>>>sys.path.append('directories to _gnuradio_swig_py_runtime')
Than your System should find this.
Regards Markus
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] cannot transmit (USRP2+xcvr2450)
Hello all,
I am using a USRP2+xcvr2450 with the latest trunk of GNU Radio (just
compiled/update the firmware and updated FPGA code to the latest release),
and FC 10 as the OS. I tried to use TCP/IP statck over USRP2 with modified
tunnel.py, transmit_path.py and receive_path.py. I used one USRP2 and one
USRP1 and ping USRP2 from USRP1. The USRP2 can receive the packets from
USRP1, but the USRP1 cannot receive anything from USRP2. On USRP2 side, I
can see packets going back and forth over the ethernet link via wireshark. I
noticed that USRP1 code uses "set_auto_tr" to enable auto switching between
tx and rx. however, no such function available for USRP2. I am wondering if
this causes the problem and how to fix it. Below is my code for transmit
path. Thanks.
class transmit_path_usrp2(gr.hier_block2):
def __init__(self, modulator_class, options):
'''
See below for what options should hold
'''
gr.hier_block2.__init__(self, "transmit_path",
gr.io_signature(0, 0, 0), # Input signature
gr.io_signature(0, 0, 0)) # Output signature
options = copy.copy(options)# make a copy so we can
destructively modify
self._which = options.which # the USRP board
attached
self._verbose= options.verbose
self._tx_freq= options.tx_freq # tranmitter's
center frequency
self._tx_amplitude = options.tx_amplitude# digital
amplitude sent to USRP
self._tx_subdev_spec = options.tx_subdev_spec # daughterboard
to use
self._bitrate= options.bitrate # desired bit
rate
self._interp = options.interp # interpolating
rate for the USRP (prelim)
self._samples_per_symbol = options.samples_per_symbol # desired
samples/baud
self._fusb_block_size= options.fusb_block_size # usb info for
USRP
self._fusb_nblocks = options.fusb_nblocks# usb info for
USRP
self._use_whitener_offset = options.use_whitener_offset # increment
start of whitener XOR data
self._interface = options.interface
self._mac_addr = options.mac_addr
self._modulator_class = modulator_class # the
modulator_class we are using
if self._tx_freq is None:
sys.stderr.write("-f FREQ or --freq FREQ or --tx-freq FREQ must
be specified\n")
raise SystemExit
# Set up USRP sink; also adjusts interp, samples_per_symbol, and
bitrate
# self._setup_usrp_sink()
self.u = usrp2.sink_32fc(self._interface, self._mac_addr)
dac_rate = self.u.dac_rate();
# derive values of bitrate, samples_per_symbol, and interp from
desired info
(self._bitrate, self._samples_per_symbol, self._interp) = \
pick_tx_bitrate(self._bitrate,
self._modulator_class.bits_per_symbol(),
self._samples_per_symbol, self._interp,
dac_rate)
self.u.set_interp(self._interp)
# copy the final answers back into options for use by modulator
options.samples_per_symbol = self._samples_per_symbol
options.bitrate = self._bitrate
options.interp = self._interp
# Get mod_kwargs
mod_kwargs =
self._modulator_class.extract_kwargs_from_options(options)
# Set center frequency of USRP2
#ok = self.set_freq(self._tx_freq)
#if not ok:
#print "Failed to set Tx frequency to %s" %
(eng_notation.num_to_str(self._tx_freq),)
#raise ValueError
# Tune the USRP2 FPGA and daughterboard to the requested center
frequency
# and LO offset
if options.lo_offset is not None:
self.u.set_lo_offset(options.lo_offset)
print options.tx_freq
tr = self.u.set_center_freq(options.tx_freq)
if tr == None:
sys.stderr.write('Failed to set center frequency\n')
raise SystemExit, 1
# transmitter
self.packet_transmitter = \
blks2.mod_pkts(self._modulator_class(**mod_kwargs),
access_code=None,
msgq_limit=4,
pad_for_usrp=True,
use_whitener_offset=options.use_whitener_offset)
# Set the Tx daughterboard gain as requested
if options.gain is None:
g = self.u.gain_range()
options.gain = float(g[0]+g[1])/2
self.u.set_gain(options.gain)
# Set the USRP for maximum transmit gain
# (Note that on the RFX cards this is a nop.)
#self.set_gain(self.subdev.gain_range()[1])
self.amp = gr.multiply_const_cc(1)
self.set_tx_amplitude(self._tx_amplitude)
# enable Auto Transmit/Receive switching
#self.set_auto_tr(True)
# Display some information about the setup
if self._verbose:
self._print_verbage()
# Create and setup tran
Re: [Discuss-gnuradio] tb lock and unlock with USRP2
Just one extra note here since I didn't mention it, this is the output from the script on my machine: sd...@sdrts:~/test$ sudo python usrp2_rx.py 0 Lock 0 Unlock usrp2: channel 0 already streaming 1 Lock 1 Unlock Sorry I didn't mention this before. Kieran On Wed, Feb 25, 2009 at 1:08 PM, Johnathan Corgan < jcor...@corganenterprises.com> wrote: > On Wed, 2009-02-25 at 12:27 +1300, Kieran Brownlees wrote: > > > There are 3 threads running, I posted thread 1 before, > > > > Here is thread 2: > > When unlock() is called, it stops the flowgraph, waits for it to finish, > then restarts it in its (possibly) new configuration. > > Thread 1 is your main thread waiting for the flowgraph to stop so it can > calculate the new flowgraph and restart it. > > Thread 2 is the usrp2 source block work function, blocked waiting for > packets to show up in its ring buffer. > > Thread 3 is the one reading packets from the kernel and putting them in > thread 2's ring buffer. It is blocked waiting for packets to come in > over the GbE. > > When the call to unlock() results in the flowgraph being stopped, > threads 2 and 3 should be gracefully exiting, but they are not. It's > also suspicious that it works the first time but not the second time. > > This is clearly a USRP2 host driver bug, but not clear where. I don't > have a workaround for you in the meantime other than to not use > lock()/unlock() on flowgraphs that have USRP2 sources. (It does work > fine with USRP2 sinks.) > > Thanks again for the minimal test case and gdb stack dumps--it makes it > much simpler to track down the problem. > > Johnathan > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Timers
On Tue, Feb 24, 2009 at 05:57:35PM -0500, Marcus D. Leech wrote: > What's the best way to setup a timer routine that has access to the bits > of the flowgraph? > > I'm using an external process (UI) to set dynamic values for certain > USRP attributes, and one of the mechanisms > I'm thinking of using is to trigger a regular timer to see if the > values in an external control file have changed, and if > so, update the USRP settings. > > I know that there's gr_local_signal_sighandler()--does the handler > function have access to the flowgraph? No. In general it's virtually impossible to safely uses threads and signals together. If you need a timer, one way to get it is to use a dedicated thread that manages the timer queue, then send messages to those who want them when the timer expires. [I'll be implementing something like this in the next few months] Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tb lock and unlock with USRP2
On Wed, 2009-02-25 at 12:27 +1300, Kieran Brownlees wrote: > There are 3 threads running, I posted thread 1 before, > > Here is thread 2: When unlock() is called, it stops the flowgraph, waits for it to finish, then restarts it in its (possibly) new configuration. Thread 1 is your main thread waiting for the flowgraph to stop so it can calculate the new flowgraph and restart it. Thread 2 is the usrp2 source block work function, blocked waiting for packets to show up in its ring buffer. Thread 3 is the one reading packets from the kernel and putting them in thread 2's ring buffer. It is blocked waiting for packets to come in over the GbE. When the call to unlock() results in the flowgraph being stopped, threads 2 and 3 should be gracefully exiting, but they are not. It's also suspicious that it works the first time but not the second time. This is clearly a USRP2 host driver bug, but not clear where. I don't have a workaround for you in the meantime other than to not use lock()/unlock() on flowgraphs that have USRP2 sources. (It does work fine with USRP2 sinks.) Thanks again for the minimal test case and gdb stack dumps--it makes it much simpler to track down the problem. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tb lock and unlock with USRP2
There are 3 threads running, I posted thread 1 before,
Here is thread 2:
(gdb) bt
#0 0xb80ef424 in __kernel_vsyscall ()
#1 0xb80bc075 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7bcd2ab in omni_condition::wait (this=0x90059f8) at posix.cc:152
#3 0xb700ed48 in usrp2::ring::wait_for_not_empty (this=0x90059c8)
at ring.cc:45
#4 0xb7016649 in usrp2::usrp2::impl::rx_samples (this=0x9005270, channel=0,
handler=0x8f5e098) at usrp2_impl.cc:704
#5 0xb700fa5d in usrp2::usrp2::rx_samples (this=0x8f1af10, channel=0,
handler=0x8f5e098) at usrp2.cc:246
#6 0xb702575f in usrp2_source_32fc::work (this=0x8fcce70,
noutput_items=4081,
input_ite...@0xb45a92f8, output_ite...@0xb45a9318)
at usrp2_source_32fc.cc:62
#7 0xb7d4d61a in gr_sync_block::general_work (this=0x8fcce70,
noutput_items=4081, ninput_ite...@0xb45a92ec, input_ite...@0xb45a92f8,
output_ite...@0xb45a9318) at gr_sync_block.cc:64
#8 0xb7d390f6 in gr_block_executor::run_one_iteration (this=0xb45a92d4)
at gr_block_executor.cc:298
#9 0xb7d50502 in gr_tpb_thread_body (this=0xb45a92d4, block=
{px = 0xb45a9324, pn = {pi_ = 0xb45a9340}}) at
gr_tpb_thread_body.cc:37
#10 0xb7d4a7ba in
boost::detail::function::void_function_obj_invoker0,
void>::invoke (function_obj_p...@0x8f25a70)
at gr_scheduler_tpb.cc:42
---Type to continue, or q to quit---
#11 0xb7bc4ffc in boost::function0 >::operator() (this=0x8f25a6c)
at /usr/include/boost/function/function_template.hpp:825
#12 0xb7bc5152 in boost::thread::thread_data > >::run (this=0x8f259b0)
at /usr/include/boost/thread/pthread/thread.hpp:130
#13 0xb7bb7938 in thread_proxy () from /usr/lib/libboost_thread-mt.so.1.35.0
#14 0xb80b850f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#15 0xb80067ee in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)
and Thread 3:
(gdb) bt
#0 0xb80ef424 in __kernel_vsyscall ()
#1 0xb7ffbf77 in poll () from /lib/tls/i686/cmov/libc.so.6
#2 0xb700a4a5 in usrp2::eth_buffer::rx_frames (this=0x8fcaa38, f=0x9005270,
timeout_in_ms=100) at eth_buffer.cc:193
#3 0xb7011bb7 in usrp2::usrp2::impl::bg_loop (this=0x9005270)
at usrp2_impl.cc:337
#4 0xb701716a in usrp2::usrp2_thread::run_undetached (this=0x8fcd058,
arg=0x0)
at usrp2_thread.cc:58
#5 0xb7bccdc1 in omni_thread_wrapper (ptr=0x8fcd058) at posix.cc:450
#6 0xb80b850f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#7 0xb80067ee in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)
On Wed, Feb 25, 2009 at 12:23 PM, Johnathan Corgan <
jcor...@corganenterprises.com> wrote:
> On Wed, 2009-02-25 at 12:19 +1300, Kieran Brownlees wrote:
>
> > Here is the backtrace from the main thread:
>
> This is showing that the main thread is stopped waiting for the
> flowgraph thread to finish as a result of an internal call to stop().
> Can you post the other traceback?
>
> Johnathan
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tb lock and unlock with USRP2
On Wed, 2009-02-25 at 12:19 +1300, Kieran Brownlees wrote: > Here is the backtrace from the main thread: This is showing that the main thread is stopped waiting for the flowgraph thread to finish as a result of an internal call to stop(). Can you post the other traceback? Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tb lock and unlock with USRP2
Here is the backtrace from the main thread: (gdb) bt #0 0xb80ef424 in __kernel_vsyscall () #1 0xb80bc075 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb7bb5fef in boost::thread::join () from /usr/lib/libboost_thread-mt.so.1.35.0 #3 0xb7bc4223 in gruel::thread_group::join_all (this=0x8f81cd4) at thread_group.cc:78 #4 0xb7d48740 in gr_scheduler_tpb::wait (this=0x8f81cd0) at gr_scheduler_tpb.cc:94 #5 0xb7d4ea69 in gr_top_block_impl::wait (this=0x8fccde0) at gr_top_block_impl.cc:124 #6 0xb7d4f0ea in gr_top_block_impl::restart (this=0x8fccde0) at gr_top_block_impl.cc:162 #7 0xb7d4f470 in gr_top_block_impl::unlock (this=0x8fccde0) at gr_top_block_impl.cc:152 #8 0xb7d4e2c0 in gr_top_block::unlock (this=0x8fccd18) at gr_top_block.cc:90 #9 0xb7dcd4f1 in _wrap_gr_top_block_sptr_unlock (args=0xb7ebaccc) at gnuradio_swig_py_runtime.cc:14389 #10 0x0805d867 in PyObject_Call () #11 0x080cd502 in PyEval_EvalFrameEx () #12 0x080d0345 in PyEval_EvalCodeEx () #13 0x080ce728 in PyEval_EvalFrameEx () #14 0x080d0345 in PyEval_EvalCodeEx () ---Type to continue, or q to quit--- #15 0x080d0557 in PyEval_EvalCode () #16 0x080edf8f in PyRun_FileExFlags () #17 0x080ee25a in PyRun_SimpleFileExFlags () #18 0x080595e7 in Py_Main () #19 0x08058962 in main () (gdb) Kieran On Wed, Feb 25, 2009 at 12:01 PM, Johnathan Corgan < jcor...@corganenterprises.com> wrote: > On Tue, Feb 24, 2009 at 2:54 PM, Kieran Brownlees > wrote: > > > When I run this script it hangs on the second call of unlock and never > makes > > it to pass. > > Thanks for the minimal error test case, that helps. > > Is it possible for you to use gdb from another terminal window to see > where it is hung up? > > I'll test this here locally when I get a few moments, but that might > not happen soon. > > Johnathan > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tb lock and unlock with USRP2
On Tue, Feb 24, 2009 at 2:54 PM, Kieran Brownlees wrote: > When I run this script it hangs on the second call of unlock and never makes > it to pass. Thanks for the minimal error test case, that helps. Is it possible for you to use gdb from another terminal window to see where it is hung up? I'll test this here locally when I get a few moments, but that might not happen soon. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Installing Gnu Radio 3.2 on centOS machine
On Tue, Feb 24, 2009 at 2:08 PM, Bruce McGuffin wrote: > Does anybody know what the problem is? What is compile-mbh.scm, and why > wasn't it part of the gnu radio download? You've found a bug in the tarball generation for release 3.2rc0, thanks. It's easily fixed, but we're not quite ready to release 3.2rc1. You can either a) copy the .scm file from the GNU Radio trunk repository into your unpacked tarball directory, or b) use svn to check out the trunk software and compile and install from there. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Timers
What's the best way to setup a timer routine that has access to the bits of the flowgraph? I'm using an external process (UI) to set dynamic values for certain USRP attributes, and one of the mechanisms I'm thinking of using is to trigger a regular timer to see if the values in an external control file have changed, and if so, update the USRP settings. I know that there's gr_local_signal_sighandler()--does the handler function have access to the flowgraph? -- Marcus Leech Principal Investigator, Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] tb lock and unlock with USRP2
Hello all,
I seem to be having some strange behaviour when trying to lock and unlock
multiple times. I am using a USRP2 with the latest trunk of GNU Radio (just
compiled/update the firmware and updated FPGA code to the latest release),
and Ubuntu 8.10 Server as the OS.
The test script I am using is:
class top_block(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
self._usrp_source = usrp2.source_32fc('eth1', '00:50:c2:85:30:6d')
self.connect(self._usrp_source, gr.null_sink(8))
if __name__ == '__main__':
app = top_block()
app.start()
for x in range (2):
print str(x) + " Lock"
app.lock()
print str(x) + " Unlock"
app.unlock()
print "Pass"
app.stop()
When I run this script it hangs on the second call of unlock and never makes
it to pass.
Any ideas?
Thank You,
Kieran
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Installing Gnu Radio 3.2 on centOS machine
Hi I'm trying to get gnuradio version 3.2 installed on an old computer that is now running the centOS 5.2 operating system. It appears that centOS is missing a lot of the features found in other versions of Linux, but after a lot of work the configure now runs. When I try to run make, it causes the following error: make[4]: Entering directory `/usr/local/gnuradio-3.2rc0/mblock/src/lib' cd ../../.. && /bin/sh ./config.status mblock/src/lib/Makefile depfiles config.status: creating mblock/src/lib/Makefile config.status: executing depfiles commands make[4]: Leaving directory `/usr/local/gnuradio-3.2rc0/mblock/src/lib' make[4]: Entering directory `/usr/local/gnuradio-3.2rc0/mblock/src/lib' GUILE_LOAD_PATH="/usr/local/gnuradio/pmt/src/scheme:/usr/local/gnuradio/mblock/src/scheme" /usr/bin/guile -e main -s ../../../mblock/src/scheme/gnuradio/compile-mbh.scm ./qa_bitset.mbh qa_bitset_mbh.cc ERROR: In procedure open-file: ERROR: No such file or directory: "../../../mblock/src/scheme/gnuradio/compile-mbh.scm" make[4]: *** [qa_bitset_mbh.cc] Error 1 make[4]: Leaving directory `/usr/local/gnuradio-3.2rc0/mblock/src/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/local/gnuradio-3.2rc0/mblock/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/gnuradio-3.2rc0/mblock' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/gnuradio-3.2rc0' make: *** [all] Error 2 Does anybody know what the problem is? What is compile-mbh.scm, and why wasn't it part of the gnu radio download? Thanks Bruce ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fixed FPGA inband firmware
Hi,
attached is a somewhat larger patch for the FPGA firmware.
The patch changes the following:
- stable timestamp, timestamp is latched on the last sample that goes into the
packet, so in case no overrun happens, timestamp goes up reliably 126 times
decimation rate.
- channel buffer is emptied when an overrun happens, avoids multiple overruns
in short succession
- tx timestamp wrap around, range is divided into 2^31 past and 2^31 future
timestamps.
- dropped flag is set
- overrun flag is set
- tag is set to the tag of the last sent package
- rssi value is transmitted in a logarithmic representation
- waiting on fifos is shortened based on the fact that these get filled and
emptied at a fixed rate. If the reader is faster than the writer, than the
fifo should reach zero level when the reader finishes.
The patches have successfully been tested with 1tx1rx on usrp rev4. Loopback
works, overrun and underrun reporting works, drops are reported as well.
Regards,
Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
phone: +49 241 53809034 mobile: +49 151 50412019
=== modified file 'usrp/fpga/inband_lib/chan_fifo_reader.v'
--- usrp/fpga/inband_lib/chan_fifo_reader.v 2008-04-30 02:52:31 +
+++ usrp/fpga/inband_lib/chan_fifo_reader.v 2009-02-24 21:01:19 +
@@ -1,7 +1,7 @@
module chan_fifo_reader
(reset, tx_clock, tx_strobe, timestamp_clock, samples_format,
fifodata, pkt_waiting, rdreq, skip, tx_q, tx_i,
-underrun, tx_empty, debug, rssi, threshhold, rssi_wait) ;
+underrun, tx_empty, debug, rssi, threshhold, rssi_wait, drop, tagline) ;
input wire reset ;
input wire tx_clock ;
@@ -19,6 +19,8 @@
input wire [31:0] rssi;
input wire [31:0] threshhold;
input wire [31:0] rssi_wait;
+ output reg drop;
+ output reg[3:0] tagline;
output wire [14:0] debug;
assign debug = {7'd0, rdreq, skip, reader_state, pkt_waiting, tx_strobe, tx_clock};
@@ -37,6 +39,7 @@
// Header format
`define PAYLOAD 8:2
+ `define TAG 12:9
`define ENDOFBURST 27
`define STARTOFBURST 28
`define RSSI_FLAG26
@@ -52,6 +55,8 @@
reg trash;
reg rssi_flag;
reg [31:0] time_wait;
+ reg [32:0] time_to_wait;
+ reg[3:0] tag_save;
always @(posedge tx_clock)
begin
@@ -68,6 +73,8 @@
trash <= 0;
rssi_flag <= 0;
time_wait <= 0;
+ time_to_wait <= 0;
+ drop <= 0;
end
else
begin
@@ -86,10 +93,10 @@
begin
reader_state <= HEADER;
rdreq <= 1;
- underrun <= 0;
end
+
if (burst == 1 && pkt_waiting == 0)
- underrun <= 1;
+ underrun <= ~underrun;
if (tx_strobe == 1)
tx_empty <= 1 ;
end
@@ -102,10 +109,7 @@
rssi_flag <= fifodata[`RSSI_FLAG]&fifodata[`STARTOFBURST];
//Check Start/End burst flag
- if (fifodata[`STARTOFBURST] == 1
- && fifodata[`ENDOFBURST] == 1)
- burst <= 0;
- else if (fifodata[`STARTOFBURST] == 1)
+ if (fifodata[`STARTOFBURST] == 1 && fifodata[`ENDOFBURST] == 0)
burst <= 1;
else if (fifodata[`ENDOFBURST] == 1)
burst <= 0;
@@ -115,19 +119,27 @@
skip <= 1;
reader_state <= IDLE;
rdreq <= 0;
+ burst <= 0;
end
else
begin
payload_len <= fifodata[`PAYLOAD] ;
+ tag_save <= fifodata[`TAG];
read_len <= 0;
rdreq <= 1;
- reader_state <= TIMESTAMP;
+ if( fifodata[`STARTOFBURST] == 0)
+ begin
+ reader_state <= WAIT;
+ timestamp <= 32'h;
+ end else
+ reader_state <= TIMESTAMP;
end
end
TIMESTAMP:
begin
timestamp <= fifodata;
+ time_to_wait <= ({1'b1, fifodata} - {1'b0, timestamp_clock});
reader_state <= WAIT;
if (tx_strobe == 1)
tx_empty <= 1 ;
@@ -137,32 +149,31 @@
// Decide if we wait, send or discard samples
WAIT:
Re: [Discuss-gnuradio] USRP2 &DBSRX testing
There are some minor mods necessary to work with the DBSRX. I will get you instructions and working code in a day or two. Thanks for your patience, Matt RH200 wrote: We have got a new USRP2 and TVRX and DBSRX recievers. Though the system seems to work when the TVRX daughter board is installed using the USRP2 fft script, it does not seem to work with the DBSRX board installed. That is there seems to be just noise coming in regardless of what frequency or bandwidth setting you are using. Does any one know of any special tricks when using the DBSRX board? Regards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Importerror _gnuradio_swig_py_runtime on Cygwin
Thanks Don for previous question! I successfully configured and compiled GNURadio trunk on Cygwin and tried to run example. But I'm getting following error: Traceback (most recent call last): File "./benchmark_tx.py", line 23, in from gnuradio import gr, gru, modulation_utils File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/__init__.py", line 43, in from gnuradio_swig_python import * File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_python.py", line 23, in from gnuradio_swig_py_runtime import * File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 6, in import _gnuradio_swig_py_runtime ImportError: No such file or directory But I can find _gnuradio_swig_py_runtime.dll file on "/usr/local/lib/python2.5/site-packages/gnuradio/gr". Anybody knows what the problem is? Any helps are appreciated. -- View this message in context: http://www.nabble.com/Importerror-_gnuradio_swig_py_runtime-on-Cygwin-tp22190302p22190302.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New implementation for fusb_linux withoutallocs/frees
On Tuesday 24 February 2009 16:03:05 Marcus D. Leech wrote: > Have you tested receive performance, and is it improved? Hm, if you are going for high bandwidth, you should set the blocksize quite high (eg 4096). I am targetting low latency, so I go for the smallest possible blocksize (512). If you are receiving with 32MB/s, the new code saves about 75e6 instructions per second at a blocksize of 512, so for 4096 this should be about 9e6. For a current generation cpu, this should be about 1% of its throughput, on the other hand, the mallocs are most probably very unfriendly to branch prediction and cache access, so savings may be higher. If I find some time, I will run oprofile to get some numbers ... Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New implementation for fusb_linux withoutallocs/frees
Eric Blossom wrote: On Tue, Feb 24, 2009 at 01:07:34PM -0500, Marcus D. Leech wrote: Eric Blossom wrote: Marcus, in my experience, USB performance has not be limited by cpu cycles. It seems to be primarily a function of the design of the host controller, the firmware in the device, and a reasonable way to get the data into user mode. In most apps I've benchmarked, the overhead of all usrp related stuff is typically on the order of 5 to 10% of the total cycles consumed. Eric OK, so improving total USB cycle counts in user mode from 10% to 5% perhaps wouldn't noticeably improve things like overruns--is that what you're saying? Overruns are generally caused because your signal processing can't keep up, not that there's a problem with handling the USB. So, in your experience what is the sh*t-hottest USB controller out there, and is it available on a PCI or PCI-E card? Once the controller can handle 32MB/s, you're golden. Pretty much any of the onboard controllers over the last few years work fine. Measure twice, cut once. Time be time. It is important to make sure that your system is not throttling back the CPU because of heat or power saving modes. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP monitoring
Hello all, I recently installed gnuradio (3.2.x) on my machine (OS X) and was wondering about purchasing the USRP. It seems that usrp2 is currently only supported on Linux, so I guess I shouldn't get that one. Can anyone recommend daughterboards that would be best for simple communication, e.g. for building networks with USRP's as nodes? I also had a question about monitoring, I couldn't find anything in the archives. Is there a way to monitor USRP's performance in software? Something like performance counters? I don't have a strong DSP background, but I imagine there are some metrics that are common for all SDR's. Thanks, Jakub. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New implementation for fusb_linux withoutallocs/frees
On Tue, Feb 24, 2009 at 01:07:34PM -0500, Marcus D. Leech wrote: > Eric Blossom wrote: > > Marcus, in my experience, USB performance has not be limited by cpu > > cycles. It seems to be primarily a function of the design of the host > > controller, the firmware in the device, and a reasonable way to get > > the data into user mode. In most apps I've benchmarked, the overhead > > of all usrp related stuff is typically on the order of 5 to 10% of the > > total cycles consumed. > > > > Eric > > > > > OK, so improving total USB cycle counts in user mode from 10% to 5% > perhaps wouldn't noticeably improve > things like overruns--is that what you're saying? Overruns are generally caused because your signal processing can't keep up, not that there's a problem with handling the USB. > So, in your experience what is the sh*t-hottest USB controller out > there, and is it available on a PCI or PCI-E card? Once the controller can handle 32MB/s, you're golden. Pretty much any of the onboard controllers over the last few years work fine. Measure twice, cut once. Time be time. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New implementation for fusb_linux withoutallocs/frees
Eric Blossom wrote: > Marcus, in my experience, USB performance has not be limited by cpu > cycles. It seems to be primarily a function of the design of the host > controller, the firmware in the device, and a reasonable way to get > the data into user mode. In most apps I've benchmarked, the overhead > of all usrp related stuff is typically on the order of 5 to 10% of the > total cycles consumed. > > Eric > > OK, so improving total USB cycle counts in user mode from 10% to 5% perhaps wouldn't noticeably improve things like overruns--is that what you're saying? So, in your experience what is the sh*t-hottest USB controller out there, and is it available on a PCI or PCI-E card? -- Marcus Leech Principal Investigator, Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RFID Capture
Thanks for all the advice. After turning the power way down and placing the tag within inches of the antenna, I can see the tag's burts. It makes me wonder how the reader can pull out the tag's bursts in 'real world' conditions. There is no processing gain to pull it out of the noise. Thanks again, Kevin On Mon, Feb 23, 2009 at 1:43 PM, Paul Mathews wrote: > > Hello All, > I am trying to capture the communications between a RFID reader and an EPC > Gen 2 tag (920 MHz). I tapped directly into the antenna of a Thinkmagic M5e > RFID reader. I turn it on and it starts reading the tags. When I look at > the raw signal from the usrp or an Agilent signal analyzer, I can clearly > make out the reader-to-tag data bursts. But, I don't see the tag-to-reader > bursts. I know they should be considerably smaller in amplitude, but all I > see is noise. > > Has anyone had any luck capturing this type of data? Any suggestions would > be greatly appreciated. > > Thanks in advance, > Kevin > > Yes, indeed, the backscatter signals from the RFID tags typically have quite > small amplitudes, and it may be difficult to trigger on them. Try bringing > the tags quite close to the reader and use various antenna alignments. Tag > signals will put small notches in the carrier envelope. You might have a > better chance of seeing them if you use a 3rd antenna for your receiver, > positioning the tag between the reader and your receiver antenna. > Paul Mathews > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: RFID Capture
Gen 2 (915 MHz) has read ranges measured in meters, while HF (13.56 MHz) range is measured in cm. Check out "How to Build a Low-Cost, Extended Range RFID Skimmer" for how to increase read range for HF devices; they got about 35 cm. But to answer your question, I just use a vanilla circular antenna which is pretty standard for Gen 2 applications. Michael > Hello All, > I'm trying to do more or less the same thing as Kevin but with two other > readers (a RFIdeas Playback and an OpenPCD) and other kind of cards (HID > IClass 2K and Mifare Classic 1K: both working at 13.56MHz). > I got an interesting signal just putting my loop antenna attached both > to the card and the reader: even if it is a bit weak, I can recognize > the tag reply. > (USRP 1, BaseRX with the usrp_rx_cfile.py -f 13560833 -r B -d 16) > One of the problems I have is that I have to stay as much close as I can > to the card to be able to read its response (from more than 3 inches I > get an unreadable signal...), so I would like to ask Michael which kind > of antenna (and any external things) you used to be able to read the > signal from few feet away. Any suggestions will be very well appreciated. > Thank you very much, > Marco > > Michael Buettner wrote: > > Are you using the ThingMagic in monostatic mode (one antenna that does RX > > and > > TX)? If so, you probably won't be able to see the tag reply. Further down > > the > > receive path the ThingMagic has circuitry that removes the strong TX signal > > leaving only the tag reply, but I assume you are tapped in before that. You > > MIGHT have better luck if you use the reader in bistatic mode and tap in at > > the > > receive antenna, particularly if you don't use the full 1W output power. > > Another > > option would be to just put the USRP antenna near the tag, and receive both > > reader and tag commands there. I have had pretty good luck with that, and > > can > > decode tag responses from a few feet away. > > > > > > michael ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: gr-sounder using xcvr2450 daughterboard - usrpsounder.py
mutsa gahadza wrote:
>> Dear all
>>
>> I have two debian host PCs and two USRPs. I have been trying to measure
> Channel Impulse Response using usrpsounder.py.
>>
>> My command lines are as follows:
>> # ./usrp_sounder.py -f 2.4G -r -v -D -F output.dat
>> # ./usrp_sounder.py -f 2.4G -R A -t -v -D
>>
>> I then used
>> a=read_complex_binary.m
>
> you have to specify your binary file like this:
> a = read_complex_binary('output.dat',inf);
>
>
>>
>> plot(abs(a))
>> to see the result. I am consistently getting zero values all the time.
>>
Hey Mutsa,
I am facing the same problem too.
Have u got any solutions since then?
Thanks!
Bruhtesfa
--
Posted via http://www.ruby-forum.com/.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: change variables in the FFT Plot the 2.
Please follow the directions to enable the wxgui - open gl sinks: http://gnuradio.org/trac/browser/gnuradio/trunk/gr-wxgui/README.gl Let me know how it works for you! -Josh feldmaus wrote: feldmaus gmx.de> writes: Not really RIGHT: def set_samp_rate(self, samp_rate): self.samp_rate = samp_rate self.wxgui_fftsink2.set_samp_rate(self.samp_rate) How is the Name of the method to set up the samp_rate ? self.wxgui_fftsink2.set_sample_rate(self.samp_rate) ___ 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] New implementation for fusb_linux withoutallocs/frees
On Tue, Feb 24, 2009 at 10:03:05AM -0500, Marcus D. Leech wrote: > Stefan Bruens wrote: > > Hi, > > > > attached is a new version for fusb_linux.cc. > > > > The current implementation uses three std::list lists for free, pending and > > completed urbs, so submitting a single urb causes three allocs and three > > frees > > (pushing and popping of the list). > > > > The new implementation uses a circular list for the urbs, where each urb is > > marked as free, pending or completed. As the total number of allocated urbs > > is > > constant, no allocs or frees are needed. > > > > Benchmark: > > usrp/host/apps/test_usrp_standard_tx -B 512 -N 64 -M 128 > > > > old code needs ~990e6 instructions, new code 690e6 instructions. The call > > to > > usrp_basic_tx::write goes down from 380e6 to 80e6 (so almost down to a > > fifth > > ...), the remaining instructions is the pattern fill for the sample buffer. > > > > Regards, > > > > Stefan > > > > > Have you tested receive performance, and is it improved? > > Bandwidth is my dearest friend in radio astronomy (in the absence of > RFI), so getting the best USB performance > that's possible given CPU constraints is important to me. > Marcus, in my experience, USB performance has not be limited by cpu cycles. It seems to be primarily a function of the design of the host controller, the firmware in the device, and a reasonable way to get the data into user mode. In most apps I've benchmarked, the overhead of all usrp related stuff is typically on the order of 5 to 10% of the total cycles consumed. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Any implementation of Spread Spectrum
On Mon, Feb 23, 2009 at 8:25 PM, Mir Ali wrote: > can you suggest me a place where I can find more information about the phase > sync and the freq sync methods you used in your work. It will be of great > help to me. There is plenty of information available via Google. An excellent reference book is: "Fundamentals of Global Positioning System Receivers: A Software Approach" Wiley Series in Microwave and Optical Engineering James Bao-Yen Tsui, 2004 Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Pulse-doppler RADAR wind profiler project and how to bypass interpolation, DAC filtering, etc.
On Mon, Feb 23, 2009 at 7:53 PM, Nick Withers wrote: > Yes, certainly feeling a little overwhelmed! You wouldn't be the first. > At this point, that's pretty well what I want to do. I want to smack as > much as possible in the FPGA (well, on the non-PC side of the USB, > anyway) and essentially only transfer configuration information and > returned base-band samples to / from the PC. For the reasons I mentioned, then, your are better off with the USRP2. >> Furthermore, depending on the range resolution you need, the 8 MHz of >> passband bandwidth that the USRP1 can transport over the USB may not >> be enough. > > Should be plenty, I think, given that I want to throw baseband samples > back to the PC... But I may well be missing something here! You need to calculate the overall data rate that needs to be sent to the host, which depends on your PRF, baseband sample rate, and range gate duration. > As I understand it, I should be right with timing if I do "everything" > on the USRP... No? I'm going to need to do some work on ensuring > pipeline delays between the FPGA and the RF world are configured > properly... Yes, but it's not a big deal. The bigger issue I encountered was accounting for the turn-around time in the transmitter power amplifier and antenna switch. It was almost a microsecond after the end of the chirp before the PA sensed the end of the power burst and switched to receive. This limited the minimum range to a few hundred meters. >> You can use state machines to handle sequencing of TX and RX, and with >> the Spartan3 multipliers, you can even do de-chirping or >> cross-correlation of your receive waveform before it gets to the host. > > This would be good, yes. I'm currently fiddling with the Altera IP > (soft) multipliers, which would I imagine allow me to do this...? You will run out of room very quickly with the USRP1 if you use these. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: RFID Capture
Hello All, I'm trying to do more or less the same thing as Kevin but with two other readers (a RFIdeas Playback and an OpenPCD) and other kind of cards (HID IClass 2K and Mifare Classic 1K: both working at 13.56MHz). I got an interesting signal just putting my loop antenna attached both to the card and the reader: even if it is a bit weak, I can recognize the tag reply. (USRP 1, BaseRX with the usrp_rx_cfile.py -f 13560833 -r B -d 16) One of the problems I have is that I have to stay as much close as I can to the card to be able to read its response (from more than 3 inches I get an unreadable signal...), so I would like to ask Michael which kind of antenna (and any external things) you used to be able to read the signal from few feet away. Any suggestions will be very well appreciated. Thank you very much, Marco Michael Buettner wrote: > Are you using the ThingMagic in monostatic mode (one antenna that does RX and > TX)? If so, you probably won't be able to see the tag reply. Further down > the receive path the ThingMagic has circuitry that removes the strong TX > signal leaving only the tag reply, but I assume you are tapped in before > that. You MIGHT have better luck if you use the reader in bistatic mode and > tap in at the receive antenna, particularly if you don't use the full 1W > output power. Another option would be to just put the USRP antenna near the > tag, and receive both reader and tag commands there. I have had pretty good > luck with that, and can decode tag responses from a few feet away. > > > michael > > > Hello All, > > I am trying to capture the communications between a RFID reader and > > an EPC Gen 2 tag (920 MHz). I tapped directly into the antenna of a > > Thinkmagic M5e RFID reader. I turn it on and it starts reading the > > > tags. When I look at the raw signal from the usrp or an Agilent > > signal analyzer, I can clearly make out the reader-to-tag data bursts. > > But, I don't see the tag-to-reader bursts. I know they should be > > > considerably smaller in amplitude, but all I see is noise. > > > Has anyone had any luck capturing this type of data? Any suggestions > > would be greatly appreciated. > > > Thanks in advance, > > Kevin > > > > > -- > - > > > ___ > 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] New implementation for fusb_linux withoutallocs/frees
Stefan Bruens wrote: > Hi, > > attached is a new version for fusb_linux.cc. > > The current implementation uses three std::list lists for free, pending and > completed urbs, so submitting a single urb causes three allocs and three > frees > (pushing and popping of the list). > > The new implementation uses a circular list for the urbs, where each urb is > marked as free, pending or completed. As the total number of allocated urbs > is > constant, no allocs or frees are needed. > > Benchmark: > usrp/host/apps/test_usrp_standard_tx -B 512 -N 64 -M 128 > > old code needs ~990e6 instructions, new code 690e6 instructions. The call to > usrp_basic_tx::write goes down from 380e6 to 80e6 (so almost down to a fifth > ...), the remaining instructions is the pattern fill for the sample buffer. > > Regards, > > Stefan > > Have you tested receive performance, and is it improved? Bandwidth is my dearest friend in radio astronomy (in the absence of RFI), so getting the best USB performance that's possible given CPU constraints is important to me. -- Marcus Leech Principal Investigator, Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSL function error on Cygwin
Yong J. Chang wrote: I'm trying to use GNU radio on Cygwin environment. It has taken couple of days to compile depedent stuffs. I'm on my almost final stage. I have following error messages when I compile 'gnuradio-core'. *** Warning: This system can not link to static lib archive /usr/local/lib/libgsl.la. *** I have the capability to make that library automatically link in when . . . I definitely installed gsl_1_12 library. Any helps are appreciated. :) It should be looking in /usr/lib (not /usr/local/lib) and it should be looking for libgsl.dll.a (not libgsl.la). You should have a gsl.pc file in /usr/lib/pkgconfig. If you also have a gsl.pc file (with old or incorrect information) in /usr/local/lib/pkgconfig, that could be the problem. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Overrun when there shouldn't be
Eric Blossom wrote am 2009-02-10 22:13: Be sure that you're in the usrp group, and that /etc/security/limits.conf contains this line: @usrp - rtprio 50 If you edit /etc/security/limits.conf I'm pretty sure you need to reboot to get it to take effect. You do not need need reboot[1]. Debian man page says: Also, please note that all limit settings are set per login. They are not global, nor are they permanent; existing only for the duration of the session. A new login should do. This can mean loging in and out once, or just saying su $USER will give you the new setting, but only in this session. Patrick [1] This is not Microsoft ;-) -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GSL function error on Cygwin
Hi all, I'm trying to use GNU radio on Cygwin environment. It has taken couple of days to compile depedent stuffs. I'm on my almost final stage. I have following error messages when I compile 'gnuradio-core'. *** Warning: This system can not link to static lib archive /usr/local/lib/libgsl.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This system can not link to static lib archive /usr/local/lib/libgslcblas.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. libtool: link: rm -fr .libs/libgnuradio-core.dll.a libtool: link: g++ -shared -nostdlib .libs/bug_work_around_6.o -Wl,--whole-archive filter/.libs/libfilter.a g72x/.libs/libccitt.a viterbi/.libs/libviterbi.a general/.libs/libgeneral.a gengen/.libs/libgengen.a io/.libs/libio.a missing/.libs/libmissing.a reed-solomon/.libs/librs.a runtime/.libs/libruntime.a -Wl,--no-whole-archive /home/ychang/gnuradio/omnithread/.libs/libgromnithread.dll.a /home/ychang/gnuradio/gruel/src/lib/.libs/libgruel.dll.a -L/opt/boost_1_37_0/lib -lboost_thread-gcc34-mt-1_37 -L/usr/local/lib /usr/local/lib/libfftw3f.dll.a -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. -lstdc++ -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -o .libs/cyggnuradio-core-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgnuradio-core.dll.a general/.libs/libgeneral.a(gr_squash_ff.o): In function `_ZN5boost6detail17sp_counted_impl_pI12gr_squash_ffE11get_deleterERKSt9type_info': /opt/boost_1_37_0/include/boost-1_37/boost/detail/sp_counted_impl.hpp:(.text+0x7f): undefined reference to `_gsl_interp_accel_free' /opt/boost_1_37_0/include/boost-1_37/boost/detail/sp_counted_impl.hpp:(.text+0x8d): undefined reference to `_gsl_spline_free' general/.libs/libgeneral.a(gr_squash_ff.o): In function `_ZN12gr_squash_ffD1Ev': /home/ychang/gnuradio/gnuradio-core/src/lib/general/gr_squash_ff.cc:66: undefined reference to `_gsl_interp_accel_free' /home/ychang/gnuradio/gnuradio-core/src/lib/general/gr_squash_ff.cc:67: undefined reference to `_gsl_spline_free' general/.libs/libgeneral.a(gr_squash_ff.o): In function `_ZN12gr_squash_ffD0Ev': /home/ychang/gnuradio/gnuradio-core/src/lib/general/gr_squash_ff.cc:66: undefined reference to `_gsl_interp_accel_free' /home/ychang/gnuradio/gnuradio-core/src/lib/general/gr_squash_ff.cc:67: undefined reference to `_gsl_spline_free' general/.libs/libgeneral.a(gr_squash_ff.o): In function `_ZN12gr_squash_ffC1ERKSt6vectorIfSaIfEES4_': /home/ychang/gnuradio/gnuradio-core/src/lib/general/gr_squash_ff.cc:57: undefined reference to `_gsl_interp_accel_alloc' /home/ychang/gnuradio/gnuradio-core/src/lib/general/gr_squash_ff.cc:58: undefined reference to `_gsl_interp_cspline' /home/ychang/gnuradio/gnuradio-core/src/lib/general/gr_squash_ff.cc:58: undefined reference to `_gsl_spline_alloc' general/.libs/libgeneral.a(gr_squash_ff.o): In function `_ZN12gr_squash_ffC2ERKSt6vectorIfSaIfEES4_': /home/ychang/gnuradio/gnuradio-core/src/lib/general/gr_squash_ff.cc:57: undefined reference to `_gsl_interp_accel_alloc' /home/ychang/gnuradio/gnuradio-core/src/lib/general/gr_squash_ff.cc:58: undefined reference to `_gsl_interp_cspline' /home/ychang/gnuradio/gnuradio-core/src/lib/general/gr_squash_ff.cc:58: undefined reference to `_gsl_spline_alloc' general/.libs/libgeneral.a(gr_squash_ff.o): In function `_ZN12gr_squash_ff4workEiRSt6vectorIPKvSaIS2_EERS0_IPvSaIS6_EE': /home/ychang/gnuradio/gnuradio-core/src/lib/general/gr_squash_ff.cc:83: undefined reference to `_gsl_spline_init' /home/ychang/gnuradio/gnuradio-core/src/lib/general/gr_squash_ff.cc:86: undefined reference to `_gsl_spline_eval' I definitely installed gsl_1_12 library. Any helps are appreciated. :) -- View this message in context: http://www.nabble.com/GSL-function-error-on-Cygwin-tp22181041p22181041.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: change variables in the FFT Plot the 2.
feldmaus gmx.de> writes: > Not really RIGHT: > def set_samp_rate(self, samp_rate): > self.samp_rate = samp_rate > self.wxgui_fftsink2.set_samp_rate(self.samp_rate) > > How is the Name of the method to set up the samp_rate ? self.wxgui_fftsink2.set_sample_rate(self.samp_rate) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: change variables in the FFT Plot the 2.
feldmaus gmx.de> writes: > > Hi All, > > i am trying to get the FFT Plot Sink under grc(gnuradio > companion) to work. But the x-min and the x-max can't > be set up. As i read the x-Axis should be fitted by the > samp_rate variable, but it does not work. > > Any Ideas ? I watched in the code and found an error. There is something mising to set up the value samp_rate of the graphical FFT Plot sink. @Developer please correct this. WRONG: def set_samp_rate(self, samp_rate): self.samp_rate = samp_rate Not really RIGHT: def set_samp_rate(self, samp_rate): self.samp_rate = samp_rate self.wxgui_fftsink2.set_samp_rate(self.samp_rate) How is the Name of the method to set up the samp_rate ? Regards Markus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] change variables in the FFT Plot the 2.
Hi All, i am trying to get the FFT Plot Sink under grc(gnuradio companion) to work. But the x-min and the x-max can't be set up. As i read the x-Axis should be fitted by the samp_rate variable, but it does not work. Any Ideas ? Regards Markus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Problem iinstalling fftw-3.2 on Centos 5.2 64 bits
anne kwong wrote am 2009-02-09 13:16: I am getting another problem when running ./configure FFTW3F is compiled with ./configure --prefix=/opt/freeswitch --enable-core-odbc-support --enable-core-libedit-support --enable-64 --with-openssl=/usr/sfw Here is my export output declare -x FFTW3F_CFLAGS="/usr/local/include" declare -x FFTW3F_LIBS="/usr/local/lib" Obviously your fftw3f is installed in opt/freeswitch. declare -x FFTW3F_CFLAGS="/usr/local/include" won't do the job in this case... Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
