[Ovmsdev] Duktape Vehicle

[Michael Geddes]

Thanks Michael,
.
That's helped a lot in refocusing my approach

12v Aux Monitor:
-----------------------
I have been looking at the 12v Aux monitor code, in addition to
simplifying the monitor to use 2 smoothed averages (a shorter one and
a longer one), I've also looked at using my smoothing class at the
source of the battery voltage measurement (smoothing the source
integer value).

Interestingly, I notice that there are a couple of vehicle
implementations that are setting that value as well.. which I'm not
sure is a good thing!?

For the 12V monitor I have a version that I'm working on that tries to
match the  other 12V events and messages. It might be worth me just
submitting that as the p/r.

I have the following events:

vehicle.aux.12v.normal
vehicle.aux.12v.charging
vehicle.aux.12v.charging.dip
vehicle.aux.12v.charging.blip
vehicle.aux.12v.blip
vehicle.aux.12v.dip
vehicle.aux.12v.low
.
with these 'dip' is where the voltage has a bit of a trough, and
'blip' indicates there is a spike.

Extended DBC
-----------------------
I take your point about the speed, so I'm working on a better idea).

I have been going over the DBC stuff.. I've been implementing the
extended multiplexers (m98M), which is necessary _if_ the DBC file is
going to interpret the multi-frame reponses. I've also consolidated so
there is only one piece of code (now on the DBC Signal) interpreting
the Muxed data, which handles either going to metrics or to a writer.

Extended Multiplex example (with M,  m98M and m256) and the SG_MUL_VAL
to link and provided extended ranges.

BO_ 1979 Temperature: 54 Vector__XXX
 SG_ IndoorTemperature m256 : 79|8 at 0+ (0.5,-40) [-50|50] "degC" Vector__XXX
 SG_ response m98M : 23|16 at 0+ (1,0) [0|0] "unit" Vector__XXX
 SG_ service M : 15|8 at 0+ (1,0) [0|0] "" Vector__XXX
 SG_ OutdoorTemperature m256 : 87|8 at 0+ (0.5,-40) [-50|50] "degC" Vector__XXX
 SG_ VehicleSpeed m256 : 271|8 at 0+ (1,0) [0|200] "kmh" Vector__XXX

SG_MUL_VAL_ 1979 IndoorTemperature response 256-256;
SG_MUL_VAL_ 1979 response service 98-98;
SG_MUL_VAL_ 1979 OutdoorTemperature response 256-256;
SG_MUL_VAL_ 1979 VehicleSpeed response 256-256;

I have it now that the UNITS specified in the DBC file are used when
setting the value.  If they match our internal unit strings they will
be set using that unit.
I also implemented the VAL_TABLE_  lookup (which seems to have been
partially implemented) to store status strings.

I'm yet to find time to test all this to make sure nothing is broken
and that the new stuff works as intended!!

The interesting part of that is that looking at a DBC implementation I
noticed that there's a difference between how the DBC wants to look at
the multi-frame data and how we look at the data coming in (which is
similar to the Torque+ one), which is that DBC files see the
multi-frame data as all the 8 bytes of frame packet data concatenated
together (which includes the PIDs), whereas the other way looks at it
as a PID plus the concatenation of the payload (5 + 7 + 7 or whatever
it is).  Also the DBC file looks at bits rather than bytes. (Torque+
specification has the ability to get flags out of a byte).

What do you think of the idea of moving the DBC interpreting to the
Poller class away from the DBC vehicle implementation?  The DBC
vehicle can still auto-load the files but the poller would be
responsible for seeing a DBC pointer and interpreting the signals.  It
kind of has to because of the multi-frame data.

For multi-frame data I'm looking at a variation to ObdRequest() call
that would cause the extended packets to be sent to the DBC file to
interpret (sending the concatenated 8 byte packets of payload).

Extending DukTape OdbRequest()
-----------------------
The ObdRequest() duktape calls should probably reside on the Poller
rather than the vehicle.

It might be preferable to be able to call ObdRequest() with a
call-back rather than the blocking call that happens now.  The
non-blocking one-off OBD calls are supported by the new poller
framework.

I'm also thinking that it would be good to have a separate mechanism
that could add entries to the poller list.  I'm also wondering whether
a different way of specifying the data would be useful (via DukTape)..
using the Payload concatenated bytes, the great thing is we could
still use the DBC code to interpret the signals. (we could have a map
of dbcSignal per address + PID).

Thoughts?

//.ichael
-----Original Message-----
From: OvmsDev <ovmsdev-bounces at lists.openvehicles.com> On Behalf Of Michael
Balzer via OvmsDev
Sent: Sunday, 1 September 2024 4:04 PM
To: ovmsdev at lists.openvehicles.com
Cc: Michael Balzer <dexter at expeedo.de>
Subject: Re: [Ovmsdev] Duktape Vehicle

Michael,

detecting 12V indications for ECU operation is generally a framework
candidate, as there have been multiple vehicles that (at least
initially) needed to rely on this. It's in the same category of framework
features as the 12V monitoring. Providing the info to the vehicle can be
done using the same scheme as other vehicle framework hooks do, and if you
include events for crossing the hysteresis boundaries, it's also easy for
scripts to hook into this.

Regarding a full Duktape based vehicle implementation, that needs more
framework support, especially for automated CAN polling with preprocessing &
storing the responses, as Duktape is too slow for high speed low level
operations like this (there's also the single thread limit). The DBC vehicle
is a precursor or possibly a base for this. The DBC approach currently
supports defining a fixed message to metrics translation, which can provide
basic vehicle data decoding. It lacks a way to define polling schemes and
possibly poll state transitions.

Poll state/list transition handling might then be delegated to the Duktape
extension. Duktape can also be used to process CAN data/responses/states
that are too complex for simple metrics translations, it just needs an
intermediate data layer for this, and some event / callback scheme to be
triggered only when there is a relevant change in the respective containers.
I think the DBC vehicle also has some basic data layer support already,
worth taking a look at.

The DBC implementation was done by Mark. I wrote a DBC primer:
https://docs.openvehicles.com/en/latest/components/vehicle_dbc/docs/dbc-primer.html

The initial Fiat 500 support was done using DBC.

We also had some discussion about polling definition standards for DBC.
Ludovic Lange created a kickoff issue for this on github:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/755

Regards,
Michael


Am 31.08.24 um 11:19 schrieb Michael Geddes via OvmsDev:
> In a recent conversation with Mark we were talking about utilising
> Duktape more for perhaps even vehicle implementations.
>
> I'm wondering if a better approach is to allow any vehicle to be
> extended via hooks in the base vehicle class or would it be better to
> have a duktape vehicle that could be extended.
>
> There would necessarily be many bits to the puzzle.  For example I
> have a class that allows us to know when blips to the 12V battery line
> might mean that somebody is interacting with the car so we should
> start polling the bus..   Should we put this (with a duktape
> interface) at the vehicle.h level?
>
> //.ichael
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735
* Handy 0176 / 206 989 26