Hello Mark, Thanks for the comments. Please find the attached responses inline in green. 1. Please don’t call this "OVMS v4", as that would cause confusion. Our ‘v’ naming is based on processor architecture: v1 - original prototype hand-built (PIC18F2680) v2 - first production version (PCI18F2685) v3 - refined production version (ESP32 WROVER, 16MB flash 4MB SPIRAM) Within that we have a .x naming scheme for subversions. The current version is v3.2 and the upcoming 4G module will be v3.3. It sounds like you are trying to make a different layout of the upcoming version, so perhaps a fork of v3.3? My concern here is to avoid confusion. Yes this is kind of fork of v3.3 with some additions on v3.2. 2. SIM7600 sounds ok. That is the direction we are heading as well. If we adopt the version SIM7600G-H then this is global with all regions supported. However all modules on this series are pin to pin so doesn’t matter if we go for region specific. 3. For ESP32 are you using WROVER module with 16MB flash and 4MB/8MB SPIRAM? Noop. I am planning to use wroom only. Should I switch to wrover instead? 4. For things like ACC detection, full power control, RGB LED, which GPIO / extended-IO pins are you using? I have used extender i.e MAX7317AEE+. Attached is the reference for esp32 connections. 5. It doesn’t look like you support the current expansion board option? Noop. I am not using any expansion thing here. Any particular requirement for that? 6. It seems that you are using a different vehicle connector, so this will be hardwired for Indian MG ZS EV? Noop. Since we can use this for many other vehicles also by changing the connector. In current version the PCB has exposed pads where we need to solder wires to connector. 7. Note that we removed the LED in v3 (it was in v2) due to power consumption issues with that. There is power control option from hardware side. Only esp32 and accelero module are always on. For other things, power control is done from GPIO of esp32. 8. How are you intending to handle firmware? A fork of the current code, or kconfig flags to support your hardware differences? Unfortunately I am not that good on software side . Can modify it slightly by not much. Would require some support on this . One more thing, I was not able to find the CAN ic in stock so using TCAN334 from TI. Will this work with MCP2515-E_ML? Regards, Rohit Soni From: OvmsDev <ovmsdev-bounces@lists.openvehicles.com> On Behalf Of Mark Webb-Johnson Sent: 09 August 2021 01:51 PM To: OVMS Developers <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] OVMS Hardware 4.0 Looks interesting. A few comments: 1. Please don’t call this "OVMS v4", as that would cause confusion. Our ‘v’ naming is based on processor architecture: v1 - origjnal prototype hand-built (PIC18F2680) v2 - first production version (PCI18F2685) v3 - refined production version (ESP32 WROVER, 16MB flash 4MB SPIRAM) Within that we have a .x naming scheme for subversions. The current version is v3.2 and the upcoming 4G module will be v3.3. It sounds like you are trying to make a different layout of the upcoming version, so perhaps a fork of v3.3? My concern here is to avoid confusion. 2. SIM7600 sounds ok. That is the direction we are heading as well. 3. For ESP32 are you using WROVER module with 16MB flash and 4MB/8MB SPIRAM? 4. For things like ACC detection, full power control, RGB LED, which GPIO / extended-IO pins are you using? 5. It doesn’t look like you support the current expansion board option? 6. It seems that you are using a different vehicle connector, so this will be hardwired for Indian MG ZS EV? 7. Note that we removed the LED in v3 (it was in v2) due to power consumption issues with that. 8. How are you intending to handle firmware? A fork of the current code, or kconfig flags to support your hardware differences? Regards, Mark, On 9 Aug 2021, at 3:18 PM, <rohit@ekraft.asia <mailto:rohit@ekraft.asia> > <rohit@ekraft.asia <mailto:rohit@ekraft.asia> > wrote: Hello OVMS dev’s, I am basically hardware designer planning to use the OVMS on my MG ZS EV ( Indian version ). For this I designed the hardware containing 4g module as well as all the components on single PCB. Have a look on below: <image002.jpg><image004.jpg> Top Side Bottom side The hardware features are as follows: 1. 4G module with active GPS antenna support ( sim7600 ) 2. ESP32 as main processor ( similar to ovms rev 3) 3. Sim and sd card in stacked single slot to save space 4. 3 can bus ports 5. Battery backup in case need to use this device as security. On board charging 6. Accelero/ gyro combined low power device 7. ACC detection in case of supported from vehicle from OBD port 8. Fully power control of each and every component and low power sleep mode 9. Input power supply up-to 60 V 10. RGB led for status indication The device case would be as below in which OBD connector would be there. <image007.jpg><image008.jpg> Do let me know if we need to add something so hardware is future ready. Regards, Rohit Soni +91-9660770212 _______________________________________________ OvmsDev mailing list <mailto:OvmsDev@lists.openvehicles.com> OvmsDev@lists.openvehicles.com <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Hello Didier, Glad to here that. Which car do you have? . Unfortunately esp32 doesn’t have spare pinouts to have that. I will do this in next rev when we plan for different processor. Regards, Rohit Soni From: OvmsDev <ovmsdev-bounces@lists.openvehicles.com> On Behalf Of didier@ernotte.com Sent: 09 August 2021 09:02 PM To: 'OVMS Developers' <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] OVMS Hardware 4.0 Hi, I have a very selfish request because all this is way beyond my skills : My OBD2 connector in the car does not have 3 bus, it has only one, the High Speed (pin 6/14), but on pin 3/11/12/13 I have the TX +/- and RX +/- cable for the Ethernet connection, plus Ethernet activation on pin 8. Could it be an option to have also DoIP (Diagnostic over IP) on a future OVMS hardware ? Didier Le lundi 9 août 2021, 05 h 03 min 06 s HAE, <rohit@ekraft.asia <mailto:rohit@ekraft.asia> > a écrit : Hello Mark, Thanks for the comments. Please find the attached responses inline in green. 1. Please don’t call this "OVMS v4", as that would cause confusion. Our ‘v’ naming is based on processor architecture: v1 - original prototype hand-built (PIC18F2680) v2 - first production version (PCI18F2685) v3 - refined production version (ESP32 WROVER, 16MB flash 4MB SPIRAM) Within that we have a .x naming scheme for subversions. The current version is v3.2 and the upcoming 4G module will be v3.3. It sounds like you are trying to make a different layout of the upcoming version, so perhaps a fork of v3.3? My concern here is to avoid confusion. Yes this is kind of fork of v3.3 with some additions on v3.2. 2. SIM7600 sounds ok. That is the direction we are heading as well. If we adopt the version SIM7600G-H then this is global with all regions supported. However all modules on this series are pin to pin so doesn’t matter if we go for region specific. 3. For ESP32 are you using WROVER module with 16MB flash and 4MB/8MB SPIRAM? Noop. I am planning to use wroom only. Should I switch to wrover instead? 4. For things like ACC detection, full power control, RGB LED, which GPIO / extended-IO pins are you using? I have used extender i.e MAX7317AEE+. Attached is the reference for esp32 connections. 5. It doesn’t look like you support the current expansion board option? Noop. I am not using any expansion thing here. Any particular requirement for that? 6. It seems that you are using a different vehicle connector, so this will be hardwired for Indian MG ZS EV? Noop. Since we can use this for many other vehicles also by changing the connector. In current version the PCB has exposed pads where we need to solder wires to connector. 7. Note that we removed the LED in v3 (it was in v2) due to power consumption issues with that. There is power control option from hardware side. Only esp32 and accelero module are always on. For other things, power control is done from GPIO of esp32. 8. How are you intending to handle firmware? A fork of the current code, or kconfig flags to support your hardware differences? Unfortunately I am not that good on software side . Can modify it slightly by not much. Would require some support on this . One more thing, I was not able to find the CAN ic in stock so using TCAN334 from TI. Will this work with MCP2515-E_ML? Regards, Rohit Soni From: OvmsDev <ovmsdev-bounces@lists.openvehicles.com <mailto:ovmsdev-bounces@lists.openvehicles.com> > On Behalf Of Mark Webb-Johnson Sent: 09 August 2021 01:51 PM To: OVMS Developers <ovmsdev@lists.openvehicles.com <mailto:ovmsdev@lists.openvehicles.com> > Subject: Re: [Ovmsdev] OVMS Hardware 4.0 Looks interesting. A few comments: 1. Please don’t call this "OVMS v4", as that would cause confusion. Our ‘v’ naming is based on processor architecture: v1 - origjnal prototype hand-built (PIC18F2680) v2 - first production version (PCI18F2685) v3 - refined production version (ESP32 WROVER, 16MB flash 4MB SPIRAM) Within that we have a .x naming scheme for subversions. The current version is v3.2 and the upcoming 4G module will be v3.3. It sounds like you are trying to make a different layout of the upcoming version, so perhaps a fork of v3.3? My concern here is to avoid confusion. 2. SIM7600 sounds ok. That is the direction we are heading as well. 3. For ESP32 are you using WROVER module with 16MB flash and 4MB/8MB SPIRAM? 4. For things like ACC detection, full power control, RGB LED, which GPIO / extended-IO pins are you using? 5. It doesn’t look like you support the current expansion board option? 6. It seems that you are using a different vehicle connector, so this will be hardwired for Indian MG ZS EV? 7. Note that we removed the LED in v3 (it was in v2) due to power consumption issues with that. 8. How are you intending to handle firmware? A fork of the current code, or kconfig flags to support your hardware differences? Regards, Mark, On 9 Aug 2021, at 3:18 PM, <rohit@ekraft.asia <mailto:rohit@ekraft.asia> > <rohit@ekraft.asia <mailto:rohit@ekraft.asia> > wrote: Hello OVMS dev’s, I am basically hardware designer planning to use the OVMS on my MG ZS EV ( Indian version ). For this I designed the hardware containing 4g module as well as all the components on single PCB. Have a look on below: <image002.jpg><image004.jpg> Top Side Bottom side The hardware features are as follows: 1. 4G module with active GPS antenna support ( sim7600 ) 2. ESP32 as main processor ( similar to ovms rev 3) 3. Sim and sd card in stacked single slot to save space 4. 3 can bus ports 5. Battery backup in case need to use this device as security. On board charging 6. Accelero/ gyro combined low power device 7. ACC detection in case of supported from vehicle from OBD port 8. Fully power control of each and every component and low power sleep mode 9. Input power supply up-to 60 V 10. RGB led for status indication The device case would be as below in which OBD connector would be there. <image007.jpg><image008.jpg> Do let me know if we need to add something so hardware is future ready. Regards, Rohit Soni +91-9660770212 _______________________________________________ OvmsDev mailing list <mailto:OvmsDev@lists.openvehicles.com> OvmsDev@lists.openvehicles.com <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

