On Fri, May 9, 2008 at 9:32 AM, Bastian Preindl <[EMAIL PROTECTED]> wrote:
> Unfortunately I'm not (yet) aware of the preprocessing (except for
> downmodulation to baseband) taking place within the (ham) radio - what
> _could_ happen to the signal? And what would be the optimal precondition for
>
Hi!
During the buildup phase of my gnuradio scripts (in __init__ of classes that
inherit from top_block or some classes that are initialized from a topblock
instance), I try to use gnuradio to convert some data. E.g. I use gr.fft to do
FFT on some constant data, or apply the function of some sp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 9, 2008, at 9:21 AM, Eric Blossom wrote:
You're probably running into a limit on the total number of shared
memory segments in the system (SHMMNI) or the max segs per process
(SHMMSEG). You can check the current values by:
$ cat /sys/proc/
Hi Jonathan,
many thanks for the detailed explanation!
Johnathan Corgan wrote:
That entirely depends on what has already happened to the signal prior
to it arriving at the sound card.
Unfortunately I'm not (yet) aware of the preprocessing (except for
downmodulation to baseband) taking pl
Bastian Preindl wrote:
> That are very good news for me! I'm aware about the relations between
> SNR and BER - I just wonder about the several ways to estimate the SNR
> in GnuRadio. That's exactly the information I lack of - do you have any
> documentation/examples/sources for how to accomplish t
On Fri, May 09, 2008 at 08:42:35AM -0700, Dan Halperin wrote:
> Hey,
>
> I know that the buffer allocation uses some memory mapping tricks to
> make it efficient; is there some shared resource that this process
> uses of which a computer should have a finite amount? I'm running a
> process w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey,
I know that the buffer allocation uses some memory mapping tricks to
make it efficient; is there some shared resource that this process
uses of which a computer should have a finite amount? I'm running a
process with, oh, say 500 buffers (
Dear Jonathan,
If you use the USRP, you will obtain a complex baseband representation
of your satellite signal. From this, you will need to implement a
demodulator for the particular signal involved. From the output of
As far as I know there already exist demodulators for (A)FSK, BPSK and
Are there any special considerations needed to use Linux signals
(in particular sigalarm) or forks from within a custom GnuRadio
C++ block?
Background information:
I'm written a block that consumes an HDLC/MPoFR bitstream and
extracts and forwards any contained IP packets. The block
generates
On Fri, May 9, 2008 at 2:22 AM, Bastian Preindl <[EMAIL PROTECTED]> wrote:
> As we're not the operator of the satellites, it is impossible to know
> the data we'll receive beforehand and make a comparison afterwards to
> calculate the bit error rate. So I have to count on information I can
> gain
Staffan,
I am not sure how to post to the list, but..
I came up with a noise temperature of 2291. 5 degrees K.
This would not make for a good front-end type receiver,
but could work as a back-end.
John
-- Original Message --
From: Staffan Josefsson <[EMAIL PROTECTED]>
Date: Thu
On 17.11.2006 19:45 Eric Blossom wrote:
> Re: PS3/Cell BE platform
>
>
> Sounds like fun.
>
> And yes, I think we could get the HDTV receiver running in real time ;)
>
> Eric
>
>
In light of the experience gained since then, is that still a reasonably
attainable goal?
The only thing stop
Hi,
I'm a project member of the global education network for satellite
operations (Genso, www.genso.org) and currently working on gaining
comparable link quality information when having an RX communication with
satellites.
As we'll probably support GnuRadio on a broad base (both using a USRP or
Hi Rafael, prego!
yes the link is correct but the video isn't online yet because i've had a
few sync problems with the transcoding.
I'll send you an email as soon as it's online..
best regards
vincenzo
2008/5/8 rafael2k <[EMAIL PROTECTED]>:
> Ciao Vincenzo,
> Grazie!
>
> Is the video link correc
14 matches
Mail list logo