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 do
Hi,
Concerning GSM GMSK demodulation, due to the ISI, I initially thought many
folks were using the Viterbi algorithm on the waveform to demodulate it
properly. After doing some lit review, I am finding that this is not the
case and that when most folks talk about Viterbi concerning GSM GMSK
To the USRP experts out there:
I reclocked my USRP from 64 to 65.536 MHz and have recently discovered
that the I Q samples are no longer orthogonal, rather they seem to be
only 70 degrees or so apart. I would guess this is due to some hard
coded values in the CIC or HB filters? Is there a
Gregory W Heckler wrote:
To the USRP experts out there:
I reclocked my USRP from 64 to 65.536 MHz and have recently discovered
that the I Q samples are no longer orthogonal, rather they seem to
be only 70 degrees or so apart. I would guess this is due to some hard
coded values in the CIC or
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?
On Thu, Jun 05, 2008 at 11:04:53AM -0700, Matt Ettus wrote:
Gregory W Heckler wrote:
To the USRP experts out there:
I reclocked my USRP from 64 to 65.536 MHz and have recently discovered
that the I Q samples are no longer orthogonal, rather they seem to be
only 70 degrees or so apart. I
On Thu, Jun 5, 2008 at 7:45 AM, isaacgerg [EMAIL PROTECTED] wrote:
Hi,
Concerning GSM GMSK demodulation, due to the ISI, I initially thought many
folks were using the Viterbi algorithm on the waveform to demodulate it
properly. After doing some lit review, I am finding that this is not the
I've added a link to
http://gnuradio.org/trac/wiki/Enhanced_GMSK_Demodulator from
http://gnuradio.org/trac/wiki/OurUsers
Summary:
[...] offers an enhanced GMSK demodulator that I believe to be
superior to the GNURadio standard gmsk demodulator. It should be a
drop-in replacement for the existing
On Thu, Jun 05, 2008 at 03:25:29PM -0400, Steven Clark wrote:
I've added a link to
http://gnuradio.org/trac/wiki/Enhanced_GMSK_Demodulator from
http://gnuradio.org/trac/wiki/OurUsers
Summary:
[...] offers an enhanced GMSK demodulator that I believe to be
superior to the GNURadio standard
Gregory W Heckler wrote:
I reclocked my USRP from 64 to 65.536 MHz
Greg,
Just out of curiosity, why did you do this? Related to GPS?
Chris
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
Steven,
If you were to generate a patch that had your demodulator show up as a
new demod called, say, gsm_demod_alt2 that hooked it into the existing
framework with this new name, we could add it to the tree and it would
get more testing without having to overwrite the known implemenation
Steven,
That is totally rockin'; thanks!
Isaac
Steven Clark-2 wrote:
On Thu, Jun 5, 2008 at 7:45 AM, isaacgerg [EMAIL PROTECTED] wrote:
Hi,
Concerning GSM GMSK demodulation, due to the ISI, I initially thought
many
folks were using the Viterbi algorithm on the waveform to demodulate
I noticed that many gnuradio files (gmsk.py for example) contain an
unholy mix of spaces and tabs for indentation. Is there any easy way
to standardize our indentation? Many text editors can make it so
hitting tab creates 4 spaces instead of the tab character.
(I like 4 spaces per indent, what
On Thu, Jun 5, 2008 at 3:25 PM, Steven Clark [EMAIL PROTECTED] wrote:
[snip]
It should be a
drop-in replacement for the existing demodulator in designs, except
that the transmitted data needs to be differentially encoded (you will
NOT, however, need a differential decoder on the receive side).
On Thu, Jun 05, 2008 at 05:03:39PM -0400, Steven Clark wrote:
I noticed that many gnuradio files (gmsk.py for example) contain an
unholy mix of spaces and tabs for indentation. Is there any easy way
to standardize our indentation? Many text editors can make it so
hitting tab creates 4 spaces
On Thu, Jun 5, 2008 at 5:28 PM, Gregory Maxwell [EMAIL PROTECTED] wrote:
On Thu, Jun 5, 2008 at 3:25 PM, Steven Clark [EMAIL PROTECTED] wrote:
[snip]
It should be a
drop-in replacement for the existing demodulator in designs, except
that the transmitted data needs to be differentially encoded
Steven Clark wrote:
I noticed that many gnuradio files (gmsk.py for example) contain an
unholy mix of spaces and tabs for indentation. Is there any easy way
to standardize our indentation? Many text editors can make it so
hitting tab creates 4 spaces instead of the tab character.
You can fix
-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
Some incantation like
indent -br -brs -cdw -ce -cs -hnl -i2 -lp -nbad -nbbo -nprs -psl -saf -sai
-saw -nss -npcs
works well for most C-ish code. Substitute -i4 if you don't use graduated
lenses in your glasses.
Frank
On Thu, Jun 5, 2008 at 6:00 PM, Josh Blum [EMAIL PROTECTED] wrote:
Steven
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
20 matches
Mail list logo
