SPI Shenanigans

Arduino SPI Fun featuring ADS1298!

SPI Library

- SPI.setDataMode(SPI_MODE1);
  SPI.setBitOrder(MSBFIRST);
  SPI.setClockDivider(SPI_CLOCK_DIV4);

Different ways of communication we tried:
1) SPI.transfer(byte) only
We are not sure if this toggles SS before and after each byte sent. If this is so, then we cannot use this to send multi-byte commands.

2) digitalWrite(SS, LOW);
    shiftIn(dataPin, clockPin, bitOrder) or shiftOut(dataPin, clockPin, bitOrder, value)
    digitalWrite(SS, HIGH);

- According to the ADS1298 manual, we need a delay of >= 4 SCLK cycles before sending the next command. For our 4MHz clock this is 0.25uS * 4 = 1 uS.

Neither is working so far...

We can use analogWrite(pin, value) to generate an analog signal we can use to test the ADS1298 A-D coverter. *Only works on certain pins!

Some (maybe) helpful discussions on the TI forums:
http://e2e.ti.com/support/data_converters/precision_data_converters/f/73/t/188917.aspx
http://e2e.ti.com/support/data_converters/precision_data_converters/f/73/t/168648.aspx

SPI Connections we made to our toy A-D converter:

Threading

There is an excellent blog on threading in Python at http://www.tutorialspoint.com/python/python_multithreading.htm.

After reading this, I wrote some threaded code in thread_graph.py. It seems to work great!

(I chose to use the Threading module, not the Thread module, as recommended on the website, although it gives examples for using both).

Finally, in super_threading.py, I wrote some truly multi-threaded code with separate threads that are interdependent. That is the fastest code yet!

GUI Wrapper for graphing library

One problem we have with our currently python plotting (besides buffer overflow) is the lack of interactivity with the plotting window itself. Whenever we click the plotting window, it freezes up. The buttons for modifying the plot in matplotlib on work after the graph has finished plotting, which is useless for us since it will never be done. Therefore we need a GUI wrapper to contain our graphing module, that has buttons and other modes to interact with the plot. Daniel found a matplotlib example that uses the wxPython wrapper: http://eli.thegreenplace.net/2008/08/01/matplotlib-with-wxpython-guis/ , and Anand found a graphing module built from scratch using Tkinter, the "default" GUI library for Python: (insert link here).

The wxPython example requires wxPython to be installed, along with the following two lines to be placed before import wx:

import wxversion
wxversion.select('2.8')

SimPlot is another plotting tool, but it's just like Stamplot, so we don't think there's much use for it now.

Happy St. Patrick's Day!

Blitting and animating

Blitting Resources
http://stackoverflow.com/questions/8955869/why-is-plotting-with-matplotlib-so-slow

http://stackoverflow.com/questions/4222344/clearing-background-in-matplotlib-using-wxpython
http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg06565.html

Re-evaluating Library Options for Python Graphing

So we figured out that matplotlib by itself may not be optimal for real time graphing. We looked around and found the following alternatives:
wxPython + matplotlib (came with a piece of code, testing this now) Stack Overflow Post
- wxPython is a GUI wrapper for Python, which will supposedly make matplotlib faster

chaco: recommended by official Python page for real-time plotting
Some other possible options (last post on page):
http://pyqwt.sourceforge.net/
http://code.google.com/p/guiqwt/
http://luke.campagnola.me/code/pyqtgraph/

Another option is to store a fixed amount of data in a buffer and plot the contents at once, reducing the frequency of graph updates. To make the updates appear as smooth real-time plotting, we can animate the plotting. From our (Daniel & Anand) discussion, we concluded that the quality of the data updates will determine the quality of our ECG GUI, which we will measure by the following metrics:
- Smoothness: does the graph appear to be constantly updating, without any abrupt pauses
- sequential cycle: collect data --> plot --> collect --> plot ...
- this will work under the assumption that collecting data takes a negligible amount of time (ie. no pauses)
- if not, then we will have to look into multithreading (painful!) so that the updates will be smooth

- Delay: what is the delay between when the data is collected off the patient's skin to when it's displayed on the computer screen? ideally this number should be small, but more importantly it should remain constant (increasing means that data is accumulating in the serial buffer, very bad!)

- Data accumulation in buffer - 0, else we risk a buffer overflow as t --> infinity

Some possible algorithm designs considerations:
- Create a rotating buffer of two arrays. At any time, one is being plotted and covering up the other. During the first iteration, the array being replaced is empty, so there are no ugly effects from replacing a zero'd array.

-