On 10/08/2011 12:01 PM, discuss-gnuradio-requ...@gnu.org wrote:
Date: Sat, 8 Oct 2011 01:33:09 -0400
From: Achilleas Anastasopoulos
To:discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] file source/sinks and named pipes
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1
I have
Michael,
Good description of the TPB running mechanism!
Here is a more detailed explanation with some graph illustrations (see
page 2 of the linked paper):
http://gnuradio.org/redmine/attachments/download/264
Andrew
On 09/23/2011 12:01 PM, discuss-gnuradio-requ...@gnu.org wrote:
Message:
Josh,
Thanks for posting your work on stream tag.
I'd like to try out your code. Would you please tell me which version of
GNU Radio to use with your code examples? Any other specific requirements?
I will let you know what I will get.
Thanks,
Andrew
On 09/24/2011 12:01 PM, discuss-gnuradio
Josh, thanks for the information. Where can I get those few
implementations using stream tags?
Andrew
On 09/21/2011 12:31 PM, Josh Blum wrote:
On 09/21/2011 09:10 AM, Feng Andrew Ge wrote:
Josh,
I noticed that there are many useful commands enabled by UHD. For
example, they are used in uhd
Eric, in your 2009 experiment indicated below, did the USRP2 sustain the high
temperature of 150 F?
Is there anybody else who has tried to use USRP2 continuously at a temperature
above 105 F? Your feedback is highly appreciated.
Andrew
On Mon, Jul 13, 2009 at 1:13 PM, Eric Matlis wrote:
.stop())/2.0);/
On 04/20/2011 07:01 PM, Josh Blum wrote:
On 04/20/2011 03:24 PM, Feng Andrew Ge wrote:
Josh,
Thanks for the clarification.
Does it mean that, by this hacked code, turning off RX mixer at
transmitting time happens on FPGA? Or does it happen at UHD on the host
side
with 4095 which I cant figure out why.
Thanks,
Dave
*From:* Feng Andrew Ge
*To:* David Barton
*Cc:* discuss-gnuradio@gnu.org
*Sent:* Fri, April 29, 2011 2:57:28 PM
*Subject:* Re: [Discuss-gnuradio] Tunnel.py exception
Nick,
Could you confirm that switching TX frequency takes "a few ms"? How did
you get this number? Is it the same for switching TX frequency after
the code has been running for a while, that is, reconfiguring the TX
frequency dynamically?
Andrew
On 04/29/2011 12:00 PM, discuss-gnuradio-re
Dave
*From:* Feng Andrew Ge
*To:* discuss-gnuradio@gnu.org; David Barton
*Sent:* Fri, April 29, 2011 10:35:52 AM
*Subject:* Re: [Discuss-gnuradio] Tunnel.py exception
Dave,
In the patch I told you, please change 4096 to 4095, that is
Tom, in your email exchange with Richard Clarke on 29 Jan 2008, as shown below,
it was mentioned that a multi-path channel model might be integrated into GNU
Radio library.
I am wondering whether this has happened or not? If not, do you still have
code written by Richard's student? If so, woul
Dave,
In the patch I told you, please change 4096 to 4095, that is,
if (string_len> 18)& (string_len< 4095) :
Here is how this happened:
When you send a packet in GNU Radio, there is a header right ahead the payload
(plus CRC bits).
The header has 4 bytes which consist of two same 2-byte
Any idea?
Thanks,
Dave
Message: 11
Date: Thu, 21 Apr 2011 16:26:56 -0400
From: Feng Andrew Ge
To:discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Tunnel.py exception
Message-ID:<4db09310.4020...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Dave,
To bypas
Dave,
To bypass this problem, change the pkt.py file. In the end, after
msg = self.rcvd_pktq.delete_head()
add
if (string_len > 18) & (string_len < 4096) :
ok, payload = packet_utils.unmake_packet(msg.to_string(),
int(msg.arg1()))
Andrew
On 04/21/2011 12:00 PM, discuss-gnuradio-requ.
Josh,
Thanks for the clarification.
Does it mean that, by this hacked code, turning off RX mixer at
transmitting time happens on FPGA? Or does it happen at UHD on the host
side?
Andrew
On 04/20/2011 06:15 PM, Josh Blum wrote:
On 04/20/2011 03:03 PM, Feng Andrew Ge wrote:
Josh,
When
Josh,
When you say " In any case, you can shutoff the rx mixer in full duplex
mode with this little change:", is it true that this radio, once started
with the changed code, cannot receive anymore at it runtime?
Andrew
On 04/19/2011 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote:
Messag
Achilleas,
I have looked at the gr-trellis code and my understanding is that the
code is used mainly for simulation in GNU Radio (signals don't go over
the air). I was thinking about integrating the code into the digital
examples, e.g., transmit_path.py and receiver_path.py. However, I have
Hi, all,
Does any person happen to know whether USRP2/WBX has been given a J/F 12
application number yet?
I'd greatly appreciate if you have information about this?
Regards,
Andrew
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http:/
Here is what you need to do
SIOCSIFHWADDR = 0x8924
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
ioctl(s, SIOCSIFHWADDR, struct.pack("16sH6s", ifname,
socket.AF_UNIX, hwaddr))
Andrew
On 03/24/2011 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote:
Message: 11
Date: Thu, 2
Would experienced users please recommend me a 10MHz REF clock for
stabilizing USRP2? I followed previous emails and found that "any 10 MHz
reference (square or sine wave, DC-blocked and terminated in 50 ohms, 3V
pk-pk) with will suffice, it does not need to be a pulse per second
source." As
Josh,
I haven't found time learning how to create new branches and upload
files using git yet, would you mind post the attachment?
Thanks,
Andrew
On 03/14/2011 03:01 PM, Josh Blum wrote:
On 03/14/2011 06:23 AM, 齐亮 wrote:
Hello, everybody.
I need the code of “tunnel.py” which can b
Josh,
The code works well now, thanks a lot for your help in the past week.
The delay was caused by a system setting in my computer and not related
to UHD code.
Andrew
On 03/04/2011 12:19 AM, Josh Blum wrote:
As such, do you know an approach to solve this blocking problem? I have
tried
Josh,
Thanks for pointing out the time function library, which I actually
intended to call for printout analysis. As shown below, the huge delay
was not caused by the WORK function's SEND. I am still trying to figure
out the root, will let you know once I have it.
Andrew
SEND:
ping 192.1
Josh,
I have observed uhd_usrp_sink quite often blocks when working in
non-continuous scenarios.
Here is one example, node 192.168.200.2 (A) pings 192.168.200.1 (B), one
result (on node A) is here:
ping 192.168.200.1 -i 0.5
PING 192.168.200.1 (192.168.200.1) 56(84) bytes of data.
64 bytes f
Another question is how "UUU" gets generated---I still got many of
them? Further, "UUU" makes sense when GNU Radio works with an audio
device; however, I am not sure about its use when GNU Radio sends
non-continuous data to USRP. When this "UUU" happens, will it be
possible that some samples
Josh,
Before I test it with the raw ethernet driver, would you tell me what's
the difference in gr_uhd_usrp_sink between blocking send and
non-blocking send? Since the sending data is already in the buffer and
it is UDP sending, I don't see any difference. But perhaps you might
point out any
Josh,
Once I start uhd_benmark_rx.py, USRP2 continuously sends data to the
host. The data rate is the sample rate times 4 (bytes per sample). This
happens even when no transmitter is around. Therefore, I assume that the
ADC just converts noise into samples and USRP2 sends those samples at
th
noutput_items? Is this purely GNU
Radio scheduler's job?
One previous question I had is this: why *recv_buff_size* is needed for
benchmark_tx.py which involves only gr_uhd_usrp_sink.cc? I thought only
*send_buff_siz* is needed.
Andrew
On 03/01/2011 08:20 PM, Josh Blum wrote:
On 03/01/
buffer) and uhd_single_usrp_source (receiving buffer)?
When I started uhd_benchmark_tx.py, it also asked for specification of
*recv_buff_size, where is it used? *
On 03/01/2011 07:01 PM, Josh Blum wrote:
On 03/01/2011 03:25 PM, Feng Andrew Ge wrote:
Josh,
Everything is in the attachment
buffers and how are data are processed, by FIFO or LIFO? If overflow
happens, will newly coming packets get simply dropped?
Andrew
On 03/01/2011 04:18 PM, Josh Blum wrote:
On 03/01/2011 12:52 PM, Feng Andrew Ge wrote:
> Josh,
>
> That's great, thanks.
>
> When using
er
packet. Which looks like this:
return seq_type(_last_seq_out -_last_seq_ack)< _max_seqs_out;
-josh
On 02/28/2011 02:42 PM, Feng Andrew Ge wrote:
Marc,
Unfortunately I don't much experience with Ethernet pause-frame flow
control. For my applications, sending is not an issue
josh
On 02/28/2011 02:42 PM, Feng Andrew Ge wrote:
Marc,
Unfortunately I don't much experience with Ethernet pause-frame flow
control. For my applications, sending is not an issue since we don't
send high data rates; we are more concerned at the receiver side,
particularly its latency (w
02/28/2011 11:21 AM, Feng Andrew Ge wrote:
Josh,
Thanks for sharing the information and your changes sound quite
reasonable.
However, it seems that your changes have introduced some bugs at the
transmitter side. I updated my system using your new code (following
your instructions in your Feb.
nding data into USRP2 (based on observation from wireshark results).
Both cases used 1500B for each packet and the send-buff-size was 100kB.
Would you please take a look at this?
Andrew
--
Message: 3
Date: Sat, 26 Feb 2011 16:19:06 -0500
From: Feng Andrew Ge
Subject: [Discuss-gn
Josh,
When you say "2x" performance increase, do you mean CPU performance or
send()/recv() latency? Do you mind saying a few words on what changes
you have made?
Andrew
On 02/26/2011 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote:
-
I did some test on DBPSK2 checked out from gnuradio.git next and
observed some interesting result.
I set up a transmitter and a receiver, using UHD. Two radios were close
to to each other (2~3 feet). I set TX and RX gain both as 18dB. When I
started the transmitter first and then the receive
I posted one question in an early email, but it might be better to put
it together with other questions here. I'd greatly appreciate your answers.
(1) When transmitting UHD packets (with USRP2 + WBX), after each
transmission, there is either one or a few "U" printed out. What does
"U" mean?
rame_size"] = "1024"
-josh
On 02/15/2011 10:57 AM, Feng Andrew Ge wrote:
> Could anybody please tell me how to set the following parameters? I am
> working on supporting UHD in the Python digital communication example
> and hopefully I can soon share my code with the l
Could anybody please tell me how to set the following parameters? I am
working on supporting UHD in the Python digital communication example
and hopefully I can soon share my code with the list.
* *recv_frame_size:* The size of a single receive buffer in bytes
* *num_recv_frames:* The nu
link.
Thanks,
Andrew
--
Feng (Andrew) Ge, Ph.D.
Senior Research Scientist
Knowledge-Based Systems Department
One Telcordia Drive
Piscataway, NJ 08854
(732) 699-2376
f...@telcordia.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http
Tom or Josh,
I guess that you two know as best the current status of UHD supporting
GNU Radio Python examples. Could you please kindly share some
information about this and also possible schedules, e.g., will it be
available in GNU Radio 3.3.1 whose release is expected to be quite soon?
Rega
Josh or Matt,
Would you please tell me which TI OMAP processor is exactly used in
E100, OMAP3530 or OMAP 3525 or other?
Also, is there some hardware architecture diagram available somewhere?
What software support is currently available?
Thanks,
Andrew
_
Eric,
In my experiments, I had one transmitter and one receiver, which used
tunnel.py for communicating with each other. Occasionally, I got the
problem that one radio stopped receiving, but could still transmit. I
used TX and RX printings to observe this behavior. In the receiving
path, ther
Nick, thanks for pointing this out. Do you know whether there is some
plan to update benchmark_tx/rx.py for UHD?
Andrew
On 11/15/2010 1:06 PM, Nick Foster wrote:
benchmark_tx uses the old USRP2 driver, not the UHD driver.
--n
On Mon, 2010-11-15 at 09:30 -0500, g...@vt.edu wrote:
Installed
Marcus,
Would you post your flow graph? Also, did you use TUN/TAP?
Andrew
On Mon, Oct 18, 2010 at 08:37:33PM -0400, Marcus D. Leech wrote:
> I've noticed latency issues with one of the applications I'm working on.
> Latencies of up to tens of seconds
> have been observed, which I tri
Eric,
I found a puzzling fact about running GNU Radio on the 64-bit Lenovo
workstation D20.
Basically, the maximum packet size (payload at the transmitter side in
the benchmark_tx.py) must be less than or equal to 221. Below this size,
packets from the workstation can be correctly received
Yes, I was talking about the PFB blocks. Thanks.
However, the comparison result of IIR and FIR in terms of computational
efficiency is a little disappointing; I had hoped that IIR can be better.
Andrew
On 10/16/2010 5:18 PM, Tom Rondeau wrote:
On Wed, Oct 13, 2010 at 1:20 PM, Andrew Ge
Tom,
You have been doing some good work in using more efficient filters; have
you integrated your code into GNU Radio code base yet? If there is a
working version, could you please tell me where I can find it? Is it in
the development version or in GNU Radio 3.3 release version.
More import
Tom,
You have been doing some good work in using more efficient filters; have
you integrated your code into GNU Radio code base yet? If there is a
working version, could you tell me where I can find it? Is it in the
development version or in GNU Radio 3.3 release version.
More importantly,
pe that, after stepping down as the "Maintainer", you will have
more time for other things that you like to do in your life.
Best regards,
Feng (Andrew) Ge, Ph.D.
Senior Research Scientist
Telcordia Technologies, Inc.
On 9/10/2010 12:00 PM, discuss-gnurad
Eric,
Thanks for pointing out this. Now I am able to install GNU Radio 3.3 on
Ubuntu 10.04. I have tested some functions without USRP and they work.
Andrew
On 5/18/2010 12:23 PM, Eric Blossom wrote:
On Tue, May 18, 2010 at 10:40:40AM -0400, Andrew Ge wrote:
(1) tarball GNU Radio 3.2.2
Forgot to add that it was on out-of-box HP laptops.
Andrew
On 5/18/2010 10:40 AM, Andrew Ge wrote:
(1) tarball GNU Radio 3.2.2 has Make error with boost_1_39_0,
boost_1_40_0, boost_1_41_0, boost_1_43_0 with or without
--prefix=/opt/boost_1_4*_0 (where boost is installed)
/bin/bash
(1) tarball GNU Radio 3.2.2 has Make error with boost_1_39_0,
boost_1_40_0, boost_1_41_0, boost_1_43_0 with or without
--prefix=/opt/boost_1_4*_0 (where boost is installed)
/bin/bash ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall
-Woverloaded-virtual -pthread -o test_usrp_standar
io will be tremendous.
Please join me in congratulating Tom.
Bob
--
Feng (Andrew) Ge
Graduate Research Assistant, CWT
Center for Wireless Telecommunications
[EMAIL PROTECTED] Tech
436 Whittemore Hall
Blacksburg, VA 24061-0111
Office: 540-231-2558
Mobile: 540-239-2275
Fax: 540-231-3004
Em
Eric,
I am just wondering whether this piece of code exists somewhere or not
to enable
>
> 100MS/s I & Q is decimated to 25MS/s complex. We use 16-bit I & Q.
> That works out to ~800Mbit/s on the gigabit ethernet, which the USRP2
> can sustain, no problem.
If so, would you please kindly po
I am trying to enable non-blocking reading for os.read(tun_fd, *)
through open_tun_interface() in tunnel.py, did anybody do so before? Are
there any potential problem for the whole tunnel.py code if I do so?
Thanks
Andrew
___
Discuss-gnuradio mailin
George,
Thanks very much, that's what I want.
Andrew
George Nychis wrote:
Hi,
This is addressed on the FAQ page on the wiki. I'd link you but I'm on
a handheld.
- George
On Apr 20, 2008, at 5:45 PM, Feng Andrew Ge <[EMAIL PROTECTED]> wrote:
I want to use two USRPs
I want to use two USRPs on one computer with one USRP for TX and the
other for RX, is it feasible to control two USB ports which host two
USRPs in GNU Radio? Any suggestion will be highly appreciated.
Andrew
___
Discuss-gnuradio mailing list
Discuss
appreciated!
Andrew Ge
Did you setup udev as the wiki page instructed?
Are you in group usrp?
Eric
Eric,
I strictly followed the setup udev as the wiki page:
http://www.gnuradio.org/trac/wiki/UdevConfig. However, because the new
kernel 2.6.24-rc4-gd7f0b481uses different sysfs from
Dear all
I have been reading GNU Radio discussion for half a year, first time to
post a topic. Thanks a lot for all the GNU Radio knowledge I learned
from you guys.
Now I am doing some signal detection project. I want to collect some
signal in 700MHz range with bandwidth as larger as possibl
59 matches
Mail list logo
