We do not have a DPV test implemented for the Rodeostat yet. This is something we are planning to add in the future. However, there isn't a specific timeline I can give you for adding this test.
I looks like the access permissions had be set to private. I've change it to public. You should be able to download the file now. You can also access the repository here https://bitbucket.org/iorodeo/ph_meter_firmware
I'm not sure the exact cause of the "hairyness" the CV's. I do know that it only seems to occur when using certain electrochemical setups. We don't see it with purely resistive loads such as dummy cells or even simple dummy cells with combined resistive and capacitive loads. You can do CV sweeps etc. and no hairiness . So it isn't really a matter of whether or not the potential is fixed - maybe it is some characteristic of the load in the cases where we see the hairiness. It would definitely be interesting to explore the issue. I've been considering designing some more general dummy cell PCBs for testing purposes and I would love some input on designs. It would be great to have a very general dummy cell design which could mimic all sorts of loading situations. In particular, could we find a dummy cell with the correct load characteristics to reproduce the issue? or is this really something to do with the electrochemical cell?
The capacitor in the feedback loop of capacitor of the control amplifier is a compensation capacitor used to improve stability. It is basically providing a high-frequency bypass. The load which the potentiostat is going to be hooked up to is essentially unknown (lots of different variations) so we wanted the control loop to stable under a broad range of conditions. Adding this compensation capacitor was found to help extend in stability over a broader range of conditions without causing a detrimental effect. I don't believe this capacitor is the cause of the hairiness you are seeing.
The compensation capacitors on the transimpedance amplifiers are also for stability. The values have been selected fairly conservatively. So we are probably getting a bit more lowpass filtering then absolutely necessary. For the most part this is more of an issue for the lower current ranges where the resistor in the feedback loop is larger. We've made some nA versions of the Rodeostat where we had to go to larger capacitor values in order to ensure stability. For example, for a +/- 60nA range with a 10MOhm resistor we needed a 100nF compensation capacitor for stability. Again I don't think these capacitors are the issue.
The LEDs not flashing could still be related to the sensor issue. The firmware cycles through the LEDs one at a time and measuring the frequency of the pulses coming from the light sensor - the frequency of these pulses is proportional to the light intensity. It measures the frequency (or period) for "Samples" number of pulses and then averages to get a get final measure of the frequency (and thus light intensity). If the Arduino isn't receiving the pulses the firmware will error out and so you won't cycle through to the next color. This could explain why you aren't seeing all the LED flashes. Also, you can slow down the LED flashes by increasing the "Samples" number, e.g., increasing "Samples" to 5000 will make the firmware try to measure 5000 pulses and average the results - this will take longer so the LED will remain illuminated for longer.
We can send you a replacement sensor board, arduino shield and ribbon cable. This should cover the bases regarding the sensor unless it is an issue with the Arduino itself. I should be able to have the replacement parts in the mail to you by tomorrow.
Yes, it may indicate an issue with the sensor board, the connection to the sensor, or with the firmware.
Do you get any error when initially connecting to the Arduino? After connecting what do you see in the "Samples" textbox? is it set to 500?
If connecting to the Arduino works OK, but after trying to calibrate with the sensor in room light you get the error "unable to calibrate device: RSP_ERROR: [0, calibration failed]". This means the the Arduino is not able to read from the light sensor.
Another test which you can try is to expose the light sensor to light and then run the calibration procedure. Because the light sensor is exposed to light the calibration procedure should finish - it won't matter whether or not the LEDs flash. This will test the operation of the light sensor and firmware.
You can expose the light sensor to room light by removing the top of the colorimeter enclosure. Make sure the light sensor is directly exposed to the room light. Then try running the calibration procedure. Do you still get the RSP_ERROR? Note, this won't result is a good calibration, but it will let us know if the light sensor is working and which will help us diagnose the problem.
Check the cable connecting the light sensor board to the led board board and make sure that the orientation is correct i.e., that GND -> GND, red -> red, etc.
Are you using the standard RGB LED board or one of the custom boards with 1 LED (board B ) or 2 LEDs (board C). In the later case make sure to select the correct mode from the drop down menu.
If you are on windows you can use Device Manager. Start with the colorimeter arduino unconnected. Open Device Manager. Then connect the arduino. After the arduino is connect in you should see a new device appear in the Device Manager. If you click on it you should be able to get the com port number.
On linux you can look in the /dev directory e.g. run "ls /dev/ttyACM*" the colorimeter should show up as /dev/ttyACM0, /dev/ttyACM1, ... etc.