[Ovmsdev] OVMS v3?

[HONDA S-2000]

Good news, and great work!

I've certainly needed multiple revisions for a design because of SPI MISO conflicts, so I feel your pain. The power issues have probably been a very rewarding learning experience.

The plastic enclosure seems great for Bluetooth and WiFi, but do you think there will be any FCC/CE issues? Maybe it's not the certifications that are as much of an issue as the chances that the non-radio circuits might create interference with the vehicle electronics. Since the OVMS v3 will be mounted under the dash in most installations, it seems like there is some risk that changing from a metallic to plastic case will leave the possibility of problems with unintended interference. Perhaps any problems along those lines can be solved with clever layout techniques to reduce signal transmissions.

Brian Willoughby
Sound Consulting


On Aug 2, 2017, at 6:19 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> On the circuit board side, all the peripherals are now working with the exception of the MAX7317 I/O expander. The MISO line on that is not tri-state buffered so is interfering with responses from the two MCP2515 on the same SPI bus. That was a nightmare to troubleshoot (everything looks good, but the MCP2515 responses simply couldn't be seen on the SPI bus - it took us a while to work out that the MCP2515 were working; we just couldn’t see any data out). Solution is relatively simple and is to add an external tri-state buffer chip driven by the !CS line of the MAX7317 - we’re testing this now on a patched board and it seems to work. All the other peripherals (including the three CAN buses) are working, and basic driver support is in the firmware. The issue that is taking the most time is the power management - making sure that we can deep sleep the board and all it’s peripherals. This has proven to be much harder than originally expected - we’ve got so much on this board that identifying each user of power and addressing them one by one is just taking time. The good news is that we’re almost done with this now. The last three power hogs (the CP2102, BTS45R, and SN65 chips) have been identified and we are testing solutions to power each down properly during deep sleep. It seems that we are going to be able to achieve low single digits mA during deep sleep, which is under 1/10th to 1/20th the power of the v2 OVMS hardware; lower than that will hopefully be achievable in software (doing things like powering down the external flash during deep sleep), but we are fast reaching diminishing returns. Espressif will also release other sleep modes in their upcoming SDK, that we hope to be able to take advantage of. The plan now is to make a Release Candidate (RC#1) board (our third revision of board) with these power control fixes and size adjusted to fit the enclosure (primarily the four mounting posts). Hopefully I’ll have that in my hands next week. We have a prototype modem board which looks good, and have started to work on firmware support for that.
> 
> These power control issues have taken so much longer than expected and have been the real hold-up in recent weeks. We originally thought that the power usage in OVMS v2 was primarily the modem and linear power supply choices we had made on that platform, but it has turned out that it is much more complex than that. Even things like the CAN transceivers (we tie the power control line to GND in both v2 and v3) take 5mA each - three of them in OVMS v3 is 15mA - so we need to re-work the power control line to be able to deep sleep these under the control of the MCP2515 controllers (and MAX7317 EGPIO in the case of the on-board CAN bus). Then, the CP2102 USB controller can’t deep-sleep from the output side (only from the USB side), so we have to re-work that so it is powered from the USB bus (so it will have zero consumption if USB is disconnected). That means re-working our CTS/RTS/DTR control line logic for flash programming over USB. Lots of little changes, and a steep learning curve. One on-board CAN bus, no SDCARD, no SPI, no EGPIO, etc, would have been much simpler ;-)
> 
> On the enclosure side, we’ve completed the 3D design (including logo directly in the plastic so we don’t need top sticker, and cut-out area for serial number / certification sticker on the base). Renders look like this:
> 
> Final enclosure will be in black/gray plastic. Just easier to see fit in white. Using plastic avoids any bluetooth/wifi antenna issues that a metal case brings.
>