FINAL UPDATE:

After buffering the data, the limitation in sampling frequency appears to come from the testTimer function. This function has a specific runtime, and runs on a timer interrupt. If the timer interrupt's period (testTimerPeriod in ps_constants.cpp) is smaller than the actual time it takes for the function to run, the function does not run correctly, yielding incorrect and strange results.

For those looking to increase their sampling frequency, this seems to be the next bottleneck after the data streaming. Perhaps some alteration/optimization of this function could increase the sampling rate slightly, perhaps not.

Ultimately, to increase the sampling frequency of the Rodeostat, you can:

Decrease MinimumSamplingPeriod within ps_constants.cpp in order to remove the software limitation on sampling frequency

Remove calls to convertMstoUs in ps_periodic test and in ps_system_state.cpp, allowing for periods to be passed directly in units of us, rather than being limited to a sampling period of an integer in ms

In serviceDataBuffer (in ps_system_state.cpp) , modify the function so that it does not transmit data until test done flag has been set (by putting an if statement around most of the function).

With this we were able to achieve higher than the stock sampling frequency for a small number of periods (this was limited by the memory, since the data buffer would get filled with too many points since we did not clear it until the end). Unfortunately, high frequencies like 10kHz or 100kHz did not seem to be reachable.

In addition, thank you @Will-Dickson for your help figuring this out.

Update:

We ended up encapsulating the everything in the SystemState::serviceDataBuffer() in the ps_system_state.cpp file after the comment "//Empty data buffer" in an if statement. The data buffer is only emptied once the test is finished running.

After making this change, the t vectors returned by the test were still delayed, each point was a minimum of 1ms apart, and thus we had repeated points. However, after creating our own t vectore with the know t step, the plots came out quite nicely, and we were able to run waveforms up to 10kHz.

Due to the limitation on data buffer size, slower waveforms must be analyzed with a sample rate such that the number of points doesn’t exceed the data buffer. But this is not big deal, as for our purposes we only need the high sampling rate for the fast waveforms.. I may do some further modifications to change the buffer size to allow for high sampling rates on slow waves, but for now the above modifications have sufficed to allow us to run waveforms of up to 10kHz.

Next we’ll be working on calculating impedance and phase from these output data arrays.

@Will-Dickson
Another update:
I’ve followed your first point and changed the testTimerPeriod to be much lower. In addition, I noticed that for periodic tests the period was limited to an integer in units of milliseconds, which would limit the period of the applied wave to 1 ms, for a maximum applied frequency of 1000 Hz. So in the ps_periodic_test.cpp file I removed the call to convertMstoUs() in order to fix this.

In the further testing I’ve done, I’ve seen strange results. The Start and End time are correct for my plots, and the correct number of points are plotted based on my sampling rate, even if the sampling period is set to be quite low. However, in the returned t vector, there are multiple time points. e.g., we’ll see two 0.0s, two 0.001s, and so on until the end of the test.

This appears to be a sort of delay of 1ms, where the program attempts to sample but can’t move forward. I believe you are correct: and this has to do with the data streaming over USB.

For our purposes, we do not need to send data back to the computer until the test is complete. Thus, we would be happy to modify the data transmission to send the time, voltage, and current arrays over USB after the test is over. So essentially, we want to do like you said an buffer the data, sending it after the test is over. What would we need to change to do this?

Where is the current data streaming controlled? Is this within the Python library, JSON, or the Arduino code? What specific files or scripts would I need to modify?

EDIT: If we do need to modify the JSON library, how would we incorporate these changes to the library? I’m not all that familiar with JSON to be honest.

My apologies for the late update.

Changing the optimization to FAST from FASTER allowed for the firmware to correctly update.

After some more testing, changing the MinimumSamplePeriod value allows me to manually set the sampling period/rate to be much faster than before without the command being rejected for being too small. However, when I run the sinusoid test, I still cannot apply a waveform of a frequency higher than 500Hz.

I will continue looking through the firmware to see where I can change this, as well as do further sampling frequency tests with different firmware tests. Any recommendations on where else in the firmware to increase sampling frequency? I’ve begun looking into the firmware files for the periodic test and the sinusoid test.

I have changed the MinimumSamplePeriod value in the ps_constants.cpp file in the firmware. However, I'm running into problems trying to upload the modified firmware to the Teensy.

I have Arduino and Teensy installed. I put all of the header files and .cpp files from the firmware/libraries/potentiostat folder into the /firmware/potentiostat folder with the potentiostat.ino file. The Arduino IDE compiles this file, and successfully uploads it via Teensyduino. However, when I attempt to run the example CV script from python, I get an error stating that “No JSON Object Could Be Decoded”.

I went back and made sure to zip the Array and ArduinoJson libraries and include them via the Arduino IDE in the potentiostat.ino file. However, when these libraries are included in that file the Arduino IDE will no longer compile the potentiostat.ino file, returning multiple errors about redefining various structs related to JSON.

This may seem dumb, but what is the correct procedure on how to upload new firmware for the Rodeostat?

@Will-Dickson Thank you for your response. The software limitation makes sense. Ideally we're looking to measure the impedance of the cell in response to a 1000Hz sine wave, so I think you're right: our best bet will be to modify the firmware to achieve a higher sampling rate via the Teensy board. Where do you think would be the best place in the firmware to start? I'll take a look now and see what I can do.

I was hoping to use the Rodeostat to get a measure of electrochemical impedance in a cell at difference signal frequencies. Is this something any of you have tried before? If so, how did you go about it using the libraries?

Additionally: when using manual control, I have been unable to achieve a sampling rate higher than 40 sps. Whether using the Manual/Direct example here or using my own script, no matter how much the intervale between samples is decreased I only get roughly 40 samples per second of testing. When using the Python library the software seems to have a sampling rate limit of 1000 sps, but even when I set the sampling rate to the maximum I still see 40. Is this a hardware limitation, or a limitation in the Python library?

In order to run these Impedance Spectroscopy tests, I'd ideally need a sampling frequency of at least 2000 samples per second. Is this achievable with the Rodeostat?