[Ovmsdev] Merging in Twizy and Volt/Ampera work
Mark Webb-Johnson
mark at webb-johnson.net
Sun Nov 18 16:49:28 HKT 2012
Michael,
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.
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.
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?
I also tested the new net_sms arrangement, found a few bugs, and fixed them. Code is on github now.
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.
Regards, Mark.
On 18 Nov, 2012, at 4:38 AM, Michael Balzer <dexter at expeedo.de> wrote:
> 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
> <dexter.vcf>_______________________________________________
> 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/20121118/7b00e498/attachment.htm>
More information about the OvmsDev
mailing list