On Sun, 13 Dec 2020 at 12:34, Michael Balzer <dexter@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.

I don't think that the extra byte is included in the replies. (Would help if I could get a reply...):

I'm not sure how your time and priorities go - so I started poking around.

I hacked at vehicle.cpp to send it in this format. (Not a committable change, I just hard-coded it)

V (250161) canlog-monitor: 1607862592.210593 1T11 6F1 07 03 22 dd bc 00 00 00

Frustratingly I'm still not seeing a response logged.

(I do see a steady flow of what I assume are idle frames:

V (1868881) canlog-monitor: 1607865104.942289 1R11 130 00 f0 fc ff ff

V (1868981) canlog-monitor: 1607865105.042269 1R11 130 00 f0 fc ff ff)

I haven't done anything to fix the flow control packet format, so I thought that might be the problem.

So I tried another one that returns a single frame response - Battery voltage:

V (102161) canlog-monitor: 1607863338.229125 1T11 6F1 07 03 22 dd 68 00 00 00

Also no reply.

Is the CAN bus on the OBD-II port a bus? Can I connect both my bluetooth dongle and the OVMS to it and then capture what the other app does right in OVMS and as it sees it?