Mark, here's a potential buyer of ~50 v3 modules. Do we have a production schedule yet? Thanks & regards, Michael -------- Weitergeleitete Nachricht -------- Betreff: OVMS v3? Datum: Wed, 2 Aug 2017 16:15:40 +0200 (CEST) Von: fabian@legoutdulibre.com An: dexter@dexters-web.de Hi, I am the IT manager for a small transport company in Canada, evaluating different devices to track our vehicles and store other data. I read with interest your post 3 months ago about work on OVMS v3 boards/devices. Could you post an brief update on your site about these? It would help in my research, our timeframe is Nov/Dev 2017 (~50 vehicles, possibly more). Many thanks, Fabian Rodriguez https://legoutdulibre.com
Here’s an update: On the software side, Steve (who is using a DEVKIT-C for development) has been doing some great work on the command interface, including USB serial and now TELNET consoles (over wifi). This is looking pretty elegant (dare I say ‘polished’) now, with on-line help, tab option expansion, etc; and I’m very grateful to Steve for all his hard work on this. The same command interface will be used for SMS, scripting, event triggers, and pretty much all interactions with the module; so it is important that we get this right. I’ve been working on the framework; things like metrics, configuration, power management, peripheral support, etc. All is looking good with this now, and coming together nicely. I’m particularly happy with the extensibility of the framework - really easy to add commands or other functionality that will then be available through all the different interfaces. Everything is in github, so you can follow progress there. 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: Rough prototype 3D printed, it looks 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. Production schedule will depend on outcome of RC#1 board next week. If that is OK, we’ll go ahead and proceed to build a limited-run set of boards for developers based on that design. If people want enclosures, we can 3D print for the moment, until the injection mold is ready. The actual production run is relatively simple. We give the go ahead and one-to-two weeks later get hundreds of modules. The issue is getting to the stage where we are brave enough to say ‘go ahead’. Regards, Mark.
On 3 Aug 2017, at 12:18 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
here's a potential buyer of ~50 v3 modules. Do we have a production schedule yet?
Thanks & regards, Michael
-------- Weitergeleitete Nachricht -------- Betreff: OVMS v3? Datum: Wed, 2 Aug 2017 16:15:40 +0200 (CEST) Von: fabian@legoutdulibre.com <mailto:fabian@legoutdulibre.com> An: dexter@dexters-web.de <mailto:dexter@dexters-web.de>
Hi,
I am the IT manager for a small transport company in Canada, evaluating different devices to track our vehicles and store other data.
I read with interest your post 3 months ago about work on OVMS v3 boards/devices. Could you post an brief update on your site about these? It would help in my research, our timeframe is Nov/Dev 2017 (~50 vehicles, possibly more).
Many thanks,
Fabian Rodriguez https://legoutdulibre.com <https://legoutdulibre.com/>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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.
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@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@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.
Long answer sent to the list a few minutes ago. Short answer is Nov/Dec timeframe should be fine. We should be done with hardware this month. Regards, Mark.
On 3 Aug 2017, at 12:18 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
here's a potential buyer of ~50 v3 modules. Do we have a production schedule yet?
Thanks & regards, Michael
-------- Weitergeleitete Nachricht -------- Betreff: OVMS v3? Datum: Wed, 2 Aug 2017 16:15:40 +0200 (CEST) Von: fabian@legoutdulibre.com <mailto:fabian@legoutdulibre.com> An: dexter@dexters-web.de <mailto:dexter@dexters-web.de>
Hi,
I am the IT manager for a small transport company in Canada, evaluating different devices to track our vehicles and store other data.
I read with interest your post 3 months ago about work on OVMS v3 boards/devices. Could you post an brief update on your site about these? It would help in my research, our timeframe is Nov/Dev 2017 (~50 vehicles, possibly more).
Many thanks,
Fabian Rodriguez https://legoutdulibre.com <https://legoutdulibre.com/>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Thanks, Mark! I've forwarded the info to Fabian. Regards, Michael Am 03.08.2017 um 03:25 schrieb Mark Webb-Johnson:
Long answer sent to the list a few minutes ago.
Short answer is Nov/Dec timeframe should be fine. We should be done with hardware this month.
Regards, Mark.
On 3 Aug 2017, at 12:18 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
here's a potential buyer of ~50 v3 modules. Do we have a production schedule yet?
Thanks & regards, Michael
-------- Weitergeleitete Nachricht -------- Betreff: OVMS v3? Datum: Wed, 2 Aug 2017 16:15:40 +0200 (CEST) Von: fabian@legoutdulibre.com An: dexter@dexters-web.de
Hi,
I am the IT manager for a small transport company in Canada, evaluating different devices to track our vehicles and store other data.
I read with interest your post 3 months ago about work on OVMS v3 boards/devices. Could you post an brief update on your site about these? It would help in my research, our timeframe is Nov/Dev 2017 (~50 vehicles, possibly more).
Many thanks,
Fabian Rodriguez https://legoutdulibre.com
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
participants (3)
-
HONDA S-2000 -
Mark Webb-Johnson -
Michael Balzer