==
USRP News, July 2007
==
News Items
1USRP2
2USRP Demo Contest
3Vertical Antenna Information
4Offices Closed July 30th-August 21st
===
Hsin-mu Tsai wrote:
> I didn't change the nice value (with top or nice, etc.). I thought
> enabling the real time setting (gr.enable_realtime_scheduling) in the
> script will automatically change priority to (max + min) /2.
I don't actually know what the gr.enable_realtime_scheduling
function do
I didn't change the nice value (with top or nice, etc.). I thought
enabling the real time setting (gr.enable_realtime_scheduling) in the
script will automatically change priority to (max + min) /2.
are 'priority' and 'nice' the same thing?
Thanks,
-Michael
That all looks well-formed. Are
Sorry I reread your original email, ... you're now using settings where
the there are no more (or very few) USRP overruns? Is that correct?
Yes. When using smaller fusb_nblock and fusb_block_size parameters, I
don't see any 'uO' when running the script.
In that case it's not the overruns, it'
Hi,
I am working on a VHF receiver using USRP/TVRX board. I need to receive a band
of 6 MHz from 156,025 MHz to 162,025 MHz.
I have compiled the latest version of GNU Radio (3.0.3), the old tv_rx script
are not compatible with the latest version of GNU Radio.
Do you know which script in Python I
Hsin-mu Tsai wrote:
> This is my limits.conf
>
> @usrp - rtprio 90
> @usrp - memlock 2048000
> @usrp - nice-19
>
> The user running the code is in usrp group.
>
> I'm running kernel 2.6.20-0119.rt8 from
> http://people
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hsin-mu Tsai wrote:
> On 7/25/07, Dan Halperin <[EMAIL PROTECTED]> wrote:
> I removed all the USB devices from the computer when I was doing the
> experiment. The benchmark script said 32 MB/s throughput can be
> achieved.
Sorry I reread your original
Have you tried running the latest low-latency kernel, with
modified settings in /etc/security/limits.conf?
Frank
This is my limits.conf
@usrp - rtprio 90
@usrp - memlock 2048000
@usrp - nice-19
The user running the c
On 7/25/07, Dan Halperin <[EMAIL PROTECTED]> wrote:
IIRC 802.15.4 is a 2 MHz (if you think of it as QPSK at twice the symbol
rate, that is) modulation scheme so this is going to be testing the
limits of USB if you sample at 2 4, or 8MHz complex (8, 16, 32 MBps
respectively). Have you benchmark
Hsin-mu Tsai wrote:
> I don't think my problem is related to the CPU. Here are my reasons:
>
> 1. I tried overclock my CPU from 2.6 GHz to 3.2 GHz in order to see if
> an increase of CPU performance can decrease the packet loss ratio.
> However, no significant change was observed. And I'm using I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hsin-mu Tsai wrote:
> 2. I guess I wasn't very clear in my first e-mail. I tried two
> different kinds of setting with file_sink and file_source:
>
> a) TX_blocks -> usrp_source -> usrp board 1 ---physical_channel--->
> usrp board 2 -> usrp_sink -> f
Thanks for the quick response. I really appreciate it.
uO means "USRP Overrun". That is, the USRP is sending data to the
computer faster than the computer can handle it. This probably means
that you are sending at too high a data rate -- the online decoder is
taking too much CPU. When you start
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> One interesting thing I noticed is that when I increased fusb_nblock
> and fusb_block_size, it shows a lot of buffer overrun ('uO'). When I'm
> using the default setting, these uO disappear. Why is this happening?
> However, the packet loss ratio are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The data is packed binary data. Each complex samples is stored as 8
bytes, 4 bytes I as a float and 4 bytes Q. You need to use a binary
program to read these files. See read_complex_binary.m for MATLAB code
and the exact same syscalls translate directo
Hello,
I e-mailed this list last week and have had some issues trying to get the
file usrp_rx_cfile.py to give me a proper output. The readme file says that
the output is "single precision complex float values". Honestly I do not
know how to convert this data to a proper text that I can analyz
Hi,
I'm running some packet transmission experiments using GNU Radio and
USRP. However, the packet loss ratio is very high (20%) even when I
directly connect two USRP boards, which are the transmitter and the
receiver, with a direct antenna cable (I've also tried using regular
antennas, but the p
On Wed, Jul 25, 2007 at 12:14:42PM +0200, Vincenzo Pellegrini wrote:
> my fromfile (file, dtype) numpy function does not accept d type =
> complex32...
>
>
> data = fromfile("/root/Desktop/rx.dat", dtype="complex32")
> TypeError: data type not understood
>
>
>
>
> but what is the usual g
The way I read that ruling, it requires that the USRP,
among other products be approved by the FCC. Matt or
anybody care to comment?
John Bratteli
John Gilmore schrieb:
>
http://news.com.com/Feds+snub+open+source+for+smart+radios/2100-1041_3-6195102.html
>
> This story had more details and inve
my fromfile (file, dtype) numpy function does not accept d type =
complex32...
data = fromfile("/root/Desktop/rx.dat", dtype="complex32")
TypeError: data type not understood
but what is the usual good way in gnuradio to fill a vector with data
from files?
is there an alternative to this
19 matches
Mail list logo
