No 32.768khz xtal?

[Daniel]

I just purchased the kit and was looking at the parts list (schematic
will come later, i'm at work right now) and found it a little
disconcerting that there isn't a 32.768khz crystal (i.e. 1/2 second
for a 16-bit register). This frequency of crystal makes it
tremendously easier to build something that keeps time. Also, since
they are relatively slow, they can be pretty accurate, even for a
cheap one. Otherwise, you are at the mercy of either the internal
oscillator of the uC, or in this case, the 16mhz external oscillator.
It is not uncommon for these things to float a LOT (even though they
say this one is 50ppm, according to Mouser) due to temperature and
other environmental things, which would make a time system based on it
float also.

Unless I am missing something, which I very well could be.

--Daniel

[Ben Combee]

The problem is that the 3V battery doesn't last very long, so the
amount of clock slippage over the life of the battery will be pretty
small. Bre said his use case was to have this running for an evening
out, but not necessarily to run for days on end.

[Adam Mayer]

I've built clocks on top of these crystals before, and they're usually
pretty close to dead-on. (The one at resistor loses a minute a day,
but that's a firmware error I've been too lazy to address. :P) It's
not perfect, but unless you're navigating by sextant, it shouldn't be
too big a deal.

-a

[Daniel]

Let me preface that I have not used the Atmel architecture before,
only PIC.

Anyway, my hope was that with a 32.768khz crystal, you could sleep in
between crystal pulses and extended battery life by a whole bunch.
32768/16M = 0.205%, so say 1% to include processing. You only need to
pulse the LEDs every once in a while, and POV in the human eye will
take over.

Anywho, I smell some major hackery about to take place. =)

[Ben Combee]

It would actually be a pretty interesting hack -- use the internal
8MHz oscillator with the crystal pads used for input from a 32.768khZ
crystal. You'd have to change the fuses configuration when burning
the bootloader on the board, but that's not too bad.

[bre pettis]

Feel free to just take out the 16mhz crystal and get another one in there. The crystal I'm wearing on my wrist right now isn't even smd, I just bent the leads over to make it work.

If you do end up messing with the fuses, make sure to modify and share the boards.txt file.

Cool!

Bre

[Enkel Bici]

You could put a real time clock there, instead of the crystal and put
the atmega on sleep. Potentially this could be battery saver, since
the atmega draws very little power in sleep mode and with the internal
oscillator it can work at a much smaller voltage.
The price shouldn't be much higher, i've found this RTC
http://it.farnell.com/nxp/pcf8563t-f4-112/rtc-calendar-smd-8563-soic8/dp/8906130
(note: I'm not working for them, I'm just a customer) it communicates
through i2c and draws very little current so it can stay always on.
Keep up the good work!

On Dec 9, 1:56 am, bre pettis <brepet...@gmail.com> wrote:
> Feel free to just take out the 16mhz crystal and get another one in there.
> The crystal I'm wearing on my wrist right now isn't even smd, I just bent
> the leads over to make it work.
>
> If you do end up messing with the fuses, make sure to modify and share the
> boards.txt file.
>
> Cool!
>
> Bre
>

[Daniel]

Octopart'd: http://octopart.com/info/Philips/PCF8563T%2FF4%2C112
Avnet has them for USD$0.82.

On Dec 9, 10:34 am, Enkel Bici <enkelb...@gmail.com> wrote:
> You could put a real time clock there, instead of the crystal and put
> the atmega on sleep. Potentially this could be battery saver, since
> the atmega draws very little power in sleep mode and with the internal
> oscillator it can work at a much smaller voltage.

> The price shouldn't be much higher, i've found this RTChttp://it.farnell.com/nxp/pcf8563t-f4-112/rtc-calendar-smd-8563-soic8...

[bre pettis]

This looks cool, but I'm not an expert on setting up schematics for
this sort of thing.

If anyone wants to point me in the right direction with where the pins
on this thing go, I'll slap it into the main schematic and play with
it.

Here's a rather confusing thread about integrating it with Arduino if
that helps.

I'll include the datasheet too if anyone wants to try a crack at it.
Feel free to just write it on a napkin.

Bre


http://brepettis.com
http://makerbot.com

[Matt Joyce]

This is completely off topic, but are there any varying widths in the acryllic used in the watch dxf?   Thicknesses ftw.

On Dec 10, 2009 7:52 PM, "bre pettis" <brep...@gmail.com> wrote:

This looks cool, but I'm not an expert on setting up schematics for
this sort of thing.

If anyone wants to point me in the right direction with where the pins
on this thing go, I'll slap it into the main schematic and play with
it.

Here's a rather confusing thread about integrating it with Arduino if
that helps.

I'll include the datasheet too if anyone wants to try a crack at it.
Feel free to just write it on a napkin.

Bre


http://brepettis.com
http://makerbot.com

On Wed, Dec 9, 2009 at 12:17 PM, Daniel <samur...@gmail.com> wrote: > > Octopart'd: http://oct...

[bre pettis]

The thick ones are the appx 1/4 inch material and the thin stuff is
the 1/16 material.

Bottom to top:

thin
thick
thin
thick
thin

Bre



http://brepettis.com
http://makerbot.com

[raphael]

There's several good reasons to use the 16mhz crystal and not a
32.768Khz Xtal or the internal oscillator:

The extra cycles make for a more open ended platform: you can do some
signal processing or some complex math without the whole thing feeling
sluggish.

Matrixing of the LEDs will look flickery if the clock is running too
slow. (I've tried this myself, it's not pretty.)

No crystal at all? The internal 8Mhz clock will drift something like 1
second per minute which is very bad for even a novelty watch. Breathe on
it on a cold day and it will change speed!

Most important though is simple no-adjustments compatibility with the
arduino software.

Counting pulses for keeping time is not that hard, it just takes a few
lines of code. As for power consumption, this is an LED watch. I's never
going to be efficient!

Now, maybe an 8mhz xtal would give the best of both worlds. Still, I
like to adhere to standards when I'm working on an open and distributed
project.

-r

--
Raphael Abrams
Artist Engineer

web: teuthis.com
drawings: doodlebird.wordpress.com
hack space: nycresistor.com
email: rap...@teuthis.com

[Andrew Plumb]

Use both. Take a look at the ATmega48PA/88PA/168PA/328PA datasheet,
Section 17.10: "Timer/Counter Prescaler":

"When AS2 is set, pins TOSC1 and TOSC2 are disconnected from Port C. A
crystal can then be connected between the TOSC1 and TOSC2 pins to
serve as an independent clock source for Timer/Counter2. The
Oscillator is optimized for use with a 32.768 kHz crystal.

See Section 17: "8-bit Timer/Counter2 with PWM and Asynchronous
Operation" for all the T/C2 specific details.

Andrew.

--

"The future is already here. It's just not very evenly distributed"
-- William Gibson

[raphael]

This is true, but the benefit is only in reduced power. Timekeeping is
not improved at all. Also, more stuff on the board...

[Daniel]

There's already a 16mhz crystal on the board. I proposed changing it
to a watch crystal, using the 8mhz internal OSC for processing, and
the watch crystal for keeping time via interrupts or whatever (32768 =
16-bits, hence when a 16-bit timer overflowed [which trips a flag/
interrupt] you count up 1 second).

I hope the benefits of such a setup are now obvious.

> >>> On Thu, Dec 10, 2009 at 6:26 PM, Matt Joyce <mdjo...@gmail.com> wrote:
> >>>> This is completely off topic, but are there any varying widths in the
> >>>> acryllic used in the watch dxf?   Thicknesses ftw.
>

> >>>> On Dec 10, 2009 7:52 PM, "bre pettis" <brepet...@gmail.com> wrote:
>
> >>>> This looks cool, but I'm not an expert on setting up schematics for
> >>>> this sort of thing.
>
> >>>> If anyone wants to point me in the right direction with where the pins
> >>>> on this thing go, I'll slap it into the main schematic and play with
> >>>> it.
>
> >>>> Here's a rather confusing thread about integrating it with Arduino if
> >>>> that helps.
>
> >>>> I'll include the datasheet too if anyone wants to try a crack at it.
> >>>> Feel free to just write it on a napkin.
>
> >>>> Bre
>
> >>>>http://brepettis.com
> >>>>http://makerbot.com
>

> >>>> On Wed, Dec 9, 2009 at 12:17 PM, Daniel <samurai1...@gmail.com>

> >>>> wrote: > >
> >>>> Octopart'd:http://oct...
>
> >> --
> >> Raphael Abrams
> >> Artist Engineer
>
> >> web: teuthis.com
> >> drawings: doodlebird.wordpress.com
> >> hack space: nycresistor.com

> >> email: raph...@teuthis.com

>
> > --
>
> > "The future is already here.  It's just not very evenly distributed" --
> > William Gibson
>
> --
> Raphael Abrams
> Artist Engineer
>
> web: teuthis.com
> drawings: doodlebird.wordpress.com
> hack space: nycresistor.com

> email: raph...@teuthis.com

[Enkel Bici]

I'm not very good with interrupts and such, but wouldn't that break
the arduino compatibility?
Other than space issues and marginally cost, why not use the RTC for
timekeeping and put the atmega to sleep (display leds off too) until a
button is pressed, so it can read the time and display it for a short
period and go to sleep again.
This way we could have an efficient and precise time reading without
sacrificing battery life.

Again the method Daniel described seems valid, I'm just not that good
with avr-c to really know what's going on.

[raphael]

I'm liking the idea of the 32khz xtal on a timer input. But if it does
break the standard timing functions or other interrupt based features of
the arduino, I don't think it would work. If someone can show me how to
do it without breaking anything, I'd love to see.

The main issue is compatibility with arduino. That's more important than
saving power or maintaining accuracy.

email: rap...@teuthis.com

[Andrew Plumb]

I dunno... Maintaining accuracy over at least a few days runtime is
kind of an important feature for me in a watch... ;-)

[Adam Mayer]

Just my few cents:

+/- 50ppm error => 4.3 seconds/day. That's about the same accuracy as
a good mechanical pocketwatch. Your battery would have to last months
for it to really be an issue.

I'm playing with a RTC chip for a clock design I'm working on at the
moment, but they're overkill unless you're planning on using a battery
backup. It would work out to about $2-$3 more per watch in quantity.

I agree that we'd be better off maintaining arduino compatibility and
reducing power consumption by using the chip's sleep modes and
interrupts properly. We could conceivably use the internal 8MHz clock
and an external crystal for the time interrupt (essentially, making
the board a lilypad), but I don't think we'd be saving ourselves much
more than a few lines of code.

I'm really enjoying the discussion that's coming out of this, by the
way. More brains == better watch!

-a

[raphael]

Really! How odd! What I mean is the difference between +-10ppm and
+-100ppm. It should definitely keep time to within 1 minute per week.

I think we can get crystal accuracy without breaking arduino
compatibility. It's just going to take some compromises.