The recorded file was only about 80MB for 10 seconds of recording, and FFT
playback was static. Without using the low pass filter, I was seeing a
bunch of 'D' (I think) markers, and my playback was choppy.
Nick Foster wrote:
What was the size of the recorded file on the RAM disk? Are you seeing
What was the size of the recorded file on the RAM disk? Are you seeing "O"
indications (for overflow)?
--n
On Mon, Dec 2, 2013 at 1:59 PM, Paul B. Huter wrote:
> Nick:
>
> I tried downsampling the 25MHz to 10, but still was not recording the
> whole time I ran (about 10 seconds, with only a cou
Nick:
I tried downsampling the 25MHz to 10, but still was not recording the whole
time I ran (about 10 seconds, with only a couple seconds of playback). That
was when I tried using a RAM disk, albeit at 50 downsampled to 30. I am
using the following for my disk:
mount -o size=1G -t tmpfs none /mn
Paul,
30MHz is a big chunk of data to be streaming to anything. A 4GB ramdisk
will be full in 30 seconds at this rate. Do you really not know *a
priori* where
in the whole 0-30MHz spectrum your signal will be?
I notice now in your first post that you're streaming 25Msps with a
low-pass filter to
I finally got around to trying writing to RAM, and the result is worse - my
replay FFT is static.
I am trying to record a chunk of spectrum (in this case the shortwave
chunk, 0-30MHz) and then go back and look at small pieces to find my
specific data. If someone can provide insight into how to do
I agree with Nick: that VOLK stuff is all expected behavior. If you're
trying to write to a file at high rates you should look in to using a
ramdisk/tmpfs. You'll be limited by how much RAM you have rather than
IO speed.
However, based on your other threads I wonder if you've taken Tom's
recent su
Your file sink only records a few seconds of data because your hard drive
can't keep up, not because of any problem with Volk. The Volk machine being
used does not indicate which particular architecture is used for each
kernel -- that isn't printed at runtime.
--n
On Nov 24, 2013 9:58 PM, "Paul B.
When running with a USRP source at 25M and a low pass filter down to 10MHz,
I get something saying "Using Volk machine: sse4_a_64", and my file sink
only records a couple seconds of data. I ran the volk_profile script, but
still get the same result. The script returned something other than
"sse4_a_
On Fri, Apr 26, 2013 at 4:35 PM, Barry Jackson wrote:
>
> Brian
> I think you misunderstood.
> We were using boost-1.52 which is blacklisted for gnuradio, hence the need
> for us to update to 1.53.
>
> I don't think these current test failure problems are boost related and
> AFAIK there is no reas
On 25/04/13 15:26, Brian Stamper wrote:
On Thu, Apr 25, 2013 at 4:43 AM, Barry Jackson wrote:
On 24/04/13 22:09, Johnathan Corgan wrote:
[snip]
This was reported last January in the course of a thread related to
failures with Boost 1.5.2:
[snip]
Hi folks - all my tests in that thread were
On Thu, Apr 25, 2013 at 4:43 AM, Barry Jackson wrote:
> On 24/04/13 22:09, Johnathan Corgan wrote:
[snip]
>>
>> This was reported last January in the course of a thread related to
>> failures with Boost 1.5.2:
[snip]
> Hi folks - all my tests in that thread were on x86_64 and we have since
> moved
On 24/04/13 22:09, Johnathan Corgan wrote:
On Wed, Apr 24, 2013 at 1:56 PM, Johnathan Corgan
wrote:
On Wed, Apr 24, 2013 at 10:50 AM, Brian Stamper wrote:
114: AssertionError: 39 != 31
114: AssertionError: 0.8 != 0.0 within 4 places
Now that's just being unreasonable :)
Actually, I recall
On Wed, Apr 24, 2013 at 1:56 PM, Johnathan Corgan
wrote:
> On Wed, Apr 24, 2013 at 10:50 AM, Brian Stamper wrote:
>
>> 114: AssertionError: 39 != 31
>> 114: AssertionError: 0.8 != 0.0 within 4 places
>
> Now that's just being unreasonable :)
>
> Actually, I recall seeing these same failures somet
On Wed, Apr 24, 2013 at 10:50 AM, Brian Stamper wrote:
> 114: AssertionError: 39 != 31
> 114: AssertionError: 0.8 != 0.0 within 4 places
Now that's just being unreasonable :)
Actually, I recall seeing these same failures sometime in the past,
and am looking around to see if I can find the refer
On Wed, Apr 24, 2013 at 1:07 PM, Johnathan Corgan
wrote:
>
> On Wed, Apr 24, 2013 at 9:46 AM, Stamper, Brian wrote:
>
>>
>> generic 99% tests passed, 2 tests failed out of 192
>
>
> I'm curious which QA tests failed for you when everything was set to
> 'generic'.
>
All tests had
On Wed, Apr 24, 2013 at 9:46 AM, Stamper, Brian wrote:
> generic 99% tests passed, 2 tests failed out of 192
>
I'm curious which QA tests failed for you when everything was set to
'generic'.
--
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganl
Hi Tom,
>From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom
>Rondeau
>Sent: Tuesday, April 23, 2013 10:15 PM
>On Tue, Apr 23, 2013 at 10:37 AM, Stamper, Brian wrote:
...
>> Previously I posted that I was getting the following make test failures. I'm
>> building GNU Radi
On Wed, Apr 24, 2013 at 2:48 AM, Johannes Demel wrote:
> I just want to point out that you could use gdb python for debugging.
>
> just run gdb python and then "run path/file.py". At least it works for
> me and doesn't need this import os stuff and looking up PIDs.
>
This works in most cases (an
Hi all,
I just want to point out that you could use gdb python for debugging.
just run gdb python and then "run path/file.py". At least it works for
me and doesn't need this import os stuff and looking up PIDs.
Johannes
Am 24.04.2013 04:14, schrieb Tom Rondeau:
On Tue, Apr 23, 2013 at 10:37 A
On Tue, Apr 23, 2013 at 10:37 AM, Stamper, Brian wrote:
> Hi all,
>
> Previously I posted that I was getting the following make test failures. I'm
> building GNU Radio in Fuduntu (a fork of Fedora) on a 32-bit Intel Atom N270
> based netbook (an Asus Eee 1000).
>
>>
>> 22/192 Test #22: qa_fft_fi
Hi all,
Previously I posted that I was getting the following make test failures. I'm
building GNU Radio in Fuduntu (a fork of Fedora) on a 32-bit Intel Atom N270
based netbook (an Asus Eee 1000).
>
> 22/192 Test #22: qa_fft_filter ***Failed 1.05 sec
> 85/192 Test #85: tes
21 matches
Mail list logo
