DS3231 32khz output instead of crystal for Teensy 3.2?

Status
Not open for further replies.
E

evgenymagata

Member
Hi,

i bought a cheap DS3231 i2c module and realized it also has a 32khz output. Can i use that instead of a quarz to make the internal RTC of the teensy accurate, if so, can i wire it directly as a replacement for the quarz?

If not, what is good practice to make the teensy accurate using the DS3231 (instead of constant i2c readout and drift checks / reclocking?)

cheers,
e.
 
I do not know. Freescale's datasheet isn't really clear about whether the RTC oscillator can be driven by an external square wave. I have personally not tried this. Seems like it has a good chance of working, but then the RTC osc does have a AGC circuit, so it's not a simple matter like many other chips.

The pin definitely isn't 5V tolerant, so make sure your DS3231 is running from 3.3V power. A 5V signal would be very likely to damage your Teensy.

If you're going to try, this would be the place to connect the 32.768 kHz signal. Of course, GND also needs to connect to the DS3231 ground.

teensy32.jpg
 
You need a pullup to 3.3v on the 32k pin. I have an old DS3231 laying around (chronodot http://www.adafruit.com/products/255). With scope I verified I was getting 32khz spike on the 32K pin (25% duty), and also ran a frequency drift test (against NTP host) and measured less than 1 ppm for the DS3231 32K pin.
With 3.3v, GND, and 2.2k pullup on 32K pin, i measured 1.19 ma going to the DS3231.

I jumpered the 32K pin to the RTC crystal hole on T3.2 as noted by paul in post #2. It appears the RTC is working (get 0's from sketch if nothing in RTC holes), as RTC seconds are ticking. The drift of the RTC vs micros() yields the drift of the T3.2 MCU crystal, so T3.2 RTC seems to be ticking with accuracy of DS3231 TCXO.
 
Last edited:
Thanks Paul, Michael, Manitou for these excellent infos. I got a follow up question for you. What i am trying to achieve at some point in the future is a realtime SMPTE Timecode de&en-encoder. I was thinking to sync the DS3231 to the time received by a GPS Module, and then let the DS3231 do the timekeeping. I think a lot of GPS modules also have TXCO components but i was to lazy to research on the respective accuracy since i knew that the DS3231 will do the job.

Ok, so the next step is to get Robin Gareus libltc (https://github.com/x42/libltc) to run on the Teensy, in realtime. Among other things i asked him for some pointers on what to watch out for in terms of timing, this was his reply:

As for the timing question. libltc is only concerned with en/decoding timecode. The problem boils down to synchronize the TimeCode Module with your DAC. An LTC frame has 80 bits, e.g. 30 [fps] * 80 [bits/f] = 2400 bits per second. You need at least twice that as sample-rate for the DAC. but 8kHz or more is highly recommended.

receive time from GPS, convert to timecode "now = HH:MM:SS:FF"
add 1 frame HH:MM:SS:(FF+1)
encode this frame to audio using LTC using sample-rate SR
start playing the audio using the sample-rate SR
when the data is played back, exactly "1 frame" worth of time has passed (assuming the DAC is clocked by the GPS).
jump to (2) -- no need to query GPS again
If you cannot clock the DAC using GPS, some adaptive re-sampling or a PLL is needed.
Click to expand...

So, my follow up question: If the DS3231 is used as a crystal replacement, is the whole internal clock of the Teensy syncing with the DS3231 clock, including the DAC?
What i need to assure (if i understand Robins remarks correctly) is that after outputting 44100 samples with the audio library, exactly (according to the DS3231's precision) one second has passed...

Or do i need to look into this PLL idea?

Thanks,
E.
 
Last edited:
evgenymagata said:
So, my follow up question: If the DS3231 is used as a crystal replacement, is the whole internal clock of the Teensy syncing with the DS3231 clock, including the DAC?
Click to expand...

No, that's a wrong assumption.

Teensy 3.x has 2 crystal oscillators. Almost everything is timed by the PLL which syncs to the main 16 MHz crystal. When using the DAC with the audio library, the PDB timer generates the DAC's sample rate. The PDB timer runs from F_BUS, which is an integer division of the PLL. The integer div varies depending on which Teensy and which CPU speed you're using. Details are in kinetis.h.

With Teensy 3.2, the default CPU speed is 96 MHz and the default F_BUS speed is 48 MHz (div by 2).

What i need to assure (if i understand Robins remarks correctly) is that after outputting 44100 samples with the audio library, exactly (according to the DS3231's precision) one second has passed...
Click to expand...

I can't really comment on that remark, but I can tell you the default speed for the library with the PDB timer clocked at 48 MHz with a division of 1088. That results in a sample rate of 44117.647 Hz, which is slightly higher than 44.1 kHz, but the closest we can achieve using this hardware. You may wish to take that slight difference into account?
 
PaulStoffregen said:
I can't really comment on that remark, but I can tell you the default speed for the library with the PDB timer clocked at 48 MHz with a division of 1088. That results in a sample rate of 44117.647 Hz, which is slightly higher than 44.1 kHz, but the closest we can achieve using this hardware. You may wish to take that slight difference into account?
Click to expand...

Sorry If this is an obvious question since I only have a vague idea about those timing things: would it be possible to use a lower output Samplerate like 24 or 16khz? The minimum Samplerate for the smpte Timecode according to Robin would be 8khz.
 
evgenymagata said:
would it be possible to use a lower output Samplerate like 24 or 16khz?
Click to expand...

Possible, yes. Easy, no.

Several people have reported changing sample rates. Maybe you can find those old thread on this forum with some searching.

The minimum Samplerate for the smpte Timecode according to Robin would be 8khz.
Click to expand...

Maybe best to discuss SMPTE timecode modulation on that other thread?

https://forum.pjrc.com/threads/41584-Audio-Library-for-Linear-Timecode-(LTC)

I don't see how 8 kHz is any easier or different from 44.1 kHz.
 
PaulStoffregen said:
Maybe best to discuss SMPTE timecode modulation on that other thread?
Click to expand...

Thanks for the suggestion. In my understanding, the timecode modulation is being taken care of by libltc, so the issue that i am trying to understand here with my DS3231 question is how to get (extremely) precise timing and audio output from the teensy.

a typical use case for a Timecode Sync device is that, while shooting a film, the camera and the soundperson sync their respective clock devices at the beginning of the work day and then these two devices are supposed to run in sync (with less than one frame drift, so 1/25th of a second in the case of a 25fps frame rate) for a whole day, each recording the timecode either as an audio representation or on a seperate timecode track, to make the syncronization of sound and video during the editing process fast and reliable.

Before starting to get into actually decoding and encoding the actual timecode, i just want to make sure there are no pitfalls in the process. With my rudimentary understanding, something like 44117.647 sample rate might precisely cause a pitfall, because of the fractional sample that is not aligned with the clock rate. So my though was that a whole number of samples might be easier to handle, thus 48 / 24 / 16Khz ... if this is bullshit, please accept my apology, i am learning here and trying to understand.
 
Status
Not open for further replies.
Back
Top