Slow UI response with long data acquisition time

[AliasAlreadyOnFile]

Hi all,

I have a question to ask more out of curiosity than necessity right now. I built a program that acquires data from an accelerometer and processes it in a number of ways - filtering, FFTs, FRFs, stuff like that but the UI response is always slow because I need a frequency domain resolution of 0.2Hz for my data, which means the sample acquisition time is 5s and everything waits for this before executing.

My question is this: Is there a way to completely isolate the UI from the data acquisition so that it responds immediately?

I tried a producer consumer design pattern with queues but found that everything was still waiting for the samples to be collected. Maybe it was just the way I did it.

Thanks

Phil 

[GerdW]

Hi idt,

use parallel loops to handle UI separately from DAQ!

[Bob_Schor · Accepted solution]

If you need to sample for 5 seconds in order to have enough data to analyze, then unless you can "predict the future" and "know" the next five seconds of data, you just have to wait for the data to arrive.  Using parallel Consumer-Producer loops will allow the data acquisition to proceed (to get the next 5 seconds of data) while you are doing the analysis, but you still need to wait for data to analyze.

Note that the preceding paragraph assumes you are collecting data in 5 second "chunks", and want to analyze each (independent) "chunk" as they arrive.  You could also do something like having a "sliding 5 second window" that moves, say, a second at a time, giving your FFT a finer "time resolution" (at the cost of their independence).  This would entail a (slight) change in your Producer loop (you'd want to sample in 1 second chunks, accumulate 5 such chunks) and Consumer Loop (start analyzing, spitting out an FFT every second, while replacing the oldest "chunk" with the newest -- a lossy Queue can do this for you).

Bob Schor

[Eric1977]

I agree with the last two posters. Look into the Producer Consumer design pattern. I strongly suggest using a Event Structure with this design pattern. I've had great success with this in the past.

[AliasAlreadyOnFile]

Thanks for your responses,

Bob, yes the data is collected in 'chunks' so even with parallel loops I found that everything is still waiting for the sampling. I thought that by using parallel loops the consumer loop could be made to loop as fast as I told it to and I could just use shift registers to have the current data going round and round until the next lot of data was collected, thereby allowing me to use the UI at a much faster rate than the DAQ in the producer loop - this was my aim but the general and producer-consumer design patterns do exactly the same thing - there's no noticable difference.

I think the problem is that the sample data is coming through the queue - the enqueue data is waiting for the data collection so the dequeue in the consumer loop just sits there waiting for the producer loop enqueue.

[Bob_Schor]

The idea of a Consumer Loop is not that it goes "as fast as you tell it to", but that it goes, on average, as fast as the Producer Loop.  The "on average" is important, because the loops don't need to be "locked together" -- the Consumer Loop can lag behind occasionally (for example, to do a particularly long calculation every once in a while), "catching up" when the long process ends.  If there is "nothing to Consume", the Consumer Loop simply waits, allowing other processes to run.