April 2017 - OvmsDev - Open Vehicles

OVMS logo
by Mark Webb-Johnson 06 Jun '17

06 Jun '17

We need to change the OVMS logo, to better reflect the vehicle independence. The existing logo is too much Tesla. Felix has kindly prepared a couple of options for us, attached below. My preference is for the one with the car outline (even though it retains a hint of Tesla), as it emphasizes the vehicle comms aspect. This is quite urgent, as the Teslive people are pushing for artwork. What do you guys/gals think? Regards, Mark

8 14

OVMS v3
by Mastro Gippo 20 May '17

20 May '17

Hi all, I'd like to resurrect an old conversation. As we know, the current PIC is quickly running out of resources and maybe it's time to switch to a better platform. Two CAN buses are now desirable too. A microSD slot and direct USB connectivity wouldn't hurt either. I will probably have to design a similar hardware for myself, so I'd like to contribute to the OVMS by sharing the HW platform if you want; no strings attached of course, if you decide that there's no need for the upgrade, I'll keep on working on my project by myself! :) That said, I'd like to throw a few ideas to the table. - MCU: I'd like to use an STM32 micro. They seem to be emerging as the standard choice for diy ARM projects, and this offers a few interesting opportunities: -Programming it in c/c++ with the manufacturer CMSIS standard libraries (boring) -Programming it with the mbed.org SDK. Unfortunately no dev boards are available with dual CAN bus, but it will be easy to move to the correct micro of the same series once most of the software is ironed out on a dev board like the https://mbed.org/platforms/ST-Nucleo-F302R8/ -Programming it with an RTOS. NuttX would be my choice, as it's the one used in the Ardupilot Pixhawk platform, and I'd like to learn it. This would mean a steeper starting curve, but a lot of flexibility later as a lot of stuff is handled on the OS level (network stacks, SD card & filesystems, multitasking...). FreeRTOS is a nice option too. I'd like to use the STM32F405RG as it's the most similar to the one found on the Pixhawk, but of course I'm biased because of that, and that micro is quite overkill for the task. We can of course use a lower specced part and lose some RTOS fuctionality as long as it has 2 CAN buses. - MODEM: I have no experience in this field; is the SIM908 still a good choice or does anyone think that we should try new platforms? I like this, but I don't know if the price puts it out of budget: http://www.telit.com/telit/Pulsar/en_US.Store.display.1001./ge864-gps On the bright side, it can be programmed in python, so we can offload some of the work to the modem. This *could* allow us to free some space on the PIC, and keep that platform without changing MCU.. - Enclosure: I think that, even with the new MCU, we can still fit the old enclosure. Is that ok, or should we think about a more automotive-friendly one? Maybe waterproof for the twizy? And that's it. I think that the core SW developers should voice their opinion, as there is a lot of work to be done on that front. A huge problem will be keeping backwards compatibility to add features for the v2 users, so we should discuss about this too. Regards MG

18 70

OVMS v3 First Board Layout
by Mark Webb-Johnson 09 May '17

09 May '17

I’m trying to finalise the OVMS v3 final board layout, with the factory in China. We have some questions and seek your opinions: CAN transceivers / power Overall, the OVMS v3 system runs at 3.3V. We have two power supply sources: USB (where we use a 5V -> 3.3V regulator), and +12V vehicle power (where we use a +12V -> 3.3V switching power supply, to be as energy efficient as possible). Diodes are used for reverse-polarity protection as well as coping with the situation where both usb and vehicle power is applied simultaneously. Our problem is with the CAN transceivers. I’m used to the MCP2551 (been using it for a decade or more), but that is 5V so greatly complicates the power supply arrangements at the +12V side. We can switch to something like the SN65HVD233 transceiver that works at 3.3V. But, I am concerned about comments I am reading about 3.3V CAN transceivers and their inability to meet the ISO11898 dominant condition requirement of 3.5V. From my understanding, these 3.3V CAN transceivers get around this by driving CAN-L to 1V, to still get the differential of about 2V (recessive condition?). My concern is compatibility. What do people think about this? Any recommendations? External Connectors The idea is to retain the existing DB9 connector, with the same basic pin arrangement: DB9-M Signal 3 Chassis/Power GND 2 CAN-L (primary) 7 CAN-H (primary) 4 CAN-L (alternate CAN) 5 CAN-H (alternate CAN) 9 +12V Vehicle Power That leaves pins #1, #6, and #8 free for expansion uses. It gives us compatibility with existing OVMS cables. We would then add a second connector. The suggestions here are DB15 normal density, DB25 normal density, or DA-26 high density. My preference is the DA-26 (as DB25 is the old parallel printer style connector and very bulky). As well as power lines, expansion cards could wire to this connector to expose external inputs/outputs. What do people think about the DA-26 connector? I’m suggesting a female version (as power is carried there, and I don’t want the pins to get pushed together for a short). Note that we’ve also got a micro-usb socket, as well as space for GPS and GSM/GNS antennas. Other than that, we are good to go. Things have stabilised now with Espressif, so we can proceed with building developer boards. Regards, Mark.

