On 10/08/2011 12:01 PM, discuss-gnuradio-requ...@gnu.org wrote:
Date: Sat, 8 Oct 2011 01:33:09 -0400
From: Achilleas Anastasopoulosanas...@umich.edu
To:discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] file source/sinks and named pipes
Message-ID:
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,
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 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
: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?
In this case the mixer is controlled
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
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,
*From:* Feng Andrew Ge gefengflo...@gmail.com
*To:* discuss-gnuradio@gnu.org; David Barton david.barto...@yahoo.com
*Sent:* Fri, April 29, 2011 10:35:52 AM
*Subject:* Re: [Discuss-gnuradio] Tunnel.py exception
Dave,
In the patch I told you
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,
which I cant figure out why.
Thanks,
Dave
*From:* Feng Andrew Ge gefengflo...@gmail.com
*To:* David Barton david.barto...@yahoo.com
*Cc:* discuss-gnuradio@gnu.org
*Sent:* Fri, April 29, 2011 2:57:28 PM
*Subject:* Re: [Discuss
Sorry that I skipped one line when I made the copy
msg = self.rcvd_pktq.delete_head()
string_len = len(msg.to_string())
On 04/25/2011 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote:
Date: Mon, 25 Apr 2011 06:56:53 -0700 (PDT)
From: David Bartondavid.barto...@yahoo.com
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,
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:
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
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
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, 24
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
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
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
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
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/2011 04:39 PM, Feng Andrew Ge wrote:
Josh,
Your explanation makes sense. Is there a quick
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
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
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 get
, 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 (which is related to CPU consumption too
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 since we don't
send high data rates; we are more concerned
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 UHD in GNU Radio, I
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
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. 24's email titled Re: GRC + N210 +
/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. 24's
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
, 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 list.
* *recv_frame_size:* The size of a single receive buffer in bytes
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? Is
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
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
Emai: [EMAIL
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 point
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
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
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 on one computer
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
44 matches
Mail list logo
