Sampling Hz increase 8

[FeX32]

Hey guys,

I have a straightforward question.
I have a DAQ system that can sample at 10,000 Hz max. I now have an application that requires 20,000Hz sampling.
There are several unused ports on the DAQ system. Is there a way to obtain an effective sampling of 20K Hz with the current system? Or an approximate method? Thanks,

Fe


"Simplicity is the ultimate sophistication." L. da Vinci
- Gian

 

[MacGyverS2000]

Can you offset the time at which each channel samples compared to the others? If so, a bit of scripting on the resultant capture files to interlace the values would allow you to do it.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[FeX32]

Thanks Dan. I had a similar thought. Unfortunately, I cannot offset the channels.
I thought someone might know of some other method. I know it is not likely though.

I am measuring rotary speed. My other alternative it to mechanically reduce the speed. Unless there is some electrical circuit I can use for this.


"Simplicity is the ultimate sophistication." L. da Vinci
- Gian

 

[MikeHalloran]

How fast is the object turning? In ... revs/ minute, remember. 20,000 rev/min is only 333.3 rev/sec.

Come to think of it, sampling is kind of an awkward way to measure rotational speed. It would be more direct a fit a one-bit encoder of some sort to give you a pulse at every revolution, and just hook that to a counter and a timer.


Or maybe I am misinterpreting the problem, as sometimes happens.




Mike Halloran
Pembroke Pines, FL, USA

 

[FeX32]

Thanks Mike.
It's rotation upwards of 20K rev/s. So Ideally I would need >40K sampling. But I would like more than one sample per revolution to measure small variations in angular acceleration. It's an automotive application. This is something I am doing on the side (not part of my job). So I didn't want to have to purchase a more advanced daq setup. I have something similar to this:

http://performancetrends.com/dtm-hdwe.htm

I think I will just have have to step down the rpm, hopefully without too much loss of inertial accel.

Come to think of it, sampling is kind of an awkward way to measure rotational speed. It would be more direct a fit a one-bit encoder of some sort to give you a pulse at every revolution, and just hook that to a counter and a timer.

My only issue is logging the very small time increments accurately.


"Simplicity is the ultimate sophistication." L. da Vinci
- Gian

 

[FeX32]

I thought about trying to setup a raspberry Pi to log some data. It's logging speed may be able to keep up. But I never seem to have the time.

 

[itsmoked]

Boy Mike.. I have NO idea how you decided (correctly) that this had something, anything, to do with rotation.

FedX32; Your DAQ system is not going to work as you realize.

Are you just looking for data or actually trying to control with it?

Keith Cress
kcress -

http://www.flaminsystems.com

 

[FeX32]

Thank you Keith. I'm just looking to gather some data.

 

[IRstuff]

Typically, rotational speed is measured through counting of something correlated with one complete rotation, like a Hall sensor. A DAQ is just not the sort of thing to use to count rotations, unless they are more like 1/5 of the sample rate. Rather than slowing the system down, perhaps you can use the rotating object to drive something that gears or otherwise reduces the speed, like a gear. If you can get a 10:1 or 20:1 reduction, then your DAQ stands a chance of getting you reasonably accurate rotation speeds. Otherwise, using a Hall sensor would be the more conventional approach.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[FeX32]

I agree IRStuff. Thanks. That was also my first thought, to simply reduce the speed via a gear train and simply measure that instead of the original system.
I was just thinking I that if there is a way for me to avoid making this extra reduction system, it would save some time. I will also then have to take into account the inertia of the extra system too. The prime mover is an IC engine.

My experience with daq systems thus far have only been at work where we have state of the art stuff. Sampling freq. was never a problem really.

Oh an I was also considering a pulley system at 1:5, but I am concerned about belt flexibility affecting the results.

After this I thought that if I use 2 (or more?) ports, say one on opposite ends of the rotating disc/shaft I could somehow effectively increase the sampling rate by a recursive averaging algorithm. Say taking into account which 1-bit input is triggered. For example, if they are triggered in order, then the rotation is below the max sampling of the system, or if one is triggered and then the second is not, following by the first, this would indicate that the speed is above the max sampling.

I thought that there might have been some work done on this before. I guess not really .
Thanks guys.

 

[IRstuff]

I'm guessing you've just got to use that DAQ?

One option is a magnetoresistive rotation sensor:

http://www.nxp.com/documents/application_note/AN98087.pdf

that is then fed into a frequency to voltage converter than can be then read by your DAQ. Of course, by that time, you could just get a digital frequency counter to read the MR rotation sensor. An optical encoder would do the same, but there are constraints on lighting, contamination, etc.

Is there a way of tapping into whatever is causing the rotation? I'm thinking you have some sort of motor driving whatever it is. Most AC motors are commutated from the outside, so hanging a frequency counter on one of the windings and dividing accordingly would get you the rotation speed.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[MikeHalloran]

Keith: 'rotary' in Fex' second message.

Well, now I'm curious.
20,000 r/sec is 1.2 million RPM.
Turbos don't go that fast.
Gyroscopes don't go that fast.
I know of no way to mechanically reduce that speed.
I must have missed another meeting.

Hall effect may be too slow, and you can't just strap a magnet on with a hose clamp.

If it has a single feature that's at all shiny, you can use an optical retroreflector to get a 1/rev signal. From there, I think you can put a phase lock loop on the pulses, and watch the error signal to see rotational accelerations.





Mike Halloran
Pembroke Pines, FL, USA

 

[FeX32]