I have another selfish request. Can we get Bluetooth dongle support? The RAV4 EV has two diagnostic connectors at opposite ends of the car. The main connector has power and the Toyota CAN bus under the dashboard. The Tesla bus is at the rear of the car and does not have 12V power on the connector, but has a 12V power socket nearby. If the rear connector could use an off the shelf Bluetooth dongle, the installation of the OVMS under the dash would be much simpler and the long cable to the rear of the car would not be necessary. - Mike On Mon, Aug 9, 2021 at 8:32 AM didier@ernotte.com <didier@ernotte.com> wrote:

Hi,

I have a very selfish request because all this is way beyond my skills : My OBD2 connector in the car does not have 3 bus, it has only one, the High Speed (pin 6/14), but on pin 3/11/12/13 I have the TX +/- and RX +/- cable for the Ethernet connection, plus Ethernet activation on pin 8. Could it be an option to have also DoIP (Diagnostic over IP) on a future OVMS hardware ?

Didier

The base ESP32 chip does not have enough RAM to support all the OVMS functions. Things like javascript, DBC files, etc. All those require PSRAM/SPIRAM that comes with the WROVER modules. The base OVMS firmware also required 16MB flash (factory + 2xOTA 4MB firmware partitions, and the rest for config, etc). I know of two expansion boards for OVMS v3 (K-Line, and SWCAN), but there may be others. I suspect that this may be the limitation of your design (using GPIO and EGPIO pins for power control, LED, etc, doesn’t leave any free for expansion). We are really hitting the limits of the ESP32 here. The ESP32-S3 (with an extra 10 GPIO pins over the ESP32 we use) looks to be a possible way forward, but it is too early to tell (we learned our lesson adopting the ESP32 too early) - best to wait for things to stabilise with that new platform. Hardwiring the vehicle OBDII connector will be an issue. Firstly, not all vehicle types supported use OBDII. Secondly, the pinouts change (most general users are not comfortable with soldering). And thirdly, the size of the box gets in the way for some vehicle types when sticking out of the OBDII port. Regarding the power consumption of the LED, what I mean is that in OVMS v1 and v2 we used blinking LEDs to convey status. But doing a power consumption analysis on that, we found that the LEDs actually consumed a surprisingly significant amount of power. That is why we didn’t use them in OVMS v3. I haven’t used the TCAN334, so can’t comment on compatibility. I would in general worry more about the vehicle side for CAN transceivers than the MCP. In general, your design seems fine to me (apart from the firmware support, WROOM/WROVER, and OBDII connector issues pointed out), for your specific vehicle type. But, I have reservations as to its general suitability for all the supported vehicle types. Regarding the near future of the core v3 OVMS modules (and kits), I can confirm we are working on: No major changes to the main board; just fixing some bugs, and making slight improvements to some components - but in a backwards compatible way. A new SIM7600 based modem board (we are still evaluating whether to use one global chip, or EU and US version as before). No change to vehicle or expansion connectors. The overall goal is to maintain compatibility, but bring 4G support. 5G could also be added with the same approach. Existing OVMS v3 users can upgrade (if they need to, as 3G is sunset) by a simple relatively low cost swap of their modem board to the new one. Once the ESP32-S3 comes out, we will evaluate that (as a relatively simple upgrade), but I don’t hold out much hope that will improve things as the on-board RAM is still very limited in that (although Espressif say they have changed the allocation approach). Regards, Mark. P.S. In general, for the current OVMS v3.2 boards, the power consumption is already very controllable. If you power the board from 12v (not USB), shutdown (or deep sleep) the modem, and deep sleep the CPU, you will see power consumption drop to a very minimal level. The issue is not really hardware, but software support for these low power features (and in particularly being able to wake up the system from a low power state).

