Timekeeping - High Level ?

Go To Last Post
87 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

100/second along with an interrupt signal is possible for this one RTC

AM08X5 Datasheet (Ambiq Micro)

[page 1, near top of left column]

...

- Counters for hundredths, seconds, minutes, hours, date, month, year, century, and weekday

- Alarm capability on all counters

...

via Ultra-Low Power RTC

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ohhh, I like it!

 

Thank you,

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Error spec: better than naked 32.768 crystal. No absolute spec. Its "better is good".

 

Allowable tick sizes: uncertain.

 

Expected access to accurate time base: once a day

 

Rate of temperature change: normal diurnal rates, or perhaps 30C in 12 hours?

 

Remember, this is EARLY DESIGN. The decision, at this point, is mostly about program structure and high-level processes.

If you have a MCU with a temperature sensor, you may be able to do some modest TCXO work in the MCU, and use a generic 32KHz xtal, which are very cheap.

You can certainly use the 'once a day' to sort out offset errors so that leaves the temperature tracking side.

 

Or, you can go to a part like  SiT1533, (57c/3k)  and get better tempco than a xtal, but at a mid price/performance point relative to a full TCXO.

That lends itself to daily calibrate checks.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

My tick rate goal is at least one per second. I hope for 10 per second in some cases or maybe all the time. Hence, that becomes a challenge with using an external RTC as a substitute time base as most that I've found only provide interrupts at one per second. This pushes toward one of the PLL-like locking/synchronizing mechanisms.

 

Do your logging against the internal RTC mechanism, and add an extra entry entry to the log which time stamps every 1pps pulse from your external source.

 

You then have complete untweaked raw data logs, plus enough information to do the correction by any means you choose, interpolation/software PLL/whatever, once the data has been downloaded to be processed.

 

By doing the adjustments outside the units you will be able to do clever things like put error bars on all the results at an individual level, rather than some global level.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Last Edited: Wed. May 27, 2020 - 08:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is is critical that the reading be done at a certain (precise) moment, or more so that the time of that moment is precisely known?  These are not necessarily the same thing.   So you might say you need to take samples approx every 500ms, and approx being fine, as long as each time is precisely known.  so you end up with 0, 500.2, 999.89 1500.14, 1999.87....

 

 You read the RTC each time to get the exact actual time for the recording.   That's certainly an easy case, without accumulating error.

This exact time could also be used to set the timer for when to wake up again...since that interval is small (100ms), you probably hit it very close.  As mentioned, you'd know the timer count differences between samples & adj interval irq up/dn until the exact time differences became zero.

 

A slightly different question that applies regardless, is: when is the exact time?  Reading the time clock vs doing something with that & then taking a sample has some variability...but now we're down in the microseconds mud & could prob ignore.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Wed. May 27, 2020 - 02:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

...

A slightly different question that applies regardless, is: when is the exact time?  Reading the time clock vs doing something with that & then taking a sample has some variability...but now we're down in the microseconds mud & could prob ignore.

 

Pedantically, it's correct on that caesium clock attached to your network time server. NTP has some fairly clever algorithms to accommodate latency in the network between you and the precise time source. https://en.wikipedia.org/wiki/In.... NTP on a LAN should be correct to a millisecond or so.

 

If I walk to the kitchen to check the clock, by the time I get back to my desk time has moved on and what I saw is no longer correct. I need to factor in how long it takes me to walk back from the kitchen, etc.

 

As a smart-a*** colleague used to say whenever somebody remarked "oh, is that the time?", "no, time is an abstract concept; that's a clock".

 

And the most precise clock is the one that is stopped. At least it's correct twice a day ;)

 

 

Last Edited: Wed. May 27, 2020 - 12:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My intention is to simply provide a time stamp rather than samples at predefined times. 

 

Part of the issue is that the sample rate is driven by a sensor and that rate has a very significant temperature coefficient. The sample rate is totally out  of my control other than at a very gross level (250Hz vs 100Hz, for example). Because users are looking for very small frequency changes in the FFT of the data, the short-term sample rate has to be determinable after the fact. 

 

Another part of the issue is correlation between the data from this unit and others, say on a near-by meteorological tower. 

 

