On Wed, Aug 02, 2006 at 10:40:38AM +0800, hanwen wrote:
> Interesting about realtime scheduling?
> What does it do and what can we benifit from it?
$ man sched_setscheduler
And look for the part about SCHED_FIFO.
When enabled it ensures that our process runs before most others.
Note that it's
On Tue, 2006-08-01 at 17:35 -0700, Eric Blossom wrote:
> On Tue, Aug 01, 2006 at 08:26:58PM -0400, Lee Patton wrote:
> > I see a single USRP underrun (uU) about four out of five times that my
> > application starts. My transmit work() routine couldn't be simpler: a
> > for-loop that moves data fro
Interesting about realtime scheduling?
What does it do and what can we benifit from it?
2006/8/2, Eric Blossom <[EMAIL PROTECTED]>:
On Tue, Aug 01, 2006 at 08:26:58PM -0400, Lee Patton wrote:> I see a single USRP underrun (uU) about four out of five times that my
> application starts. My transmit
Michael Dickens wrote:
> Hopefully now -really- fixed the compile issue.
Yep, really fixed on my machine. Thanks.
-Johnathan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Johnathan Corgan wrote:
> Everything else appears to compile, I get an ecc.o in the .libs directory.
Sorry, wrong directory--but libecc/.libs also gets everything in it as
well, encoder.o, decoder.o, code_metrics.o, and code_io.o.
-Johnathan
___
Disc
Michael Dickens wrote:
> Hopefully fixed compile errors.
With the new CVS code, I get:
g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -pthread
-I/usr/local/include/gnuradio -I/usr/local/include/gnuradio
-I/usr/local/include/gnuradio/swig -I.. -g -O2 -Wall
-Woverloaded-virtual -pthread -MT code_convolut
On Tue, Aug 01, 2006 at 08:26:58PM -0400, Lee Patton wrote:
> I see a single USRP underrun (uU) about four out of five times that my
> application starts. My transmit work() routine couldn't be simpler: a
> for-loop that moves data from a local buffer to the output buffer. So,
> I don't think I c
I see a single USRP underrun (uU) about four out of five times that my
application starts. My transmit work() routine couldn't be simpler: a
for-loop that moves data from a local buffer to the output buffer. So,
I don't think I can scale it back or anything.
Is there anything I can do to avoid t
On Tue, Aug 01, 2006 at 11:41:10AM -0700, Johnathan Corgan wrote:
> I'm getting a compile time error with gr-error-correcting-codes in libecc:
>
> code_convolutional_trellis.cc:293: error: no match for 'operator=' in
> 't_fb_generators_soai =
> ((code_convolutional_trellis*)this)->code_convolution
Hi,I am looking at the tx_buffer module. From my understanding, that module does the interlacing of the data to be transmitted (2 I channels and 2 Q channels). Is that correct? Also, next to the bus_reset input declaration there is a comment saying "Used here for the 257 hack to fix the FX2 bug". W
Johnathan Corgan wrote:
> Michael Dickens wrote:
>
>> (3) I've just checked in the latest version (decoder stuff still doesn't
>> work, but the rest is starting to take over the duties of the decoder
>> slowly but surely). I was on vacation from July 21 to 29, but I did
>> Could you try updating
Michael Dickens wrote:
> (2) The error you get is when copying a std::vector into another via
> "=", instead of copying individual elements.
I'm not familiar enough with the standard library to know whether this
is "proper"; it looks like it would be very convenient.
> What OS are you trying t
That's the "quickie" overview. 'k-1', BTW, is the memory order
required to realize the actual encoder; the "constraint length" is
effectively how long a single ("impulse") input bit can possibly
effect output bits. Codes are (sometimes) referred to as (n,m,k),
where 'n' is the number of i
(1) gr-ecc is a work in progress and really doesn't do anything yet.
The encoder seems to work (passes the basic QA tests), and is hooked
into a gr_block (soon to be called
"ecc_streams_encode_convolutional"), but none of the decoder stuff
has been verified to function yet. I'm working on
I'm getting a compile time error with gr-error-correcting-codes in libecc:
code_convolutional_trellis.cc:293: error: no match for 'operator=' in
't_fb_generators_soai =
((code_convolutional_trellis*)this)->code_convolutional_trellis::d_code_feedback'
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../i
hanwen wrote:
Hi,
Recently, I'm trying to do CDMA commnication at 1.28Mchip/s with USRP
and I've met a problem.
The sample rate of DAC on USRP is 128M, so samples avialabe for each
chip is 128M / 1.28M = 100.
The interpolation rate of USRP must be [4, 512] and multiple of 4. So
the only cho
hanwen wrote:
Hi,
Recently, I'm trying to do CDMA commnication at 1.28Mchip/s with USRP
and I've met a problem.
The sample rate of DAC on USRP is 128M, so samples avialabe for each
chip is 128M / 1.28M = 100.
The interpolation rate of USRP must be [4, 512] and multiple of 4. So
the only cho
That is straightforward.
In High SNR, the lazy algorithm is O(1)!!!
In low SNR, both the lazy algorithm and the traditional algorithm are
both O(2^k) where k+1 is the constraint length.
It is not a simple relationship as the SNR falls off but in many of the
cases we would consider, the l
Michael Dickens wrote:
I'm working on programming the "Lazy" Viterbi (convolutional, maximum
likelihood) decoder right now. See
< http://citeseer.ist.psu.edu/599573.html >
< http://vanu.com/resources/publications/
2002fast_maximum_likelihood_decoder.pdf >
Mike,
Can't help you with the alg
How about just dropping a note to the authors?
Their email addresses are at the bottom of column one of the report.
Done that. Waiting. Thought I'd ping the list too. I certainly am
surprised by the breadth / width / depth of experience available on
the list. ;-) MLD
__
On Tue, Aug 01, 2006 at 11:06:11AM -0400, Michael Dickens wrote:
> I'm working on programming the "Lazy" Viterbi (convolutional, maximum
> likelihood) decoder right now. See
> < http://citeseer.ist.psu.edu/599573.html >
> <
> http://vanu.com/resources/publications/2002fast_maximum_likelihood_de
I'm working on programming the "Lazy" Viterbi (convolutional, maximum
likelihood) decoder right now. See
< http://citeseer.ist.psu.edu/599573.html >
< http://vanu.com/resources/publications/
2002fast_maximum_likelihood_decoder.pdf >
I have a few issues which I'm trying to resolve, and maybe
It's interesting that both 'make's (I assume -j2) are trying to
compile 'gnuradio_swig_python' at the same time (or that's the way I
read the output), and both are failing (both trying to [over]write
the same file at the same time?)
Probably reissuing the 'make' allows one thread to do this
Sorry for the confusion, usually I separate the make and make install
and only use sudo on the make install, but sometimes, especially if
you work on multiple machines at the same time, you get a little bit
lazy ;)
So, I checked out a new version and did the make seperate from the
install, and it
On a related note: Separate out the commands and do "sudo" only for
the actual install. Makes it easier to clean up since you don't need
to "umask 0" or "chmod -R a+rw ." or whatever in order to have
appropriate permissions; you can do the "make" again and again from
whatever account you
Ok, I have some more results from tests I just made:
- On the same machine (macbook) I installed an Ubuntu as dualboot
system. There, the USRP works just fine, i.e., I can run the different
tests and benchmark scripts without any problems.
- Next, I reboot into mac os x, without unplugging or powe
It looks to me like the build worked (perhaps you could try building
without installing), and that the install failed. I think this is due
to there being a number of files that need to be installed in a
directory that doesn't yet exist, and make parallelizing the install
commands. Then two inv
I am currently rebuilding everything on a mac mini and post the
failing logs here...
Thomas
On 8/1/06, Greg Troxel <[EMAIL PROTECTED]> wrote:
"Thomas Schmid" <[EMAIL PROTECTED]> writes:
> A quick note of caution: I found out that sometimes compiling with -j2
> gets errors, then restarting the
"Thomas Schmid" <[EMAIL PROTECTED]> writes:
> A quick note of caution: I found out that sometimes compiling with -j2
> gets errors, then restarting the process without -j2 compiles without
> any errors. I assume that it is some dependency problems because one
> of the processes did not finish yet
29 matches
Mail list logo
