Rodeostat FAQ

For the most part the Rodeostat with the Itsy Bitsy M4 Express has the same functionality as the Rodeostat with the Teensy 3.2. It uses the same firmware (slightly modified), the same python API and the same Web App. The biggest difference is that the Rodeostat with the Itsy Bitsy M4 express is not able to support the multiplexer expansion kit. This is due to the Itsy Bitsy M4 not having sufficient IO to interface with the expansion kit. One of the primary reasons for adding a new version of the Rodeostat is due to the Teensy 3.2 availability issues. The manufacturer of the Teensy, PJRC, is currently unable to get the MK20 microcontrollers for the Teensy 3.2 from NXP. There may be a small batch of Teensy 3.2's available in April and Sept 2023, but it is not clear how many and whether we will be able to get any. Because of this we decided to create a modified version of the Rodeostat which uses the Itsy Bitsy M4 express.

In porting the firmware to Itsy Bitsy M4 express we had to make some minor modifications. This consisted of changing the pin mapping to accommodate the new microcontroller. These changes are mostly confined to ps_pin_map.h. There were also some changes due to differences in timer operation between the two microcontrollers. None of these are changes that you would notice as a user of the system unless you are customizing the firmware. Also, the firmware now supports both Teensy 3.2 and Itsy Bitsy M4 express. The board you are targeting is selected using a #define in ps_hardware_defs.h To build the firmware for the Teensy 3.2 #define DEV_BOARD_TEENSY and to build the firmware for the Itsy Bitsy M4 #define DEV_BOARD_ITSY_BITSY.

In terms of microcontrollers, the MK20 on the Teensy and the ATSAMD51 on the Itsy Bitsy are pretty similar. The ATSAMD51 on the Itsy Bitsy M4 is a bit faster running at 120MHz whereas the MK20 on the Teensy 3.2 is running at 72MHz. The ATSAMD51 also has more flash (512KB) and RAM (192KB) vs the MK20 which has flash (256KB) and RAM (64KB). On the other hand the Teensy exposes more digital IO from the MK20 than the Itsy Bitsy does from the ATSAMD51. This enables the Teensy to support the Multiplexer expansion board where the Itsy Bitsy M4 cannot. Another difference is that the analog inputs on the Teensy (MK20) are 16-bit and the analog inputs on the Itsy Bitsy M4 (ATSAMD51) are 12-bit. However, in practice you won't see much of a difference between the two. This is because in practice while analog inputs in the MK20 are 16-bit in practice you can really only use the highest 12 or 13 bits. So the overall resolution is about the same.

Yes the maximum current range for our standard Rodeostat is ±1mA . We also have a new higher current version with a maximum ±10mA range. However, both have limits. There are a couple of aspects which determine this limit.
 First, the transimpedance amplifier converts the current at the working electrode to a voltage which is proportional to the current. Subsequent amplifier stages then scale and shift this voltage to a range which is suitable for an analog input (ADC) on the microcontroller. The analog ADC has a finite (voltage) range and we want to make the best use of that range. So for a given current range, say - 1mA to 1mA, the output voltage of the transimpedance amplifier is shifted and scaled to cover the full range of the ADC. However, because of this, currents outside of this range lead to voltages which are outside of the range of the ADC - either too low or too high. The analog inputs are protected so that when this happens the signal is just clipped at the minimum or maximum values. However, it does prevent you from making measurements outside of the given current range.
 Second, there is a limit on how much current the control and transimpedance amplifiers can source/sink. The op amps used in these circuits determine the absolute maximum currents for the device. In general if the sole current source from your test cell is the Rodeostat itself (i.e. the Rodeostats counter electrode) then there isn't too much danger in over currenting the device. However, if there is some external source of current then I would try and limit the current to ±10mA.

The Rodeostat doesn't have this ability built in. It is a potentiostat and controls the potential between the working and reference electrodes. It doesn't have built-in galvanostat functionality. That said if the timing requirements aren't too demanding it might be possible to mimic this behavior in software from manual/direct mode. This would require writing a program in python which implements a little control loop to keep the current fixed by adjusting the output voltage in real-time. There are some limitations as this would have to be done over USB so the fastest you could probably run this loop is about 500Hz and you would have to implement this control loop yourself.

If you are using the Chrome browser, note there is a new flag which can prevent the serialport-bridge from communicating with the web app software. You can change the value of this flag here (chrome://flags/#block-insecure-private-network-requests). On the page change "Block insecure private network requests" from "Enabled" to "Disabled". This will allow the web app software to communicate with the serialport-bridge. Note, you will need to restart chrome - all running chrome browser windows - after making this change in order for the change to take effect.

Also, note that all of the communication between the web app and the serialport-bridge is local to your computer. The web app software is just javascript which runs in your browser, there is no communication with a remote server or anything like that. The purpose of the serialport-bridge is to enable the javascript running in your web browser to communicate with the USB/Serial ports on your computer. In the future we plan to remove the serialport-bridge requirement altogether as there is a new WebUSB API specification which allows for direct access of the USB/Serial ports from web browsers so there would be no need for the serialport-bridge.

The "sample rate" determines the rate at which measurements (samples) are sent from the Rodeostat to the host PC. The units are Hz or (samples per second). Note, this value only sets the rate at which data is collected - it does not control how quickly the output voltage is changing. When performing a linear sweep with the web app the "scan rate" in V/s controls the rate at which the output voltage is changing. When using the Python library (http://stuff.iorodeo.com/docs/potentiostat/) the scan rate is set by the (finalValue - startValue)/duration. Note, the tests are implemented in firmware on the Rodeostat so the same underlying test is being run regardless of whether you are using the web app or the python API. The various tests are documented more completely in the python library documentation. For example, the documentation for "linear sweep" test can be found here http://stuff.iorodeo.com/docs/potentiostat/tests.html#linear-sweep-voltammetry and the documentation for cyclic voltammetry can be found here http://stuff.iorodeo.com/docs/potentiostat/tests.html#cyclic-voltammetry. That said, for a given test the input parameters aren't always exactly the same for the web app and python library. However, usually the translation between the two is pretty straight forward - such as with the scan rate in the linear sweep test.