1
$\begingroup$

I'm facing a challenge that requires me to process a signal from an engine knocking sensor. The acquisition is done synchronously with the engine speed (every 0.1 degree) which gives me a range from 50KSa/s to 390KSa/s (related to engine speed range). The sensor bandwidth is 20KHz. My task is to convert this data to a fixed sampling of 200KSa/s for further processing in MATLAB. I'm working in this issue for some weeks now but I couldn't find any solution to it! Is there a common approach to such task?

$\endgroup$
  • $\begingroup$ How are you planning to capture 200kHz of samples with 20kHz bandwidth? $\endgroup$ – Jazzmaniac Jun 22 '17 at 10:54
  • $\begingroup$ @Jazzmaniac There is no issue with sampling a system at a higher rate than its analog bandwidth, in fact that is preferred to avoid spectral folding. Does that make more sense now? $\endgroup$ – Dan Boschen Jun 22 '17 at 11:17
  • $\begingroup$ @DanBoschen, I'm very well aware of that. The question however seemed to imply that there is an actual data bandwidth of 200kHz, which is intended to be sampled at that same rate. $\endgroup$ – Jazzmaniac Jun 22 '17 at 11:20
  • 1
    $\begingroup$ @PDuarte Does this post help you: dsp.stackexchange.com/questions/8488/… $\endgroup$ – Dan Boschen Jun 22 '17 at 11:20
  • 1
    $\begingroup$ @Jazzmaniac He wrote the sensor bandwidth is 20 KHz. This is the analog system bandwidth prior to sampling. The system currently samples at a variable rate, as fast as 390 KSa/s, and he wants to sample at a fixed rate of 200 KSa/s. Perhaps the confusion is in what you actually mean by "data bandwidth" if it is not covered by the analog bandwidth of the signal itself or the sampling rate used to sample that signal? $\endgroup$ – Dan Boschen Jun 22 '17 at 11:32
1
$\begingroup$

[WARNING, RUDE OPINION AHEAD] Engine people often record data in a speed-invariant fashion using angular sampling. I have been working in that domain for a while, and I bear with you. I have been testing the performance of $0.1$ CA sensors, most of them doing some weird and undocumented interpolation. I also have tested $6$ CA sensors, at the other end of the camshaft.

My opinion so far is that they don't match well, for different reasons, including the acyclic behavior of an engine:

  • some angular devices are crappy,
  • the analog filtering (if any) in the acquisition chain is not speed-dependent,
  • the speed cannot be assumed constant within a cycle, and even within a stroke.

    And the measurements can be quite uneven at both ends of a camshaft, indicating that in between, at each cylinder, depending on the engine organisation, you might have various effects. This is all the more detrimental with noisy knock sensors : their spec sheets are often imprecise, their calibration is often neglected, etc.

I have concluded that in a standard speed range (1000-4500 RPM), a precision below 0.2 CA is (often) meaningless. And at high speeds, 0.5 CA is doubtful.

So :

  • if you only have 0.1 CA data, do the simplest interpolation that copes with the processing you need. A simple LS interpolation (linear, splines) could do the work
  • if you have access to the angular timing for raw files, get rid of the spikes, and use it directly have a non-uniform sampling (but don't forget you only see it from one end of the shaft)
  • if you have data models, plug them into some super-resolution tool. -if none of the above, well...

I'd suggest a track anyway, that I did not push to the end (so be careful): try to bound or to "probabilize" uncertainties: speed variation, quantization, filtering, etc. From the given measure, make a fuzzy measurement, ie a simulated multivariate object, that will go through further processing, which can give you a rough approximation of uncertainties pertaining to subsequent processing.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.