Author Topic: OLED significant digit stability  (Read 2758 times)

pabigot

  • NewMember
  • *
  • Posts: 5
OLED significant digit stability
« on: July 11, 2020, 07:46:39 PM »
I received my CurrentRanger today.  Testing against the uCurrent I've been using the last couple years it provides similar results on a DMM, and the autoranging is very nice.

The OLED accuracy is surprisingly poor, though, at least with the tests I've run so far.  Reading other postings here I understand I should expect some offset and error.  At 3050 uA it bounces around between 3020-3070 so that's useful.  But at 232 uA reading on the DMM the OLED bounces between 30 uA and 400+ uA so fast it tells me nothing about the value; similarly steady 650 uA displays anywhere between 500 and 850.

That's significantly worse than I've seen in messages here.  Is this expected?  It occurred with the as-delivered firmware and with the latest UF2 image on Github.  I'd hoped to get two significant digits of accuracy at a given magnitude, but even one would be helpful.

Thanks.

pabigot

  • NewMember
  • *
  • Posts: 5
Re: OLED significant digit stability
« Reply #1 on: July 12, 2020, 09:08:13 AM »
Looks like this is influenced by https://github.com/LowPowerLab/CurrentRanger/commit/2435424e605db6e16bb1aabe8d03a8f80bdb01e8.  Switching to slow ADC sampling improves things significantly, but the slow rate 256 still bounces between 206 and 242 uA with occasional 187s showing up.  512 sample averaging may be needed in my case.

Switching to the fast ADC sampling rate causes autoranging to go into a fit (constant buzzing toggling between nA and uA.)

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: OLED significant digit stability
« Reply #2 on: July 13, 2020, 09:26:43 AM »
The OLED accuracy is surprisingly poor, though, at least with the tests I've run so far.  Reading other postings here I understand I should expect some offset and error.  At 3050 uA it bounces around between 3020-3070 so that's useful.  But at 232 uA reading on the DMM the OLED bounces between 30 uA and 400+ uA so fast it tells me nothing about the value; similarly steady 650 uA displays anywhere between 500 and 850.
That's not normal. The CRs are all tested and calibrated against known fixed values in each range to ensure the ADC/OLED/raw readings are valid and stable.
Noise can certainly play a role, and there can be several sources.
How exactly do you perform your testing?
I would ensure you are not connected to any earth ground in any way, ensure USB is disconnected (or run through a isolator) as this is a ground loop hazard and possible damage to the CR as explained in the guide. I would simply go somewhere where there is no possible noise pickup from mains (noisy lights and other such things) and perform a very simple standalone test (everything floating and nothing connected to earth ground in any way), with a battery and resistor for instance to give you the 200uA you're after, and a DMM at the output.

pabigot

  • NewMember
  • *
  • Posts: 5
Re: OLED significant digit stability
« Reply #3 on: July 13, 2020, 03:38:26 PM »
This was with a microcontroller system powered by LiPo; no USB or mains powered sources involved.  After plugging in a scope it does seem to be a problem with noise on the test board and the environment.  Switching to testing a battery with a resistor things are much more stable.  But since I do need to measure systems like this I'll have to tweak the code to increase the sample size.

Thanks for your help.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: OLED significant digit stability
« Reply #4 on: July 13, 2020, 07:34:57 PM »
Yes definitely a scope would show you the raw behavior which is at much higher bandwidth than what the CR can sample.

willemb

  • NewMember
  • *
  • Posts: 6
OLED Reading Bouncing Around
« Reply #5 on: December 20, 2020, 02:12:52 AM »
Measured source is from MCU connected to lipo.  I have a CR-R2 with firmware 1.1.0.  mA scale gives fairly stable readings on the OLED.  However, uA scale measuring about 250uA, the OLED bounce is horrendous! Somewhere between 90uA and 500uA.  If I flash back to R1 firmware the OLED doesn't bounce around; but I lose the logging which is nice.  I feel like this is an averaging problem in the firmware?  Changing between slow, average and fast does not make much of a difference.  Slow seems to be the best but its still a 300 uA swing.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: OLED significant digit stability
« Reply #6 on: December 20, 2020, 09:09:14 PM »
I shipped a small batch of 1.1.0 and then I reverted back to 1.0.0.

Please switch back to firmware CurrentRanger R3.1.0.UF2, it is available here: https://github.com/LowPowerLab/currentRanger/

Let me know if you're still having any issues.

willemb

  • NewMember
  • *
  • Posts: 6
