<div dir="ltr"><img src="https://api2.activeinboxhq.com/1.0/anon/rr/874e2f812c0bddf5a95d023e0c857bf4" width="1" height="1" style="display:none !important"><div dir="ltr"><img src="https://api2.activeinboxhq.com/1.0/anon/rr/874e2f812c0bddf5a95d023e0c857bf4" width="1" height="1" style="display:none !important"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 13 Dec 2020 at 12:34, Michael Balzer <<a href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div><br>
    But it shouldn't be hard to add support for this, as it basically
    just fills the first frame byte from the lower 8 bits of the TX and
    RX IDs, reduces the payload size by one byte and shifts the offsets
    by one. PollerSend() and PollerReceive() need to be extended for
    this, and poll_pid_t needs to be extended by an addressing scheme
    tag.<br></div></blockquote><div><br></div><div>In my inspection of traffic it seems that when we send the request frame this extra byte is always set the same as the bottom 8 bits of the RXMODULEID.</div><div><br></div><div>IE in the example of the SOC - </div><div><br></div><div>static const OvmsVehicle::poll_pid_t obdii_polls[] = {<br>  // TXMODULEID, RXMODULEID, PID, { POLLTIMES }, BUS<br>  { 0x6f1, 0x0607, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xDDBC, {  60, 60, 60 }, 0 }, // SOC<br>  { 0, 0, 0x00, 0x00, { 0, 0, 0 }, 0 }<br>};<br></div><div><br></div><div>So the extra byte would need to be RXMODULEID&0xff => 0x0607&0xff = 0x07</div><div><br></div><div>Does that seem reasonable?</div><div><br></div><div>That seems to be consistent over all the queries I looked at in my traces.</div><div><br></div><div>It isn't always 0x07 - I'm pretty sure it is to do with which ECU we are talking to.</div><div><br></div><div>(I'm guessing it's some "route" to the ECU being queried since on the i3 there are lots of buses and the OBD isn't directly connected to any of them - the OBD goes to the body domain controller which connects in turn to the other buses.</div><div><br></div><div>Note also that the flow control frame sent in reply to First Frames also needs to be formatted this way.</div><div><br></div><div>I'm starting to understand why someone involved with the development of an Android app that can handle i3 OBD2 was full of dark hints of trouble ahead.  OTOH, it would have been nice if he'd actually shared info and not just mysterious hints.</div><div><br></div><div>If you could deal with this for me I'd be very grateful - I'm new to the code and also I'm not an experienced C++ programmer so I'd hate to send you a nasty PR.</div><div><br></div><div>If you want to change it in a branch I can pull that branch into my fork and take it from there.</div><div><br></div><div>Thanks,</div><div>Steve</div><div><br></div><div><br></div></div></div>