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

Steve Davies steve at telviva.co.za
Sun Dec 13 21:38:12 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.
>

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201213/3ca40009/attachment-0003.htm>


More information about the OvmsDev mailing list