Mismatch Smartshunt 500A and specifications

Q&A and troubleshooting
, ,
21

Hi,

there are basically two accuracy criteria in a smartshunt. One is the smartshunt resistor accuracy which will give a constant % accuracy across all current ranges. The other is the accuracy of the A-D converter. On top of that is the resolution, which is actually pretty arbitrary and should be ignored. The datasheet and the manual suggest ±0.3% voltage and ±0.4% on current. This suggests a resistance accuracy of about 0.01% (a reasonable value). The A-D resolution is best found by measuring very small currents. The datasheet implies 10mA on the 500A version or 20E-6 or 50,000:1 which is very close to that expected from a 16bit AtoD which are as cheap as chips.

Its likely that since input and output go through the same systems (particularly the shunt resistor) that in-out inaccuracies cancel which is probably why Amp-h and SOC% are quoted as 0.1.

If you are to check the accuracy then it is important to use a measuring device with lab accuracy, most multimeters struggle to manage 2% on some ranges.

Anyway my 2 cents worth.

Personally, I believe the shunt and totally disbelieve the other data coming from victron devices. Not least I suspect they measure at the inputs (solar) and outputs (inverters) and this ignores the rather significant 9% (in my system) inverter losses each way. That is from solar through/past battery to inverter results in an 18% energy loss on average, and equally charging from mains then using it later also results in an 18% loss. My guess is battery losses, for moderate charge rates, are about 2% round trip, surprisingly low.

22

Thx for your responses guys. Helpful. Regarding the remarks of Geert-Jan; dont mix up the measurment power consumption of the shunt with all the other measurements. It’s totally independent of the rest. The power consumption of almost 4mA was simply measured with a good desktop DMM. This is not a difficult measurement and can be repeated by everyone with a fair multimeter with some accuracy (Fluke, Brymon, some UNI-T’s, Rigol etc) If someone has other readings I’m glad to know.

Regarding the other measurements it’s always good to specify the measurement error by the equipment. As the shunt is simply consisting of 2 pieces as Farmeroz explains (I’d like to say 3; the shunt itself, which is nothing more than a known resistor, then the electronics consisting of a accurate voltmeter to measure the Voltage across the resistor and an AD converter to convert the reading into the digital domain) there can go three things wrong. First, the resistance of the shunt can be off and that will be linear across the whole spectrum. Second, the measurement of the voltage drop and three, the AD conversion. I’m not an expert on AD’s and accuracy of voltage measurements, but imho these two are more or less the most easy to do good with today’s state of technology.
The DMM used for reading the voltage drop over the shunt in my case is quite precise. It has an accuracy of 0.025% in this reading and goes to 0.0001 millivolts resolution. So the total measurement failure in this reading domain is worst case scenario 10uV. But that’s the worst case scenario. Most of the times this DMM has proven to be a lot more precise than it’s max fault tolerance. But, okay, we have to take this into account. As we have to take into account the measurement of the current by the Fluke, which has an error of almost 2% in this domain of currents. That means that for e.g. the first measurement it can be 1.02A, but also 1 or 1,04. That was also the reason to do it this way; the current source checking with the Fluke for accuracy, if they align more or less then probably they are both performing within specs.

But now comes the funny part. If you look at the mV readings over the shunt done by this measurements and the current the shunt calculates. That’s almost 1 to 1 related!. So, my idea/conclusion is that the voltage measurement and AD conversion of the shunt is quite accurate (just like the voltage reading of the DMM, which seems to be quite accurate here), and the shunt calculates with a resistance of 0,1 mOhm as it looks like. And because of this, it’s not a weird conclusion I think that the digital resolution of the shunt is rather okay, but if the base (the resistor) is a little bit off, you get results which are a little bit lower on every range. So, that’s all guys, I just think only the resistor of the shunt is not quite as good as it can be and therefor these results apply. Let me know where I go wrong.

23

My two cents here: You’ll note that the resistor of the shunt is usually “tuned” by one or more small cuts (sometimes large cuts) in the fins; sometimes the tuning isn’t precise, and minor variations occur.

Personally, I look at it as pretty good and pretty accurate for a ~$100 USD measuring device; my Fluke cost about 5 times as much, and is -as I would expect- much more reliably precise. When one needs a high-precision instrument, one pays for a high-precision instrument, but in the meantime for an average-use battery monitor I think the SmartShunts in general do pretty well considering their low cost.

24

