Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #56339

Re: microsecond resolution delay and time

Show all headers | View raw

On Saturday, March 25, 2017 at 11:10:01 PM UTC-5, rickman wrote:
> On 3/25/2017 10:08 PM, krishna.myneni@ccreweb.org wrote:
> > On Saturday, March 25, 2017 at 8:42:46 PM UTC-5, rickman wrote:
> >> On 3/25/2017 1:57 PM, krishna.myneni@ccreweb.org wrote:
> >>> On Tuesday, March 21, 2017 at 1:59:12 PM UTC-5, Brad Eckert wrote:
> >>>> On Thursday, March 16, 2017 at 7:57:22 AM UTC-7, krishna...@ccreweb.org wrote:
> >>>>>
> >>>>> Do you mean that millisecond resolution was not necessary for your application(s), or that you simply needed a rescaling of the milliseconds count back into seconds?
> >>>>>
> >>>> I use a 32-bit COUNTER (a FORTH Inc word) incremented at 10 kHz (non-standard) because the MCU has a built-in 10 kHz clock (80 kHz oscillator) that I keep running all the time, even in sleep mode. A 16-bit timer overflows into a count in memory, so the whole thing serves as a RTC (with 2% accuracy - not exactly Swiss time).
> >>>
> >>> If you need better accuracy, you could consider putting some thermal insulation around the quartz crystal oscillator, or perhaps even replace it with an ovenized-crystal oscillator. Such oscillators are readily available at 10 MHz, so a clock divider circuit would be needed to bring it down to 10 kHz. The fractional frequency stability is on the order of 10^-10, so the clock would deviate about 10 microseconds per day (not bad!).
> >>>
> >>> Here's a link to an expensive one, but cheaper ones (~$100) can be found.
> >>>
> >>> http://www.thinksrs.com/products/SC10.htm
> >>
> >> Well, sure, an ovenized oscillator would be great.  But why stop there?
> >> Get an atomic clock oscillator while you're at it.  Did you notice he
> >> mentioned keeping the oscillator running while the CPU is in sleep mode?
> >>
> >
> > Depends on the application, and an atomic frequency standard might be needed for some applications. Higher end test instruments such as fast oscilloscopes keep power on their ovenized crystal oscillators all the time, even when the rest of the electronics is off. The oscillator I linked to has a power consumption between 3 to 8 W, depending on the ambient temperature. Of course, I suggested a no-power low-tech option, which was to thermally insulate the standard crystal oscillator, but apparently your short-term memory register doesn't hold much information.
> 
> I'm just commenting on the fact that he is talking about an RC 
> oscillator built into a CPU which is powered down between operations. 
> Insulation may help some with that.  But if it isn't heated to a 
> constant temperature (ovenized) this is only changing the response time 
> and not the actual extent of the temperature excursions.
> 
> In fact, since the CPU is powered up and down, adding insulation may 
> *increase* the temperature excursions as the unit warms up to a higher 
> operating temperature.  Better might be a good heat sink directly on the 
> CPU to minimize the self heating impact.  It would require some 
> knowledge of the operating details to know which is better.
> 

Ok, I assumed Brad was talking about an external oscillator. Even simple microcontrollers such as PICs have an external clock input. Yes, I agree, if the oscillator is integrated inside the CPU, stabilizing it with thermal insulation might not be a great idea. Better to use an external oscillator if better accuracy is needed.

Krishna

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-15 18:06 -0700
  Re: microsecond resolution delay and time hughaguilar96@gmail.com - 2017-03-15 21:48 -0700
    Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-16 07:42 -0700
  Re: microsecond resolution delay and time stephen@mpeforth.com (Stephen Pelc) - 2017-03-16 10:29 +0000
    Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-16 07:57 -0700
      Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-16 08:04 -0700
      Re: microsecond resolution delay and time stephen@mpeforth.com (Stephen Pelc) - 2017-03-16 16:14 +0000
        Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-16 10:00 -0700
      Re: microsecond resolution delay and time Brad Eckert <hwfwguy@gmail.com> - 2017-03-21 11:59 -0700
        Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-25 10:57 -0700
          Re: microsecond resolution delay and time rickman <gnuarm@gmail.com> - 2017-03-25 21:42 -0400
            Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-25 19:08 -0700
              Re: microsecond resolution delay and time rickman <gnuarm@gmail.com> - 2017-03-26 00:09 -0400
                Re: microsecond resolution delay and time Paul Rubin <no.email@nospam.invalid> - 2017-03-25 22:18 -0700
                Re: microsecond resolution delay and time rickman <gnuarm@gmail.com> - 2017-03-26 02:48 -0400
                Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-26 05:21 -0700
              Re: microsecond resolution delay and time hughaguilar96@gmail.com - 2017-03-25 23:12 -0700
                Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-26 05:32 -0700
  Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-25 11:20 -0700
    Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-25 18:28 -0700
      Re: microsecond resolution delay and time rickman <gnuarm@gmail.com> - 2017-03-25 21:44 -0400
        Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-25 19:00 -0700
          Re: microsecond resolution delay and time rickman <gnuarm@gmail.com> - 2017-03-26 03:00 -0400
            Re: microsecond resolution delay and time krishna.myneni@ccreweb.org - 2017-03-26 05:39 -0700
              Re: microsecond resolution delay and time rickman <gnuarm@gmail.com> - 2017-03-27 18:10 -0400

csiph-web