Hi,

Thanks again for the helpful information:

--- In msp430@msp4..., Micah Stevens <micah@9...> wrote:
> 
> Hi,
> 
> More below: 
> 
> On Tuesday 23 August 2005 12:31 pm, finfets wrote:
> >  --- In msp430@msp4..., Micah Stevens <micah@9...> wrote:
> >  > >  > After lots of figuring out, I finally seem to have
gotten my
> >
> >  ADC10 to
> >
> >  > >  > work. I used another MSP430 to send a square wave to
my
receiving
> >  > >  > MSP430, and my receiving
MSP430 seemed to get data results
ok: ie:
> >  > >  >
> >  > >  > results: 0, 1023, 0, 3, 1023, 0, 1024, 0, 0, 1024,
1023,...
> >  >
> >  > This just seems that the square wave is very near your nyquist
> >
> >  frequency. What
> >
> >  > are you sampling at? What freq is the square wave?
> >
> >  I am sending my square wave at 43.0 kHz. I am sampling at 196 kHz, as
> >  that is my frequency of my TimerA (which is used to trigger the
ADC10). 
> >
> >  As an aside, I will be taking the basic upper division signals and
> >  systems course this fall, so I will definitely become more familiar
> >  with the nyquist stuff. I did learn about it in the intro signals and
> >  systems course, but I forgot it :D
> >
> 
> Essentially, the rule is, in order to sample a frequency of x, you
must sample 
> at x*2. From what you're saying, you're
well above the nyquist with
your 
> sampling rate, so that's not an issue like I
thought. That's > 4
samples per 
> cycle. However this confuses me, in a perfect work
with everything
synced up, 
> this would lead to this sort of data:
> 
> 0,0,0,0, 1024, 1024, 1024, 1024, 0, 0, 0, 0, 1024, 1024, 1024, 1024,
0, 0, 0, 
> 0, etc.. 
> 
> Of course that will never happen, and since your sampling rate isn't
a direct 
> multiple of the signal, that will hose things too,
as well as it
seems (I may 
> be wrong) that you aren't syncing the signal
with the sample clock,
so there 
> is likely some jitter going on. 
> 
> How about injecting a nice 48Khz (sample/4) signal and seeing how
that works 
> out for you? 
> 

So, I got it to give as close to 48 as possible, trying both 46.5 kHz
and 50.67 kHz. Both give much better results than before, as I had
alot fewer clumps of 2 consecutive, same values. I tried sending at a
worse frequency just to test, so at 40.0 kHz, and indeed I got alot of
 clumps of 2 same values. 

As for the reason why I only have 0,1024,0,1024 instead of clumps of 4
same values, I think its because of my setting for ADC10SHT_X. I am
using ADC10SHT_3 == 64 x ADC10CLK, and I am using SMCLK for ADC10CLK,
where SMCLK==MCLK==8.0 MHz external crystal.

I calculated to use ADC10SHT_3 because:

Using ADC10SR=1, max sample rate is 50 kbps. CLK period = 1/8Mhz = 125
 ns.
Using a worst-case impedance Rs = 2.0 KOhm,

tsample > (Rs + 2k)*7.625*20pF + 2.5us = 3.11 us.

Number of divisions of ADC10CLK needed = tsample_min / CLK_Period 3.11 us / 125
ns = 24.88

I divide ADC10CLK by 1, however, and instead use the Sample Timer
Division (ADC10SHT_X) to do my division.

So since 24.88 > 16 divisions, I must use 64 divisions. Then my total
ADC10CLK cycles needed = 64+13+1 = 78, giving total time = 78*125ns 9.75
us, which is Freq2.6 KHz.

This frequency is the frequency I *should* be sampling at, but instead
I used 196 which is roughly double that. I tested sampling at 100 KHz,
but results were the same: 0,1024,0,1024 with the occasional clump of 2.


> Also, I would try toggling a spare GPIO pin at
every sample, to see how 
> regular the sample clock is.. you might find your clock is a little
screwey 
> depending on how you've set things up.
> 

Initially I had the GPIO debug toggle in my ADC10_ISR vector, which
gave an ok signal with not too much jitter. My DTC n  transfers were
giving a ADC10_ISR at a constant freq=4.6 kHz.

So I am using TimerA to auto trigger the ADC10, but I still doing this
in my TimerA ISR:

// Timer A0 interrupt service routine
#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A (void)
{
  ADC10CTL0 = ADC10SHT_3 | REFON | ADC10ON | ADC10IE | ADC10SR;
  ADC10CTL0 |= ENC;                         // ADC10 enable set
  
  P2OUT ^= DOUT; // debug
}

The TimerA ISR is happening at the expected 195 kHz, but there is
quite alot of jitter on the edges. In fact, the frequency varies from
195 to 200 kHz!


Thanks alot for you help and time,
Regards,
Rich

Ok I figured out my problem of why it was 0,1024,0,1024 instead of
0,0,0,0,1024,1024,1024,1024,0,0,etc

I measured my TX rate wrong, my TX rate was actually 70 KHz. And I was
sampling at 195 KHz. Well, this seems to imply I should be getting
something like a very skewed: 0,0,1024,1024, etc, but at least this is
a step in the right direction.

Thanks,
Rich