Basically, there is an inherent problem when managing/measuring/charging victron systems. There is with others too, but concealed, which is worse. That problem is where you measure and for what purpose. 16bitAtoD are cheap as chips and so are accurate enough shunts (with calibration a bit of PCB circuit board track is sufficient). However, a mains connected inverter needs to be measuring the power at the mains connection to manage mains interaction within legal regulations. It cares not for the actual input power and probably doesn’t even measure it to any great accuracy (enough to prevent damaging connected equipment settings). A solar is equally not very interested in details of charging the battery. Unfortunately the battery really cares a lot about getting over or undercharged so modest accuracy inadequacy in solar or inverter/charger can be quite damaging if cumulative errors build up. Hence the wish for weekly 100% charging and a general wish (reading between the lines) to keep batteries at about 50%+ capacity. Sadly (take it from me) this is not quite good enough when you run independently of grid (eg off batteries with charging done when convenient via solar or low priced grid) even if you always do a full charge weekly. The killer is the 9% inverter inefficiency (not the 1% to 2% of batteries) which I do not think is not compensated for anywhere in the victron software. I don’t think there is any compensation at all, which is bad. They should at least deduct their expected losses for each passage through an inverter/charger/mppt etc in each direction. It should also be made clear that reliable charging and discharging of batteries (and SOC etc) can ONLY be done using an appropriate shunt.

Also (in passing) they should include the use of a shunt (ie use two shunts in any system) to measure external DC energy flow from ‘outside’ sources.

25

There is really nothing to see here, the results of the accuracy are to be expected at low amp draw.

When comparing the Victron shunt accuracy to other manufacturers shunts, I have found that the Victron shunt is just fine.

There are systems from different inverter manufacturers where the users have added a Victron shunt to compare accuracy for state of charge. The consensus is the Victron shunt is more accurate than the other manufactures.

26

In maritime applications, and that’s where these shunts are being used a lot, we normally are working with small currents for the household system. Refrigerator, VHF, navigation lights and plotter. Most of the times we live in the 3-8 A range. It almost never happens that we use 100A at once, yes, maybe for a while when making coffee or something. Then the inverter (if the boat has one) get’s started, but normally inverters are off and we use the 12V boardsystem as powersource. So accuracy is important. In this particular case the shunt has not been calibrated I think. There are no ‘cuts’ in the metal like there are in my production shunt. And that’s probably the reason the resistance is 2,4% lower than it should be. And thus the voltage drop over the shunt is 2,4% lower than it should be. And thus the reading is 2,4% lower than it should be. The electronics however are within their 0,4% specs; the measured voltage over the shunt and the conducted current reading are all within their 0,4% specs.
Why I think this is important and the reason I started digging? Just because I was expecting my LifePO4 build batteries would read around 330Ah after finishing and testing. And I was only reading 324 a 325Ah. And there my 2,4% difference is again. If the shunt reads 2,4% more current, the expected outcome would have been reached. (Each separate cell had been measured at 330 a 331Ah with a dedicated cell tester.) No one likes to loose 5 a 6Ah when testing with new cells. So, that’s the reason I started looking for the reason. And I think I’ve found it.
By the way; I might try to trim the shunt myself. With a small cut out of the shunt I likely would be able to get it more to the 0,1 mOhm. Sounds like a nice experiment to me :slight_smile:

27

Shunt measurement at low amperage is a problem with alot of BMS management systems as well. I would think given that it affects more than one application that there is more to it than a simple measurement.

Than being said, how long was the test and bms own self consumption and conversion can also be affecting this.

28

Why would that be difficult you think?

29

Not sure. Never really looked into it. It is juat an observation from experience with low current draws.

I have one battery bank with 12 batteries and when the system idles at night (or has a low load relative to size) the soc can stay up at 98% and then suddenly it is at 70%. If i work it out its pretty close to where it should have been. Its almost like is doesn’t ‘see’ the low discharge and then suddenly realised the voltage is too low and then works out sort of what it should be.

It has happened on more than one battery make as well. So not a quirk of one battery. If you want to check out the jk bms complaints the issue is there too.
(I worked out the draw would be about ½-2 amps on this one instance per battery. And there is a shunt on the bms board.)

30

These days it’s easier than ever to measure very low voltages. Look at the most common BMS, which has rather accurate voltage measurement for guarding each cell. The JK’s are accurate to a thousand of Volt. So imagine a really good DMM, which can measure up to uV. Not that hard anymore. And, let’s keep in mind, in this case, the Victron does a terrific job in measuring the voltage drop across it’s shunt. If you look at the test results, the measured voltage drop which leads to the current follows the current almost one on one, that cannot be any coincidence. So, that’s not the problem here. But(!), if the resistance of the shunt is a little off, all measured voltages will be translated to a wrong current. I’m more or less convinced that this shunt will be spot on if I make some small cuts in the shunt to match it to it’s 0.1mOhm.

(Regarding very small currents, less than 0,5A or something, I recognize what you say. And yes, JK BMS is a horror in getting the current consumption right. They are terrible. If you calibrate at 10A, then everything is wrong at lower and higher currents. You keep calibrating these things. But that’s a complete other problem)

