<div dir="ltr"><div><div><div><div><div>I've been working on a similar device for a while, and I have a very nice working prototype that may help: <a href="https://hackaday.io/project/7134-crunchtrack">https://hackaday.io/project/7134-crunchtrack</a><br></div>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 [ <a href="https://hackaday.io/project/7134/gallery#fab1dd8fe131e0410d64b3615e04458a">https://hackaday.io/project/7134/gallery#fab1dd8fe131e0410d64b3615e04458a</a> ]. 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. <br></div>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.<br></div>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.<br></div>The device is open source, and I'd love to give back to the OVMS project.<br></div><div>Do you think this can be a starting point for v3?<br></div><div><br></div><div>Regards<br></div><div>Mastro Gippo<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 26, 2015 at 10:32 AM, Mark Webb-Johnson <span dir="ltr"><<a href="mailto:mark@webb-johnson.net" target="_blank">mark@webb-johnson.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Low power is one of our primary goals.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards, Mark.</div><div><div class="h5"><div><br><div><blockquote type="cite"><div>On 26 Aug, 2015, at 4:21 pm, Julien (JaXX) Banchet <<a href="mailto:jaxx@jaxx.org" target="_blank">jaxx@jaxx.org</a>> wrote:</div><br><div>
<div bgcolor="#FFFFFF" text="#000000">
I agree,<br>
<br>
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)<br>
Even a simple console port could do... or ethernet (being a network
guy, not liking wifi latency) and an MQTT stack :-)<br>
<br>
[ 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 ]<br>
<br>
JaXX./.<br>
<br>
<div>Le 26/08/2015 09:58, Mark Webb-Johnson
a écrit :<br>
</div>
<blockquote type="cite">
Display is interesting, and something a few have asked about.
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>
<ul>
<li>A standard port that can be used to drive an
external display</li>
<li>A standard protocol that can be used for external
displays either via that port or via bluetooth/wifi/cellular
comms link</li>
</ul>
</div>
<div><br>
</div>
<div>That would mean a display could be run on an
iPhone/Android device via bluetooth/wifi.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Regards, Mark.</div>
<div><br>
<div>
<blockquote type="cite">
<div>On 26 Aug, 2015, at 3:48 pm, Julien (JaXX)
Banchet <<a href="mailto:jaxx@jaxx.org" target="_blank">jaxx@jaxx.org</a>>
wrote:</div>
<br>
<div>Hi,<br>
<br>
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.<br>
<br>
Yes, I intend to make those LCD-dashboard-savvy Mercedes
and Jaguar drivers jealous :-)<br>
<br>
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.<br>
<br>
Best,<br>
<br>
Julien JaXX Banchet<br>
<br>
Le 26/08/2015 09:37, Mark Webb-Johnson a écrit :<br>
<blockquote type="cite">Development boards are a
tricky thing. Our suppliers hate making too many of
them.<br>
<br>
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.<br>
<br>
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).<br>
<br>
Regards, Mark.<br>
<br>
<blockquote type="cite">On 25 Aug, 2015, at
4:04 pm, Michael Balzer <<a href="mailto:dexter@expeedo.de" target="_blank">dexter@expeedo.de</a>>
wrote:<br>
<br>
Great news, thanks!<br>
<br>
Please put me on the list for two of the V3
development boards.<br>
<br>
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.<br>
<br>
I said pricing will probably be max 200 €.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
Am 25.08.2015 um 07:41 schrieb Mark Webb-Johnson:<br>
<blockquote type="cite">Plans change.<br>
<br>
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).<br>
<br>
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.<br>
<br>
I checked, and the supplier has just a few hundred
SIM908 modules left.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards, Mark<br>
<br>
<blockquote type="cite">On 11 Aug, 2015, at
10:17 am, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" target="_blank"></a><a href="mailto:mark@webb-johnson.net" target="_blank">mark@webb-johnson.net</a>>
wrote:<br>
<br>
<br>
At the current rate, the batch we have of OVMS v2
modules will run out sometime in the next two
months.<br>
<br>
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.<br>
<br>
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.<br>
Option #2: Just let the v2 modules run out, and
move on with the plans for v3.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Even if we started now, which we can’t, an
optimistic schedule for the first end-user v3
units would be early 2016.<br>
<br>
So, tough decisions, but I really think option #2
is best. Bottom line is if you need v2 modules,
order them now.<br>
<br>
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).<br>
<br>
Regards, Mark.<br>
<br>
</blockquote>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">OvmsDev@lists.teslaclub.hk</a><br>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</blockquote>
<br>
-- <br>
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal<br>
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26<br>
<br>
<br>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">OvmsDev@lists.teslaclub.hk</a><br>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</blockquote>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">OvmsDev@lists.teslaclub.hk</a><br>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</blockquote>
<br>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">OvmsDev@lists.teslaclub.hk</a><br>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">OvmsDev@lists.teslaclub.hk</a>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">OvmsDev@lists.teslaclub.hk</a><br><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br></div></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" rel="noreferrer" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
<br></blockquote></div><br></div>