Brainstorm for a high resolution, high speed, synchronous rpm sensor

Go To Last Post
47 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

 

I'm looking at a project that requires high resolution measurement of the rotational speed of a shaft, that is spinning at up to 15,000 rpm (250 revs per second).  That shaft will have 6 (for now) trigger teeth on it (likely to be optical sensed), and so i need to provide a counter that can time the passing of those stream of teeth, and do so without gaps (ie every tooth interval is timed)  That data will be spat out on a 1Mb serial link for recording and processing by a separate system.

 

 

Now, with 6 teeth, at 15krpm (ie 4ms per rev), that means a tooth interval will be 666.667 us.  That is a decent time interval, certainly enough to spit out the data etc.

 

My current consideration is to gate the pulses from a 10MHz clock (OXO) into some form of counter, using the tooth pulses to open and close that gate.  At each tooth edge, that counter will have accumulated counts of 100ns, making it easy to calculate the time interval between teeth, and hence the average velocity of the shaft.

 

 

The question, is really how to do the counter and gating?

 

With a 10MHz clock, a normal AVR can juuuust  (if clocked at 20MHz) about count the incoming pulse stream, but with only a 16b counter, software will be required to keep track of overflows, and because each tooth interval must be counted, i think there could be significant jitter where the software has to access and reset the counter whilst new clock edges continue to stream in every 100ns  (high time for a 50% duty will of course be just 50ns).

 

Alternatively i could use external counting hardware and latch on each incoming tooth edge a snap shot of the parallel output for the micro to grab?  To get down to say 100rpm (which would be nice) i'd need a 20 bit counter assuming a 10 Mhz clock)

 

 

Anyone have any better ideas?    (one option is to use a different micro, i could easily use a STM32, as i use those for other projects, but i'd have to go read up to see how it's counter work and the likely jitter etc)

 

 

(BTW, this is for a one or two off, non production/commercial solution)

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SN74LV8154   looks useful!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can almost do this with an ATmega2560.  It has four 16-bit timers with

input capture.  Unfortunately the other two (8-bit) timers do not.  If you

don't mind a little jitter on the other two you can use external or pin change

interrupts for them.

 

--Mike

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you wanting to measure only RPM or is position count (revs from start) as well?

If RPM only, I would use input capture on T1 using rising edge to get tick period rate.

Then you can read the IPC reg at your leisure, convert to RPM and send.

Let the timer do the hard part....

 

 

Jim

 

 

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

Last Edited: Tue. Oct 16, 2018 - 07:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the minimum RPM?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

max_torque_2008 wrote:
With a 10MHz clock, a normal AVR can juuuust  (if clocked at 20MHz) about count the incoming pulse stream, but with only a 16b counter, software will be required to keep track of overflows, and ...
megaAVR 0-series Event System (EVSYS) can switch a TC overflow signal into the next TC's trigger input.

Likewise with all XMEGA; XMEGA adds a quadrature decoder to the event system.

XMEGA B has a segment LCD controller for display of RPM to the machine's operator.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

max_torque_2008 wrote:
... where the software has to access and reset the counter whilst new clock edges continue to stream in every 100ns  (high time for a 50% duty will of course be just 50ns).
XMEGA can DMA data into a TC.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

max_torque_2008 wrote:
a tooth interval will be 666.667 us. That is a decent time interval, certainly enough to spit out the data etc.

Now, tell more about that.  Tell what precision and accuracy you would like to measure that interval.  If, say, "to 1 microsecond" then when things are slow it will be many many microseconds.  Let's make it easy on you and say you are going to send a 16-bit binary value.  So that would be two USART frames of 10 bits each, or 20 bits.  1Mb link?  And the other end will be able to swallow it? 

 

I don't see why an AVR's input capture in a polled loop, stuffing the result into the USART, wouldn't work.  If you give clean signals why do you need gates and external clocks and all that fussing?  I suppose since you posted in GE forum the sparkies will need to dream up something with flux capacitors and such.  Clean up up your input signal and run it into the ICP pin.  There is no electronics involved in having previous and current counts in register variables, doing the subtraction, and shipping off the result.  All [?] modern-model AVR USARTs are double-buffered in the transmit direction.  Heck, since you know that UDR is clear you don't even need to look at UDRE. 

 

 

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:
What is the minimum RPM?

