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>