Here’s the final issue-list we had to be addressed with the OVMS v3 release candidate board: Board layout to match enclosure (including mounting holes) To be able to have a board + enclosure product. CP2102 power from USB (with no connection to 3.3v on ESP side) To fix sleep-mode power consumption issue with CP2102. 100nF for C21 To resolve auto-flash issue. 10K between pin 25 of the CP2102 and pin 35 of the ESP32 To protect against fake CP2102. Change to resistor values for voltage divider on ESP32 ADC To fix power consumption issue with that voltage divider network. Tri-state buffer on MAX7317 MISO using 74AHC1G125 To fix MAX7317 MISO not co-existing with MCP2515 MISOs. EGPIO P2 (MAX7317) 10K pull-up to 3.3v and connection to Rs of matching SN65 To fix sleep-mode power consumption issue of SN65. MCP2515 #1 10K pull-up on RX0BF and connection to Rs of matching SN65 To fix sleep-mode power consumption issue of MCP2515 and SN65. MCP2515 #2 10K pull-up on RX0BF and connection to Rs of matching SN65 To fix sleep-mode power consumption issue of MCP2515 and SN65. #3 was the worst. That has been plaguing us for months, and got worse when we changed #2 to power the CP2102 from USB. We thought it might be a ‘fake’ component issue, but that turned out to be not so. In the end, it turned out to be a silicon issue on the ESP32. Frustrating in that Espressif knew about it all along, but it was not documented or discussed much. Anyway, a change from 1nF to 100nF capacitor works around the issue and will continue to work with newer silicon (when Espressif release it). Apart from #3 and #6, these fixes are primarily to address power consumption. We want to get that as low as possible (particularly in sleep mode). Without the modem, and with the above fixes, it seems that we can get down to around 23mA in normal operation, 19mA with CAN asleep, and 4.5mA with everything sleeping (all these @12v supply). By comparison, with modem, OVMS v2 is around 80mA @12v (and can’t sleep). We might be able to get the sleep figure a bit lower in software, but we think we are about as low as it is going to get. At such low currents, our switched mode power supply is not very efficient, and further work on this is really now hitting diminishing returns. The modem should be able to be completely powered off, under control of the ESP32. It also has various low-power sleep modes. So, that will add to the consumption (as does wifi/bluetooth, if enabled), but only in use. Anyway, it is a separate board so any required fixes can be made directly without affecting the main board. New layout is done, and release candidate board is being made now. It should be in my hands any day. Assuming that is ok, we’ll pull the trigger and make the first production run of developer boards. Firmware is coming on, but we need more people working on it. Particularly for porting over vehicle support. So, #1 priority is getting those developer boards available. Regards, Mark.
Mark, thanks again for all your efforts to make V3 great! I've got not much spare time currently but will join firmware development & porting ASAP. Regards, Michael Am 21.08.2017 um 03:42 schrieb Mark Webb-Johnson:
New layout is done, and release candidate board is being made now. It should be in my hands any day. Assuming that is ok, we’ll pull the trigger and make the first production run of developer boards.
Firmware is coming on, but we need more people working on it. Particularly for porting over vehicle support. So, #1 priority is getting those developer boards available.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hey all ! It sounded like “Make xx Great Again” from someone who spends more time golfing than governing :-) But I couldn’t have said it any better ! I still remember when we were, well especially Mark I bet, still chasing after features and whatever MCU to go with and the ESP32 showed it’s nose (or silicon) Thank you Mark, and thank you Michael in the name of the “Twizystes” ! (Actually using Twizy-Cfg with a few mods, might have some commits to give back, mostly to bridge with a computer aboard) Best, JaXX./. On 21 Aug 2017, 23:19 +0200, Michael Balzer <dexter@expeedo.de>, wrote:
Mark,
thanks again for all your efforts to make V3 great!
I've got not much spare time currently but will join firmware development & porting ASAP.
Regards, Michael
Am 21.08.2017 um 03:42 schrieb Mark Webb-Johnson:
New layout is done, and release candidate board is being made now. It should be in my hands any day. Assuming that is ok, we’ll pull the trigger and make the first production run of developer boards.
Firmware is coming on, but we need more people working on it. Particularly for porting over vehicle support. So, #1 priority is getting those developer boards available.
-- 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
FYI: RC1 board, layout, and as it fits in prototype 3D printed case. China guys say it all checks out. I’ll have it in my hands any day now (just waiting for minor fit changes to enclosure), and then can confirm from my side. I’ll then give the go ahead for a small production run of developer boards. These will be fine for development, and later should be fine to go into cars, but there may be differences between these and the final production boards. If you are interested in helping out with development / porting vehicle support, and want one of these early boards, please could you eMail me personally to mark@webb-johnson.net <mailto:mark@webb-johnson.net> with the following details: Contact eMail address Full name Postal address Postal contact telephone number What area of the firmware are you willing to help out with Whether you want a prototype 3D printed case now (or we can send injection moulded case later when ready) Whether you want a modem board now, your preference for 3G or 4G, and if so what 3G AND 4G frequency ranges your cellular provider uses (That is private information, so please don’t reply to this mailing list - send to me privately). I am not sure what the pricing will be (I’ll confirm nearer the time), so nothing committed yet; just trying to get an indication of interest. I am tying to arrange some sponsorship for this, for the first few boards to go free to developers who have done the most for the project; so if you can commit to do something specific, please let me know. Regards, Mark.
On 21 Aug 2017, at 9:42 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Here’s the final issue-list we had to be addressed with the OVMS v3 release candidate board:
Board layout to match enclosure (including mounting holes) To be able to have a board + enclosure product.
CP2102 power from USB (with no connection to 3.3v on ESP side) To fix sleep-mode power consumption issue with CP2102.
100nF for C21 To resolve auto-flash issue.
10K between pin 25 of the CP2102 and pin 35 of the ESP32 To protect against fake CP2102.
Change to resistor values for voltage divider on ESP32 ADC To fix power consumption issue with that voltage divider network.
Tri-state buffer on MAX7317 MISO using 74AHC1G125 To fix MAX7317 MISO not co-existing with MCP2515 MISOs.
EGPIO P2 (MAX7317) 10K pull-up to 3.3v and connection to Rs of matching SN65 To fix sleep-mode power consumption issue of SN65.
MCP2515 #1 10K pull-up on RX0BF and connection to Rs of matching SN65 To fix sleep-mode power consumption issue of MCP2515 and SN65.
MCP2515 #2 10K pull-up on RX0BF and connection to Rs of matching SN65 To fix sleep-mode power consumption issue of MCP2515 and SN65.
#3 was the worst. That has been plaguing us for months, and got worse when we changed #2 to power the CP2102 from USB. We thought it might be a ‘fake’ component issue, but that turned out to be not so. In the end, it turned out to be a silicon issue on the ESP32. Frustrating in that Espressif knew about it all along, but it was not documented or discussed much. Anyway, a change from 1nF to 100nF capacitor works around the issue and will continue to work with newer silicon (when Espressif release it).
Apart from #3 and #6, these fixes are primarily to address power consumption. We want to get that as low as possible (particularly in sleep mode).
Without the modem, and with the above fixes, it seems that we can get down to around 23mA in normal operation, 19mA with CAN asleep, and 4.5mA with everything sleeping (all these @12v supply). By comparison, with modem, OVMS v2 is around 80mA @12v (and can’t sleep). We might be able to get the sleep figure a bit lower in software, but we think we are about as low as it is going to get. At such low currents, our switched mode power supply is not very efficient, and further work on this is really now hitting diminishing returns.
The modem should be able to be completely powered off, under control of the ESP32. It also has various low-power sleep modes. So, that will add to the consumption (as does wifi/bluetooth, if enabled), but only in use. Anyway, it is a separate board so any required fixes can be made directly without affecting the main board.
New layout is done, and release candidate board is being made now. It should be in my hands any day. Assuming that is ok, we’ll pull the trigger and make the first production run of developer boards.
Firmware is coming on, but we need more people working on it. Particularly for porting over vehicle support. So, #1 priority is getting those developer boards available.
Regards, Mark.
Now on my desk, and in my hands. A few hand-modified last-minute modifications, but so far it seems ok. I think we just might be ‘there’ (from a hardware point of view, at least). Size is a little bit bigger than v2, but we’ve left enough height to add an expansion board above the modem. Anything more (like big chunky relays, etc) and it is relatively simple to 3D print a taller top part of the shell. I’m going to validate all the peripherals, sleep modes, etc, this weekend. They’ve all been individually validated before, so I just need to make sure they all work together. Also check the new MAX7317 tri-state buffer on the MISO line. If all is ok, I’ll give the go-ahead to make the first small hand-produced batch for developers next week. So we will have the ability to get wider testing by non-technical users, I’m going to work on firmware ‘OTA’ update via SD-CARD and get that into the initial factory firmware. That would make it so that people are able to just put a firmware file on SD-CARD, drop it into the slot, and power on to update firmware. All the wireless (wifi, bluetooth, cellular) stuff is going to take a while (although Tom has made a great start on the wireless side). SIMCOM GSM side at the moment is limited to power control, sleep mode control, a ‘simcom tx’ command, and dumping rx traffic to the monitor. A lot of work still to do, but the hard learned logic in OVMS v2 should at least stay the same. We can turn it on/off, sleep it, wake it up, transmit and receive; what more do we need? The 3G and 4G versions of SIMCOM have a nice software MUX that works over ASYNC. That means we can have the control commands separated from data and separated from the GPS/GNS NMEA location stream. That vastly simplifies the control logic, makes controlling the modem more reliable, and speeds up GPS/GNS location tracking (as we no longer need to poll GPS/GNS). In other news, Greg has come on board and is going to start porting his OBDII ECU simulation code over to this framework. That will allow us to run HUDs, dongles, and all sorts of fun ODBII stuff directly from the DB26 expansion connector. Hopefully we can have this pretty close to day#1 full production run. Only sad thing is no more blinky lights ;-( Oh well, think of all the mA of power we save. And a USB terminal + Bluetooth App will make up for it. Regards, Mark.
On 23 Aug 2017, at 4:53 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
FYI: RC1 board, layout, and as it fits in prototype 3D printed case.
China guys say it all checks out. I’ll have it in my hands any day now (just waiting for minor fit changes to enclosure), and then can confirm from my side.
I’ll then give the go ahead for a small production run of developer boards. These will be fine for development, and later should be fine to go into cars, but there may be differences between these and the final production boards.
If you are interested in helping out with development / porting vehicle support, and want one of these early boards, please could you eMail me personally to mark@webb-johnson.net <mailto:mark@webb-johnson.net> with the following details:
Contact eMail address Full name Postal address Postal contact telephone number What area of the firmware are you willing to help out with Whether you want a prototype 3D printed case now (or we can send injection moulded case later when ready) Whether you want a modem board now, your preference for 3G or 4G, and if so what 3G AND 4G frequency ranges your cellular provider uses
(That is private information, so please don’t reply to this mailing list - send to me privately).
I am not sure what the pricing will be (I’ll confirm nearer the time), so nothing committed yet; just trying to get an indication of interest. I am tying to arrange some sponsorship for this, for the first few boards to go free to developers who have done the most for the project; so if you can commit to do something specific, please let me know.
Regards, Mark.
On 21 Aug 2017, at 9:42 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Here’s the final issue-list we had to be addressed with the OVMS v3 release candidate board:
Board layout to match enclosure (including mounting holes) To be able to have a board + enclosure product.
CP2102 power from USB (with no connection to 3.3v on ESP side) To fix sleep-mode power consumption issue with CP2102.
100nF for C21 To resolve auto-flash issue.
10K between pin 25 of the CP2102 and pin 35 of the ESP32 To protect against fake CP2102.
Change to resistor values for voltage divider on ESP32 ADC To fix power consumption issue with that voltage divider network.
Tri-state buffer on MAX7317 MISO using 74AHC1G125 To fix MAX7317 MISO not co-existing with MCP2515 MISOs.
EGPIO P2 (MAX7317) 10K pull-up to 3.3v and connection to Rs of matching SN65 To fix sleep-mode power consumption issue of SN65.
MCP2515 #1 10K pull-up on RX0BF and connection to Rs of matching SN65 To fix sleep-mode power consumption issue of MCP2515 and SN65.
MCP2515 #2 10K pull-up on RX0BF and connection to Rs of matching SN65 To fix sleep-mode power consumption issue of MCP2515 and SN65.
#3 was the worst. That has been plaguing us for months, and got worse when we changed #2 to power the CP2102 from USB. We thought it might be a ‘fake’ component issue, but that turned out to be not so. In the end, it turned out to be a silicon issue on the ESP32. Frustrating in that Espressif knew about it all along, but it was not documented or discussed much. Anyway, a change from 1nF to 100nF capacitor works around the issue and will continue to work with newer silicon (when Espressif release it).
Apart from #3 and #6, these fixes are primarily to address power consumption. We want to get that as low as possible (particularly in sleep mode).
Without the modem, and with the above fixes, it seems that we can get down to around 23mA in normal operation, 19mA with CAN asleep, and 4.5mA with everything sleeping (all these @12v supply). By comparison, with modem, OVMS v2 is around 80mA @12v (and can’t sleep). We might be able to get the sleep figure a bit lower in software, but we think we are about as low as it is going to get. At such low currents, our switched mode power supply is not very efficient, and further work on this is really now hitting diminishing returns.
The modem should be able to be completely powered off, under control of the ESP32. It also has various low-power sleep modes. So, that will add to the consumption (as does wifi/bluetooth, if enabled), but only in use. Anyway, it is a separate board so any required fixes can be made directly without affecting the main board.
New layout is done, and release candidate board is being made now. It should be in my hands any day. Assuming that is ok, we’ll pull the trigger and make the first production run of developer boards.
Firmware is coming on, but we need more people working on it. Particularly for porting over vehicle support. So, #1 priority is getting those developer boards available.
Regards, Mark.
participants (3)
-
Julien “JaXX” Banchet -
Mark Webb-Johnson -
Michael Balzer