Need guidance for current monitoring for simple sleep/wake scenario

[BDLawISU84]

I think I've run into a use case that CurrentRanger just wasn't designed for, but just double-checking before I look at other products ...

My board toggles between sleep & wake states frequently ... it wakes every 30 msec, polls some inputs for 3-5 msec, then goes back to sleep. In sleep mode, the current usage is about 500-800 uA. In wake mode current usage is > 5 mA.

On my bench the board is powered by a power supply and I have a USB isolator connected so I can monitor the current readings and eventually graph them. I'm running the off-the-shelf R3_1.1.6 CurrentRanger firmware. My custom graphing app initializes the CurrentRanger via commands '!' (reset all settings to defaults), 'a' (auto-off disabled), 'u' (start logging) plus a "mode" setting I document below.

If I run CurrentRanger in uA mode (init sequence = "! a 2 u"), the sleep current looks correct but the wake current readings are clipped at just under 3300 uA.

If I run CurrentRanger in mA mode (init sequence = "! a 1 u"), the wake current looks correct but the sleep current readings are 0 or sometimes negative:
0.00e-3
-0.40e-3
0.00e-3
-0.40e-3
-0.40e-3
-0.40e-3

If I run CurrentRanger in autoranging mode (init sequence = "! a 1 6 u"), I almost have a working solution except that when the op amp saturates in uA mode during the wake up, I get extreme out of range errors like this  glitch to 446 mA ...
553.53e-6
556.75e-6
665.44e-6
1002.38e-6
446.44e-3    <-- 446 mA
7.65e-3
3.22e-3
1259.62e-6
983.46e-6
1022.51e-6
974.21e-6
890.47e-6
823.24e-6
787.42e-6

I guess one solution is to toss the first 2 readings reported whenever the exponent changes from a high number to a lower number, but I'm trying to do some average current consumption over time calculations and that throws off those averages.

Is there any kind of workaround for this?

[Felix]

The -0.40e-3 readings in mA you see are just the very bottom end of the ADC (noise), don't expect high accuracy there (since you're really running uA's, not mA's).

The spikes during auto-ranging are a usual artifact when ranges switch 3 orders of magnitude.

You could do software filtering as you said, or modify the firmware to wait a certain amount of time.
Or do the averaging right in the firmware yourself.

Or maybe one of the 3rd party GUI's can do something or it's easy to add functionality to.
Like this one looks really good and has a lot of goodies but I don't see averaging, but good export support and maybe that's 1 step away from some cleanup and getting averages:
https://vitormhenrique.github.io/CurrentRangerApp/