Re: OLED significant digit stability
« Reply #7 on: December 21, 2020, 12:30:44 AM »
Hi Felix.  I think I must have borked it.  I must admit it's quite possible when I first got it a few years ago I did not heed your warnings regarding earth grounds. I haven't really used it since I first bought it as work has got in the way.  Firmware doesn't make a difference for accuracy.  It helps with the OLED bouncing around but the reading is still way off.  Only the nA scale seems to be ok.  uA and mA are completely off when reading directly with probes and no OLED.  With a lipo battery measuring 4.19V and using a 1M resistor I get 550 - 600uA at the probes. 




Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: OLED significant digit stability
« Reply #8 on: December 21, 2020, 10:25:53 AM »
I'm not sure how to help other than take a look at it myself. I can tell right away if something is wrong. Otherwise its a bit of a guessing game.
If you want to ship it back I can do that, but I cant spend too much time on it, and you will have to cover shipping cost back. Up to you, let me know via the contact form.

willemb

  • NewMember
  • *
  • Posts: 6
Re: OLED significant digit stability
« Reply #9 on: December 21, 2020, 03:20:25 PM »
The OLED is matching the output so is it reasonable to suspect the opamps are damaged and that the SAMD21 is ok?  One other strange thing though.  When auto-power kicks in I am unable to start the OLED after powering back on?  I have to load the firmware again in order to get the OLED back on?  Perhaps I'm missing something really obvious?

I might try and fix it myself first with some new opamps when I get my next Digi-key order.  If that doesn't work then I will get a new current ranger.  Thanks Felix.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: OLED significant digit stability
« Reply #10 on: December 21, 2020, 03:39:31 PM »
Never heard of OLED needing firmware reflashing to work again, makes no sense. If it works, it should work always.
More like the SAMD is damaged, but could be something else, hard to really say.

willemb

  • NewMember
  • *
  • Posts: 6
Re: OLED significant digit stability
« Reply #11 on: December 29, 2020, 11:39:05 PM »
I found and fixed the problem!

So nA and mA ranges were fine; uA was not.  It was consistently reading off.  For a 10K resistor in series with a LiPo at 4.06V I was measuring around 580uA!!!  About 40% off the mark.  I should have started with the easy parts first but of course not.  I ordered two new opamps and surgically replaced them.  Same problem.  I then started at the beginning and popped off the 10-ohm shunt resistor and voila - it was measuring 14-ohm!  I thought when resistors went bad they tended towards shorting rather than opening?  I didn't have a 603 10-ohm resistor on hand so I kludged a low quality axial resistor.  (10ohm 10%). Problem fixed!  I am now getting a rock solid 403 uA - more than acceptable until I get a 5% 603 part. 

I must have been delusional regarding the OLED not turning back on after an auto power off.  That is working fine now.  I am back in business!

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: OLED significant digit stability
« Reply #12 on: December 30, 2020, 09:57:29 AM »
Oh that's interesting, I don't recall ever hearing about the uA shunt being damaged.
Thanks for the follow up, by the way the OEM precision shunt is 0.05%, ~100x more accurate than the 5% you were planning to use ;-)

willemb

  • NewMember
  • *
  • Posts: 6
Re: OLED significant digit stability
« Reply #13 on: December 30, 2020, 01:34:47 PM »
Ah thanks for that.  I suspect it was my initial use when I first got it years ago.  I can't remember exactly but I do recall hooking things up wrong.  Should have read the manual first.

stevie67

  • NewMember
  • *
  • Posts: 2
Re: OLED significant digit stability
« Reply #14 on: February 12, 2021, 01:05:11 AM »
Hi,

I am using the CR since a couple of years, it is really awesome!

Recently I wanted to do something USB logging. I flashed the newest firmware release from Gibhub. With that release I now get every 100 ms or so (it is not very regular) a reading of 0.4 mA, even if no load is connected. Similar to uA range, where I get roughly every 100 ms some high value around 300-400 uA, although there is no load. Or a load of around 35 uA - as displayed with the old version (load is a MC with LIPO powering). I switched back to the old FW and got normal behaviour back. So something is off. I tried to fix that by setting the original calibration values but that did not improve things. Note this is with and without USB connected.

I am posting in this thread because I have apparently similar issues to pabigot which are not there with the 1.0 firmware. Felix, you mentioned that you also switched back. Is there a know issue, which will be fixed?

Also notably, when switching back to the original firmware the OLED worked. Then after powering off and on again it did not work any longer. Similar to what was also posted in this thread. I was able to fix it by putting a delay(1000) before the Wire().begin() statement in setup.

Thanks,

Stefan