Group Details Private

Global Moderators

Forum wide moderators

Member List

  • RE: Impedance Spectroscopy and Manual Control Sampling Rate

    @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.

    posted in Rodeostat
  • RE: Impedance Spectroscopy and Manual Control Sampling Rate

    @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.

    posted in Rodeostat
  • RE: Impedance Spectroscopy and Manual Control Sampling Rate

    @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.

    posted in Rodeostat
  • RE: Galvanostatic measurements/two-electrode setup

    @Kathy

    No the Rodeostat cannot do galvanostatic measurements. Nor can it do battery charging and discharging using constant current and a defined voltage range.

    It is possible to do measurements with the Rodeostat using a two electrode setup.

    posted in Rodeostat
  • RE: Chromebook Colorimeter

    @304dturner

    Unfortunately, we don't have a version colorimeter software which works on Chrome OS.

    We do have software for linux. so you could install ubuntu on the Chromebook using crouton https://github.com/dnschneid/crouton This will allow you to run ubuntu while preserving your original Chrome OS system.

    There are some instructions here https://tutorials.ubuntu.com/tutorial/install-ubuntu-on-chromebook#0

    posted in Rodeostat
  • RE: Increasing current ranges to detect mA

    @Will-Dickson

    Also, 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.

    posted in Rodeostat
  • RE: Increasing current ranges to detect mA

    @tellis

    In the "firmware/libraries/potentiostat" sub-directory there is file named ps_constants.h there is a #define near the top which is commented out

    //#define HARDWARE_VARIANT_MILL_AMP
    

    remove the comments - so it like like this

    #define HARDWARE_VARIANT_MILL_AMP
    

    Notes, this assumes that you are changing two resistors - R8 with 50 Ohm and R7 with 25 Ohm. If want to just change one you may need modify lines 92-99 in ps_constants.cpp where the parameters for the current range are set.

    posted in Rodeostat
  • RE: Arduino Communication

    @HoughA

    There are a couple things that come into this.

    First, the output voltages are set at discrete time points via the testTimer which run by default at 5kHz. To make a reasonable approximation of a sine wave you will probably want enough points - maybe 50 or so. So you could probably output reasonable approximations of sinusoids voltages up to frequencies of about 100Hz.

    Second, the data is not sent back to the PC (or other device connected via UART) at every update of the testTimer. Rather it is sent at a lower sub-sampled rate set by the sample rate (or actually sample period in the firmware). The maximum value for the sample frequency is 1000Hz. You will need sufficient number of sample points at which to measure the current you get in response to the sine wave output. So maybe 20 or 30 or 50 ... the exact number depends on your needs. Lets say that 20 is sufficient. Then this further reduces the maximum sinusoid frequency to 50Hz (1000/20).

    Third you will need to take into account the bandwidth of the current measurement range you are using e.g. +/- 1uA, +/-10uA, +/-100uA, +/-1000uA. Each of these channels will lowpass filter the measure signal to some extent based on the resistor capacitor combination used in the feedback network of the transimpedance amplifier. The more sensitive channels will have lower cutoff frequencies. The +/-1000uA and +/-100uA channels have pretty high cut off frequencies such that it won't be an issue. However, the +/-10 uA and +/- 1uA ranges have cutoff frequencies of approximately 47Hz and 4.7Hz respectively. So if you are using these channels this will limit the bandwidth of your measurements somewhat or at least you should be aware of the possible attenuation of the measurements at higher frequencies.

    posted in Rodeostat
  • RE: Arduino Communication

    @HoughA Great. I'm glad to hear you got it working.

    Another option, if you really want a hardware serial port, is the other header P14. The pins D26 and D31 on that header can be used at the Rx and Tx pins for Serial2. See the serial docs for the various teensys here https://www.pjrc.com/teensy/td_uart.html

    Regarding pressing return in the serial monitor. The potentiostat's MessageReceiver, implemented in ps_message_receiver.h and ps_message_receiver.cp, only decides that a new message has arrived after receiving the '\n' character. The Arduino Serial Monitor sends a '\n' when you press return ... so could be that. Maybe adding a '\n' to the end of all messages sent to the teensy would help.

    posted in Rodeostat
  • RE: Arduino Communication

    @HoughA

    I think the issue might be with using D3 and D4 as Tx and Rx pins for Serial1 in the the teensy 3.2. It looks like they are the Tx, Rx pins for the CAN bus not a UART .... You could use SoftwareSerial on these pins. The other option would be to move to something like I2C or SPI.

    posted in Rodeostat