7 17

Re: [Ovmsdev] OVMS V2.5 production / Renault Zoe support
by Mark Webb-Johnson 09 May '17

09 May '17

Copying OVMS developers in on this, as it is an interesting question. Free pins are very tight on the OVMS v3. We’ve added so much as standard (extra flash, SD card, 3 CAN buses, etc, etc) that there is not much free. In the first draft design (shown on the attached pictures), we had two general GPIO pins free - EXP_1 and EXP_2. However, working with Espressif (the makers of the ESP-32 MCU) it seems that the best and simplest way to use external flash is to change the SPI bus chip select line and add an external flash on that. If we do that, we need one more pin, and that means goodbye EXP_2. So, only one free GPIO pin - EXP_1. We do have two internal expansion slots where piggy-back boards can be plugged (one for the optional modem and one free for general use). These use standard 0.1” SIP connectors (two 1x10), so very easy to breadboard. For those, we have EXP_1 on the attached diagram. These pins are also available on a DA26 female expansion connector on the side of the module (so you can use them directly). There is also a SW_12V switched 12volt supply on the DA26 female expansion connector. So, the short answer is if you just need a single GPIO, that is available either internally of externally as EXP_1. If you need a second, you could probably use the SW_12V as well. I/O expansion If you need more than two, then you could use a SPI bus I/O expander, probably on one of the internal expansion slots, and use EXP_1 to drive that. The MAX7317 is suitable. In the first draft design for OVMS v3, we have three relatively unused simple I/O pins MDM_EN - UART 2, modem enable (used to reset the modem - very infrequent) SW_CTL - Switched 12V control signal (used to turn on/off the external 12V - very infrequent) EXP_1 - expansion pin What I’ve been considering is adding a MAX7317 as standard, using EXP_1 to drive that (along with the normal SPI bus used for two of the CAN buses), then moving MDM_EN and SW_CTL to that. The MAX7317 has 10 I/O ports, so if we did that, we’d get 8 free I/O ports from the MAX7317 as well as 2 direct off the ESP32 MCU. I’m 99% decided to do that, but just trying to work out cost impact and if there is enough room on the board to actually fit it in. Regards, Mark. > On 28 Apr 2017, at 3:04 AM, Wolfgang Jenne <wolfi(a)spider.li> wrote: > > One question: The OVMS v3 module: is it going to have some digital inputs somehow? > > thanks, > Wolfgang

3 8

OVMS V2.5 production / Renault Zoe support
by Michael Balzer 26 Apr '17

26 Apr '17

Mark, module V2.5 has been out of stock for some weeks now. Is a new batch underway? New Twizy drivers asked about it, and I'm also in contact with a Zoe driver and a to-be Zoe developer in need for modules. Or do you think V3 is close enough to wait for? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 2

OVMS V3 Schematic
by Mark Webb-Johnson 23 Apr '17

23 Apr '17

