[Ovmsdev] OVMS v3?

[Mark Webb-Johnson]

> The power issues have probably been a very rewarding learning experience.

In hindsight, yes. At the time, peering through a microscope while trying to de-solder a single pin on a micro-sized surface mount component where my smallest solder tip was the size of three pins; a PITA.

> The plastic enclosure seems great for Bluetooth and WiFi, but do you think there will be any FCC/CE issues?

Perhaps. The wifi/bluetooth antenna is at the end of the WROOM-32 module we use. We can arrange that at the side of the case. We had four options:

Use a metal shell enclosure like we do currently for v2, but change to plastic end-caps. The supplier wasn’t happy with this, and anyway the radio signal became a bit ‘directional’.
Modify the existing WROOM-32 modules, to add an external antenna. We lose certification of the module itself.
Use a WROOM-32 module with antenna connection, then an external antenna. Those modules don’t have certification.
Use a plastic case

I think for the moment, we’ll have to live with our choice of #4. It seems the least of four evils. If it becomes an issue when we go through certification, we can always add a metal shielding onto the board itself. That seems to be what pretty much everyone does anyway.

Regards, Mark.

> On 3 Aug 2017, at 9:54 AM, HONDA S-2000 <s2000 at audiobanshee.com> wrote:
> 
> 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.
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20170803/b698a894/attachment.htm>