I usually 'Instrument' several critical timing points in the interrupt code.

https://forum.allaboutcircuits.com/threads/project-ideas.143685/page-2#post-1330315

Sorry @nsaspook, after reading your linked post, still not sure; the "critical timing points" are actually inside the ISR? Do you always measure lattency of anyone against the very first, isn't it?

Now that I think of it, they do not need to be inside necessarily, right?

 

Hola @spinnaker

I believed it was a problem in my phone, but in my laptop I also see this:



Maybe just a video artifact?

 

Sorry @nsaspook, after reading your linked post, still not sure; the "critical timing points" are actually inside the ISR? Do you always measure lattency of anyone against the very first, isn't it?

Now that I think of it, they do not need to be inside necessarily, right?

I agree. I qualified my first latency comments with 'if the actual RPM doesn't change'. Mechanical timing variations are usually greater than ISR timing variations if the software (with hardware support) is written to minimize interrupt exclusion periods.

 

Hola @spinnaker

I believed it was a problem in my phone, but in my laptop I also see this:

View attachment 172008

Maybe just a video artifact?

No it is really happening. I think I need to lower the RPM. Someone else that did a similar project mentioned it was happier at a lower RPM even though it seemed to work fine at the higher RPM. I was not seeing this at the lower RPM. But it was slowed due to dragging which I think I solved. But trying to adjust the cheap eBay brushless motor controller that I am using has been a challenge.

 

Is the disk accurately balanced, or do any additions affect balance?
Is the jitter periodic or purely random?

I went for a bicycle ride on a beautiful but very windy afternoon (those head winds were killers). Had a chance to think about your post some more. I do have it balanced with one screw opposite the magnet. But I wonder if I need 3? One in each quarter with the magnet in the 4th?

 

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

My fault there. I meant when the code compiles, is it efficient, and are there any possibilities that it might not run with the same timing where you want it to? I was especially noting that you use 8-bit shifts in a number of places, and I was hoping that the compiler would handle those intelligently, and not give you a loop counting through 8 single-bit shifts. I always skim through a program's assembly listing and look for any places where a single line of C turns into a huge number of assembly instructions.

And if there are questions of mechanical balance, is it possible that the disk might warp or develop waves at high speed, and cause the magnet to have a variable height relative to the Hall sensor? If it did, you'd get variable timing in the actuation of your sensor, and the processor might try to correct it by changing the speed, and all your timing points would be affected.

 

I do have it balanced with one screw opposite the magnet. But I wonder if I need 3? One in each quarter with the magnet in the 4th?

You may also have to consider the aerodynamics of the assembly, considering its high rotation rate. Any geometric asymmetry might result in disk vibration and hence periodic timing jitter.

 

You may also have to consider the aerodynamics of the assembly, considering its high rotation rate. Any geometric asymmetry might result in disk vibration and hence periodic timing jitter.

Regardless of the application, I would go with the magnet and two other counterweights. Based on that a tripod is the most stable support.

Another thought is to use the same weight for each point. Using three identical magnets may be easier to balance. What would happen I’d you mounted two of the magnets with the opposite pole facing down? Would your sensor not see the “upside-down” magnets?

 

You may also have to consider the aerodynamics of the assembly, considering its high rotation rate. Any geometric asymmetry might result in disk vibration and hence periodic timing jitter.

I'll throw out another.

There are other drag forces here that might not be so obvious. You have a quickly spinning magnet attached to a disk platter in close proximity to conductors the lamp circuit board and a good conductor metallic disk drive housing. The flux lines of the magnet cut across the free charges in these conductors causing a induced EMF proportional to the rotational speed. The spinning disk will feel a force resisting that motion.
https://en.wikipedia.org/wiki/Lenz's_law

