<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Michael,<div><br></div><div>I think there is a confusion around the use of vehicle_fn_smshandler - that is to override (premsg) or extend (!premsg) an existing SMS command. I hadn't thought about the vehicle module wanting its own SMS messages.</div><div><br></div><div>We can do this in two ways: (1) expose a vehicle sms handler table to the net_sms code and have it look there, or (2) just hook in to the vehicle and let it handle sms messages itself. For the moment, I've chosen (2) as I think there will be relatively few vehicle-specific sms messages. The old way we did this was just 'strcmp' for each possible SMS commands. If there are not too many, that is fine and probably more efficient than having a dispatch table. Anyway, I've added a vehicle_fn_smsextensions now, which is called if the incoming sms is not recognised by net_sms and allows the vehicle to look.</div><div><br></div><div>Michael B: can you try to migrate your Twizy code to this new vehicle_fn_smsextensions framework for Twizy-specific sms messages, and vehicle_fn_smshandler for the extension to the STAT command? Regarding your vehicle_twizy_sms_handle_stat() function, is it not possible to just extend (add a couple of lines) the SMS reply, rather than replace the entire command?</div><div><br></div><div>I also tested the new net_sms arrangement, found a few bugs, and fixed them. Code is on github now.</div><div><br></div><div>I'm now looking at implementing a registration mechanism so that the vehicle modules can register the commands they implement, as well as other parameters for what they support, and we can push this in net_msg when we connect to the server.</div><div><br></div><div>Regards, Mark.</div><div><br><div><div>On 18 Nov, 2012, at 4:38 AM, Michael Balzer <<a href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
Mark,<br>
<br>
I ported my STAT changes to the new framework and tried to prepare
it for my first specific commands as well:<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/7b050c4dd92045d62bce3315122ac496c5d305c6">https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/7b050c4dd92045d62bce3315122ac496c5d305c6</a><br>
<br>
Haven't tested yet, but the vehicle / framework distinction becomes
very clean now I think.<br>
<br>
Regarding hooking in the vehicle cmdtable: I now think that was
nonsense, as the vehicle dispatcher will need to parse the command
itself. I'll wait for your thoughts on if/how to integrate the
common auth stuff with this.<br>
<br>
To get internal net_sms_stat() calls to use the overloaded function,
I suggest to inject the call through the SMS dispatcher as shown in
my commit. There's only one call outside net_sms, and that's not
time critical and using fixed (no) arguments. I also think STAT is
the only SMS we need to route like this (?)<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 17.11.2012 19:20, schrieb Michael
Balzer:<br>
</div>
<blockquote cite="mid:50A7D588.4010006@expeedo.de" type="cite">Mark,
<br>
<br>
man, you're fast! :-)
<br>
<br>
...ok, that looks good for extending and replacing existing SMS
commands.
<br>
<br>
Next step will be to split the command table in standard + vehicle
commands. That could be done by simply calling
vehicle_fn_smshandler() before checking the standard cmdtable and
leave everything else to the vehicle module, but I like the
concept of net_sms_in() doing the common caller authentication for
all commands.
<br>
<br>
I assume you intend to use this for the vehicle commands as well?
So the vehicle module will hook in a specific cmdtable+hfntable to
be used by net_sms_in()?
<br>
<br>
Thinking about auth... maybe I'm missing something, but why is
there a need for the three auth modes? Couldn't it just be mode 3
for every command?
<br>
<br>
Regards,
<br>
Michael
<br>
<br>
<br>
Am 17.11.2012 16:03, schrieb Mark Webb-Johnson:
<br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">I'll also port my specific STAT?
version to the new framework ASAP.
<br>
</blockquote>
This is a little more involved. I need to re-work the SMS
framework to hook in to the vehicle modules nicely, and that
will require quite a bit o structural rework. Let me handle
this - I'll get it done in the next hour or two.
<br>
</blockquote>
I've done the structural work for this, and committed to github.
<br>
<br>
There is now a vehicle module hook for SMS commands, that are
run pre-command (allowing a vehicle module to completely
override an SMS command), and post-command (allowing a vehicle
module to add stuff onto the end of an standard sms command).
<br>
<br>
I haven't re-worked Michael's Twizy STAT extensions, yet, but
the hooks are now there.
<br>
<br>
The changes were quite drastic, and I've probably broken a lot.
It builds, but completely untested. I just wanted to get it in
so you could have a look at it.
<br>
<br>
I'll test it tomorrow, and fix as necessary.
<br>
<br>
Regards, Mark.
<br>
<br>
On 17 Nov, 2012, at 9:24 PM, Mark Webb-Johnson
<a class="moz-txt-link-rfc2396E" href="mailto:mark@webb-johnson.net"><mark@webb-johnson.net></a> wrote:
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">I will look into integrating the
internal GPS flag so we don't need a compiler switch for
this as well. Does it make sense to couple this to the car
type or could someone with a GPS equipped car have some
reason to occasionally use the OVMS GPS instead?
<br>
</blockquote>
Its ok. I've handled this. Just add a bitmap flag set to
net.h/net.c and controlled it by that. It defaults to OFF (in
vehicle.c initialisation), and the none, obdii, Volt/Ampera
and Twizy modules enable it.
<br>
<br>
<blockquote type="cite">I'll also port my specific STAT?
version to the new framework ASAP.
<br>
</blockquote>
This is a little more involved. I need to re-work the SMS
framework to hook in to the vehicle modules nicely, and that
will require quite a bit o structural rework. Let me handle
this - I'll get it done in the next hour or two.
<br>
<br>
<blockquote type="cite">I have one concern for the overlaying
of the vehicle RAM sections:
<br>
</blockquote>
I'll have to think about this and have a look at how it is
initialised at the moment. My guess is we're linking to the c
library version that wipes all user ram to zero on reboot.
<br>
<br>
Regards, Mark.
<br>
<br>
On 17 Nov, 2012, at 3:52 AM, Michael Balzer
<a class="moz-txt-link-rfc2396E" href="mailto:dexter@expeedo.de"><dexter@expeedo.de></a> wrote:
<br>
<br>
<blockquote type="cite">Mark,
<br>
<br>
I followed your branch naming, "v2" on my repository adds my
latest Twizy changes to the new framework.
<br>
<br>
Stunningly, V2 worked out of the box :-) Great job!
<br>
<br>
I will look into integrating the internal GPS flag so we
don't need a compiler switch for this as well. Does it make
sense to couple this to the car type or could someone with a
GPS equipped car have some reason to occasionally use the
OVMS GPS instead?
<br>
<br>
I'll also port my specific STAT? version to the new
framework ASAP.
<br>
<br>
I have one concern for the overlaying of the vehicle RAM
sections: I now changed most of my state variables to
uninitialized to harden against crash resets (we've got SRAM
after all). That works quite well with the old framework. I
had no reset with V2 up to now -- my concern is, that an
initialized overlay from another vehicle will initialize my
variables as well. As all vehicle modules exist side by side
now, can we introduce two data sections, one explicitly
being uninitialized? #pragma idata seems to be meant for
something like that, but everything's now in udata, even
initialized vars...
<br>
<br>
Regards,
<br>
Michael
<br>
<br>
<br>
Am 15.11.2012 14:52, schrieb Mark Webb-Johnson:
<br>
<blockquote type="cite">I've just committed another night's
work on this. Looks good and now runs on actual hardware.
<br>
<br>
I've extended the MODULE and MODULE? SMS commands with a
fourth parameter - the car type - to allow this to be set.
Also SMS VERSION now shows the car type being used.
<br>
<br>
I've ported the SMS commands over to the new vehicle
module framework, and they look good.
<br>
<br>
I've bumped the version to 2.1.1, to reflect the major
restructuring that this is.
<br>
<br>
This will still only run on v2 hardware at present. No
reason we can't support v1 (and will) - just need to tidy
up the build configurations.
<br>
<br>
Regards, Mark.
<br>
<br>
On 14 Nov, 2012, at 10:57 PM, Mark Webb-Johnson
<a class="moz-txt-link-rfc2396E" href="mailto:mark@webb-johnson.net"><mark@webb-johnson.net></a> wrote:
<br>
<br>
<blockquote type="cite">I've just committed my
work-in-progress for this to the github v2 branch.
<br>
<br>
Best I can say about it is that it compiles and links
without error.
<br>
<br>
It would be a miracle if it actually ran. I doubt it. I
haven't had a chance to test it on real hardware yet.
<br>
<br>
The framework for multiple cars is there, and seems to
work ok. I can't get the overlay data section working
(yet) - it is there but doesn't seem to be overlaying
the different vehicle data and saving ram like it
should. I re-worked the 100 byte net_msg_cmd_msg to be a
pointer, saving a lot of ram but possibly breaking more
advanced commands like "AT", "MMI/USSD" and "SMS" - I'll
test them when I get a chance to run this on real
hardware.
<br>
<br>
I followed Michael B's suggestion for the net_msg_cmd
handlers, and the hooks in general. So far, the can
hooks are there, as well as the re-work of the
net_msg_cmd stuff to hook through to the vehicle. I
haven't had a chance to remove some of the old stub
functions yet.
<br>
<br>
The overall approach is that I've moved the old common
can code to vehicle.h and vehicle.c. This defines a
series of hooks, for vehicle initialisation. When the
system starts up, a PARAM_VEHICLETYPE is now used to
define the type of vehicle, and initialise that one
vehicle module. During initialisation, the vehicle
module hooks itself in to other functions it requires.
If it doesn't hook in, the function is handled by the
default handler. Once this part is working well, I
intend to add hooks for SMS messages as well.
<br>
<br>
To create a new vehicle, we would need to create a
vehicle_* module, add the #define for it, and change
vehicle.c initialisation to detect the vehicle type and
initialise the module. It would be nice to have a better
plugin architecture for this, but we're (a) limited by c
(not c++), and (b) any such architecture would need ram
space which is at a premium compared to rom.
<br>
<br>
I've still got a bit of work to go to tidy this up, but
as it is now the vehicle modules certainly look neater
and have a lot less stub functions. The current approach
now lets arbitrary commands make it through the the
individual vehicle modules for action - which will
provide amazing opportunities for expansion, as well as
avoiding having stub functions in the Twizy module for
locking and unlocking the non-existent doors.
<br>
<br>
Feel free to have a look at the code, and let me know
what you think and if there is anything obviously wrong.
<br>
<br>
Regards, Mark.
<br>
<br>
On 13 Nov, 2012, at 11:37 PM, Mark Webb-Johnson
<a class="moz-txt-link-rfc2396E" href="mailto:mark@webb-johnson.net"><mark@webb-johnson.net></a> wrote:
<br>
<br>
<blockquote type="cite">I've got the framework for this
70% done. So far, it builds and looks good. Code size
for experimental v2 branch has gone from 50% of flash
to 55% - including all vehicle modules for tesla
roadster, twizy, volt/ampera, basic odbii and a null
vehicle stub. RAM has gone up about 30 bytes, but that
is part of the 30% not yet done.
<br>
<br>
I've merged in all Michael B's recent changes
(including stuff that may need to be looked at in
light of this re-work).
<br>
<br>
I'm going to do one more night on it, then commit what
I have to the v2 branch for others to look at.
<br>
<br>
Regards, Mark.
<br>
<br>
On 11 Nov, 2012, at 10:13 PM, Mark Webb-Johnson
<a class="moz-txt-link-rfc2396E" href="mailto:mark@webb-johnson.net"><mark@webb-johnson.net></a> wrote:
<br>
<br>
<blockquote type="cite">I think the general approach
here is correct.
<br>
<br>
It is a fine line between allowing the vehicle
modules to do more, and duplicating common
functionality in each module. But, your suggestion
to implement the core functions centrally, then
allow the vehicle modules to either override or
extend those core functions, is a good solution. It
can also be extended to SMS messages.
<br>
<br>
I'm not sure about using command/response ("C", "c")
to allow the Apps to query the module capabilities.
Those are quite expensive for the Apps to issue:
App->Server->Car->Server->App latency
can be 1, 2 or more seconds over GPRS - doing that
each time the App starts up is going to be
expensive. We can do this just as easily by a
published message type giving the capabilities of
the car - and that message could be issued just once
on module startup (with the application receiving a
copy each time it connected to the server).
<br>
<br>
This also fits in with my email a while ago about
restructuring to include a single firmware with
multiple vehicle modules switchable at runtime. I'm
very interested in getting a generic ODBII module
working as well (which could show speed, fuel tank
pressure, ODBII fault codes, etc).
<br>
<br>
We need to maintain the stability of the v1 system,
as we have so many users using it at the moment. So,
what I've just done is commit the last major change
to v1 code - I've update the protocol manual
formatting to make it clearer - and created two new
branches ("v1" and "v2). Let's work in the "v2"
branch to create a single unified firmware
supporting Roadster, Twizy, Volt and generic ODBII
on v2 hardware. For v1 hardware users (Roadster), we
can always back-port new features as necessary.
<br>
<br>
I can work on this now, so give me a few days to try
to build the framework for this re-structure.
<br>
<br>
Regards, Mark.
<br>
<br>
On 10 Nov, 2012, at 10:10 PM, Michael Balzer
<a class="moz-txt-link-rfc2396E" href="mailto:dexter@expeedo.de"><dexter@expeedo.de></a> wrote:
<br>
<br>
<blockquote type="cite">Am 04.11.2012 14:21, schrieb
Mark Webb-Johnson:
<br>
<blockquote type="cite">For major new feature
specific to a particular vehicle, I was hoping
we can handle those by the command protocol. We
could, for instance, route commands 100-200
directly through to the vehicle modules for
response. We could also add hooks for the
vehicle modules to directly transmit messages
out (the protocol itself is extensible and new
message types can be easily added).
<br>
</blockquote>
Mark, List,
<br>
<br>
for the Twizy, it's not so much about extending
but about reducing, as many current standard
commands do not make sense on the Twizy. Some
could also use slightly different implementations
(STAT SMS as seen).
<br>
<br>
I've thought about that last night and had fun
reading into the net code. Cool stuff. I stumbled
about a very simple way to not only enable routing
of special commands to the car, but to also enable
overloading of builtin commands. Seems you had
something like that already in mind when writing
that code :-)
<br>
<br>
So the system net modules could implement just the
common standard commands while the car modules
would dynamically extend those with just their
specific commands. Using a message passing scheme
to mimic an OO sub class approach, a car module
will be able to...
<br>
- either leave a command handling to the system
<br>
- or use and extend the system handling
<br>
- or completely implement a command itself,
possibly replacing a system handler.
<br>
<br>
Current car specific hook calls like
can_tx_setchargemode() can then be removed from
the common net framework.
<br>
<br>
To configure themselves accordingly, servers and
apps may want to know the type and version of the
car module, and a list of the commands supported
by the firmware. To enable this, I would introduce
two new msg commands:
<br>
<br>
- 6 = car module type + version
<br>
=> reply scheme: "MP-0
c6,0,<car_code>,<car_name>,<version_major>,<version_minor>,<version_patchlevel>"<br>
<br>
- 7 = list of commands supported
<br>
=> reply scheme: "MP-0
c7,0,<class:STD/CAR>,<cmdid1>,<cmdid2>,..."
<br>
More than one list of each class can be sent,
clients should collect and join all.
<br>
I think IDs are sufficient, otherwise the reply
scheme could be extended.
<br>
<br>
Maybe a third one will make sense for the...
<br>
<br>
- 8 = list of car data properties supported
<br>
=> reply scheme: "MP-0 c8,0,..." (todo? can
make life easier for the App)
<br>
<br>
Due to the structural beauty of the net code, this
extension should be quite easy to implement.
Please take a look at my implementation draft
below and give me some feedback. The SMS part
should be able to use the same approach.
<br>
<br>
AFAIS this extension would require no immediate
change to the existing server and apps, it just
offers an opportunity for the next releases.
<br>
<br>
Regards,
<br>
Michael
<br>
<br>
<br>
// ------------------- net_msg module
----------------------
<br>
<br>
// REPLACE:
<br>
void net_msg_cmd_do(void)
<br>
{
<br>
/****************************************************************
<br>
* MSG COMMAND DISPATCHER
<br>
* Called by: net_msg_cmd_in() &
net_state_ticker1()
<br>
*
<br>
* GLOBAL PARAMS:
<br>
* net_msg_cmd_code = int command id
<br>
* net_msg_cmd_msg = char * to first parameter
<br>
*/
<br>
<br>
delay100(2);
<br>
<br>
// commands 40-49 are special AT commands, thus,
disable net_msg here
<br>
if ((net_msg_cmd_code < 40) ||
(net_msg_cmd_code > 49))
<br>
net_msg_start();
<br>
<br>
// Execute cmd: ask car module to execute first:
<br>
if( !car_msg_cmd_exec() )
<br>
{
<br>
// Car module does not feel responsible, fall
back to standard:
<br>
if( !net_msg_cmd_exec() )
<br>
{
<br>
// No standard as well => return
"unimplemented"
<br>
sprintf(net_scratchpad, (rom far
char*)"MP-0 c%d,3",net_msg_cmd_code);
<br>
net_msg_encode_puts();
<br>
}
<br>
}
<br>
<br>
// terminate IPSEND by Ctrl-Z (should this be
disabled for commands 40-49 as well?)
<br>
net_msg_send();
<br>
<br>
// clear command
<br>
net_msg_cmd_code = 0;
<br>
net_msg_cmd_msg[0] = 0;
<br>
<br>
}
<br>
<br>
<br>
// ADD:
<br>
bool net_msg_cmd_exec(void)
<br>
{
<br>
/****************************************************************
<br>
* IMPLEMENTATION OF STANDARD MSG COMMANDS
<br>
* Called by: net_msg_cmd_do() & car specific
cmd handlers
<br>
*
<br>
* GLOBAL PARAMS:
<br>
* net_msg_cmd_code = int command id
<br>
* net_msg_cmd_msg = char * to first parameter
<br>
*
<br>
* RETURNS:
<br>
* true if cmd has been handled
<br>
*/
<br>
<br>
int k;
<br>
char *p;
<br>
<br>
switch (net_msg_cmd_code)
<br>
{
<br>
// ...std cmds 1-5 to be inserted here if
compiler does no jump table optimization...
<br>
<br>
case 7:
<br>
// List commands supported (for peer
configuration):
<br>
// standard commands:
<br>
sprintf( net_scratchpad, (rom far
char*)"MP-0 c7,0,STD,1,2,3,4,5,40,41,49" );
<br>
net_msg_encode_puts();
<br>
// (can be extended if clients need more
than the cmd ids)
<br>
return true;
<br>
<br>
// ...std cmds to be inserted here...
<br>
<br>
default:
<br>
// unhandled cmd_code:
<br>
return false;
<br>
}
<br>
}
<br>
<br>
<br>
// ------------------- can_<model> or maybe
separate car_<model> module
----------------------
<br>
<br>
// ADD:
<br>
bool car_msg_cmd_exec(void)
<br>
{
<br>
/****************************************************************
<br>
* HOOK to integrate CAR SPECIFIC MSG command
handlers
<br>
* May overlay and/or extend the standard command
set
<br>
* Called by: net_msg_cmd_do()
<br>
*
<br>
* GLOBAL PARAMS:
<br>
* net_msg_cmd_code = int command id
<br>
* net_msg_cmd_msg = char * to first parameter
<br>
*
<br>
* RETURNS:
<br>
* true : cmd has been handled completely
<br>
* false: fallback to net_msg_cmd_exec()
<br>
*
<br>
* OUTPUT SCHEME:
<br>
* sprintf(net_scratchpad, (rom far
char*)"MP-...");
<br>
* net_msg_encode_puts();
<br>
*
<br>
* CALL SPECIFIC STANDARD FUNCTION n: (rare case)
<br>
* [save net_msg_cmd_* if needed later on]
<br>
* net_msg_cmd_code = n;
<br>
* strcpy( net_msg_cmd_msg, "arg1,arg2,..." );
<br>
* if( net_msg_cmd_exec() ) {...success...}
<br>
*
<br>
*/
<br>
<br>
/* Command dispatcher: */
<br>
switch( net_msg_cmd_code )
<br>
{
<br>
case 6:
<br>
// Echo CAR TYPE + MODULE VERSION:
<br>
sprintf( net_scratchpad, (rom far
char*)"MP-0 c6,0,RT,Renault Twizy,1,2,0" );
<br>
net_msg_encode_puts();
<br>
return true;
<br>
<br>
case 7:
<br>
// List commands supported (for peer
configuration):
<br>
// a) standard commands:
<br>
net_msg_cmd_exec();
<br>
// b) car specific commands / overloads:
<br>
sprintf( net_scratchpad, (rom far
char*)"MP-0 c7,0,CAR,6,7,10" );
<br>
net_msg_encode_puts();
<br>
// (can be extended if clients need more
than the cmd ids)
<br>
return true;
<br>
<br>
<br>
/************************************************************
<br>
* CAR SPECIFIC COMMANDS
<br>
*/
<br>
<br>
case 10:
<br>
// EXAMPLE FROM TESLA MODULE: Set charge
mode (params: 0=standard,
1=storage,3=range,4=performance)
<br>
if (sys_features[FEATURE_CANWRITE]==0)
<br>
{
<br>
sprintf(net_scratchpad, (rom far
char*)NET_MSG_NOCANWRITE,net_msg_cmd_code);
<br>
}
<br>
else
<br>
{
<br>
can_tx_setchargemode(atoi(net_msg_cmd_msg));
<br>
sprintf(net_scratchpad, (rom far
char*)NET_MSG_OK,net_msg_cmd_code);
<br>
}
<br>
net_msg_encode_puts();
<br>
return true;
<br>
<br>
// ...more...
<br>
<br>
default:
<br>
// Not handled, fall back to standard:
<br>
return false;
<br>
}
<br>
<br>
}
<br>
<br>
<br>
<br>
-- <br>
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
<br>
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
<br>
<br>
<dexter.vcf>_______________________________________________
<br>
OvmsDev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
<br>
</blockquote>
</blockquote>
_______________________________________________
<br>
OvmsDev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
<br>
</blockquote>
</blockquote>
_______________________________________________
<br>
OvmsDev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
<br>
</blockquote>
-- <br>
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
<br>
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
<br>
<br>
<dexter.vcf>_______________________________________________
<br>
OvmsDev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
<br>
</blockquote>
</blockquote>
_______________________________________________
<br>
OvmsDev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
</div>
<span><dexter.vcf></span>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br></blockquote></div><br></div></body></html>