Hello,
The USRP2 has a high data rate and it needs a lot of resources, I don't
think that it is a good idea to run both USRP2's on one machine.
Ben Yahmed
Miklos Christine wrote:
Hello,
I don't encounter this problem anymore. Someone else was trying to
debug the code.
I tried to run both
Hello,
I don't encounter this problem anymore. Someone else was trying to debug the
code.
I tried to run both USRP2's on one machine with 2 gigabit ethernet ports. It
did not seem to work.
Does anyone know if it is possible to run both USRP2's on one machine?
Thanks,
Miklos Christine
On Mon, Ma
Hi Everyone,
I think I understand the problem with the DBPSK/DQPSK. Currently, the
modulate function modulates the entire packet as 2Mbps. However, the PLCP
decode function expects the packet to be DBPSK for the header and then DQPSK
for rest of the payload.
The solution I have devised is to rew
Hi,
I do not encounter this problem, the simple_mac run in a correct way for
me. Do you use the latest versions of the firmware and fpga?
Ben Yahmed
Miklos Christine wrote:
Hello Ben,
When I try to run the version of simple_mac that you posted, I get an
error.
It seems like an infinite lo
Hello Ben,
When I try to run the version of simple_mac that you posted, I get an error.
It seems like an infinite loop that prints to stdout:
2nstreams:
It happens at the call to fg.rxpath.start() .
Do you have the same problem?
Thanks,
Miklos Christine
On Wed, May 6, 2009 at 10:46 AM, Ben Ya
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ben Yahmed wrote:
> Hi all,
> I modified the gain in the bbn_80211_rx.py file from 46 to 27 and the
> loss ratio has fallen down to 15-20%. Do you have any idea about the
> best value to put?
> this is the ping capture:
>
> # ping 10.0.0.1PING
Hi all,
I modified the gain in the bbn_80211_rx.py file from 46 to 27 and the
loss ratio has fallen down to 15-20%. Do you have any idea about the
best value to put?
this is the ping capture:
# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_s
Has anyone been able to get 2Mbps to work, which uses DQPSK instead of
DBPSK? I have had no luck, even with the test script. . .
--Colby
On Sun, Apr 26, 2009 at 9:39 PM, Colby Boyer wrote:
> I think some of the work my group will require porting the mac layer to the
> USRP2. I'll keep the list
I think some of the work my group will require porting the mac layer to the
USRP2. I'll keep the list posted.
--Colby
On Sat, Apr 25, 2009 at 2:32 PM, wrote:
> The next step is to convert the simple_mac.py inorder to work with USRP2.
> Who is interested in this work?
>
> Ben Yahmed
>
> > It was
The next step is to convert the simple_mac.py inorder to work with USRP2.
Who is interested in this work?
Ben Yahmed
> It was a firmware problem, and after updating the latest firmware I was
> able
> to transmit/receive at 1Mbps.
>
> -Colby
>
> Good work everyone! =)
>
> On Fri, Apr 24, 2009 at 1
It was a firmware problem, and after updating the latest firmware I was able
to transmit/receive at 1Mbps.
-Colby
Good work everyone! =)
On Fri, Apr 24, 2009 at 11:23 AM, Colby Boyer wrote:
> Hi,
>
> I am unable to replicate the results. Are you using the code from the
> CGRAN repo without an
Hi,
I am unable to replicate the results. Are you using the code from the CGRAN
repo without any modifcations?
I am also receiving a "usrp2::ctor reset_db failed" error. Could this be a
problem?
Thanks,
Colby
On Fri, Apr 24, 2009 at 10:41 AM, Eric Blossom wrote:
> On Fri, Apr 24, 2009 at 02
On Fri, Apr 24, 2009 at 02:15:36PM +0200, Ben Yahmed wrote:
> Good News
> I finally succeeded to receive with an USRP2 packets sent with another
> USRP2. I tryed to modify the parameters and found the magic combination:
Yeah!
Eric
___
Discuss-gn
Yep!
It works also here between USRPs2 with the code from colby's branch (also with
other parameters, as far as interp*spb=~200).
The problem is the DSSS... I don't know why, but whenever Barker is enabled,
nothing works anymore... :-(
Have you tried?
Colby mentioned that even the test has prob
Good News
I finally succeeded to receive with an USRP2 packets sent with another
USRP2. I tryed to modify the parameters and found the magic combination:
./bbn_80211b_tx.py -f 2.4G -e eth1 -i 24 -r 20
>>> gr_fir_ccf: using SSE
Network interface: eth1
USRP2 address: 00:50:c2:85:30:cb
Us
I run wireshark on the eth0 to see the traffic between USRP2 and the PC
while running the rx file.
ok for the test code.
Colby Boyer wrote:
Ah, so wireshark on a 802.11b card can capture packets sent by the USRP2?
I will modify my test code so that it usable by some one else. It is
sorta hack
Hi all,
Thank you Colby for the update. I just run the code and it seems to
work, but when I send packets from another USRP2 with the same frequency
(bbn_80211b_tx_port2.py) I don't see anything happening.
when I run wireshark, a huge number of packets was arriving, something
like 11000 packets
Hi All,
So I ran a sanity test on the TX and RX functions.
In the tx.py file, I added a file sink to record the data being sent to the
USRP2. In the rx.py file I added a file source to read that data, rather
than reading samples from the USRP2. When I did this, it was able to
successfully demodul
Hi Ben,
I uploaded my files to the usrp2_version in the CGRAN server. It uses the
same files I used to run my USRP2 tests, so it should interface with the
hardware correctly. Let me know if it does not.
Bests,
Colby
On Fri, Apr 17, 2009 at 10:15 AM, Colby Boyer wrote:
> Hi Ben,
>
> Perhaps I h
I'm trying to modify the bbn_80211b_rx.py code inorder to receive
packets but in every step I'm facing an AttributeError like:
AttributeError: 'usrp2_source_32fc_sptr' object has no attribute
'make_format'
AttributeError: 'usrp2_source_32fc_sptr' object has no attribute
'set_format'
Attrib
That's good news.
The code I sent seemed to be working but i realy didn't tested it. We have
only one USRP2 here and we were trying to receive pkts using a 802.11b PCI
card (Realtek RTL8180L chipset), but without success (some problems with the
card configuration).
2009/4/17 Valerio, Danilo
>
Hi Colby!
We have also tried without success.
We have used the TX path from Tiago and a modified version of the RX path
(firmware and FPGA at their latest update).
I also felt confident that the the TX path works, and consequently that the RX
path had some problem.
So we have tried to transmit
Hi All,
I've been trying to run some hardware tests between two USRP2s, but I have
had no success in receiving packets. I am using the modified TX from Tiago.
I feel sorta confident that the TX code works, because when I run the
usrp2_fft.py, I see a wave form being transmitted over the channel.
Hi all,
Since I have tested the tx code (bbn_80211b_tx_port2.py), I wanted to run the
bbn_80211b_rx.py inorder to capture the packets sent but I encountred this
error:
# ./bbn_80211b_rx.py
Traceback (most recent call last):
File "./bbn_80211b_rx.py", line 179, in
main ()
File "./bbn_8
Thank you for your help, the error disappeared
Ben Yahmed
Johnathan Corgan wrote:
The issue is with the output signature being declared in the last part
of the above line. It is trying to create a hierarchical block with a
variable number of output ports. This functionality is not yet
suppor
On Tue, Apr 7, 2009 at 5:02 AM, Ben Yahmed
wrote:
> File "/root/usrp2_version/gr-bbn/src/examples/bbn_80211b.py", line 95, in
> __init__
> gr.hier_block2.__init__(self, "bbn_80211b", gr.io_signature(1, 1,
> gr.sizeof_char), gr.io_signature(1, 2, gr.sizeof_gr_complex))
> RuntimeError: Hierarchic
Hi all,
I'm very interested in the code you are discussing and as a first step I
installed gnuradio and the svn code taken from
https://www.cgran.org/browser/projects/bbn_80211/branches/usrp2_version
on a fedora core 10 and tried to test the bbn_80211b_test.py, but I
encountred this problem:
On Mon, Apr 06, 2009 at 04:29:20PM -0300, Tiago Rogério Mück wrote:
> Updated from the trunk and I'm not getting that msg anymore.
>
> Everything seems to be ok now.
Glad to hear it! Thanks for letting us know.
Eric
> 2009/4/3 Eric Blossom
>
> > On Fri, Apr 03, 2009 at 10:45:18AM -0300, Tia
Updated from the trunk and I'm not getting that msg anymore.
Everything seems to be ok now.
2009/4/3 Eric Blossom
> On Fri, Apr 03, 2009 at 10:45:18AM -0300, Tiago Rogério Mück wrote:
> > I fixed the problem. The top_block on bbn_80211b_tx_port was not being
> > properly initialized.
> >
> > It
Great to hear. I will be able to start testing with two USRPs soon. I am
waiting on some hardware. I will let the list know what I find out.
On Fri, Apr 3, 2009 at 9:09 AM, Eric Blossom wrote:
> On Fri, Apr 03, 2009 at 10:45:18AM -0300, Tiago Rogério Mück wrote:
> > I fixed the problem. The top_
On Fri, Apr 03, 2009 at 10:45:18AM -0300, Tiago Rogério Mück wrote:
> I fixed the problem. The top_block on bbn_80211b_tx_port was not being
> properly initialized.
>
> It seems to be working now, but when I use 8 samples per data bit instead of
> 4 I randomly got the following error:
>
> usrp2::
I fixed the problem. The top_block on bbn_80211b_tx_port was not being
properly initialized.
It seems to be working now, but when I use 8 samples per data bit instead of
4 I randomly got the following error:
usrp2::tx_raw: FIXME: short packet: 7 items (56 bytes)
Does anyone know what this mean?
Hi all,
I'm trying to port the tx code to the usrp2 based on Colby's branch and i'm
having some problems. The program freezes when the 3rd packet is being sent.
The program uses a gr.message_source to buffer the packets and convert them
into a data flow to the modulator, and the problem is that,
Hi all,
I created a branch on the cgran server for the usrp2 code. If anyone is
interested in still using the usrp with the hier_block2, just dont use the
rx/tx.py files. The rest of the files should work with the usrp1.
Cheers,
Colby
On Mon, Mar 30, 2009 at 3:58 PM, George Nychis wrote:
> Hi
Hi all,
CGRAN's trac has a core dumping issue that I still have not figured out how
to address yet. So, if you're using the wiki and get blank pages or a 500
internal server error, sorry. I've been trying to sort it out, but no luck
yet:
http://www.gossamer-threads.com/lists/trac/users/40954
I
The cgran server seems to be down. I'll let you know when I am able to get
an account.
On Mon, Mar 30, 2009 at 8:36 AM, Colby Boyer wrote:
> Sure. I will try to get a cgran account and upload my code to their SVN. It
> would then be easy to see the changes I made.
>
>
> On Mon, Mar 30, 2009 at 2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Costantini, Andrea wrote:
> Hi Colby,
>
> I am glad that I am not the only one trying to port the code.
> I guess you are in a more advanced state. I wasn't even able to run the
> test.py. ;-)
>
> Would you like to share your modified code (even if i
Hi Douglas!
Yes, I was referring to your branch (thank you for that).
This comment on the CGRAN made me thinking that also the tx path was
changed:
"bbn_80211b_tx.py - douggeiger: Works with hier_block2 - with some help
from code found …"
Have you uploaded some work-in-progress on the rx pa
Hi Colby,
I am glad that I am not the only one trying to port the code.
I guess you are in a more advanced state. I wasn't even able to run the
test.py. ;-)
Would you like to share your modified code (even if it is not finished)?
so that I try to understand your modifications.
Best Regards,
Hi Andrea,
I am also working to port the 802.11b code to the USRP2. I have finished
converting the code to hier_block2, and the bbn_80211b_test.py script works
correctly and it can send packets in simulation. I am currently working on
modifying the rx, and tx files to connect to the USRP2, but bee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Costantini, Andrea wrote:
> Dear all,
>
> I'm trying to port the Douglas BBN 802.11b code on the USRP2 working
> with the last version of GNU-Radio (3.2SVN)
>
> The last version of Douglas bbn 802.11b already work with hier_blok2 but
> not with USRP2
Dear all,
I'm trying to port the Douglas BBN 802.11b code on the USRP2 working
with the last version of GNU-Radio (3.2SVN)
The last version of Douglas bbn 802.11b already work with hier_blok2 but
not with USRP2, so,
in order to do this porting I followed the recommendations below :
-
htt
42 matches
Mail list logo