Indeed a consideration.  One should count overflows on the ICP timer and "loss of signal" after more than one.  To really consider the "minimum" question, one needs to know the desired precision. 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

a dual 16b counter

SLG46120 has up to 22 bits of counter at slightly less in price and is OTP.

Similar for cPLD or FPGA but those would be a force solution though will work and are flash programmable.

 

http://www.ti.com/product/SN74LV8154

https://www.dialog-semiconductor.com/products/slg46120

via https://www.dialog-semiconductor.com/products/configurable-mixed-signal/greenpak

https://www.avrfreaks.net/forum/icestorm

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want an average velocity of the shaft, why do you need to count time between every tooth? Is the "separate system" able to correct rotation speed at that rate?

Just count number of teeth (pulses) per constant period of time. You can make as big resolution as you wish simple by selecting an adequate time period.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

max_torque_2008 wrote:
That data will be spat out on a 1Mb serial link for recording and processing by a separate system.
fyi, a new product by the Linear Technology part of Analog Devices :

Analog Devices

LTC4331 Datasheet and Product Info

I2C Slave Device Extender Over Rugged Differential Link

http://www.analog.com/en/products/ltc4331.html

IIRC, 1MHz at 30m over Cat5.

It's a bridge so it's not multi-master (iow, not a bus extender)

max_torque_2008 wrote:
(BTW, this is for a one or two off, non production/commercial solution)
a proof-of-concept ... your preferred MCU's development board with an attached PCBA for I/O.

 


ETA 29-Oct'18 though the other two on order are well into '19 :

https://www.mouser.com/ProductDetail/Analog-Devices-Linear-Technology/LTC4331HUFDPBF?qs=sGAEpiMZZMuH431S2KcKU6stnOovFArQu2%2fYHYqf8%2f4%3d

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
a dual 16b counter

I still don't see how adding e.g. that counter chip is going to provide anything to help OP;s timing of each tooth interval and sending results over a serial link.  Similarly, what help is an I2C bus extender?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Similarly, what help is an I2C bus extender?
It's cool! smiley

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

max_torque_2008 wrote:

... will be 666.667 us.  ...

My current consideration is to gate the pulses from a 10MHz clock (OXO) into some form of counter, using the tooth pulses to open and close that gate.  At each tooth edge, that counter will have accumulated counts of 100ns, making it easy to calculate the time interval between teeth, and hence the average velocity of the shaft.

 

The question, is really how to do the counter and gating?

 

With a 10MHz clock, a normal AVR can juuuust  (if clocked at 20MHz) about count the incoming pulse stream, but with only a 16b counter, software will be required to keep track of overflows, and because each tooth interval must be counted, i think there could be significant jitter where the software has to access and reset the counter whilst new clock edges continue to stream in every 100ns  (high time for a 50% duty will of course be just 50ns).

Instead of gating, and counting, look at capture.

That way, your CPU sysCLK is the timebase, and no need for 20Mhz / 10MHz juuust ok stuff.

 

You can even simplify your counting, by sending on timer overflow, as well as capture.

The host then manages the 16b overflows, and very low RPMs send overflow tags at 10M/2^16 or 20M/2^16  (~6ms or ~3ms)

 

If you mentioned OXO, you will need a mcu Eval board with an external clock ability.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As speed doesn't instantly change drastically, one can send just the difference from the previous reading to keep packet size down.

 

I still want to hear about the other end that is going to receive and swallow and do something useful with over 1000 sps, to a very fine resolution.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure what the challenge is..the sensor only generates about 15000/60*6=1500 pulses per second....Rather slow

Any timer, such as in a tiny13, can be counting along at 10, or maybe 20MHz. Overflow Irq's extend the count range to any number of desired bits.

 

The encoder pulses merely generate an edge irq which grabs the current time value for use in doing whatever is to be done........Since time must rollover, due to limited number of time bits, the result might best be represented as a delta from the previously grabbed time.  As previously recommended, using an "input capture" mode device allows capturing the current time lsb's (from timer registers) automatically with reduced jitter effects...the extended (overflow) msb's can be grabbed manually, with lower immediacy concerns.

 