I’m sharing the schematic and design instructions for OVMS v3. Attached is the schematic and pinout file. This was a first draft, to the board design and PCB layout guys in China, but should give you an idea of what we’re trying for. The guys in China are now working on it, but I welcome any feedback from this group. As you can see, we have managed to incorporate pretty much all our goals, although the ESP32 expansion pins are pretty much maxed out (SD card, flash, and SPI take most) - only GPIO 2 pins free. We could use an I/O expander (via SPI, I guess), but that wouldn’t help that much. Here are some guideline instructions that went along with this to China: We are using ESP-WROOM-32 module. We have one problem with this module - Flash memory size is too small. When using OTA (over-the-air) updates, the flash must be divided into 3 (1 for factory image, 1 for running image, and 1 for new download image). So, 4MB flash in ESP-WROOM-32 module is really just 1.3MB for each image. We tried arranging external flash, but not possible in ESP-WROOM-32 design. We will talk to Espressif about a custom ESP-WROOM-32 module with 16MB flash chip (instead of standard 4MB flash chip), or even perhaps no flash chip at all (then we can simply connect to pins 17-22 on our board ourselves). Anyway, for development, 4MB is ok, so let’s start with that. The ESP-WROOM-32 connection arrangement is the same as DEVKIT reference design. Using the same EN and BOOT two buttons. The same CP2102 USB-UART. Just the power supply is different. Please check this reference design and double-check our schematic. It should follow almost exactly. This circuit is really just a DEVKIT circuit, but with different power supply, SD card, CAN bus, etc. We want a high efficiency power supply. In particular on the 12V side. Suggestion is to use a AOZ1280 buck converter chip (but happy for you to use something better if you know of it). That has a wide input voltage range, and can support both 5V (from USB) and 12V-15V (from car). I haven’t given the schematic for that part of the circuit, as you can take it straight from the data sheet. As car power maybe not so stable, I suggest some big capacitor and inductor. We use diodes to protect against reverse polarity, and to allow circuit to be powered BOTH from the USB and CAR at the same time. There is a voltage divider circuit to go to ADC pin on ESP32 so we can measure the 12V voltage exactly. We’ve use a 5V->3.3V converter also on the USB side, although not sure if that is necessary. Supposedly the AOZ1280 can take 5V->3.3V itself. Can you have a look at that and suggest? Maybe we can skip that component completely and just wire 5V from USB through a diode into input side of AOZ1280 next to 12V from the car? We would like to be able to provide a high-side switched 12V car power output on the expansion connector. This will be under ESP32 control, so we can turn on/off external peripherals. We’ve used a simple BTS452R here. We need a micro SD card slot. It would be good if this is externally reachable so card can be put in / taken out even with module in a case. We just used normal ESP32 schematic for this. For the connectors, there is one DA26 female, and one DB9 male (same as OVMS v2). Also a USB connector for the CP2102. For the CAN bus, we’ve included 120R resistors which can be enable/disabled using jumpers. You can leave these jumpers open (termination disabled). For the CAN bus, we’ve used the main controller in the ESP32 and a SN65 3.3V transceiver. We’ve also added two MCP2515 SPI can controllers and two SN64 3.3V transceivers for those. For the expansion sockets, We’ve used two strips of 1x10 female SIP. We suggest putting these 40mm apart (to make two 40mm x 40mm squares). The top and bottom of any expansion board can be longer. There are two expansion sockets (one for modem, the other for custom). We haven’t specified a GSM modem. We can work on that later (let’s just get wifi and bluetooth working first). The expansion sockets have GND, 3.3V, MDM_EN, MDM_TXD and MDM_RXD, which should be sufficient for this (same as OVMS v2). The modem expansion board will have GSM and GPS antennas on it, to come through case. We don’t think we have enough pull-ups / pull-downs / current limiting resistors on the circuit (some pins on ESP32 have this internally, but not well documented, so safer to use external components). We think each line to/from the ESP32 needs these. Can you check, and add as necessary? Please have a look at it, and let me have your questions / suggestions. Thanks, Mark. Pin Type Function Name Function 1 P Ground GND Ground 2 P Power supply. 3.3V Power supply to ESP32 WROOM32 3 I Chip-enable signal. Active high. ESP32_EN "EN" switch 4 I GPIO36, SENSOR_VP, ADC_H, ADC1_CH0, RTC_GPIO0 ADC_IN ADC in (from 12V vehicle power voltage divider) 5 I GPIO39, SENSOR_VN, ADC1_CH3, ADC_H, RTC_GPIO3 SD_DET SD Card DETECT 6 I GPIO34, ADC1_CH6, RTC_GPIO4 SP_INT1 VSPI INT 1 7 I GPIO35, ADC1_CH7, RTC_GPIO5 SP_INT2 VSPI INT 2 8 I/O GPIO32, XTAL_32K_P (32.768 kHz crystal oscillator input), ADC1_CH4, TOUCH9, RTC_GPIO9 MDM_EN UART 2, Modem Enable 9 I/O GPIO33, XTAL_32K_N (32.768 kHz crystal oscillator output), ADC1_CH5, TOUCH8, RTC_GPIO8 SW_CTL Switched 12V control signal 10 I/O GPIO25, DAC_1, ADC2_CH8, RTC_GPIO6, EMAC_RXD0 CAN_TXD CAN, tx to transceiver 11 I/O GPIO26, DAC_2, ADC2_CH9, RTC_GPIO7, EMAC_RXD1 CAN_RXD CAN, rx from transceiver 12 I/O GPIO27, ADC2_CH7, TOUCH7, RTC_GPIO17, EMAC_RX_DV SP_CS2 VSPI CS 2 13 I/O GPIO14, ADC2_CH6, TOUCH6, RTC_GPIO16, MTMS, HSPICLK, HS2_CLK, SD_CLK, EMAC_TXD2 SD_CLK SD Card CLK 14 I/O GPIO12, ADC2_CH5, TOUCH5, RTC_GPIO15, MTDI, HSPIQ, HS2_DATA2, SD_DATA2, EMAC_TXD3 SD_DATA2 SD Card DATA2 15 P Ground GND Ground 16 I/O GPIO13, ADC2_CH4, TOUCH4, RTC_GPIO14, MTCK, HSPID, HS2_DATA3, SD_DATA3, EMAC_RX_ER SD_DATA3 SD Card DATA3 17 I/O GPIO9, SD_DATA2, SPIHD, HS1_DATA2, U1RXD n/a SPI flash on ESP-WROOM-32 18 I/O GPIO10, SD_DATA3, SPIWP, HS1_DATA3, U1TXD n/a SPI flash on ESP-WROOM-32 19 I/O GPIO11, SD_CMD, SPICS0, HS1_CMD, U1RTS n/a SPI flash on ESP-WROOM-32 20 I/O GPIO6, SD_CLK, SPICLK, HS1_CLK, U1CTS n/a SPI flash on ESP-WROOM-32 21 I/O GPIO7, SD_DATA0, SPIQ, HS1_DATA0, U2RTS n/a SPI flash on ESP-WROOM-32 22 I/O GPIO8, SD_DATA1, SPID, HS1_DATA1, U2CTS n/a SPI flash on ESP-WROOM-32 23 I/O GPIO15, ADC2_CH3, TOUCH3, MTDO, HSPICS0, RTC_GPIO13, HS2_CMD, SD_CMD, EMAC_RXD3 SD_CMD SD Card CMD 24 I/O GPIO2, ADC2_CH2, TOUCH2, RTC_GPIO12, HSPIWP, HS2_DATA0, SD_DATA0 SD_DATA0 SD Card DATA0 25 I/O GPIO0, ADC2_CH1, TOUCH1, RTC_GPIO11, CLK_OUT1, EMAC_TX_CLK ESP32_IO0 "BOOT" switch 26 I/O GPIO4, ADC2_CH0, TOUCH0, RTC_GPIO10, HSPIHD, HS2_DATA1, SD_DATA1, EMAC_TX_ER SD_DATA1 SD Card DATA1 27 I/O GPIO16, HS1_DATA4, U2RXD, EMAC_CLK_OUT MDM_TXD UART 2, TX to modem 28 I/O GPIO17, HS1_DATA5, U2TXD, EMAC_CLK_OUT_180 MDM_RXD UART 2, RX from modem 29 I/O GPIO5, VSPICS0, HS1_DATA6, EMAC_RX_CLK SP_CS1 VSPI CS 1 30 I/O GPIO18, VSPICLK, HS1_DATA7 SP_CLK VSPI CLK 31 I/O GPIO19, VSPIQ, U0CTS, EMAC_TXD0 SP_MISO VSPI MISO 32 - - n/a No connection 33 I/O GPIO21, VSPIHD, EMAC_TX_EN EXP_1 Expansion #1 34 I/O GPIO3, U0RXD, CLK_OUT2 CSL_TXD UART 0, TX to console 35 I/O GPIO1, U0TXD, CLK_OUT3, EMAC_RXD2 CSL_RXD UART 0, RX from console 36 I/O GPIO22, VSPIWP, U0RTS, EMAC_TXD1 EXP_2 Expansion #2 37 I/O GPIO23, VSPID, HS1_STROBE SP_MOSI VSPI MOSI 38 P Ground GND Ground 39 P Ground GND Ground

1 0