I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too...... One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1... which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340 If I'm not mistaken the OVMS currently reads the CAR CanBus ? There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help? GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure. I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc. So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right? Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now... Thanks Nigel. nigel@cherrybyte.me.uk -- ---- Nigel Jones
OVMS reports 0% SOC and sends out panicked low battery messages when it's not getting a valid SOC message from the CAN bus. I get this when I screw up the vehicle setting, which is set via the MODULE command. The first thing I'd do is make sure the vehicle type is set correctly. You can see it from the smartphone app on the Vehicle Info screen, look at the Car line. For my set up I see: Car: 2.6.5/TR/V2 This says the car is running firmware version 2.6.5, the car type is TR (Tesla Roadster), and it's V2 hardware. You can get the same info by texting MODULE? to the car, which returns the VehicleID, VehicleType, Units (miles or km), and the notifications setting. For the Leaf, you should see NL as the vehicle type. Which CAN bus OVMS reads depends on how the cable is wired. I believe the group consensus is that reading from the CAR CAN bus is the best strategy since we know LeafSpy is able to get everything from the that bus. The code in vehicle_nissanleaf.c that decodes data from message 0x5b3 looks like it's trying to pull out the Gid values scaled down to work as a rough SOC %, but it looks like the array offsets are off by one. Dividing by 3 is a rough approximation to multiplying by 100 and dividing by 281 to get the standard conversion from Gids to percent. case 0x5b3: // Rough and kludgy car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; break; Here's a sample message from our Leaf: 5B3 69 BE FF FF FC DD 53 0A When I captured that message, I was reading 221 = 0xDD Gids. Both the Leaf message decoder spreadsheet and the OVMS can_databuffer array start indexing bytes at 0, so byte zero is 0x69, byte 1 is 0xBE, etc. Using the Leaf message decoder spreadsheet, I believe the Gids calculation is: take the low bit of byte 4, shift left by 8 into 16 bits then add byte 5: (((int)0xFC&0x01)<<8) + 0xDD = 0xDD = 221. So I think the code to extract Gids from CAR CAN message 0x5B3 is: (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5] My thought is that the Gids value should be stored in car_idealrange. Like Gids, the ideal range on the Roadster is an estimate of the state of charge in absolute energy units. An ideal mile is 225.4 Wh; a Gid is 80 Wh. The UI on the Smartphone app will have to change, or Gids will have to be scaled. I propose this: car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent Optionally, we could do the same thing with Gids that Tesla did to compute ideal miles. The EPA said the Roadster's range is 244 miles, so Tesla equated that with the nominal full capacity of a new Roadster battery, and thus the ideal miles was created. To do the same for the Leaf, take the EPA rating of 84 miles (after Nissan eliminated the 80% charge to get rid of the EPA's stupidity in taking the range to be the average of the 100% and 80% charge levels). After using the raw gids to compute the SOC percent, convert to EPA rated miles: car_idealrange = (car_idealrange * 84 + 140) / 281; We can also get the SOH value out of message 0x5B3. According to the spreadsheet, it's the top seven bits in byte one, so soh = can_databuffer[1] >> 1; For my sample message above, that's 0xBE >> 1 = 0x5F = 95, which agrees with the SOH reported by LeafSpy when I did that data capture. BTW, SOH and Hx appear to be different, but perhaps related. I'm trying to figure that out. I suspect SOH is just the Hx value rounded, but I have some data from the Plug In America Leaf survey which contradicts that. The value in message 0x5BE doesn't have enough bits to be the higher resolution Hx. Tom On 5/6/14, 11:39 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote: I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too...... One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1 ON2xZSzlMUXc#gid=0 which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340 If I'm not mistaken the OVMS currently reads the CAR CanBus ? There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help? GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure. I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc. So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right? Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now... Thanks Nigel. nigel@cherrybyte.me.uk -- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Leaf spy uses the car CAN bus because that's the way the ELM modules come stock, so Jim and others did excellent work figuring out how to request from the EV bus presumably through the VCM. Some initial work was done using modified ELM's set up to read the EV bus. Keep in mind the the ELM doesn't have much "horsepower" to filter for specific messages so doing requests is the best way to use it. The telematics module in the stock leaf uses the EV bus, and that's the one I'd recommend using for OVMS. When the leaf is off for more than ~30 seconds or so, the Car CAN bus goes silent, even while charging. The ev bus is active when the car is on, charging, remote CC, or for about 30 seconds when the telematics module wakes up the VCM over a separate logic line (I believe pulling a line low). If you start sending requests on the car can while the ev bus is active but the car is not on, you will get a click on/off from a relay for every request you send. It's not damaging but the clicking is obviously undesirable. However if the car is completely powered off and not charging the car does not respond to car can requests. Thus, I don't think using the car can for OVMS is the way to go since most of the time it's use will be when the car is powered down. Jeremy On Tuesday, May 6, 2014, Tom Saxton <tom@idleloop.com> wrote:
OVMS reports 0% SOC and sends out panicked low battery messages when it's not getting a valid SOC message from the CAN bus. I get this when I screw up the vehicle setting, which is set via the MODULE command. The first thing I'd do is make sure the vehicle type is set correctly. You can see it from the smartphone app on the Vehicle Info screen, look at the Car line. For my set up I see:
Car: 2.6.5/TR/V2
This says the car is running firmware version 2.6.5, the car type is TR (Tesla Roadster), and it's V2 hardware.
You can get the same info by texting MODULE? to the car, which returns the VehicleID, VehicleType, Units (miles or km), and the notifications setting.
For the Leaf, you should see NL as the vehicle type.
Which CAN bus OVMS reads depends on how the cable is wired. I believe the group consensus is that reading from the CAR CAN bus is the best strategy since we know LeafSpy is able to get everything from the that bus.
The code in vehicle_nissanleaf.c that decodes data from message 0x5b3 looks like it's trying to pull out the Gid values scaled down to work as a rough SOC %, but it looks like the array offsets are off by one. Dividing by 3 is a rough approximation to multiplying by 100 and dividing by 281 to get the standard conversion from Gids to percent.
case 0x5b3: // Rough and kludgy car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; break;
Here's a sample message from our Leaf:
5B3 69 BE FF FF FC DD 53 0A
When I captured that message, I was reading 221 = 0xDD Gids. Both the Leaf message decoder spreadsheet and the OVMS can_databuffer array start indexing bytes at 0, so byte zero is 0x69, byte 1 is 0xBE, etc. Using the Leaf message decoder spreadsheet, I believe the Gids calculation is: take the low bit of byte 4, shift left by 8 into 16 bits then add byte 5:
(((int)0xFC&0x01)<<8) + 0xDD = 0xDD = 221.
So I think the code to extract Gids from CAR CAN message 0x5B3 is:
(((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]
My thought is that the Gids value should be stored in car_idealrange. Like Gids, the ideal range on the Roadster is an estimate of the state of charge in absolute energy units. An ideal mile is 225.4 Wh; a Gid is 80 Wh. The UI on the Smartphone app will have to change, or Gids will have to be scaled.
I propose this:
car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent
Optionally, we could do the same thing with Gids that Tesla did to compute ideal miles. The EPA said the Roadster's range is 244 miles, so Tesla equated that with the nominal full capacity of a new Roadster battery, and thus the ideal miles was created. To do the same for the Leaf, take the EPA rating of 84 miles (after Nissan eliminated the 80% charge to get rid of the EPA's stupidity in taking the range to be the average of the 100% and 80% charge levels). After using the raw gids to compute the SOC percent, convert to EPA rated miles:
car_idealrange = (car_idealrange * 84 + 140) / 281;
We can also get the SOH value out of message 0x5B3. According to the spreadsheet, it's the top seven bits in byte one, so
soh = can_databuffer[1] >> 1;
For my sample message above, that's 0xBE >> 1 = 0x5F = 95, which agrees with the SOH reported by LeafSpy when I did that data capture.
BTW, SOH and Hx appear to be different, but perhaps related. I'm trying to figure that out. I suspect SOH is just the Hx value rounded, but I have some data from the Plug In America Leaf survey which contradicts that. The value in message 0x5BE doesn't have enough bits to be the higher resolution Hx.
Tom
On 5/6/14, 11:39 AM, "Nigel Jones" <nigel@cherrybyte.me.uk<javascript:_e(%7B%7D,'cvml','nigel@cherrybyte.me.uk');>> wrote:
I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too......
One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1...
which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340
If I'm not mistaken the OVMS currently reads the CAR CanBus ?
There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help?
GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure.
I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc.
So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at
http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html
It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right?
Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now...
Thanks Nigel. nigel@cherrybyte.me.uk<javascript:_e(%7B%7D,'cvml','nigel@cherrybyte.me.uk');>
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk<javascript:_e(%7B%7D,'cvml','OvmsDev@lists.teslaclub.hk');> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Jeremy, The polling code we have has three states, which control how the polling is done - what is polled, when. The thinking is that we can change the polling behaviour depending on what state the car is in (for example, only polling once a minute or so when the car is charging). You are correct in that OVMS can connect to either one of the EV or CAR can buses. We would need a custom cable, but that is not too hard. I guess the advantage of using the EV can bus is that we can directly read the EV can bus values, especially during charging. The disadvantages are that we need to poll the car can bus (but there is very little known about the capabilities of that - I have read that it is possible, but has anyone actually tested it?), and that a custom cable would be required. The advantages of using the CAR can bus are that the behaviour is well known, and standard cables and tools can be used (we know it works because of leafspy and others). The disadvantage is that the EV bus must be polled (taking care with that 'clicking' issue). I'm happy to go whichever way you guys think is best. But, if we want to use the EV can bus, we do need to confirm that we can PID poll from that bus through to the car can bus as well as determine the state of the car (off, charging, driving) purely from messages on that one bus. Regards, Mark. On 7 May, 2014, at 8:38 am, Jeremy Whaling <jeremy.whaling@gmail.com> wrote:
Leaf spy uses the car CAN bus because that's the way the ELM modules come stock, so Jim and others did excellent work figuring out how to request from the EV bus presumably through the VCM. Some initial work was done using modified ELM's set up to read the EV bus. Keep in mind the the ELM doesn't have much "horsepower" to filter for specific messages so doing requests is the best way to use it.
The telematics module in the stock leaf uses the EV bus, and that's the one I'd recommend using for OVMS. When the leaf is off for more than ~30 seconds or so, the Car CAN bus goes silent, even while charging. The ev bus is active when the car is on, charging, remote CC, or for about 30 seconds when the telematics module wakes up the VCM over a separate logic line (I believe pulling a line low). If you start sending requests on the car can while the ev bus is active but the car is not on, you will get a click on/off from a relay for every request you send. It's not damaging but the clicking is obviously undesirable. However if the car is completely powered off and not charging the car does not respond to car can requests.
Thus, I don't think using the car can for OVMS is the way to go since most of the time it's use will be when the car is powered down.
Jeremy
On Tuesday, May 6, 2014, Tom Saxton <tom@idleloop.com> wrote: OVMS reports 0% SOC and sends out panicked low battery messages when it's not getting a valid SOC message from the CAN bus. I get this when I screw up the vehicle setting, which is set via the MODULE command. The first thing I'd do is make sure the vehicle type is set correctly. You can see it from the smartphone app on the Vehicle Info screen, look at the Car line. For my set up I see:
Car: 2.6.5/TR/V2
This says the car is running firmware version 2.6.5, the car type is TR (Tesla Roadster), and it's V2 hardware.
You can get the same info by texting MODULE? to the car, which returns the VehicleID, VehicleType, Units (miles or km), and the notifications setting.
For the Leaf, you should see NL as the vehicle type.
Which CAN bus OVMS reads depends on how the cable is wired. I believe the group consensus is that reading from the CAR CAN bus is the best strategy since we know LeafSpy is able to get everything from the that bus.
The code in vehicle_nissanleaf.c that decodes data from message 0x5b3 looks like it's trying to pull out the Gid values scaled down to work as a rough SOC %, but it looks like the array offsets are off by one. Dividing by 3 is a rough approximation to multiplying by 100 and dividing by 281 to get the standard conversion from Gids to percent.
case 0x5b3: // Rough and kludgy car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; break;
Here's a sample message from our Leaf:
5B3 69 BE FF FF FC DD 53 0A
When I captured that message, I was reading 221 = 0xDD Gids. Both the Leaf message decoder spreadsheet and the OVMS can_databuffer array start indexing bytes at 0, so byte zero is 0x69, byte 1 is 0xBE, etc. Using the Leaf message decoder spreadsheet, I believe the Gids calculation is: take the low bit of byte 4, shift left by 8 into 16 bits then add byte 5:
(((int)0xFC&0x01)<<8) + 0xDD = 0xDD = 221.
So I think the code to extract Gids from CAR CAN message 0x5B3 is:
(((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]
My thought is that the Gids value should be stored in car_idealrange. Like Gids, the ideal range on the Roadster is an estimate of the state of charge in absolute energy units. An ideal mile is 225.4 Wh; a Gid is 80 Wh. The UI on the Smartphone app will have to change, or Gids will have to be scaled.
I propose this:
car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent
Optionally, we could do the same thing with Gids that Tesla did to compute ideal miles. The EPA said the Roadster's range is 244 miles, so Tesla equated that with the nominal full capacity of a new Roadster battery, and thus the ideal miles was created. To do the same for the Leaf, take the EPA rating of 84 miles (after Nissan eliminated the 80% charge to get rid of the EPA's stupidity in taking the range to be the average of the 100% and 80% charge levels). After using the raw gids to compute the SOC percent, convert to EPA rated miles:
car_idealrange = (car_idealrange * 84 + 140) / 281;
We can also get the SOH value out of message 0x5B3. According to the spreadsheet, it's the top seven bits in byte one, so
soh = can_databuffer[1] >> 1;
For my sample message above, that's 0xBE >> 1 = 0x5F = 95, which agrees with the SOH reported by LeafSpy when I did that data capture.
BTW, SOH and Hx appear to be different, but perhaps related. I'm trying to figure that out. I suspect SOH is just the Hx value rounded, but I have some data from the Plug In America Leaf survey which contradicts that. The value in message 0x5BE doesn't have enough bits to be the higher resolution Hx.
Tom
On 5/6/14, 11:39 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too......
One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1...
which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340
If I'm not mistaken the OVMS currently reads the CAR CanBus ?
There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help?
GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure.
I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc.
So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at
http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html
It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right?
Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now...
Thanks Nigel. nigel@cherrybyte.me.uk
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Tom, In general, I think it best to keep the original meaning of the standardised messages and values. So, 'ideal' range is some standardised measure of ideal range (based on EPA or whatever the manufacturer suggests) and 'estimated' range is based on prior driving habits (or some more realistic estimate). For per-vehicle custom information (such as GIDs), I've been meaning to add something to allow that for some time. It is actually fairly simple - include a callback hook in the vehicle.{h,c} functions to allow the vehicle to output vehicle-specific custom data. I've been thinking we can use protocol messages '0' through '9' for this custom information, so it gets through to the Apps. The apps themselves can use a custom tab to display this in a vehicle-specific manner. Regards, Mark. On 7 May, 2014, at 7:16 am, Tom Saxton <tom@idleloop.com> wrote:
OVMS reports 0% SOC and sends out panicked low battery messages when it's not getting a valid SOC message from the CAN bus. I get this when I screw up the vehicle setting, which is set via the MODULE command. The first thing I'd do is make sure the vehicle type is set correctly. You can see it from the smartphone app on the Vehicle Info screen, look at the Car line. For my set up I see:
Car: 2.6.5/TR/V2
This says the car is running firmware version 2.6.5, the car type is TR (Tesla Roadster), and it's V2 hardware.
You can get the same info by texting MODULE? to the car, which returns the VehicleID, VehicleType, Units (miles or km), and the notifications setting.
For the Leaf, you should see NL as the vehicle type.
Which CAN bus OVMS reads depends on how the cable is wired. I believe the group consensus is that reading from the CAR CAN bus is the best strategy since we know LeafSpy is able to get everything from the that bus.
The code in vehicle_nissanleaf.c that decodes data from message 0x5b3 looks like it's trying to pull out the Gid values scaled down to work as a rough SOC %, but it looks like the array offsets are off by one. Dividing by 3 is a rough approximation to multiplying by 100 and dividing by 281 to get the standard conversion from Gids to percent.
case 0x5b3: // Rough and kludgy car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; break;
Here's a sample message from our Leaf:
5B3 69 BE FF FF FC DD 53 0A
When I captured that message, I was reading 221 = 0xDD Gids. Both the Leaf message decoder spreadsheet and the OVMS can_databuffer array start indexing bytes at 0, so byte zero is 0x69, byte 1 is 0xBE, etc. Using the Leaf message decoder spreadsheet, I believe the Gids calculation is: take the low bit of byte 4, shift left by 8 into 16 bits then add byte 5:
(((int)0xFC&0x01)<<8) + 0xDD = 0xDD = 221.
So I think the code to extract Gids from CAR CAN message 0x5B3 is:
(((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]
My thought is that the Gids value should be stored in car_idealrange. Like Gids, the ideal range on the Roadster is an estimate of the state of charge in absolute energy units. An ideal mile is 225.4 Wh; a Gid is 80 Wh. The UI on the Smartphone app will have to change, or Gids will have to be scaled.
I propose this:
car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent
Optionally, we could do the same thing with Gids that Tesla did to compute ideal miles. The EPA said the Roadster's range is 244 miles, so Tesla equated that with the nominal full capacity of a new Roadster battery, and thus the ideal miles was created. To do the same for the Leaf, take the EPA rating of 84 miles (after Nissan eliminated the 80% charge to get rid of the EPA's stupidity in taking the range to be the average of the 100% and 80% charge levels). After using the raw gids to compute the SOC percent, convert to EPA rated miles:
car_idealrange = (car_idealrange * 84 + 140) / 281;
We can also get the SOH value out of message 0x5B3. According to the spreadsheet, it's the top seven bits in byte one, so
soh = can_databuffer[1] >> 1;
For my sample message above, that's 0xBE >> 1 = 0x5F = 95, which agrees with the SOH reported by LeafSpy when I did that data capture.
BTW, SOH and Hx appear to be different, but perhaps related. I'm trying to figure that out. I suspect SOH is just the Hx value rounded, but I have some data from the Plug In America Leaf survey which contradicts that. The value in message 0x5BE doesn't have enough bits to be the higher resolution Hx.
Tom
On 5/6/14, 11:39 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too......
One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1...
which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340
If I'm not mistaken the OVMS currently reads the CAR CanBus ?
There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help?
GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure.
I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc.
So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at
http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html
It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right?
Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now...
Thanks Nigel. nigel@cherrybyte.me.uk
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark, That's exactly what I proposed with the code that converts Gids to EPA rated miles; scale 281 Gids to 84 EPA miles. Still, Leaf nerds will want to see raw Gids, SOH, and Hx so having a way to display those sorts of values will be great. Tom On 5/6/14, 5:48 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote: Tom, In general, I think it best to keep the original meaning of the standardised messages and values. So, 'ideal' range is some standardised measure of ideal range (based on EPA or whatever the manufacturer suggests) and 'estimated' range is based on prior driving habits (or some more realistic estimate). For per-vehicle custom information (such as GIDs), I've been meaning to add something to allow that for some time. It is actually fairly simple - include a callback hook in the vehicle.{h,c} functions to allow the vehicle to output vehicle-specific custom data. I've been thinking we can use protocol messages '0' through '9' for this custom information, so it gets through to the Apps. The apps themselves can use a custom tab to display this in a vehicle-specific manner. Regards, Mark. On 7 May, 2014, at 7:16 am, Tom Saxton <tom@idleloop.com> wrote:
OVMS reports 0% SOC and sends out panicked low battery messages when it's not getting a valid SOC message from the CAN bus. I get this when I screw up the vehicle setting, which is set via the MODULE command. The first thing I'd do is make sure the vehicle type is set correctly. You can see it from the smartphone app on the Vehicle Info screen, look at the Car line. For my set up I see:
Car: 2.6.5/TR/V2
This says the car is running firmware version 2.6.5, the car type is TR (Tesla Roadster), and it's V2 hardware.
You can get the same info by texting MODULE? to the car, which returns the VehicleID, VehicleType, Units (miles or km), and the notifications setting.
For the Leaf, you should see NL as the vehicle type.
Which CAN bus OVMS reads depends on how the cable is wired. I believe the group consensus is that reading from the CAR CAN bus is the best strategy since we know LeafSpy is able to get everything from the that bus.
The code in vehicle_nissanleaf.c that decodes data from message 0x5b3 looks like it's trying to pull out the Gid values scaled down to work as a rough SOC %, but it looks like the array offsets are off by one. Dividing by 3 is a rough approximation to multiplying by 100 and dividing by 281 to get the standard conversion from Gids to percent.
case 0x5b3: // Rough and kludgy car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; break;
Here's a sample message from our Leaf:
5B3 69 BE FF FF FC DD 53 0A
When I captured that message, I was reading 221 = 0xDD Gids. Both the Leaf message decoder spreadsheet and the OVMS can_databuffer array start indexing bytes at 0, so byte zero is 0x69, byte 1 is 0xBE, etc. Using the Leaf message decoder spreadsheet, I believe the Gids calculation is: take the low bit of byte 4, shift left by 8 into 16 bits then add byte 5:
(((int)0xFC&0x01)<<8) + 0xDD = 0xDD = 221.
So I think the code to extract Gids from CAR CAN message 0x5B3 is:
(((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]
My thought is that the Gids value should be stored in car_idealrange. Like Gids, the ideal range on the Roadster is an estimate of the state of charge in absolute energy units. An ideal mile is 225.4 Wh; a Gid is 80 Wh. The UI on the Smartphone app will have to change, or Gids will have to be scaled.
I propose this:
car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent
Optionally, we could do the same thing with Gids that Tesla did to compute ideal miles. The EPA said the Roadster's range is 244 miles, so Tesla equated that with the nominal full capacity of a new Roadster battery, and thus the ideal miles was created. To do the same for the Leaf, take the EPA rating of 84 miles (after Nissan eliminated the 80% charge to get rid of the EPA's stupidity in taking the range to be the average of the 100% and 80% charge levels). After using the raw gids to compute the SOC percent, convert to EPA rated miles:
car_idealrange = (car_idealrange * 84 + 140) / 281;
We can also get the SOH value out of message 0x5B3. According to the spreadsheet, it's the top seven bits in byte one, so
soh = can_databuffer[1] >> 1;
For my sample message above, that's 0xBE >> 1 = 0x5F = 95, which agrees with the SOH reported by LeafSpy when I did that data capture.
BTW, SOH and Hx appear to be different, but perhaps related. I'm trying to figure that out. I suspect SOH is just the Hx value rounded, but I have some data from the Plug In America Leaf survey which contradicts that. The value in message 0x5BE doesn't have enough bits to be the higher resolution Hx.
Tom
On 5/6/14, 11:39 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too......
One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1... 2xZSzlMUXc#gid=0
which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340
If I'm not mistaken the OVMS currently reads the CAR CanBus ?
There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help?
GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure.
I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc.
So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at
http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html
It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right?
Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now...
Thanks Nigel. nigel@cherrybyte.me.uk
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Tom, I just committed this: index 1e17f34..2b695ec 100644 --- a/vehicle/OVMS.X/vehicle_nissanleaf.c +++ b/vehicle/OVMS.X/vehicle_nissanleaf.c @@ -92,7 +92,9 @@ BOOL vehicle_nissanleaf_poll1(void) } case 0x5b3: // Rough and kludgy - car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; + car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids + car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent + car_idealrange = (car_idealrange * 84 + 140) / 281; break; } return TRUE; But, perhaps too simplistic (due to car_SOC being unsigned char). The car_idealrange is unsigned int, so it may be ok. What is your thinking regarding the EV bus vs CAN bus decision? Regards, Mark. On 7 May, 2014, at 9:13 am, Tom Saxton <tom@idleloop.com> wrote:
Mark,
That's exactly what I proposed with the code that converts Gids to EPA rated miles; scale 281 Gids to 84 EPA miles.
Still, Leaf nerds will want to see raw Gids, SOH, and Hx so having a way to display those sorts of values will be great.
Tom
On 5/6/14, 5:48 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
In general, I think it best to keep the original meaning of the standardised messages and values. So, 'ideal' range is some standardised measure of ideal range (based on EPA or whatever the manufacturer suggests) and 'estimated' range is based on prior driving habits (or some more realistic estimate).
For per-vehicle custom information (such as GIDs), I've been meaning to add something to allow that for some time. It is actually fairly simple - include a callback hook in the vehicle.{h,c} functions to allow the vehicle to output vehicle-specific custom data. I've been thinking we can use protocol messages '0' through '9' for this custom information, so it gets through to the Apps. The apps themselves can use a custom tab to display this in a vehicle-specific manner.
Regards, Mark.
On 7 May, 2014, at 7:16 am, Tom Saxton <tom@idleloop.com> wrote:
OVMS reports 0% SOC and sends out panicked low battery messages when it's not getting a valid SOC message from the CAN bus. I get this when I screw up the vehicle setting, which is set via the MODULE command. The first thing I'd do is make sure the vehicle type is set correctly. You can see it from the smartphone app on the Vehicle Info screen, look at the Car line. For my set up I see:
Car: 2.6.5/TR/V2
This says the car is running firmware version 2.6.5, the car type is TR (Tesla Roadster), and it's V2 hardware.
You can get the same info by texting MODULE? to the car, which returns the VehicleID, VehicleType, Units (miles or km), and the notifications setting.
For the Leaf, you should see NL as the vehicle type.
Which CAN bus OVMS reads depends on how the cable is wired. I believe the group consensus is that reading from the CAR CAN bus is the best strategy since we know LeafSpy is able to get everything from the that bus.
The code in vehicle_nissanleaf.c that decodes data from message 0x5b3 looks like it's trying to pull out the Gid values scaled down to work as a rough SOC %, but it looks like the array offsets are off by one. Dividing by 3 is a rough approximation to multiplying by 100 and dividing by 281 to get the standard conversion from Gids to percent.
case 0x5b3: // Rough and kludgy car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; break;
Here's a sample message from our Leaf:
5B3 69 BE FF FF FC DD 53 0A
When I captured that message, I was reading 221 = 0xDD Gids. Both the Leaf message decoder spreadsheet and the OVMS can_databuffer array start indexing bytes at 0, so byte zero is 0x69, byte 1 is 0xBE, etc. Using the Leaf message decoder spreadsheet, I believe the Gids calculation is: take the low bit of byte 4, shift left by 8 into 16 bits then add byte 5:
(((int)0xFC&0x01)<<8) + 0xDD = 0xDD = 221.
So I think the code to extract Gids from CAR CAN message 0x5B3 is:
(((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]
My thought is that the Gids value should be stored in car_idealrange. Like Gids, the ideal range on the Roadster is an estimate of the state of charge in absolute energy units. An ideal mile is 225.4 Wh; a Gid is 80 Wh. The UI on the Smartphone app will have to change, or Gids will have to be scaled.
I propose this:
car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent
Optionally, we could do the same thing with Gids that Tesla did to compute ideal miles. The EPA said the Roadster's range is 244 miles, so Tesla equated that with the nominal full capacity of a new Roadster battery, and thus the ideal miles was created. To do the same for the Leaf, take the EPA rating of 84 miles (after Nissan eliminated the 80% charge to get rid of the EPA's stupidity in taking the range to be the average of the 100% and 80% charge levels). After using the raw gids to compute the SOC percent, convert to EPA rated miles:
car_idealrange = (car_idealrange * 84 + 140) / 281;
We can also get the SOH value out of message 0x5B3. According to the spreadsheet, it's the top seven bits in byte one, so
soh = can_databuffer[1] >> 1;
For my sample message above, that's 0xBE >> 1 = 0x5F = 95, which agrees with the SOH reported by LeafSpy when I did that data capture.
BTW, SOH and Hx appear to be different, but perhaps related. I'm trying to figure that out. I suspect SOH is just the Hx value rounded, but I have some data from the Plug In America Leaf survey which contradicts that. The value in message 0x5BE doesn't have enough bits to be the higher resolution Hx.
Tom
On 5/6/14, 11:39 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too......
One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1...
which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340
If I'm not mistaken the OVMS currently reads the CAR CanBus ?
There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help?
GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure.
I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc.
So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at
http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html
It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right?
Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now...
Thanks Nigel. nigel@cherrybyte.me.uk
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark, You're too quick! I neglected the other end of the mapping. Since the car stops around 6 Gids, we should map 6 Gids to 0 ideal miles. So: case 0x5b3: // get raw Gids car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // convert Gids to percent car_SOC = (car_idealrange * 100 + 281/2) / 281; // convert Gids to EPA rated miles: 6 Gids -> 0 IM, 281 Gids -> 84 IM car_idealrange = ((car_idealrange-6) * 84 + (281-6)/2) / (281-6); break; Historically the bottom end mapping is not done when converting Gids to percent SOC. I mixed feelings about doing a better job vs. following community expectations. Since people in the community aren't doing a fixed ideal miles calculation, I think it's OK to do it the more correct way. The car_SOC calculation will be fine. All the math with be done with 16-bit ints because car_idealrange forces it. The result may be a couple of points over 100, but it will always easily fit in an unsigned char. On the EV CAN vs. Car CAN bus issue, I wasn't aware that the Car CAN isn't live during charging. That's not good! LeafSpy demonstrates that we can get everything interesting from Car CAN. Has anyone demonstrated that all interesting values are available from the EV CAN? I suppose it doesn't matter if using the Car CAN won't let OVMS monitor charging. Given all that, I have to say the EV CAN is looking like the way to go for OVMS, but we'll need to figure out how to get at least a few key things like the odometer which aren't known to exist on the EV CAN. Tom On 5/6/14, 6:23 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote: Tom, I just committed this:
index 1e17f34..2b695ec 100644 --- a/vehicle/OVMS.X/vehicle_nissanleaf.c +++ b/vehicle/OVMS.X/vehicle_nissanleaf.c @@ -92,7 +92,9 @@ BOOL vehicle_nissanleaf_poll1(void) } case 0x5b3: // Rough and kludgy - car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; + car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids + car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent + car_idealrange = (car_idealrange * 84 + 140) / 281; break; } return TRUE;
But, perhaps too simplistic (due to car_SOC being unsigned char). The car_idealrange is unsigned int, so it may be ok. What is your thinking regarding the EV bus vs CAN bus decision? Regards, Mark. On 7 May, 2014, at 9:13 am, Tom Saxton <tom@idleloop.com> wrote:
Mark,
That's exactly what I proposed with the code that converts Gids to EPA rated miles; scale 281 Gids to 84 EPA miles.
Still, Leaf nerds will want to see raw Gids, SOH, and Hx so having a way to display those sorts of values will be great.
Tom
On 5/6/14, 5:48 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
In general, I think it best to keep the original meaning of the standardised messages and values. So, 'ideal' range is some standardised measure of ideal range (based on EPA or whatever the manufacturer suggests) and 'estimated' range is based on prior driving habits (or some more realistic estimate).
For per-vehicle custom information (such as GIDs), I've been meaning to add something to allow that for some time. It is actually fairly simple - include a callback hook in the vehicle.{h,c} functions to allow the vehicle to output vehicle-specific custom data. I've been thinking we can use protocol messages '0' through '9' for this custom information, so it gets through to the Apps. The apps themselves can use a custom tab to display this in a vehicle-specific manner.
Regards, Mark.
On 7 May, 2014, at 7:16 am, Tom Saxton <tom@idleloop.com> wrote:
OVMS reports 0% SOC and sends out panicked low battery messages when it's not getting a valid SOC message from the CAN bus. I get this when I screw up the vehicle setting, which is set via the MODULE command. The first thing I'd do is make sure the vehicle type is set correctly. You can see it from the smartphone app on the Vehicle Info screen, look at the Car line. For my set up I see:
Car: 2.6.5/TR/V2
This says the car is running firmware version 2.6.5, the car type is TR (Tesla Roadster), and it's V2 hardware.
You can get the same info by texting MODULE? to the car, which returns the VehicleID, VehicleType, Units (miles or km), and the notifications setting.
For the Leaf, you should see NL as the vehicle type.
Which CAN bus OVMS reads depends on how the cable is wired. I believe the group consensus is that reading from the CAR CAN bus is the best strategy since we know LeafSpy is able to get everything from the that bus.
The code in vehicle_nissanleaf.c that decodes data from message 0x5b3 looks like it's trying to pull out the Gid values scaled down to work as a rough SOC %, but it looks like the array offsets are off by one. Dividing by 3 is a rough approximation to multiplying by 100 and dividing by 281 to get the standard conversion from Gids to percent.
case 0x5b3: // Rough and kludgy car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; break;
Here's a sample message from our Leaf:
5B3 69 BE FF FF FC DD 53 0A
When I captured that message, I was reading 221 = 0xDD Gids. Both the Leaf message decoder spreadsheet and the OVMS can_databuffer array start indexing bytes at 0, so byte zero is 0x69, byte 1 is 0xBE, etc. Using the Leaf message decoder spreadsheet, I believe the Gids calculation is: take the low bit of byte 4, shift left by 8 into 16 bits then add byte 5:
(((int)0xFC&0x01)<<8) + 0xDD = 0xDD = 221.
So I think the code to extract Gids from CAR CAN message 0x5B3 is:
(((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]
My thought is that the Gids value should be stored in car_idealrange. Like Gids, the ideal range on the Roadster is an estimate of the state of charge in absolute energy units. An ideal mile is 225.4 Wh; a Gid is 80 Wh. The UI on the Smartphone app will have to change, or Gids will have to be scaled.
I propose this:
car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent
Optionally, we could do the same thing with Gids that Tesla did to compute ideal miles. The EPA said the Roadster's range is 244 miles, so Tesla equated that with the nominal full capacity of a new Roadster battery, and thus the ideal miles was created. To do the same for the Leaf, take the EPA rating of 84 miles (after Nissan eliminated the 80% charge to get rid of the EPA's stupidity in taking the range to be the average of the 100% and 80% charge levels). After using the raw gids to compute the SOC percent, convert to EPA rated miles:
car_idealrange = (car_idealrange * 84 + 140) / 281;
We can also get the SOH value out of message 0x5B3. According to the spreadsheet, it's the top seven bits in byte one, so
soh = can_databuffer[1] >> 1;
For my sample message above, that's 0xBE >> 1 = 0x5F = 95, which agrees with the SOH reported by LeafSpy when I did that data capture.
BTW, SOH and Hx appear to be different, but perhaps related. I'm trying to figure that out. I suspect SOH is just the Hx value rounded, but I have some data from the Plug In America Leaf survey which contradicts that. The value in message 0x5BE doesn't have enough bits to be the higher resolution Hx.
Tom
On 5/6/14, 11:39 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too......
One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1... N2xZSzlMUXc#gid=0
which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340
If I'm not mistaken the OVMS currently reads the CAR CanBus ?
There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help?
GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure.
I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc.
So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at
http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html
It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right?
Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now...
Thanks Nigel. nigel@cherrybyte.me.uk
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
A few thoughts * When I tested my leaf the car shutdown at 3 GIDS - I think the exact point may depend on cell voltage. I have no idea what the > 2013 MY leaf shows as % on the dash when the car stops, it might be good to get similar to this - but the above is a great 1st pass. * The car_SOC will drop as the car ages/battery life goes down. I think ideally we'd want to offer similar feedback to the in-car display - but I'm aware this isn't on the car can, we need the other message for that * The EPA range differs by MY - a feature (like in the TR code?) may allow this to be configured. This may help with other differences too * Good point about car vs ev can when it comes to what's live. I'm used to leafdd which is on the ev can and is thus able to always display charge etc. It would be really useful, but then given that once charging stops even the ev can isn't available, any active control (heat/charge etc) is not going to be possible with ovms? * Agree on Hx etc... & custom data... the key enabler here is being able to read ev can as above -- either via picking up data from another pin, or by sw bridging * first step (only limited time) I'll build test Mark's latest commit with Tom's update * second step - understand the polling framework and try to read data from EVcan - say % charge * third step - look at cable mod & in addition to above see if I can read some data from car can Slow progress - the embedded side is new to me & limited time but hope i can help :-) Nigel. On 7 May 2014 03:15, Tom Saxton <tom@idleloop.com> wrote:
Mark,
You're too quick!
I neglected the other end of the mapping. Since the car stops around 6 Gids, we should map 6 Gids to 0 ideal miles. So:
case 0x5b3: // get raw Gids car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // convert Gids to percent car_SOC = (car_idealrange * 100 + 281/2) / 281; // convert Gids to EPA rated miles: 6 Gids -> 0 IM, 281 Gids -> 84 IM car_idealrange = ((car_idealrange-6) * 84 + (281-6)/2) / (281-6); break;
Historically the bottom end mapping is not done when converting Gids to percent SOC. I mixed feelings about doing a better job vs. following community expectations. Since people in the community aren't doing a fixed ideal miles calculation, I think it's OK to do it the more correct way.
The car_SOC calculation will be fine. All the math with be done with 16-bit ints because car_idealrange forces it. The result may be a couple of points over 100, but it will always easily fit in an unsigned char.
On the EV CAN vs. Car CAN bus issue, I wasn't aware that the Car CAN isn't live during charging. That's not good! LeafSpy demonstrates that we can get everything interesting from Car CAN. Has anyone demonstrated that all interesting values are available from the EV CAN? I suppose it doesn't matter if using the Car CAN won't let OVMS monitor charging.
Given all that, I have to say the EV CAN is looking like the way to go for OVMS, but we'll need to figure out how to get at least a few key things like the odometer which aren't known to exist on the EV CAN.
Tom
On 5/6/14, 6:23 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
I just committed this:
index 1e17f34..2b695ec 100644 --- a/vehicle/OVMS.X/vehicle_nissanleaf.c +++ b/vehicle/OVMS.X/vehicle_nissanleaf.c @@ -92,7 +92,9 @@ BOOL vehicle_nissanleaf_poll1(void) } case 0x5b3: // Rough and kludgy - car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; + car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids + car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent + car_idealrange = (car_idealrange * 84 + 140) / 281; break; } return TRUE;
But, perhaps too simplistic (due to car_SOC being unsigned char). The car_idealrange is unsigned int, so it may be ok.
What is your thinking regarding the EV bus vs CAN bus decision?
Regards, Mark.
On 7 May, 2014, at 9:13 am, Tom Saxton <tom@idleloop.com> wrote:
Mark,
That's exactly what I proposed with the code that converts Gids to EPA rated miles; scale 281 Gids to 84 EPA miles.
Still, Leaf nerds will want to see raw Gids, SOH, and Hx so having a way to display those sorts of values will be great.
Tom
On 5/6/14, 5:48 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
In general, I think it best to keep the original meaning of the standardised messages and values. So, 'ideal' range is some standardised measure of ideal range (based on EPA or whatever the manufacturer suggests) and 'estimated' range is based on prior driving habits (or some more realistic estimate).
For per-vehicle custom information (such as GIDs), I've been meaning to add something to allow that for some time. It is actually fairly simple - include a callback hook in the vehicle.{h,c} functions to allow the vehicle to output vehicle-specific custom data. I've been thinking we can use protocol messages '0' through '9' for this custom information, so it gets through to the Apps. The apps themselves can use a custom tab to display this in a vehicle-specific manner.
Regards, Mark.
On 7 May, 2014, at 7:16 am, Tom Saxton <tom@idleloop.com> wrote:
OVMS reports 0% SOC and sends out panicked low battery messages when it's not getting a valid SOC message from the CAN bus. I get this when I screw up the vehicle setting, which is set via the MODULE command. The first thing I'd do is make sure the vehicle type is set correctly. You can see it from the smartphone app on the Vehicle Info screen, look at the Car line. For my set up I see:
Car: 2.6.5/TR/V2
This says the car is running firmware version 2.6.5, the car type is TR (Tesla Roadster), and it's V2 hardware.
You can get the same info by texting MODULE? to the car, which returns the VehicleID, VehicleType, Units (miles or km), and the notifications setting.
For the Leaf, you should see NL as the vehicle type.
Which CAN bus OVMS reads depends on how the cable is wired. I believe the group consensus is that reading from the CAR CAN bus is the best strategy since we know LeafSpy is able to get everything from the that bus.
The code in vehicle_nissanleaf.c that decodes data from message 0x5b3 looks like it's trying to pull out the Gid values scaled down to work as a rough SOC %, but it looks like the array offsets are off by one. Dividing by 3 is a rough approximation to multiplying by 100 and dividing by 281 to get the standard conversion from Gids to percent.
case 0x5b3: // Rough and kludgy car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; break;
Here's a sample message from our Leaf:
5B3 69 BE FF FF FC DD 53 0A
When I captured that message, I was reading 221 = 0xDD Gids. Both the Leaf message decoder spreadsheet and the OVMS can_databuffer array start indexing bytes at 0, so byte zero is 0x69, byte 1 is 0xBE, etc. Using the Leaf message decoder spreadsheet, I believe the Gids calculation is: take the low bit of byte 4, shift left by 8 into 16 bits then add byte 5:
(((int)0xFC&0x01)<<8) + 0xDD = 0xDD = 221.
So I think the code to extract Gids from CAR CAN message 0x5B3 is:
(((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]
My thought is that the Gids value should be stored in car_idealrange. Like Gids, the ideal range on the Roadster is an estimate of the state of charge in absolute energy units. An ideal mile is 225.4 Wh; a Gid is 80 Wh. The UI on the Smartphone app will have to change, or Gids will have to be scaled.
I propose this:
car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent
Optionally, we could do the same thing with Gids that Tesla did to compute ideal miles. The EPA said the Roadster's range is 244 miles, so Tesla equated that with the nominal full capacity of a new Roadster battery, and thus the ideal miles was created. To do the same for the Leaf, take the EPA rating of 84 miles (after Nissan eliminated the 80% charge to get rid of the EPA's stupidity in taking the range to be the average of the 100% and 80% charge levels). After using the raw gids to compute the SOC percent, convert to EPA rated miles:
car_idealrange = (car_idealrange * 84 + 140) / 281;
We can also get the SOH value out of message 0x5B3. According to the spreadsheet, it's the top seven bits in byte one, so
soh = can_databuffer[1] >> 1;
For my sample message above, that's 0xBE >> 1 = 0x5F = 95, which agrees with the SOH reported by LeafSpy when I did that data capture.
BTW, SOH and Hx appear to be different, but perhaps related. I'm trying to figure that out. I suspect SOH is just the Hx value rounded, but I have some data from the Plug In America Leaf survey which contradicts that. The value in message 0x5BE doesn't have enough bits to be the higher resolution Hx.
Tom
On 5/6/14, 11:39 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too......
One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1...
which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340
If I'm not mistaken the OVMS currently reads the CAR CanBus ?
There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help?
GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure.
I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc.
So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at
http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html
It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right?
Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now...
Thanks Nigel. nigel@cherrybyte.me.uk
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- ---- Nigel Jones
Unfortunately I only had an hour tonight. I built the new hex (experimental) fine with just that small change, but ovms is now not starting properly. Perhaps I have an issue with my toolchain in some way . Error is 2 red led flashes (can't communicate with modem). Possibly related is the fact the centre pin of the GSM antenna connection fell out though it seems to have pushed in ok. I'll have to hook up the serial to debug when I get a chance another night..... On 8 May 2014 19:54, Nigel Jones <nigel@cherrybyte.me.uk> wrote:
A few thoughts
* When I tested my leaf the car shutdown at 3 GIDS - I think the exact point may depend on cell voltage. I have no idea what the > 2013 MY leaf shows as % on the dash when the car stops, it might be good to get similar to this - but the above is a great 1st pass.
* The car_SOC will drop as the car ages/battery life goes down. I think ideally we'd want to offer similar feedback to the in-car display - but I'm aware this isn't on the car can, we need the other message for that
* The EPA range differs by MY - a feature (like in the TR code?) may allow this to be configured. This may help with other differences too
* Good point about car vs ev can when it comes to what's live. I'm used to leafdd which is on the ev can and is thus able to always display charge etc. It would be really useful, but then given that once charging stops even the ev can isn't available, any active control (heat/charge etc) is not going to be possible with ovms?
* Agree on Hx etc... & custom data... the key enabler here is being able to read ev can as above -- either via picking up data from another pin, or by sw bridging
* first step (only limited time) I'll build test Mark's latest commit with Tom's update
* second step - understand the polling framework and try to read data from EVcan - say % charge
* third step - look at cable mod & in addition to above see if I can read some data from car can
Slow progress - the embedded side is new to me & limited time but hope i can help :-)
Nigel.
On 7 May 2014 03:15, Tom Saxton <tom@idleloop.com> wrote:
Mark,
You're too quick!
I neglected the other end of the mapping. Since the car stops around 6 Gids, we should map 6 Gids to 0 ideal miles. So:
case 0x5b3: // get raw Gids car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // convert Gids to percent car_SOC = (car_idealrange * 100 + 281/2) / 281; // convert Gids to EPA rated miles: 6 Gids -> 0 IM, 281 Gids -> 84 IM car_idealrange = ((car_idealrange-6) * 84 + (281-6)/2) / (281-6); break;
Historically the bottom end mapping is not done when converting Gids to percent SOC. I mixed feelings about doing a better job vs. following community expectations. Since people in the community aren't doing a fixed ideal miles calculation, I think it's OK to do it the more correct way.
The car_SOC calculation will be fine. All the math with be done with 16-bit ints because car_idealrange forces it. The result may be a couple of points over 100, but it will always easily fit in an unsigned char.
On the EV CAN vs. Car CAN bus issue, I wasn't aware that the Car CAN isn't live during charging. That's not good! LeafSpy demonstrates that we can get everything interesting from Car CAN. Has anyone demonstrated that all interesting values are available from the EV CAN? I suppose it doesn't matter if using the Car CAN won't let OVMS monitor charging.
Given all that, I have to say the EV CAN is looking like the way to go for OVMS, but we'll need to figure out how to get at least a few key things like the odometer which aren't known to exist on the EV CAN.
Tom
On 5/6/14, 6:23 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
I just committed this:
index 1e17f34..2b695ec 100644 --- a/vehicle/OVMS.X/vehicle_nissanleaf.c +++ b/vehicle/OVMS.X/vehicle_nissanleaf.c @@ -92,7 +92,9 @@ BOOL vehicle_nissanleaf_poll1(void) } case 0x5b3: // Rough and kludgy - car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; + car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids + car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent + car_idealrange = (car_idealrange * 84 + 140) / 281; break; } return TRUE;
But, perhaps too simplistic (due to car_SOC being unsigned char). The car_idealrange is unsigned int, so it may be ok.
What is your thinking regarding the EV bus vs CAN bus decision?
Regards, Mark.
On 7 May, 2014, at 9:13 am, Tom Saxton <tom@idleloop.com> wrote:
Mark,
That's exactly what I proposed with the code that converts Gids to EPA rated miles; scale 281 Gids to 84 EPA miles.
Still, Leaf nerds will want to see raw Gids, SOH, and Hx so having a way to display those sorts of values will be great.
Tom
On 5/6/14, 5:48 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
In general, I think it best to keep the original meaning of the standardised messages and values. So, 'ideal' range is some standardised measure of ideal range (based on EPA or whatever the manufacturer suggests) and 'estimated' range is based on prior driving habits (or some more realistic estimate).
For per-vehicle custom information (such as GIDs), I've been meaning to add something to allow that for some time. It is actually fairly simple - include a callback hook in the vehicle.{h,c} functions to allow the vehicle to output vehicle-specific custom data. I've been thinking we can use protocol messages '0' through '9' for this custom information, so it gets through to the Apps. The apps themselves can use a custom tab to display this in a vehicle-specific manner.
Regards, Mark.
On 7 May, 2014, at 7:16 am, Tom Saxton <tom@idleloop.com> wrote:
OVMS reports 0% SOC and sends out panicked low battery messages when it's not getting a valid SOC message from the CAN bus. I get this when I screw up the vehicle setting, which is set via the MODULE command. The first thing I'd do is make sure the vehicle type is set correctly. You can see it from the smartphone app on the Vehicle Info screen, look at the Car line. For my set up I see:
Car: 2.6.5/TR/V2
This says the car is running firmware version 2.6.5, the car type is TR (Tesla Roadster), and it's V2 hardware.
You can get the same info by texting MODULE? to the car, which returns the VehicleID, VehicleType, Units (miles or km), and the notifications setting.
For the Leaf, you should see NL as the vehicle type.
Which CAN bus OVMS reads depends on how the cable is wired. I believe the group consensus is that reading from the CAR CAN bus is the best strategy since we know LeafSpy is able to get everything from the that bus.
The code in vehicle_nissanleaf.c that decodes data from message 0x5b3 looks like it's trying to pull out the Gid values scaled down to work as a rough SOC %, but it looks like the array offsets are off by one. Dividing by 3 is a rough approximation to multiplying by 100 and dividing by 281 to get the standard conversion from Gids to percent.
case 0x5b3: // Rough and kludgy car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; break;
Here's a sample message from our Leaf:
5B3 69 BE FF FF FC DD 53 0A
When I captured that message, I was reading 221 = 0xDD Gids. Both the Leaf message decoder spreadsheet and the OVMS can_databuffer array start indexing bytes at 0, so byte zero is 0x69, byte 1 is 0xBE, etc. Using the Leaf message decoder spreadsheet, I believe the Gids calculation is: take the low bit of byte 4, shift left by 8 into 16 bits then add byte 5:
(((int)0xFC&0x01)<<8) + 0xDD = 0xDD = 221.
So I think the code to extract Gids from CAR CAN message 0x5B3 is:
(((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]
My thought is that the Gids value should be stored in car_idealrange. Like Gids, the ideal range on the Roadster is an estimate of the state of charge in absolute energy units. An ideal mile is 225.4 Wh; a Gid is 80 Wh. The UI on the Smartphone app will have to change, or Gids will have to be scaled.
I propose this:
car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent
Optionally, we could do the same thing with Gids that Tesla did to compute ideal miles. The EPA said the Roadster's range is 244 miles, so Tesla equated that with the nominal full capacity of a new Roadster battery, and thus the ideal miles was created. To do the same for the Leaf, take the EPA rating of 84 miles (after Nissan eliminated the 80% charge to get rid of the EPA's stupidity in taking the range to be the average of the 100% and 80% charge levels). After using the raw gids to compute the SOC percent, convert to EPA rated miles:
car_idealrange = (car_idealrange * 84 + 140) / 281;
We can also get the SOH value out of message 0x5B3. According to the spreadsheet, it's the top seven bits in byte one, so
soh = can_databuffer[1] >> 1;
For my sample message above, that's 0xBE >> 1 = 0x5F = 95, which agrees with the SOH reported by LeafSpy when I did that data capture.
BTW, SOH and Hx appear to be different, but perhaps related. I'm trying to figure that out. I suspect SOH is just the Hx value rounded, but I have some data from the Plug In America Leaf survey which contradicts that. The value in message 0x5BE doesn't have enough bits to be the higher resolution Hx.
Tom
On 5/6/14, 11:39 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too......
One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1...
which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340
If I'm not mistaken the OVMS currently reads the CAR CanBus ?
There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help?
GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure.
I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc.
So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at
http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html
It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right?
Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now...
Thanks Nigel. nigel@cherrybyte.me.uk
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- ---- Nigel Jones
-- ---- Nigel Jones
Hi Nigel, Some comments on your comments... When the Leaf shuts down probably depends on when the weakest battery module voltage drops below some threshold rather than on the total energy remaining in the pack. So, when it stops will vary by vehicle, conditions, and history. I believe the 6 Gids number came from Tony Williams exhaustive experimentation with early Leafs. If you're driving down to single-digit Gids, you're past the point where the car can accurately predict when it's going to stop. Basing the car_SOC on Gids will have the effect of showing smaller numbers for a full charge as the pack loses capacity. To me this is far preferable to the so-called "True SOC" that will show 100% even when the pack has lost half its capacity. Gids are available on both the Car and EV bus. The EPA range only changed significantly when Nissan removed the 80% charge option. In order for Leaf owners to be able to compare numbers between vehicles, I think it's vital that the conversion from Gids to percent and Gids to ideal miles be invariant across years and models. Ideal miles is an energy measure stated it units that are move convenient than Gids or percent. If it's to be usable as an energy unit, it has to be the same across all Leafs, and not a customizable mapping. It's great to have someone digging into the Leaf implementation of OVMS. Good luck sleuthing! Tom On 5/8/14, 11:54 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote: A few thoughts * When I tested my leaf the car shutdown at 3 GIDS - I think the exact point may depend on cell voltage. I have no idea what the > 2013 MY leaf shows as % on the dash when the car stops, it might be good to get similar to this - but the above is a great 1st pass. * The car_SOC will drop as the car ages/battery life goes down. I think ideally we'd want to offer similar feedback to the in-car display - but I'm aware this isn't on the car can, we need the other message for that * The EPA range differs by MY - a feature (like in the TR code?) may allow this to be configured. This may help with other differences too * Good point about car vs ev can when it comes to what's live. I'm used to leafdd which is on the ev can and is thus able to always display charge etc. It would be really useful, but then given that once charging stops even the ev can isn't available, any active control (heat/charge etc) is not going to be possible with ovms? * Agree on Hx etc... & custom data... the key enabler here is being able to read ev can as above -- either via picking up data from another pin, or by sw bridging * first step (only limited time) I'll build test Mark's latest commit with Tom's update * second step - understand the polling framework and try to read data from EVcan - say % charge * third step - look at cable mod & in addition to above see if I can read some data from car can Slow progress - the embedded side is new to me & limited time but hope i can help :-) Nigel. On 7 May 2014 03:15, Tom Saxton <tom@idleloop.com> wrote:
Mark,
You're too quick!
I neglected the other end of the mapping. Since the car stops around 6 Gids, we should map 6 Gids to 0 ideal miles. So:
case 0x5b3: // get raw Gids car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // convert Gids to percent car_SOC = (car_idealrange * 100 + 281/2) / 281; // convert Gids to EPA rated miles: 6 Gids -> 0 IM, 281 Gids -> 84 IM car_idealrange = ((car_idealrange-6) * 84 + (281-6)/2) / (281-6); break;
Historically the bottom end mapping is not done when converting Gids to percent SOC. I mixed feelings about doing a better job vs. following community expectations. Since people in the community aren't doing a fixed ideal miles calculation, I think it's OK to do it the more correct way.
The car_SOC calculation will be fine. All the math with be done with 16-bit ints because car_idealrange forces it. The result may be a couple of points over 100, but it will always easily fit in an unsigned char.
On the EV CAN vs. Car CAN bus issue, I wasn't aware that the Car CAN isn't live during charging. That's not good! LeafSpy demonstrates that we can get everything interesting from Car CAN. Has anyone demonstrated that all interesting values are available from the EV CAN? I suppose it doesn't matter if using the Car CAN won't let OVMS monitor charging.
Given all that, I have to say the EV CAN is looking like the way to go for OVMS, but we'll need to figure out how to get at least a few key things like the odometer which aren't known to exist on the EV CAN.
Tom
On 5/6/14, 6:23 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
I just committed this:
index 1e17f34..2b695ec 100644 --- a/vehicle/OVMS.X/vehicle_nissanleaf.c +++ b/vehicle/OVMS.X/vehicle_nissanleaf.c @@ -92,7 +92,9 @@ BOOL vehicle_nissanleaf_poll1(void) } case 0x5b3: // Rough and kludgy - car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; + car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids + car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent + car_idealrange = (car_idealrange * 84 + 140) / 281; break; } return TRUE;
But, perhaps too simplistic (due to car_SOC being unsigned char). The car_idealrange is unsigned int, so it may be ok.
What is your thinking regarding the EV bus vs CAN bus decision?
Regards, Mark.
On 7 May, 2014, at 9:13 am, Tom Saxton <tom@idleloop.com> wrote:
Mark,
That's exactly what I proposed with the code that converts Gids to EPA rated miles; scale 281 Gids to 84 EPA miles.
Still, Leaf nerds will want to see raw Gids, SOH, and Hx so having a way to display those sorts of values will be great.
Tom
On 5/6/14, 5:48 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
In general, I think it best to keep the original meaning of the standardised messages and values. So, 'ideal' range is some standardised measure of ideal range (based on EPA or whatever the manufacturer suggests) and 'estimated' range is based on prior driving habits (or some more realistic estimate).
For per-vehicle custom information (such as GIDs), I've been meaning to add something to allow that for some time. It is actually fairly simple - include a callback hook in the vehicle.{h,c} functions to allow the vehicle to output vehicle-specific custom data. I've been thinking we can use protocol messages '0' through '9' for this custom information, so it gets through to the Apps. The apps themselves can use a custom tab to display this in a vehicle-specific manner.
Regards, Mark.
On 7 May, 2014, at 7:16 am, Tom Saxton <tom@idleloop.com> wrote:
OVMS reports 0% SOC and sends out panicked low battery messages when it's not getting a valid SOC message from the CAN bus. I get this when I screw up the vehicle setting, which is set via the MODULE command. The first thing I'd do is make sure the vehicle type is set correctly. You can see it from the smartphone app on the Vehicle Info screen, look at the Car line. For my set up I see:
Car: 2.6.5/TR/V2
This says the car is running firmware version 2.6.5, the car type is TR (Tesla Roadster), and it's V2 hardware.
You can get the same info by texting MODULE? to the car, which returns the VehicleID, VehicleType, Units (miles or km), and the notifications setting.
For the Leaf, you should see NL as the vehicle type.
Which CAN bus OVMS reads depends on how the cable is wired. I believe the group consensus is that reading from the CAR CAN bus is the best strategy since we know LeafSpy is able to get everything from the that bus.
The code in vehicle_nissanleaf.c that decodes data from message 0x5b3 looks like it's trying to pull out the Gid values scaled down to work as a rough SOC %, but it looks like the array offsets are off by one. Dividing by 3 is a rough approximation to multiplying by 100 and dividing by 281 to get the standard conversion from Gids to percent.
case 0x5b3: // Rough and kludgy car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; break;
Here's a sample message from our Leaf:
5B3 69 BE FF FF FC DD 53 0A
When I captured that message, I was reading 221 = 0xDD Gids. Both the Leaf message decoder spreadsheet and the OVMS can_databuffer array start indexing bytes at 0, so byte zero is 0x69, byte 1 is 0xBE, etc. Using the Leaf message decoder spreadsheet, I believe the Gids calculation is: take the low bit of byte 4, shift left by 8 into 16 bits then add byte 5:
(((int)0xFC&0x01)<<8) + 0xDD = 0xDD = 221.
So I think the code to extract Gids from CAR CAN message 0x5B3 is:
(((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]
My thought is that the Gids value should be stored in car_idealrange. Like Gids, the ideal range on the Roadster is an estimate of the state of charge in absolute energy units. An ideal mile is 225.4 Wh; a Gid is 80 Wh. The UI on the Smartphone app will have to change, or Gids will have to be scaled.
I propose this:
car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent
Optionally, we could do the same thing with Gids that Tesla did to compute ideal miles. The EPA said the Roadster's range is 244 miles, so Tesla equated that with the nominal full capacity of a new Roadster battery, and thus the ideal miles was created. To do the same for the Leaf, take the EPA rating of 84 miles (after Nissan eliminated the 80% charge to get rid of the EPA's stupidity in taking the range to be the average of the 100% and 80% charge levels). After using the raw gids to compute the SOC percent, convert to EPA rated miles:
car_idealrange = (car_idealrange * 84 + 140) / 281;
We can also get the SOH value out of message 0x5B3. According to the spreadsheet, it's the top seven bits in byte one, so
soh = can_databuffer[1] >> 1;
For my sample message above, that's 0xBE >> 1 = 0x5F = 95, which agrees with the SOH reported by LeafSpy when I did that data capture.
BTW, SOH and Hx appear to be different, but perhaps related. I'm trying to figure that out. I suspect SOH is just the Hx value rounded, but I have some data from the Plug In America Leaf survey which contradicts that. The value in message 0x5BE doesn't have enough bits to be the higher resolution Hx.
Tom
On 5/6/14, 11:39 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too......
One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1 ON2xZSzlMUXc#gid=0
which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340
If I'm not mistaken the OVMS currently reads the CAR CanBus ?
There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help?
GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure.
I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc.
So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at
http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html
It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right?
Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now...
Thanks Nigel. nigel@cherrybyte.me.uk
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Just a quick FYI. I reconnected the OVMS this morning (with the modified code) and it's up and running. I can't check SOC as I'm in the office & not by car but it looks as if my build at least worked. That's helpful for debugging/making progress ;-) On 9 May 2014 01:26, Tom Saxton <tom@idleloop.com> wrote:
Hi Nigel,
Some comments on your comments...
When the Leaf shuts down probably depends on when the weakest battery module voltage drops below some threshold rather than on the total energy remaining in the pack. So, when it stops will vary by vehicle, conditions, and history. I believe the 6 Gids number came from Tony Williams exhaustive experimentation with early Leafs. If you're driving down to single-digit Gids, you're past the point where the car can accurately predict when it's going to stop.
Basing the car_SOC on Gids will have the effect of showing smaller numbers for a full charge as the pack loses capacity. To me this is far preferable to the so-called "True SOC" that will show 100% even when the pack has lost half its capacity. Gids are available on both the Car and EV bus.
The EPA range only changed significantly when Nissan removed the 80% charge option. In order for Leaf owners to be able to compare numbers between vehicles, I think it's vital that the conversion from Gids to percent and Gids to ideal miles be invariant across years and models. Ideal miles is an energy measure stated it units that are move convenient than Gids or percent. If it's to be usable as an energy unit, it has to be the same across all Leafs, and not a customizable mapping.
It's great to have someone digging into the Leaf implementation of OVMS. Good luck sleuthing!
Tom
On 5/8/14, 11:54 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
A few thoughts
* When I tested my leaf the car shutdown at 3 GIDS - I think the exact point may depend on cell voltage. I have no idea what the > 2013 MY leaf shows as % on the dash when the car stops, it might be good to get similar to this - but the above is a great 1st pass.
* The car_SOC will drop as the car ages/battery life goes down. I think ideally we'd want to offer similar feedback to the in-car display - but I'm aware this isn't on the car can, we need the other message for that
* The EPA range differs by MY - a feature (like in the TR code?) may allow this to be configured. This may help with other differences too
* Good point about car vs ev can when it comes to what's live. I'm used to leafdd which is on the ev can and is thus able to always display charge etc. It would be really useful, but then given that once charging stops even the ev can isn't available, any active control (heat/charge etc) is not going to be possible with ovms?
* Agree on Hx etc... & custom data... the key enabler here is being able to read ev can as above -- either via picking up data from another pin, or by sw bridging
* first step (only limited time) I'll build test Mark's latest commit with Tom's update
* second step - understand the polling framework and try to read data from EVcan - say % charge
* third step - look at cable mod & in addition to above see if I can read some data from car can
Slow progress - the embedded side is new to me & limited time but hope i can help :-)
Nigel.
On 7 May 2014 03:15, Tom Saxton <tom@idleloop.com> wrote:
Mark,
You're too quick!
I neglected the other end of the mapping. Since the car stops around 6 Gids, we should map 6 Gids to 0 ideal miles. So:
case 0x5b3: // get raw Gids car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // convert Gids to percent car_SOC = (car_idealrange * 100 + 281/2) / 281; // convert Gids to EPA rated miles: 6 Gids -> 0 IM, 281 Gids -> 84 IM car_idealrange = ((car_idealrange-6) * 84 + (281-6)/2) / (281-6); break;
Historically the bottom end mapping is not done when converting Gids to percent SOC. I mixed feelings about doing a better job vs. following community expectations. Since people in the community aren't doing a fixed ideal miles calculation, I think it's OK to do it the more correct way.
The car_SOC calculation will be fine. All the math with be done with 16-bit ints because car_idealrange forces it. The result may be a couple of points over 100, but it will always easily fit in an unsigned char.
On the EV CAN vs. Car CAN bus issue, I wasn't aware that the Car CAN isn't live during charging. That's not good! LeafSpy demonstrates that we can get everything interesting from Car CAN. Has anyone demonstrated that all interesting values are available from the EV CAN? I suppose it doesn't matter if using the Car CAN won't let OVMS monitor charging.
Given all that, I have to say the EV CAN is looking like the way to go for OVMS, but we'll need to figure out how to get at least a few key things like the odometer which aren't known to exist on the EV CAN.
Tom
On 5/6/14, 6:23 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
I just committed this:
index 1e17f34..2b695ec 100644 --- a/vehicle/OVMS.X/vehicle_nissanleaf.c +++ b/vehicle/OVMS.X/vehicle_nissanleaf.c @@ -92,7 +92,9 @@ BOOL vehicle_nissanleaf_poll1(void) } case 0x5b3: // Rough and kludgy - car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; + car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids + car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent + car_idealrange = (car_idealrange * 84 + 140) / 281; break; } return TRUE;
But, perhaps too simplistic (due to car_SOC being unsigned char). The car_idealrange is unsigned int, so it may be ok.
What is your thinking regarding the EV bus vs CAN bus decision?
Regards, Mark.
On 7 May, 2014, at 9:13 am, Tom Saxton <tom@idleloop.com> wrote:
Mark,
That's exactly what I proposed with the code that converts Gids to EPA rated miles; scale 281 Gids to 84 EPA miles.
Still, Leaf nerds will want to see raw Gids, SOH, and Hx so having a way to display those sorts of values will be great.
Tom
On 5/6/14, 5:48 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
In general, I think it best to keep the original meaning of the standardised messages and values. So, 'ideal' range is some standardised measure of ideal range (based on EPA or whatever the manufacturer suggests) and 'estimated' range is based on prior driving habits (or some more realistic estimate).
For per-vehicle custom information (such as GIDs), I've been meaning to add something to allow that for some time. It is actually fairly simple - include a callback hook in the vehicle.{h,c} functions to allow the vehicle to output vehicle-specific custom data. I've been thinking we can use protocol messages '0' through '9' for this custom information, so it gets through to the Apps. The apps themselves can use a custom tab to display this in a vehicle-specific manner.
Regards, Mark.
On 7 May, 2014, at 7:16 am, Tom Saxton <tom@idleloop.com> wrote:
OVMS reports 0% SOC and sends out panicked low battery messages when it's not getting a valid SOC message from the CAN bus. I get this when I screw up the vehicle setting, which is set via the MODULE command. The first thing I'd do is make sure the vehicle type is set correctly. You can see it from the smartphone app on the Vehicle Info screen, look at the Car line. For my set up I see:
Car: 2.6.5/TR/V2
This says the car is running firmware version 2.6.5, the car type is TR (Tesla Roadster), and it's V2 hardware.
You can get the same info by texting MODULE? to the car, which returns the VehicleID, VehicleType, Units (miles or km), and the notifications setting.
For the Leaf, you should see NL as the vehicle type.
Which CAN bus OVMS reads depends on how the cable is wired. I believe the group consensus is that reading from the CAR CAN bus is the best strategy since we know LeafSpy is able to get everything from the that bus.
The code in vehicle_nissanleaf.c that decodes data from message 0x5b3 looks like it's trying to pull out the Gid values scaled down to work as a rough SOC %, but it looks like the array offsets are off by one. Dividing by 3 is a rough approximation to multiplying by 100 and dividing by 281 to get the standard conversion from Gids to percent.
case 0x5b3: // Rough and kludgy car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; break;
Here's a sample message from our Leaf:
5B3 69 BE FF FF FC DD 53 0A
When I captured that message, I was reading 221 = 0xDD Gids. Both the Leaf message decoder spreadsheet and the OVMS can_databuffer array start indexing bytes at 0, so byte zero is 0x69, byte 1 is 0xBE, etc. Using the Leaf message decoder spreadsheet, I believe the Gids calculation is: take the low bit of byte 4, shift left by 8 into 16 bits then add byte 5:
(((int)0xFC&0x01)<<8) + 0xDD = 0xDD = 221.
So I think the code to extract Gids from CAR CAN message 0x5B3 is:
(((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]
My thought is that the Gids value should be stored in car_idealrange. Like Gids, the ideal range on the Roadster is an estimate of the state of charge in absolute energy units. An ideal mile is 225.4 Wh; a Gid is 80 Wh. The UI on the Smartphone app will have to change, or Gids will have to be scaled.
I propose this:
car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent
Optionally, we could do the same thing with Gids that Tesla did to compute ideal miles. The EPA said the Roadster's range is 244 miles, so Tesla equated that with the nominal full capacity of a new Roadster battery, and thus the ideal miles was created. To do the same for the Leaf, take the EPA rating of 84 miles (after Nissan eliminated the 80% charge to get rid of the EPA's stupidity in taking the range to be the average of the 100% and 80% charge levels). After using the raw gids to compute the SOC percent, convert to EPA rated miles:
car_idealrange = (car_idealrange * 84 + 140) / 281;
We can also get the SOH value out of message 0x5B3. According to the spreadsheet, it's the top seven bits in byte one, so
soh = can_databuffer[1] >> 1;
For my sample message above, that's 0xBE >> 1 = 0x5F = 95, which agrees with the SOH reported by LeafSpy when I did that data capture.
BTW, SOH and Hx appear to be different, but perhaps related. I'm trying to figure that out. I suspect SOH is just the Hx value rounded, but I have some data from the Plug In America Leaf survey which contradicts that. The value in message 0x5BE doesn't have enough bits to be the higher resolution Hx.
Tom
On 5/6/14, 11:39 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too......
One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1...
which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340
If I'm not mistaken the OVMS currently reads the CAR CanBus ?
There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help?
GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure.
I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc.
So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at
http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html
It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right?
Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now...
Thanks Nigel. nigel@cherrybyte.me.uk
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- ---- Nigel Jones
Tom, Nigel, What OBDII-OVMS cable are you guys using - left or right? I would like to see if they are easily modded to switch to EV CAN bus. Regards, Mark. On 9 May, 2014, at 3:55 pm, Nigel Jones <nigel@cherrybyte.me.uk> wrote:
Just a quick FYI. I reconnected the OVMS this morning (with the modified code) and it's up and running. I can't check SOC as I'm in the office & not by car but it looks as if my build at least worked. That's helpful for debugging/making progress ;-)
On 9 May 2014 01:26, Tom Saxton <tom@idleloop.com> wrote: Hi Nigel,
Some comments on your comments...
When the Leaf shuts down probably depends on when the weakest battery module voltage drops below some threshold rather than on the total energy remaining in the pack. So, when it stops will vary by vehicle, conditions, and history. I believe the 6 Gids number came from Tony Williams exhaustive experimentation with early Leafs. If you're driving down to single-digit Gids, you're past the point where the car can accurately predict when it's going to stop.
Basing the car_SOC on Gids will have the effect of showing smaller numbers for a full charge as the pack loses capacity. To me this is far preferable to the so-called "True SOC" that will show 100% even when the pack has lost half its capacity. Gids are available on both the Car and EV bus.
The EPA range only changed significantly when Nissan removed the 80% charge option. In order for Leaf owners to be able to compare numbers between vehicles, I think it's vital that the conversion from Gids to percent and Gids to ideal miles be invariant across years and models. Ideal miles is an energy measure stated it units that are move convenient than Gids or percent. If it's to be usable as an energy unit, it has to be the same across all Leafs, and not a customizable mapping.
It's great to have someone digging into the Leaf implementation of OVMS. Good luck sleuthing!
Tom
On 5/8/14, 11:54 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
A few thoughts
* When I tested my leaf the car shutdown at 3 GIDS - I think the exact point may depend on cell voltage. I have no idea what the > 2013 MY leaf shows as % on the dash when the car stops, it might be good to get similar to this - but the above is a great 1st pass.
* The car_SOC will drop as the car ages/battery life goes down. I think ideally we'd want to offer similar feedback to the in-car display - but I'm aware this isn't on the car can, we need the other message for that
* The EPA range differs by MY - a feature (like in the TR code?) may allow this to be configured. This may help with other differences too
* Good point about car vs ev can when it comes to what's live. I'm used to leafdd which is on the ev can and is thus able to always display charge etc. It would be really useful, but then given that once charging stops even the ev can isn't available, any active control (heat/charge etc) is not going to be possible with ovms?
* Agree on Hx etc... & custom data... the key enabler here is being able to read ev can as above -- either via picking up data from another pin, or by sw bridging
* first step (only limited time) I'll build test Mark's latest commit with Tom's update
* second step - understand the polling framework and try to read data from EVcan - say % charge
* third step - look at cable mod & in addition to above see if I can read some data from car can
Slow progress - the embedded side is new to me & limited time but hope i can help :-)
Nigel.
On 7 May 2014 03:15, Tom Saxton <tom@idleloop.com> wrote: Mark,
You're too quick!
I neglected the other end of the mapping. Since the car stops around 6 Gids, we should map 6 Gids to 0 ideal miles. So:
case 0x5b3: // get raw Gids car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // convert Gids to percent car_SOC = (car_idealrange * 100 + 281/2) / 281; // convert Gids to EPA rated miles: 6 Gids -> 0 IM, 281 Gids -> 84 IM car_idealrange = ((car_idealrange-6) * 84 + (281-6)/2) / (281-6); break;
Historically the bottom end mapping is not done when converting Gids to percent SOC. I mixed feelings about doing a better job vs. following community expectations. Since people in the community aren't doing a fixed ideal miles calculation, I think it's OK to do it the more correct way.
The car_SOC calculation will be fine. All the math with be done with 16-bit ints because car_idealrange forces it. The result may be a couple of points over 100, but it will always easily fit in an unsigned char.
On the EV CAN vs. Car CAN bus issue, I wasn't aware that the Car CAN isn't live during charging. That's not good! LeafSpy demonstrates that we can get everything interesting from Car CAN. Has anyone demonstrated that all interesting values are available from the EV CAN? I suppose it doesn't matter if using the Car CAN won't let OVMS monitor charging.
Given all that, I have to say the EV CAN is looking like the way to go for OVMS, but we'll need to figure out how to get at least a few key things like the odometer which aren't known to exist on the EV CAN.
Tom
On 5/6/14, 6:23 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
I just committed this:
index 1e17f34..2b695ec 100644 --- a/vehicle/OVMS.X/vehicle_nissanleaf.c +++ b/vehicle/OVMS.X/vehicle_nissanleaf.c @@ -92,7 +92,9 @@ BOOL vehicle_nissanleaf_poll1(void) } case 0x5b3: // Rough and kludgy - car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; + car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids + car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent + car_idealrange = (car_idealrange * 84 + 140) / 281; break; } return TRUE;
But, perhaps too simplistic (due to car_SOC being unsigned char). The car_idealrange is unsigned int, so it may be ok.
What is your thinking regarding the EV bus vs CAN bus decision?
Regards, Mark.
On 7 May, 2014, at 9:13 am, Tom Saxton <tom@idleloop.com> wrote:
Mark,
That's exactly what I proposed with the code that converts Gids to EPA rated miles; scale 281 Gids to 84 EPA miles.
Still, Leaf nerds will want to see raw Gids, SOH, and Hx so having a way to display those sorts of values will be great.
Tom
On 5/6/14, 5:48 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
In general, I think it best to keep the original meaning of the standardised messages and values. So, 'ideal' range is some standardised measure of ideal range (based on EPA or whatever the manufacturer suggests) and 'estimated' range is based on prior driving habits (or some more realistic estimate).
For per-vehicle custom information (such as GIDs), I've been meaning to add something to allow that for some time. It is actually fairly simple - include a callback hook in the vehicle.{h,c} functions to allow the vehicle to output vehicle-specific custom data. I've been thinking we can use protocol messages '0' through '9' for this custom information, so it gets through to the Apps. The apps themselves can use a custom tab to display this in a vehicle-specific manner.
Regards, Mark.
On 7 May, 2014, at 7:16 am, Tom Saxton <tom@idleloop.com> wrote:
OVMS reports 0% SOC and sends out panicked low battery messages when it's not getting a valid SOC message from the CAN bus. I get this when I screw up the vehicle setting, which is set via the MODULE command. The first thing I'd do is make sure the vehicle type is set correctly. You can see it from the smartphone app on the Vehicle Info screen, look at the Car line. For my set up I see:
Car: 2.6.5/TR/V2
This says the car is running firmware version 2.6.5, the car type is TR (Tesla Roadster), and it's V2 hardware.
You can get the same info by texting MODULE? to the car, which returns the VehicleID, VehicleType, Units (miles or km), and the notifications setting.
For the Leaf, you should see NL as the vehicle type.
Which CAN bus OVMS reads depends on how the cable is wired. I believe the group consensus is that reading from the CAR CAN bus is the best strategy since we know LeafSpy is able to get everything from the that bus.
The code in vehicle_nissanleaf.c that decodes data from message 0x5b3 looks like it's trying to pull out the Gid values scaled down to work as a rough SOC %, but it looks like the array offsets are off by one. Dividing by 3 is a rough approximation to multiplying by 100 and dividing by 281 to get the standard conversion from Gids to percent.
case 0x5b3: // Rough and kludgy car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; break;
Here's a sample message from our Leaf:
5B3 69 BE FF FF FC DD 53 0A
When I captured that message, I was reading 221 = 0xDD Gids. Both the Leaf message decoder spreadsheet and the OVMS can_databuffer array start indexing bytes at 0, so byte zero is 0x69, byte 1 is 0xBE, etc. Using the Leaf message decoder spreadsheet, I believe the Gids calculation is: take the low bit of byte 4, shift left by 8 into 16 bits then add byte 5:
(((int)0xFC&0x01)<<8) + 0xDD = 0xDD = 221.
So I think the code to extract Gids from CAR CAN message 0x5B3 is:
(((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]
My thought is that the Gids value should be stored in car_idealrange. Like Gids, the ideal range on the Roadster is an estimate of the state of charge in absolute energy units. An ideal mile is 225.4 Wh; a Gid is 80 Wh. The UI on the Smartphone app will have to change, or Gids will have to be scaled.
I propose this:
car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent
Optionally, we could do the same thing with Gids that Tesla did to compute ideal miles. The EPA said the Roadster's range is 244 miles, so Tesla equated that with the nominal full capacity of a new Roadster battery, and thus the ideal miles was created. To do the same for the Leaf, take the EPA rating of 84 miles (after Nissan eliminated the 80% charge to get rid of the EPA's stupidity in taking the range to be the average of the 100% and 80% charge levels). After using the raw gids to compute the SOC percent, convert to EPA rated miles:
car_idealrange = (car_idealrange * 84 + 140) / 281;
We can also get the SOH value out of message 0x5B3. According to the spreadsheet, it's the top seven bits in byte one, so
soh = can_databuffer[1] >> 1;
For my sample message above, that's 0xBE >> 1 = 0x5F = 95, which agrees with the SOH reported by LeafSpy when I did that data capture.
BTW, SOH and Hx appear to be different, but perhaps related. I'm trying to figure that out. I suspect SOH is just the Hx value rounded, but I have some data from the Plug In America Leaf survey which contradicts that. The value in message 0x5BE doesn't have enough bits to be the higher resolution Hx.
Tom
On 5/6/14, 11:39 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too......
One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1...
which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340
If I'm not mistaken the OVMS currently reads the CAR CanBus ?
There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help?
GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure.
I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc.
So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at
http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html
It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right?
Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now...
Thanks Nigel. nigel@cherrybyte.me.uk
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
This is mine Also I note that with that new message decode I'm still not seeing any battery level reported just 0. I'll try to debug when I get a chance On 9 May 2014 14:42, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom, Nigel,
What OBDII-OVMS cable are you guys using - left or right? I would like to see if they are easily modded to switch to EV CAN bus.
Regards, Mark.
On 9 May, 2014, at 3:55 pm, Nigel Jones <nigel@cherrybyte.me.uk> wrote:
Just a quick FYI. I reconnected the OVMS this morning (with the modified code) and it's up and running. I can't check SOC as I'm in the office & not by car but it looks as if my build at least worked. That's helpful for debugging/making progress ;-)
On 9 May 2014 01:26, Tom Saxton <tom@idleloop.com> wrote:
Hi Nigel,
Some comments on your comments...
When the Leaf shuts down probably depends on when the weakest battery module voltage drops below some threshold rather than on the total energy remaining in the pack. So, when it stops will vary by vehicle, conditions, and history. I believe the 6 Gids number came from Tony Williams exhaustive experimentation with early Leafs. If you're driving down to single-digit Gids, you're past the point where the car can accurately predict when it's going to stop.
Basing the car_SOC on Gids will have the effect of showing smaller numbers for a full charge as the pack loses capacity. To me this is far preferable to the so-called "True SOC" that will show 100% even when the pack has lost half its capacity. Gids are available on both the Car and EV bus.
The EPA range only changed significantly when Nissan removed the 80% charge option. In order for Leaf owners to be able to compare numbers between vehicles, I think it's vital that the conversion from Gids to percent and Gids to ideal miles be invariant across years and models. Ideal miles is an energy measure stated it units that are move convenient than Gids or percent. If it's to be usable as an energy unit, it has to be the same across all Leafs, and not a customizable mapping.
It's great to have someone digging into the Leaf implementation of OVMS. Good luck sleuthing!
Tom
On 5/8/14, 11:54 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
A few thoughts
* When I tested my leaf the car shutdown at 3 GIDS - I think the exact point may depend on cell voltage. I have no idea what the > 2013 MY leaf shows as % on the dash when the car stops, it might be good to get similar to this - but the above is a great 1st pass.
* The car_SOC will drop as the car ages/battery life goes down. I think ideally we'd want to offer similar feedback to the in-car display - but I'm aware this isn't on the car can, we need the other message for that
* The EPA range differs by MY - a feature (like in the TR code?) may allow this to be configured. This may help with other differences too
* Good point about car vs ev can when it comes to what's live. I'm used to leafdd which is on the ev can and is thus able to always display charge etc. It would be really useful, but then given that once charging stops even the ev can isn't available, any active control (heat/charge etc) is not going to be possible with ovms?
* Agree on Hx etc... & custom data... the key enabler here is being able to read ev can as above -- either via picking up data from another pin, or by sw bridging
* first step (only limited time) I'll build test Mark's latest commit with Tom's update
* second step - understand the polling framework and try to read data from EVcan - say % charge
* third step - look at cable mod & in addition to above see if I can read some data from car can
Slow progress - the embedded side is new to me & limited time but hope i can help :-)
Nigel.
On 7 May 2014 03:15, Tom Saxton <tom@idleloop.com> wrote:
Mark,
You're too quick!
I neglected the other end of the mapping. Since the car stops around 6 Gids, we should map 6 Gids to 0 ideal miles. So:
case 0x5b3: // get raw Gids car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // convert Gids to percent car_SOC = (car_idealrange * 100 + 281/2) / 281; // convert Gids to EPA rated miles: 6 Gids -> 0 IM, 281 Gids -> 84 IM car_idealrange = ((car_idealrange-6) * 84 + (281-6)/2) / (281-6); break;
Historically the bottom end mapping is not done when converting Gids to percent SOC. I mixed feelings about doing a better job vs. following community expectations. Since people in the community aren't doing a fixed ideal miles calculation, I think it's OK to do it the more correct way.
The car_SOC calculation will be fine. All the math with be done with 16-bit ints because car_idealrange forces it. The result may be a couple of points over 100, but it will always easily fit in an unsigned char.
On the EV CAN vs. Car CAN bus issue, I wasn't aware that the Car CAN isn't live during charging. That's not good! LeafSpy demonstrates that we can get everything interesting from Car CAN. Has anyone demonstrated that all interesting values are available from the EV CAN? I suppose it doesn't matter if using the Car CAN won't let OVMS monitor charging.
Given all that, I have to say the EV CAN is looking like the way to go for OVMS, but we'll need to figure out how to get at least a few key things like the odometer which aren't known to exist on the EV CAN.
Tom
On 5/6/14, 6:23 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
I just committed this:
index 1e17f34..2b695ec 100644 --- a/vehicle/OVMS.X/vehicle_nissanleaf.c +++ b/vehicle/OVMS.X/vehicle_nissanleaf.c @@ -92,7 +92,9 @@ BOOL vehicle_nissanleaf_poll1(void) } case 0x5b3: // Rough and kludgy - car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; + car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids + car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent + car_idealrange = (car_idealrange * 84 + 140) / 281; break; } return TRUE;
But, perhaps too simplistic (due to car_SOC being unsigned char). The car_idealrange is unsigned int, so it may be ok.
What is your thinking regarding the EV bus vs CAN bus decision?
Regards, Mark.
On 7 May, 2014, at 9:13 am, Tom Saxton <tom@idleloop.com> wrote:
Mark,
That's exactly what I proposed with the code that converts Gids to EPA rated miles; scale 281 Gids to 84 EPA miles.
Still, Leaf nerds will want to see raw Gids, SOH, and Hx so having a way to display those sorts of values will be great.
Tom
On 5/6/14, 5:48 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
In general, I think it best to keep the original meaning of the standardised messages and values. So, 'ideal' range is some standardised measure of ideal range (based on EPA or whatever the manufacturer suggests) and 'estimated' range is based on prior driving habits (or some more realistic estimate).
For per-vehicle custom information (such as GIDs), I've been meaning to add something to allow that for some time. It is actually fairly simple - include a callback hook in the vehicle.{h,c} functions to allow the vehicle to output vehicle-specific custom data. I've been thinking we can use protocol messages '0' through '9' for this custom information, so it gets through to the Apps. The apps themselves can use a custom tab to display this in a vehicle-specific manner.
Regards, Mark.
On 7 May, 2014, at 7:16 am, Tom Saxton <tom@idleloop.com> wrote:
OVMS reports 0% SOC and sends out panicked low battery messages when it's not getting a valid SOC message from the CAN bus. I get this when I screw up the vehicle setting, which is set via the MODULE command. The first thing I'd do is make sure the vehicle type is set correctly. You can see it from the smartphone app on the Vehicle Info screen, look at the Car line. For my set up I see:
Car: 2.6.5/TR/V2
This says the car is running firmware version 2.6.5, the car type is TR (Tesla Roadster), and it's V2 hardware.
You can get the same info by texting MODULE? to the car, which returns the VehicleID, VehicleType, Units (miles or km), and the notifications setting.
For the Leaf, you should see NL as the vehicle type.
Which CAN bus OVMS reads depends on how the cable is wired. I believe the group consensus is that reading from the CAR CAN bus is the best strategy since we know LeafSpy is able to get everything from the that bus.
The code in vehicle_nissanleaf.c that decodes data from message 0x5b3 looks like it's trying to pull out the Gid values scaled down to work as a rough SOC %, but it looks like the array offsets are off by one. Dividing by 3 is a rough approximation to multiplying by 100 and dividing by 281 to get the standard conversion from Gids to percent.
case 0x5b3: // Rough and kludgy car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; break;
Here's a sample message from our Leaf:
5B3 69 BE FF FF FC DD 53 0A
When I captured that message, I was reading 221 = 0xDD Gids. Both the Leaf message decoder spreadsheet and the OVMS can_databuffer array start indexing bytes at 0, so byte zero is 0x69, byte 1 is 0xBE, etc. Using the Leaf message decoder spreadsheet, I believe the Gids calculation is: take the low bit of byte 4, shift left by 8 into 16 bits then add byte 5:
(((int)0xFC&0x01)<<8) + 0xDD = 0xDD = 221.
So I think the code to extract Gids from CAR CAN message 0x5B3 is:
(((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]
My thought is that the Gids value should be stored in car_idealrange. Like Gids, the ideal range on the Roadster is an estimate of the state of charge in absolute energy units. An ideal mile is 225.4 Wh; a Gid is 80 Wh. The UI on the Smartphone app will have to change, or Gids will have to be scaled.
I propose this:
car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent
Optionally, we could do the same thing with Gids that Tesla did to compute ideal miles. The EPA said the Roadster's range is 244 miles, so Tesla equated that with the nominal full capacity of a new Roadster battery, and thus the ideal miles was created. To do the same for the Leaf, take the EPA rating of 84 miles (after Nissan eliminated the 80% charge to get rid of the EPA's stupidity in taking the range to be the average of the 100% and 80% charge levels). After using the raw gids to compute the SOC percent, convert to EPA rated miles:
car_idealrange = (car_idealrange * 84 + 140) / 281;
We can also get the SOH value out of message 0x5B3. According to the spreadsheet, it's the top seven bits in byte one, so
soh = can_databuffer[1] >> 1;
For my sample message above, that's 0xBE >> 1 = 0x5F = 95, which agrees with the SOH reported by LeafSpy when I did that data capture.
BTW, SOH and Hx appear to be different, but perhaps related. I'm trying to figure that out. I suspect SOH is just the Hx value rounded, but I have some data from the Plug In America Leaf survey which contradicts that. The value in message 0x5BE doesn't have enough bits to be the higher resolution Hx.
Tom
On 5/6/14, 11:39 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too......
One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1...
which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340
If I'm not mistaken the OVMS currently reads the CAR CanBus ?
There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help?
GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure.
I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc.
So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at
http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html
It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right?
Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now...
Thanks Nigel. nigel@cherrybyte.me.uk
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark, I have this cable with connects the CAR CAN to the Sparkfun board. Sadly, the pin-out on the DB9 end isn't compatible with the OVMS. https://www.sparkfun.com/products/10087 It's a straight cable, which I've been connecting via a this Y-cable: http://www.amazon.com/gp/product/B00EEDOWU8/ The Y-cable points to the left when plugged into the car, which is the orientation that works best for the Gary Giddings SOC meter we run in the Leaf. Tom On 5/9/14, 6:42 AM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote: Tom, Nigel, What OBDII-OVMS cable are you guys using - left or right? I would like to see if they are easily modded to switch to EV CAN bus. Regards, Mark. On 9 May, 2014, at 3:55 pm, Nigel Jones <nigel@cherrybyte.me.uk> wrote:
Just a quick FYI. I reconnected the OVMS this morning (with the modified code) and it's up and running. I can't check SOC as I'm in the office & not by car but it looks as if my build at least worked. That's helpful for debugging/making progress ;-)
On 9 May 2014 01:26, Tom Saxton <tom@idleloop.com> wrote:
Hi Nigel,
Some comments on your comments...
When the Leaf shuts down probably depends on when the weakest battery module voltage drops below some threshold rather than on the total energy remaining in the pack. So, when it stops will vary by vehicle, conditions, and history. I believe the 6 Gids number came from Tony Williams exhaustive experimentation with early Leafs. If you're driving down to single-digit Gids, you're past the point where the car can accurately predict when it's going to stop.
Basing the car_SOC on Gids will have the effect of showing smaller numbers for a full charge as the pack loses capacity. To me this is far preferable to the so-called "True SOC" that will show 100% even when the pack has lost half its capacity. Gids are available on both the Car and EV bus.
The EPA range only changed significantly when Nissan removed the 80% charge option. In order for Leaf owners to be able to compare numbers between vehicles, I think it's vital that the conversion from Gids to percent and Gids to ideal miles be invariant across years and models. Ideal miles is an energy measure stated it units that are move convenient than Gids or percent. If it's to be usable as an energy unit, it has to be the same across all Leafs, and not a customizable mapping.
It's great to have someone digging into the Leaf implementation of OVMS. Good luck sleuthing!
Tom
On 5/8/14, 11:54 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
A few thoughts
* When I tested my leaf the car shutdown at 3 GIDS - I think the exact point may depend on cell voltage. I have no idea what the > 2013 MY leaf shows as % on the dash when the car stops, it might be good to get similar to this - but the above is a great 1st pass.
* The car_SOC will drop as the car ages/battery life goes down. I think ideally we'd want to offer similar feedback to the in-car display - but I'm aware this isn't on the car can, we need the other message for that
* The EPA range differs by MY - a feature (like in the TR code?) may allow this to be configured. This may help with other differences too
* Good point about car vs ev can when it comes to what's live. I'm used to leafdd which is on the ev can and is thus able to always display charge etc. It would be really useful, but then given that once charging stops even the ev can isn't available, any active control (heat/charge etc) is not going to be possible with ovms?
* Agree on Hx etc... & custom data... the key enabler here is being able to read ev can as above -- either via picking up data from another pin, or by sw bridging
* first step (only limited time) I'll build test Mark's latest commit with Tom's update
* second step - understand the polling framework and try to read data from EVcan - say % charge
* third step - look at cable mod & in addition to above see if I can read some data from car can
Slow progress - the embedded side is new to me & limited time but hope i can help :-)
Nigel.
On 7 May 2014 03:15, Tom Saxton <tom@idleloop.com> wrote:
Mark,
You're too quick!
I neglected the other end of the mapping. Since the car stops around 6 Gids, we should map 6 Gids to 0 ideal miles. So:
case 0x5b3: // get raw Gids car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // convert Gids to percent car_SOC = (car_idealrange * 100 + 281/2) / 281; // convert Gids to EPA rated miles: 6 Gids -> 0 IM, 281 Gids -> 84 IM car_idealrange = ((car_idealrange-6) * 84 + (281-6)/2) / (281-6); break;
Historically the bottom end mapping is not done when converting Gids to percent SOC. I mixed feelings about doing a better job vs. following community expectations. Since people in the community aren't doing a fixed ideal miles calculation, I think it's OK to do it the more correct way.
The car_SOC calculation will be fine. All the math with be done with 16-bit ints because car_idealrange forces it. The result may be a couple of points over 100, but it will always easily fit in an unsigned char.
On the EV CAN vs. Car CAN bus issue, I wasn't aware that the Car CAN isn't live during charging. That's not good! LeafSpy demonstrates that we can get everything interesting from Car CAN. Has anyone demonstrated that all interesting values are available from the EV CAN? I suppose it doesn't matter if using the Car CAN won't let OVMS monitor charging.
Given all that, I have to say the EV CAN is looking like the way to go for OVMS, but we'll need to figure out how to get at least a few key things like the odometer which aren't known to exist on the EV CAN.
Tom
On 5/6/14, 6:23 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
I just committed this:
index 1e17f34..2b695ec 100644 --- a/vehicle/OVMS.X/vehicle_nissanleaf.c +++ b/vehicle/OVMS.X/vehicle_nissanleaf.c @@ -92,7 +92,9 @@ BOOL vehicle_nissanleaf_poll1(void) } case 0x5b3: // Rough and kludgy - car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; + car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids + car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent + car_idealrange = (car_idealrange * 84 + 140) / 281; break; } return TRUE;
But, perhaps too simplistic (due to car_SOC being unsigned char). The car_idealrange is unsigned int, so it may be ok.
What is your thinking regarding the EV bus vs CAN bus decision?
Regards, Mark.
On 7 May, 2014, at 9:13 am, Tom Saxton <tom@idleloop.com> wrote:
Mark,
That's exactly what I proposed with the code that converts Gids to EPA rated miles; scale 281 Gids to 84 EPA miles.
Still, Leaf nerds will want to see raw Gids, SOH, and Hx so having a way to display those sorts of values will be great.
Tom
On 5/6/14, 5:48 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
Tom,
In general, I think it best to keep the original meaning of the standardised messages and values. So, 'ideal' range is some standardised measure of ideal range (based on EPA or whatever the manufacturer suggests) and 'estimated' range is based on prior driving habits (or some more realistic estimate).
For per-vehicle custom information (such as GIDs), I've been meaning to add something to allow that for some time. It is actually fairly simple - include a callback hook in the vehicle.{h,c} functions to allow the vehicle to output vehicle-specific custom data. I've been thinking we can use protocol messages '0' through '9' for this custom information, so it gets through to the Apps. The apps themselves can use a custom tab to display this in a vehicle-specific manner.
Regards, Mark.
On 7 May, 2014, at 7:16 am, Tom Saxton <tom@idleloop.com> wrote:
OVMS reports 0% SOC and sends out panicked low battery messages when it's not getting a valid SOC message from the CAN bus. I get this when I screw up the vehicle setting, which is set via the MODULE command. The first thing I'd do is make sure the vehicle type is set correctly. You can see it from the smartphone app on the Vehicle Info screen, look at the Car line. For my set up I see:
Car: 2.6.5/TR/V2
This says the car is running firmware version 2.6.5, the car type is TR (Tesla Roadster), and it's V2 hardware.
You can get the same info by texting MODULE? to the car, which returns the VehicleID, VehicleType, Units (miles or km), and the notifications setting.
For the Leaf, you should see NL as the vehicle type.
Which CAN bus OVMS reads depends on how the cable is wired. I believe the group consensus is that reading from the CAR CAN bus is the best strategy since we know LeafSpy is able to get everything from the that bus.
The code in vehicle_nissanleaf.c that decodes data from message 0x5b3 looks like it's trying to pull out the Gid values scaled down to work as a rough SOC %, but it looks like the array offsets are off by one. Dividing by 3 is a rough approximation to multiplying by 100 and dividing by 281 to get the standard conversion from Gids to percent.
case 0x5b3: // Rough and kludgy car_SOC = ((((int)can_databuffer[5]&0x01)<<1) + ((int)can_databuffer[6])) / 3; break;
Here's a sample message from our Leaf:
5B3 69 BE FF FF FC DD 53 0A
When I captured that message, I was reading 221 = 0xDD Gids. Both the Leaf message decoder spreadsheet and the OVMS can_databuffer array start indexing bytes at 0, so byte zero is 0x69, byte 1 is 0xBE, etc. Using the Leaf message decoder spreadsheet, I believe the Gids calculation is: take the low bit of byte 4, shift left by 8 into 16 bits then add byte 5:
(((int)0xFC&0x01)<<8) + 0xDD = 0xDD = 221.
So I think the code to extract Gids from CAR CAN message 0x5B3 is:
(((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]
My thought is that the Gids value should be stored in car_idealrange. Like Gids, the ideal range on the Roadster is an estimate of the state of charge in absolute energy units. An ideal mile is 225.4 Wh; a Gid is 80 Wh. The UI on the Smartphone app will have to change, or Gids will have to be scaled.
I propose this:
car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]; // raw Gids car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to percent
Optionally, we could do the same thing with Gids that Tesla did to compute ideal miles. The EPA said the Roadster's range is 244 miles, so Tesla equated that with the nominal full capacity of a new Roadster battery, and thus the ideal miles was created. To do the same for the Leaf, take the EPA rating of 84 miles (after Nissan eliminated the 80% charge to get rid of the EPA's stupidity in taking the range to be the average of the 100% and 80% charge levels). After using the raw gids to compute the SOC percent, convert to EPA rated miles:
car_idealrange = (car_idealrange * 84 + 140) / 281;
We can also get the SOH value out of message 0x5B3. According to the spreadsheet, it's the top seven bits in byte one, so
soh = can_databuffer[1] >> 1;
For my sample message above, that's 0xBE >> 1 = 0x5F = 95, which agrees with the SOH reported by LeafSpy when I did that data capture.
BTW, SOH and Hx appear to be different, but perhaps related. I'm trying to figure that out. I suspect SOH is just the Hx value rounded, but I have some data from the Plug In America Leaf survey which contradicts that. The value in message 0x5BE doesn't have enough bits to be the higher resolution Hx.
Tom
On 5/6/14, 11:39 AM, "Nigel Jones" <nigel@cherrybyte.me.uk> wrote:
I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too......
One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQM y1ON2xZSzlMUXc#gid=0
which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340
If I'm not mistaken the OVMS currently reads the CAR CanBus ?
There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help?
GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure.
I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc.
So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at
http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html
It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right?
Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now...
Thanks Nigel. nigel@cherrybyte.me.uk
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsd ev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list
OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsde>>>> v
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Nigel, Regarding the polling framework, sorry this is very new and there is zero documentation. Implementation is in vehicle.{h,c}. Have a look at vehicle_obdii.c for an example implementation. The idea is that vehicle_poll_setpidlist() is used to set the table of PIDs to be polled, vehicle_poll_setstate() is used to set the state, and vehicle_fn_poll0() is used to receive the PID values coming back. The other vehicle_fn_poll1() function can be used for general listen-only can bus messages. The CAN bus rx filters for poll0() should be setup to receive the responses from the polled modules (the example in vehicle_obdii.c illustrates this for standard OBDII responses). The table of PIDs to be polled is based on the vehicle_pid_t structure. It is stored in ROM and contains the CAN module ID, poll type, PID to be polled, and a sub-array of three poll times (for each of the three states). The states can be used for whatever is required (I suggest something like: 0=vehicle off, 1=charging, 2=driving), and setting a poll time to 0 for that state will disable polling of a particular PID. The poll type is designed to recognise different ways of polling for PID. We currently have listed VEHICLE_POLL_TYPE_OBDIICURRENT normal OBDII over CAN), VEHICLE_POLL_TYPE_OBDIIVEHICLE (for polling things like VIN over OBDII), VEHICLE_POLL_TYPE_OBDIIGROUP (for Nissan Leaf - currently just a stub implementation) and VEHICLE_POLL_TYPE_OBDIIEXTENDED (0x22 as used in Volt/Ampera). Regards, Mark. On 7 May, 2014, at 2:39 am, Nigel Jones <nigel@cherrybyte.me.uk> wrote:
I have the OVMS module running in my car so found an hour tonight to start looking through the source - sorry it's taking a while to catch up, so forgive the newbie questions too......
One thing I noticed is that I'm getting a 0% state of charge indication, and regular texts saying my battery is low (for testing I setup the sim with unlimited texts.....). I see there was a commit last year which used some of the data from the spreadsheet at
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1...
which I found references from the nissan leaf forum discussion at http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340
If I'm not mistaken the OVMS currently reads the CAR CanBus ?
There's an indication in the spreadsheet that CAN message 0x5b3 contains SOC information - but in fact the spreadsheet refers to it as SOH. I have a leafDD and I think this is also known as the Hx figure -- ie it seems to vary with battery age/capacity -- mine for example is down to around 82%, but it is not current state of charge, so I don't think decoding that will help?
GIDs are what I use in daily driving as they are absolute. The sheet suggests that figure might be retrievable from this message, but then most people would only see a % of 95% for example as life is lost? Is that's what's wanted? I suspect not for the overall SOC figure.
I can't see much else decoded yet (I was looking for low hanging fruit!) on the CAR canbus - instead most work was done on the EV canbus, including looking at state of charge etc.
So the question comes how to bridge the data from that bus onto the CAR can. There was reference to this previously on the list at
http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html
It would appear the way to get any of the EV can data is to actively request the data. I can see examples of CAN data requests in the tesla module but haven't yet figured how I might for example retrieve CAN msg 0x5bb for example (it's one of the ones to try). I can also see the developers guide p24 which refers to writing on the bus. I'm also wary of the need to be careful in making active requests rather than the easier passive monitoring! Can anyone point me to an example of how I might do this? I'd make that call from the ticker functions? and then handle it in the poll right?
Apologies if this is all covered in the nissan leaf forum thread - I have 39 pages to read now...
Thanks Nigel. nigel@cherrybyte.me.uk
-- ---- Nigel Jones _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (4)
-
Jeremy Whaling -
Mark Webb-Johnson -
Nigel Jones -
Tom Saxton