Clock precision in arduino and clock modules connection

Hello,
I am doing a project where I read the angles of two axis of a telecope tripod from 2 encoders to then determine where it is looking at.

I still have a fair bit of coding to do, but I basicaly have 2 encoders feeding two slaves with values, and a master connected to the 2 slaves, a screen and a rotary encoder button for menu selection and all that jazz. I have connected the 2 encoders and the screen successfully. I need another 2 pins for the button I believe, so I'm getting low on free pins.

I also need a time reference. It doesn't have to be real time, but I need to be able to measure elapsed time, with ideally a precision of around 1 second on a running time of a few hours (3 would be nice).

Do you know if the internal clock will be precise enough?
Do you think I need a clock module?
Do you know how many pins it takes? If a can share pins with encoders/slave/screens/buttons?

Any experience in that field is welcome.

Cheers

Grێoire

The internal clock should be sufficient for your purpose. Check yourself how much millis() differs from PC clock after 3 hours. Then you also can correct the measured time by the known deviation.

gregoirem:
Do you know if the internal clock will be precise enough?

The internal clock, of most of the Atmega based Arduinos, is unlikley to be accurate or stable enough, but you might want to reveal which Arduino you are using.

Most Arduinos dont actually use the internal clock anyway, they use an external crystal or resonator, and the accuracy or stability of that depends on the components actually used on your Arduino.

You need to measure the 'precision' yourself, as has already been suggested.

Keep in mind that the internal Arduino clock is highly temperature dependent.

What do you consider "internal" clock? The 8MHz RC generator or the XTAL or ceramic resonator based one? It's easier to add an accurate crystal instead of a RTC module.

The ds3231 is a good accurate clock module that costs about $3, and is established practice, so why not just bight the bullet?

Arduino's counter may indeed be quite adequate, but is very subject to temperature variations and, for your sort of work, may be just what you don't need.

Further, your project is likely to involve something clock-related next week that you didn't think of last week, leading to you regretting not having an RTC.

DrDiettrich:
What do you consider "internal" clock? The 8MHz RC generator or the XTAL or ceramic resonator based one? It's easier to add an accurate crystal instead of a RTC module.

I was referring to the millis() function, which I don't know what it is based on (I'm using Arduino Nano boards). I just did a few tests and it is off by a few seconds after a couple of hours, I could test further and see if it is temperature related as jremigton mentionned, but I believe it is unnecessary as I will have to have a better clock anyway.
What do you mean by add an acurate crystal instead of a RTC?
I might go down the ds3231 route anyway, as Nick said, I might find it useful down the line.

gregoirem:
I was referring to the millis() function, which I don't know what it is based on (I'm using Arduino Nano boards).

Everything in a processor runs on a clock (like all the daily things in your life),
which is a cheap temp dependent inaccurate ceramic resonator on a classic Nano.

The problem will be solved if you use an Arduino with a crystal clock.
Adding a RTC will complicate things, and replacing the resonator for a crystal is only for experts that can work with smd parts.

Why three boards. That will also complicate things.
Leo..

Some Nano clones have a quartz crystal instead of a ceramic resonator. Those are very much more accurate and also more temperature stable.

If you already have any I2C devices, you can usually add an RTC to the I2C lines, because I2C devices have bus addresses, they can co-exist with other I2C devices on the same data lines.

The Arduino internal timekeeping is as good as the reference oscillator.

A board with a computer grade crystal will be good to about 100 ppm, which works out to about 1 second over 3 hours.

A board with a ceramic resonator will be good to about 0.5% which works out to almost a minute over 3 hours.

These are worst case over the specified temperature range, so typically you'll do better.

The DS3231 is specified to 2 ppm or about 0.02 seconds over 3 hours.

Wawa:
Why three boards. That will also complicate things.

The three boards (actually probably 2 after testing) is because I have encoders that trigger interrupts, and I need to miss as little steps as I can. Making the board busy with dealing with a screen, a button, possibly a clock, the logic that calculates the stars coordinates, all that while having encoders triggering interrupts, resulted in about 0.5% of steps missed in the conditions I will use it in. Having one board dealing with one encoder (actualy probably 2 encoders on the same board as it seems that it works fine this way) and communicating via SPI to send the measured value to the master solved this problem.

