logo

Could not compile stylesheet for simplistic. Using last compiled stylesheet.

Real Time Problem?

posted in IGEP COM MODULE
Tuesday, May 28 2013, 11:33 AM
0
hello,
I have been working for a while with IGEP module and I am having some problems using the SPI interface.
I developed a kernel module that deals with the SPI interface with 4 ADCs (ADS1299). The main goal of this application is to develop a EEG acquisition platform with 32 channels wireless.
The problem starts with the analog signals acquisition. The ADS1299 has a configurable mode that delivers a test signal (square wave). In that mode I can make the correct acquisition with no problems. When I start to acquire analog signals, I start to have a lot of data corruption. In the image bellow, you can see a ECG signal acquired by IGEP module, and as it shows, I have that flutuation around the true signal. The configuration of the ADS1299 used with IGEP was experimented in another platform (mbed) and I had no problems in the acquisition.
I am using the 2.6.37 kernel with voluntary preemption. The module is using a threaded interrupt and a spinlock for the SPI transfers.
Is this a real-time problem? Can somebody help me please?.

Thanks in advance.
[attachment=0:1r1k4ydg]exemplo1.png[/attachment:1r1k4ydg]
Attachments:

Accepted Answer

Monday, June 03 2013, 12:44 PM - #permalink
0
hello,
Thanks for the answer.
I have already solved the problem, and in fact the problem wasn't with IGEP, but in the mainframe were the data was being "decoded".
Thanks anyway.

By the way, you guys in IGEP are thinking in a dual-core processor platform??? If this one with a single-core is great, a dual-core could be FANTASTIC!!!
The reply is currently minimized Show
Responses (5)
  • Accepted Answer

    Wednesday, May 29 2013, 09:01 AM - #permalink
    0
    Hi, The other platform uses the same driver and the same OS ? Can you provide a correct image ?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, May 29 2013, 01:15 PM - #permalink
    0
    Thanks for the quick answer, No, the other platform (mbed) is a microcontroller, so is totaly real-time. The hardware connections and the ADCs configuration are the same as with IGEP. The driver as already been tested in a Gumstix Overo Fire, and the final results were worst then IGEP (a lot more data corruption) althought the same fluctuation happens. Could this be a Real-time acquisition problem?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, May 29 2013, 03:21 PM - #permalink
    0
    Hello again,
    Sorry about the images...
    So the first one is the expected signal:
    [attachment=1:tdghlg81]real-signal.png[/attachment:tdghlg81]

    The second one is the acquired signal:
    [attachment=0:tdghlg81]Corrupted_signal.png[/attachment:tdghlg81]

    Any ideas about what is happening?

    Thanks in advance
    The reply is currently minimized Show
  • Accepted Answer

    Monday, June 03 2013, 09:20 AM - #permalink
    0
    Could be a RT problem, not sure, if the same configuration works with a microcontroller seems that also should work with IGEP. How the ADC is connected to the board ? It uses a interrupt pin ? Can you program the ADC to capture a batch of data ? BTW, can you try if modifying following kernel configuration option improves the results ? CONFIG_OMAP_32K_TIMER_HZ=1024
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, June 04 2013, 08:48 AM - #permalink
    0
    Yes, WIP ...
    The reply is currently minimized Show
Your Reply

SUPPORT


This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
IGEP Community Wiki
IGEP Community Forum
IGEP Community Online Chat