April 2013 - OvmsDev - Open Vehicles

More sophisticated hardware
by Mark Webb-Johnson 27 Apr '13

27 Apr '13

Long post - apologies... I'm not suggesting changing the current hardware offering, but coming up with something more powerful to offer along side it. Requirements listed include: WIFI Bluetooth Display Full OBD-II More CAN buses 3G SD-Card for data logging capability We've been talking about this for a while, and have tried various approaches. It comes down to a choice between: Low power embedded PIC style High power Linux arm style My personal preference is for low-power - especially given the 12V issues we've seen. A couple of things have come together over the past few months, and there are some interesting opportunities: I've been looking at the PIC32MX795 microcontroller. 128KB of RAM, 512KB flash. 6 async ports. 2 CAN buses. etc. Using controller-based touch-screen LCDs is hellishly expensive. But, Microchip have a neat solution. Using an off-chip memory buffer (or on chip ram for lower resolutions) and DMA transfers, a 4.3" LCD WQVGA resolution display (with touchscreen) can be interfaced for a fraction of the cost of a controller-based display, using just 5% to 10% of the CPU. 3G is possible - just need to work out the required frequencies to see if we need (a) the tri-band version, or (b) two different dual-band versions. Full OBD-II is relatively easy - standard outputs interfaces via async serial ELM327 style (using the newer STN1110). Single-wire CAN is also possible. The PIC32s have USB on-board (for serial, or firmware upload). SD-Card is relatively easy (libraries are available, and plenty of I/O PINs for the I2C controller). Bluetooth modules are easy (async serial interface). Wifi is possible (for wifi client based setups as an alternative to 3G - hotspot is trickier). The design I've been looking at includes: A 4.3" multi-touch 400x240 resolution LCD display. A primary PIC32MX795 cpu for 2xCAN ports, 1xOBD-II main control tasks (always on). A secondary PIC32MX795 cpu with LCC setup to drive the LCD display and touchpad - this is just for UI. SD-Card Wifi Bluetooth 3G+GPS We could use the 2xCAN ports on the second (display) CPU as well, if we needed them - although the basic setup above already has 3 CAN ports (2 direct and 1 via OBD-II). The primary controller has power control and can power down the other parts of the system (particularly power hungry systems like display) when the car is off. It seems to me that the more advanced portion of our user base wants to do some sophisticated stuff, and there is a very large community of users out there using things like the DashDAQ for real-time logging and display of vehicle metrics. The DashDAQ costs US$549 (plus extras), and doesn't have wifi, bluetooth, 3G - it only works on OBD-II and is 'closed' (although you can do some screen design in it). Feature-wise, I'm looking at something like the DashDAQ. The ability to make screens with real-time metrics, as well as an in-car display. Couple that with logging capability for both low-level CAN/OBD-II traffic and high-level gps-based plots. Wifi-connectivity to home wifis for garages with no 3G coverage, and bluetooth for cell-phone connectivity. Plus, all the existing OVMS features. I'm guessing that the hardware to do all of the above would be about double what we have now (so around US$200). The biggest cost items are the 4.3" display and 3G module. CPUs are cheap (about US$10 each). There are quite a large number of ancillary components (especially for OBD-II), but it should fit in an enclosure behind a 4.3" display. Other than bread-boarding some mock-ups, to see if this is feasible, I haven't done any extensive work on the above. What do people think? Is this something people would want? A way to grow the community? Or, is there a better way of doing it? Regards, Mark.

5 15

Fwd: Parrot (@Parrot) is now following you on Twitter!
by Mark Webb-Johnson 27 Apr '13

27 Apr '13

Lol :-) Begin forwarded message: > Subject: Parrot (@Parrot) is now following you on Twitter! > To: Open Vehicles > > > Open Vehicles, > You have a new follower on Twitter. > > > > Parrot > @Parrot > Parrot on twitter. Bluetooth hands free Asteroid. Wireless speakers. Parrot Zik. Parrot Flower Power. Quadrocopter @ardrone @Parrot_US@ardronejapan > Paris, France · http://www.parrot.com > Following: 2251 · Followers: 5492 >

