Everyone,
I'd say release 3.3.005 is due. 3.3.004 was 03/2024, we've since
collected quite some fixes and new features, including extensions for
Smart EQ & the new MG4 support. There are lots of new Smart users now,
as Mercedes have stopped support for the official Smart EQ App (see
https://www.smart-emotion.de/article/415-mercedes-discontinues-smart-eq-app…)
The current state is also very stable, I had no issue reports.
Any objections / open fixes or additions that should be included in 3.3.005?
Regards,
Michael
--
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926
Dear all,
coming back to Marks suggestions, how to configure the Lilygo T-Call module, or in general alternative mappings of the GPIOs in OVMS.
To move away from a single config to enable/disable the Lilygo support, I introduced now a new choice to enable alternative GPIO mappings.
- Select default hardware base (e.g. HW31)
- Use the default or an alternative GPIO mapping (new choice)
- in case an alternative GPIO mapping is enabled, a file has to be specified, which contains the #define statements for all needed GPIOs and the modem control.
This file is included into ovms_peripherals.h, if the alternative mapping is enabled.
This way, there is no explicit dependence on a specific hardware in the configuration, or the code. Of course, there is the assumption that the hardware is compatible
with the standard hardware base of the OVMS module, e.g. the modem is supported.
I had to make some assumptions, how to handle the naming of the EGPIO/MAX7317 pins, in case the MAX7317 is not existing (MODEM_EGPIO_PWR -> MODEM_GPIO_PWR, MAX7317_CAN1_EN -> ESP32CAN_PIN_RS etc).
All specific components for the alternative hardware have to be explicitly enabled/disabled in menuconfig (modem,ESP32CAN, SD Card, OTA update, extension port ...).
This is now implemented in https://github.com/zbchristian/Open-Vehicle-Monitoring-System-3-Lilygo-Supp… (branch Lilygo-GPIO-remapping).
The only Lilygo dependence is existing in some additional files:
- example sdkconfig file in the support folder: sdkconfig.lilygo-tc
- three GPIO mapping files in components/gpio_maps/ for different versions of the Lilygo T-Call and the corresponding motherboard.
This folder is added to the include path.
I think, that this method is simple and very flexible. For an alternative module to be added, just a GPIO map file and an example sdkconfig have to be provided.
No change in the configuration or code is required.
What do you think?
Best regards
Christian
Dear all,
I recently experienced some interferences between my OVMS module (Lilygo
based) and the CAN bus of the car. The car was complaining once in while
about problems with certain components.
I first thought it might be related to my hardware. Checking some
discussions, I realized, that, at least for the Smart EQ, this seems to
be a common problem, independent of the used hardware.
I traced this down to a crashing firmware (edge version), which leads to
a disturbance of CAN1 (ESP32CAN).
Actually I emulated a car (Smart EQ) with an Arduino and two CAN
interfaces and recorded the bus errors and transmission problems. For
this I crashed the firmware intentionally once a minute. The efficiency
of occurring errors is pretty high, but not each crash leads to
transmission problems.
It actually does not help to disable the write access to the bus, since
this is only implemented in software. The hardware listen-only mode of
the CAN transceiver SN65HVD233 is not implemented yet (see below).
In conclusion, CAN1 is inherently sensitive to to a crashing firmware
due to the undefined GPIO transients on the ESP32CAN TX pin.
What helps, is to switch the transceiver into the listen-only mode (RS
pin high). In this case two pins have to conspire to achieve a dominant
state on the bus.
The MCP2515 based bus is not effected by crashes.
I propose to implement the hardware based listen-only mode in case, that
the write access is disabled anyway. I implemented this now for the
ESP32CAN as well as for the MCP2515 code.
See
https://github.com/zbchristian/Open-Vehicle-Monitoring-System-3-Lilygo-Supp…
This branch includes only the changes wrt to the switching of the
listen-only mode. I will issue a corresponding pull request.
In the code for the cars, the can bus mode has to be specified:
if (write_is_enabled) RegisterCanBus(busno,CAN_MODE_ACTIVE, speed);
else RegisterCanBus(busno,CAN_MODE_LISTEN, speed);
In case the config changes:
if (write_is_enabled) SetCanbusMode(busno,CAN_MODE_ACTIVE);
else SetCanbusMode(busno,CAN_MODE_LISTEN);
As an example, I implemented this for vehicle_smarteq in the above repo.
Another measure of security would be to shift for newer hardware to a
different CAN transceiver chip. I use now the TI TCAN330, which is pin
and functionally compatible with the SN65HVD233, but has a feature
called DOT (Dominant Time Out), which will return the bus to a recessive
state after a few msecs, in case the dominant state is applied for a too
long time.
Best regards
Christian