Mike,
Thank you.
I'm looking to accurately measure the rotational speed of a shaft (and accompanying flywheel and other.) driven by an IC motor. It is geared so that the speed of the shaft is quite high. The end result is part of a side project I'm working on. I'm sorry, but I can't say too much more. Only that the instantaneous pulses of the IC motor are one of my interests.

Seems the main issue with this is accurately logging the rotational speeds. I guess if I directly use a rotational encoder, instead of sampling at a frequency, I will have to look into correlating the error in the signal to accelerations. Thanks.

IRStuff,
Thanks. The magnetoresistive rotation sensor option looks promising. I may just setup an optical encoder and try some post-processing.
I hope that the datamite can keep up with the high speeds of the system though. I would imagine that the datamite's circuitry may be the limiting factor. I guess I will have to see.

At least now I know that sampling at a frequency is not really the way to go.

Thanks guys!

 

[itsmoked]

Thanks Mike.

Fed have you considered an oscilloscope? That's a cake-walk for them. You could even see the dither you're seeking.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[SomptingGuy]

Note that the magnetoresistive sensor gives a nominal sinusoidal output when targeted at moving gear teeth. Instead of just counting zero crossings to estimate gear position, it's possible to estimate the instantaneous phase of the output at a frequency that's higher than tooth-passing (i.e. at each sample point). The gear teeth produce a carrier wave. The base frequency of that wave can give the mean shaft speed. Demodulating it can give the deviations from mean speed. If I remember correctly, the Matlab code for getting a phase ramp (increases 1.0 per gear rev) from a raw tooth signal is something like:

ramp = unwrap(angle(hilbert(signal))) / (nteeth*2*pi);

Missing teeth can cause a problem - an interesting one.

- Steve

 

[SomptingGuy]

... we used inductive sensors, like these:

http://www.blunikracing.com/eng/c/product/product/12/sonda_inductiva.htm

They produce quite a high voltage when close to a typical automotive gear (like a flywheel ring gear).

- Steve

 

[VEBill]

"20,000 r/sec is 1.2 million RPM"

The word 'grenade' comes to mind. Look at the safety cage used on this recent 1 million RPM world record (2008) electric motor.

LiveScience 'New Spin Record Set: 1 Million RPM (November 14, 2008)

Now 1.2M RPM is being applied? Wow... F1 motorsports?

---

If one simply measures the period, counting a clock between one reference pulse (perhaps an optical sensor) per revolution and the next, then one would have a new data point every 50us. That's already a flood of data. If one needs more frequent data about the system, then arrange for multiple reference pulses per revolution.

One must consider the required clock frequency. If one uses (for example) a 10 MHz clock, along with ten pulses per revolution (as from gear teeth for example), then one is only counting about 50 clock pulses between the teeth. So the temporal resolution is terrible. One will need a much faster clock, hundreds of MHz minimum.

If one demands this sort of detail, then one will be dealing with pretty high clock frequencies, and a flood of data. It's all doable, but non-trivial.

A completely different approach would be to simply use an oscilloscope to view the reference pulses (N per revolution) signal from the shaft. If there's any significant acceleration variation, then the pulses would be moving around. If they're steady, then the RPM is stable even within one revolution. One might even be able to trigger from the drive for synchronous exploration. A very simple check using a cheap 'scope.

 

[FeX32]

Keith,
Thanks I have not considered an oscilloscope. I will look into it, as long as I can somehow gather the data.

Steve,
Thanks for the info on magnetoresistive and inductive sensors. I will for sure look at these. Seems like the main advantage would be to estimate the output at a frequency higher than sampling.

I think I underestimated the complexity of dealing with such high rotations. But, should be alright to at least estimate what I want.

VE1BLL,

One must consider the required clock frequency. If one uses (for example) a 10 MHz clock, along with ten pulses per revolution (as from gear teeth for example), then one is only counting about 50 clock pulses between the teeth. So the temporal resolution is terrible. One will need a much faster clock, hundreds of MHz minimum.

Thanks. I also was thinking along these lines. I need to make sure the clock speed of the hardware is quick enough.
Oh and unfortunately this is not for F1 . I wish it were, haha. I stayed up late last night to watch the China qualifying.

I think I have enough info to go upon now. Should I run into issues I will for sure chime back.
Worst case is I can add a low inertia mechanical reduction and correlate it back to the original speeds. Thanks guys.

 

[Skogsgurra]

The resolution can be easily improved. All you need to do is to count a number of revolutions, say as many revolutions as there are in 10 milliseconds or whatever time period you tink is suitable. When you have reached end of the time period, you have two numbers: The number of pulses and the time it took to get them. The time resolution may very well be poor, but the longer time you measure, the better the resolution gets. Then divide number of pulses into time and get speed with high resolution.

It is trivial, actually. There is a report on this here:

http://www.gke.org/rapporter/files/Reciprok frekvensmetning 2.pdf

Sorry that it is in Swedish. But I think that the few formulae and pictures can be understood even without Googletranslate. With it you won't understand a word.

Gunnar Englund

http://www.gke.org

--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

 

[MikeHalloran]

Fex, you could use the IC engine's crank position sensor as a basic clock or trigger, and look at everything relative to that.

... until the gearing frags. I suspect you may have underestimated the cost/ difficulty/ technical challenges/ safety risks associated with transferring significant power at 1.2x10^6 r/min.

It's time to read up on scattershields. There was an article in the ME house rag maybe a decade ago about scattershields for energy storage flywheels. The post-scatter photos were seriously disturbing.





Mike Halloran
Pembroke Pines, FL, USA