2 2

Progress with the Renault Twizy's remote start/stop.
by Nikki Gordon-Bloomfield 22 Apr '13

22 Apr '13

Hey everyone, So today I finally ventured underneath and inside the Twizy with a view to find out a little more about the Twizy charging setup. The first thing was to find out more about the charger and the type of equipment we are dealing with. First off, I removed the mat and the floor from inside the Twizy, giving me some easy view of what the inside of the Twizy looked like. Then I got the Twizy up on ramps and removed the front belly panel, which I presume is Aluminium. (Or Aluminum? ;) ) The latter comes off really easy: you just need an M14 and M10 wrench. With the bottom panel off, I could more easily see the Charger and DC/DC converter, which is actually the same unit. With some googling, it turns out that the model is based on an ELIPS 2000W charger by IES Synergy. Sadly, despite an hour of looking online, I can't find ANY manuals, schematics, or anything else to identify exactly what is what with regards to pinout. But I have identified: DC 12V out Mains In Comms port (presumably CAN bus, but I can't be sure) Temperature monitor/Battery pack monitoring cable. DC 60V out. The fact that the charger appears to have comms makes me think that perhaps there is some luck for sniffing on the CAN bus for charger information. I don't have a logger, so perhaps someone with logging could log the Twizy while charging to see if there are any info on the can bus? The mains input is also interesting: I can clearly see where the mains lead comes in from the front of the Twizy, as well as where the earth splits to chassis and the mains live and neutral passes through an APEX 280 connector on its way to the charger. If we can't figure out the comms for the charger, this seems like a logical place to connect a short loop to a double-pole NC relay. This would certainly give us the ability to control power on and off, but it would also (I think) remove the "don't power on while plugged in" safety in the Twizy. Technically then, if we used this setup and energised the NC relay to stop charging, you could then get IN the Twizy, power it up and try to drive off with it still plugged into the mains. NOT good! But there's also a mystery cable coming out of the mains input which isn't any of the three usual cables. It's smaller, and may be some form of sensor placed at the car-end of the cable (I don't think the mains cable is anything other than standard 3-core so can't travel the length of the mains cable) Any suggestions gratefully received. I think I can come up with some charger relay hardware, but It's going to be a little long-winded. Photos, for the curious, are here: http://www.flickr.com/photos/aminorjourney/8667778563/in/set-72157633073576… Nikki. P.S. Got a cron job running last night so that my Twizy OVMS logs are automatically pulled down daily and put on my Raspberry pi. ;)

2 6

RT_PWR logs.
by Nikki Gordon-Bloomfield 22 Apr '13

22 Apr '13

Guys, Has the Twizy firmware removed RT_PWR_BattPack and RT_PWR_BattCell? Just noticed that since upgrading it, these two records aren't appearing on the OVMS server when I run ./cmd.pl 31 ? Do I need a Twizy-specific firmware now? Nikki.

2 1

CTP: Charge Time Predictor or Chocolate Tea Pot?
by Mark Webb-Johnson 19 Apr '13

19 Apr '13

Tom's CTP algorithm is in my Tesla Roadster, and I've just started the first charge with it: 2013-04-17 06:59:39.975150 -0400 info main: #71 C EV915 rx msg S 79,K,3,0,prepare,standard,246,222,56,0,100,0,7,13,0,0,0,-1,156.78,-1 2013-04-17 07:04:32.207360 -0400 info main: #71 C EV915 rx msg S 79,K,220,0,charging,standard,246,222,56,0,100,0,5,1,0,0,0,-1,156.78,-1 2013-04-17 07:04:32.208899 -0400 info main: #71 C EV915 rx msg S 79,K,220,0,charging,standard,248,224,56,0,100,0,5,1,0,0,0,-1,156.78,-1 2013-04-17 07:09:10.003015 -0400 info main: #71 C EV915 rx msg S 82,K,218,56,charging,standard,258,232,56,9,100,2,5,1,0,0,0,-1,156.78,38 2013-04-17 07:19:08.396430 -0400 info main: #71 C EV915 rx msg S 86,K,218,56,charging,standard,269,243,56,19,100,4,5,1,0,0,0,-1,156.78,27 Prediction is the last column: 38 minutes given 56 amps @ 220 volts, 24 - 27 celcius ambient, with about 80km (50 miles) to put into the pack. Exciting times ahead, with alternative charge control mechanisms. Regards, Mark.

