[Ovmsdev] Merging in Twizy and Volt/Ampera work
Michael Balzer
dexter at expeedo.de
Sun Nov 18 04:38:00 HKT 2012
Mark,
I ported my STAT changes to the new framework and tried to prepare it
for my first specific commands as well:
https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/7b050c4dd92045d62bce3315122ac496c5d305c6
Haven't tested yet, but the vehicle / framework distinction becomes very
clean now I think.
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.
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 (?)
Regards,
Michael
Am 17.11.2012 19:20, schrieb Michael Balzer:
> Mark,
>
> man, you're fast! :-)
>
> ...ok, that looks good for extending and replacing existing SMS commands.
>
> 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.
>
> 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()?
>
> 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?
>
> Regards,
> Michael
>
>
> Am 17.11.2012 16:03, schrieb Mark Webb-Johnson:
>>>> I'll also port my specific STAT? version to the new framework ASAP.
>>> 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.
>> I've done the structural work for this, and committed to github.
>>
>> 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).
>>
>> I haven't re-worked Michael's Twizy STAT extensions, yet, but the
>> hooks are now there.
>>
>> 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.
>>
>> I'll test it tomorrow, and fix as necessary.
>>
>> Regards, Mark.
>>
>> On 17 Nov, 2012, at 9:24 PM, Mark Webb-Johnson
>> <mark at webb-johnson.net> wrote:
>>
>>>> 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?
>>> 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.
>>>
>>>> I'll also port my specific STAT? version to the new framework ASAP.
>>> 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.
>>>
>>>> I have one concern for the overlaying of the vehicle RAM sections:
>>> 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.
>>>
>>> Regards, Mark.
>>>
>>> On 17 Nov, 2012, at 3:52 AM, Michael Balzer <dexter at expeedo.de> wrote:
>>>
>>>> Mark,
>>>>
>>>> I followed your branch naming, "v2" on my repository adds my latest
>>>> Twizy changes to the new framework.
>>>>
>>>> Stunningly, V2 worked out of the box :-) Great job!
>>>>
>>>> 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?
>>>>
>>>> I'll also port my specific STAT? version to the new framework ASAP.
>>>>
>>>> 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...
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> Am 15.11.2012 14:52, schrieb Mark Webb-Johnson:
>>>>> I've just committed another night's work on this. Looks good and
>>>>> now runs on actual hardware.
>>>>>
>>>>> 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.
>>>>>
>>>>> I've ported the SMS commands over to the new vehicle module
>>>>> framework, and they look good.
>>>>>
>>>>> I've bumped the version to 2.1.1, to reflect the major
>>>>> restructuring that this is.
>>>>>
>>>>> 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.
>>>>>
>>>>> Regards, Mark.
>>>>>
>>>>> On 14 Nov, 2012, at 10:57 PM, Mark Webb-Johnson
>>>>> <mark at webb-johnson.net> wrote:
>>>>>
>>>>>> I've just committed my work-in-progress for this to the github v2
>>>>>> branch.
>>>>>>
>>>>>> Best I can say about it is that it compiles and links without error.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Feel free to have a look at the code, and let me know what you
>>>>>> think and if there is anything obviously wrong.
>>>>>>
>>>>>> Regards, Mark.
>>>>>>
>>>>>> On 13 Nov, 2012, at 11:37 PM, Mark Webb-Johnson
>>>>>> <mark at webb-johnson.net> wrote:
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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).
>>>>>>>
>>>>>>> I'm going to do one more night on it, then commit what I have to
>>>>>>> the v2 branch for others to look at.
>>>>>>>
>>>>>>> Regards, Mark.
>>>>>>>
>>>>>>> On 11 Nov, 2012, at 10:13 PM, Mark Webb-Johnson
>>>>>>> <mark at webb-johnson.net> wrote:
>>>>>>>
>>>>>>>> I think the general approach here is correct.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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).
>>>>>>>>
>>>>>>>> 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).
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> I can work on this now, so give me a few days to try to build
>>>>>>>> the framework for this re-structure.
>>>>>>>>
>>>>>>>> Regards, Mark.
>>>>>>>>
>>>>>>>> On 10 Nov, 2012, at 10:10 PM, Michael Balzer
>>>>>>>> <dexter at expeedo.de> wrote:
>>>>>>>>
>>>>>>>>> Am 04.11.2012 14:21, schrieb Mark Webb-Johnson:
>>>>>>>>>> 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).
>>>>>>>>> Mark, List,
>>>>>>>>>
>>>>>>>>> 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).
>>>>>>>>>
>>>>>>>>> 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 :-)
>>>>>>>>>
>>>>>>>>> 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...
>>>>>>>>> - either leave a command handling to the system
>>>>>>>>> - or use and extend the system handling
>>>>>>>>> - or completely implement a command itself, possibly replacing
>>>>>>>>> a system handler.
>>>>>>>>>
>>>>>>>>> Current car specific hook calls like can_tx_setchargemode()
>>>>>>>>> can then be removed from the common net framework.
>>>>>>>>>
>>>>>>>>> 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:
>>>>>>>>>
>>>>>>>>> - 6 = car module type + version
>>>>>>>>> => reply scheme: "MP-0
>>>>>>>>> c6,0,<car_code>,<car_name>,<version_major>,<version_minor>,<version_patchlevel>"
>>>>>>>>>
>>>>>>>>> - 7 = list of commands supported
>>>>>>>>> => reply scheme: "MP-0
>>>>>>>>> c7,0,<class:STD/CAR>,<cmdid1>,<cmdid2>,..."
>>>>>>>>> More than one list of each class can be sent, clients should
>>>>>>>>> collect and join all.
>>>>>>>>> I think IDs are sufficient, otherwise the reply scheme could
>>>>>>>>> be extended.
>>>>>>>>>
>>>>>>>>> Maybe a third one will make sense for the...
>>>>>>>>>
>>>>>>>>> - 8 = list of car data properties supported
>>>>>>>>> => reply scheme: "MP-0 c8,0,..." (todo? can make life easier
>>>>>>>>> for the App)
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> AFAIS this extension would require no immediate change to the
>>>>>>>>> existing server and apps, it just offers an opportunity for
>>>>>>>>> the next releases.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Michael
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> // ------------------- net_msg module ----------------------
>>>>>>>>>
>>>>>>>>> // REPLACE:
>>>>>>>>> void net_msg_cmd_do(void)
>>>>>>>>> {
>>>>>>>>> /****************************************************************
>>>>>>>>> * MSG COMMAND DISPATCHER
>>>>>>>>> * Called by: net_msg_cmd_in() & net_state_ticker1()
>>>>>>>>> *
>>>>>>>>> * GLOBAL PARAMS:
>>>>>>>>> * net_msg_cmd_code = int command id
>>>>>>>>> * net_msg_cmd_msg = char * to first parameter
>>>>>>>>> */
>>>>>>>>>
>>>>>>>>> delay100(2);
>>>>>>>>>
>>>>>>>>> // commands 40-49 are special AT commands, thus, disable
>>>>>>>>> net_msg here
>>>>>>>>> if ((net_msg_cmd_code < 40) || (net_msg_cmd_code > 49))
>>>>>>>>> net_msg_start();
>>>>>>>>>
>>>>>>>>> // Execute cmd: ask car module to execute first:
>>>>>>>>> if( !car_msg_cmd_exec() )
>>>>>>>>> {
>>>>>>>>> // Car module does not feel responsible, fall back to
>>>>>>>>> standard:
>>>>>>>>> if( !net_msg_cmd_exec() )
>>>>>>>>> {
>>>>>>>>> // No standard as well => return "unimplemented"
>>>>>>>>> sprintf(net_scratchpad, (rom far char*)"MP-0
>>>>>>>>> c%d,3",net_msg_cmd_code);
>>>>>>>>> net_msg_encode_puts();
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> // terminate IPSEND by Ctrl-Z (should this be disabled for
>>>>>>>>> commands 40-49 as well?)
>>>>>>>>> net_msg_send();
>>>>>>>>>
>>>>>>>>> // clear command
>>>>>>>>> net_msg_cmd_code = 0;
>>>>>>>>> net_msg_cmd_msg[0] = 0;
>>>>>>>>>
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> // ADD:
>>>>>>>>> bool net_msg_cmd_exec(void)
>>>>>>>>> {
>>>>>>>>> /****************************************************************
>>>>>>>>> * IMPLEMENTATION OF STANDARD MSG COMMANDS
>>>>>>>>> * Called by: net_msg_cmd_do() & car specific cmd handlers
>>>>>>>>> *
>>>>>>>>> * GLOBAL PARAMS:
>>>>>>>>> * net_msg_cmd_code = int command id
>>>>>>>>> * net_msg_cmd_msg = char * to first parameter
>>>>>>>>> *
>>>>>>>>> * RETURNS:
>>>>>>>>> * true if cmd has been handled
>>>>>>>>> */
>>>>>>>>>
>>>>>>>>> int k;
>>>>>>>>> char *p;
>>>>>>>>>
>>>>>>>>> switch (net_msg_cmd_code)
>>>>>>>>> {
>>>>>>>>> // ...std cmds 1-5 to be inserted here if compiler does no
>>>>>>>>> jump table optimization...
>>>>>>>>>
>>>>>>>>> case 7:
>>>>>>>>> // List commands supported (for peer configuration):
>>>>>>>>> // standard commands:
>>>>>>>>> sprintf( net_scratchpad, (rom far char*)"MP-0
>>>>>>>>> c7,0,STD,1,2,3,4,5,40,41,49" );
>>>>>>>>> net_msg_encode_puts();
>>>>>>>>> // (can be extended if clients need more than the cmd
>>>>>>>>> ids)
>>>>>>>>> return true;
>>>>>>>>>
>>>>>>>>> // ...std cmds to be inserted here...
>>>>>>>>>
>>>>>>>>> default:
>>>>>>>>> // unhandled cmd_code:
>>>>>>>>> return false;
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> // ------------------- can_<model> or maybe separate
>>>>>>>>> car_<model> module ----------------------
>>>>>>>>>
>>>>>>>>> // ADD:
>>>>>>>>> bool car_msg_cmd_exec(void)
>>>>>>>>> {
>>>>>>>>> /****************************************************************
>>>>>>>>> * HOOK to integrate CAR SPECIFIC MSG command handlers
>>>>>>>>> * May overlay and/or extend the standard command set
>>>>>>>>> * Called by: net_msg_cmd_do()
>>>>>>>>> *
>>>>>>>>> * GLOBAL PARAMS:
>>>>>>>>> * net_msg_cmd_code = int command id
>>>>>>>>> * net_msg_cmd_msg = char * to first parameter
>>>>>>>>> *
>>>>>>>>> * RETURNS:
>>>>>>>>> * true : cmd has been handled completely
>>>>>>>>> * false: fallback to net_msg_cmd_exec()
>>>>>>>>> *
>>>>>>>>> * OUTPUT SCHEME:
>>>>>>>>> * sprintf(net_scratchpad, (rom far char*)"MP-...");
>>>>>>>>> * net_msg_encode_puts();
>>>>>>>>> *
>>>>>>>>> * CALL SPECIFIC STANDARD FUNCTION n: (rare case)
>>>>>>>>> * [save net_msg_cmd_* if needed later on]
>>>>>>>>> * net_msg_cmd_code = n;
>>>>>>>>> * strcpy( net_msg_cmd_msg, "arg1,arg2,..." );
>>>>>>>>> * if( net_msg_cmd_exec() ) {...success...}
>>>>>>>>> *
>>>>>>>>> */
>>>>>>>>>
>>>>>>>>> /* Command dispatcher: */
>>>>>>>>> switch( net_msg_cmd_code )
>>>>>>>>> {
>>>>>>>>> case 6:
>>>>>>>>> // Echo CAR TYPE + MODULE VERSION:
>>>>>>>>> sprintf( net_scratchpad, (rom far char*)"MP-0
>>>>>>>>> c6,0,RT,Renault Twizy,1,2,0" );
>>>>>>>>> net_msg_encode_puts();
>>>>>>>>> return true;
>>>>>>>>>
>>>>>>>>> case 7:
>>>>>>>>> // List commands supported (for peer configuration):
>>>>>>>>> // a) standard commands:
>>>>>>>>> net_msg_cmd_exec();
>>>>>>>>> // b) car specific commands / overloads:
>>>>>>>>> sprintf( net_scratchpad, (rom far char*)"MP-0
>>>>>>>>> c7,0,CAR,6,7,10" );
>>>>>>>>> net_msg_encode_puts();
>>>>>>>>> // (can be extended if clients need more than the cmd
>>>>>>>>> ids)
>>>>>>>>> return true;
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /************************************************************
>>>>>>>>> * CAR SPECIFIC COMMANDS
>>>>>>>>> */
>>>>>>>>>
>>>>>>>>> case 10:
>>>>>>>>> // EXAMPLE FROM TESLA MODULE: Set charge mode (params:
>>>>>>>>> 0=standard, 1=storage,3=range,4=performance)
>>>>>>>>> if (sys_features[FEATURE_CANWRITE]==0)
>>>>>>>>> {
>>>>>>>>> sprintf(net_scratchpad, (rom far
>>>>>>>>> char*)NET_MSG_NOCANWRITE,net_msg_cmd_code);
>>>>>>>>> }
>>>>>>>>> else
>>>>>>>>> {
>>>>>>>>> can_tx_setchargemode(atoi(net_msg_cmd_msg));
>>>>>>>>> sprintf(net_scratchpad, (rom far
>>>>>>>>> char*)NET_MSG_OK,net_msg_cmd_code);
>>>>>>>>> }
>>>>>>>>> net_msg_encode_puts();
>>>>>>>>> return true;
>>>>>>>>>
>>>>>>>>> // ...more...
>>>>>>>>>
>>>>>>>>> default:
>>>>>>>>> // Not handled, fall back to standard:
>>>>>>>>> return false;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>>>>>>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>>>>>>>>
>>>>>>>>> <dexter.vcf>_______________________________________________
>>>>>>>>> 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
>>>> --
>>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>>>
>>>> <dexter.vcf>_______________________________________________
>>>> 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
--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20121117/b1e6642b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20121117/b1e6642b/attachment-0002.vcf>
More information about the OvmsDev
mailing list