On Tue, 6 Dec 2005 16:04:07 -0800, Eric Blossom [EMAIL PROTECTED] wrote
To: [EMAIL PROTECTED], discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gmsk error / log files and octave
On Tue, Dec 06, 2005 at 06:16:32PM -0500, [EMAIL PROTECTED] wrote:
> Probably the easiest thing is to mod
> What should the data going in and out of the gr.clock_recovery_mm_ff look
> like?
Your data looks good except for the DC offset.
> I see that in gmsk2.py you remove DC offset, should the signal be varying
> +/-Vpeak equally?
Yes, the data should be symmetric about zero.
> Any requirements th
On Tue, Dec 06, 2005 at 06:23:24PM -0500, [EMAIL PROTECTED] wrote:
> Not sure if this will work but here is a screen shot of my demodulated data
> that I am trying to recover the digital signal from and inputing into
> gr.clock_recovery_mm_ff.
>
> Mike
There's probably a frequency error between t
On Tue, Dec 06, 2005 at 06:16:32PM -0500, [EMAIL PROTECTED] wrote:
> On Tue, 6 Dec 2005 14:24:43 -0800, Eric Blossom [EMAIL PROTECTED] wrote:
> > Quick answer:
> >
> > use the defaults.
> >
> > Involved answer:
> >
> > It's a Mueller and Müller (M&M) discrete-time error-tracking
> synchronize
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, 7 December 2005 9:47 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gmsk error
On Tue, 6 Dec 2005 14:24:43 -0800, Eric Blossom [EMAIL PROTECTED] wrote
Try http://www.superbookdeals.com/
Search by ISBN, they can ship it in a couple days. "Only" $89.
On Tue, 6 Dec 2005, [EMAIL PROTECTED] wrote:
> On Tue, 6 Dec 2005 14:24:43 -0800, Eric Blossom [EMAIL PROTECTED] wrote:
> > Quick answer:
> >
> > use the defaults.
> >
> > Involved answer:
>
On Tue, 6 Dec 2005 14:24:43 -0800, Eric Blossom [EMAIL PROTECTED] wrote:
> Quick answer:
>
> use the defaults.
>
> Involved answer:
>
> It's a Mueller and Müller (M&M) discrete-time error-tracking
synchronizer.
>
> See "Digital Communication Receivers: Synchronization, Channel
> Estimation a
On Tue, Dec 06, 2005 at 03:57:26PM -0500, [EMAIL PROTECTED] wrote:
> What are the parameters/arguments (omega, gain_omega, me, gain_mu...) used
> in gr_clock_recovery_mm_xx and how do you determine what they should be?
Quick answer:
use the defaults.
Involved answer:
It's a Mueller and MÃ
What are the parameters/arguments (omega, gain_omega, me, gain_mu...) used
in gr_clock_recovery_mm_xx and how do you determine what they should be?
I have been trying to find in the Python literature what the follow syntac
represent.
"""
...
@param omega: nominal relative freq (de
CTED], discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gmsk error
This is the whole thing. You don't need a lookup table.
/**
*Calculate the CRC-16 CCITT of buffer that is length
bytes long.
*The crc parameter allow the calculation on the CRC on
multiple buffers.
*
This is the whole thing. You don't need a lookup table.
/**
*Calculate the CRC-16 CCITT of buffer that is length
bytes long.
*The crc parameter allow the calculation on the CRC on
multiple buffers.
*
*@param buffer Pointer to data buffer.
*@param length number of bytes in d
On Thu, 1 Dec 2005 16:02:59 -0700 (MST), mgray wrote:
> The following is a link to CRC16 for the PIC controller with similiar
> memory limitations:
> http://www.kd7lmo.net/picobeacon_code.html
I looked at the code and all I could find was the function sysCRC16 in
lines 1899-1916 of the PicoBeacon
On Fri, Dec 02, 2005 at 12:22:22PM -0700, Robitaille, Michael wrote:
>
> I am in the process of implementing the whitener and will most likely do
> CRC16. For integrity check, I originally implemented of you a parity bit
> (yes it's limited to detecting on one bit error but my data load was small
Gwier [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 01, 2005 8:30 PM
To: [EMAIL PROTECTED]
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gmsk error
We put the whitener and CRC32 in for a reason:
1) clock recovery and other things work better if you do not have long
runs of 1
We put the whitener and CRC32 in for a reason:
1) clock recovery and other things work better if you do not have long
runs of 1's or 0's.
2) How will you be able to check end to end integrity without CRC or
other style checking?
The answer is, you can live without either but you pay the ob
Urgg, should have been under this subject
Original Message:
-
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Thu, 1 Dec 2005 13:53:15 -0500
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] (no subject)
On Wed, 30 Nov 2005 15:00:34 -0800, Eric Blossom wrote:
> The calling
On Wed, Nov 30, 2005 at 04:16:50PM -0500, [EMAIL PROTECTED] wrote:
> I was trying to use the ggmsk-test.py, from the gnuradio-example directory,
> and got the following error message:
>
> $ ./ggmsk-test.py
> sps:8
> symbol_rate:270833.33
> sample_rate:216.7
> p_size
17 matches
Mail list logo
