Re: [Ovmsdev] OVMS V2.5 production / Renault Zoe support
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@spider.li> wrote:
One question: The OVMS v3 module: is it going to have some digital inputs somehow?
thanks, Wolfgang
Currently the Think uses two GPIO pins, the Leaf one, and the Twizy eight (4 in + 4 out for the SimpleConsole). This is the only SPI bus left for general purpose extensions? But as the MAX7317 is 16 bit and supports daisy chaining, it will still be possible to add a touch screen or other I/O extensions to it? If it doesn't create problems for "higher level" addons it's got my vote as well. Regards, Michael Am 28.04.2017 um 07:02 schrieb Mark Webb-Johnson:
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
o MDM_EN - UART 2, modem enable (used to reset the modem - very infrequent) o SW_CTL - Switched 12V control signal (used to turn on/off the external 12V - very infrequent) o 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@spider.li <mailto:wolfi@spider.li>> wrote:
One question: The OVMS v3 module: is it going to have some digital inputs somehow?
thanks, Wolfgang
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I’ve re-drawn it, as discussed, and sent to China for their comment. MAX7317 ends up looking like this: Our expansion slots like this: and the ESP32 MCU pinout like this: New pinout for MCU: 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 EXP_1 Expansion GPIO 1 9 I/O GPIO33, XTAL_32K_N (32.768 kHz crystal oscillator output), ADC1_CH5, TOUCH8, RTC_GPIO8 EXP_2 Expansion GPIO 2 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 (MCP2515) 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 FL_DATA2 SPI flash on ESP-WROOM-32 18 I/O GPIO10, SD_DATA3, SPIWP, HS1_DATA3, U1TXD FL_DATA3 SPI flash on ESP-WROOM-32 19 I/O GPIO11, SD_CMD, SPICS0, HS1_CMD, U1RTS FL_CS1 SPI flash on ESP-WROOM-32 20 I/O GPIO6, SD_CLK, SPICLK, HS1_CLK, U1CTS FL_CLK SPI flash on ESP-WROOM-32 21 I/O GPIO7, SD_DATA0, SPIQ, HS1_DATA0, U2RTS FL_DATA0 SPI flash on ESP-WROOM-32 22 I/O GPIO8, SD_DATA1, SPID, HS1_DATA1, U2CTS FL_DATA1 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 (MCP2515) 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 SP_CS3 VSPI CS3 (MAX7317 I/O expander) 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 FL_CS2 SPI to external flash, Chip Select 37 I/O GPIO23, VSPID, HS1_STROBE SP_MOSI VSPI MOSI 38 P Ground GND Ground 39 P Ground GND Ground Overall, that gives us two free GPIO directly on the ESP-32 and eight free GPIO on the MAX7317 expander. If China is OK with that, they’ll finalise the board layout next week and make a couple of development boards to ensure that all the components work as expected. I attached the revised draft schematic (2017-05-01). This one also incorporates the change to the external flash arrangement. Regards, Mark. A note on displays In general, for external displays I’m thinking that a UART/Bluetooth/SPI/CAN interface would be better suited, with some small micro-controller, rather than raw GPIO. I know raw GPIO is simple, but there is so much more that can be done with this, and the prices of displays are plummeting. I certainly intend to use bluetooth to a cellphone, and we can expose the OVMS protocol to that to allow for some pretty powerful control. The ESP32 now has two direct GPIO pins free (EXT_1 and EXT_2) and those can be mapped to a UART, for example. Along with some HUDs, I’ve been experimenting with a little OBDII display that costs around US$25 (quantity: 1). Connection is via OBDII (CAN bus) - the idea being that we will emulate an OBDII ECU on one of our CAN buses that connects to this. So, we can output battery temperate where the unit expects coolant temperature, SOC% as fuel level, etc. MCU in that unit is a GD32F103 (like an STM32, but 108MHz). Input is via a little jog-left, jog-right, push-to-click button on the front. Just an idea and something I’m messing around with.
On 29 Apr 2017, at 1:07 AM, Michael Balzer <dexter@expeedo.de> wrote:
Currently the Think uses two GPIO pins, the Leaf one, and the Twizy eight (4 in + 4 out for the SimpleConsole).
This is the only SPI bus left for general purpose extensions?
But as the MAX7317 is 16 bit and supports daisy chaining, it will still be possible to add a touch screen or other I/O extensions to it?
If it doesn't create problems for "higher level" addons it's got my vote as well.
Regards, Michael
Am 28.04.2017 um 07:02 schrieb Mark Webb-Johnson:
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@spider.li <mailto:wolfi@spider.li>> wrote:
One question: The OVMS v3 module: is it going to have some digital inputs somehow?
thanks, Wolfgang
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi Mark, I'm really interested in the down-stream OBDII connection (ECU emulator). I would like to use it to drive a Wi-Fi Hotspot dongle (T-Mobile's "SyncUp Drive"). Thanks for including this. Besides providing a hotspot for the car's passengers, and the intended vehicle telematics, it could also give the OVMS module a Wi-Fi alternative to the 3G modem, at least when the car is awake. I presume the modem would be the preferred connection for lower power states. Greg Mark Webb-Johnson wrote:
Along with some HUDs, I’ve been experimenting with a little OBDII display that costs around US$25 (quantity: 1). Connection is via OBDII (CAN bus) - the idea being that we will emulate an OBDII ECU on one of our CAN buses that connects to this. So, we can output battery temperate where the unit expects coolant temperature, SOC% as fuel level, etc. MCU in that unit is a GD32F103 (like an STM32, but 108MHz). Input is via a little jog-left, jog-right, push-to-click button on the front. Just an idea and something I’m messing around with.
I’ve seen quite a few of these OBDII-plugin devices in recent years. Not just HUDs, but insurance company driving behaviour monitors, dongles, etc. While most modern cars provide at least some standard OBDII PID support (such as speed, fuel level, etc), Tesla have been notable in their absence of any such support. Navdy, Exploride, Hudly, Garmin HUD, iScout; none work with Tesla cars. Software wise it is quite simple to do. The only issue I see is dedicating one CAN bus port to this (but we’ve got three). On some cars, it might be possible to multiplex this on top of an existing CAN bus (so long as there is no conflict on the CAN IDs used or bus speed). Regards, Mark.
On 2 May 2017, at 7:37 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
I'm really interested in the down-stream OBDII connection (ECU emulator). I would like to use it to drive a Wi-Fi Hotspot dongle (T-Mobile's "SyncUp Drive"). Thanks for including this.
Besides providing a hotspot for the car's passengers, and the intended vehicle telematics, it could also give the OVMS module a Wi-Fi alternative to the 3G modem, at least when the car is awake. I presume the modem would be the preferred connection for lower power states.
Greg
Mark Webb-Johnson wrote:
Along with some HUDs, I’ve been experimenting with a little OBDII display that costs around US$25 (quantity: 1). Connection is via OBDII (CAN bus) - the idea being that we will emulate an OBDII ECU on one of our CAN buses that connects to this. So, we can output battery temperate where the unit expects coolant temperature, SOC% as fuel level, etc. MCU in that unit is a GD32F103 (like an STM32, but 108MHz). Input is via a little jog-left, jog-right, push-to-click button on the front. Just an idea and something I’m messing around with.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi Mark, I'm curious why there would be an issue with using one of the three CAN bus ports for a down-stream device? Do some cars require connecting to all of them for normal operation? What else would they be used for? Thanks, Greg Mark Webb-Johnson wrote:
I’ve seen quite a few of these OBDII-plugin devices in recent years. Not just HUDs, but insurance company driving behaviour monitors, dongles, etc. While most modern cars provide at least some standard OBDII PID support (such as speed, fuel level, etc), Tesla have been notable in their absence of any such support.
Navdy, Exploride, Hudly, Garmin HUD, iScout; none work with Tesla cars.
Software wise it is quite simple to do. The only issue I see is dedicating one CAN bus port to this (but we’ve got three). On some cars, it might be possible to multiplex this on top of an existing CAN bus (so long as there is no conflict on the CAN IDs used or bus speed).
Regards, Mark.
On 2 May 2017, at 7:37 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
I'm really interested in the down-stream OBDII connection (ECU emulator). I would like to use it to drive a Wi-Fi Hotspot dongle (T-Mobile's "SyncUp Drive"). Thanks for including this.
Besides providing a hotspot for the car's passengers, and the intended vehicle telematics, it could also give the OVMS module a Wi-Fi alternative to the 3G modem, at least when the car is awake. I presume the modem would be the preferred connection for lower power states.
Greg
Mark Webb-Johnson wrote:
Along with some HUDs, I’ve been experimenting with a little OBDII display that costs around US$25 (quantity: 1). Connection is via OBDII (CAN bus) - the idea being that we will emulate an OBDII ECU on one of our CAN buses that connects to this. So, we can output battery temperate where the unit expects coolant temperature, SOC% as fuel level, etc. MCU in that unit is a GD32F103 (like an STM32, but 108MHz). Input is via a little jog-left, jog-right, push-to-click button on the front. Just an idea and something I’m messing around with.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On many modern cars there are multiple CAN buses used for different things. The approach is to separate different parts of the car onto different buses. For example, the Tesla Roadster has three CAN buses, the Nissan Leaf has two, and the Tesla Model S and X have at least four. It is helpful for OVMS to be able to connect to multiple CAN buses to be able to have more functionality (control parts of the car not directly connected to a single CAN bus). Regards, Mark
On 9 May 2017, at 6:41 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
I'm curious why there would be an issue with using one of the three CAN bus ports for a down-stream device? Do some cars require connecting to all of them for normal operation? What else would they be used for?
Thanks,
Greg
Mark Webb-Johnson wrote:
I’ve seen quite a few of these OBDII-plugin devices in recent years. Not just HUDs, but insurance company driving behaviour monitors, dongles, etc. While most modern cars provide at least some standard OBDII PID support (such as speed, fuel level, etc), Tesla have been notable in their absence of any such support.
Navdy, Exploride, Hudly, Garmin HUD, iScout; none work with Tesla cars.
Software wise it is quite simple to do. The only issue I see is dedicating one CAN bus port to this (but we’ve got three). On some cars, it might be possible to multiplex this on top of an existing CAN bus (so long as there is no conflict on the CAN IDs used or bus speed).
Regards, Mark.
On 2 May 2017, at 7:37 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
I'm really interested in the down-stream OBDII connection (ECU emulator). I would like to use it to drive a Wi-Fi Hotspot dongle (T-Mobile's "SyncUp Drive"). Thanks for including this.
Besides providing a hotspot for the car's passengers, and the intended vehicle telematics, it could also give the OVMS module a Wi-Fi alternative to the 3G modem, at least when the car is awake. I presume the modem would be the preferred connection for lower power states.
Greg
Mark Webb-Johnson wrote:
Along with some HUDs, I’ve been experimenting with a little OBDII display that costs around US$25 (quantity: 1). Connection is via OBDII (CAN bus) - the idea being that we will emulate an OBDII ECU on one of our CAN buses that connects to this. So, we can output battery temperate where the unit expects coolant temperature, SOC% as fuel level, etc. MCU in that unit is a GD32F103 (like an STM32, but 108MHz). Input is via a little jog-left, jog-right, push-to-click button on the front. Just an idea and something I’m messing around with.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Right. As it should be. But, for our (OVMS) purposes, do we know of any cars that need connection to more than two? I'm guessing is this more of a matter of future-proofing the design (which is a really good idea!). Currently, OVMS v2 only connects to one CAN bus, right? I guess what I am wondering is, are there any cars that OVMS needs to support, that don't already support these dongles directly on the OBDII port, and that need OVMS to connect to more than two CAN busses in order to function? Hopefully that intersection is empty... If not, then there would need either be some multiplexing (risky), or an either-or of functionality (undesirable). For my own purposes I'm focused on the Roadster, to which I believe OVMS only needs a connection to CAN0. Yes? (This is from the discussion here: https://teslamotorsclub.com/tmc/posts/52337/ ) Greg Mark Webb-Johnson wrote:
On many modern cars there are multiple CAN buses used for different things. The approach is to separate different parts of the car onto different buses.
For example, the Tesla Roadster has three CAN buses, the Nissan Leaf has two, and the Tesla Model S and X have at least four.
It is helpful for OVMS to be able to connect to multiple CAN buses to be able to have more functionality (control parts of the car not directly connected to a single CAN bus).
Regards, Mark
On 9 May 2017, at 6:41 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
I'm curious why there would be an issue with using one of the three CAN bus ports for a down-stream device? Do some cars require connecting to all of them for normal operation? What else would they be used for?
Thanks,
Greg
Mark Webb-Johnson wrote:
I’ve seen quite a few of these OBDII-plugin devices in recent years. Not just HUDs, but insurance company driving behaviour monitors, dongles, etc. While most modern cars provide at least some standard OBDII PID support (such as speed, fuel level, etc), Tesla have been notable in their absence of any such support.
Navdy, Exploride, Hudly, Garmin HUD, iScout; none work with Tesla cars.
Software wise it is quite simple to do. The only issue I see is dedicating one CAN bus port to this (but we’ve got three). On some cars, it might be possible to multiplex this on top of an existing CAN bus (so long as there is no conflict on the CAN IDs used or bus speed).
Regards, Mark.
On 2 May 2017, at 7:37 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
I'm really interested in the down-stream OBDII connection (ECU emulator). I would like to use it to drive a Wi-Fi Hotspot dongle (T-Mobile's "SyncUp Drive"). Thanks for including this.
Besides providing a hotspot for the car's passengers, and the intended vehicle telematics, it could also give the OVMS module a Wi-Fi alternative to the 3G modem, at least when the car is awake. I presume the modem would be the preferred connection for lower power states.
Greg
Mark Webb-Johnson wrote:
Along with some HUDs, I’ve been experimenting with a little OBDII display that costs around US$25 (quantity: 1). Connection is via OBDII (CAN bus) - the idea being that we will emulate an OBDII ECU on one of our CAN buses that connects to this. So, we can output battery temperate where the unit expects coolant temperature, SOC% as fuel level, etc. MCU in that unit is a GD32F103 (like an STM32, but 108MHz). Input is via a little jog-left, jog-right, push-to-click button on the front. Just an idea and something I’m messing around with.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Greg,
But, for our (OVMS) purposes, do we know of any cars that need connection to more than two?
We are getting by at the moment with connection to just one. More than one is a ‘nice to have’. Only having one may limit what we can do. It is hard to answer the question as up until now we’ve only had one CAN bus (OVMS v1 and v2) so we’ve never really looked hard at what a second (or third) bus would give us. I know that for the Nissan Leaf, there is a bridge and we can poll across the two buses - but that is klunky and slow (a direct connection would be much easier and provide greater control). So far that car we sit on the EV bus and poll across for vehicle things like speed. For Tesla Roadster, we are unable to pre-cool / pre-heat the car as the instrumentation bus we are on doesn’t have that capability. The HVAC bus may (but we haven’t tried).
Currently, OVMS v2 only connects to one CAN bus, right?
Yes.
are there any cars that OVMS needs to support, that don't already support these dongles directly on the OBDII port, and that need OVMS to connect to more than two CAN busses in order to function?
I think two for vehicle control should be sufficient. I added the third for this idea of external display, and because it was just a couple of bucks more and 2 GPIO pins. The other option that multiple buses gives us is to physically break the CAN bus into two and bridge it programatically. Some people have done that for both reverse-engineering as well as message spoofing / modification purposes. Regards, Mark.
On 9 May 2017, at 8:10 AM, Greg D. <gregd2350@gmail.com> wrote:
Right. As it should be.
But, for our (OVMS) purposes, do we know of any cars that need connection to more than two? I'm guessing is this more of a matter of future-proofing the design (which is a really good idea!). Currently, OVMS v2 only connects to one CAN bus, right?
I guess what I am wondering is, are there any cars that OVMS needs to support, that don't already support these dongles directly on the OBDII port, and that need OVMS to connect to more than two CAN busses in order to function? Hopefully that intersection is empty... If not, then there would need either be some multiplexing (risky), or an either-or of functionality (undesirable).
For my own purposes I'm focused on the Roadster, to which I believe OVMS only needs a connection to CAN0. Yes? (This is from the discussion here: https://teslamotorsclub.com/tmc/posts/52337/ )
Greg
Mark Webb-Johnson wrote:
On many modern cars there are multiple CAN buses used for different things. The approach is to separate different parts of the car onto different buses.
For example, the Tesla Roadster has three CAN buses, the Nissan Leaf has two, and the Tesla Model S and X have at least four.
It is helpful for OVMS to be able to connect to multiple CAN buses to be able to have more functionality (control parts of the car not directly connected to a single CAN bus).
Regards, Mark
On 9 May 2017, at 6:41 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
I'm curious why there would be an issue with using one of the three CAN bus ports for a down-stream device? Do some cars require connecting to all of them for normal operation? What else would they be used for?
Thanks,
Greg
Mark Webb-Johnson wrote:
I’ve seen quite a few of these OBDII-plugin devices in recent years. Not just HUDs, but insurance company driving behaviour monitors, dongles, etc. While most modern cars provide at least some standard OBDII PID support (such as speed, fuel level, etc), Tesla have been notable in their absence of any such support.
Navdy, Exploride, Hudly, Garmin HUD, iScout; none work with Tesla cars.
Software wise it is quite simple to do. The only issue I see is dedicating one CAN bus port to this (but we’ve got three). On some cars, it might be possible to multiplex this on top of an existing CAN bus (so long as there is no conflict on the CAN IDs used or bus speed).
Regards, Mark.
On 2 May 2017, at 7:37 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
I'm really interested in the down-stream OBDII connection (ECU emulator). I would like to use it to drive a Wi-Fi Hotspot dongle (T-Mobile's "SyncUp Drive"). Thanks for including this.
Besides providing a hotspot for the car's passengers, and the intended vehicle telematics, it could also give the OVMS module a Wi-Fi alternative to the 3G modem, at least when the car is awake. I presume the modem would be the preferred connection for lower power states.
Greg
Mark Webb-Johnson wrote:
Along with some HUDs, I’ve been experimenting with a little OBDII display that costs around US$25 (quantity: 1). Connection is via OBDII (CAN bus) - the idea being that we will emulate an OBDII ECU on one of our CAN buses that connects to this. So, we can output battery temperate where the unit expects coolant temperature, SOC% as fuel level, etc. MCU in that unit is a GD32F103 (like an STM32, but 108MHz). Input is via a little jog-left, jog-right, push-to-click button on the front. Just an idea and something I’m messing around with.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (3)
-
Greg D. -
Mark Webb-Johnson -
Michael Balzer