> On Sat, Jul 24, 2010 at 6:12 PM, Anil Sharma wrote:
> Hi everyone ,
> I am just a newbie to gnuradio, please someone guide me. Can some one
please explain me what is realtime scheduling in
> gnuradio used for. And how we can use the realtime scheduling in gnuradio
, Moreover what is needed to m
>
> How can I tell GNU Radio to only use the eth2 interface for all
> communications with the USRP2, instead of eth0?
>
For python scripts you change the defaults by modifying:
gnuradio/gr-usrp2/src/usrp2.i
For the four blocks change std::string ifc="eth0" to std::string ifc="eth2"
and recompile
Juha,
> Do I understand correctly that this is similar to gr-gpio? I thought
> VRT allowed separate streams, why are the bits still in the LSB of I
> and Q? Does this also work with UHD?
I'm using pre-UHD/VRT code at the moment - my understanding is the metadata
VRT adds applies to a group of sam
Hi,
I'm trying to use the LSB streaming functionality but cant seem to get the
following code to work:
---
self.u=usrp2.source_16sc(options.interface)
self.u.set_center_freq(options.freq)
self.u.set_decim(options.decim)
print "Current GPIO State: " + str(self.u.read_gpio())
print "GPIO
Charles,
If your looking to move applications to the long term solution you probably
want : UHD with UDP
"Raw ethernet version" is what was used on previous FPGA images/firmware -
the USRP2 had to be connected directly to the PC and didnt have an IP etc.
"UDP" implements more layers of a network
It seems to display correctly on that link for me.
Checking it on my copy here it looks like the script is playing the
dangerous game of mixing tabs + spaces so the actual indentation you see on
your text editor depends on how it treats tabs. Whether it works or not then
depends on how python choo
Hi,
I think the get fences error is an OpenGL/Video Driver thing, I've seen it
when using a laptop with an Intel GMA video chip and just ignored it as
things still seemed to work.
Can you see a noise floor?
Which RF Port are you using on the XCVR2450? (i.e tx/rx or rx only?)
Cheers,
Tim
On Mon
Hi,
1)
I don't think gr-howto-write-a-block is part of the normal build environment
-- there's a separate one within this directory.
Try running:
./bootstrap
./configure
make
make check
sudo make install
from inside this directory (i.e gnuradio/gr-howto-write-a-block)
You might run into some we
Hi,
That output looks like its from the end of the ./configure script
You should be ok to carry on though as those components are skipped on my
installation as well:
gcell/gr-gcell are only necessary for cell processor work (typically on a
ps3)
gr-audio* are just for using different audio "driv
Hi,
I just tried running the example on a RFX2400 and it seems to work for me.
I think the error is caused when the usrp2object.gain_range() command
returns a step size of 0.0 (like on the BasicRX).
As a quick fix you could try replacing:
myform['gain'] = \
form.quantize
Hi,
I've been having a look at usrp2/host/lib/copiers.cc and the schematics to
try and work out if the units mean anything.
As far as I can tell the LTC2284 ADC is set up to use the +-1V input range
and output 14bits as a twos complement.
>From the datasheet/the maths I think the ADC is thus giv
cket?
>
> (And yes the timestamps are treated as uint32's.)
>
> Regards,
> /Ulrika
>
> --
> *From:* Tim Pearce [mailto:timothy.pea...@gmail.com]
> *Sent:* Thursday, February 18, 2010 9:35 PM
> *To:* Ulrika Uppman
> *Cc:* Discuss-gnurad
Ulrika,
I agree with how you think the timestamps are generated -- it seems to work
for me that way anyway!
I did it with a custom source block that added the counter*decimation rate
after the first sample, the trap I fell into there is that (particuarly at
lower decimation rates) rx_*_handler()
Hi,
I've finally had a bit of time to have a go with the VRT branch - I noticed
with the rx_timed_samples example it's now possible to start rx_streaming at
a specific time so I've quickly merged my custom usrp2 timestamp source
block (gr-usrp2 - providing a second stream of timestamps - I dont th
I haven't seen any code but there's an academic paper on this at :
http://www.usenix.org/events/woot07/tech/full_papers/spill/spill.pdf from
UCL in the UK. (Linked on gnuradio website)
A bit more information searching on the UCL site:
http://www.cs.ucl.ac.uk/staff/a.bittau/dom.pdf
--
Tim
On Wed
Immediately above "Traceback (most recent call last):" in the command window
is there any error?
The most common I get are:
t...@tim-laptop:~$ usrp2_fft.py
*eth0: SIOCGIFINDEX: No such device*
or
t...@tim-laptop:~$ usrp2_fft.py -e eth1
*socket(PF_PACKET, SOCK_RAW, htons(0xBEEF)): Operation not
1)
Run:
sudo chmod u+s /usr/local/bin/usrp2_socket_opener
2) As root edit /etc/security/limits.conf and add the line:
@usrp - rtprio 50
If your not already in the USRP group add your user with:
useradd -G usrp username
(This will create the group if it doesn't already exist)
--
Tim
On Sa
Hi,
I've been using the latest git version of gnuradio and trying to get Doug's
start_rx_streaming_at patch (now merged with the git version) to work. I
don't think there's any support via gr-usrp2 so I've modified
usrp2_source_base (temporarily) to call start_rx_streaming_at(0,0,0) (i've
tried us
I've just tried it and it doesnt work here using a 4gb card. I guess the
CPLD has been configured (or doesnt support SDHC) to only use SD
addressing..
On the other remarks, an email did goto this mailing list - thats how I
found out about the problem.
The link to the binary image files is in the
command changing branches seemed to sort everything out for me:
(from jblum/)
git checkout origin/usrp2_vrt
git checkout -b usrp2_vrt
I need to go and read up on the new non-cvs style systems :)
Cheers,
Tim
git clone http://gnuradio.org/git/jblum.git usrp2_vrt
On Mon, Dec 28, 2009 at 10:21 PM,
should see a broadcast packet going out and a packet coming
> back from the usrp2. The 2 byte transport type should read BEFO in hex.
>
> -Josh
>
>
> Tim Pearce wrote:
>
>> Looking through the header files this looks really useful, thanks for the
>> hard work guy
Looking through the header files this looks really useful, thanks for the
hard work guys :)
I'm having some problems getting it to work though, I've downloaded the
firmware/fpga builds from the link and with these running python/find_usrps
isnt able to find the usrp2 - its fine with the latest non
Cheers for that Christoph, beats my post processing with timestamps fix!
For what its worth I've gotten away with fairly cheap TCXO's (£15 generic
farnell ones) and a GPSDO circuit like the one at
http://ve2zaz.net/GPS_Std/GPS_Std.htm (it did need some manual tuning at
first as the oscillators wer
Hi,
I havent used these boards so I havent looked at the RF components etc to
answer your second question but my understanding of the burn-db-eeprom
program is that it just updates the frequencies, gain etc that the
daughterboard reports it can handle when the appropriate function is called.
Ther
Brook,
I'd guess its an error in one of the modifications to Makefile.am -- have
you put a \ at the end of the preceding line? i.e it should be something
like:
grinclude_HEADERS =\
howto_square_ff.h\
howto_square2_ff.h \
howto_code.h
lib_LTLIBRARIES = libgnuradio-howto.la
Hi Ben,
I was having problems with what appears to be blocks of data being saved out
of sync (tended to happen at decimation rates lower than 100) but I haven't
had a chance to get to the root of this issue, my current line of thinking
is that when blocks have a side effect the ordering isnt guare
Doug,
Thanks I'll try this. Googling a bit more I think fwrite has to be thread
safe, I'll double check my setup again and have another think if this
doesn't help.
Cheers,
Tim
On Thu, Nov 19, 2009 at 7:17 PM, Doug Geiger wrote:
> Tim Pearce wrote:
>
>> Hi Guys,
>
Oops sorry guys this is in reply to the wrong timestamp question -- I had
meant to reply to this thread:
http://lists.gnu.org/archive/html/discuss-gnuradio/2009-11/msg00069.html
Cheers,
Tim
On Thu, Nov 19, 2009 at 7:02 PM, Tim Pearce wrote:
> Hi Guys,
>
> After experimenting a bit mor
Hi Guys,
After experimenting a bit more I think the issue was my test setup.
Previously I was using python to setup a USRP Source (with timestamps) and
save both the samples (64 bit) and timestamps (32bit) to a file sink to
process by importing with numpy and checking timestamps later.
At 25MHz
Devin,
The metadata is already passed to GNURadio by the USRP2 firmware. Its the
gnuradio usrp2 source block that doesn't do anything with this information
(metadata has the timestamp for the first sample of each frame)
You can modify the code to provide a second stream, or interleave the data
wi
6 PM, Doug Geiger wrote:
> Tim Pearce wrote:
>
>> Hi All,
>>
>> I've modified the source to generate timesamples (as a seperate stream)
>> from the USRP2 source blocks and noticed an issue - if the PC is struggling
>> some frames have a timesample dated befo
Hi All,
I've modified the source to generate timesamples (as a seperate stream) from
the USRP2 source blocks and noticed an issue - if the PC is struggling some
frames have a timesample dated before the timesample of a frame processed
before it.
It's possible I've done something wrong modifying t
I've had quite a few problems which I think are caused by poor phase noise
on the XCVR2450 -- it's an all in one chip with a local oscillator on board
etc - the 2400 appears quite a bit better (20dB if I remember correctly!)
The schematics are in an odd place for this board - I could only find a l
Ah! The 10MHz was coming out the back of the siggen so would have been
locked to the same reference.
Thanks for your help Doug/Matt -- next time I'll stop and think through my
test setup!
Cheers,
Tim
On Tue, Oct 20, 2009 at 6:16 PM, Matt Ettus wrote:
> Tim Pear
>
>
> There is no frequency which can be received by both the BasicRX and the
> DBSRX. What frequency are you putting in? What frequency are you telling
> the USRP2s to tune to?
>
> Matt
>
>
Hi,
Sorry I probably confused things by mentioning the BasicRX
DBSRX is the only receiver we have 2 of a
Hi,
I've been trying to get two USRP2's with their clocks both synced to a 10MHz
reference (for now the same reference from the back of some test equipment)
- to do this I'm using the following code:
in_pipe1=usrp2.source_32fc('eth0')
in_pipe2=usrp2.source_32fc('eth2')
in
In terms of integrating more tightly with the USRP/GnuRadio
You could (maybe) just use the SPI pins and one of the digital IO lines as
the enable (the ATMega8 running as a slave)
That way theres functions to communicate with the chip already built in you
just need to define the various commands e
This seems very similar I had with the same chipset/dell laptop (probably
the one you saw) -- does ethtool -a eth0 say Rx: On ?
If not "ethtool -A eth0 rx on" (as root) fixed the problem for us
I cant remember if this solution was replied to on the mailing list..
Cheers,
Tim
On Mon, Sep 21, 20
38 matches
Mail list logo