So, my idea right now is that Victron is more than capable to be within the 0,4% margin, IF the shunt resistance itself was spot on. In this story I’m convinced the problem lies in the wrong (or not tuned?) shunt itself and not in their electronics. Let me try to prove that by tuning this shunt myself by making small cuts. Because I can’t go back, I have to be very careful. Will be a nice project I think :slight_smile: All, best wishes for 2026!

31

I think one of the reasons smartshunts are so popular is they can see the small currents that battery bms tends to struggle with. So their soc percentage can diverge significantly from reality. Having the smartshunt soc available to truly trust as a reference while battery bms loses its mind is reassuring.

32

@mystudio

What is the serial number of the SmartShunt?

With kind regards,
Thiemo van Engelen

33

Hi Thiemo,

S/n is HQ2308VJVQA

Thx in advance.

34

Sidestep in this story, but I think its good to mention because it became a part of the story. LX, do you see those weird SOC changes only on the BMS?
For some days I’m measuring the ability to register very low currents with the Victron BMS702 with shunt and bluetooth module in my production setup (sailing boat, LifePO4 batteries). It’s winter, no sailing, all is at rest aboard. But, the shunt does a fantastic job in monitoring the SOC imho. The current drawn these months is only the consumption of the JK BMS and the BMV702 with bluetooth add-on. So the consumption is only a few mA, a wild guess 100-200mAh per day. (will measure it soon, when it’s a little bit warmer). Although the 702 does not show any drawn current (mA are not visible, tresholds etc), it DOES register, because every few days the SOC is a little bit lower and also the consumed current is a little more. So, how exactly they do it I don’t know, but it appears to be that the Victron shunts are more than anything capable also to monitor very little changes in SOC. Yoehee!

For reference the figures of the last week:

5/1: SOC 63% Consumed Ah: 121.0 Ah
3/1: SOC 64% Consumed Ah: 120,5 Ah
2/1: SOC 64% Consumed Ah: 120,3 Ah
31/12: SOC 64% Consumed Ah: 120.0Ah

35

Completely OT, but, now I’m monitoring the SOC state every day, I’m a little bit surprised that as well the BMV702 do register the own consumption as well as the JK BMS does a rather good job in registering the very low decrease in SOC caused by the consumption of the BMV and the BMS itself. The only thing is it’s not constant, but they do decrease every day a little. But okay, thats OT, back to the shunt. Tomorrow I’m gonna ‘tune’ it with the Dremel. Let’s see how that works out!

36

Okay, don’t want to sound stubborn, but made some small cuts today in the shunt (just like my earlier shunts have) to trim it exactly to 0.1 mOhm. And, it works. It is spot on now! For the ones that might want to know how I did it; I did it live, with current through the shunt to see how many small cuts I had to make to trim it. I guess Victron does it the same way normally, measuring while cutting. Don’t know, but that sounds fair.

shunttrim
shunttrim481×640 80.3 KB

Guess the warranty is gone now :wink: But, never mind, it’s accurate as hell now. Measuring of the voltages, even very small ones, were accurate if you calculated with the odd resistance the shunt had. It was not exactly 0.1 mOhm. But now it is! I’ve checked it to around 150A and all is within specs now. The only thing which is not clear to me yet, is the power consumption, which is far higher than the datasheet advertises. That might be an firmware update thing for the near future. Thx for thinking along with me!

37

Very interesting thread. I came to it because my SmartShunt shows small currents in the VRM portal with 0.1A resolution, even though the datasheet says the resolution is 0.01A. The official software on Venus OS rounds the value before it reaches D-Bus. This bothered me enough that I wrote a script that checks what exactly the shunt sends over VE.Direct interface.

Turns out, the actual resolution is 1 mA! Accuracy is another question (I don’t know it beyond the datasheet number), but the way I display it now definitely looks better to me than “-0.10A” or “-0.20A” I had before. I had to solve a bunch of software issues on the way to read it reliably on Cerbo, I can share the details if anyone is interested (you’d need some software development skills for integration). Overall this took me 2 days with help from LLMs.

I wonder if the official decision to round the current for D-Bus was because it’s not that accurate, or for some other reasons. If anyone has any further information about accuracy beyond what’s in this thread already, I’d be very interested to hear that.

38

Please do

39

Disclaimer first: everything I mention here is at your own risk. It works on my system, but I can’t tell if it will work on yours, use your judgement.

You’ll need SSH access to your GX device (as a new user somehow I can’t post links here): victronenergy. com/live/ccgx:root_access

Proof of concept

I’ve attached a proof of concept script you can run on the GX device to read the data.

First you’ll need to identify which port the shunt is on. It should be one of these ports:

ls /service | grep vedirect

