From what RScott has written, the can bus you are on looks to have what we want. I understand everything stops when car is turned off. But, can you try recording while charging and see if it still stops?

Yes, it stops too when it is charging.

This may be an issue. One of the primary used features of OVMS is the ability to monitor the charge, and get alerted if it stops. I guess it is less of an issue with the Volt/Ampera (due to the ICE backup engine), but still required, I guess.

Can you do some more testing around this. See what happens if you abort a charge early? Perhaps leave it running and see if it starts/stops periodically.

In the meantime, I'll work on the skeleton. Based on RScott's work, it shouldn't take long.

The main challenge is going to be converting milliarcseconds to OVMS format latitude/longitude, on an 8 bit microprocessor!

Anyone here want to help out with an algorithm for that?

Tesla stores it as a long, and looks like 2048*3600 times the latitude or longitude value. We'll need to convert Volt/Ampera milliarcseconds to that Tesla long format, to keep things simple.

The current function for converting Tesla Roadster latitude/longitude to a string format (for the protocol) is:

// Format a Latitude/Longitude as a string
// <dest> must have room to receive the output
void format_latlon(long latlon, char* dest)
  {
  float res;
  long lWhole; // Stores digits left of decimal
  unsigned long ulPart; // Stores digits right of decimal

  if (latlon < 0)
    {
    *dest++ = '-';
    latlon = ~latlon; // and invert value
    }
  res = (float) latlon / 2048 / 3600; // Tesla specific GPS conversion
  lWhole = (long) ((float) res); // As the PIC has no floating point support in printf,
  // we do it manually
  ulPart = (unsigned long) ((float) res * 1000000) - lWhole * 1000000;
  sprintf(dest, (rom far char*)"%li.%06li", lWhole, ulPart); // make sure we print leading zero's after the decimal point
  }

Is it as simple as Tesla using 2048 as the factor, and Volt/Ampera using 1000?

Some log data for that, with real latitude+longitude to compare, would be really helpful to confirm whatever we do here.

Regards, Mark.

P.S. Michael: what color is your Ampera? I'll put a picture in the App for you, so you have something to make you feel good about all this work ;-)

On 30 May, 2012, at 2:43 AM, Michael Jochum wrote:

Hi mark,

Probably best to continue the discussion on the ovmsdev mailing list, as others there are interested in progress (especially dpeillow and Marcus).
Yes. answer to the list.


What you have below is a 'cyclic' log. Good for identifying unique messages (by ID) seen on the bus. Can you see if canhack has a normal logging mode to just log all messages with a time stamp?

i will do my best.


What type of PC do you use? Linux, Mac or Windows?

For this first i use a PC with XP.


From what RScott has written, the can bus you are on looks to have what we want. I understand everything stops when car is turned off. But, can you try recording while charging and see if it still stops?

Yes, it stops too when it is charging.


I think that as a starting point we should target a limited amount of information, to just try to get something working and see how feasible this is. Specifically, I suggest:

  1. SOC% (CAN ID #206)
  2. GPS Latitude and Longitude (CAN ID #32A)
  3. Vehicle Speed (CAN ID #3E9)
  4. VIN (unknown CAN ID, but supposedly there)

From the document at:


these should be:

CAN IDLocationDataUnitsNotes




206Bytes 1-2Battery SOC.250kWhUnits possibly .244kWh
32ABytes 1-4GPS LatitudeMilliarcseconds 
32ABytes 5-8GPS LongitudeMilliarcseconds 
3E9Bytes 1-2Speed1/100 MPH55MPH would be 5500 (0x157c)

Looking at your capture, you have:

  • 206      3   69 C3 00 

at this time the battery was charging. i think ist was between 30 and 40 %.
you must know that the lowest usable Battery power is at 30% an full is at 90%.
i will got the next log when the battery is full

  • 32A      8   00 00 00 00 00 00 00 00 
  • 3E9      8   00 00 00 00 00 00 00 00

Probably your car was stationary or in the garage without GPS signal?

it was stationary in front of my house with clear view to the sky.


RScott's sample data is:

  • 11:48:49.885: 206 628600
  • 11:48:54.955: 206 5FCA00
  • 11:48:49.636: 3E9 0BAC01AC0B3C019E [Speed 29.88MPH]
  • 11:48:49.870: 3E9 0C3B01C20BED01B4 [Speed 31.31MPH]

Can you try to capture:

  1. The SOC% in your car, as displayed by the car itself, and matching capture of ID #206.
is coming

  1. Drive down a stretch of road at a constant speed, while logging. Then, get the approximate latitude and longitude of your position and speed you were at, and matching capture of ID #32A and ID #3E9.
i only have two hands. :-)

  1. Put the car in the open air, so it has a good GPS signal. Then, get the exact latitude and longitude of your location, and matching capture of ID#32
  1. The VIN number of your car.


Based on that, we should be able to setup OVMS to capture this and transmit it on to the OVMS server/apps.
yes

Do you want me to create the framework for this in can_voltampera.c? Maybe easier for me to create the first few messages, and then for you to adjust and fix, as I know the code so well.
ok, so it looks good.

This is looking really promising. Your 104 captured IDs seem to match RScott's 105 almost exactly, and most of what we need has already been discovered.
Good. 

Bye
michael


Regards, Mark.

On 29 May, 2012, at 6:03 AM, Michael Jochum wrote:

Hi Mark,

i did the first try to get a CAN Log from my Volt. It works. I got a first small output. Didi it with CANHACK. Unfortunately the Log is not so formated that a Program can read it. A human can. Still waiting for your script.
But, ... we have a problem! 10 seconds after the car is shut down the is no more traffic on this CAN bus. 12V are still there.
But there are three (3) more CAN Buses in this car. Really!
Two at the OBD2 Connector driver side and two at the OBD2 Connector Passenger side.
I will made me some adapter to get access to this Signals. Hope they still alive after shutdown the car.

Here is the small Log: (i think this is NOT a time based log. it seems that this is a log from all seen messages)


Bye
Michael