--- In msp430@msp4..., "finfets" <finfets@y...> wrote:
> Hi,
> 
> Thanks again for the helpful information:
> 
> --- In msp430@msp4..., Micah Stevens <micah@9...> wrote:
> > 
> > Hi,
> > 
> > More below: 
> > 
> > On Tuesday 23 August 2005 12:31 pm, finfets wrote:
> > >  --- In msp430@msp4..., Micah Stevens <micah@9...> wrote:
> > >  > >  > After lots of figuring out, I finally seem to
have gotten my
> > >
> > >  ADC10 to
> > >
> > >  > >  > work. I used another MSP430 to send a square
wave to my
> receiving
> > >  > >  > MSP430, and my receiving MSP430 seemed to get
data results
> ok: ie:
> > >  > >  >
> > >  > >  > results: 0, 1023, 0, 3, 1023, 0, 1024, 0, 0,
1024, 1023,...
> > >  >
> > >  > This just seems that the square wave is very near your
nyquist
> > >
> > >  frequency. What
> > >
> > >  > are you sampling at? What freq is the square wave?
> > >
> > >  I am sending my square wave at 43.0 kHz. I am sampling at 196
kHz, as
> > >  that is my frequency of my TimerA
(which is used to trigger the
> ADC10). 
> > >
> > >  As an aside, I will be taking the basic upper division signals
and
> > >  systems course this fall, so I will definitely become more
familiar
> > >  with the nyquist stuff. I did learn about it in the intro
signals and
> > >  systems course, but I forgot it :D
> > >
> > 
> > Essentially, the rule is, in order to sample a frequency of x, you
> must sample 
> > at x*2. From what you're saying, you're well above the
nyquist with
> your 
> > sampling rate, so that's not an issue like I thought. That's
> 4
> samples per 
> > cycle. However this confuses me, in a perfect work with everything
> synced up, 
> > this would lead to this sort of data:
> > 
> > 0,0,0,0, 1024, 1024, 1024, 1024, 0, 0, 0, 0, 1024, 1024, 1024, 1024,
> 0, 0, 0, 
> > 0, etc.. 
> > 
> > Of course that will never happen, and since your sampling rate
isn't
> a direct 
> > multiple of the signal, that will hose things too, as well as it
> seems (I may 
> > be wrong) that you aren't syncing the signal with the sample
clock,
> so there 
> > is likely some jitter going on. 
> > 
> > How about injecting a nice 48Khz (sample/4) signal and seeing how
> that works 
> > out for you? 
> > 
> 
> So, I got it to give as close to 48 as possible, trying both 46.5 kHz
> and 50.67 kHz. Both give much better results than before, as I had
> alot fewer clumps of 2 consecutive, same values. I tried sending at a
> worse frequency just to test, so at 40.0 kHz, and indeed I got alot of
>  clumps of 2 same values. 
> 
> As for the reason why I only have 0,1024,0,1024 instead of clumps of 4
> same values, I think its because of my setting for ADC10SHT_X. I am
> using ADC10SHT_3 == 64 x ADC10CLK, and I am using SMCLK for ADC10CLK,
> where SMCLK==MCLK==8.0 MHz external crystal.
> 
> I calculated to use ADC10SHT_3 because:
> 
> Using ADC10SR=1, max sample rate is 50 kbps. CLK period = 1/8Mhz = 125
>  ns.
> Using a worst-case impedance Rs = 2.0 KOhm,
> 
> tsample > (Rs + 2k)*7.625*20pF + 2.5us = 3.11 us.
> 
> Number of divisions of ADC10CLK needed = tsample_min / CLK_Period > 3.11
us / 125 ns = 24.88
> 
> I divide ADC10CLK by 1, however, and instead use the Sample Timer
> Division (ADC10SHT_X) to do my division.
> 
> So since 24.88 > 16 divisions, I must use 64 divisions. Then my total
> ADC10CLK cycles needed = 64+13+1 = 78, giving total time = 78*125ns
> 9.75 us, which is Freq2.6 KHz.
> 
> This frequency is the frequency I *should* be sampling at, but instead
> I used 196 which is roughly double that. I tested sampling at 100 KHz,
> but results were the same: 0,1024,0,1024 with the occasional clump of 2.
> 
> 
> > Also, I would try toggling a spare GPIO pin at every sample, to
see how 
> > regular the sample clock is.. you might find
your clock is a little
> screwey 
> > depending on how you've set things up.
> > 
> 
> Initially I had the GPIO debug toggle in my ADC10_ISR vector, which
> gave an ok signal with not too much jitter. My DTC n  transfers were
> giving a ADC10_ISR at a constant freq=4.6 kHz.
> 
> So I am using TimerA to auto trigger the ADC10, but I still doing this
> in my TimerA ISR:
> 
> // Timer A0 interrupt service routine
> #pragma vector=TIMERA0_VECTOR
> __interrupt void Timer_A (void)
> {
>   ADC10CTL0 = ADC10SHT_3 | REFON | ADC10ON | ADC10IE | ADC10SR;
>   ADC10CTL0 |= ENC;                         // ADC10 enable set
>   
>   P2OUT ^= DOUT; // debug
> }
> 
> The TimerA ISR is happening at the expected 195 kHz, but there is
> quite alot of jitter on the edges. In fact, the frequency varies from
> 195 to 200 kHz!
> 
> 
> Thanks alot for you help and time,
> Regards,
> Rich