March 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