Hard Drive POV Clock inconsistent RPM issue remains

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
So I pretty much have my clock working but it is not working 1t 100% the way I want. I still seem to be getting an inconsistent RPM reading. Though it is vastly improved. Previous versions had much more shift of characters, I think do to the greater shift in RPM measurement. Part of that may have had to do with a sensor and or magnet that was poorly mounted tossing some vibration into the mix.

But the display is still not rock solid and would like to get some thoughts on trouble shooting this. I have vastly simplified my CCP interrupt code.

Code:
if (PIR4bits.CCP5IF == 1)
  {  
  PIR4bits.CCP5IF = 0;
  
  // Calculate ticks per revolution from Timer 1 capture
  unsigned long thisCCPPeriod;
  thisCCPPeriod = CCPR5H;
  thisCCPPeriod = (thisCCPPeriod << 8) | CCPR5L;
  ticksPerRev = (thisCCPPeriod - prevCCPPeriod);
  prevCCPPeriod = thisCCPPeriod;  
  revTimeUpdated = 1;  
  totalOverflows=0;  
  
  
  // Setup Timer 3 to turn on the LED in Slot 0
  T3CONbits.TMR3ON = 0; // Timer 3 off
  frameCounter = 0;
  TMR3H = (frameDelayTimes[frameCounter] >> 8);
  TMR3L = (frameDelayTimes[frameCounter] & 0xFF);  
  ledsOn = 1;
  T3CONbits.TMR3ON = 1; // Timer 3 on
  
  }

I calculate the rpm in the main loop and set up all of the interrupt times to turn on the LEDs. I am taking 16 samples before calculating the RPM and setting up the timers. For brevity I have excluded the code that setups up the LED time tables and bit map for the LEDs.
Code:
INTCONbits.GIE = 0;  
  oldTicksPerRev = ticksPerRev;  
  revTimeUpdated = 0;
  INTCONbits.GIE = 1; 
  
  totRotationTicks = totRotationTicks + oldTicksPerRev;
  rotationTimesCount++;

  if (rotationTimesCount >= MAXROTATIONTIMES)
  {
  rotationTimesCount = 0;
  avgRotationTicks = totRotationTicks / MAXROTATIONTIMES;
  totRotationTicks = 0;  
  ticksPerDegree =  (float)(avgRotationTicks / 360.0);  
  
  float timePerRev = avgRotationTicks * 0.0000305;
  rpm = (1 / timePerRev) * 60;  
  
  
  }
The video below shows what I mean. What is strange is the reading on the scope appears to be rock solid but if I do a measurement on the period, it does seem to be changing.

I am still getting a clicking that I solved once put had to disassemble The disk. I am wondering if that would cause the inconsistent RPM I might try to clear that up and see if if it fixes it.

Not real good at math. Does it look like that period change is consistent with the RPM change?


P.S. It is not near as nosily as it sounds in the video but it is there.
 
Last edited:

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
So you want me to toggle one of the outputs when the CCP occurs? Well I can scope one of the LEDs. Would that help?

What is causing that change in period on the sensor? I am scoping the sensor. And why am I not seeing a change in period on the waveform?
 

nsaspook

Joined Aug 27, 2009
13,086
So you want me to toggle one of the outputs when the CCP occurs? Well I can scope one of the LEDs. Would that help?

What is causing that change in period on the sensor? I am scoping the sensor. And why am I not seeing a change in period on the waveform?
You need something to tell the amount of changing 'slip' between the sensor signal that might be completely stable and when the controller reacts (that might be changing) to the input signal.

What we are looking for is not a change in the waveform period. We are looking for a 'phase' shift between two things at the same periods (RPM) but with slightly changing synchronization.

It's something we see with analog signals in a Lissajous Pattern if we change the phase relationship of one signal in the X/Y configuration with two inputs of the same frequency.

3:30
 

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
You need something to tell the amount of changing 'slip' between the sensor signal that might be completely stable and when the controller reacts (that might be changing) to the input signal.

What we are looking for is not a change in the waveform period. We are looking for a 'phase' shift between two things at the same periods (RPM) but with slightly changing synchronization.

It's something we see with analog signals in a Lissajous Pattern if we change the phase relationship of one signal in the X/Y configuration with two inputs of the same frequency.

3:30

So is there anyway for me to verify that the sensor is stable with my scope?
 

nsaspook

Joined Aug 27, 2009
13,086
So is there anyway for me to verify that the sensor is stable with my scope?
Just look at the period with the scope Persist set to a high or infinite value. Thickening lines means jitter. If you see a lot the most likely source is disk speed as the sensor reaction change should be just a slight noise factor with a good unit.

Some scopes do have a jitter problem even with stable signals so YMMV on what you see.
 

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
I moved the disk further off of the board. The disk must have been dragging on something because now the RPM is nearly double. But there is a strange optical illusion going on with that zero.

The downside of moving the disk further off of the board is more light contamination on other numbers. That first five is not even above an LED. The led under the 4 is lighting 2 LEDs.


 

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
Just look at the period with the scope Persist set to a high or infinite value. Thickening lines means jitter. If you see a lot the most likely source is disk speed as the sensor reaction change should be just a slight noise factor with a good unit.

Some scopes do have a jitter problem even with stable signals so YMMV on what you see.

This was after about 2 minutes.
upload_2019-3-9_21-31-4.png
 

nsaspook

