1
$\begingroup$

I thought this was supposed to be an obvious question, until I finally set up my real time system.

So basically I have a transmitter that sends 128 samples/second to a receiver. The transmitted information is stored as an object in MATLAB and continuously updated.

When people talk about real time signal processing, I'm really confused as to what they mean by real time.

For example, say I want to extract the "mean" feature of this signal. Do I compute the mean when I receive one sample, two samples, all 128 samples, or ...what is this mean value?

More intriguing for me is the prospect of doing real time wavelet transform for joint time frequency analysis. Again, the question of "real time" comes up. How many samples do I need to reliable compute the wavelet (or fourier) coefficients so I could get a good view of the energy contained in this signal.

Can anyone who is knowledgeable on this topic please elaborate how when and under what condition do you compute "features" or perform frequency domain analysis for a real time system.

Thanks!

Improve this question
$\endgroup$

1 Answer 1

Reset to default
3
$\begingroup$

'Real time' is a concept from computer engineering. A real time system is one that is guaranteed, by design, to execute a function or routine in a certain time T, or less. For example, a real-time avionics system is proven to react to signals coming from certain instruments in a time below a given threshold.

In your case, a more precise description (IMHO) of what you want is a "streaming system". You want a receiver that can process a stream of incoming samples without "dropping" samples; in other words, without its buffer overflowing. The easiest way to achieve that is to provide large enough computing power that the probability of dropping samples is very small.

This property is largely orthogonal to the problem of estimating signal features. Since the incoming signal is random, its features are going to vary. You may need to calculate, or find by experiment, how many samples do you need to process to have a useful feature estimate.

For example, these days most, if not all, transmitted signals have no DC component, so the mean will be close to zero all the time (barring imperfections in your analog front-end). I wouldn't worry about updating the mean estimate very often.

In modulation recognition, in contrast, you may need a few thousand samples, and the processing could take some time. You may decide to do something like gathering 5,000 samples (which in your case would take ~40 seconds), and you may take five second to process them, so you'll be updating that estimate every 45 seconds or so.

As you see, it really varies by estimate, and you'll need to figure out the best number in each case, given your requirements and your processing resources.

Improve this answer
$\endgroup$
5
  • 2
    $\begingroup$ this is perhaps not the most objective (i had a piece in writing it), but Wikipedia has a reasonably concise definition for real-time signal processing which appears consistent with Baz's second paragraph. except i would say that true real-time would guarantee that once a buffer delay is set to some finite value, that "real-time" guarantees no samples dropped due to an overflowing buffer. $\endgroup$
    – robert bristow-johnson
    Oct 20, 2014 at 1:04
  • 1
    $\begingroup$ @robertbristow-johnson: That is a good definition, thanks for the link. I still prefer "streaming" to real-time when there is no hard guarantee (as happens in most applications). But that is just a personal preference. $\endgroup$
    – MBaz
    Oct 20, 2014 at 2:04
  • 1
    $\begingroup$ well, i would agree with you, M. if there is no hard guarantee (so hiccups are possible), i wouldn't use the term "real-time signal processing". $\endgroup$
    – robert bristow-johnson
    Oct 20, 2014 at 2:35
  • $\begingroup$ Hello, thank you very much for your answer I've learnt quite a lot already. I'm not familiar as to how people construct such a system, so are you saying that it would be necessary to first collect sample over one time period, and then compute the features, wavelet coefficient, etc? So that the data from the analysis of such real time signal would always have a time T delay to when the signal was actually received. $\endgroup$
    – Fraïssé
    Oct 20, 2014 at 6:06
  • $\begingroup$ I had this misconception because I've seen some video online showing the frequency plot and the time plot at the same time. So are you indicating that a plot such as aac-research.at/products/… can only be produced through post-processing of the recorded data and not in real time? $\endgroup$
    – Fraïssé
    Oct 20, 2014 at 6:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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