Of course 20MHz, might not give enough "high resolution", compared to your typical 8 digit frequency/period counter...1500Hz at 20MHz timebase gives a max interval count of 13333 (1 part in 13000 resolution, about 4+ digits).  This can be artificially extended using mathematical processing of the results.  Some AVRs have an onboard PLL multiplier to generate higher internal freqs for the timers, improving the available time resolution. 

 

has to access and reset the counter whilst new clo

Don't reset anything manually...since you do that as a reaction to some notification, the resetting response will introduce it's own jitter.  Let it rollover. No need to ever reset & thus completely avoid that potential pitfall   

 

Depending on your range of speed (is it nominally steady?), you could change your timebase settings, sort of an auto range. Then at slower motor speeds (longer intervals), the count values don't get too extreme in size.

When in the dark remember-the future looks brighter than ever.

Last Edited: Wed. Oct 17, 2018 - 12:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you familiar with variable reluctance sensors?

https://en.wikipedia.org/wiki/Variable_reluctance_sensor

These are made of a magnet with an inductor wound around them.

They are sometimes called "gear tooth sensors"

When a piece of steel gets near the magnet, the magnetic field strenght changes, which is picked up by the inductor.

These are common sensors and multiple manufacturers make IC's to process the inductor signal into a nice digital output.

A variant of these sensors work with 1 or 2 Hall sensors. With 2 hall sensors you have a phase shift which results into a 2-bit grey code ouput to sense direction ( I believe Honeywel makes these).

Some variants described in: https://en.wikipedia.org/wiki/Wheel_speed_sensor

 

I would very likely also use "capture" mode of a timer.

With an AVR @ 20MHz, program a counter to run at F_CPU.

In your 666us interval the counter will have counted to around 13000 which gives a nice resolution for speed measurement.

Do not reset the counter, this will introduce jitter.

If you generate an interrupt on each capture event then you can calculate the captured timer value with the previously captured value.

The difference between the 2 numbers is your current speed.

By calculating the difference (New - Old) between 2 values the overflows of the counter are automatically corrected.

 

You could program a timer to reset on a positive flank, and capture on a negative flank, but this will have a (much ) maller measurement interval and thus lower resolution.

 

You mentioned STM32.

STM32F103C8T6 has hardware for quadrature encoder inputs which may be handy if you want to keep track of long term position.

