[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