Task - Accelerometer and low power Code implementation

[GoogleCodeExporter]

Description of the task:

Implement the code for the accelerometer, the desired functionality is:
1.Periodically come out of a low power mode and sample the input pins. 
Three A/D converters will need to be implemented for this 
2.If any value indicates movement, go out of the low power mode and enable 
a flag that says when we're ready to start receiving GPS signals
3.Go into low power for a long period of time after the GPS signals are 
received and then start step 1 again.

Please update the issue with any progress you've made.

Jake, I've assigned this to you, but I can lend support as needed.

Original issue reported on code.google.com by c.shi...@gmail.com on 27 Oct 2009 at 4:52

[GoogleCodeExporter]

I'll take this, since I've already looked at it a little bit.

Original comment by c.shi...@gmail.com on 27 Oct 2009 at 5:19

[GoogleCodeExporter]

So here's what I know so far about how this works. Consider this part 1 of 
several 
comments on how to operate it.

The ADC12_A component is a A/D converter that shuts down when it's not sampling 
or 
converting a signal, perfect for our application.

It starts sampling an analog signal when the SHI signal has gone high. When 
initializing 
the A/D converter, you choose how this signal operates, you can choose from 3 
different timers, or you can use the ADC12SC signal manually to start the 
process.

Original comment by c.shi...@gmail.com on 30 Oct 2009 at 1:55

[GoogleCodeExporter]

A/D conversion operates in two steps. First, the converter is activated and it 
samples 
the audio signal. In the setup, you tell it how long it should sample each time 
it does.

Then the converter takes 13 ADC12CLK cycles and convertes the sample into a 12 
bit 
digital value. Again, during setup, you assign which clock, or timer, acts as 
the clock 
source.

When this process is finished, the interrupt is triggered. You can then read 
the digital 
values from the ADC12MEMx registers. In our case we can replace x with 0 
through 2. 
If one of those registers has changed alot from its default value, you know 
it's moving.

If one of them is moving, we can set a global flag saying that it's time to be 
awake and 
take gps samples, and then reset this flag when we are done.

Original comment by c.shi...@gmail.com on 30 Oct 2009 at 2:26

• Changed state: Started

[GoogleCodeExporter]

The plan for this is to implement this in parts.

Part 1:  Implement desired low power mode, including being able to exit it and 
reenter
Part 2:  incorporate accelerometer and use to wake it up

Original comment by c.shi...@gmail.com on 5 Nov 2009 at 6:29

[GoogleCodeExporter]

I am able to put the processor in LPM3, but ACLK, the clock that is active in 
the 
power mode, doesn't seem to be working yet. I am able to use other clock 
sources to 
wake up the processor periodically in other power modes.

Original comment by c.shi...@gmail.com on 9 Nov 2009 at 5:08

[GoogleCodeExporter]

Part 1 complete! Our oscillator crystal for the old processsor (MSP430F169) iss 
an 
external component that you have to hook up to XIN and XOUT pins, once that was 
in, 
the rest began to work shortly thereafter.

In LPM3, we can now do an A/D conversion (aka look at the accelerometer) as 
often or 
as little as we want and it stays in LPM3 while we do it. All we have to do is 
wake it up 
in the ISR for the ADC when we see movement.

Original comment by c.shi...@gmail.com on 10 Nov 2009 at 5:29

[GoogleCodeExporter]

I asked Sandia a couple of design questions related to doing A/D conversion in 
low 
power mode:

I had a couple of questions about how to approach using the low power modes, 
mainly I 
want to know what you consider to be "good design."

+How often should I have an interrupt check our inputs from the accelerometer? 
I'm 
thinking right now to do it every couple of minutes.
+When polling the accelerometer, do you take multiple samples to confirm that 
you're 
detecting movement? We were concerned about how noise might spike and cause a 
false trigger

Original comment by c.shi...@gmail.com on 11 Nov 2009 at 6:54

[GoogleCodeExporter]

Patrick answered in the following email, these issues should be considered as 
we are 
refining the code:

If you do the math you will find that even if you take a sample once a second - 
or a few 
times a second - your average power will still be very, very low.  Maybe tens 
of uA.

Another path would be to have the Accelerometer feed into a comparator that can 
give 
you a digital interrupt.  That way you can be completely asynchronous.  Any 
time you 
are forced to poll instead of interrupt you are giving something up.  If you 
wanted to be 
real fancy you could have 3 comparators set to 3 different levels would could 
trigger 3 
maskable interrupts.  See where I am going?  This would improve your response 
time, 
power usage, and processor availability for other interrupts.

When you do poll the accelerometer it is always wise to take a handful of 
samples, 
throw out the highest and the lowest, then average the rest.  If you want to 
get real 
tricky you can have heuristics that analyze the spread of the data to detect 
noise, you 
can integrate over time - whatever you want to do.  Technically it is "ok" to 
just take one 
sample -- if -- everything goes well.  If on the other hand you steer off into 
the weeds 
people are going to ask why you were only taking one sample.  ;-)

Original comment by c.shi...@gmail.com on 11 Nov 2009 at 6:55

[GoogleCodeExporter]

Part 1 is now implemented on the new processor (MSP430F5529).

Original comment by c.shi...@gmail.com on 12 Nov 2009 at 9:44

[GoogleCodeExporter]

Part 2 is implemented on the new processor. The timing in the code still needs 
to be
refined, but we can now wake up the processor when we detect movement. 

Original comment by c.shi...@gmail.com on 24 Nov 2009 at 3:07

[GoogleCodeExporter]

Original comment by c.shi...@gmail.com on 22 Dec 2009 at 5:37

• Changed state: Debug