Getting more precise timing

Using Arduino Programming Questions
#1

Hi, everyone I'm working on a clock device for audio/midi/synth purposes, it is pretty accurate right now, but I think it can do better.

The code runs on a library, and gets refreshed on the loop. The code calculates how many micros should it wait until it must do something. and also Stores how many microseconds are lost every minutes.

This is the pice of code that determines the length of the steps:

if(PPQN[i] == 0){ PPQN[i] = 1; }
_TPM[x] =(BPM * PPQN[x]);         
Tick[x] = (60000000 / _TPM[x]);  
_ML[x] = (60000000 - (Tick[x] * _TPM[x]));

First the code makes sure that PPQN (Pulses per quarter note) are not equal to 0. Then it multiplies BPM times PPQN to know how many Pulses must send on a minute (TPM = Ticks per minute). Then it determines the length of the intervals, and then multiplies the Pulse length by TPM and then subtract that from 60000000 to know how many microseconds are lost.

So what do you think? Is there a way that I can divide the steps better, without getting extreme hardcore math?.

maybe you can think of something, or point me toward the right direction, Thanks :slight_smile:

#2

and then subtract that from 60000000 to know how many microseconds are lost.

What do you mean by lost? microseconds can’t get lost.

Is there a way that I can divide the steps better

Better is a relative term. You’d need to describe, as though you were talking to your teddy bear (or mine), what the code currently does, and what is wrong with that, before any suggestions for improvements can be made.

#3

Depending on the data types of your variables the calculations may not actually be doing what you think they are.

#4

PaulS:
What do you mean by lost? microseconds can't get lost.

Those are the microseconds that would get lost yup, Let me explain this in other way.

Let's say we want to get the length of the steps for a clock running at 132.5 BPM(float) at 22 PPQN(uint32)

so the code first multiplies both so TPM is equal to 2,915

then it gets the length of the step by dividing it into 60,000,000 , because we are using Beats per minute and microseconds. So Tick (uint32) is equal to it is equal 20,583.

then if we multiply that number again by the number we divided we know how many microseconds per minute you are going faster.

20,583 * 2915 = 599,999,445

so 60,000,000 - 599,999,445 = 555

This means that every minute your clock is running 555 microseconds faster than it shoud

I don't know if to makes sense, I can attach the library files if you want to give it a check.

PaulS:
Better is a relative term. You'd need to describe, as though you were talking to your teddy bear (or mine), what the code currently does, and what is wrong with that, before any suggestions for improvements can be made.

I want to reduce the amount of microseconds lost every minute, that would be much better :slight_smile: :slight_smile:

UKHeliBob:
Depending on the data types of your variables the calculations may not actually be doing what you think they are.

BPM is a float, all the other variables are 32 bit unsigned integers :slight_smile:

#5

So BPM = quarter notes per minute and
PPQN = Ticks per quarter note
so 132.5 BPM * 22 PPQN = 2915 TPM

2915 TPM = 20583.190394511149228 Microseconds Per Tick

That gets truncated (rounded?) to 20583 Microseconds Per Tick so after 2915 ticks you are 555 microseconds short of a minute.

Multiply 555 times 1 million and divide by Ticks Per Minute to get millionths of a microsecond (picoseconds) to add per tick: 190394. Add that value to an accumulator every tick and when it goes over 1 million (about every 5.25 ticks), add 1 to the length of the tick and subtract 1 million from the accumulator. At the end of a minute you will be short by less than 1.5 nanoseconds.

#6