[Ovmsdev] V3 size and arrangement
Mark Webb-Johnson
mark at webb-johnson.net
Mon Jun 19 10:04:57 HKT 2017
And we inch closer to the finishing line…
Here’s the PCB layout (with copper layer removed to make it easier to see both sides). About the same height as OVMS v3, but an inch or so wider. I’ve also attached schematic, and top+bottom layer detail for the main as well as modem board. We’re trying to go with one modem board PCB, with different components put on it depending on 3G/4G modem.
This _should_ be the final layout and arrangement made to fit the enclosure. We have two enclosure candidates:
Metal shell, like ovms v2. If we use this, we need to bring out bluetooth/wifi antenna as well (to a little stubby antenna on the enclosure directly).
Plastic shell, injection moulded.
My preference is for #2, but I’m waiting to see it. The up-front cost for the injection moulding is high, but long-term is cheaper. We’re 3D printing a prototype at the moment (to get the design 100% before making the mould - to keep costs down).
Firmware framework is progressing. Fighting missing bits in ESP32 newlib… #notquitethefulllibc
Regards, Mark.
> On 9 Jun 2017, at 1:41 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>
> Just a short update on progress.
>
> It was painful, but we’ve finished the validation of the OVMS v3 board. Only one ESP32 was blown in the entire testing process ;-) [ Putting a 12V pin just next to a 3.3V pin on the switched 12V probably wasn’t such a smart idea. ] Oh well, at least I had fun with a microscope and some SMT soldering skills.
>
> Some nasty bugs and documentation issues on the ESP32 side of things, as well as an inadvertently swapped pair of MOSI / MISO pins caused endless issues. Thank Saleae for logic analysers.
>
> <image2.jpeg>
>
> Really rather cool to watch the logic analyser display SPI bus traffic to/from the MCP2515, then CAN bus output of the message itself.
>
> Most of the issues we’ve been having are because the ESP32 internal pull-up system just doesn’t seem to be working well. Some of the GPIO pins have to use the RTC side to do pull-up, and behave the worst. We often get 2.1V, not 3.3V, measured; and it just doesn’t seem reliable (especially on the high speed side such as SPI and SD-card access). Switching to physical pull-ups resolve these issues, so that is what we are doing. There were also issues with dual-purposes GPIO lines used during bootstrapping. For example, the GPIO2 line (which must be low during boot for firmware download), and GPIO12 (which is used during boot for 1.8v / 3.3v flash selection). We’re also going to prepare pull-up pads for the other lines, and some test clip connection points, but leave them unpopulated - should be easier to change things in future, if necessary.
>
> To keep the high-speed SPI buses used to talk to the MCP2515 and MAX7317 short and clean, we’ve had to remove those three pins from the DB26 external expansion connector. It just seemed to be causing too much interference. These pins are still available on the expansion slot(s), and the SPI master driver we have switched to supports software control of the CS lines, so can support more than 3 SPI slaves on one master.
>
> Here is the current status:
>
> Power supply: vehicle 12V
> 3.3V: 3.300V measured and very stable - pass
> EXT_PWR: 11.704V measured - pass
> EXT_12V: 12.002V measured - pass
> USB_5V: 0.7013V measured (floating?) - pass
> Power supply: USB 5V
> 3.3V: 3.301V measured and very stable - pass
> EXT_PWR: 4.525V measured - pass
> EXT_12V: 0.0012V measured - pass
> USB_5V: 4.810V measured - pass
> Power supply: vehicle 12V and USB 5V
> 3.3V: 3.301V measured and very stable - pass
> EXT_PWR: 11.771V measured - pass
> EXT_12V: 12.031V measured - pass
> USB_5V: 4.838V measured - pass
> Reset Button
> Tested ok - pass
> Boot Button
> Tested ok - pass
> CP2102
> Async comms: Tested ok - pass
> Automatic firmware download: Tested ok - pass
> Wifi
> Tested ok - pass
> Bluetooth
> Tested ok - pass
> External flash
> Special ESP32 fuse settings required
> Tested ok - pass
> SD-CARD
> 1-line mode: physical pull-ups added - pass
> 10K pull-up needed on GPIO14, GPIO15, GPIO4, GPIO13
> Link required between GPIO0 and GPIO2
> Special pull up and fuse setting arrangement needed for GPIO12
> 4-line mode: physical pull-ups added - pass
> 10K pull-up needed on GPIO14, GPIO15, GPIO4, GPIO13
> Link required between GPIO0 and GPIO2
> Special pull up and fuse setting arrangement needed for GPIO12
> ESP32 CAN bus #0 - pass
> 1MHz bus speed
> Transmit: Working perfectly - pass
> Receive: Working perfectly - pass
> MCP2515 CAN bus #1
> SPI MOSI/MISO swapped
> 1MHz bus speed
> Transmit: Working perfectly - pass
> Receive: Working perfectly - pass
> MCP2515 CAN bus #2
> SPI MOSI/MISO swapped
> 1MHz bus speed
> Transmit: Working perfectly - pass
> Receive: Working perfectly - pass
> MAX7317
> Remove pull-down to GND on SW_CTL, and add physical pull-up.
> Add pull-up on SP_CS3.
> Tested, and works ok - pass
> Vehicle 9 pin port
> Visually ok - pass
> Connections ok
> Expansion 26 pin port
> Visually ok - pass
> SPI MOSI/MISO swapped
> Connections ok
> USB port
> Visually ok - pass
> To change to a physically stronger port (or mounting arrangement)
> Expansion slot #1
> Visually ok - pass
> Expansion slot #2
> Visually ok - pass
> To be removed in production board
>
> Burning the ESP32 fuses was exciting. This is a one-time operation with no way back. It is literally passing too much current through some little wires in the chip, to burn through and break the wire. Blowing the fuse. Once we do it, here is what we get:
>
> $ espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse XPD_SDIO_REG 1
> $ espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse XPD_SDIO_TIEH 1
> $ espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse XPD_SDIO_FORCE 1
>
> $ espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_CLK 6
> $ espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_Q 7
> $ espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_D 8
> $ espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_HD 9
> $ espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_CS0 22
>
> $ espefuse.py -p /dev/tty.SLAB_USBtoUART summary
> XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 1 R/W (0x1)
> XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 1 R/W (0x1)
> XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 1 R/W (0x1)
>
> SPI_PAD_CONFIG_CLK Override SD_CLK pad (GPIO6/SPICLK) = 6 R/W (0x6)
> SPI_PAD_CONFIG_Q Override SD_DATA_0 pad (GPIO7/SPIQ) = 7 R/W (0x7)
> SPI_PAD_CONFIG_D Override SD_DATA_1 pad (GPIO8/SPID) = 8 R/W (0x8)
> SPI_PAD_CONFIG_HD Override SD_DATA_2 pad (GPIO9/SPIHD) = 9 R/W (0x9)
> SPI_PAD_CONFIG_CS0 Override SD_CMD pad (GPIO11/SPICS0) = 22 R/W (0x16)
>
> Once that is done, we can simply change to DIO mode for SPI flashing and set flash size to 16MB - it will now use our external 16MB flash and the WROOM-32 4MB flash will not be used. In theory, we should still be able access the WROOM-32 4MB flash in our code, but it is not used by the system. This procedure will be done by the factory, as part of factory firmware load.
>
> So, yesterday I handed the final list of all the above over to the China guys. We’re happy that the board is close enough to try to make a production version, so they are sourcing an enclosure and re-laying everything out to fit and match that. The goal is to get the system about the same height and depth as an OVMS v2 module, just about an inch longer. Biggest constraint seems to be the number and size of external connectors we have.
>
> Here is what I sent China:
>
> <PastedGraphic-1.tiff>
>
> and this is what they sent back:
>
> <269B1E05-5609-4430-B04B-23D2A314D01E.png>
>
> Touché, China. You win that one.
>
> <6DBB6579-A139-46BE-8664-2C3B3D74C467.png>
>
> We’re trying to find some low-profile stacking connectors to keep the depth reasonable.
>
> So, the enclosure selection and final board layout is being drawn up now by the China side. I’m taking a break from banging on SPI buses, and now full-time on the firmware framework.
>
> Regards, Mark.
>
>> On 22 May 2017, at 10:58 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>
>> I'm still trying to work out the stackable/side-by-side issue.
>>
>> The thing I didn't like with the stackable option is the height (assuming each expansion module is also stackable). Every time I look at Arduino / Raspberry / etc, I think it is too tall. My problem is that top-most stackable connector that is _always_ empty. I know why it is there - but it just increases the height for the enclosure.
>>
>> I am thinking that perhaps there is a way out.
>>
>> What if we used a stackable design, but just have the modem modules non-stackable? The modem always goes on top. That way, the height of a normal system (without expansion modules other than the modem) is mostly unaffected. If an expansion module is required, then it must be stackable and placed between the main board and the modem. The non-stackable modem always on top. So for the 5% of users who use in-the-box expansion, they need a bigger case, but the 95% of other users can go with something slimmer.
>>
>> Kind of like this: Base board on the bottom, stackable expansion boards in the middle, and non-stackable modem board on top. The top picture shows the 5% case (with stackable expansion module sandwiched), the bottom picture shows the 95% case (with just base and modem).
>>
>> Size wise, we could go with something more like an Aurduido Due. Wider than OVMS v2, but about the same height and depth.
>>
>> Thoughts?
>>
>> Regards, Mark.
>>
>> <image1.jpeg>
>>
>> <image2.jpeg>
>>
>>
>>> On 19 May 2017, at 2:23 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>
>>> I've got the first OVMS v3 development board in my hands now. The components seem fine, and I'm finalizing the QC program that checks everything to make sure all is ok. 16MB flash with OTA capability, Wifi, Bluetooth, 3xCAN bus, lots of GPIO, switched 12V, power by USB/12V, SD card reader/writer, optional 2G/3G/4G modem (with GPS), two expansion slots, USB, and an external expansion connector - all look good.
>>>
>>> Both 3G and 4G development expansion boards are also being made now, and I should have those next week.
>>>
>>> But, having seen it and held it, I'm now having second thoughts about the layout. As you can see from the attached pictures, the expansion slots are each about 60mm x 45mm. Putting two of those on the board makes it about 9.5cm x 9.5cm square. Height will be similar (a little bit taller) than the current OVMS v2. This is a first draft run only, just to confirm the components, but as you can see there is quite a lot of blank space and traces for the two expansion slots. That, and the sheer number of connectors we have, dominate the board. Let's call this arrangement (A).
>>>
>>> There was an alternative arrangement that I considered a while back. That would be to have just one expansion slot, but use stackable connectors (so multiple boards could be piggybacked on each other). In that arrangement, the expansion slot could be either vertical or horizontal, with a vertical arrangement being close in size to the existing OVMS v2 (but the height would need to be much taller to accommodate the piggybacked expansion boards). Let's call this arrangement (B).
>>>
>>> It doesn't change the wiring. Just the size and arrangement of components on the board, as well as the box housing this all. (A) ends up with a 1" wider+taller box of about the same thickness, while (B) ends up with a box about the same width and height, but significantly thicker. To me, it seems that (A) is more automotive, and (B) more hobbyist.
>>>
>>> What do people think?
>>>
>>> In the meantime, on with development (now that at last I have a target in my hands).
>>>
>>> Mark
>>>
>>> <image1.jpeg>
>>>
>>> <image2.jpeg>
>>>
>>> <image3.jpeg>
>>>
>>> <image4.jpeg>
>>>
>>> <image5.jpeg>
>>>
>>> <image6.jpeg>
>>>
>>> <image7.jpeg>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20170619/81c09629/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PCB.pdf
Type: application/pdf
Size: 400394 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20170619/81c09629/attachment-0004.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20170619/81c09629/attachment-0006.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sch.pdf
Type: application/pdf
Size: 157124 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20170619/81c09629/attachment-0005.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20170619/81c09629/attachment-0007.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OVMS V3 PCB.pdf
Type: application/pdf
Size: 613179 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20170619/81c09629/attachment-0006.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20170619/81c09629/attachment-0008.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MDM V1.0.pdf
Type: application/pdf
Size: 383883 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20170619/81c09629/attachment-0007.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20170619/81c09629/attachment-0009.html>
More information about the OvmsDev
mailing list