In Chamber Testing

[vex]

Oh believe me I know about samples and windowing. It's annoying as crap Hence why I asked the question.

As for the 3 million/min... why do you make me do math? I hate math! so you'd be sampling at 48khz unless you wish to avoid windowing then you'd need to sample at 96khz. Is the timing sensor hall or optical? (I'm trying to estimate the sensor error to guesstimate the perturbed error)

so your calibration uncertainty is 0.04% which ain't bad. If you can nail down the timing uncertainty it will be easy enough to get an uncertainty plot for the pressure distribution.

[Barry Bordes]

Originally Posted by vex

Oh believe me I know about samples and windowing. It's annoying as crap Hence why I asked the question.

You are over my head with windowing functions.

As for the 3 million/min... why do you make me do math? I hate math! so you'd be sampling at 48khz unless you wish to avoid windowing then you'd need to sample at 96khz. Is the timing sensor hall or optical? (I'm trying to estimate the sensor error to guesstimate the perturbed error)

The system, I think is 80Khz, and it uses an optical pickup.

so your calibration uncertainty is 0.04% which ain't bad. If you can nail down the timing uncertainty it will be easy enough to get an uncertainty plot for the pressure distribution.

Barry

[vex]

Originally Posted by Barry Bordes

Barry

Windowing occurs when you sample something too slowly and the result is a different reading altogether. For instance say you take a sample of a simple sine wave with a frequency (i'll keep it simple) of 4khz. If you sample that same sine wave at some other frequency that is less than 4khz you could get some surprizing results. Windowing would occur and you may end up looking at a cosine wave with a frequency of 2.3khz and a different amplitude that fluctuates over time. Not exactly what you're looking at? For DAQ's it is a good rule of thumb to sample at twice the frequency than what your expecting to be as your function. IE: if you are ever going to see 48khz in a function you'd want to sample double that to ensure you don't have window the function.

There is also another windowing occurance which usually helps in DAQ systems and is fairly easily explained in the following wiki article:
http://en.wikipedia.org/wiki/Window_function

[Barry Bordes]

Originally Posted by vex

Windowing occurs when you sample something too slowly and the result is a different reading altogether. For instance say you take a sample of a simple sine wave with a frequency (i'll keep it simple) of 4khz. If you sample that same sine wave at some other frequency that is less than 4khz you could get some surprizing results. Windowing would occur and you may end up looking at a cosine wave with a frequency of 2.3khz and a different amplitude that fluctuates over time. Not exactly what you're looking at? For DAQ's it is a good rule of thumb to sample at twice the frequency than what your expecting to be as your function. IE: if you are ever going to see 48khz in a function you'd want to sample double that to ensure you don't have window the function.

There is also another windowing occurance which usually helps in DAQ systems and is fairly easily explained in the following wiki article:
http://en.wikipedia.org/wiki/Window_function

Vex,

I believe the program will throw an error code when the data is not acceptable.

Barry

[scotty305]

Originally Posted by vex

For DAQ's it is a good rule of thumb to sample at twice the frequency than what your expecting to be as your function. IE: if you are ever going to see 48khz in a function you'd want to sample double that to ensure you don't have window the function.

I don't mean to be contrary, but I received the same 'sample at double the input signal frequency' advice from textbooks and some professors. Other professors with more real-world industry experience advised that data will be much more useful when sampled at no less than 5-10x the signal frequency. Try sampling a 100Hz sine wave at 200Hz, the plotting the results... it's not going to look much like a sine wave. If you logged a fuel injector its operating frequency, the indicated duty cycles would always be 0%, 50% or 100%... Personally I'd like to at least know +/-10%.


80kHz sounds like a very reasonable sampling rate. Assuming the sensor responds quickly enough, an 80k sample rate will give you one datapoint every ~0.5 eccentric shaft degrees at 6500 RPM.

Compare this to the RX-7 'crankshaft' position sensor which has one tooth every 30 degrees... I wonder if your ECU's ignition timing accuracy is better or worse than +/- 0.5 degrees? If your logger has a spare input it would be very interesting to monitor the ignition trigger signals in addition to chamber pressure, either by tapping into the 0/5V signal going from the ECU to the ignitor or by tapping the wire between the ignition coil and ignitor (careful, this will be over +20V due to inductive flyback... make sure the logger can handle it).

[vex]

Originally Posted by scotty305

I don't mean to be contrary, but I received the same 'sample at double the input signal frequency' advice from textbooks and some professors. Other professors with more real-world industry experience advised that data will be much more useful when sampled at no less than 5-10x the signal frequency. Try sampling a 100Hz sine wave at 200Hz, the plotting the results... it's not going to look much like a sine wave. If you logged a fuel injector its operating frequency, the indicated duty cycles would always be 0%, 50% or 100%... Personally I'd like to at least know +/-10%.

You're right. I forgot the word 'least' after at.