1

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?

PDuarte
  • 121
  • 4
  • How are you planning to capture 200kHz of samples with 20kHz bandwidth? – Jazzmaniac Jun 22 '17 at 10:54
  • @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? – Dan Boschen Jun 22 '17 at 11:17
  • @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. – Jazzmaniac Jun 22 '17 at 11:20
  • 1
    @PDuarte Does this post help you: https://dsp.stackexchange.com/questions/8488/what-is-an-algorithm-to-re-sample-from-a-variable-rate-to-a-fixed-rate?rq=1 – Dan Boschen Jun 22 '17 at 11:20
  • @DanBoschen Very interesting! I'll take a detailed look! – PDuarte Jun 22 '17 at 11:22
  • @Jazzmaniac Not sure how it implies that? It says "convert to a fixed sampling of 200KSa/s"...how does that imply analog bandwidth? It is just specifying the sampling rate, isn't it? The data rate is the rate of the samples after sampling (which is the sampling rate), it is not the analog bandwidth of the system. – Dan Boschen Jun 22 '17 at 11:22
  • @DanBoschen, maybe I have expressed my question not clearly. I was in fact hoping for a clarification about the actual data bandwidth, which remains unclear from the question. And a possible problem is implied by the fact that the original data acquisition rate is much higher than the sensor bandwidth. So in my eyes, clarification is required. – Jazzmaniac Jun 22 '17 at 11:25
  • 1
    @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? – Dan Boschen Jun 22 '17 at 11:32
  • @DanBoschen Correct! – PDuarte Jun 22 '17 at 11:34
  • @DanBoschen, ok, let me ask it differently. Is the designed data acquisition sensible? What is the actual bandwidth of data produced by the engine? Is the sensor bandwidth chosen appropriately? If not, is it a limitation of the sensor and how does it affect the reliability of the data? Is the sensor itself continuous or discrete time? If it's continuous time and bandlimiting, why is an extra resampling stage required? If it is discrete time, what happens to input data that exceeds the sensor bandwidth? Is the sensor clocked independently? Why is the final data rate chosen 10 times higher? – Jazzmaniac Jun 22 '17 at 11:37
  • Maybe I'm pedantic, but I actually want to understand if a problem is well posed and really understood before investing time in an answer. – Jazzmaniac Jun 22 '17 at 11:38
  • @PDuarte Interesting problem and interested in what you finally do. I haven't had to deal with this specifically but would be tempted to do a zero fill as in traditional interpolation (and eliminate samples above your 200 KHz rate as in decimation) and then pass the result through a digital filter with 20 KHz passband bandwidth. (Exactly as is done in traditional interpolation/decimation). This is a complete hunch with many reasons why it may not work, but just a thought as I could see that it might, assuming your samples are on integer sub-boundaries with your 200 Ksps rate. – Dan Boschen Jun 22 '17 at 11:45
  • @Jazzmaniac The sensor is analog, its bandwidth is from 0Hz to 20KHz, all bandwidth contains information that should't be lost. Regarding reliability, it's a correct sensor for the application. The extra resample is required because the signal processing must be done in a uniform data but the acquisition system only works with non uniform sampling. Fixed sample rate is necessarily high because post-processing system only works with 200KSa/s. – PDuarte Jun 22 '17 at 11:46
  • @DanBoschen, zero filling won't give you reliable amplitude reconstruction, because you would need an amplitude factor that is proportional to the instantaneous conversion rate. Zero order hold or linear interpolation are much better options. – Jazzmaniac Jun 22 '17 at 11:46
  • @PDuarte such that actual samples when they occur land exactly on a 200 KSps sampling location, and then when they don't occur you just fill a zero, all samples that at the higher rate above 200 KSps are simply ignored. If you sensor bandwidth is truly only 20 KHz and there is no presence of higher frequency signals, I think this could work. (as I said nothing I have tried or worked through) – Dan Boschen Jun 22 '17 at 11:47
  • @PDuarte If your sensor is continuous time (or 'analog' as you say), then why don't you just sample its output at the target rate? There is no need for rate conversion. – Jazzmaniac Jun 22 '17 at 11:48
  • @Jazzmaniac The reason I thought it might work is the significant difference in sampling rate to analog bandwidth; I would actually be surprised if the baseband spectrum was not created in the process of zero filling---- you could possibly view the variable rate as a summation of various fixed rates of the same system. But like I said have not tried or know so would believe it not be possible. – Dan Boschen Jun 22 '17 at 11:53
  • @PDuarte are the samples you get consistently on the 200KSps sample locations (except for the ones at the higher rates), meaning discrete in 5 us steps with missing samples, or completely at arbitrary locations in time? Also if the link I gave answers your question let us know as we should then probably close this one as a duplicate – Dan Boschen Jun 22 '17 at 12:02
  • @DanBoschen the samples are completely arbitrary in time since it depends only on an engine rotation speed. It's not guaranteed that I could find 200K sync samples so easily. Regarding the duplicated aspect I believe we could flag it, there's a good material there :) – PDuarte Jun 22 '17 at 13:44
  • although perhaps there is a simpler way--be great to know what you ultimately come up with. What confuses me is where you derive your sense of time for each sample. I assume this must come from your 200 KSps clock (or perhaps a higher rate clock?). In which case it is implied that your sample is assumed to be at those boundaries and a phase noise is then introduced by the delay between "truth" and your assumed time stamps. With high enough sampling that phase noise will not be a factor but certainly needs to be watched. Am I off track? – Dan Boschen Jun 22 '17 at 13:55
  • @DanBoschen You must have a reference for the incoming signal, otherwise it becomes impossible to locate it in time. Fortunately I have the timestamp of every sample. I wouldn't know how to proceed otherwise. – PDuarte Jun 22 '17 at 15:07
  • Comments are not for extended discussion; this conversation has been moved to chat. – Peter K. Jun 22 '17 at 15:41

1 Answers1

1

[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.

Community
  • 1
Laurent Duval
  • 31,850
  • 3
  • 33
  • 101