Lorentz force makes the charges move, thus inducing a current for a opposing magnetic field to that moving magnet and thus a drag force (energy is transferred from the disk rotation PE to conductor resistive KE (shorting the generator)) on rotation that varies depending on the geometry of the metallic surfaces below the magnet and any significant lamp currents flowing in traces (and magnetic fields) as the magnet passes above. How much of an effect this has on variations of rotational speed due to transient drag forces and the motor controller reacting to them is something you could find by experimental measurements but one thing is sure, for X configuration, weaker magnets, moving magnets away from conductors and slowing down the RPM should reduce the effect.

https://en.wikipedia.org/wiki/Faraday's_law_of_induction

This demonstrates the drag with a stationary magnet and moving platter but the Lorentz force doesn't care which one is moving.
https://en.wikipedia.org/wiki/Eddy_current#Explanation

 

Two others? You mean two in addition to the one I have?

Yes I could use magnets. I an face the opposite pole and it would not affect the sensor. But if I wanted to add another sensor a I would be stuck. Can't think of why I would want to do that but the design allows for it.

 

Another thought going on what Alec said is just vibration. I am going to add the counter weights to see if that helps.

It isn't the end of the world. If I need to go with optical I can do it.

 

I think part of my problem is my brushless motor controller. I can't seem to slow the damn thing down. I have one of these that I got from eBay.

@nsaspook , what are you using for a brushless motor controller? If it is your design, are you willing to share?

 

I think part of my problem is my brushless motor controller. I can't seem to slow the damn thing down. I have one of these that I got from eBay.

@nsaspook , what are you using for a brushless motor controller? If it is your design, are you willing to share?

I'm using original internal HDD motor driver on an old 2GB IDE drive. It works but won't run continuously because the disk controller times-out eventually for missing disk head data.

I'm using a HALL Magnetostrictive Sensor so the disk only has a small ferrous tab attached, not a magnet so I only have small induction drag effects near the sensor.

 

MUCH more stable. I think I still have some alignment to do but getting there. I swapped out brushless motor controllers and that seemed to help. I can slow the motor down a lot more and it seems more well behaved.

My problem with alignment is I can only align a whole frame and not the individual numbers in a frame.

Here are the frames.

/*
Frame

* 0 7,6,5,4,3,2,1,0
* 1 8,7,6,5,4,3,2,1
* 2 9,8,7,6,5,4,3,2
* 3 /,9,8,7,6,5,4,3
* 4 :,/,9,8,7,6,5,4
* 5 0,:,/,9,8,7,6,5
* 6 1,0,:,/,9,8,7,6
* 7 2,1,0,:,/,9,8,7
* 8 3,2,1,0,:,/,9,8
* 9 4,3,2,1,0,:,/,9
* 10 5,4,3,2,1,0,:,/
* 11 6,5,4,3,2,1,0,:
*/

 

Alignment issues continue to plague me. But at least I have the clock working now. After looking at the video I think the alignment issues are the source of the ghost images I am seeing.

Still need to add in time and date set, option to display time, date RPM etc. I don't have any buttons on the actual clock I decided the easier way to go is using Bluetooth. I might even develop an app for my tablet.

 

Made a little adjustment. I am fairly certain now the "ghosting" is due to alignment. Seems like when I get one number aligned another one goes out. I might not have the numbers aligned on the drawing as well as I thought.

 

Made a little adjustment. I am fairly certain now the "ghosting" is due to alignment. Seems like when I get one number aligned another one goes out. I might not have the numbers aligned on the drawing as well as I thought.

Excellent work.

 

Next step would be a 12 segment display . I can't do 14 segments unless I redesign the light board. I should be able to do 12 pretty easily. I would need to sit down and see if that works out. See what 2 segments can be left off and still be useful. Of course I could do 8 but not too much point to that.

 

I will probably have more updates but wanted to take the time out to thank the little people (just kidding ) everyone that gave advice on this project. I have worked with a number of the various chip peripherals before but this project really gave me a solid understanding of how they work. I think the hardest part of this project was trying to envision what is going on. The debugger helps but you really just can't use it to solve every issue.

There is still a lot of work to do. I need to finish the interface to set time and different features. also need to add battery for backup and implement power failure code to put the pic to sleep.