<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I don’t have much information to be able to help. All I see is a screenshot of numbers. Also not really sure what you mean by ‘I got 16 bytes as reply’, as CAN frames are limited to 8 bytes total. Or are you talking about a multi-frame reply (ISO-TP, ISO15765)?<div class=""><br class=""></div><div class="">Simple PID request/response frames are not usually complicated. Simple byte ordering, byte boundaries, single value, and scaling by offset and multiplier/divisor.</div><div class=""><br class=""></div><div class="">But if structured data is being returned in a multi-frame response, or actively transmitted on the bus as a broadcast, then things can get more difficult - encoding can be big / little endian, and the values don’t have to start on byte boundaries or have lengths divisible by 8 bits.<br class=""><div class=""><br class=""></div><div class="">Can you break it down easier? For example, for the AmpHrs Chrg number, provide a textual canlog-monitor of the VCDS request and response, let us know the PID number requested, response received, and value shown in VCDS. You need to start by narrowing it down to a single request/response for a single known VCDS displayed value.</div><div class=""><br class=""></div><div class="">On the positive side, once you’ve worked out the encoding for one, the manufacturer normally uses the same style for all the others (at least from that one ECU).</div><div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 17 Aug 2020, at 3:45 PM, Soko <<a href="mailto:ovms@soko.cc" class="">ovms@soko.cc</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="content-type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">Hi,</p><p class="">I'm trying to find the correct value conversions from the CAN-Hex
values to the display values in VCDS. I cannot believe the values
I'm getting though so I'd like to ask you for help guys as I ran
out of ideas...</p><p class="">Its about the Ah and kWh charged and discharged. All 4 values are
at the same PID and I get 16 bytes as reply which suggests 4 bytes
per value. (I've already checked if there are other values in this
PID but there are not).</p><p class="">Here is what I've done checked so far:</p>
<ol class="">
<li class="">Swapping Ah data with kWh data. No luck as the conversion
factors are just other weird values</li>
<li class="">Looking for an offset from 0. No luck as the delta-section
below proves</li>
<li class="">As they are 4 bytes they may be no integer but float. Some of
you might already see by the hex values that it can't be float</li>
</ol><p class="">I'm very grateful for any thoughts as this just can't be right as
the conversion factor differs slightly with every day I'm taking
new data...</p><p class="">It might just be me interpreting the CAN-Hex data in a wrong way,
but I can't find the error.<br class="">
</p><p class=""><span id="cid:part1.F289B21E.52E26EF8@soko.cc"><gponehmpacgmdjkc.png></span></p>
</div>
_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></div></body></html>