2 3

FW: Release Firmware
by Kevin Sharpe ZCW 17 Apr '13

17 Apr '13

Email sent again without the car photo (which exceeded the 1Mbyte file attachment limit)… From: Kevin Sharpe <kevin.sharpe(a)zerocarbonworld.org<mailto:kevin.sharpe@zerocarbonworld.org>> Date: Sunday, 14 April 2013 18:28 To: OVMS Developers <ovmsdev(a)lists.teslaclub.hk<mailto:ovmsdev@lists.teslaclub.hk>> Subject: Re: [Ovmsdev] Release Firmware Just to add a little more to Nikki's report… I've seen some odd behaviour with SOC… if you see the attached photo's you'll see STAT report SOC as 46% and then 50% even though the commands were sent within a minute of one another (approximately). You'll also see the app and car displayed 52% and 92m at the same time. I also note that the ODO reports 0.0 mil and I see no CAC in response to a STAT command. Is this expected behaviour with this firmware? Firmware version reported in the app is 2.3.1/TR/V2 All the best, [http://www.zerocarbonworld.org/images/logo.png] Kevin Sharpe | Founder & Patron Tel: +44 122 566 7544 ext: 800 | Skype: zerocarbonworld kevin.sharpe(a)zerocarbonworld.org <mailto:kevin.sharpe@zerocarbonworld.org> | www.zerocarbonworld.org<http://www.zerocarbonworld.org/> | twitter.com/zerocarbonworld<http://twitter.com/ZCWcharlie> [http://www.zerocarbonworld.org/images/email-signatures_06.png] Zero Carbon World is a UK Registered Charity #1141347 From: Nikki Gordon-Bloomfield <nikki(a)littlecollie.com<mailto:nikki@littlecollie.com>> Reply-To: OVMS Developers <ovmsdev(a)lists.teslaclub.hk<mailto:ovmsdev@lists.teslaclub.hk>> Date: Sunday, 14 April 2013 17:24 To: OVMS Developers <ovmsdev(a)lists.teslaclub.hk<mailto:ovmsdev@lists.teslaclub.hk>> Subject: Re: [Ovmsdev] Release Firmware Just a head up: I flashed my Twizy firmware and it immediately started working. I flashed Kevin's firmware on his Roadster, and it took about 10 minutes to start working. Not sure why -- but thought you'd all appreciate the report. :) I've got a 35 mile round-trip tonight to Bath, and about 120 miles of work-related travel this week in the Twizy, so plenty of time to test it! Nikki Gordon-Bloomfield http://about.me/aminorjourney/bio email: nikki(a)littleCollie.com<mailto:nikki@littleCollie.com> tel: +44 7901 553308 On 14 Apr 2013, at 17:04, Michael Balzer <dexter(a)expeedo.de<mailto:dexter@expeedo.de>> wrote: I've had GPS streaming enabled during the last days, and neither GPS nor GSM connectivity are good at the moment. May be related, as streaming means more data communication. But still that should not lead to RAM corruption. Am 14.04.2013 17:54, schrieb Michael Balzer: Mark, I've got the last but one version in my car, just lacking the new VEHICLE commands. I've got two open issues, the minor one being to raise the 12V auto acquisition time even more, as the faults have become better but it's not yet perfect. I'm trying 20 TAD now, as we don't need to be fast on that A/D conversion. But a major issue might have turned up: I've just had the second RAM corruption within three days. Effect: MP-0 c32,0,106,119,*-OVM-DebugCrash,2013-04-14 14:06:40,0,2.2.7/RT2.6.4/V2,0,0000,20 MP-0 c32,0,107,119,*-OVM-DebugCrash,2013-04-14 14:25:13,0,2.2.7/RT2.6.4/V2,80,0020,61 As there is no checkpoint 61, this means at least the debug variables have been overwritten, was the same with the first occurence (but other values). As the module behaves weird afterwards I suppose more variables have been corrupted. I've looked through the last changes several times, I'm pretty sure none could have introduced this kind of bug... if I'm the only one experiencing this, maybe I've got some hardware issue as well? I'll continue checking the source for possible buffer overruns... Regards, Michael Am 14.04.2013 16:29, schrieb Mark Webb-Johnson: I've just built from latest sources, v2.3.1. This is a release candidate, and I have 24 hours to test before i need to send it to China. It is in my car now, and seems ok. I'll do more testing tomorrow. I'd be grateful if others could grab it and put it in their cars to ensure there are no major problems. Regards, Mark. On 13 Apr, 2013, at 10:04 PM, Mark Webb-Johnson <mark(a)webb-johnson.net<mailto:mark@webb-johnson.net>> wrote: All seems ok. I've committed and pushed my changes (just the stp_ltf_h() function, and change to report cac as 999.99 to server). I've just flashed and it will go in my car tomorrow. Regards, Mark On 13 Apr, 2013, at 2:51 AM, Michael Balzer <dexter(a)expeedo.de<mailto:dexter@expeedo.de>> wrote: Mark, I just checked in my latest changes. In net.c I added the pending send check also to the new net_notify_errorcode send, I think that should be correct, but please have a look. I saw the new stp_f() function, but I don't understand it's purpose yet. What's the difference to my stp_l2f() function? Btw: l2f = "long to float" -- I think "_f" should be reserved for an stp call with a real float type parameter, if we once really need one. Regards, Michael Am 12.04.2013 20:16, schrieb Michael Balzer: Nikki, yes, see attachment. I could not make out any possible source of that strange error I had yesterday (completely garbled data). I made a clean build with a freshly started MPLAB and got no errors up to now. May have been something completely different, not related to my last changes. Regards, Michael Am 12.04.2013 17:01, schrieb Nikki Gordon-Bloomfield: Michael, Any new firmware for me to test this weekend? Nikki. On 11 Apr 2013, at 18:33, Michael Balzer <dexter(a)expeedo.de<mailto:dexter@expeedo.de>> wrote: I think I was a bit too fast on this, Nikki, don't use that version, it seems to have some new bug causing frequent crashes... :-( Regards, Michael Am 11.04.2013 19:22, schrieb Michael Balzer: Mark, Nikki, I'm currently trying to fix a last bug with the power statistics (the distance counter still went wrong), and I'm trying to get the 12V A/D conversion to work without these strange "peaks" by raising the automatic acquisition time. I will finish testing this ASAP or tell you in time before sunday. Nikki, I attached the latest version in case you'd like to test as well. Regards, Michael Am 11.04.2013 16:41, schrieb Mark Webb-Johnson: China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week. I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function. Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed? I plan to cut release candidate for 2.3.1 on Sunday. Regards, Mark. _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.teslaclub.hk<mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.teslaclub.hk<mailto:OvmsDev@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(a)lists.teslaclub.hk<mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.teslaclub.hk<mailto:OvmsDev@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 _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.teslaclub.hk<mailto:OvmsDev@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(a)lists.teslaclub.hk<mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.teslaclub.hk<mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.teslaclub.hk<mailto:OvmsDev@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 _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.teslaclub.hk<mailto:OvmsDev@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(a)lists.teslaclub.hk<mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