You could use 2 timers. 1 for capturing the speed and another for counting (long term) pulses, but you can also count the pulses by incrementing a global variable in the ISR.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unless your rotating mechanical system has a lot of mass, you might find yourself measuring torque ripple. Especially on an internal combustion engine as compression slows and ignition accelerates the crankshaft.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The application is a high speed dynamic torque / speed measurement system for electric machine test. (i can't go into exact details)

 

I need to measure rotational speed to +-1rpm at 15krpm at a minimum of 60 degree intervals.

 

(synchronously on each tooth edge the processor is going to also grab an analogue torque signal from a precision high speed torque sensor as well)

 

 

Using an external 32b counter means i can run with a very fast clock (up to 40MHz with the IC i mentioned) and still capture data at low speed as well without overflows.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

max_torque_2008 wrote:
I need to measure rotational speed to +-1rpm at 15krpm at a minimum of 60 degree intervals.

 

So the measurement has to be instantaneous and with an accuracy of +/-0.00667% or in other words +/-66.7 ppm?

 

How accurate is a 20MHz crystal? How much does it vary over time, temperature, voltage etc?

The built-in clock surely is far from good enough!

 

You'd have to add the accuracy of the trigger teeth into your equation also; is it reasonable to assume that the accuracy is better than 67ppm?

Also you'd have to think about how accurately you will be able to measure a tooth passing by your sensor!

Will it trigger reliably in the exact same location every time or will there be slight variations?

 

Everything will sum up to a total system accuracy and I think it will be hard to achieve an instantaneous accuracy of 67ppm.

 

However if you can let the shaft rotate a few rotations and count how many teeth will have passed in a few fractions of a second, your life will be a lot easier!

- Brian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Using an external 32b counter means

No need for any external counter, one can be made using the internal timer & overflow interrupt...add as many bytes (bits) as desired.  You could even program a 256bit counter. 

You could probably squeak by with 20MHz (1.1Hz resolution@15000)...at lower speeds you have more counts & better resolution.  Probably a good starting point.

The xmega's can be clocked at 32MHz

 

 

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

max_torque_2008 wrote:
The application is a high speed dynamic torque / speed measurement system for electric machine test. (i can't go into exact details)
Yet another example of a question for feedback for ideas from very incomplete set of specifications.

 

If you are in doubt of how to take rpm measurements, then I am in doubt in your ability to seamlessly integrate it with your other sensors.

This also leaves us guessing as to questions of the internal combustion engine from #19 etc.

 

Do you really think that the system you are designing is something new and has not been done 100's of times before worldwide on different uC archtitectures, sensor combinations etc?

 

 

 

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

what?

 

I asked here cause you know, people might have some good ideas worth using, precisely because it's been done loots of times before!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And no, i won't be using the internal oscilator or a basic external one, i already have a 10Mhz reference source that is used for the phase shift torque sensor.  Alternative i'll use a calibrated OCXO or similar. For this application the absolute accuracy (ie calculation of true rpm) is less important than the measurement of torsional vibration, ie the change in speed vs time (or angular displacement)

 

And yes, i realise the accuracy and jitter of the tooth sensor (and the physical profile of those teeth themselves) is important. The sensor is a high speed optical sensor, and the trigger wheel is "learnt" by the system during an unpowered (non driven) coastdown of the rig.  Those small timing differences as a result of the machining of the trigger wheel geometry are corrected out by the software.  (sensor latency is not an issue because the precise location of the trigger event (in the angular domain) does not matter (because the torque sensor does not have sufficient bandwidth to be able to coherently measure torque precisely in-phase with the trigger.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An no, there is no "Internal combustion engine" involved (i have never said there was, other posters mentioned it) and yes, i can't just average out many cycles to get an average velocity (as mentioned) i need an instantaneous speed measurement 6 times per revolution at between approx 100 rpm and 15,000 rpm to within +- 1 rpm at all speeds (obviously trivial at 100 rpm)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

max_torque_2008 wrote:
... measurement of the rotational speed of a shaft, that is spinning at up to 15,000 rpm ...
wow ... best I could quickly find at Mouser was 8000 rpm.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

Using an external 32b counter means

No need for any external counter, one can be made using the internal timer & overflow interrupt...add as many bytes (bits) as desired.  You could even program a 256bit counter. 

You could probably squeak by with 20MHz (1.1Hz resolution@15000)...at lower speeds you have more counts & better resolution.  Probably a good starting point.

The xmega's can be clocked at 32MHz

 

 

You can concatenate two 16 bit timers and using 32 bit input capture. This will give you RPM to under 100RPM.

 

From XMEGA E5:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

angelu wrote:

You can concatenate two 16 bit timers and using 32 bit input capture. This will give you RPM to under 100RPM.

From XMEGA E5:

 

Good point, can new 0-series parts like Mega4809 achieve the same thing ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

Good point, can new 0-series parts like Mega4809 achieve the same thing ?

 

The problem with Mega0 series is the clock and lack of PLL. Since OP wants to use a 10MHz external clock, the counting resolution is limited. With XMega, it can get 30MHz with its internal PLL.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With XMega, it can get 30MHz with its internal PLL

According to Digikey, Xmega can accept a 32MHz xtal...but I didn't check the details  (none of the datasheets would download)

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Xmega can accept a 32MHz xtal...but I didn't check the details

I think the max is 16MHz but it can be multiplied internally.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
(none of the datasheets would download)
Sometimes after Microchip HQ COB their web site is partially inoperative (currently so)

An alternate source for datasheets are the distributors.

 

XMEGA A1U Xplained Pro - 32KHz crystal for XMEGA128A1U, 12MHz crystal for EDBG UC3A4

Similar for MattairTech's board but with pads for the high frequency crystal :

https://www.mattairtech.com/index.php/development-boards/mt-x1s-atxmega128a1-u-usb-development-board.html

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The more you tell us about the complete setup, the better advice we can give.

We might have ideas to improve implementations of stuff you already thought you knew and did not ask.

 

If accuracy is so important that you want (need) to adjust for errors on tooth placement tolerences then it seems like a good idea to intentionally put some asymetry in the tooth placement.

Do not put all teeth at 60 degree from each other, but for example 5x 59 degree and 1x 55 degree.

This guarantees that your tooth correction algorithm does not get easily confused.

Or if you can spare the hardware, add an "index" / 0 position sensor.

 

An ATMEGA can do the raw sensor measurements, but it seems you want to add a lot of intelligent computing. I think this project may benefit from a (significantly ?) faster processor.

 

I do not do much programming nowaday's, but some time ago I was tinking about adding another processor to my portofolio because the Atmega's were too slow for some applications.

Natural grow path seemed to be the Xmega's. Studied some datasheets and became enthusiastic about lots of added features.

Then I scratched my head and realized it was an almost completly different uC architecture from the atmega's I knew.

When I realized that I began to look further, and it did not take long to decide to use some ARM processor.

 

Out of curiousity I bought some "blue pills" (STM32F103C8T6) & ST-LinkV2 programmers / debuggers.

Extremely cheap,(Boards, / programmers / tools) which is nice as I'm only a hobby programmer.

Capabilities of this beast is equal or exceeds the capabilities of Xmega's.

(Multiple level ISR's / DMA / Quadrature / Motor timer / ...)

And the ARM processors have a much wider grow path than the Xmega's. They easily go to 300MHz or more.

Unfortunately there seems to be very little overlap between implementations of I/O and peripherals between different ARM manufacturers.

Had a look between ST, ATsam, Freescale, and some others, and even simple I/O registers were implemented differently.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use STM's 32 bitters for other projects, but this project doesn't need a load of computing power at the sharp end, because the data all gets fed up into a super duper FPGA based controller from National Instruments that does all the heavy lifting.  As such the device that does the counting needs to be fast but not that computationally powerful.

 

The target wheel already includes the necessary features to enable absolute angular determination, and the optical trigger is a custom high speed setup and is already used on another project (so is a known quantity)

 

I'll look at a cascaded 32b internal counter on the xmega

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about.... Feed your six sensors into a 6-input XOR chip and use the output

as the trigger for a single timer input capture.  At your maximum speed of 15k

RPM and a CPU clock of 10 MHz the timer will count at least 111 during this time.

The CPU will have a pretty good idea what rate to expect since the RPMs can't

change much from one pulse to the next.  So similar to how a PLL (phase locked

loop) works, have the CPU keep a predicted next_count and compare it to the

actual count measured.  Then send the delta along to the FPGA and also use it

to calculate the next predicted count.  The data would then look like: 0 0 +1 0 0

-1 0 0 -1 0 0 0 0 +1 0 0, etc.  Occasionally send the absolute value in case there's

some missed deltas.

 

--Mike

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

max_torque_2008 wrote:
I need to measure rotational speed to +-1rpm at 15krpm at a minimum of 60 degree intervals.

Geronimo wrote:
So the measurement has to be instantaneous and with an accuracy of +/-0.00667% or in other words +/-66.7 ppm?

 

Hmm! I make that 11ppm because you given yourself only 1/6 of a revolution in which to perform that measurement.

 

1/15000/6*10^6 = 11.1ppm

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:
Hmm! I make that 11ppm because you given yourself only 1/6 of a revolution in which to perform that measurement. 1/15000/6*10^6 = 11.1ppm

 

But also you have six signals per revolution, so wouldn't  the result be the same?

6*1/15000/6*10^6 = 66.7 ppm?

 

EDIT: You might be right though because the reading is every 1/6th revolution... Hmm, even worse!

- Brian

Last Edited: Thu. Oct 18, 2018 - 12:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

Using an external 32b counter means

No need for any external counter, one can be made using the internal timer & overflow interrupt...add as many bytes (bits) as desired.  You could even program a 256bit counter. 

You could probably squeak by with 20MHz (1.1Hz resolution@15000)...at lower speeds you have more counts & better resolution.  Probably a good starting point.

The xmega's can be clocked at 32MHz

Yes, at 15,000 RPM a 1 RPM difference equates to 44 ns, which would require about a 22.5 MHz clock to detect (or, as you say, 1.1 RPM (not Hz) can be detected with a 20 MHz clock).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
And the ARM processors have a much wider grow path than the Xmega's. They easily go to 300MHz or more.
252MHz for PIC32MZ EF for the industrial temperature range or 180MHz to 125C.

Four 32-bit timers by concatenating eight 16-bit timers (timers 2 through 9; timer 1 is for RTC or other uses including asynchronous)

Not much PIC32 is on-sale this month other than a SEGGER J-Link (IIRC its firmware is PIC32 only though) and a good price on the MPLAB XC32++ Pro toolchain.

There's a Curiosity board for PIC32MZ EF and a chipKIT.

 

Six 32-bit timers/counters (TC) in SAMA5D27 (500MHz) which can be in a module.

There's a bare board package for it and, IIRC, a few posts here about use of SAMA5 with that.

Might be of interest if porting functions from the National Instruments machine to the sensor.

 

https://www.microchip.com/design-centers/32-bit/pic-32-bit-mcus/pic32mz-ef-family

https://www.microchipdirect.com/product/DevToolDeals

https://www.microchipdirect.com/product/search/all/Curiosity

https://chipkit.net/wiki/index.php?title=MikroElektronika_Flip%26Click_MZ

https://www.microchip.com/wwwproducts/en/ATSAMA5D27C-D1G

https://www.microchip.com/wwwproducts/en/ATSAMA5D27-SOM1

https://github.com/atmelcorp/atmel-software-package

 

Edit: SAMA5

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Oct 18, 2018 - 07:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:

max_torque_2008 wrote:
I need to measure rotational speed to +-1rpm at 15krpm at a minimum of 60 degree intervals.

Geronimo wrote:
So the measurement has to be instantaneous and with an accuracy of +/-0.00667% or in other words +/-66.7 ppm?

 

Hmm! I make that 11ppm because you given yourself only 1/6 of a revolution in which to perform that measurement.

 

1/15000/6*10^6 = 11.1ppm

 

 

Of course, that 1rpm LSB likely comes from some middle manager, and if you make that 1 rpm per revolution, you can get the 66.7ppm

 

That said, anyone going to the trouble of designing a 32b time-reporting system, is not going to choose 66ppm, or even 10ppm.

± 10ppm is $1.27 1+ at digikey, and ± 2.5ppm is $2.36   ± 1ppm clipped sine is $2.91,  (or VCTCXO    19.2MHz   Clipped Sine Wave    3.3V    ±2ppm is $1.46/1)

 

Better than ± 2.5ppm usually means clipped sine, but you add a level shifter (eg 74AVC1T45)  or amplifier for clipped sine buffering.

A VCTCXO allows you to calibrate against a GPS standard

 

 

Last Edited: Thu. Oct 18, 2018 - 07:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

+-1rpm at 15krpm at a minimum

Maybe that really isn't needed, but sounded good for starters.  A lot of times desires/specs are dealt like cards, then when it becomes a no-win situation, the specs are revisited.    Sounds nice on paper to measure your battery to microvolts, but after awhile you find out that millivolts are plenty good & a whole lot easier.  Call it within 2Hz and you can use a std AVR.   

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
Call it within 2Hz and you can use a std AVR.   

When using capture mode, you could devise an algorithm that spits out a speed value every 60 degree, that is based on timings from the last 120 or 180 degrees.

But why spend the development time with so readily availability of 300+ MHz processors?

A 70MHz ARM is about the same price as a 20MHz AVR, and AVR seems to be getting troublesome ( = more development time) to get it to work reliably here.

 

But to what spec's would be really needed here, or are just noise from ignorant marketing monkeys is nothing more than speculation and guesswork for us.

 

As said before, High RPM with high accuracy necessitates a hich timer clock, but this easily leads to overflows with low rpm.

A software solution could be to extend the timer to 24 or 32 bits (haven't done the math).

Another software solution would be to clock the timer at a lower frequency for low RPM measurements, but this would introduce jitter when switching.

Anoter alternative is to use 2 timers. One clocked at a high frequency for High RPM, and another clocked with a lower frequency for lower PRM.

A hardware solution could be to add a higher resolution encoder for measuring the low speed range.

 

There is too much speculation going on here and not enough facts or real requirements.

What are the important parameters of this thing?

Is size important?

What is the global budget for this thing?

How about development time versus costs?

Low or high volume (number of units)?

Those are all important questions which should influence the development process.

 

In the inital post a 1Mb (speculation 1Mbps?) serial interface was mentioned.

Is the protocol fixed? What does it look like?

If it is not compatible with UsART / SPI / etc this could be a bigger problem than the RPM measurement.

 

But for some initial prototype, just get some development board of your choice, sit down and do some programming.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was looking into some Rotary Hall encoders (such as for example the AS5047D) and I accidentally bumped into:

 

https://www.rls.si/en/products/rotary-magnetic-encoders/incremental-encoders/lm13-magnetic-ring-encoder-system

 

This certainly seems to tick some of the right boxes for a "high-resolution-high-speed-synchronous-rpm-sensor"

Resolutions from 1,280 to 327,680 counts per revolution
High speed operation to 20,000 revolutions per minute

 

The pricepoint of that product might be a bit dissapointing for you, but it might be educational and give you some insight if you study what's in those kind of sensors.

But my suspicion is it is custom analog electonics, probably an ASIC, and / or FPGA.

 

Also:

You haven't said anything about your torque measuement, so I'm (yet again) guessing here.

The obvious way is a force sensor on a lever, another way is to use 2 encoders with a torsion bar in between to measure phase difference between the ends of the torsion bar.

 

Edit (A bit later):

Also from RLS I downloaded the datasheet of the am4096:

https://www.rls.si/en/am4096-12-bit-rotary-magnetic-encoder-chip

I was surprised that this 12 bit encoder chip works upto 60,000rpm. No price info though.

 

Then I went back to the datasheet of the AS5047d.

It quotes a maximum speed of 14500rpm and a dynamic angle error of 0.18 degree at that speed.

AS5047 is a USD 10 sensor available form Mouser / Digikey / etc:

https://octopart.com/search?q=AS5047D

https://www.findchips.com/search/AS5047D

 

Slightly off topic:

I had previous knowledge of those sensors, but the AS5047 popped up when i saw "mechaduino".

"Mechaduino" is a project where they use that chip to make a closed loop stepper motor controller.

 

And you probably have guessed by now that there are multiple manufactures of similar chips with different accuracies, speeds and prices...

Have fun.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Last Edited: Sat. Oct 20, 2018 - 08:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I actually have significant experience with various "high speed" angular position sensors including the 4096, from the last 15 off years of developing high performance motors (F1 kers, FormulaE etc)!  And in my experience, a lot of those sensors, whilst undoubtedly meeting their claimed specs 'on the bench' often seem to fall short in the real world, where noise, temperature, stray magnetic fields and vibrations all play a part.  Hence the use of a custom optical sensing system in this case........

 

 

Torque measurement is still TBC, either it will be an off-the-shelf inline high precision torquemeter (likely indeed to be a phase shift or contact-less strain gauge type arrangement), however, if i can get the speed measurement system to a suitable level of accuracy, then it becomes relatively trivial to add a torsion bar type drive and a second speed sensor and do the phase offset calcs within our supervisor system! 

 

 

Last Edited: Sat. Oct 20, 2018 - 01:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

however, if i can get the speed measurement system to a suitable level of accuracy, then it becomes relatively trivial to add a torsion bar type drive and a second speed sensor and do the phase offset calcs within our supervisor system

Right now you are working hard to get measuring/timing to 60 deg (360/6)...say the torsion/twist caused a 1 deg timing (phase) offset (twist might be more?)...you'd have to measure 60 times better! Of course, longer term avg of the offset might be possible, but you seem to be interested only in instantaneous readings.    15000rpm= 90000deg/sec   ...if you wanted to resolve 1/100 deg delta twist timing, that's resolving 1/9,000,000 sec ( 0.11uSec)  delta between two sensors.   It's prob doable, but perhaps not trivial.

 

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 With say a 20 MHz reference clock, giving 50ns time quanta, assuming we can measure tooth intervals down to +- 1 count (which is unlikely) that's an angular resolution of 0.0045 deg, easily good enough to calc a decent phase shift (in reality, the issues surrounding doing our own torque meter will i suspect revolve (pun intended!) around physical effects, such as hysteresis, bending, torsional vibration and whirl etc etc)

 

Right now i have a tooth trigger system that looks to have around 100ns of jitter (just over 2 counts with a 20Mhz clock) and a latency of about 200ns.  What i need to know is how does that latency change with target wheel speed!

Last Edited: Sun. Oct 21, 2018 - 12:52 PM