[Ovmsdev] Help me get my first data item on the I3
Steve Davies
steve at telviva.co.za
Sun Dec 13 19:09:31 HKT 2020
On Sun, 13 Dec 2020 at 12:34, Michael Balzer <dexter at expeedo.de> wrote:
>
> 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.
>
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.
IE in the example of the SOC -
static const OvmsVehicle::poll_pid_t obdii_polls[] = {
// TXMODULEID, RXMODULEID, PID, { POLLTIMES }, BUS
{ 0x6f1, 0x0607, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xDDBC, { 60, 60, 60
}, 0 }, // SOC
{ 0, 0, 0x00, 0x00, { 0, 0, 0 }, 0 }
};
So the extra byte would need to be RXMODULEID&0xff => 0x0607&0xff = 0x07
Does that seem reasonable?
That seems to be consistent over all the queries I looked at in my traces.
It isn't always 0x07 - I'm pretty sure it is to do with which ECU we are
talking to.
(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.
Note also that the flow control frame sent in reply to First Frames also
needs to be formatted this way.
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.
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.
If you want to change it in a branch I can pull that branch into my fork
and take it from there.
Thanks,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201213/bcce46eb/attachment-0001.htm>
More information about the OvmsDev
mailing list