On 9 Aug 2021, at 5:02 PM, <rohit@ekraft.asia> <rohit@ekraft.asia> wrote:

Hello Mark, Thanks for the comments. Please find the attached responses inline in green. Please don’t call this "OVMS v4", as that would cause confusion. Our ‘v’ naming is based on processor architecture:

v1 - original prototype hand-built (PIC18F2680) v2 - first production version (PCI18F2685) v3 - refined production version (ESP32 WROVER, 16MB flash 4MB SPIRAM)

Within that we have a .x naming scheme for subversions. The current version is v3.2 and the upcoming 4G module will be v3.3.

It sounds like you are trying to make a different layout of the upcoming version, so perhaps a fork of v3.3?

My concern here is to avoid confusion. Yes this is kind of fork of v3.3 with some additions on v3.2. SIM7600 sounds ok. That is the direction we are heading as well. If we adopt the version SIM7600G-H then this is global with all regions supported. However all modules on this series are pin to pin so doesn’t matter if we go for region specific. For ESP32 are you using WROVER module with 16MB flash and 4MB/8MB SPIRAM? Noop. I am planning to use wroom only. Should I switch to wrover instead? For things like ACC detection, full power control, RGB LED, which GPIO / extended-IO pins are you using? I have used extender i.e MAX7317AEE+. Attached is the reference for esp32 connections. <image002.jpg>