Both of these cases argue for a local time base with good short-term temperature characteristics, good long-term stability, and good resolution. Oh, of course, low power, low cost, and low program overhead. Lets see, that is 6 good things; can I have more than 2?

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Wed. May 27, 2020 - 06:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Might be an application for LoRa? Low data rate, low power and long(ish) distance. You could receive only to get time updates or maybe send out data etc? Of course, it adds another layer of complexity onto your application, but there's plenty of examples and off the shelf solutions available. It should be much lower power than using a GNSS receiver.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Both of these cases argue for a local time base with good short-term temperature characteristics, good long-term stability, and good resolution. Oh, of course, low power, low cost, and low program overhead. Lets see, that is 6 good things; can I have more than 2?

Sure, provided cost is not one of them ;)

 

The  SiT1533 OSC I mentioned above is  ±20ppm, and claims 0.9uA typical Icc, and it can be used with MCU that has 32KHz support, or RTC.

 

Or, you can buy a 32KHz xtal down as good as ±5ppm (~50c/3k) with these specs, and apply your own temperature correction if you need wider, but not extreme temperature coverage. 

Frequency Tolerance @ +25°C ± 5 ppm  - good initially, but it does have the parabola tempco

Equivalent Series Resistance R1 70K Ω

Turnover Temperature +20 +25 +30 °C

Temperature Coefficient -0.028 -0.034 -0.040 ppm/°C²  << use that and a temperature sensor.

 

Or you can pick a SIT1566A  $2/1k and get a 4.5uA ±3ppm   -20°C ~ 70°C level of operation.  

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This changes everything surely.

ka7ehk wrote:
looking for very small frequency changes in the FFT of the data

Won't slewing your clock introduce yet more error.

Does the timing jitter simply show as noise or does it have more serious affects.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Part of the issue is that the sample rate is driven by a sensor and that rate has a very significant temperature coefficient. The sample rate is totally out  of my control other than at a very gross level (250Hz vs 100Hz, for example). Because users are looking for very small frequency changes in the FFT of the data, the short-term sample rate has to be determinable after the fact.
Over what period and how many samples is the FFT done?

I'm guessing that even halfway between calibration events,

you will want an error less than the interval between measurements.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My thinking is that if the correction scheme is well done (a really questionable assumption), that the error should always be significantly smaller than the sample interval. 

 

FFT windows can be fairly long, as they are often looking at 1Hz scale frequencies and (big guess) maybe 1% to 0.1% changes in characteristic frequency. 

 

