[Ovmsdev] Help me get my first data item on the I3

[Steve Davies]

On Sun, 13 Dec 2020 at 15:55, Steve Davies <steve at telviva.co.za> wrote:

>
>
> In there I can see "f1 10 09 62 dd bc 02 eb"   0x02eb = 747 = 74.7% - so
> there is the SOC. :-)
> and "f1 05 62 dd 68 93 88 00" 0x9388 = 37768 = 377.68 volts - so there is
> the battery voltage.
>
> So it looks like the receivepacket does need to be adjusted too - that f1
> I guess is OUR "extended address".
>
>
Well I put another nasty hack in PollerReceive and I have my first value :-)

D (576161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DD68],
expecting 6f1/607-607
D (576201) vehicle: PollerReceive[607]: process OBD/UDS response 22(DD68)
frm=0 len=2 off=0 rem=0
D (576201) v-bmwi3: BMWI3: got Volts=380.35V

I just did this so as to make the received packet look like a "normal" one :

  // SD: Hack to remove the extended addressing
  if (frame->data.u8[0] == 0xf1) {
    for (uint8_t i = 0; i<7; i++) {
      frame->data.u8[i] = frame->data.u8[i+1];
    }
  }

But my hack is no real solution - it was a test and shows that the poll
succeeds with the extended address included on the transmit and expected
(and removed) on receive.

So like you say the car can be supported with the help of support for
the ISO-TP
extended addressing scheme.

How to proceed?  I think it's better if you add the support since I don't
know the code well yet.  I can make a github issue.

But if you don't have time or inclination I can have a go myself since I'm
keen to make progress with this over the holidays.

Thanks,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201213/e32643ac/attachment-0001.htm>