Joined Aug 27, 2009
13,086
Does that delta X fraction of total RPM time look to be in proportion to the total rotation time for the digit movements you are seeing?
 

John P

Joined Oct 14, 2008
2,025
Does a line like this

thisCCPPeriod = (thisCCPPeriod << 8) | CCPR5L;

involve 8 one-bit shifts or anything similarly hideous? You could define the variable as a union and access its two bytes separately, and avoid any such delays. Though even if it's inefficient, it should be doing the same thing every time, so it shouldn't cause jitter.
 

atferrari

Joined Jan 6, 2004
4,764

djsfantasi

Joined Apr 11, 2010
9,156
D5A015D1-3720-4361-B066-422D7CBCEFE0.jpeg
Is it just me?

I can see a discrete block around each digit in the video. For example, there are gray bars just after each digit. The light for the 4 looks like it starts significantly before the digit center. Or the light from the start to the digit center is greater than from the digit center to where it stops.

Is this period caused by when the software turns on the light to when it turns off the light? Or is the period when the light is on affected by a delay in the LED or driver?

You might be able to see what I am talking about better, if you could just illuminate one digit. Of course, that could affect the timing I’m a manner such that the test results are moot.
 

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
View attachment 171998
Is it just me?

I can see a discrete block around each digit in the video. For example, there are gray bars just after each digit. The light for the 4 looks like it starts significantly before the digit center. Or the light from the start to the digit center is greater than from the digit center to where it stops.

Is this period caused by when the software turns on the light to when it turns off the light? Or is the period when the light is on affected by a delay in the LED or driver?

You might be able to see what I am talking about better, if you could just illuminate one digit. Of course, that could affect the timing I’m a manner such that the test results are moot.

You might have caught a frame where I had a "jitter" problem. I am fairly certain every thing is lined up under normal conditions but I think I am going to do one of two things since I have trouble seeing the bar you mentioned in real life.


The "bar" you are seeing might be the "wall" I have between each slot / LED.


Get some white paint and mark boundary lines for each slot on the frame. Maybe even a center mark.

Or cut a smaller number disk so I can see behind the disk where each number is firing.

I can turn on any LED independently and it should not affect the timing. In the video, you see only 4 numbers but there are 8 slots. I have a chain of 8 timer interrupts. The CCP interrupt sets up the first interrupt. It is actually 0 that timer sets up the next one and the next one and so on. Times are precalculated in the main loop, based off the amount of degrees of movement that I want for each slot.
 

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
Does a line like this

thisCCPPeriod = (thisCCPPeriod << 8) | CCPR5L;

involve 8 one-bit shifts or anything similarly hideous? You could define the variable as a union and access its two bytes separately, and avoid any such delays. Though even if it's inefficient, it should be doing the same thing every time, so it shouldn't cause jitter.

I don't understand your post. The code you posted is exactly what I have above.


thisCCPPeriod = CCPR5H;
thisCCPPeriod = (thisCCPPeriod << 8) | CCPR5L;
ticksPerRev = (thisCCPPeriod - prevCCPPeriod);
prevCCPPeriod = thisCCPPeriod;
revTimeUpdated = 1;
totalOverflows=0;
 

nsaspook

Joined Aug 27, 2009
13,086
Probably the best / simplest trick ever since I started using interrupts.
I usually 'Instrument' several critical timing points in the interrupt code.
https://forum.allaboutcircuits.com/threads/project-ideas.143685/page-2#post-1330315

Here you see a typical set of signals.



Sensor to ISR response jitter.
Scope trigger is on 0 HALL with the Instruments ISR signal on 2 ISR. The interrupt jitter looks to be in the range of 80ns. That's too small to be much of a display issue with my simple demo unit.


Disk rotation sensor HALL jitter detail using analog signal probe. Falling edge trigger to rising edge end of sync tab.

Detail


About 6us of jitter for that tab length times maybe 60 for the disk total circumference gives rotational jitter of about 0.36ms.
 

djsfantasi

Joined Apr 11, 2010
9,156
You might have caught a frame where I had a "jitter" problem. I am fairly certain every thing is lined up under normal conditions but I think I am going to do one of two things since I have trouble seeing the bar you mentioned in real life.


The "bar" you are seeing might be the "wall" I have between each slot / LED.


Get some white paint and mark boundary lines for each slot on the frame. Maybe even a center mark.

Or cut a smaller number disk so I can see behind the disk where each number is firing.

I can turn on any LED independently and it should not affect the timing. In the video, you see only 4 numbers but there are 8 slots. I have a chain of 8 timer interrupts. The CCP interrupt sets up the first interrupt. It is actually 0 that timer sets up the next one and the next one and so on. Times are precalculated in the main loop, based off the amount of degrees of movement that I want for each slot.
The bars I see appear in the entire visible I grabbed one frame and attempted to mark each one

The first two marks define a time period which appears similar for every digit in magnitude. A more detailed analysis is in order, but my conclusion is the light comes on early and is not centered on the digit.
 

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
Is the disk accurately balanced, or do any additions affect balance?
Is the jitter periodic or purely random?

Best I can figure how to get it. But maybe not good enough? I have a magnet on one side. A screw and nut on the other. They are so light I am not certain they are the same weight. I have a small mail scale but doubt it is sensitive enough to weigh the magnet. I tried making a balance but did not have a whole lot of luck. I might try again.
 
Top