Normally, vedirect service reads the shunt data, and it doesn’t let other processes read it at the same time. So the correct port will be the one you can’t read from (for now). In that case the script outputs “SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)”.
In my case on Cerbo GX MK2, the port labeled “VE.Direct 1” turned out to be /dev/ttyS7.

I first tried a simple option: stop the service, run the script to see if I can read the data, and then start the service again:

svc -d /service/vedirect-interface.ttyS7
python ~/read_shunt.py --port /dev/ttyS7
svc -u /service/vedirect-interface.ttyS7

It should show something like in the attached output.txt, repeating every second.

Reading alongside vedirect service

If you’re ok with vedirect service not running for the shunt, that’s all then and you can skip to the Integration section below, but I still wanted it to run, so I split the TX and GND wires from the shunt into a separate USB TTL adapter, so that I get a mirror of the data on a different port. I used an isolated adapter based on FT232RL. I bought one that supports both 5V and 3.3V. Turned out in my case the shunt is using 3.3V. The connectors are JST PH with 2mm pitch, so I just made my own cable, but I guess splitting an existing one would work too. GND and V+ are easy to find with a multimeter, they’re on the sides. TX and RX wires cross from one end of the cable to the other end. I found TX from the shunt by checking which wire had non-zero fluctuating voltage. To the adapter I connected only TX from the shunt (to adapter’s RX) and GND, nothing else.

Resolving interference issues

After everything is connected, the GX device should still see the shunt as usual, but now the data is also readable from the port the adapter is plugged in. In my case it was /dev/ttyUSB0. However, when you run the script you might notice it frequently outputs “Interference detected” errors. I believe serial-starter is the culprit, it tries to run various services over and over again to see which one can identify the plugged in device. I tried reprogramming the vendor and product IDs on the adapter so that it doesn’t get recognized by serial-starter, but even if I use some obscure IDs and change the adapter description, serial-starter still interferes, so I suspect it starts for all IDs that the FTDI driver supports. The remaining option was to disable serial-starter for this particular adapter, using the adapter’s serial number (or you can try some other attributes if your adapter doesn’t have a serial number):

Get the serial number of the adapter:

udevadm info -a -n /dev/ttyUSB0 | grep ‘{serial}’

Create a rule to stop serial-starter from interfering with a device with this particular serial number, and optionally add a /dev/ttySH symlink. Make sure to replace YOUR_SERIAL_HERE!
In theory since this is in /data directory, it should survive software upgrades, but I haven’t tested that.

mkdir -p /data/etc/udev/rules.d
cat > /data/etc/udev/rules.d/10-ignore-shunt-secondary-adapter.rules << ‘EOF’
ACTION==“add”, SUBSYSTEM==“tty”, ATTRS{serial}==“YOUR_SERIAL_HERE”, ENV{VE_SERVICE}=“ignore”, SYMLINK+=“ttySH”
EOF

Then run nano /data/rc.local to add the following lines to /data/rc.local, so that the rule gets applied on startup and force-triggers udev to re-process tty devices. This applies the new rule to the already-connected USB adapter.

ln -sf /data/etc/udev/rules.d/10-ignore-shunt-secondary-adapter.rules /etc/udev/rules.d/
udevadm control --reload-rules
udevadm trigger --action=add --subsystem-match=tty

Reboot the GX device:

reboot

Now you should see a new symlink /dev/ttySH, and the script should be able to read from it without interference (or from the original /dev/ttyUSB0 if you prefer that).

Integration

The code from the script can be integrated into the system, for example into dbus-serialbattery or dbus-aggregate-batteries that already implement the Battery Monitor code. They’re open source, so instead of the current value they use, the code can be edited to pass the high-resolution shunt current (and SOC or other values if needed). Then the script becomes a part of a proper battery monitor with all the privileges of getting these measurements to the rest of the system. The current shows up on the GX device and in the VRM portal. One note is that even if you pass the current with mA resolution, GX device rounds it to one decimal place and VRM to two. This is a separate UI limitation of the GX device and VRM themselves. I don’t know if there are any solutions to it, but I’m ok with it. Edit: for example, here’s the integration for dbus-aggregate-batteries: Add support for reading SmartShunt current with 1 mA resolution · dmitrych5/dbus-aggregate-batteries@b96f5ef · GitHub

With this setup, it should be easy to compensate for wrong shunt resistance in software and add other custom logic or calculations.

What I’m really curious now is what accuracy can be achieved on practice, both at very small and large currents, by reading this high-resolution data and compensating for shunt resistance and maybe temperature (I don’t know if this is needed). At what point would it get limited by noise and other factors out of our control.

output.txt (281 Bytes)

read_shunt.py.txt (5.2 KB)

40

I tried calibrating a JK BMS several times and, based on what I’ve seen, I’m starting to suspect that it also has a problem with temperature.
I think JK BMS current readings are seriously affected by the local temperature in the BMS.