Temperature changes, on the other hand, typically have a period of 1 day, but I have seen much shorter scale changes when a shadow sweeps across a unit.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some older transmitter designs had a heat resistor on the crystal (both in a insulated "box" together with a temp sensor ), so it was warmed up to about 70 deg. (and the manual said don't key in the first 3 minuts after power up.). 

 

So if it's always on that could be a way to do it.

 

 

LOL

I just picture a crystal clued on the top of the AVR with a resistor and some insulator tape over and also under the pcb, and then keep the AVR (with the internal temp sensor) 70 deg.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
but I have seen much shorter scale changes when a shadow sweeps across a unit.

This illustrates my point. Won't that drift in sample-rate/time-stamps appear as noise after FFT. OK A very low frequency noise but isn't that what your customer is measuring?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the timebase drifts, it will compress or expand the freq axis...so a 20ppm drift is 0.002 % compression/expansion.   It would only matter if you were looking at a very tight absolute freq & instead ended up looking at a close neighbor.  The general spectral shape would overall, look the same.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

Some older transmitter designs had a heat resistor on the crystal (both in a insulated "box" together with a temp sensor ), so it was warmed up to about 70 deg. (and the manual said don't key in the first 3 minuts after power up.). 

So if it's always on that could be a way to do it.

LOL

I just picture a crystal clued on the top of the AVR with a resistor and some insulator tape over and also under the pcb, and then keep the AVR (with the internal temp sensor) 70 deg.

In a more modern twist on this, you can buy 4-Pad xtals with an inbuilt thermistor,  but I've seen them only in GPS related MHz values, not seen one in 32kHz yet ? 

 

There are Temperature sensors made using a deliberate cut crystal.

 

Something interesting could be made with two crystals from here ?

https://www.axtal.com/English/Products/PiezoSensors/TemperatureSensors/

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My understanding is the Fourier transforms, fast or otherwise,

are based on equally spaced sample.

If you customer can only get sort of 10 Hz-ish,

he might have trouble doing the math.

I suppose some king of FT could be done with unevenly spaced

samples, but I'd expect the fast part of FFT to be inoperative.

 

Where are these things going to be that they cannot

find a GPS satellite, WWV or something more than once a day?

 

Since 2018 one has been able to buy a 120 mW

RoHS-compliant atomic clock on a chip.

IIRC it only cost a few thousand.

 

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
Since 2018 one has been able to buy a 120 mW
Not great for a battery powered data logger running on 2 'D' cells.  40 mA.  A pair of cells would be dead in less than 2 weeks.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am well aware of the issue around equal spacing of samples. At this point, I have no solution, good or otherwise.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There seem to be a lot of post-processing techniques and libraries than can help if the data is non uniform/jittery

https://scicomp.stackexchange.com/questions/593/how-do-i-take-the-fft-of-unevenly-spaced-data

 

The effect of the jitter could be so secondary that nobody notices or cares.  Hopefully it's all down in the noise!!

 

It's not always a slam dunk:

There's the jitter you do know about (you have a list you can see of slightly nonuniform time values) 

There's a jitter you don't know about (when exactly were theses slightly nonuniform time values actually taken, with respect to the data conversion)

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I'm curious what they get out of the change in mode frequency.   Are they using that to track the growth rate?

Last Edited: Sat. May 30, 2020 - 01:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Which takes you back to the original premise: either you have to track your error (somehow) and adjust the timestamp as written, then do the heavy lifting in the NUDFT later, or you need to find a way to keep your sampling (and implicitly, assuming you're issuing the sample request) at a precision suitable for your post-sampling processing.

 

Seems to me they're both really the same thing; since to track the error you need a precise (but wrong) timebase anyway, you may as well get the timebase right and be done with it.

 

Can you tolerate a few days' tuning time at the beginning of the samples? You can do a calculate error and adjust at each time-of-day correction, basically a very slow phase locked loop in software. You may even be able to incorporate a correction to the clock frequency based on temperature... but your simplest (and possibly only) way may be to find a low power thermally controlled oscillator that lives in your power budget.

 

(thought: watch crystals (32768Hz) are tweaked to run inside a second a day at worn-on-the-arm temperatures. Or a tuning capacitor selected for the inverse temperature drift of the crystal (good luck with that one!))

 

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MattRW -

 

They are using changes in the  mode frequency to track when the tree leafs out or drops its leaves. Others use it to track rainfall, in which the rain collected on the leaves changes the mass of the tree canopy. And, other similar things.

 

Neil -

 

I cannot control the sample rate other than in very gross steps. It is driven from a sample rate clock (ultimately, there are several internally-clocked Delta-Sigma ADCs) inside the sensor and THAT has the significant temperature coefficient. So, the only thing I can do is provide timestamps and let the user do what ever he or she can. That MIGHT mean interpolating and resampling. OR, it might mean some algorithm other than the standard FFT. Thats the best I can do. Thus, the search for a "good" (e.g. better than uncompensated 32.768KHz crystal) clock.

 

Everyone -

 

Thanks for the suggestions and comments. This has really helped me to understand what some of the issues are and helped me to comprehend some of the techniques that might help address this challenge. It clearly won't be trivial but that is also what makes this challenge "interesting".

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

I cannot control the sample rate other than in very gross steps. It is driven from a sample rate clock (ultimately, there are several internally-clocked Delta-Sigma ADCs) inside the sensor and THAT has the significant temperature coefficient. So, the only thing I can do is provide timestamps and let the user do what ever he or she can. That MIGHT mean interpolating and resampling. OR, it might mean some algorithm other than the standard FFT. Thats the best I can do. Thus, the search for a "good" (e.g. better than uncompensated 32.768KHz crystal) clock.

The sensor tempco will be much larger than your Xtal, so even little compensation should be quiet good.

 

Looking at Xtals, the initial & reflow errors you can correct from your 'once a day' time update, so that leaves getting a modest temperature correction working, for that the tightest parabola spec is needed.

I did find this Xtal

https://lcsc.com/product-detail/SMD-Crystal-Resonators_Seiko_SC-32S32-768kHz20PPM9pF_Seiko-SC-32S32-768kHz20PPM9pF_C97605.html

that has the tightest spec on the parabolic correction I've seen so far   (-0.030±10%)×10-6/℃^2

The ECS one with 5ppm initial tolerance, is  about ±18%

 

For more $, but from the same supplier is this 32kHz Oscillator, - specs  ±3 ppm and a corrected tempco, that is much less parabolic.  1uA Icc typical.

https://www.sii.co.jp/en/quartz/files/2018/03/20180704_SH-32-leaflet-e.pdf

 

What range of operating temperatures do you need to correct over ?

 

Last Edited: Sun. May 31, 2020 - 05:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

when the tree leafs out

For some trees that is a slow process, where it first start to get sap up from the roots before it start to leaf out, and that must also change the freq.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, both leaf drop and leaf growth are slow. That is part of the challenge.

 

I have seen temperature compensated RTCs with "built in" crystals spec'ing tolerances under +-5ppm (I think) for not a lot of money (or power) - Abracon, maybe. So it looks like there are multiple sources. 

 

Thanks

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's a thought:

 

Maybe set up a periodic interrupt from the RTC:

4.5. PERIODIC COUNTDOWN TIMER INTERRUPT FUNCTION The Periodic Countdown Timer Interrupt function generates an interrupt event periodically at any period set from 244.14 μs to 4095 minutes. When an interrupt event is generated, the INT ̅̅̅̅̅ pin goes to the low level and the TF flag is set to 1 to indicate that an event has occurred. T

https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-8803-C7_App-Manual.pdf

 

Set the ADC to trigger off of this external countdown signal (presented at the ADC triggering pin). 

Then you have precise sampling repetitions, with essentially zero software timing/latency considerations.  You can additionally, thereafter, read the RTC, to read out what the exact time of the IRQ pulse was.  As far as the AVR, if you know you want a sample every 100ms, wake it up say, 3 ms early, so the ADC is ready to respond to the precise RTC countdown trigger pulse.

 

AVR WAKE 3ms early

WAIT for ADC external START trigger (from RTC countdown timer generated PULSE)

     read adc

READ RTC FOR TIME VALUE (allows calc of when pulse must have occurred).

AVR sleep

 

 

 

 

 

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sun. May 31, 2020 - 08:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No separate ADC here. It is an external chip with its own sample rate clock and delta-sigma ADC.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Sun. May 31, 2020 - 08:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, separate ADC here. It is an external chip with its own sample rate clock and delta-sigma ADC.

 hmm....Maybe that ADC chip has a trigger pin??...that's all that is needed for this "scheme"...the scheme being: let the RTC cause the ADC to take a sample.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No trigger pin. It is totally autonomous. You have a few choices:

 

(1) Read a sample when it says that a sample is ready (via interrupt line)

 

(2) Samples stashed in a FIFO buffer that you can access at any time up to the point where the FIFO overflows (at which time, you start loosing samples). An interrupt signal can be used to tell you when any given FIFO count is reached. You can read the FIFO count at any time to determine how many are present. You can also read up to (FIFO count) samples from the FIFO.

 

(3) You can read a status register to see if a new sample is available.

 

That is it. 

 

Device is LIS3DSH accelerometer from STmicro.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Sun. May 31, 2020 - 11:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"here's another thought"

 

If you get shadows, you get sunshine. How about a small solar panel to charge a better battery to power a better TXCO.

 

Ross McKenzie ValuSoft Melbourne Australia

Last Edited: Mon. Jun 1, 2020 - 01:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it's at the top of a tree I would think of a magnet in a coil could be inside the box, then it could still be ?IP67 and generate some power in the wind.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe getting up to the top of the tree is not an option.

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The unit measure how the tree move in the wind, and depending of the osc.freq it find out if there are leafs on the tree. I don't think that can be done at the ground level

unless you place an strain gauge on the tree. (this is a joke don't comment)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Abracon, maybe.
indeed

  • 800nA typ
  • wide voltage range
  • extended industrial temperature range at time accuracy of 5ppm or 15ppm typ
  • temperature precision is 6C typ

ASTX-H09-pg1.pdf

via https://abracon.com/parametric/realtimeclocks?limit=100&page=1&interface=I%C2%B2C%2C%202-Wire%20Serial&part_status=Active

 

"Dare to be naïve." - Buckminster Fuller

Pages