Bob McGwier wrote:
There is insufficient dynamic range in any GPS signal on any ordinary
mortals GPS antenna to use more than 8 bits.
Not so if the signal is being jammed...
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu
There is insufficient dynamic range in any GPS signal on any ordinary
mortals GPS antenna to use more than 8 bits.
Bob
Chris Stankevitz wrote:
Dan Halperin wrote:
USRP's cfile utility cannot write my data without overruns, so I use
my own app which I have attached to this email in case anyon
Dan Halperin wrote:
USRP's cfile utility cannot write my data without overruns, so I use
my own app which I have attached to this email in case anyone is
interested. I will try Juha's recorder to see if it performs better.
FWIW (maybe you've fixed the problem already), I would think that if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- - -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- - - -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 4, 2008, at 10:59 PM, Chris Stankevitz wrote:
USRP's cfile utility cannot write my data wi
Robert Fitzsimons wrote:
Just some comments on the code:
int NumBytes = rx->read(
(char*)Buffer,
n*sizeof(short),
&Overrun);
Your code doesn't do anyting if the read returns less then
n*sizeof(short) bytes. Is that possible within the gnuradio code?
pStream->write((ch
> USRP's cfile utility cannot write my data without overruns, so I use
> my own app which I have attached to this email in case anyone is
> interested.
Just some comments on the code:
>int NumBytes = rx->read(
> (char*)Buffer,
> n*sizeof(short),
> &Overrun);
Your code doesn't
On Wed, Jun 04, 2008 at 09:33:33PM -0700, Chris Stankevitz wrote:
>
> Thanks again. Is it ever possible for all of these things to happen:
>
> 1. write data to disk using cfile
> 2. hard drive cannot keep up for whatever reason (new sector, etc) and data
> is lost
> 3. A USRP "overrun" condition
Chris-
> > I've seen cases before where the drive does handle the throughput as
> > advertised, but
> > on an average basis. Under sustained, continuous write circumstances, when
> > the drive
> > reaches a new sector, multiple of sectors, or some other internal space
> > boundary,
> > extra t
Jeff Brower wrote:
I've seen cases before where the drive does handle the throughput as
advertised, but
on an average basis. Under sustained, continuous write circumstances, when the
drive
reaches a new sector, multiple of sectors, or some other internal space
boundary,
extra time is taken fo
Chris-
> > 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 MBb
I have sampled continuously for many hours without problems. I had a
setup with USRP syncronized to an external clock. I have then measured
a constant frequency sinusoid derived out of the same clock and
verified that the ratio of consecutive complex samples was always
constant (up to a certain err
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
17 matches
Mail list logo
