[Ovmsdev] OVMS v2 stock / OVMS v3

Wed Aug 26 19:23:41 HKT 2015

I've been working on a similar device for a while, and I have a very nice
working prototype that may help:
https://hackaday.io/project/7134-crunchtrack
It already has an mbed-compatible STM32F3 Cortex M4, GPS and GSM modules, a
switching power supply, SD card slot, USB port, and fits inside a small
ELM327 dongle case: the board itself is 4x2 cm [
https://hackaday.io/project/7134/gallery#fab1dd8fe131e0410d64b3615e04458a
]. So it can be used standalone, or as a module that can be plugged on a
linux board to handle communication and low-power modes. The OBD connector
adapter board has jumpers to connect to one of the Leaf's CAN buses or to
the standard one. The GPS is a high quality Ublox 7 module that can be put
in sleep mode and has various power saving modes. The GSM module is still a
SIMCOM one, based on Mediatek chipset.
On the bottom connector there are some IOs, an UART, SPI, I2C, and on the
top debug connector there's a spare UART that may be used to add a
Bluetooth module or an ESP8266 wifi module.
I'm thinking about upgrading to a STM32F4 MCU to get 2 CAN buses and more
power/memory (1M vs 512K) but that will mean moving to BGA and a 4 layer
board, making it harder for the end user to rework and modify.
The device is open source, and I'd love to give back to the OVMS project.
Do you think this can be a starting point for v3?

Regards
Mastro Gippo

On Wed, Aug 26, 2015 at 10:32 AM, Mark Webb-Johnson <mark at webb-johnson.net>
wrote:

> Low power is one of our primary goals.
>
> The idea is that each module will be individually capable of being powered
> up/down or sleep/awake. In addition, we’ll use a proper switching power
> supply (the current ones literally burn 13V down to 5V and 3.3V). Finally,
> the framework will support the central processor being put to sleep.
>
> This is one of the reasons I am still interested in the hybrid
> Arduino/Linux design. I like the idea of a low power supervisor being able
> to sleep/awake a higher power processor.
>
> Regards, Mark.
>
> On 26 Aug, 2015, at 4:21 pm, Julien (JaXX) Banchet <jaxx at jaxx.org> wrote:
>
> I agree,
>
> The unit has to be simple (actually i would have seen something modular,
> with optionnal means of comms, but it would be a pain on the SW side I
> suppose)
> Even a simple console port could do... or ethernet (being a network guy,
> not liking wifi latency) and an MQTT stack :-)
>
> [ question: will each means of communication be disable-able ? the Twizy
> has a cr*ppy service battery, the actual v2 eats it up in less than a week
> in the best case, killing the car literally if you're away from a plug,
> there is nearly no need for a continuosly powered GSM/GPS when the car
> isn't moving, or barely a status update on a regular basis or on events ]
>
> JaXX./.
>
> Le 26/08/2015 09:58, Mark Webb-Johnson a écrit :
>
> Display is interesting, and something a few have asked about.
>
> My suggestion was to keep this off the basic unit, as it is just too
> expensive and means the unit must be mounted in a visible position. It
> dramatically changes the housing design, and is hard to please everyone
> with one design. I would rather provide:
>
>
>    - A standard port that can be used to drive an external display
>    - A standard protocol that can be used for external displays either
>    via that port or via bluetooth/wifi/cellular comms link
>
>
> That would mean a display could be run on an iPhone/Android device via
> bluetooth/wifi.
>
> It would also mean that a dumb display couldn’t be used, which would drive
> up cost for those that wanted a display, but would give us the flexibility
> to add one for those that want it. It would also keep all the display code
> out of the core project and into a separate project.
>
> Regards, Mark.
>
> On 26 Aug, 2015, at 3:48 pm, Julien (JaXX) Banchet <jaxx at jaxx.org> wrote:
>
> Hi,
>
> I have little personnal time but I'd still be highly interested in putting
> what I have on testing out a beta v3... I'm slowly working on a cluster
> replacement for the Twizy and having a board to preprocess comms to the
> CANbus (or moving what I'm doing to the "heavyweight" part of a Udoo
> Neo-like board) would be a great relief.
>
> Yes, I intend to make those LCD-dashboard-savvy Mercedes and Jaguar
> drivers jealous :-)
>
> So if there are any available slots for a test board or better/safer, an
> early version of a production board (to give priority to the devs, i'm in
> no hurry), count me in.
>
> Best,
>
> Julien JaXX Banchet
>
> Le 26/08/2015 09:37, Mark Webb-Johnson a écrit :
>
> Development boards are a tricky thing. Our suppliers hate making too many
> of them.
>
> What I’ve told them this time is to firstly make a couple of test boards
> that we can use to validate all major functionality (can we program, can we
> reach all the auxiliary chips, do the lights flash, etc). Once we have
> that, then come up with a development board based on the test board design
> (without box, and more pinouts available) and make 10 of them
> hand-soldered. We’ll send those out to the guys developing vehicle modules
> to help with their porting processes.
>
> Based on the feedback of the development boards, we can then re-layout the
> production board to optimise for the chosen case, and make the first
> production run (probably 100 to 200 units, machine soldered).
>
> Regards, Mark.
>
> On 25 Aug, 2015, at 4:04 pm, Michael Balzer <dexter at expeedo.de> wrote:
>
> Great news, thanks!
>
> Please put me on the list for two of the V3 development boards.
>
> I've forwarded your info to the Twizy forum. There are some active beta
> testers, I asked to send orders for the V3 development board to me or you.
>
> I said pricing will probably be max 200 €.
>
> Regards,
> Michael
>
>
> Am 25.08.2015 um 07:41 schrieb Mark Webb-Johnson:
>
> Plans change.
>
> For some inexplicable reason (Michael? #twizycon?), we had a jump in order
> for the v2 modules. August is not even yet over, and they are going too
> quickly now. We are down to about 40 (of which I need to retain at least 10
> for RMA/repair purposes).
>
> The Arduino+Linux hybrid sample boards look to be delayed another month,
> and MBED OS was due in August 2015 but has yet to make an appearance.
>
> I checked, and the supplier has just a few hundred SIM908 modules left.
>
> Accordingly, I just put in an order for definitely-the-last-batch of 100x
> v2 modules. With four more months to go in the year, I’ll take the risk.
>
> Hopefully we can start work on v3 next month, once we see the
> Arduino+Linux hybrid vs MBED OS options solidify. I suspect MBED OS won’t
> be finalised until 2016Q1 anyway. The guys I am working with in China
> suggest to first produce a small batch of development boards (not in a
> case, but functionally complete) so that we can start development work, and
> then work on packaging the board into a small footprint with case,
> certification, etc. I suspect that this could be a six month project to get
> a final v3 based packaged product, so those 140 remaining v2 modules should
> hopefully give us some breathing room.
>
> I am excited about bluetooth and wifi options. Pricing for these has
> plummeted, and available options grown dramatically. I am hopeful that we
> can get a small board with cellular + gps + wifi + bluetooth radios, for a
> reasonable cost. Add on a bunch of flash (1GB+), SD-card, RAM (at least
> 128KB, maybe more), at least 2 CAN ports, and we’ll have a pretty amazing
> vehicle hacking and telemetry platform.
>
> Regards, Mark
>
> On 11 Aug, 2015, at 10:17 am, Mark Webb-Johnson < <mark at webb-johnson.net>
> mark at webb-johnson.net> wrote:
>
>
> At the current rate, the batch we have of OVMS v2 modules will run out
> sometime in the next two months.
>
> Given the imminent shutdown of AT&T’s 2G network in USA, global
> re-allocation of 2G frequency bands, and the difficulties we are having
> obtaining the discontinued SIM908, it is decision time.
>
> Option #1: Re-order a large batch now, enough to last us into the new
> year, but with the risk that I’ll be personally stuck with them.
> Option #2: Just let the v2 modules run out, and move on with the plans for
> v3.
>
> Development on v2 is stagnating. Partly because the platform already does
> what we need it to do, and partly because we’re hitting the limits (no
> external connectivity other than GPRS, single CAN bus, no storage, limited
> RAM, flash, etc).
>
> The v3 plans have been on hold for some time, pending MBED OS release
> (first beta due this month) and the imminent release of hybrid processors
> such as that used in the UDOO Neo (due in September). We know what we want,
> but it is just too hard to pick a long-term platform when everything is on
> the cusp of changing.
>
> I really want a v3 module. Something with lots of RAM and Flash, wifi,
> bluetooth and cellular connectivity, multiple CAN bus support, and a rich
> development platform. Something we can all use as a platform for reverse
> engineering as well as end-user connectivity. I’ll do everything I can to
> make this a reality. Just not today. Too much is changing and we need to
> wait for things to stabilise.
>
> So, my gut feeling is to choose option #2. 2G GPRS is slowing dying, and
> building more on that platform just seems to be the wrong decision. This
> may leave us with several months of no platform stock, but I would rather
> people waited than spend $100 on something that is going to be
> obsolete/outdated. Kind of like buying an iPhone in August ;-) I don’t want
> to be stuck with the stock, and I don’t want people to buy a v2, only to
> have v3 come out a week later.
>
> Even if we started now, which we can’t, an optimistic schedule for the
> first end-user v3 units would be early 2016.
>
> So, tough decisions, but I really think option #2 is best. Bottom line is
> if you need v2 modules, order them now.
>
> If you are likely to need a large quantity for any upcoming projects, let
> me know. The SIM908 modules will be unavailable within the next month or
> so, and changing to another module is a PITA I don’t want to deal with
> (especially given the tight RAM and FLASH we have now).
>
> Regards, Mark.
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>
>
> _______________________________________________
> OvmsDev mailing list
> 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
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> 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.openvehicles.com/pipermail/ovmsdev/attachments/20150826/2625c5de/attachment.htm>