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