It doesn’t look like you support the current expansion board option? Noop. I am not using any expansion thing here. Any particular requirement for that? It seems that you are using a different vehicle connector, so this will be hardwired for Indian MG ZS EV? Noop. Since we can use this for many other vehicles also by changing the connector. In current version the PCB has exposed pads where we need to solder wires to connector. Note that we removed the LED in v3 (it was in v2) due to power consumption issues with that. There is power control option from hardware side. Only esp32 and accelero module are always on. For other things, power control is done from GPIO of esp32. How are you intending to handle firmware? A fork of the current code, or kconfig flags to support your hardware differences? Unfortunately I am not that good on software side . Can modify it slightly by not much. Would require some support on this . One more thing, I was not able to find the CAN ic in stock so using TCAN334 from TI. Will this work with MCP2515-E_ML?

Regards, Rohit Soni

From: OvmsDev <ovmsdev-bounces@lists.openvehicles.com <mailto:ovmsdev-bounces@lists.openvehicles.com>> On Behalf Of Mark Webb-Johnson Sent: 09 August 2021 01:51 PM To: OVMS Developers <ovmsdev@lists.openvehicles.com <mailto:ovmsdev@lists.openvehicles.com>> Subject: Re: [Ovmsdev] OVMS Hardware 4.0

Looks interesting. A few comments:

