Calibrated reference consumption drifts to zero

[DNS79]

Good day,

I have set up the link to ABRP on two OVMS, and the live connection is working so far. However, I have the phenomenon with both cars that the "calibrated reference consumption" drifts towards zero over time. I have already reset it to the reference value twice, and it’s always the same. Does anyone have an idea what could be causing this? The only peculiarity I have is that my GPS is deactivated/not connected; could it be related to that? Is GPS absolutely necessary?

Another point I notice is that the value performance is not displayed plausibly in the diagram.

Best regards,

Daniel

[DragonEndeavour]

Hi Daniel, I also had that problem with my smart ED4 forfour, I'm currently testing a patch lowering the minimum calibration speed for ABRP so the timeout will be 5s instead of the nearly 2 minutes of normal driving. This is because my usual journeys imply a lot of urban driving and/or lots of traffic jams which I think it's messing with the energy consumed by kilometer. I don't know if that would be the same case for you, but for now the solution seems to be working.

It's worth mentioning that I don't have ABRP premium so I can't see any historical data because I'm still testing the app. Also I have another smart fortwo ED3 wich didn't have the issue, but I also did the same workaround as it's use is the same.

Hope this helps and I will try to update if anything changes as this is some recent changes.

Best regards, Nick.

[jason-abrp]

@DNS79 - your plot loooks like a charging event. Consistent negative power at -1kW and SoC rising slowly. If that's not marked correctly as a charge (is_charging=True), that could definitely throw off the calibration. I'd be happy to take a closer look at your vehicle's data and see if I can identify what's going wrong. Shoot me an email at jason@abetterrouteplanner.com with your details and I can help you figure it out.

@DragonEndeavour - Our calibration should be speed independent, but it is pretty sensitive to data quality. If we get really infrequent updates, and the speed and power are matched poorly in time (IE, big gap between the speed and power measurement) it can throw off the calibration. That's especially a problem for in-town driving, as your speed varies quite a lot, so a time mismatch is more significant there.

[jason-abrp]

@DNS79, @kezarjg - After looking into the data from the ForTwo and ForFour, a probable culprit seems to be the current measurement's sign. The bulk of the power readings going into consumption calibration are negative, with a relatively small number of positive readings close to where we'd expect to see regeneration occurring.

In calibration, we expect negative power for regeneration, and positive power for consumption.

[kezarjg]

@DNS79 @DragonEndeavour Can you mention what version of OVMS firmware you are currently using?

[kezarjg]

Updated I've corrected this comment with on-device telemetry captured from both cars while driving. My original source-only reading had the sign backwards; the device data resolves it:

v.b.power is the inverted metric on both smart modules; v.b.current is correct.

Since ABRP uses power when it's available (thanks @jason-abrp), the inverted power is exactly what drags consumption calibration toward zero.

Conventions at a glance

Convention	Positive means	Negative means	Current	Power
OVMS core (metrics_standard.h)	output / discharging	input / charging	discharge +	discharge +
Iternio / ABRP	output / discharging	input / charging	discharge +	discharge +

Both agree: positive = output (discharging), negative = input (charging) - for current and power alike. The two metrics should share the same sign.

SQ - smart 453 / forfour (vehicle_smarteq)

// eq_can_poll.cpp, PollReply_BMS_BattState()
float i_pack = (float)cur_s / 32.0f;                     // raw pack current
float pack_power_kw = (v_pack_term * i_pack) / 1000.0f;  // P = V * I_raw
StdMetrics.ms_v_bat_current->SetValue(i_pack * -1.0f);   // current: raw negated
StdMetrics.ms_v_bat_power->SetValue(pack_power_kw);      // power:   uses raw

Metric	Assigned	Matches core / Iternio?
v.b.current	-i_pack	Yes (device data)
v.b.power	+v*i_pack	No - inverted

