On Mon, Jun 02, 2008 at 10:29:22PM -0400, KC Huang wrote:
> Hi:
> Lately, I have tried to modify tunnel.py to switch freq in the
> middle of packet transmitting. But I have two problems.
> 1. When I tried to switch freq in the same daughterboard, should I
> have to stop the original transmission
Heckler, Gregory W. (GSFC-596.0) wrote:
Have you ruled out the USRP overflowing? I have had that problem bite me
too. It causes all of the tracking
channels to dump in my receiver, but I could see how it could also cause
a jump in the frequency estimate
(delay in time domain == shift in frequenc
Chris Stankevitz wrote:
Thanks for your recommendation. I can indeed pipe the output of my
"data gathering app" to the input of my GPS processor and see if the
problem goes away.
BTW one problem with this approach is that I can only confirm that there
is lost data by post processing. The sy
Jeff Brower wrote:
Is there a way for you to temporarily take file-write out of the equation?
I.e. can
your code look at the bitstream and know if it remains continuous / intact?
The "every minute or two" thing makes me suspicious that some HDD related thing
is
going on. 16 MBbyte/sec is a
Eric Blossom wrote:
If you're running Linux and writing to an ext3 filesystem, try
remounting it as an ext2 filesystem. I've seen problems in the past
when the ext3 filesytem posts its journal, however they showed up as
overruns -- the filesystem wasn't keeping up.
Eric,
I used to have this
Chris-
> I'm using the USRP/DBSRX to record data for GPS. GPS tracking demands a
> continuous stream of data -- dropped bits make tracking impossible.
> 4Msps of complex data supplies 16 MB/s -- within USB2 bandwidth and my 4
> disk RAID0 bandwidth.
>
> I record the data using my own c++ version
On Tue, Jun 03, 2008 at 01:41:03PM -0700, Chris Stankevitz wrote:
> Hi,
>
> I'm using the USRP/DBSRX to record data for GPS. GPS tracking demands a
> continuous stream of data -- dropped bits make tracking impossible.
> 4Msps of complex data supplies 16 MB/s -- within USB2 bandwidth and my 4
> dis
Hi,
I'm using the USRP/DBSRX to record data for GPS. GPS tracking demands a
continuous stream of data -- dropped bits make tracking impossible.
4Msps of complex data supplies 16 MB/s -- within USB2 bandwidth and my 4
disk RAID0 bandwidth.
I record the data using my own c++ version of cfile. I
By the way, in the "Simple Gnuradio User Manual v1.0" [1] p.110 appears sub
function (11) gr.mpsk_receiver_cc.freq(). I haven't been able to find this
function, does it really exist?
I would like to have your opinion, is this document compliant to GNU Radio
code?
Regards,
Irene
[1] -
http://ww
Tom Rondeau wrote:
>
> Do "make install" from gnuradio-core/src/lib
>
> Tom
>
You got it! Thanks,
Irene
--
View this message in context:
http://www.nabble.com/Trace-mpsk_receiver_cc%28%29-tp17605464p17623536.html
Sent from the GnuRadio mailing list archive at Nabble.com.
_
irene159 wrote:
George Nychis wrote:
You need to do a make, and make install ... otherwise you don't add your
new modifications to the library and install the library for the python
code to access.
Hi,
Thanks for giving me a hand.
I tried "make" and "make install" in the
/usr/s
Dear all,
I am experimenting with OFDM between two USRPs. Unfortunately, I am not yet
able to master the gnuradio framework so I have made my own implementation.
The results are given in the link below.
http://www.s3.kth.se/~perz/usrp/OFDM_results.pdf
How does this compare with the gnuradio OF
George Nychis wrote:
>
> You need to do a make, and make install ... otherwise you don't add your
> new modifications to the library and install the library for the python
> code to access.
>
Hi,
Thanks for giving me a hand.
I tried "make" and "make install" in the
/usr/src/gnuradio/gnur
13 matches
Mail list logo
