I have been able to run Python in the command window and run my code consecutively and it worked fine. I double checked that the REPL feature I was using is the cause of my trouble. Thanks for your help.
Thank you so much! We tried rebooting it before with the potentiostat.ino file; however, we had set CPU speed to 96 MHz and Optimize to "FASTER". It is now working with the settings you specified. Thank you again.
There is definitely something funny going on in that first result. . I'm not sure what is causing it. I doubt that it was the firmware update. I would start with the usual things - make sure all the connections are OK and that the electrodes are connected correctly. Also, If you want to the send rodeostat back to I could have a look at. Send me an email (firstname.lastname@example.org) if this is the case.
Unfortunately, it isn't possible to do a true linear ramp with the Rodeostat. It uses a Digital to Analog Converter (DAC) to set the analog output value and so the output will always be in discrete steps where the minimum possible step value set by the resolution of the DAC.
Ey guys, after working on this along the afternoon I have solved the issues in our case.
For the future generations that want to integrate Rodeostat in their Arduino based platforms:
The Hardware: As Will has said before, you will need to connect the Arduino to the teensy in one of the possible ways (SoftwareSerial, I2C, SPI, Hardware Serial (like Serial2...)). In our case we have connected it by Hardware Serial, with Serial2 in the pins 26 of the P14 connector (see the schematic that Will attached before, remeber that the arrow in the pcb indicate the first pin of the header) to a TX pin in the Arduino (in our case the TX2 pin in Arduino Mega) and the 31 (also in the P14 connector) to the RX pin in the Arduino. For powering the rodeostat you will also need to connect the ground from teensy (like the one in the P13 or P14 connector) to the ground in Arduino, and 5V of Arduino to the pin 5V in the teensy PCB. This last pin is located under the P13 connector, there are four pins and the sign "5V" are near the internal pin of the PCB but TAKE CARE the 5V pin is the one in front of this, the one near the border of the PCB. That letters lead to an error.
The Arduino software. You could use the one that @HoughA have post before, measuring the voltage between the "DAC BIP" hole in the pcb and a hole connected to ground. The voltage should change between 1 and 0 every second (if you polymeter don´t change this fast, just change the code and set a delay of 5 secs).
Teensy software. First of all, you will need to add this lines to the setup function in the Arduino file (these lines are specific if you are using Serial2 communication, substitutes them for your own system):
You will need also to change the functions that receive the messages from the normal usb serial port, and set them to receive by Serial2 port instead. For doing this just open the files ps_message_receiver.cpp and ps_message_sender.cpp (this one if you want to also receive the response in your arduino instead of your PC) from the potentiostat library and change every line in which you see "Serial." to "Serial2."
If you made only this changes you will have the problem that @HoughA have faced before; Your Arduino and your Teensy only communicates after you send something over the normal Serial port with a PC. This is because we don't have changed the Serial Event handler in the Arduino code. This handler triggers on with a new Serial communication and updates the message data.
This handler function is located at the bottom of your .ino file. Is called SerialEvent and you will need to change it to SerialEvent2 (To handle Serial2 events instead of Serial events).
Sorry for my poor English. Hope this comment has given you a hand.
Thanks, for the suggestions. Just for clarification, I'm using 1WE, 1CE, 1RE (or 1WE - 1 CE/RE) for each rodeostat. For now I'm running each rodeostat in individual beakers.
Anecdotally, I ran the same experiment using a research-grade multi-channel potentiostat (from GAMRY) and didn't see cross-talk in a single beaker. Specifically, I ran high currents using a single Ag/AgCl wire (reference+aux) for each channel. The stability of each cell degraded randomly. Previously, when using a few rodeostats, all WE signals decayed at the same time (suggesting the 3 wires were acting as a shared reference/aux).
Ordered a USB isolator, will wait before splicing my teensy boards. They're cheap enough to replace, but I'd rather not need to if I can help it.
This will give you a development environment which will allow you to program the firmware on the teensy and would be the option you want if you wish to customize the firmware on the teensy in some way.
You should get the best current measurement by selecting the smallest current range which will encompass your data.
In this case the sample rate just determines the rate at which samples are collected and sent to the host PC i.e. the time step between samples. So the scan rate (V/s) is independent from the sample rate. The scan rate is set via the 'amplitude' and the 'period' parameters as follows scan rate = 4 x amplitude/period.
This is a very interesting idea - thanks for sending me a link to the paper. I think this would be a great way to expand the capabilities of the Rodeostat. Perhaps the quickest and cheapest way to try this with the Rodeostat would be be make a little external expansion board which implements the make-before-break multiplexing. The expansion board could connect the Rodeostat's K1 header for the working, counter and reference electrode connections and to the DIO header "P14" for power, ground and digital control signals. I think this would be a pretty easy expansion board to make as there are only a few components required. This way we could test the idea without too much new hardware. I think I will definitely have a go at designing this expansion board. I will send you a schematic when I have something ready.
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.