I’ve noticed a strange issue with the auto-ranging in certain low current configurations. I have an Otii ARC powered by a 7.9 V linear DC supply (fairly quiet), and plugged directly into a laptop USB port, powering a sleeping prototype device drawing 3.7 uA, with the auto-ranging turned on. When the output is switched on, the ARC seems to run in the higher range. I can get it to drop down into the lower range by removing a power lead from the prototype, then reattaching it. If I then toggle the outputs off and on again, they switch back to the high range. See the attached image, where the selected area shows the low range reading back the correct values. After I toggle the output in the software, you can see the noise floor increase as the ARC switches back to the high range.
I’ve tried this at 4.55 V and at 4.2 V, and it happens at both voltages. I’ve also tried it with a 1.2 Meg resistor, which draws roughly the same current as my prototype at 4.2 V, and it does not occur with the resistor. It also does not occur when I configure my prototype to draw a higher sleep current (say 20 or 30 uA). So it seems to only occur with a noisy load and over a certain current range. It can spontaneously switch from the high range to the low range under some circumstances. For instance, if I have my 3.7 uA prototype running in the high-range error state, and add the resistor in parallel, it usually switches to the low range within a few seconds.
Its a bit of a hassle, since the accuracy seems to be about ± 30 uA in the high range, versus <0.5 uA in the low range, and I’d like to be able to trust the readings without double checking them. So I hope it is an easy firmware fix.
Hello James. What software and firmware are you currently using? You can see the firmware version printed in the History window when Arc is initialized.
And it would be good if you can attach a project file with this error condition.
I’ve attached a screenshot of the history window, and a couple of projects - one before, and one after running a calibration. The waveforms in the graph are divided into 4 distinct sections:
Device sleeping at ~3.7 uA, after turning the Arc on - noise floor is high due to high range
Then I pull the ground lead off my device, and the range drops down, noise floor diminishes
Then I plug the ground lead back into the device, and the noise floor drops further now that the lead isn’t electrically floating
Then I toggle the Arc output using the toggle button in the software, causing a short transient, and a return to the higher range.
We can be fairly certain the Arc is switching from high to low range and back, as the sample rate changes from 4 kHz to 1 kHz where you’d expect it to.
This is strange.
One idea is that your device has very short, high current pulses, that switches the Otii Arc to high range mode.
Add a capacitor between + and - and try again.
If the issue still exist, send a project file that includes the voltage.
Seems like a long shot - it’s just a sleeping microcontroller, and has its own input capacitance and decoupling… I think the voltages are all pretty much flat, but will check. Capacitor on the leads sounds like a good idea - will try it. I also tried with the new firmware and software that came out yesterday, with the same results.
I’ve attached a project file including the voltage. This one starts in the high range, then resets to the low range by removing and reattaching the load. I also tried adding 4.7 uF across the banana plugs, and that definitely seemed to help.
The problem is quite temperamental. It’s much easier to trigger the high-range state when my USB uart is plugged into the load device, after which it will stay in that state when the uart is removed from the device leaving it with just the power cords to the Arc, until it is cleared by either adding capacitance or disconnecting the load.
Adding an update here in case somebody stumbles upon this issue: After some testing back and forth we believe we have found why this occurred, and have a fix to be included in the next firmware release (1.0.8). Thank you very much James for assisting us with this!