MrMark:
The Arduino internal timekeeping is as good as the reference oscillator.

A board with a computer grade crystal will be good to about 100 ppm, which works out to about 1 second over 3 hours.

A board with a ceramic resonator will be good to about 0.5% which works out to almost a minute over 3 hours.

These are worst case over the specified temperature range, so typically you'll do better.

The DS3231 is specified to 2 ppm or about 0.02 seconds over 3 hours.

That is what I measured (about a minute over 5-6 hours) and the precision of the DS3231 is way better than I need, but then I don't have to worry about it anymore! Ijust ordered it.

Have you worked out how to communicate between boards.
And how much extra time that takes.

gregoirem:
...the precision of the DS3231 is way better than I need...

That also takes time to communicate with.
A board with crystal would have been easier.
Leo..

gregoirem:
The three boards (actually probably 2 after testing) is because I have encoders that trigger interrupts, and I need to miss as little steps as I can. Making the board busy with dealing with a screen, a button, possibly a clock, the logic that calculates the stars coordinates, all that while having encoders triggering interrupts, resulted in about 0.5% of steps missed in the conditions I will use it in.

Ordinary controller activity does not block interrupts. If you find a problem with 2 encoders then your encoder ISR is designed badly, spending too much time in the ISR itself. Another ISR design problem is debouncing of buttons in an ISR - that's fatal abuse of interrupts.

I'm wondering how this

Gets squared with this

Wawa:
Have you worked out how to communicate between boards.
And how much extra time that takes.

Nick_Pyner:
I'm wondering how thisGets squared with this

That wouldn't matter too much. It's increasing error over time that I want to avoid. I don't intend to do real time analysis of any data, and a second or two delay in measuring encoders and displaying it is fine.

Here is a try at explaining my plan:

Slave: read encoder value all the time

Master: get encoder values from slave (6 bytes in 7 SPI calls, encoder values being stored in valueToSend variable on first call)
get time straight after and record it
process encoder values+recorded time
display something on the screen depending on those values
repeat or wait for button instruction

The encoder values measure the rotation of 2 perpendicular axis of a telescope mount. But the stars move all the time, so getting just the encoder value won't give me enough information to know which star I'm pointing at.

There will be an initialisation of the program where I would point at stars of known positions and click on q button to record the encodervalues/time. This then calibrates the program to then be able to give the sky coordinates from a couple (encoder values/time). This takes into consideration time between measures. So as long as I do (master get value from slave; master get time) in the same order without anything in between to record any couple of (encoder values/time), even if the time I record doesn't correspond to the time the encoder had those values, time between to record of (encoder values/time) will be the time I want anyway. Even if the call to slave take 0.2s and the call to time take 0.1s.

Even if I can get good accuracy for the calibration, after let's say 3 hours of use (typical observation session time), the program will still use the initial calibration, and calculates the roation of the stars to know where the telescope is pointing at. If at that point it is of by 10s, the position will be off by a little bit too, so I prefer to avoid that if I can.

In the end, I will need more than 32k of memory anyway, so I might get an arduino mega, which comes with a crystal.

DrDiettrich:
Ordinary controller activity does not block interrupts. If you find a problem with 2 encoders then your encoder ISR is designed badly, spending too much time in the ISR itself. Another ISR design problem is debouncing of buttons in an ISR - that's fatal abuse of interrupts.

With 2 encoders on the board, there is no problem at all. It is with one (or 2) encoders plus tft screen that there was some problem. My ISR code (in bith cases, master/slave or everything on the same board) is here, I don't think it can be much faster than that, but if it can I'm happy to learn how:

// Altitude encoder interrupt routine
ISR(INT0_vect)
{
  // Activated if channel A of the altitude encoder (pin 2) changes state
  // Check channel B of the altitude encoder to determine the direction (pin 4)
  
   switch (PIND & 20) {//20 = b00010100, used to read pin 2 and 4
      case 20:
        ++altEncoderCount;
        break;
      case 0:
        ++altEncoderCount;
        break;
      default:
        --altEncoderCount;
  }
}  // end of altitude encoder interrupt routine

I might get an arduino mega, which comes with a crystal.

Wrong. The Mega has a resonator.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.