-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dan Halperin wrote:
> Eric Blossom wrote:
>> On Wed, May 09, 2007 at 01:02:52PM +0200, Albert Rodriguez wrote:
>>> We're trying to receive two signals from two different RFX2400 in the
>>> same USRP. We've already
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Blossom wrote:
> On Wed, May 09, 2007 at 01:02:52PM +0200, Albert Rodriguez wrote:
>> We're trying to receive two signals from two different RFX2400 in the
>> same USRP. We've already read everything about setting the rx mux and
> These lines:
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eng. Firas wrote:
> Hi,
>
> How can I now my USRP REV number (and my daughter boards rev)? where I can
> read it on the broad?
>
> Firas,
Upper right corner of the USRP. Daughterboards, at least for the RFX
2400, right below the model name (middle o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey all,
Sorry to bring up painful memories :). I did some calculations to work
out frequency drift of the USRPs, and I wanted to know where I'm going
wrong.
The crystals in the RFX 2400 are spec'ed at 50ppm error, which is to say
that the maximum fr
Melody S wrote:
> Hi,
>
> I already have downloaded all the Usrp codes and Gnuradio code but when I
> go to this link >>> http://www.comsec.com/wiki?UsrpInstall for the
> Usrp Hardware setup and try to run the %tail -f /var/log/messages
> command, it gives me this error >>> No such fi
You can just do it from the gnuradio-core/src/lib directory too, unless
you actually add a new block.
-Dan
pradeepbhat wrote:
> I do the same but it seems to be achingly slow. Well I guess I would have
> keep doing that if i need to modify something.
> Pradeep
>
> Chris Stankevitz wrote:
>
>>
Davide Anastasia wrote:
Hi List,
I'm using a line link this in a script:
self.pack = gr.unpacked_to_packed_ss(1, gr.GR_LSB_FIRST)
It's give me only a sequence of zero, but I don't mind why!
Any suggestion?
What's the previous block? Is it binary? Are you using the wrong
endianness? For mos
Dan Halperin wrote:
Is there a howto for how to add a new signal processing block to the GNU
Radio libraries?
Sorry; in case it wasn't clear, I saw and used the how-to-write-a-block
code. But actually adding it to libgnuradio-core and getting SWIG to
process it was the tricky bit that
Is there a howto for how to add a new signal processing block to the GNU
Radio libraries? I made a gr_xor_bb (in src/lib/general) block, and it
took me about an hour to figure out all the files I had to modify to get
it made (the one I missed was general.i).
Anticipating Eric's response, what's th
Greg Troxel wrote:
> I think you should see real data packets at 1 Mb/s if there are any. I
> would expect multicast in IBSS mode to be like this.
>
Sorry; I was unclear. Yes, if I put my laptop into 1Mbps mode then I can
see data packets. Even in 2Mbps mode (especially if I use the -p
option).
Are you trying to capture real 802.11 1Mbps packets, or what?
To do that you'll need to do:
$ ./bbn_80211b_rx.py -f 2.462G -d 8 -b
>>> gr_fir_ccf: using SSE
Packet received, length = 148, rssi = -15, rate = 1.0 Mbps
Packet received, length = 147, rssi = -40, rate = 1.0 Mbps
Packet received, lengt
Eric Blossom wrote:
> On Thu, Mar 29, 2007 at 05:16:45PM -0700, Dan Halperin wrote:
>
>> Greg Troxel wrote:
>>
>>> I wonder if there is data somewhere in the flowgraph that's less than
>>> the amount needed for the next block to run. Perha
Greg Troxel wrote:
> I wonder if there is data somewhere in the flowgraph that's less than
> the amount needed for the next block to run. Perhaps there should
> be some sort of drain operation, or query for this (that adds over
> components), so one can find out what's going on.
>
This appear
George Nychis wrote:
> Thibaud Hottelier wrote:
>
>>> If any of that doesn't make sense, or people see it in a different way
>>> - please feel free to comment and criticize.
>>>
>>
>> It looks like your message did not arrive to mailing list! That
>> weird, it already happened to me once.
>
> Off t
DiX wrote:
> So I should update the SWIG to 1.3.31, right? Then how to call
> bin_statistics_f that is not in the Gnuradio 3.0 please? Thanks in advance.
>
> DiX
>
You'll want to uninstall the code you're using from the tarballs and
install from the trunk. To install from the trunk, see:
ht
Dan Halperin wrote:
> This is the final state of the flow graph:
>
> regular 2:1
> max_items_avail = 9
> noutput_items = 8191
> BLKD_IN
> were_done
I realized that the other two flow graph elements with max_items_avail >
0 have the same max_items_avail at in
(Eric, sorry I keep failing to reply all)
Eric Blossom wrote:
> On Thu, Mar 29, 2007 at 08:01:38AM -0700, Eric Blossom wrote:
>
>> On Thu, Mar 29, 2007 at 08:04:22AM -0400, Greg Troxel wrote:
>>
>>> I wonder if there is data somewhere in the flowgraph that's less than
>>> the amount needed
Eric Blossom wrote:
On Wed, Mar 28, 2007 at 09:39:14PM -0700, Dan Halperin wrote:
Same loopback code I emailed about earlier; this time I attached the
complete file (modulo some cleanup).
Here's my input file (in stupid x86 short ordering..):
$ hexdump input.txt
000 bbaa
Same loopback code I emailed about earlier; this time I attached the
complete file (modulo some cleanup).
Here's my input file (in stupid x86 short ordering..):
$ hexdump input.txt
000 bbaa ddcc ffee 1100 3322 5544 7766 9988
and then after going through loopback.py and being packed b
Hi,
So I made a loopback graph (file source, modulator, demodulator, file
sink) with a short 1K file in it. The following code works (runs and
exits without any exceptions):
graph = loopback_graph()
print "starting"
graph.start()
print "started"
print "stop
George Barrinuevo wrote:
--
complex_to_float = gr.complex_to_float ()
slicer = gr.binary_slicer_fb()
dst_file = gr.file_sink(gr.sizeof_float,
"out_file2.txt")
self.connect (ddc, complex_to_float, slicer,
dst_file)
--
ValueError: source and destination data sizes
bellzii wrote:
> audio_alsa_sink[hw:0,0]: Device or resource busy
>
That error looks like you've got some application locking the sound
card. Music player, esound, something like that?
> why is alsa not working does it have to with my RXF2400 daughter being not
> in fm range??
Shouldn't be, bu
Johnathan Corgan wrote:
> Dan Halperin wrote:
>
>> Is the CRC actually required? In the version of the code I'm using on
>> the lab machines (which is from early January), the framer_sink only
>> uses the length field to form the packet and the CRC is checked lat
Johnathan Corgan wrote:
> If a received packet fails CRC because of some pattern-specific
> synchronization problem, and if the upper protocol layers cause a
> retransmission, then the re-transmitted packet will have a different
> whitened bit pattern, allowing it to go through.
>
> While this does
Johnathan Corgan wrote:
> The CRC check on the payload is of course dependent on the correct
> length. If the length value gets corrupted but both copies are
> identical, the packet will still get rejected at the CRC check stage.
>
> Except in your case, where the state machine hangs up with a pay
Hey all,
I finally figured out the problem where my receivers would stop
receiving packets. It had nothing to do with hardware gain, thanks to
Tom Rondeau for pointing me off of that path.
So the gr_framer_sink_1 is a little screwed up. (As a reminder,) The
packet format is:
[ ACCESS_CODE(<=
Daniel Garcia wrote:
work (
int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const float *in = (const float *) input_items[0];
float *out = (float *) output_items[0];
for (int ii = 0; ii < noutput_i
Tom Rondeau wrote:
small increase in --costas-alpha. The main issue with these gains is the
different samples per symbol, which is corrected for mostly by changes in
the mu gain in the M&M loop. To keep the logic simple, I set costas-alpha
Using the old versions of the code, I noticed that t
Michael Dickens wrote:
> weekend, and it went without a hitch from start to finish. I actually
> wrote down what I did, so it's even repeatable (in theory).
I put my gnuradio install script up on the Wiki (UbuntuInstall); it
would be great if you would compare it to yours and make any useful
chan
Eric Blossom wrote:
> Try this work around for Ubuntu brokenness:
>
> Add /usr/local/lib to /etc/ld.so.conf then run
> # ldconfig
I added this to the Wiki (UbuntuInstall). Are we just supposed to use
the guest account?
-Dan
___
Discuss-gnuradio ma
Eric Blossom wrote:
I think you're going to want the CORDIC and CIC in place. Otherwise
What do you mean by "in place"? I was planning on leaving them there,
and inserting the correlator between them. Do you mean I don't want to
jump in the middle?
you're looking at the full IF passband o
Hi,
I'm trying to put the Barker correlator in the FPGA. This should greatly
improve the SNR of the BBN 802.11 code.
The plan is:
64Msps complex w/11MHz info -> Barker Correlator -> Decim by 16 -> 4Msps
complex with 1MHz info
instead of
64Ms complex w/11MHz info -> Decim by 8 -> 8Msps com
Hi,
I'm working on FPGA mods to push a little bit of work off of the
computer onto the USRP's FPGA. If I understand correctly, the right way
to do what I want is to create a new config file (e.g. a modification of
usrp_std_config_2rxhb_2tx.vh) with my changes in the defines.
First, the comme
Dan Halperin wrote:
Eric Blossom wrote:
Dan, how are you controlling the receiver h/w gain?
.. uh? Are there controls for that? Are there examples where they are used?
Again, what controls are there for controlling the receiver h/w gain? I
only see the set_pga() function in
Liu Xin wrote:
Sorry for the confusion.
My program jammer.py got Segmentation error and stopped.
Now I am trying to rebuild fftw_3.0.1 (since from previous list in this
group, some one suggested to rebuild fftw without --enable-sse), it cannot
pass through the make :(
Is your CPU fan spinning?
Anastasopoulos Achilleas wrote:
What I don't know how to do is to enqueue a message every time
I press a button.
Can someone point to the right direction as to how this event driven
behavior is implemented.
Look in the gnuradio-examples/python/digital/tunnel.py and subfiles.
transmit_path.py
Parth Pathak wrote:
> I am thinking of doing something with USRP and GNUradio especially
> in 802.11 domain or something in Bluetooth. If you people can please help me
> in
> buying the hardware first.
Make sure to re-read carefully Tom Rondeau's email of 5 December 2006
about the feasibility o
In packet_utils.py, function make_packet, there is always at least one
padding byte added:
pkt = ''.join((packed_preamble, packed_access_code, make_header(L),
whiten(payload_with_crc), '\x55'))
Can anyone explain why this is necessary? We've found in our tests that
not only is this necessary
Dan Halperin wrote:
> Eric Blossom wrote:
>
>> If they're not running as root (or holding CAP_SYS_NICE), the call
>> sched_setscheduler (the system call that enables realtime) will fail.
>>
>>
> They're not running as root, I just added the
Eric Blossom wrote:
> If they're not running as root (or holding CAP_SYS_NICE), the call
> sched_setscheduler (the system call that enables realtime) will fail.
>
They're not running as root, I just added the Ubuntu udev rules on the
website. I never explicitly enabled the SYS_CAP_NICE, it just
Hey,
I'm hoping someone has run into this problem before... We have a that
lab we access remotely, and sometimes the students get a little
overzealous in e.g. their rate selection, and the machines become
unresponsive. I seem to be having a hard time getting them to stop using
realtime mode.
Matt Ettus wrote:
> All RFX boards currently shipping are configured for MIMO_B mode, which
> requires a Rev 4 or higher USRP (serial number greater than 500).
>
> If you wish to use it with a USRP with a serial number below 500 you
> will need to do the following:
>
> Remove R115 (zero ohms) a
Does the USRP Rev 3 (1-3-2005) not handle the RFX boards? I guess it's
been two years...
-Dan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Achilleas Anastasopoulos wrote:
Any thoughts as to what is wrong?
configure:32018: gcc -o conftest.exe -g -O2 -Wall -I/usr/local/include/SDL
-I/usr/include/mingw -mno-cygwin -Dmain=SDL_main conftest.c -lwinmm
-L/usr/local/lib -lmingw32 -lSDLmain -lSDL -mno-cygwin -mwindows >&5
In file in
What are the practical effects of automatic transmit/receive switching
on the USRP subdevices (in particular, the RFX2400). If I have a
transmit-only application, will having this option on hurt my
performance in any way? The reason I ask is that if I leave it off, then
after the application finish
Eric Blossom wrote:
> Dan, how are you controlling the receiver h/w gain?
.. uh? Are there controls for that? Are there examples where they are used?
> Right now we don't implement closed-loop AGC (that is, there's no code
> that reads the RSSI and uses it to control the receiver gain). This
> is
Hi,
The groups in our networking class have each built an ad-hoc wireless
networks using a modified version of tunnel.py. For the next step we
want them to develop routing in a multi-hop environment. In the code
that we started them, we pretty much used the same transmit_ and
receive_paths.
I fig
nilay shah wrote:
> As my first test, I am trying to do connect 2 USRP board on same PC
> with 2400 Flex daugterboard and trying to do communication with
> scripts provided in GNU Radio distribution under digital folder.
>
> I am trying to modify Benchmark_Tx and Benchmark_Rx program scripts
> for
Eric Blossom wrote:
> On Mon, Jan 29, 2007 at 10:35:33AM -0800, Dan Halperin wrote:
>
>> Hi,
>>
>> What options are there for profiling GNU Radio code? I've done some
>> Python profiling, and some C profiling, but what options are there for
>&
Hi,
What options are there for profiling GNU Radio code? I've done some
Python profiling, and some C profiling, but what options are there for
this crazy SWIG-driven mix of the two?
Also, a flow graph question. In the main loop of the transmit path of my
benchmarking program, I have the following
An unanswered question from before:
>> Also, another (incidental) question, I get really bad performance when the
>> fusb_options set by realtime being true are used
>>
What are the fusb_options all about, and how can I get intuition on the
right settings for them?
> I think you're burnin
Eric Blossom wrote:
> overruns or underruns?
>
uO means a USRP Overrun right?
> Underruns are to be expected with tunnel.py, assuming that you're not
> feeding it data constantly.
>
> (When the in-band signaling stuff is complete, we'll have a more
> sensible interpretation for the underrun ca
Hi,
I'm trying to figure out what the right tools are to debug problems like
overruns in the USRP. I have a modified version of tunnel.py running (I
basically took out the tun/tap interfaces and added my own on top), and
I'm finding things like after exactly 700 128-byte packets I see an
overrun -
Brett Trotter wrote:
> Replying to myself here, I heard from someone that I should do make
> uninstall on the standard tree before doing make install on n4hy's tree. I
> make uninstalled both just to make sure it was cleaned out, and toasted
> /usr/local/lib/python2.4/site-packages/gnuradio (same f
Matt,
In the enclosure_open picture, you show the fan in the position such
that it is blowing outside air in. Is this the correct configuration? I
thought devices usually blew hot air out.
Secondly, for the 8 mounting points around the edges (rather than the 4
corners/ 4 center), those are simply
Also, gr.file_sink stores data native-Endian, so you may want to include
the Endian-ness in the description.
-Dan
Matt Ettus wrote:
> Chris Stankevitz wrote:
>
>> Q1: When using USRP source_c (complex) with decimation == 8, am I
>> getting 4 million complex samples per second? 64Mhz / 8 = 8MH
Hi,
I know this isn't really a gnuradio question, but a half-hour on Google
and browsing the Python site didn't find me the answer. What does ** in
Python do? Not in the exponent context (2 ** 4 = 16). In particular, I'm
looking at receive_path.py in the digital examples folder, the following
code
Hi,
I'm trying to get the code together to enable the RFX2400 board from a
C++ program. I'm mostly looking in usrp.py, usrp1.py, db_base.py, and
db_flexrf.py and copying commands like write_io and write_oe into their
C++ versions. Is there good documentation on all of these various
commands, and/o
Hey,
1) I want to add a switch for which USRP (the which_board argument) is
used in the example scripts. -w seems to be used by some scripts
(usrp_siggen.py for example); is -W open?
2) What's the proper procedure for submitting patches? I've seen people
email to the list...
Thanks,
Dan
_
Dan Halperin wrote:
> Hi,
>
> Is it possible to use two USRPs on the same machine? I'm having trouble
> finding in the USRP constructors (python or C) where you tell it which
> board to use if it finds multiple.
>
Ok, so this question was in fact as stupid as I t
Hi,
Is it possible to use two USRPs on the same machine? I'm having trouble
finding in the USRP constructors (python or C) where you tell it which
board to use if it finds multiple.
Thanks,
-Dan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.
Rohit Gupta wrote:
> Hi,
>
> I am looking for USRP/RFX2400 bloack diagrams, but it seems that the
> files at the link below are moved/deleted. If anybody has the diagrams
> mentioned below, pls send them to me directly.
Rohit,
I believe you want to look in the usrp-hw repository:
http://gnur
John Clark wrote:
> We are putting a new USRP module in service. Is there some firmware
> setup required,
> and if so what is the procedure. The 'manual' mentions if the LED is
> blinking in a
> certain way, that the firmware has not been loaded, but there's
> doesn't seem to
> be a paragraph on ho
Eric Hill Matlis wrote:
Thanks for the response. I guess my question is: where is that
information carried? Is it in the definition of the source? The two
definitions of the sinks look virtually identical to me:
am_rcv.py:
pre_demod = fftsink.fft_sink_c (self, panel,
I found that I can see a lot of structured noise on, e.g., the frequency
2.467G (802.11b channel 6) using my RFX2400 and the usrp_oscope script
in the gnuradio-examples/python/usrp directory. That gives me good
indication that the board works.
Also, if you have two boards, run usrp_siggen on one a
Eric Blossom wrote:
> The rx_mux value of -1 means "do the right thing". It ends up setting
> the mux to 0x32103210.
>
> The tx_mux value of -1 means "do the right thing". For the single
> channel case it sets it to 0x0098.
>
Cool. Thanks!
>> I've also tried to mimic usrp_oscope.py and usrp_
Hi,
I'm trying to understand the C++ interface to the USRP. I've read the
library files (usrp_{basic,standard}.h) and the test_usrp_standard_tx
and test_usrp_standard_rx scripts.
My current mission is to modify (or use?) these scripts to get the same
information out of the USRP that I put in. (Us
Shravan Rayanchu wrote:
> 1. How to use the quadpatch -- I have a copper coax tube that came
> along with the antenna. I could connect the coax to TX/RX port on the
> RFX 2400, but what after that? .. the quadpatch pad does not seem to
> have any interface . do I need to solder or something? (I
Hi,
Are there any good (standard) tests for the flex2400, or can anyone tell
me what I'm doing wrong?
I tested the BasicRX and BasicTX boards by plugging a shielded wire
between them, running usrp_oscope.py, and running the
test_usrp_standard_tx script. Signal in, signal out - happiness, aft
[EMAIL PROTECTED] wrote:
>
>
> >The first issue, with the automake version, can be addressed in the
> >Cygwin setup.exe program. It should be offering you version 1.9.6. If
> >it is not, the mirror you selected must be out of date.
>
> A cygcheck revealed the automake version as u indicated
>
[EMAIL PROTECTED] wrote:
I have a USRP and it seems to communicate fine with
the FC5 box. I have looked through the discuss-gnuradio mail archive and it
seems like python is not finding gnuradio module. I checked path from within
python for
/usr/local/lib/python/site-packages as mentioned in pr
Kyle Zhou wrote:
have u added /usr/local/lib in your LD_LIBRARY_PATH environment variable?
cheers
kyle
- Original Message -
Yep, that was it. I created /etc/ld.so.conf.d/usrp.conf containing the
line /usr/local/lib and then re-ran ldconfig as root. Stupid FC4.
Thanks,
Dan
__
Hi,
I must be doing something really stupid. I'm trying to figure out how to
compile against the C++ libraries.
I copied test_usrp_standard_tx.cc, timestuff.h, and timestuff.c to a new
folder, then I compiled the application using
g++ test_usrp_standard_tx.cc timestuff.c -lusrp -Wall
an
Jim Borynec wrote:
Try using a meter long wire.
That seems to have fixed the problem; I took the two antennas and linked
them end-to-end and all of a sudden the scope reflects a change with and
without the antennas connected. Thanks so much!
What kind of wire is best? Are we talking just a
ng
used. I had the best luck with this.
Depending on your scanning bandwidth, I don't know if you'll actually pick
up any listenable stations, so I'd just use the aforementioned file for FM
testing purposes.
Written
Dan Halperin wrote:
I've used the 2.4GHz RX/TX board, bu
I've used the 2.4GHz RX/TX board, but I have since been using the Basic
RX and Basic TX boards.
-Dan
Written wrote:
Hi Dan,
What daughterboards are you using?
Thanks,
Written
Dan Halperin wrote:
Hi all,
I'm just beginning grad school and trying to get my USRP board up an
Hi all,
I'm just beginning grad school and trying to get my USRP board up and
running so I can start playing. I've tested our equipment on two
different machines now; one an older box running FC4, 512MB ram, with an
Intel(R) Celeron(R) CPU 2.40GHz. I've also tried one on a newer laptop
(comp
101 - 177 of 177 matches
Mail list logo