5 27

Seeking ideas for 'range' representation
by Mark Webb-Johnson 16 Apr '13

16 Apr '13

Working with the guys at zerocarbonworld / openchargemap on the integration of Open Charge Map to the OVMS Apps, we are trying to find a way to represent range graphically. The first idea was a circle, centered around the car, with the inner edge of the circle being estimated range and the outer edge ideal range (or vice versa if you are coming down the mountains on a _long_ mountain road). Plugging in the values for my car today, assuming I was somewhere in the centre of the UK, it would look something like this: The idea is to represent the range, and then plot the charge points within (and perhaps also slightly outside) that range. That is just one idea. What do people think? Any other suggestions? Regards, Mark. P.S. Work on the Apps for this has already started, so I would appreciate a quick reply. Nothing too extensive - just ideas.Thanks.

6 9

The search for Tesla Roadster CAC
by Mark Webb-Johnson 16 Apr '13

16 Apr '13

Tom, 'roadsters', I'm searching for the CAC value on the Tesla Roadster. Here is a log extract. The first NOTE is just before we called up the diagnostic screen, and the second NOTE was after the screen had appeared. I also attach the matching diagnostics screen. 127.1062 NOTE PING: TD11 transmit 127.1236 400 01 01 00 00 00 00 4C 1D 127.1716 400 02 A3 01 80 C5 80 55 00 127.2220 400 01 01 00 00 00 00 4C 1D 127.2716 400 02 A3 01 80 C5 80 55 00 127.3220 400 01 01 00 00 00 00 4C 1D 127.3716 400 02 A3 01 80 C5 80 55 00 127.4220 400 01 01 00 00 00 00 4C 1D 127.4621 100 80 4B 92 00 64 00 7B 00 ->VDS Range (SOC 75%) (ideal 146) (est 123) 127.4633 100 9C 01 5C 01 ->VDS Trip->VDS (trip 34.8miles) 127.4716 400 02 A3 01 80 C5 80 55 00 127.5239 400 01 01 00 00 00 00 4C 1D 127.5687 402 FA 00 C3 59 F4 01 5C 01 402?? Odometer (miles: 12808.9 km: 20613.9) (trip 34.8miles) 127.5716 400 02 A3 01 80 C5 80 55 00 127.6236 400 01 01 00 00 00 00 4C 1D 127.6553 102 06 D0 07 00 00 00 00 40 VDS-> (message from VDS 06) 127.6579 100 9E 44 FD 9C 8A 5B 44 46 ->VDS (message to VDS 9E) 127.6586 100 9F 00 00 00 00 00 B5 21 ->VDS (message to VDS 9F) 127.6590 100 A0 3B 34 00 30 02 11 01 ->VDS (message to VDS A0) 127.6596 100 A1 01 41 0C 40 32 1C 00 ->VDS (message to VDS A1) 127.6600 100 A2 01 4B 00 4C FF 00 00 ->VDS (message to VDS A2) 127.6606 100 A1 02 29 0C 40 12 2D 00 ->VDS (message to VDS A1) 127.6610 100 A2 02 50 00 84 FF 00 00 ->VDS (message to VDS A2) 127.6621 100 A1 03 97 0B 41 35 36 00 ->VDS (message to VDS A1) 127.6626 100 A2 03 55 00 EA FF 00 00 ->VDS (message to VDS A2) 127.6632 100 A1 04 8B 0B 41 13 43 00 ->VDS (message to VDS A1) 127.6636 100 A2 04 53 00 0C 01 00 00 ->VDS (message to VDS A2) 127.6642 100 A1 05 87 0B 3F 07 47 00 ->VDS (message to VDS A1) 127.6647 100 A2 05 49 00 FF FF 00 00 ->VDS (message to VDS A2) 127.6653 100 A1 06 86 0B 3F 09 48 00 ->VDS (message to VDS A1) 127.6658 100 A2 06 49 00 3F FF 00 00 ->VDS (message to VDS A2) 127.6662 420 00 8A 8A 127.6665 588 00 00 84 127.6668 280 00 00 03 00 00 00 00 00 127.6670 1A0 00 00 00 00 127.6674 590 01 00 00 00 00 00 00 00 127.6717 400 02 A3 01 80 C5 80 55 00 127.7220 400 01 01 00 00 00 00 4C 1D 127.7716 400 02 A3 01 80 C5 80 55 00 127.8217 400 03 11 66 00 00 00 77 00 127.8719 400 01 01 00 00 00 00 4C 1D 127.9019 100 96 69 00 02 21 0C 00 00 ->VDS Doors (l-door: open) (r-door: closed) (chargeport: closed) (pilot: true) (charging: false) (bits 69) 127.9217 400 02 A3 01 80 C5 80 55 00 127.9720 400 01 01 00 00 00 00 4C 1D 128.0244 400 02 A3 01 80 C5 80 55 00 128.0723 400 01 01 00 00 00 00 4C 1D 128.1253 400 02 A3 01 80 C5 80 55 00 128.1723 400 01 01 00 00 00 00 4C 1D 128.2221 400 02 A3 01 80 C5 80 55 00 128.2724 400 01 01 00 00 00 00 4C 1D 128.3221 400 02 A3 01 80 C5 80 55 00 128.3724 400 01 01 00 00 00 00 4C 1D 128.4221 400 02 A3 01 80 C5 80 55 00 128.4319 100 9B 2D 88 73 0C B9 C6 07 ->VDS (message to VDS 9B) 128.4724 400 01 01 00 00 00 00 4C 1D 128.5241 400 02 A3 01 80 C5 80 55 00 128.5388 402 FA 00 C3 59 F4 01 5C 01 402?? Odometer (miles: 12808.9 km: 20613.9) (trip 34.8miles) 128.5724 400 01 01 00 00 00 00 4C 1D 128.5939 NOTE PING: TD11 transmit Most likely candidate is the "102 06" being used to inform the VMS we are looking at the ESS SOC screen, then the VMS steaming a few message with the information requested. We've seen "102 06" a screen switch command, a few times in the past. It seems to awake dormant stuff in the VMS. Looking at the return data, we get: 127.6579 100 9E 44 FD 9C 8A 5B 44 46 ->VDS (message to VDS 9E) 127.6586 100 9F 00 00 00 00 00 B5 21 ->VDS (message to VDS 9F) 127.6590 100 A0 3B 34 00 30 02 11 01 ->VDS (message to VDS A0) as likely candidates for the top part of the screen, and: 127.6596 100 A1 01 41 0C 40 32 1C 00 ->VDS (message to VDS A1) 127.6600 100 A2 01 4B 00 4C FF 00 00 ->VDS (message to VDS A2) 127.6606 100 A1 02 29 0C 40 12 2D 00 ->VDS (message to VDS A1) 127.6610 100 A2 02 50 00 84 FF 00 00 ->VDS (message to VDS A2) 127.6621 100 A1 03 97 0B 41 35 36 00 ->VDS (message to VDS A1) 127.6626 100 A2 03 55 00 EA FF 00 00 ->VDS (message to VDS A2) 127.6632 100 A1 04 8B 0B 41 13 43 00 ->VDS (message to VDS A1) 127.6636 100 A2 04 53 00 0C 01 00 00 ->VDS (message to VDS A2) 127.6642 100 A1 05 87 0B 3F 07 47 00 ->VDS (message to VDS A1) 127.6647 100 A2 05 49 00 FF FF 00 00 ->VDS (message to VDS A2) 127.6653 100 A1 06 86 0B 3F 09 48 00 ->VDS (message to VDS A1) 127.6658 100 A2 06 49 00 3F FF 00 00 ->VDS (message to VDS A2) as the rest. For the 'rest', that it six pairs of A1 A2 lines, with an index value of 01 through 06, and then 12 bytes of data (2x6) for each. Kind of looks like the 6 lines of date based AH log. For the 9E, 9F and A0, we need to find: SOC LIM: 68% (0x44 single byte hex) SOC MIN: 68% (0x44 single byte hex) SOC MAX: 70% (0x46 single byte hex) CAC: 156.99Ah AR:91.54Ah #Ah: 0.0Ah #kWh: 0.00kWh EVC: 3.7V kWhR: 33.71kWh RR: 123 miles (0x7B 0x00 tesla-style LSB-first, 2 byte hex) dRMS: 52A (0x34 single byte hex) dAI: 560mO (0x30 0x02 tesla-style LSB-first, 2 byte hex) dWhM: 273Wh/mile (0x11 0x01 tesla-style LSB-first, 2 byte hex) Given: 127.6579 100 9E 44 FD 9C 8A 5B 44 46 ->VDS (message to VDS 9E) 127.6586 100 9F 00 00 00 00 00 B5 21 ->VDS (message to VDS 9F) 127.6590 100 A0 3B 34 00 30 02 11 01 ->VDS (message to VDS A0) Here' s my working (both to show others how such a search is done, and also to document it): We can get rid of some easy ones: 127.6579 100 9E <SOCLIM?> FD 9C 8A 5B <SOCMIN?> <SOCMAX> 127.6586 100 9F 00 00 00 00 00 B5 21 127.6590 100 A0 3B 34 00 30 02 11 01 Working: 5B8A(hex) = 23434(decimal) 9CFB(hex) = 40187(decimal) and 23434/40187 = 0..5831238957 while Ah/CAC (91.54/156.99) = 0.5833174026 So, those two seem to be good candidates. Interestingly: 40187 / 156.99 = 255.98 Could it be that? 9CFD(hex) = 40187(decimal). Then 40187/256 = 156.98 5B8A(hex) = 23434(decimal). Then 23434/256 = 91.54 Close, but no cigar. We're 0.01 off on the CAC. The Tesla loves bytes, and hates decimals (just like the PIC), so how about if we treat them as separate bytes (essentially rather than /100, try /256): 9C.FD (hex) = 156.99 5B.8A (hex) = 91.54 Woohoo! I think we may have a match. Plugging in these, and some of the other ones I found along the way, gives us: 127.6579 100 9E <SOCLIM?> <CACLSB> <CACMSB> <ARLSB> <ARMSB> <SOCMIN?> <SOCMAX> 127.6586 100 9F 00 00 00 00 00 <kWhRLSB> <kWhRMSB> 127.6590 100 A0 3B <dRMSLSB> <dRMSMSB> <dAILSB> <dAIMSB> <dWhMLSB> <dWhMMSB> And the notes would be: SOC LIM: 68% (0x44 single byte hex) - 100 9E (B2) SOC MIN: 68% (0x44 single byte hex) - 100 9E (B7) SOC MAX: 70% (0x46 single byte hex) - 100 9E (B8) CAC: 156.99Ah - 100 9E (B4 . B3/256) AR:91.54Ah - 100 9E (B6 . B5/256) #Ah: 0.0Ah #kWh: 0.00kWh EVC: 3.7V kWhR: 33.71kWh - 100 9F (B8 . B7/256) RR: 123 miles (0x7B 0x00 tesla-style LSB-first, 2 byte hex) - maybe just from 100 80 (standard message) dRMS: 52A (0x34 single byte hex) - 100 A0 (B4-MSB B3-LSB) dAI: 560mO (0x30 0x02 tesla-style LSB-first, 2 byte hex) - 100 A0 (B6-MSB B5-LSB) dWhM: 273Wh/mile (0x11 0x01 tesla-style LSB-first, 2 byte hex) - 100 A0 (B8-MSB B5-LSB) I did a search for '100 9E' in all my old logs, and find only one other: anon1_charge_heating049.txt: 0.0 100 9E 3F A1 9C 40 52 3F 42 ->VDS (message to VDS 9E) Not exactly surprising, as presumably that diagnostic screen would have had to be open, while the can log was being captured. Very rare. That is a charging log provided by one the the users here. I've labelled it anonymous, because I'm not sure if he publicised the data. Putting the same decode logic in, would give us for him: SOC LIM: 63% SOC MIN: 63% SOC MAX: 66% CAC: 156..63Ah AR: 82.24Ah I did a search for '9C FD' through the rest of my logs (including a large 20 minute one), and is did't show up anywhere apart from '100 9E'. So, my conclusion is that I'm pretty sure this is the CAC value, as well as a bunch of other techy metrics and the last six consumption history records. Nasty is that we have to request it (with a 102 06 D0 07 00 00 00 00 40). We could presumably stop the request (with a 102 06 10 …), but it times out after a while anyway. I think what I'll do is add that to the code for charge completion in vehicle_teslaroadster, and add a decoder to pick the CAC up off the bus and report it back. That way, we'll check the CAC every time a charge completes. If any other vehicles have a useful indication of overall battery health, they can use the same value. Regards, Mark. P.S. What is CAC? It is the "Calculated Amp-hour Capacity" and supposedly a very good indication of the capacity of the vehicle's battery.Tesla Roadster owners are using it to track long-term degradation of their batteries, and Tom Saxton will be very happy with me if I can get this back to him from a reasonable number of Tesla Roadsters. It will be my thank you to him for his work on charge completion time estimation, and definitely worth a few minutes CAN-bus logging in the car (but not so sure about the hours staring through those logs with a decimal-hex calculator :-)

