[TriEmbed] Chip's trail activity logger Re: TriEmbed Digest, Vol 7, Issue 16

Pete Soper pete at soper.us
Fri Dec 20 10:16:50 CST 2013


On 12/15/2013 11:27 PM, Charles McClelland wrote:
> Pete,
>
> I think that your idea of a "start to finish" process for making a 
> printed circuit board would be fantastic.  My hope is to be ready to 
> start that process in the coming month or two.  I hope that in 
> addition to making the circuit smaller and more reliable, i can take 
> out some of the high costs of these "breakout" boards I have been 
> buying from Sparkfun.
>

OK.

> For all,
>
> I have taken the advice of the group to heart and moved my trail 
> traffic counter from a Piezo electric sensor to an accelerometer - v4.
>
> Here are some lessons learned in this process and a couple areas where 
> I am very open to suggestions:
> - Accelerometers are very cool.  I have created sketches to 
> characterize the orientation of my board and I have a number of ideas 
> for other uses - thank you all for the suggestion.
> - The inexpensive accelerometers like the MMA7361 
> <https://www.sparkfun.com/products/9652> suggested in a previous post 
> are all analog.  I got it working but saw a few disadvantages 
> primarily that the accelerometer and Arduino need to be close to one 
> another and it tied up three analog lines which needed to be read and 
> summed to create a "trigger" for a knock.
> - The accelerometers which have I2C communications are more expensive 
> but they added the interrupt functions I was looking for.  I went with 
> the MMA8452 <https://www.sparkfun.com/products/10955> which was the 
> lowest priced but also had a "tap" sensor
Until you need to worry about optimizing cost the difference between 
these two chips is surely noise but the convenience difference between 
the analog vs serial digital interface is immense.  Although I suspect 
it isn't relevant for your app, the 8452 offers 12 bit resolution vs the 
10 bits of the 7361 via your Atmega chip's ADCs, and it may be that 
without some signal conditioning of some sort you can't even get the 
full 10 bits.

> - I could not find an inexpensive i2C real time clock which could work 
> on 3.3V.  So, I am stuck with the expensive DS3234 
> <https://www.sparkfun.com/products/10160> on the SPI bus with the SD 
> Card.  Any suggestions here?  A 3.3V 1307 perhaps?
I've been exploring the ST M41T62 
<http://www.digikey.com/product-detail/en/M41T62LC6F/497-11275-1-ND/2673274> 
which, together with a temp sensor common in microcontroller chips, can 
be calibrated to 2ppm (5 seconds a month. It can generate a 32khz square 
wave to run my processor at very low speed when that's desirable, and 
comes in two packages: a QFN-16 for use with an outboard crystal, and an 
LCC8 that has a crystal inside it.

When I get caught up a bit I'm going to make small breakouts for both 
flavors of chip. Here's a rough draft 
<http://triembed.org/images/m41t62-lcc8-DRAFT.png> of one layout. I 
don't know yet if this clock is any good, but I'm going to find out. :-) 
By the way, the bypass cap in this draft is approximately the same size 
as the outboard crystal that plays with the QFN-16 version of the clock. 
(Both boards will be like this one: .4x.5 inches)

> - Getting sleep to work is still an issue, turns out the at the 
> Arduino will only come out of sleep when the interrupt goes LOW and 
> the accelerometer's interrupt goes to HIGH when it is triggered.  Ugh.
> - Unless I want to put an inverter chip on the board, I may be stuck 
> here.  Idle mode allows
An inverter would not be hard.

But it looks like the Sparkfun breakout for your clock brings the 
"INT/SQW" signal out. If you don't need the interrupt functionality you 
could program the SQW output to provide an alternate clock source for 
your CPU. If software can reliably switch the CPU between it's regular 
full speed clock and this much slower clock (1hz, 1, 4, or 8khz via 
software config) perhaps instead of "sleep" you could set your system to 
"comatose", where the interrupt handlers start off very slow but goose 
themselves with a clock source change as needed. The Atmega chip's 
current draw will be a direct function of the clock rate, so running at 
8khz vs some number of mhz would translate to a large savings.

> - My next "to do" is to enable batch writes to the SD Card reader and 
> see if I can put the card
Working out power saving strategies is surely a fun of this project. 
Securely (eeprom?) buffering data until you can pump out an entire SD 
card "sector" would seem to be one way of saving a lot of power, but I 
don't know.
> reader and clock to sleep between events to save power since my 
> Arduino has insomnia
I'm scheming to use the MSP430G2955 which has 56kb of flash memory that 
the chip can write to with itself. And the MSP430 was designed from day 
one to run at low power. Insanely low power. My goal is to get one app 
that currently uses almost eight square inches of PCB space and six AA 
batteries down to something the size of a thumb drive and running on a 
single small lithium coin cell.

>
> Thanks again for all your help.  I was able to finish my v3 board and 
> send off to a friend in Connecticut for field testing so I am making 
> progress.
It's very exciting to follow your project with the msgs to the list and 
sharing at meetings. Keep us posted!

Coincidentally I'm assembling breakout boards for the FXOS8700CQ 
accelerometer/magnetometer chip (also Freescale). With luck and a tail 
wind I may have one assembled to play with at tomorrow's meeting at 
Splatspace. (Meetup page for this meeting here 
<http://www.meetup.com/splatspace/events/155648802/>.) But I'm just 
learning what it's like to apply solder paste for a QFN-16 package. The 
first attempt was simply comical, as I couldn't keep the stencil stuck 
to the PCB and paste went through the holes and underneath the stencil, 
creating a very neat, roughly square blob over the top of the chip's pads.

-Pete

>
> Chip
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20131220/349fcb80/attachment.htm>


More information about the TriEmbed mailing list