The device data shows the negated current is the one that matches driving (= discharge), so raw i_pack is charge-positive on this hardware. Negating it fixes current, but power is built from the un-negated i_pack, so it ends up inverted. (My earlier table had this backwards - I'd assumed raw i_pack was discharge-positive.) The read site in vehicle_smarteq.cpp already documents the intended sign as // kW (pos=discharge, neg=charge) - the write site just isn't honoring it.

Fix: negate power at the write site -> SetValue(pack_power_kw * -1.0f).

SE - smart 451 / fortwo (vehicle_smarted)

// frame 0x508 (HV ampere)
HVA = (float)(d[2] & 0x3F) * 256 + (float)d[3];
HVA = (HVA - 0x2000) / 10.0;
StandardMetrics.ms_v_bat_current->SetValue(HVA, Amps);   // current: raw HVA

// frame 0x448 (HV voltage)
float HVA = StandardMetrics.ms_v_bat_current->AsFloat();
float HVP = ((HV * HVA) / 1000.0) * -1.0f;               // power: V * I, then negated
StandardMetrics.ms_v_bat_power->SetValue(HVP);

Metric	Assigned	Matches core / Iternio?
v.b.current	+HVA (raw)	Yes (device data)
v.b.power	-(v*HVA)	No - inverted

Device data shows raw HVA is discharge-positive (correct), and the * -1.0f on power flips it the wrong way. My earlier note said this one was "unverifiable from source" - the on-device capture verifies it.

Fix: drop the -1.0f -> HVP = (HV * HVA) / 1000.0.

[jason-abrp]

We use power, if available, otherwise derive it from voltage & current.

[DNS79]

@DNS79 @DragonEndeavour Can you mention what version of OVMS firmware you are currently using?

Hi,

3.3.005-3-g4f3f7688

[DNS79]

Hi, can this be adjusted so that it works? I don't seem to be the only one experiencing this:

Aktivierung OVMS -> Bluetooth -> ABRP

Best regards,

Daniel

[kezarjg]

@DNS79 @DragonEndeavour - good news: I put together a fix I'd love you to test.

What was wrong: on both smart modules (453/forfour and ED/fortwo), OVMS reports the battery power with the sign flipped - it reads negative while you're driving (consuming) instead of positive. ABRP uses power for its consumption calibration, so it was treating your driving as regen, which is what drags the calibrated reference consumption down toward zero.

The fix (draft PR #44): the plugin now corrects the power sign for these cars. It's built to be safe across a future firmware fix - it takes the power sign from the battery current (which OVMS reports correctly), so it fixes things now and simply does nothing once the underlying firmware is corrected.

• PR: fix(smart): correct inverted v.b.power sign on SQ/SE (issue #40) #44
• Download the updated abrp.js: https://raw.githubusercontent.com/kezarjg/ovms-link/34c3d2728247d5f481909f1d46045ae3e60f8212/lib/abrp.js
  (right-click / save as abrp.js)

To test: replace your existing abrp.js on the module with this file (OVMS web console editor, same location you installed it originally - see the README install steps), then script reload or reboot. Nothing else changes; your token/config stay as they are.

What to look for:

1. While driving, battery power should now read positive (you can check metrics list v.b.power in the console, or watch it in ABRP).
2. Over your next few drives, the calibrated reference consumption should stop drifting toward zero. If yours has already collapsed, you may want to reset it to the reference value once more after installing, then let it recalibrate.

If you can report back after a drive or two (especially whether the reference consumption holds steady now) that would be a big help in confirming the fix before it's merged.

[stumbaumr]

I have measurements for that...

Car is currently away... have to wait for its return to apply your fix... it is nearly impossibe to edit files over the remote cli... that is why #38 would have been so useful!!!

[stumbaumr]

Thanks for creating
openvehicles/Open-Vehicle-Monitoring-System-3#1468
and
openvehicles/Open-Vehicle-Monitoring-System-3#1469

[kezarjg]

#38 is part of 3.x... I took my first trip this weekend to test it out. It's almost ready for others to test.