2 4

v2.2.5
by Mark Webb-Johnson 16 Apr '13

16 Apr '13

Back from the brink… Good grief, there is some nasty stuff coming out of China now. I managed to spend some time on OVMS firmware today, and built v2.2.5. Change log is: 2013-04-01 2.2.5 Firmware 2.2.5 ### Fixes for charge notification logic on VA ### Show charge, trunk and alarm notifications in DIAG mode ### Speed, parking, and general tidy-ups for VA ### Switch ambient temperature to PID 0x801f for VA ### Auto-calibration for 12V line reading ### Twizy version 2.6.1 - power line plug-in detection ### Add car_doors5 for rear doors, frunk and 12v charging ### 12v alert by MSG protocol fix ### Rework of 12V reference logic - Filters out single peaks / misreadings - Sends "OK" alerts if voltage level restores w/o charging - 15 minutes calmdown before taking new ref voltage - No alerts while car is on ### ESS SOC DIAG (for TR) ### Initial support for CAC in TR and TZ modules ### Experimental Tazzari (TZ) module ### Experimental Nissan Leaf (NL) module All is in github. I haven't run it in my car yet, but it tests out fine on the bench. It is going into my car in a few minutes time. Major changes are the experimental support for Tazzari, some bug fixes and 12V work on Twizzy, and support for CAC readings in Tazzari and Tesla Roadster (including protocol extensions to report back to apps). Regards, Mark. P.S. I haven't had time to make anything good for 1st April this year (although I did consider an experimental module for Hummer support). Anyway, please consider any bugs in this version just an April fools joke.

6 39

Re: [Ovmsdev] WG: Release Firmware
by Mark Webb-Johnson 16 Apr '13

16 Apr '13

Pierre, To get CAC you need to either (a) turn car on, (b) turn car off, or (c) start a charge. It should then show up in the output. I checked the server logs, and it is now showing up for your car, so that should be ok in STAT SMS now. Regards, Mark. On 16 Apr, 2013, at 4:26 AM, Pierre Uhl wrote: > > Good morning Mark, > > Flashed my Tesla and everything is working except CAC. > > I got another Error for your collection: ID 1084 DMC FW:HCS Faulted warning. > It is possible that this is because too much humidity in the HPC-Box. > > Regards > > Pierre > > > > <Screenshot_2013-04-15-21-16-53.png><Screenshot_2013-04-15-21-17-19.png><20130410_123601a.jpg>_______________________________________________ > OvmsDev mailing list > OvmsDev(a)lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

1 0