Please don’t call this "OVMS v4", as that would cause confusion. Our ‘v’ naming is based on processor architecture:

v1 - origjnal prototype hand-built (PIC18F2680) v2 - first production version (PCI18F2685) v3 - refined production version (ESP32 WROVER, 16MB flash 4MB SPIRAM)

Within that we have a .x naming scheme for subversions. The current version is v3.2 and the upcoming 4G module will be v3.3.

It sounds like you are trying to make a different layout of the upcoming version, so perhaps a fork of v3.3?

My concern here is to avoid confusion. SIM7600 sounds ok. That is the direction we are heading as well. For ESP32 are you using WROVER module with 16MB flash and 4MB/8MB SPIRAM? For things like ACC detection, full power control, RGB LED, which GPIO / extended-IO pins are you using? It doesn’t look like you support the current expansion board option? It seems that you are using a different vehicle connector, so this will be hardwired for Indian MG ZS EV? Note that we removed the LED in v3 (it was in v2) due to power consumption issues with that. How are you intending to handle firmware? A fork of the current code, or kconfig flags to support your hardware differences?

Regards, Mark,

...

On 9 Aug 2021, at 3:18 PM, <rohit@ekraft.asia <mailto:rohit@ekraft.asia>> <rohit@ekraft.asia <mailto:rohit@ekraft.asia>> wrote:

Hello OVMS dev’s, I am basically hardware designer planning to use the OVMS on my MG ZS EV ( Indian version ). For this I designed the hardware containing 4g module as well as all the components on single PCB. Have a look on below: <image002.jpg><image004.jpg>

Top Side Bottom side

The hardware features are as follows: 4G module with active GPS antenna support ( sim7600 ) ESP32 as main processor ( similar to ovms rev 3) Sim and sd card in stacked single slot to save space 3 can bus ports Battery backup in case need to use this device as security. On board charging Accelero/ gyro combined low power device ACC detection in case of supported from vehicle from OBD port Fully power control of each and every component and low power sleep mode Input power supply up-to 60 V RGB led for status indication

The device case would be as below in which OBD connector would be there. <image007.jpg><image008.jpg>

Do let me know if we need to add something so hardware is future ready.

Regards, Rohit Soni +91-9660770212 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>

Yeah, we left that little blue one on. The big red and green were removed. We were contemplating having a little switch on the 4G board to disable the blue LED. It is rarely required. That said, when the modem is powered on, the little blue LED power consumption is trivial compared to the modem. JTAG is available on the WROVER. But as you say, not enough GPIOs. Regards, Mark.

On 10 Aug 2021, at 10:30 AM, Stephen Casner <casner@acm.org> wrote:

On Tue, 10 Aug 2021, Mark Webb-Johnson wrote:

...

Regarding the power consumption of the LED, what I mean is that in OVMS v1 and v2 we used blinking LEDs to convey status. But doing a power consumption analysis on that, we found that the LEDs actually consumed a surprisingly significant amount of power. That is why we didn’t use them in OVMS v3.

The blue modem LED is still blinking.

...

Regarding the near future of the core v3 OVMS modules (and kits), I can confirm we are working on:

No major changes to the main board; just fixing some bugs, and making slight improvements to some components - but in a backwards compatible way.

The addition I'd like to see is JTAG support. Again, probably a pinout problem.

-- Steve_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev