32.768 KHz crystal and battery for Teensy 3.0 RTC questions

Status
Not open for further replies.

tdg8934

Active member
I am interested in learning more about the RTC for the Teensy 3.0. I understand I would need a coin cell battery, case and 32.768 KHz crystal.

When might these be available through PJRC or Adafruit maybe?

Is the Teensy 3.0 RTC tutorial with Teensyarduino what I should be looking at for this?
 
I am interested in learning more about the RTC for the Teensy 3.0. I understand I would need a coin cell battery, case and 32.768 KHz crystal.

When might these be available through PJRC or Adafruit maybe?

Is the Teensy 3.0 RTC tutorial with Teensyarduino what I should be looking at for this?

I just did an order with dipmicro, primarily for connectors and protoboards. While I was there, I ordered the following:

I have 2 teensy's and I figured the coin battery holder could be used on other things.
:cool:
 
The crystal I used is Digikey 300-8303-ND. More info and photos are on Kickstarter Update #19

http://www.kickstarter.com/projects...rm-cortex-m4-usable-in-arduino-a/posts/331757

teensy3_rtc_2.jpg
 
I bought a bunch of CR2032 batteries, cases, crystals and even some DS1307 chips for like $10 including shipping from Dipmicro. Thanks!
 
I wonder, does it make sense to buy a more precise component, such as Digikey P/N 300-8763-ND with its +/- 5PPM accuracy at only $0.70 in single unit quantities? Wouldn't you get accuracies approaching those of a DS3231, especially if you can compensate for temperature drift using the internal temperature sensor?
 
The problem is that the internal sensor is ... internal, and will be subject to fluctuation depending on the core use. I bought a pack of 30 no-name crystals for 3$ and they work fine. The thing is I don't need super-duper precision for the projects I'm working on. I'm getting less than 1s per day drift in my office, but I really only need 12h precision (I use it to compute sun an moon rise and set times), so I'm sure it's not an option for everybody.
 
Agreed. The internal sensor is usually not very accurate when it comes to measuring ambient conditions. But it can still be very useful for certain tasks, such as calibrating the ADC.

I did an experiment with a MCP3241 16-bit ADC to see how temperature affected it and the MUX that was supplying it. That in turn convinced me of the need to run calibration runs for the ADC and to use the output to smooth out / eliminate these offset and gain errors. This is what the analog read does inside the Teensy, IIRC, as part of every setup.

I now have a DHT22 also designed into the Teensy shield I am developing. I am then planning something altogether more ambitious, i.e. measure drift as a function of temperature and compensate for that. A 3.3V-based GPS sensor provides the signal to compare to... the result could be a super-accurate thermally-compensated clock like the DS3231 at a bargain price. But even 5PPM is a pretty amazing spec - if I understand it correctly, per year you'd be losing / gaining 157 seconds, worst case. That's 13 seconds per month... good enough for most work, even if all you do is compensate for drift at the beginning.
 
The Teensy3Clock.get() function always returns 0 when there is no external crystal. Is there a better way to detect whether an external crystal is present than the following?

Code:
bool hasRTC() {
  uint32_t prescaler(RTC_TPR);
  delayMicroseconds(33);
  return prescaler != RTC_TPR;
}

All the status registers I found return identical values with and without the external crystal. I tried these:

Code:
!!(RTC_CR & RTC_CR_CLKO) is always 0
!!(RTC_CR & RTC_CR_OSCE) is always 1
!!(RTC_SR & RTC_SR_TCE) is always 1
!!(RTC_SR & RTC_SR_TIF) is always 0
!!(RTC_SR & RTC_SR_TCE) is always 1
 
Last edited:
The bit to use is RTC_SR_TIF, but you can't easily do this because the startup code checks that bit and tries to initialize the RTC. By the time your program is running, it's too late to discover what that bit was before the startup code ran.

There is a startup_early_hook() function you could implement to run your own code very early in the startup. Pretty much nothing is initialized at that point. The most viable solution would be to grab the value of RTC_SR and put it into a static variable. But this code runs before variables are initialized, so you'll have to use an attribute to put that variable into the .noinit section to prevent the later startup code from overwriting it. Then you could check that variable's RTC_SR_TIF bit once your program is running. Or if you don't need to do much, you could perhaps do everything you need in that extremely early startup code.... but that's quite difficult because so much stuff ordinary programming depends upon hasn't been initialized yet.
 
Paul, thank you. Makes sense. For user code, a little forensics on the prescaler, even though it isn't elegant, is good enough. It won't require messing with .noinit, et.al.

The Arduino Time library (Time.h) has a timeStatus() function. If you ever run out of interesting things to do, (Ha!) maybe the startup code could stash some information to be reported by either by timeStatus() or a new timeSouce() function. (?)
 
300-8763-ND and 300-8303-ND are the same!, see the datasheet!

Not sure I agree. While both product pages point to the same data sheet, one of the crystals is rated +/-5PPM, while the other is rated +/- 20PPM re: accuracy. The data sheet simply doesn't list all the grades that Citizen manufacturers.
 
If you ever run out of interesting things to do, (Ha!) maybe the startup code could stash some information to be reported by either by timeStatus() or a new timeSouce() function. (?)

Actually, I had intended to make some pretty major improvements in the Time library. Michael Margolis (the original author) was lukewarm to big changes, and as I worked on it, pretty much every example needed to be updated just to work with Arduino 1.0. We settled for just bringing all the code up to compatibility with Arduino 1.0.X and 1.5.X and testing on all the newer boards.

Realistically, it's unlikely I'll work on the Time library again anytime soon. I have a lot of awesome stuff planned for next year, which is going to keep me really busy!
 
http://www.swfltek.com/arduino/time32.html#avr-libc

"Time32 is a work alike for the C90 time.h functions, with lots of extras. See below for the list of functions.

This 'library' is actually a supplement* to avr-libc, and is technically more difficult to install than just dragging it to your Arduino Libraries directory.
*This package is currently a candidate for inclusion in the avr-libc distribution. Between now and the time that happens, if that happens, some things may change."



I'm using his old TimeLord library to run my LED strips on "astro time".
Set your lat/long and they come on and off at *true* local sunset/sunrise.

I'd love to use his improved code. But I'm not a programmer.
Want to add proper long 30-90 minute light fades to *properly* replicate civil/nautical/astronomical twilight.

You could have your weed plants think they are in Jamaica and be very happy.
If they are happy, you are happy. That is all.
 
I have some 32 kHz crystals from scrap pagers and I am thinking of trying one. Are the crystal pins shared with anything?
 
Unlikely to work unless they have the right load capacitance. Not worth it IMO. The specified ones are so cheap, easy to obtain, and the holes to solder them into are so tiny, why bother risking the destruction of a $20 device? Don't see the reward vs. the risk. On the other hand, retrofitting a external TXCO might be interesting, but only if you really care about keeping accurate time in variable temperature conditions and are willing to spend the $10 to get there.
 
I don't really need a RTC so I'll take your advice and just skip it for now. I just got the headers soldered on so its not like I'm running out of new things to try. On my next order I'll likely add a proper crystal.
 
Status
Not open for further replies.
Back
Top