CurrentRanger_R3 Alternative Firmware with Peakhold and Averaging

[joffe]

Hello there. In need of (cheaply and quickly) estimating power consumption of a battery operated device, a CurrentRanger with the OLED display seemed to be a good option. The provided firmware however needed some tweaking to get that done. Maybe this is helpful to others so have fun with it  .

https://github.com/gruenfron/CurrentRanger_R3-PeakAvrg

Best regards

[Felix]

Quite interesting features you added, thanks for sharing this. I will try this out for sure.

From just what I've read, tt is maybe a little complex for the average new user or existing users who are used to the touchpad combinations of before 
The screen is a little too small to provide instructions, so a written guide like yours is somewhat necessary, i'd surely not guess how to use it  , or some very creative UI be made to guide the user.

Just a note - the OLED is actually optional as well, most people buy it with the OLED. When the OLED is not attached, the CR knows not to waste time sending data to it over the I2c port, that results in a bit less noise and no pausing between sampling when the OLED it up for refresh.

USB will be far faster than BT if speed is of concern so maybe it would be worth trying to improve USB sampling speed, which seems limited by the ring buffer in the bowels of the SAMD Arduino core.  A isolator is indeed required when there are multiple GROUNDs attached to the board in any combination.

I am open for other suggestions if you have any, thanks again.

[joffe]

Update: 1.3.0 is available, has added feature to toggle between displaying either averaged current (e.g. mA) or charge (e.g. mAh).

Quite interesting features you added, thanks for sharing this. I will try this out for sure.

Please let me know your oppinion .

From just what I've read, tt is maybe a little complex for the average new user or existing users who are used to the touchpad combinations of before 

The screen is a little too small to provide instructions, so a written guide like yours is somewhat necessary, i'd surely not guess how to use it  , or some very creative UI be made to guide the user.

That's true, however my colleagues understood it and when operated several times it is easy to remember.

Just a note - the OLED is actually optional as well, most people buy it with the OLED. When the OLED is not attached, the CR knows not to waste time sending data to it over the I2c port, that results in a bit less noise and no pausing between sampling when the OLED it up for refresh.

I have seen that and therefore the OLED check and handling if present is kept from your code.

I am open for other suggestions if you have any, thanks again.

For the current (pun?) design the best would be to do ADC sampling from DMA/IRQ to get as much as possible clean equ-distant data which then could be decimated to the capabilities of the according logging output.

[Felix]

Your firmware is now vastly different than the base firmware so it will take me a while to get to this and decide what to integrate.
I do like some of the features you added and I think they're useful. Not sure about inverting the inputs after all this time, it's more a matter of preference. I do feel there is a bit too much beeping, I do understand your intent to use it as a DMM in ranging mode.

Yes DMA would be nice. A while ago I worked on a firmware with DMA without all the functionality in the base firmware. I can't remember why I put it aside (unstable?). I would be interested to get DMA to work well of course.