Best posts made by Will Dickson

@Will-Dickson

I swapped out R8 with 50 Ohm resistor to create a +/-12mA current range. I've attached a figure showing a fullscale range test with a 220 Ohm dummy cell. It looks good over the whole range.

@tmccaffr I think this would work. See the image below.

Resistors R9 and R12 set the current ranges for the transimpedance amplifier. Depending on the setting of switch3 (in firmware) you have either R12 alone for the transimpedance amplifier or R9 and R12 in parallel. The I-V jumper, which you mention, is in correct position. A resistor you put across this jumper will be in parallel with the other feedback resistors - so by adding a resistor you could reduce the sensitivity of the amplifier.

@Rodeo_First

The basic configuration for the dummy cell is just uses a single resistor. The PCB was designed to accommodate additional configurations e.g. a capacitor can be added to create dummy cells with different (dynamic) behavior.

@DavidL

Manual/Direct control mode will not be able to achieve as high sample rate as the firmware based tests which are paced by the microcontroller on the teensy 3.2. So your best bet for higher frequency sampling is to use one of the firmware based tests. Manual/Direct mode is paced via software on the PC and at each step it requires setting the voltage and then requesting the current. Each of these requires sending a command to the teensy followed by a wait for the response. This limits the sample rate quite a bit. In contrast, with the firmware based tests, the teensy just streams the data to the host PC - so we can achieve higher sample rates. The highest sample rate I can acheive with Manual/Direct mode on my PC here is about 60Hz (the results will probably vary with your hardware). Whereas with the firmware based test I can get 1000Hz.

If you are trying to measure the impedance of the cell - then I'm guessing you might be testing with sinusoids in order to put together something like a Bode plot (https://en.wikipedia.org/wiki/Bode_plot) ? If that is the case then maybe the firmware based 'sinusoid' test will work for you. This test outputs a sine wave and you can set the amplitude, period, phase (shift), offset, etc. I've attached an example below showing how to run the firmware based 'sinusoid' test at 1000Hz sample rate.

from __future__ import print_function
from potentiostat import Potentiostat
import matplotlib.pyplot as plt

port = '/dev/ttyACM0'

dev = Potentiostat(port)
dev.set_curr_range('100uA')
dev.set_sample_rate(1000)

name = 'sinusoid'
param = {
        'quietValue' : 0.0,
        'quietTime'  : 0,
        'amplitude'  : 2.0,
        'offset'     : 0.0,
        'period'     : 100,
        'numCycles'  : 5,
        'shift'      : 0.0,
        }

dev.set_param(name,param)
t,volt,curr = dev.run_test(name,display='pbar')

plt.figure(1)
plt.subplot(2,1,1)
plt.plot(t,volt,'b')
plt.ylabel('(V)')
plt.grid('on')

plt.subplot(2,1,2)
plt.plot(t,curr,'b')
plt.ylabel('uA)')
plt.xlabel('(s)')
plt.grid('on')
plt.show()

The above test outputs a sine wave with 100ms period, 2V amplitude (goes from -2V to 2V) and no DC offset. The data are sampled at 1000Hz.

Note, depending on your system you might start to drop samples above 500Hz - so you might want to examine the time points. This will usually happen with longer tests and high sample rates.

With respect to achieving even higher sample rates e.g. 2000Hz, the teensy 3.2 is definitely capable of it. However, achieving this would require some modifications to the firmware.

@DavidL

When re-programming the firmware make sure the "tools -> optimize" is set to FAST. Right now if it is set to FASTER, which is the default, there will be an issue with the ArduinoJson library.

This is something I'm going to fix soon - just need to upgrade to the latest version of the ArduionJson library and the problem goes away. Then the optimize setting won't matter. There is a little bit of an API change between the new and old version of the library - so I want to test a bit first.

@DavidL

I think that to get to higher frequencies you made need to do a bit more than just change the MinimumSamplePeriod. The MinimumSamplePeriod just sets how fast data is streamed back to the PC.

First, the voltage is set via the DAC in the testTimer callback. This timer runs are a frequency set by TestTimerPeriod (set in ps_constants.cpp). The value for this in the stock firmware is 200us - so 5000Hz. So with a 500Hz sine wave you will only have about 10 points per cycle. So you will probably want to decrease the TestTimerPeriod in order to get more points per sinewave.

Second, currently the output voltages for the sinewave test are set in a lookup table (see ps_sinusoid_test.h and .cpp) which is interpolated at intermediate time points. This isn't really optimized for speed - it is meant for lower frequencies where frequency of the sinewave is much less than the TestTimerPeriod. In the higher frequency case you may need to do this more efficiently - maybe just have the lookup table store the output values directly - so you don't have to do any computation and can just set the output voltage from the lookup table value.

Third, at higher frequencies streaming back the values during the test might not be feasible. The way we are doing it now - as JSON - definitely isn't the most efficient method. It is nice and clear, but not really meant for speed. So you might need to modify things so either the data is packaged more efficiently. Or maybe buffer the data and send it back after the test is finished or stream it in chunks consisting of data for multiple samples. Also, note, USB frames are 1ms so when sending back samples one at a time the best you could probably do would be 1kHz - and you might be able to achieve that.