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-Suppo... (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