[Ovmsdev] OvmsDev Digest, Vol 22, Issue 41

Ashwin Balan ashwin.balan at gmail.com
Fri Nov 22 16:05:08 HKT 2013 

Hi Mark,

The car has a OBD II port with the typical CAN protocols accessible over the OBD II.  I have a CAN-USB adapter on order but I am currently utilizing the OBDLINK MX bluetooth scan tool to get some base level readings.  I had a chance to connect this same OBD reader to a Volt and the readings are very similar.  I will get you a list of PIDs in the morning.  I am new to this list type of arrangement (was once on a list when I owned a HP 200lx in the Mid-90s) I hope I am not cluttering up your list with newbie questions/comments.  Thanks for any help you can assist with.  Will get you that information ASAP.  I am really excited about this prospect, I think the OVMS will really help the owners of (currently) orphaned cars like the Karma. 

Ashwin 
On Nov 21, 2013, at 8:00 PM, ovmsdev-request at lists.teslaclub.hk wrote:

> Send OvmsDev mailing list submissions to
> 	ovmsdev at lists.teslaclub.hk
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> or, via email, send a message with subject or body 'help' to
> 	ovmsdev-request at lists.teslaclub.hk
> 
> You can reach the person managing the list at
> 	ovmsdev-owner at lists.teslaclub.hk
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OvmsDev digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Fisker Karma OVMS Support (Mark Webb-Johnson)
>   2. Tom and My updates (Mark Webb-Johnson)
>   3. CTP SMS Command (Tom Saxton)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 21 Nov 2013 15:23:46 +0800
> From: Mark Webb-Johnson <mark at webb-johnson.net>
> Subject: Re: [Ovmsdev] Fisker Karma OVMS Support
> To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
> Message-ID: <934AA03E-2CBA-4D01-BE7E-66241756CAC6 at webb-johnson.net>
> Content-Type: text/plain; charset=windows-1252
> 
> Ashwin,
> 
> I'm happy to support development of support for any and all cars. But, we really need a developer with frequent and good access to the car, to be able to do this.
> 
> It would be good to first confirm feasibility. Do you know what sort of CAN bus connector the car has? Presumably OBD-II? Then, using a CAN-USB adaptor (or OBD-II adaptor in monitor-all mode), try to get a trace of what is happening on the bus (while car is idle, while car is driving, while car is charging, would be good). If the car works on a request-response arrangement, what are the PIDs you are getting a response on?
> 
> Regards, Mark.
> 
> On 21 Nov, 2013, at 2:32 am, Ashwin Balan <ashwin.balan at gmail.com> wrote:
> 
>> Hi all,
>> 
>> Has anyone done any OVMS development work for the Karma?  The CAN system is setup very similarly (from what I can tell)  to that of a Volt (about 49 PID?s can be read from my generic scan tool and I have a small list of PID definitions.  This would be a huge benefit to Karma owners as the Command Center in the car is not every useful and if a OVMS is setup in conjunction with a tablet Fisker owners may have a much better UI to interact with the car.  Anyway I will help in anyway possible.  Thanks A
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 21 Nov 2013 21:40:24 +0800
> From: Mark Webb-Johnson <mark at webb-johnson.net>
> Subject: [Ovmsdev] Tom and My updates
> To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
> Message-ID: <FD9DABCA-6073-4694-9E67-FFD89EF8B137 at webb-johnson.net>
> Content-Type: text/plain; charset="windows-1252"
> 
> 
> Quite a few updates have just been pushed, and may have broken things, but so far seem ok to me.
> 
> Tom?s changes are:
> 
> add params to vehicle_minutestocharge
> add #define for charge voltage assumed by ACC
> add CTP SMS command
> add timestamp to STAT SMS command
> generalize timestring_to_mins
> TR: CTP uses CAC100 for better resolution
> TR: move MinutesToChargeCAC code into vehicle_teslaroadster_minutestocharge
> TR: separate taper profiles for each charge mode
> 
> My changes are:
> 
> Add new polling framework to vehicle.{h,c}
> Use new polling framework to implement vehicle_obdII
> Extend polling framework for extended (mode 0x22) pid requests
> Extend polling framework for Nissan Leaf style multi-frame requests
> Change crypt_md5 to try to reduce ram usage (particular initialised ram)
> 
> I?ve also extended CAN-RE-TOOL to build a simulation framework, to help test the above and to act as a framework for future work.
> 
> I haven?t changed the VoltAmpera to use the new framework yet.
> 
> Now, the framework is stable, I can finalise the Nissan leaf polling code.
> 
> Regards, Mark.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20131121/0439c669/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 3
> Date: Thu, 21 Nov 2013 08:47:06 -0800
> From: Tom Saxton <tom at idleloop.com>
> Subject: [Ovmsdev] CTP SMS Command
> To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
> Message-ID: <CEB3741C.3A3D1%tom at idleloop.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> The new CTP command gives users full access to the charge time predictor.
> Currently only the Roadster has the necessary charge time predictor code,
> but the CTP command is general so it will work for other vehicles that add
> the required algorithm.
> 
> There are a few ways to call it:
> 
> - If the car is charging, just send CTP to get the current estimate
> (1-minute resolution) and the charge target.
> - If the car isn't charging, you have to tell is the power level to use,
> either in watts or volts and amps, e.g. "CTP 9600W" or "CTP 240V 40A".
> - You can also specify the charge mode (S, R, P), start, stop and CAC
> values. For example, "CTP 9600w 100s 150e 152c 25d" says "use 152 as the CAC
> value, then calculate the time needed to go from 100 ideal miles to 150
> ideal miles charging at 9.6 kW in a 25C environment." You can also specify
> the end percent target as: "CTP 9600w 90%".
> 
> For example, send:
> 
> CTP R 240v 40a 100s 152c 25d
> 
> receive:
> 
> 100 to 232 ideal miles
> 4:53
> 
> Which means charging in Range mode from 100 ideal miles to full (calculated
> to be 232 ideal miles for a Roadster with a CAC of 152 Ah) at 240V/40A is
> estimated to take 4 hours and 53 minutes.
> 
> Many factors can influence the actual charge time, so don't expect
> to-the-minute accuracy, more like plus or minus the larger of 30 minutes and
> 10%.
> 
> Next up is teaching it to convert to and from km.
> 
> I'm interested in implementing the Leaf charge time predictor once we start
> getting some Leaf charge data. I'm also happy to help with other vehicles.
> 
>   Tom
> 
> From:  Mark Webb-Johnson <mark at webb-johnson.net>
> Reply-To:  OVMS Developers <ovmsdev at lists.teslaclub.hk>
> Date:  Thursday, November 21, 2013 at 5:40 AM
> To:  OVMS Developers <ovmsdev at lists.teslaclub.hk>
> Subject:  [Ovmsdev] Tom and My updates
> 
> 
> Quite a few updates have just been pushed, and may have broken things, but
> so far seem ok to me.
> 
> Tom?s changes are:
> 
> * add params to vehicle_minutestocharge
> * add #define for charge voltage assumed by ACC
> * add CTP SMS command
> * add timestamp to STAT SMS command
> * generalize timestring_to_mins
> * TR: CTP uses CAC100 for better resolution
> * TR: move MinutesToChargeCAC code into
> vehicle_teslaroadster_minutestocharge
> * TR: separate taper profiles for each charge mode
> 
> My changes are:
> 
> * Add new polling framework to vehicle.{h,c}
> * Use new polling framework to implement vehicle_obdII
> * Extend polling framework for extended (mode 0x22) pid requests
> * Extend polling framework for Nissan Leaf style multi-frame requests
> * Change crypt_md5 to try to reduce ram usage (particular initialised ram)
> 
> I?ve also extended CAN-RE-TOOL to build a simulation framework, to help test
> the above and to act as a framework for future work.
> 
> I haven?t changed the VoltAmpera to use the new framework yet.
> 
> Now, the framework is stable, I can finalise the Nissan leaf polling code.
> 
> Regards, Mark.
> _______________________________________________ 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.teslaclub.hk/pipermail/ovmsdev/attachments/20131121/58f93bcd/attachment-0001.html>
> 
> ------------------------------
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> 
> End of OvmsDev Digest, Vol 22, Issue 41
> ***************************************

More information about the OvmsDev mailing list