[Ovmsdev] Weirdest value conversion ever

[Mark Webb-Johnson]

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)?

Simple PID request/response frames are not usually complicated. Simple byte ordering, byte boundaries, single value, and scaling by offset and multiplier/divisor.

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.

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.

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).

Regards, Mark.

> On 17 Aug 2020, at 3:45 PM, Soko <ovms at soko.cc> wrote:
> 
> Hi,
> 
> 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...
> 
> 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).
> 
> Here is what I've done checked so far:
> 
> Swapping Ah data with kWh data. No luck as the conversion factors are just other weird values
> Looking for an offset from 0. No luck as the delta-section below proves
> 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
> 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...
> 
> It might just be me interpreting the CAN-Hex data in a wrong way, but I can't find the error.
> 
> <gponehmpacgmdjkc.png>
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200818/122c4311/attachment.htm>