Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively: Speed Headlight status Park / Drive status SOC I’ve also pushed this to github (along with a large number of other small changes). The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses. Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all. Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically: Car idle Car plugged in and charge started Car charging Charge interrupted Driving Driving as close to a constant speed of 10 kph as possible Driving as close to a constant speed of 20 kph as possible Driving as close to a constant speed of 30 kph as possible Car parked, but on Car parked, coming out of park into drive gear Car stopped, coming out of drive gear into park Car in park gear, then handbrake applied For each of those, both with and without a T connector and LeafSpy running would be helpful. I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough. If anyone can help with the above, please let me know. Regards, Mark.
Hi Mark, Great news and thanks for tackling it even though it was hard work. So in summary there is testing of first build - Nikki do you want to do this ? getting logs without T connector - Rob to do with T connector - Rob once got a connector Which T connector would you recommend ? Regards, Rob ---- On Tue, 17 Dec 2013 15:16:04 +0100 Mark Webb-Johnson<mark@webb-johnson.net> wrote ---- Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively: Speed Headlight status Park / Drive status SOC I’ve also pushed this to github (along with a large number of other small changes). The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses. Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all. Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically: Car idle Car plugged in and charge started Car charging Charge interrupted Driving Driving as close to a constant speed of 10 kph as possible Driving as close to a constant speed of 20 kph as possible Driving as close to a constant speed of 30 kph as possible Car parked, but on Car parked, coming out of park into drive gear Car stopped, coming out of drive gear into park Car in park gear, then handbrake applied For each of those, both with and without a T connector and LeafSpy running would be helpful. I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough. If anyone can help with the above, please let me know. Regards, Mark. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Robert, Something like one of these: http://m.ebay.co.uk/sch/i.html?kw=Obdii+y+cable&isNewKw=1&pgn=1&epp=24&mfs=G... http://www.amazon.co.uk/gp/aw/s/ref=is_box_?k=Obdii+y+cable Something to plug into the car obdii then give you two sockets - one for the logger and the other for leafspy. Regards, Mark P.S. Probably best to give me 1 log file first, to make sure everything is ok.
On 17 Dec, 2013, at 10:42 pm, Robert Sharpe <robert.sharpe@evergreen-consulting.co.uk> wrote:
Hi Mark,
Great news and thanks for tackling it even though it was hard work.
So in summary there is testing of first build - Nikki do you want to do this ? getting logs without T connector - Rob to do with T connector - Rob once got a connector Which T connector would you recommend ?
Regards, Rob
---- On Tue, 17 Dec 2013 15:16:04 +0100 Mark Webb-Johnson<mark@webb-johnson.net> wrote ----
Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively:
Speed Headlight status Park / Drive status SOC
I’ve also pushed this to github (along with a large number of other small changes).
The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses.
Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all.
Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically:
Car idle Car plugged in and charge started Car charging Charge interrupted Driving Driving as close to a constant speed of 10 kph as possible Driving as close to a constant speed of 20 kph as possible Driving as close to a constant speed of 30 kph as possible Car parked, but on Car parked, coming out of park into drive gear Car stopped, coming out of drive gear into park Car in park gear, then handbrake applied
For each of those, both with and without a T connector and LeafSpy running would be helpful.
I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough.
If anyone can help with the above, please let me know.
Regards, Mark.
_______________________________________________ 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
HI Mark, That’s great. Thanks. I’ll put this in the car later today. Are we using NL for the Vehicle Type? Nikki. On 17 Dec 2013, at 14:16, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively:
Speed Headlight status Park / Drive status SOC
I’ve also pushed this to github (along with a large number of other small changes).
The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses.
Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all.
Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically:
Car idle Car plugged in and charge started Car charging Charge interrupted Driving Driving as close to a constant speed of 10 kph as possible Driving as close to a constant speed of 20 kph as possible Driving as close to a constant speed of 30 kph as possible Car parked, but on Car parked, coming out of park into drive gear Car stopped, coming out of drive gear into park Car in park gear, then handbrake applied
For each of those, both with and without a T connector and LeafSpy running would be helpful.
I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough.
If anyone can help with the above, please let me know.
Regards, Mark.
<OVMS.X.production.zip> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Okay guys. I’ve done a couple of quick tests with the new beta software. First up, it installs (Which is good, of course) Second up: I was able to drive around the block and see some SOC reports. What did appear to happen is that SOC dropped and then went back up again. I had values from 27% SOC down to 14% SOC to Empty and back up to 22% SOC. I’d guesstimate my real SOC was nearer 45%. (Although I didn’t check with LEAFSpy) Of course, I need to check the other bits and bobs too — Park/Drive status seems to work with the car on — but with the module rebooted, it forgets what was previously on. This is a problem I believe with the LEAF CAN bus, which turns itself off when parked. I’m guessing we’ll need to figure out a way to wake up CAN and then switch back off again? (That said,I think it’s supposed to stay on when charging… and I’m currently charging) I’ll play a little more tomorrow and throughout the rest of the week. I’ll also try and get some decent logs if I can. Nikki. On 17 Dec 2013, at 14:16, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively:
Speed Headlight status Park / Drive status SOC
I’ve also pushed this to github (along with a large number of other small changes).
The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses.
Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all.
Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically:
Car idle Car plugged in and charge started Car charging Charge interrupted Driving Driving as close to a constant speed of 10 kph as possible Driving as close to a constant speed of 20 kph as possible Driving as close to a constant speed of 30 kph as possible Car parked, but on Car parked, coming out of park into drive gear Car stopped, coming out of drive gear into park Car in park gear, then handbrake applied
For each of those, both with and without a T connector and LeafSpy running would be helpful.
I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough.
If anyone can help with the above, please let me know.
Regards, Mark.
<OVMS.X.production.zip> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
So here’s what I’ve learned from the alpha code so far… 1) It’s recording the parking status accurately, as far as I can tell. within a few minutes of parking, it’s noting that on the app screen. 2) It’s certainly sending me alerts as you might expect for low SOC warnings. 3) But sadly SOC isn’t working correctly with my car. For some reason, SOC is jumping all over the shop, with 22% SOC seemingly a favourite place for the OVMS code. On my quick trip just now to the shops, I noted it went from 76% SOC (which I think was fairly accurate given the number of bars I had) down to 22% when I parked up. Coming back, I got no update and ended up having to do a hard reboot to get the system to wake up. I haven’t been able to get any logs yet because I don’t have a splitter for the ODBII system. I’ll get that sorted later this week/early next. Nikki. On 17 Dec 2013, at 20:06, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
Okay guys.
I’ve done a couple of quick tests with the new beta software.
First up, it installs (Which is good, of course) Second up: I was able to drive around the block and see some SOC reports. What did appear to happen is that SOC dropped and then went back up again. I had values from 27% SOC down to 14% SOC to Empty and back up to 22% SOC. I’d guesstimate my real SOC was nearer 45%. (Although I didn’t check with LEAFSpy)
Of course, I need to check the other bits and bobs too — Park/Drive status seems to work with the car on — but with the module rebooted, it forgets what was previously on. This is a problem I believe with the LEAF CAN bus, which turns itself off when parked. I’m guessing we’ll need to figure out a way to wake up CAN and then switch back off again? (That said,I think it’s supposed to stay on when charging… and I’m currently charging)
I’ll play a little more tomorrow and throughout the rest of the week. I’ll also try and get some decent logs if I can.
Nikki.
On 17 Dec 2013, at 14:16, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively:
Speed Headlight status Park / Drive status SOC
I’ve also pushed this to github (along with a large number of other small changes).
The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses.
Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all.
Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically:
Car idle Car plugged in and charge started Car charging Charge interrupted Driving Driving as close to a constant speed of 10 kph as possible Driving as close to a constant speed of 20 kph as possible Driving as close to a constant speed of 30 kph as possible Car parked, but on Car parked, coming out of park into drive gear Car stopped, coming out of drive gear into park Car in park gear, then handbrake applied
For each of those, both with and without a T connector and LeafSpy running would be helpful.
I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough.
If anyone can help with the above, please let me know.
Regards, Mark.
<OVMS.X.production.zip> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Nikki, Thanks for this. Firstly, I'm glad the firmware is connecting back to the server ok. I broke that a few months ago (this new module meant I had to reorganise some low-level crypto stuff to make room), and am glad it is fixed again. For the SOC, I'm really just guessing. Supposedly message 0x5b3 on car can bus has GIDs in B6bit0 and B7 - I just divided that by 3 to get a rough approximation of SOC, but it is obviously not working. I think this one shouldn't be too hard, but I don't have any CAN bus dumps of what the 0x5b3 message looks like. If I can see a dump, with matching known SOC / GIDs, then I am sure we can get this right. That said, active polling (which is what leafspy uses) seems to be a better way of getting this, as it gets us true GIDs off the EV can bus. Glad about the parking indicator. I work off the parking brake for that one, and it is an important status flag for quite a few things. I'm working on the polling mechanism at the moment. It is very similar to the OBDII VIN number polling mechanism we already have, and my recent work on the common vehicle.{h,c} polling code should make this relatively easy. Regards, Mark. On 18 Dec, 2013, at 6:22 am, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
So here’s what I’ve learned from the alpha code so far…
1) It’s recording the parking status accurately, as far as I can tell. within a few minutes of parking, it’s noting that on the app screen.
2) It’s certainly sending me alerts as you might expect for low SOC warnings.
3) But sadly SOC isn’t working correctly with my car. For some reason, SOC is jumping all over the shop, with 22% SOC seemingly a favourite place for the OVMS code. On my quick trip just now to the shops, I noted it went from 76% SOC (which I think was fairly accurate given the number of bars I had) down to 22% when I parked up.
Coming back, I got no update and ended up having to do a hard reboot to get the system to wake up.
I haven’t been able to get any logs yet because I don’t have a splitter for the ODBII system. I’ll get that sorted later this week/early next.
Nikki.
On 17 Dec 2013, at 20:06, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
Okay guys.
I’ve done a couple of quick tests with the new beta software.
First up, it installs (Which is good, of course) Second up: I was able to drive around the block and see some SOC reports. What did appear to happen is that SOC dropped and then went back up again. I had values from 27% SOC down to 14% SOC to Empty and back up to 22% SOC. I’d guesstimate my real SOC was nearer 45%. (Although I didn’t check with LEAFSpy)
Of course, I need to check the other bits and bobs too — Park/Drive status seems to work with the car on — but with the module rebooted, it forgets what was previously on. This is a problem I believe with the LEAF CAN bus, which turns itself off when parked. I’m guessing we’ll need to figure out a way to wake up CAN and then switch back off again? (That said,I think it’s supposed to stay on when charging… and I’m currently charging)
I’ll play a little more tomorrow and throughout the rest of the week. I’ll also try and get some decent logs if I can.
Nikki.
On 17 Dec 2013, at 14:16, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively:
Speed Headlight status Park / Drive status SOC
I’ve also pushed this to github (along with a large number of other small changes).
The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses.
Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all.
Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically:
Car idle Car plugged in and charge started Car charging Charge interrupted Driving Driving as close to a constant speed of 10 kph as possible Driving as close to a constant speed of 20 kph as possible Driving as close to a constant speed of 30 kph as possible Car parked, but on Car parked, coming out of park into drive gear Car stopped, coming out of drive gear into park Car in park gear, then handbrake applied
For each of those, both with and without a T connector and LeafSpy running would be helpful.
I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough.
If anyone can help with the above, please let me know.
Regards, Mark.
<OVMS.X.production.zip> _______________________________________________ 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
I posted this in the LEAF CANbus decoding thread on mynissanleaf.com, but I should probably let you folks know the bad news too... Sadly, there is no "magic" CAN bus command to wake up the VCM or the rest of the leaf. The telematics module (as well as the on board charger) wake up the VCM over dedicated logic lines when the car is off to start charging/climate/request SOC. This is according to the service manual. The OVMS module will have to do the same in order to get SOC or any other parameter out of the leaf if it is not on. Note that the EV can bus is alive (along with the VCM) during charging but the CAR can bus is quiet. There is a relay that will cycle if you do requests on the car can bus during charging, and is seen as undesired. Conversely, the CAR can bus can be active if you're in accessory mode (or just unlocking the doors) but the EV bus is quiet until the car is started. Doe the OVMS module have any sort of external logic besides the CAN transceiver? Something will be needed in order to duplicate the logic that wakes the VCM up. We will also have to probe these logic lines during a remote request to see what sort of voltage/logic is used (I didn't see any details stated in the service manual). On Tue, Dec 17, 2013 at 4:57 PM, Mark Webb-Johnson <mark@webb-johnson.net>wrote:
Nikki,
Thanks for this.
Firstly, I'm glad the firmware is connecting back to the server ok. I broke that a few months ago (this new module meant I had to reorganise some low-level crypto stuff to make room), and am glad it is fixed again.
For the SOC, I'm really just guessing. Supposedly message 0x5b3 on car can bus has GIDs in B6bit0 and B7 - I just divided that by 3 to get a rough approximation of SOC, but it is obviously not working. I think this one shouldn't be too hard, but I don't have any CAN bus dumps of what the 0x5b3 message looks like. If I can see a dump, with matching known SOC / GIDs, then I am sure we can get this right. That said, active polling (which is what leafspy uses) seems to be a better way of getting this, as it gets us true GIDs off the EV can bus.
Glad about the parking indicator. I work off the parking brake for that one, and it is an important status flag for quite a few things.
I'm working on the polling mechanism at the moment. It is very similar to the OBDII VIN number polling mechanism we already have, and my recent work on the common vehicle.{h,c} polling code should make this relatively easy.
Regards, Mark.
On 18 Dec, 2013, at 6:22 am, Nikki Gordon-Bloomfield < nikki@aminorjourney.com> wrote:
So here’s what I’ve learned from the alpha code so far…
1) It’s recording the parking status accurately, as far as I can tell. within a few minutes of parking, it’s noting that on the app screen.
2) It’s certainly sending me alerts as you might expect for low SOC warnings.
3) But sadly SOC isn’t working correctly with my car. For some reason, SOC is jumping all over the shop, with 22% SOC seemingly a favourite place for the OVMS code. On my quick trip just now to the shops, I noted it went from 76% SOC (which I think was fairly accurate given the number of bars I had) down to 22% when I parked up.
Coming back, I got no update and ended up having to do a hard reboot to get the system to wake up.
I haven’t been able to get any logs yet because I don’t have a splitter for the ODBII system. I’ll get that sorted later this week/early next.
Nikki.
On 17 Dec 2013, at 20:06, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
Okay guys.
I’ve done a couple of quick tests with the new beta software.
First up, it installs (Which is good, of course) Second up: I was able to drive around the block and see some SOC reports. What did appear to happen is that SOC dropped and then went back up again. I had values from 27% SOC down to 14% SOC to Empty and back up to 22% SOC. I’d guesstimate my real SOC was nearer 45%. (Although I didn’t check with LEAFSpy)
Of course, I need to check the other bits and bobs too — Park/Drive status seems to work with the car on — but with the module rebooted, it forgets what was previously on. This is a problem I believe with the LEAF CAN bus, which turns itself off when parked. I’m guessing we’ll need to figure out a way to wake up CAN and then switch back off again? (That said,I think it’s supposed to stay on when charging… and I’m currently charging)
I’ll play a little more tomorrow and throughout the rest of the week. I’ll also try and get some decent logs if I can.
Nikki.
On 17 Dec 2013, at 14:16, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively:
- Speed - Headlight status - Park / Drive status - SOC
I’ve also pushed this to github (along with a large number of other small changes).
The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses.
Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all.
Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically:
1. Car idle 2. Car plugged in and charge started 3. Car charging 4. Charge interrupted 5. Driving 6. Driving as close to a constant speed of 10 kph as possible 7. Driving as close to a constant speed of 20 kph as possible 8. Driving as close to a constant speed of 30 kph as possible 9. Car parked, but on 10. Car parked, coming out of park into drive gear 11. Car stopped, coming out of drive gear into park 12. Car in park gear, then handbrake applied
For each of those, both with and without a T connector and LeafSpy running would be helpful.
I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough.
If anyone can help with the above, please let me know.
Regards, Mark.
<OVMS.X.production.zip> _______________________________________________ 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
Maybe the work done by Håkon on activating some of features that were not available on the CAN bus for the Think City EV can be used for the Leaf? Nikolay On Wednesday, December 18, 2013 12:34 PM, Jeremy Whaling <jeremy.whaling@gmail.com> wrote: I posted this in the LEAF CANbus decoding thread on mynissanleaf.com, but I should probably let you folks know the bad news too... Sadly, there is no "magic" CAN bus command to wake up the VCM or the rest of the leaf. The telematics module (as well as the on board charger) wake up the VCM over dedicated logic lines when the car is off to start charging/climate/request SOC. This is according to the service manual. The OVMS module will have to do the same in order to get SOC or any other parameter out of the leaf if it is not on. Note that the EV can bus is alive (along with the VCM) during charging but the CAR can bus is quiet. There is a relay that will cycle if you do requests on the car can bus during charging, and is seen as undesired. Conversely, the CAR can bus can be active if you're in accessory mode (or just unlocking the doors) but the EV bus is quiet until the car is started. Doe the OVMS module have any sort of external logic besides the CAN transceiver? Something will be needed in order to duplicate the logic that wakes the VCM up. We will also have to probe these logic lines during a remote request to see what sort of voltage/logic is used (I didn't see any details stated in the service manual). On Tue, Dec 17, 2013 at 4:57 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Nikki,
Thanks for this.
Firstly, I'm glad the firmware is connecting back to the server ok. I broke that a few months ago (this new module meant I had to reorganise some low-level crypto stuff to make room), and am glad it is fixed again.
For the SOC, I'm really just guessing. Supposedly message 0x5b3 on car can bus has GIDs in B6bit0 and B7 - I just divided that by 3 to get a rough approximation of SOC, but it is obviously not working. I think this one shouldn't be too hard, but I don't have any CAN bus dumps of what the 0x5b3 message looks like. If I can see a dump, with matching known SOC / GIDs, then I am sure we can get this right. That said, active polling (which is what leafspy uses) seems to be a better way of getting this, as it gets us true GIDs off the EV can bus.
Glad about the parking indicator. I work off the parking brake for that one, and it is an important status flag for quite a few things.
I'm working on the polling mechanism at the moment. It is very similar to the OBDII VIN number polling mechanism we already have, and my recent work on the common vehicle.{h,c} polling code should make this relatively easy.
Regards, Mark.
On 18 Dec, 2013, at 6:22 am, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
So here’s what I’ve learned from the alpha code so far…
1) It’s recording the parking status accurately, as far as I can tell. within a few minutes of parking, it’s noting that on the app screen.
2) It’s certainly sending me alerts as you might expect for low SOC warnings.
3) But sadly SOC isn’t working correctly with my car. For some reason, SOC is jumping all over the shop, with 22% SOC seemingly a favourite place for the OVMS code. On my quick trip just now to the shops, I noted it went from 76% SOC (which I think was fairly accurate given the number of bars I had) down to 22% when I parked up.
Coming back, I got no update and ended up having to do a hard reboot to get the system to wake up.
I haven’t been able to get any logs yet because I don’t have a splitter for the ODBII system. I’ll get that sorted later this week/early next.
Nikki.
On 17 Dec 2013, at 20:06, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
Okay guys.
I’ve done a couple of quick tests with the new beta software.
First up, it installs (Which is good, of course) Second up: I was able to drive around the block and see some SOC reports. What did appear to happen is that SOC dropped and then went back up again. I had values from 27% SOC down to 14% SOC to Empty and back up to 22% SOC. I’d guesstimate my real SOC was nearer 45%. (Although I didn’t check with LEAFSpy)
Of course, I need to check the other bits and bobs too — Park/Drive status seems to work with the car on — but with the module rebooted, it forgets what was previously on. This is a problem I believe with the LEAF CAN bus, which turns itself off when parked. I’m guessing we’ll need to figure out a way to wake up CAN and then switch back off again? (That said,I think it’s supposed to stay on when charging… and I’m currently charging)
I’ll play a little more tomorrow and throughout the rest of the week. I’ll also try and get some decent logs if I can.
Nikki.
On 17 Dec 2013, at 14:16, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively:
* Speed * Headlight status * Park / Drive status * SOC
I’ve also pushed this to github (along with a large number of other small changes).
The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses.
Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all.
Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically:
1. Car idle 2. Car plugged in and charge started 3. Car charging 4. Charge interrupted 5. Driving 6. Driving as close to a constant speed of 10 kph as possible 7. Driving as close to a constant speed of 20 kph as possible 8. Driving as close to a constant speed of 30 kph as possible 9. Car parked, but on 10. Car parked, coming out of park into drive gear 11. Car stopped, coming out of drive gear into park 12. Car in park gear, then handbrake applied
For each of those, both with and without a T connector and LeafSpy running would be helpful.
I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough.
If anyone can help with the above, please let me know.
Regards, Mark.
<OVMS.X.production.zip>_______________________________________________ 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
Powering up the VCM (Vehicle Control Module?) from the OVMS should be easy; simply by choosing one of the four analogue outputs (RC[0-3] and sett it in high state when needed in the code. A similar solution was made by Think in their Think City, where the built in Remote Acquisition Unit (telemetry unit) powers up some of the other ECU's on request, like Climate and Defrost Control Module. At the Leaf, lets assume we choose RC0 for awaking VCM, the following line will put RC0 in high state (+5V) *PORTCbits.RC0 = 1;* The RC0 is wired to pin 2 at the 9x2 header. This signal should be used to control a source for powering up the VCM. A relay,mosfet or a transistor would do. The OVMS-boad have to be modified, adding a single wire from 9x2 pin 2 to one free pin at the d9-sub-connector (vehicle connector). I think it's nice if the 5V-to-12V-logic is kept inside the Ovms-box, but one can keep it on the outside the box as well. Then you have to look at the Leaf wiring diagram, finding the easiest way to connect to the VCM. Maybe there is a line at on of the pins in OBD2? See attached pictures for similar implementation for Think City. In this case all the lines are used for switching power on the negative side -> pull a line down to gnd. One for Airbag Status lamp, two for door lock and one for starting heater (via an additional relay). Best regards. Håkon 2013/12/18 Nikolay Shishkov <nshishkov@yahoo.com>
Maybe the work done by Håkon on activating some of features that were not available on the CAN bus for the Think City EV can be used for the Leaf?
Nikolay
On Wednesday, December 18, 2013 12:34 PM, Jeremy Whaling < jeremy.whaling@gmail.com> wrote: I posted this in the LEAF CANbus decoding thread on mynissanleaf.com, but I should probably let you folks know the bad news too...
Sadly, there is no "magic" CAN bus command to wake up the VCM or the rest of the leaf. The telematics module (as well as the on board charger) wake up the VCM over dedicated logic lines when the car is off to start charging/climate/request SOC. This is according to the service manual. The OVMS module will have to do the same in order to get SOC or any other parameter out of the leaf if it is not on. Note that the EV can bus is alive (along with the VCM) during charging but the CAR can bus is quiet. There is a relay that will cycle if you do requests on the car can bus during charging, and is seen as undesired. Conversely, the CAR can bus can be active if you're in accessory mode (or just unlocking the doors) but the EV bus is quiet until the car is started.
Doe the OVMS module have any sort of external logic besides the CAN transceiver? Something will be needed in order to duplicate the logic that wakes the VCM up. We will also have to probe these logic lines during a remote request to see what sort of voltage/logic is used (I didn't see any details stated in the service manual).
On Tue, Dec 17, 2013 at 4:57 PM, Mark Webb-Johnson <mark@webb-johnson.net>wrote:
Nikki,
Thanks for this.
Firstly, I'm glad the firmware is connecting back to the server ok. I broke that a few months ago (this new module meant I had to reorganise some low-level crypto stuff to make room), and am glad it is fixed again.
For the SOC, I'm really just guessing. Supposedly message 0x5b3 on car can bus has GIDs in B6bit0 and B7 - I just divided that by 3 to get a rough approximation of SOC, but it is obviously not working. I think this one shouldn't be too hard, but I don't have any CAN bus dumps of what the 0x5b3 message looks like. If I can see a dump, with matching known SOC / GIDs, then I am sure we can get this right. That said, active polling (which is what leafspy uses) seems to be a better way of getting this, as it gets us true GIDs off the EV can bus.
Glad about the parking indicator. I work off the parking brake for that one, and it is an important status flag for quite a few things.
I'm working on the polling mechanism at the moment. It is very similar to the OBDII VIN number polling mechanism we already have, and my recent work on the common vehicle.{h,c} polling code should make this relatively easy.
Regards, Mark.
On 18 Dec, 2013, at 6:22 am, Nikki Gordon-Bloomfield < nikki@aminorjourney.com> wrote:
So here’s what I’ve learned from the alpha code so far…
1) It’s recording the parking status accurately, as far as I can tell. within a few minutes of parking, it’s noting that on the app screen.
2) It’s certainly sending me alerts as you might expect for low SOC warnings.
3) But sadly SOC isn’t working correctly with my car. For some reason, SOC is jumping all over the shop, with 22% SOC seemingly a favourite place for the OVMS code. On my quick trip just now to the shops, I noted it went from 76% SOC (which I think was fairly accurate given the number of bars I had) down to 22% when I parked up.
Coming back, I got no update and ended up having to do a hard reboot to get the system to wake up.
I haven’t been able to get any logs yet because I don’t have a splitter for the ODBII system. I’ll get that sorted later this week/early next.
Nikki.
On 17 Dec 2013, at 20:06, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
Okay guys.
I’ve done a couple of quick tests with the new beta software.
First up, it installs (Which is good, of course) Second up: I was able to drive around the block and see some SOC reports. What did appear to happen is that SOC dropped and then went back up again. I had values from 27% SOC down to 14% SOC to Empty and back up to 22% SOC. I’d guesstimate my real SOC was nearer 45%. (Although I didn’t check with LEAFSpy)
Of course, I need to check the other bits and bobs too — Park/Drive status seems to work with the car on — but with the module rebooted, it forgets what was previously on. This is a problem I believe with the LEAF CAN bus, which turns itself off when parked. I’m guessing we’ll need to figure out a way to wake up CAN and then switch back off again? (That said,I think it’s supposed to stay on when charging… and I’m currently charging)
I’ll play a little more tomorrow and throughout the rest of the week. I’ll also try and get some decent logs if I can.
Nikki.
On 17 Dec 2013, at 14:16, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively:
- Speed - Headlight status - Park / Drive status - SOC
I’ve also pushed this to github (along with a large number of other small changes).
The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses.
Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all.
Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically:
1. Car idle 2. Car plugged in and charge started 3. Car charging 4. Charge interrupted 5. Driving 6. Driving as close to a constant speed of 10 kph as possible 7. Driving as close to a constant speed of 20 kph as possible 8. Driving as close to a constant speed of 30 kph as possible 9. Car parked, but on 10. Car parked, coming out of park into drive gear 11. Car stopped, coming out of drive gear into park 12. Car in park gear, then handbrake applied
For each of those, both with and without a T connector and LeafSpy running would be helpful.
I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough.
If anyone can help with the above, please let me know.
Regards, Mark.
<OVMS.X.production.zip> _______________________________________________ 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
Thanks Håkon! Glad to see there is logic available on the board. Yes VCM is the Vehicle Control Module. Unfortunately the wake line isn't on the OBD2 connector as far as we know. I plan on having my OVMS piggyback the telematics module where the logic line is located. Note that the telematics is located on the EV can bus. On Thu, Dec 19, 2013 at 1:01 AM, Håkon Markussen <hakon.markussen@gmail.com>wrote:
Powering up the VCM (Vehicle Control Module?) from the OVMS should be easy; simply by choosing one of the four analogue outputs (RC[0-3] and sett it in high state when needed in the code.
A similar solution was made by Think in their Think City, where the built in Remote Acquisition Unit (telemetry unit) powers up some of the other ECU's on request, like Climate and Defrost Control Module.
At the Leaf, lets assume we choose RC0 for awaking VCM, the following line will put RC0 in high state (+5V) *PORTCbits.RC0 = 1;*
The RC0 is wired to pin 2 at the 9x2 header. This signal should be used to control a source for powering up the VCM. A relay,mosfet or a transistor would do.
The OVMS-boad have to be modified, adding a single wire from 9x2 pin 2 to one free pin at the d9-sub-connector (vehicle connector). I think it's nice if the 5V-to-12V-logic is kept inside the Ovms-box, but one can keep it on the outside the box as well.
Then you have to look at the Leaf wiring diagram, finding the easiest way to connect to the VCM. Maybe there is a line at on of the pins in OBD2?
See attached pictures for similar implementation for Think City. In this case all the lines are used for switching power on the negative side -> pull a line down to gnd. One for Airbag Status lamp, two for door lock and one for starting heater (via an additional relay).
Best regards. Håkon
2013/12/18 Nikolay Shishkov <nshishkov@yahoo.com>
Maybe the work done by Håkon on activating some of features that were not available on the CAN bus for the Think City EV can be used for the Leaf?
Nikolay
On Wednesday, December 18, 2013 12:34 PM, Jeremy Whaling < jeremy.whaling@gmail.com> wrote: I posted this in the LEAF CANbus decoding thread on mynissanleaf.com, but I should probably let you folks know the bad news too...
Sadly, there is no "magic" CAN bus command to wake up the VCM or the rest of the leaf. The telematics module (as well as the on board charger) wake up the VCM over dedicated logic lines when the car is off to start charging/climate/request SOC. This is according to the service manual. The OVMS module will have to do the same in order to get SOC or any other parameter out of the leaf if it is not on. Note that the EV can bus is alive (along with the VCM) during charging but the CAR can bus is quiet. There is a relay that will cycle if you do requests on the car can bus during charging, and is seen as undesired. Conversely, the CAR can bus can be active if you're in accessory mode (or just unlocking the doors) but the EV bus is quiet until the car is started.
Doe the OVMS module have any sort of external logic besides the CAN transceiver? Something will be needed in order to duplicate the logic that wakes the VCM up. We will also have to probe these logic lines during a remote request to see what sort of voltage/logic is used (I didn't see any details stated in the service manual).
On Tue, Dec 17, 2013 at 4:57 PM, Mark Webb-Johnson <mark@webb-johnson.net
wrote:
Nikki,
Thanks for this.
Firstly, I'm glad the firmware is connecting back to the server ok. I broke that a few months ago (this new module meant I had to reorganise some low-level crypto stuff to make room), and am glad it is fixed again.
For the SOC, I'm really just guessing. Supposedly message 0x5b3 on car can bus has GIDs in B6bit0 and B7 - I just divided that by 3 to get a rough approximation of SOC, but it is obviously not working. I think this one shouldn't be too hard, but I don't have any CAN bus dumps of what the 0x5b3 message looks like. If I can see a dump, with matching known SOC / GIDs, then I am sure we can get this right. That said, active polling (which is what leafspy uses) seems to be a better way of getting this, as it gets us true GIDs off the EV can bus.
Glad about the parking indicator. I work off the parking brake for that one, and it is an important status flag for quite a few things.
I'm working on the polling mechanism at the moment. It is very similar to the OBDII VIN number polling mechanism we already have, and my recent work on the common vehicle.{h,c} polling code should make this relatively easy.
Regards, Mark.
On 18 Dec, 2013, at 6:22 am, Nikki Gordon-Bloomfield < nikki@aminorjourney.com> wrote:
So here’s what I’ve learned from the alpha code so far…
1) It’s recording the parking status accurately, as far as I can tell. within a few minutes of parking, it’s noting that on the app screen.
2) It’s certainly sending me alerts as you might expect for low SOC warnings.
3) But sadly SOC isn’t working correctly with my car. For some reason, SOC is jumping all over the shop, with 22% SOC seemingly a favourite place for the OVMS code. On my quick trip just now to the shops, I noted it went from 76% SOC (which I think was fairly accurate given the number of bars I had) down to 22% when I parked up.
Coming back, I got no update and ended up having to do a hard reboot to get the system to wake up.
I haven’t been able to get any logs yet because I don’t have a splitter for the ODBII system. I’ll get that sorted later this week/early next.
Nikki.
On 17 Dec 2013, at 20:06, Nikki Gordon-Bloomfield < nikki@aminorjourney.com> wrote:
Okay guys.
I’ve done a couple of quick tests with the new beta software.
First up, it installs (Which is good, of course) Second up: I was able to drive around the block and see some SOC reports. What did appear to happen is that SOC dropped and then went back up again. I had values from 27% SOC down to 14% SOC to Empty and back up to 22% SOC. I’d guesstimate my real SOC was nearer 45%. (Although I didn’t check with LEAFSpy)
Of course, I need to check the other bits and bobs too — Park/Drive status seems to work with the car on — but with the module rebooted, it forgets what was previously on. This is a problem I believe with the LEAF CAN bus, which turns itself off when parked. I’m guessing we’ll need to figure out a way to wake up CAN and then switch back off again? (That said,I think it’s supposed to stay on when charging… and I’m currently charging)
I’ll play a little more tomorrow and throughout the rest of the week. I’ll also try and get some decent logs if I can.
Nikki.
On 17 Dec 2013, at 14:16, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively:
- Speed - Headlight status - Park / Drive status - SOC
I’ve also pushed this to github (along with a large number of other small changes).
The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses.
Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all.
Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically:
1. Car idle 2. Car plugged in and charge started 3. Car charging 4. Charge interrupted 5. Driving 6. Driving as close to a constant speed of 10 kph as possible 7. Driving as close to a constant speed of 20 kph as possible 8. Driving as close to a constant speed of 30 kph as possible 9. Car parked, but on 10. Car parked, coming out of park into drive gear 11. Car stopped, coming out of drive gear into park 12. Car in park gear, then handbrake applied
For each of those, both with and without a T connector and LeafSpy running would be helpful.
I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough.
If anyone can help with the above, please let me know.
Regards, Mark.
<OVMS.X.production.zip> _______________________________________________ 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
Hi Mark, Sorry it has taken a while to get back to you. I only have access to LeafSpy via my wife's work phone and she has been out most of the week. I only just realised that logging could probably be done through the OVMS :-( so will try that in the next few days as well. Anyway, attached is sample LeafSpy Elm Trace. Before I do lots of testing using this method can you confirm that this is useful. Regards, Rob ---- On Wed, 18 Dec 2013 01:57:50 +0100 Mark Webb-Johnson<mark@webb-johnson.net> wrote ---- Nikki, Thanks for this. Firstly, I'm glad the firmware is connecting back to the server ok. I broke that a few months ago (this new module meant I had to reorganise some low-level crypto stuff to make room), and am glad it is fixed again. For the SOC, I'm really just guessing. Supposedly message 0x5b3 on car can bus has GIDs in B6bit0 and B7 - I just divided that by 3 to get a rough approximation of SOC, but it is obviously not working. I think this one shouldn't be too hard, but I don't have any CAN bus dumps of what the 0x5b3 message looks like. If I can see a dump, with matching known SOC / GIDs, then I am sure we can get this right. That said, active polling (which is what leafspy uses) seems to be a better way of getting this, as it gets us true GIDs off the EV can bus. Glad about the parking indicator. I work off the parking brake for that one, and it is an important status flag for quite a few things. I'm working on the polling mechanism at the moment. It is very similar to the OBDII VIN number polling mechanism we already have, and my recent work on the common vehicle.{h,c} polling code should make this relatively easy. Regards, Mark. On 18 Dec, 2013, at 6:22 am, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote: So here’s what I’ve learned from the alpha code so far… 1) It’s recording the parking status accurately, as far as I can tell. within a few minutes of parking, it’s noting that on the app screen. 2) It’s certainly sending me alerts as you might expect for low SOC warnings. 3) But sadly SOC isn’t working correctly with my car. For some reason, SOC is jumping all over the shop, with 22% SOC seemingly a favourite place for the OVMS code. On my quick trip just now to the shops, I noted it went from 76% SOC (which I think was fairly accurate given the number of bars I had) down to 22% when I parked up. Coming back, I got no update and ended up having to do a hard reboot to get the system to wake up. I haven’t been able to get any logs yet because I don’t have a splitter for the ODBII system. I’ll get that sorted later this week/early next. Nikki. On 17 Dec 2013, at 20:06, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote: Okay guys. I’ve done a couple of quick tests with the new beta software. First up, it installs (Which is good, of course) Second up: I was able to drive around the block and see some SOC reports. What did appear to happen is that SOC dropped and then went back up again. I had values from 27% SOC down to 14% SOC to Empty and back up to 22% SOC. I’d guesstimate my real SOC was nearer 45%. (Although I didn’t check with LEAFSpy) Of course, I need to check the other bits and bobs too — Park/Drive status seems to work with the car on — but with the module rebooted, it forgets what was previously on. This is a problem I believe with the LEAF CAN bus, which turns itself off when parked. I’m guessing we’ll need to figure out a way to wake up CAN and then switch back off again? (That said,I think it’s supposed to stay on when charging… and I’m currently charging) I’ll play a little more tomorrow and throughout the rest of the week. I’ll also try and get some decent logs if I can. Nikki. On 17 Dec 2013, at 14:16, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively: Speed Headlight status Park / Drive status SOC I’ve also pushed this to github (along with a large number of other small changes). The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses. Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all. Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically: Car idle Car plugged in and charge started Car charging Charge interrupted Driving Driving as close to a constant speed of 10 kph as possible Driving as close to a constant speed of 20 kph as possible Driving as close to a constant speed of 30 kph as possible Car parked, but on Car parked, coming out of park into drive gear Car stopped, coming out of drive gear into park Car in park gear, then handbrake applied For each of those, both with and without a T connector and LeafSpy running would be helpful. I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough. If anyone can help with the above, please let me know. Regards, Mark. <OVMS.X.production.zip> _______________________________________________ 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
Robert, The leafspy log is interesting, but not very useful. What I am interested in is a raw can bus dump. This can be done from the OBDII adaptor using 'monitor all' mode. I know how to do it with a terminal emulator and some AT commands, but does anyone know any simple software that Robert can use? Regards, Mark. On 21 Dec, 2013, at 10:38 pm, Robert Sharpe <robert.sharpe@evergreen-consulting.co.uk> wrote:
Hi Mark,
Sorry it has taken a while to get back to you. I only have access to LeafSpy via my wife's work phone and she has been out most of the week. I only just realised that logging could probably be done through the OVMS :-( so will try that in the next few days as well.
Anyway, attached is sample LeafSpy Elm Trace. Before I do lots of testing using this method can you confirm that this is useful.
Regards, Rob
---- On Wed, 18 Dec 2013 01:57:50 +0100 Mark Webb-Johnson<mark@webb-johnson.net> wrote ----
Nikki,
Thanks for this.
Firstly, I'm glad the firmware is connecting back to the server ok. I broke that a few months ago (this new module meant I had to reorganise some low-level crypto stuff to make room), and am glad it is fixed again.
For the SOC, I'm really just guessing. Supposedly message 0x5b3 on car can bus has GIDs in B6bit0 and B7 - I just divided that by 3 to get a rough approximation of SOC, but it is obviously not working. I think this one shouldn't be too hard, but I don't have any CAN bus dumps of what the 0x5b3 message looks like. If I can see a dump, with matching known SOC / GIDs, then I am sure we can get this right. That said, active polling (which is what leafspy uses) seems to be a better way of getting this, as it gets us true GIDs off the EV can bus.
Glad about the parking indicator. I work off the parking brake for that one, and it is an important status flag for quite a few things.
I'm working on the polling mechanism at the moment. It is very similar to the OBDII VIN number polling mechanism we already have, and my recent work on the common vehicle.{h,c} polling code should make this relatively easy.
Regards, Mark.
On 18 Dec, 2013, at 6:22 am, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
So here’s what I’ve learned from the alpha code so far…
1) It’s recording the parking status accurately, as far as I can tell. within a few minutes of parking, it’s noting that on the app screen.
2) It’s certainly sending me alerts as you might expect for low SOC warnings.
3) But sadly SOC isn’t working correctly with my car. For some reason, SOC is jumping all over the shop, with 22% SOC seemingly a favourite place for the OVMS code. On my quick trip just now to the shops, I noted it went from 76% SOC (which I think was fairly accurate given the number of bars I had) down to 22% when I parked up.
Coming back, I got no update and ended up having to do a hard reboot to get the system to wake up.
I haven’t been able to get any logs yet because I don’t have a splitter for the ODBII system. I’ll get that sorted later this week/early next.
Nikki.
On 17 Dec 2013, at 20:06, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
Okay guys.
I’ve done a couple of quick tests with the new beta software.
First up, it installs (Which is good, of course) Second up: I was able to drive around the block and see some SOC reports. What did appear to happen is that SOC dropped and then went back up again. I had values from 27% SOC down to 14% SOC to Empty and back up to 22% SOC. I’d guesstimate my real SOC was nearer 45%. (Although I didn’t check with LEAFSpy)
Of course, I need to check the other bits and bobs too — Park/Drive status seems to work with the car on — but with the module rebooted, it forgets what was previously on. This is a problem I believe with the LEAF CAN bus, which turns itself off when parked. I’m guessing we’ll need to figure out a way to wake up CAN and then switch back off again? (That said,I think it’s supposed to stay on when charging… and I’m currently charging)
I’ll play a little more tomorrow and throughout the rest of the week. I’ll also try and get some decent logs if I can.
Nikki.
On 17 Dec 2013, at 14:16, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively:
Speed Headlight status Park / Drive status SOC
I’ve also pushed this to github (along with a large number of other small changes).
The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses.
Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all.
Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically:
Car idle Car plugged in and charge started Car charging Charge interrupted Driving Driving as close to a constant speed of 10 kph as possible Driving as close to a constant speed of 20 kph as possible Driving as close to a constant speed of 30 kph as possible Car parked, but on Car parked, coming out of park into drive gear Car stopped, coming out of drive gear into park Car in park gear, then handbrake applied
For each of those, both with and without a T connector and LeafSpy running would be helpful.
I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough.
If anyone can help with the above, please let me know.
Regards, Mark.
<OVMS.X.production.zip> _______________________________________________ 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
<TRC_1312211426.txt>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark, Ping me the terminal instructions and I'll see what I can do. Presumably you want me to pipe Bluetooth into a log file using cat? Sent from my iPhone
On 21 Dec 2013, at 14:38, Robert Sharpe <robert.sharpe@evergreen-consulting.co.uk> wrote:
Hi Mark,
Sorry it has taken a while to get back to you. I only have access to LeafSpy via my wife's work phone and she has been out most of the week. I only just realised that logging could probably be done through the OVMS :-( so will try that in the next few days as well.
Anyway, attached is sample LeafSpy Elm Trace. Before I do lots of testing using this method can you confirm that this is useful.
Regards, Rob
---- On Wed, 18 Dec 2013 01:57:50 +0100 Mark Webb-Johnson<mark@webb-johnson.net> wrote ----
Nikki,
Thanks for this.
Firstly, I'm glad the firmware is connecting back to the server ok. I broke that a few months ago (this new module meant I had to reorganise some low-level crypto stuff to make room), and am glad it is fixed again.
For the SOC, I'm really just guessing. Supposedly message 0x5b3 on car can bus has GIDs in B6bit0 and B7 - I just divided that by 3 to get a rough approximation of SOC, but it is obviously not working. I think this one shouldn't be too hard, but I don't have any CAN bus dumps of what the 0x5b3 message looks like. If I can see a dump, with matching known SOC / GIDs, then I am sure we can get this right. That said, active polling (which is what leafspy uses) seems to be a better way of getting this, as it gets us true GIDs off the EV can bus.
Glad about the parking indicator. I work off the parking brake for that one, and it is an important status flag for quite a few things.
I'm working on the polling mechanism at the moment. It is very similar to the OBDII VIN number polling mechanism we already have, and my recent work on the common vehicle.{h,c} polling code should make this relatively easy.
Regards, Mark.
On 18 Dec, 2013, at 6:22 am, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
So here’s what I’ve learned from the alpha code so far…
1) It’s recording the parking status accurately, as far as I can tell. within a few minutes of parking, it’s noting that on the app screen.
2) It’s certainly sending me alerts as you might expect for low SOC warnings.
3) But sadly SOC isn’t working correctly with my car. For some reason, SOC is jumping all over the shop, with 22% SOC seemingly a favourite place for the OVMS code. On my quick trip just now to the shops, I noted it went from 76% SOC (which I think was fairly accurate given the number of bars I had) down to 22% when I parked up.
Coming back, I got no update and ended up having to do a hard reboot to get the system to wake up.
I haven’t been able to get any logs yet because I don’t have a splitter for the ODBII system. I’ll get that sorted later this week/early next.
Nikki.
On 17 Dec 2013, at 20:06, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
Okay guys.
I’ve done a couple of quick tests with the new beta software.
First up, it installs (Which is good, of course) Second up: I was able to drive around the block and see some SOC reports. What did appear to happen is that SOC dropped and then went back up again. I had values from 27% SOC down to 14% SOC to Empty and back up to 22% SOC. I’d guesstimate my real SOC was nearer 45%. (Although I didn’t check with LEAFSpy)
Of course, I need to check the other bits and bobs too — Park/Drive status seems to work with the car on — but with the module rebooted, it forgets what was previously on. This is a problem I believe with the LEAF CAN bus, which turns itself off when parked. I’m guessing we’ll need to figure out a way to wake up CAN and then switch back off again? (That said,I think it’s supposed to stay on when charging… and I’m currently charging)
I’ll play a little more tomorrow and throughout the rest of the week. I’ll also try and get some decent logs if I can.
Nikki.
On 17 Dec 2013, at 14:16, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively:
Speed Headlight status Park / Drive status SOC
I’ve also pushed this to github (along with a large number of other small changes).
The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses.
Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all.
Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically:
Car idle Car plugged in and charge started Car charging Charge interrupted Driving Driving as close to a constant speed of 10 kph as possible Driving as close to a constant speed of 20 kph as possible Driving as close to a constant speed of 30 kph as possible Car parked, but on Car parked, coming out of park into drive gear Car stopped, coming out of drive gear into park Car in park gear, then handbrake applied
For each of those, both with and without a T connector and LeafSpy running would be helpful.
I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough.
If anyone can help with the above, please let me know.
Regards, Mark.
<OVMS.X.production.zip> _______________________________________________ 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
<TRC_1312211426.txt> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Nikki, Something like this: http://theksmith.com/technology/hack-vehicle-bus-cheap-easy-part-1/ Regards, Mark
On 27 Dec, 2013, at 4:30 pm, Nikki Gordon-Bloomfield <nikki@littlecollie.com> wrote:
Mark,
Ping me the terminal instructions and I'll see what I can do. Presumably you want me to pipe Bluetooth into a log file using cat?
Sent from my iPhone
On 21 Dec 2013, at 14:38, Robert Sharpe <robert.sharpe@evergreen-consulting.co.uk> wrote:
Hi Mark,
Sorry it has taken a while to get back to you. I only have access to LeafSpy via my wife's work phone and she has been out most of the week. I only just realised that logging could probably be done through the OVMS :-( so will try that in the next few days as well.
Anyway, attached is sample LeafSpy Elm Trace. Before I do lots of testing using this method can you confirm that this is useful.
Regards, Rob
---- On Wed, 18 Dec 2013 01:57:50 +0100 Mark Webb-Johnson<mark@webb-johnson.net> wrote ----
Nikki,
Thanks for this.
Firstly, I'm glad the firmware is connecting back to the server ok. I broke that a few months ago (this new module meant I had to reorganise some low-level crypto stuff to make room), and am glad it is fixed again.
For the SOC, I'm really just guessing. Supposedly message 0x5b3 on car can bus has GIDs in B6bit0 and B7 - I just divided that by 3 to get a rough approximation of SOC, but it is obviously not working. I think this one shouldn't be too hard, but I don't have any CAN bus dumps of what the 0x5b3 message looks like. If I can see a dump, with matching known SOC / GIDs, then I am sure we can get this right. That said, active polling (which is what leafspy uses) seems to be a better way of getting this, as it gets us true GIDs off the EV can bus.
Glad about the parking indicator. I work off the parking brake for that one, and it is an important status flag for quite a few things.
I'm working on the polling mechanism at the moment. It is very similar to the OBDII VIN number polling mechanism we already have, and my recent work on the common vehicle.{h,c} polling code should make this relatively easy.
Regards, Mark.
On 18 Dec, 2013, at 6:22 am, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
So here’s what I’ve learned from the alpha code so far…
1) It’s recording the parking status accurately, as far as I can tell. within a few minutes of parking, it’s noting that on the app screen.
2) It’s certainly sending me alerts as you might expect for low SOC warnings.
3) But sadly SOC isn’t working correctly with my car. For some reason, SOC is jumping all over the shop, with 22% SOC seemingly a favourite place for the OVMS code. On my quick trip just now to the shops, I noted it went from 76% SOC (which I think was fairly accurate given the number of bars I had) down to 22% when I parked up.
Coming back, I got no update and ended up having to do a hard reboot to get the system to wake up.
I haven’t been able to get any logs yet because I don’t have a splitter for the ODBII system. I’ll get that sorted later this week/early next.
Nikki.
On 17 Dec 2013, at 20:06, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
Okay guys.
I’ve done a couple of quick tests with the new beta software.
First up, it installs (Which is good, of course) Second up: I was able to drive around the block and see some SOC reports. What did appear to happen is that SOC dropped and then went back up again. I had values from 27% SOC down to 14% SOC to Empty and back up to 22% SOC. I’d guesstimate my real SOC was nearer 45%. (Although I didn’t check with LEAFSpy)
Of course, I need to check the other bits and bobs too — Park/Drive status seems to work with the car on — but with the module rebooted, it forgets what was previously on. This is a problem I believe with the LEAF CAN bus, which turns itself off when parked. I’m guessing we’ll need to figure out a way to wake up CAN and then switch back off again? (That said,I think it’s supposed to stay on when charging… and I’m currently charging)
I’ll play a little more tomorrow and throughout the rest of the week. I’ll also try and get some decent logs if I can.
Nikki.
On 17 Dec 2013, at 14:16, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively:
Speed Headlight status Park / Drive status SOC
I’ve also pushed this to github (along with a large number of other small changes).
The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses.
Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all.
Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically:
Car idle Car plugged in and charge started Car charging Charge interrupted Driving Driving as close to a constant speed of 10 kph as possible Driving as close to a constant speed of 20 kph as possible Driving as close to a constant speed of 30 kph as possible Car parked, but on Car parked, coming out of park into drive gear Car stopped, coming out of drive gear into park Car in park gear, then handbrake applied
For each of those, both with and without a T connector and LeafSpy running would be helpful.
I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough.
If anyone can help with the above, please let me know.
Regards, Mark.
<OVMS.X.production.zip> _______________________________________________ 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
<TRC_1312211426.txt> _______________________________________________ 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
Hi Mark, Give me a couple of days. :) Nikki. On 27 Dec 2013, at 11:33, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Nikki,
Something like this:
http://theksmith.com/technology/hack-vehicle-bus-cheap-easy-part-1/
Regards, Mark
On 27 Dec, 2013, at 4:30 pm, Nikki Gordon-Bloomfield <nikki@littlecollie.com> wrote:
Mark,
Ping me the terminal instructions and I'll see what I can do. Presumably you want me to pipe Bluetooth into a log file using cat?
Sent from my iPhone
On 21 Dec 2013, at 14:38, Robert Sharpe <robert.sharpe@evergreen-consulting.co.uk> wrote:
Hi Mark,
Sorry it has taken a while to get back to you. I only have access to LeafSpy via my wife's work phone and she has been out most of the week. I only just realised that logging could probably be done through the OVMS :-( so will try that in the next few days as well.
Anyway, attached is sample LeafSpy Elm Trace. Before I do lots of testing using this method can you confirm that this is useful.
Regards, Rob
---- On Wed, 18 Dec 2013 01:57:50 +0100 Mark Webb-Johnson<mark@webb-johnson.net> wrote ----
Nikki,
Thanks for this.
Firstly, I'm glad the firmware is connecting back to the server ok. I broke that a few months ago (this new module meant I had to reorganise some low-level crypto stuff to make room), and am glad it is fixed again.
For the SOC, I'm really just guessing. Supposedly message 0x5b3 on car can bus has GIDs in B6bit0 and B7 - I just divided that by 3 to get a rough approximation of SOC, but it is obviously not working. I think this one shouldn't be too hard, but I don't have any CAN bus dumps of what the 0x5b3 message looks like. If I can see a dump, with matching known SOC / GIDs, then I am sure we can get this right. That said, active polling (which is what leafspy uses) seems to be a better way of getting this, as it gets us true GIDs off the EV can bus.
Glad about the parking indicator. I work off the parking brake for that one, and it is an important status flag for quite a few things.
I'm working on the polling mechanism at the moment. It is very similar to the OBDII VIN number polling mechanism we already have, and my recent work on the common vehicle.{h,c} polling code should make this relatively easy.
Regards, Mark.
On 18 Dec, 2013, at 6:22 am, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
So here’s what I’ve learned from the alpha code so far…
1) It’s recording the parking status accurately, as far as I can tell. within a few minutes of parking, it’s noting that on the app screen.
2) It’s certainly sending me alerts as you might expect for low SOC warnings.
3) But sadly SOC isn’t working correctly with my car. For some reason, SOC is jumping all over the shop, with 22% SOC seemingly a favourite place for the OVMS code. On my quick trip just now to the shops, I noted it went from 76% SOC (which I think was fairly accurate given the number of bars I had) down to 22% when I parked up.
Coming back, I got no update and ended up having to do a hard reboot to get the system to wake up.
I haven’t been able to get any logs yet because I don’t have a splitter for the ODBII system. I’ll get that sorted later this week/early next.
Nikki.
On 17 Dec 2013, at 20:06, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
Okay guys.
I’ve done a couple of quick tests with the new beta software.
First up, it installs (Which is good, of course) Second up: I was able to drive around the block and see some SOC reports. What did appear to happen is that SOC dropped and then went back up again. I had values from 27% SOC down to 14% SOC to Empty and back up to 22% SOC. I’d guesstimate my real SOC was nearer 45%. (Although I didn’t check with LEAFSpy)
Of course, I need to check the other bits and bobs too — Park/Drive status seems to work with the car on — but with the module rebooted, it forgets what was previously on. This is a problem I believe with the LEAF CAN bus, which turns itself off when parked. I’m guessing we’ll need to figure out a way to wake up CAN and then switch back off again? (That said,I think it’s supposed to stay on when charging… and I’m currently charging)
I’ll play a little more tomorrow and throughout the rest of the week. I’ll also try and get some decent logs if I can.
Nikki.
On 17 Dec 2013, at 14:16, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively:
Speed Headlight status Park / Drive status SOC
I’ve also pushed this to github (along with a large number of other small changes).
The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses.
Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all.
Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically:
Car idle Car plugged in and charge started Car charging Charge interrupted Driving Driving as close to a constant speed of 10 kph as possible Driving as close to a constant speed of 20 kph as possible Driving as close to a constant speed of 30 kph as possible Car parked, but on Car parked, coming out of park into drive gear Car stopped, coming out of drive gear into park Car in park gear, then handbrake applied
For each of those, both with and without a T connector and LeafSpy running would be helpful.
I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough.
If anyone can help with the above, please let me know.
Regards, Mark.
<OVMS.X.production.zip> _______________________________________________ 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
<TRC_1312211426.txt> _______________________________________________ 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
I've got a device called the PCAN tool along with a demo monitoring program which can let me record (I think) 100,000 frames of data. Note there's a lot of repetition since some frames are sent every 10ms when the car is on. I am not sure if an ELM wi The EV bus is active when the car is charging, on, or during a remote request. The CAR bus is active when the car is on or for a few seconds when the unlock/lock button is pressed. I would highly recommend sticking with the EV bus for most of your work since that's where the charger and battery controller live. The ELM uses the car can and quires for things on the EV can because the ELM is set up for ICE cars and that is where they normally have their can communication bus on the OBD connector. On Fri, Dec 27, 2013 at 3:34 AM, Nikki Gordon-Bloomfield < nikki@aminorjourney.com> wrote:
Hi Mark,
Give me a couple of days. :)
Nikki.
On 27 Dec 2013, at 11:33, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Nikki,
Something like this:
http://theksmith.com/technology/hack-vehicle-bus-cheap-easy-part-1/
Regards, Mark
On 27 Dec, 2013, at 4:30 pm, Nikki Gordon-Bloomfield < nikki@littlecollie.com> wrote:
Mark,
Ping me the terminal instructions and I'll see what I can do. Presumably you want me to pipe Bluetooth into a log file using cat?
Sent from my iPhone
On 21 Dec 2013, at 14:38, Robert Sharpe < robert.sharpe@evergreen-consulting.co.uk> wrote:
Hi Mark,
Sorry it has taken a while to get back to you. I only have access to LeafSpy via my wife's work phone and she has been out most of the week. I only just realised that logging could probably be done through the OVMS :-( so will try that in the next few days as well.
Anyway, attached is sample LeafSpy Elm Trace. Before I do lots of testing using this method can you confirm that this is useful.
Regards, Rob
---- On Wed, 18 Dec 2013 01:57:50 +0100 *Mark Webb-Johnson<mark@webb-johnson.net <mark@webb-johnson.net>>* wrote ----
Nikki,
Thanks for this.
Firstly, I'm glad the firmware is connecting back to the server ok. I broke that a few months ago (this new module meant I had to reorganise some low-level crypto stuff to make room), and am glad it is fixed again.
For the SOC, I'm really just guessing. Supposedly message 0x5b3 on car can bus has GIDs in B6bit0 and B7 - I just divided that by 3 to get a rough approximation of SOC, but it is obviously not working. I think this one shouldn't be too hard, but I don't have any CAN bus dumps of what the 0x5b3 message looks like. If I can see a dump, with matching known SOC / GIDs, then I am sure we can get this right. That said, active polling (which is what leafspy uses) seems to be a better way of getting this, as it gets us true GIDs off the EV can bus.
Glad about the parking indicator. I work off the parking brake for that one, and it is an important status flag for quite a few things.
I'm working on the polling mechanism at the moment. It is very similar to the OBDII VIN number polling mechanism we already have, and my recent work on the common vehicle.{h,c} polling code should make this relatively easy.
Regards, Mark.
On 18 Dec, 2013, at 6:22 am, Nikki Gordon-Bloomfield < nikki@aminorjourney.com> wrote:
So here’s what I’ve learned from the alpha code so far…
1) It’s recording the parking status accurately, as far as I can tell. within a few minutes of parking, it’s noting that on the app screen.
2) It’s certainly sending me alerts as you might expect for low SOC warnings.
3) But sadly SOC isn’t working correctly with my car. For some reason, SOC is jumping all over the shop, with 22% SOC seemingly a favourite place for the OVMS code. On my quick trip just now to the shops, I noted it went from 76% SOC (which I think was fairly accurate given the number of bars I had) down to 22% when I parked up.
Coming back, I got no update and ended up having to do a hard reboot to get the system to wake up.
I haven’t been able to get any logs yet because I don’t have a splitter for the ODBII system. I’ll get that sorted later this week/early next.
Nikki.
On 17 Dec 2013, at 20:06, Nikki Gordon-Bloomfield <nikki@aminorjourney.com> wrote:
Okay guys.
I’ve done a couple of quick tests with the new beta software.
First up, it installs (Which is good, of course) Second up: I was able to drive around the block and see some SOC reports. What did appear to happen is that SOC dropped and then went back up again. I had values from 27% SOC down to 14% SOC to Empty and back up to 22% SOC. I’d guesstimate my real SOC was nearer 45%. (Although I didn’t check with LEAFSpy)
Of course, I need to check the other bits and bobs too — Park/Drive status seems to work with the car on — but with the module rebooted, it forgets what was previously on. This is a problem I believe with the LEAF CAN bus, which turns itself off when parked. I’m guessing we’ll need to figure out a way to wake up CAN and then switch back off again? (That said,I think it’s supposed to stay on when charging… and I’m currently charging)
I’ll play a little more tomorrow and throughout the rest of the week. I’ll also try and get some decent logs if I can.
Nikki.
On 17 Dec 2013, at 14:16, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is a first-run at Nissan Leaf support, with a few values read from the bus passively:
- Speed - Headlight status - Park / Drive status - SOC
I’ve also pushed this to github (along with a large number of other small changes).
The Nissan Leaf support is proving really hard for me. I don’t have the car, or much CAN bus data, and the public documentation is contradictory and incomplete. End result is that I am just guessing, and completely unable to test my guesses.
Anyway, please try it and let me know if any of those figures show up with any sense of accuracy at all.
Going forward, I really need some CAN bus dumps from a Nissan Leaf. Specifically:
1. Car idle 2. Car plugged in and charge started 3. Car charging 4. Charge interrupted 5. Driving 6. Driving as close to a constant speed of 10 kph as possible 7. Driving as close to a constant speed of 20 kph as possible 8. Driving as close to a constant speed of 30 kph as possible 9. Car parked, but on 10. Car parked, coming out of park into drive gear 11. Car stopped, coming out of drive gear into park 12. Car in park gear, then handbrake applied
For each of those, both with and without a T connector and LeafSpy running would be helpful.
I’m guessing the logs can be gotten from monitor-all mode with an OBDII adaptor. There is not too much data on the can bus and that should be fast enough.
If anyone can help with the above, please let me know.
Regards, Mark.
<OVMS.X.production.zip> _______________________________________________ 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
<TRC_1312211426.txt>
_______________________________________________ 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
I bought a tiny $12 ELM327 Bluetooth gizmo that's listed among the devices compatible with LeafSpy. http://www.amazon.com/gp/product/B008U1MOM8/ I also bought the OBDII Y cable that Mark suggested which looks like a high quality cable and it works. http://www.amazon.com/gp/product/B00EEDOWU8/ At first I had zero success getting CAN messages from the Leaf's CAR-CAN bus using the ELM327; I got either nothing or garbage data with errors and buffer overflow messages. This tutorial Mark suggested is inspiring, and illustrates a good general technique for figuring things out, but it has no information on how to get CAN data. http://theksmith.com/technology/hack-vehicle-bus-cheap-easy-part-1/ I was then led astray by reading the ELM32X data sheet and the Wikipedia page on how OBDII CAN messages work. http://elmelectronics.com/DSheets/ELM327DS.pdf http://en.wikipedia.org/wiki/OBD-II_PIDs The specifics of how the messages are formatted is completely wrong for the Leaf. The 11-bit CAN ID values are not used to identify ECUs, they are the message identifiers. Instead of looking at CAN IDs in the range 7E0 to 7EF, you have to look at all CAN IDs from 001 to 7FF. The next problem is that there is so much traffic on the Leaf's CAR-CAN bus, that a low-bandwidth unit like the cheap Bluetooth gizmos can't possibly keep up. I was able to determine that the output baud rate on the above gizmo is at most 38400 bps. To look at things, you need to filter to only get a subset of the constant stream of traffic on the CAR-CAN bus. The trick is to use the ATCM (CAN mask) and ATCF (CAN filter) commands to filter for a single message. For example, to view message 0x5C5 which includes the Leaf's odometer value, first set up the chip with these commands: ATZ ATH1 ATL1 ATS1 ATAL Those commands in order: reset the chip to defaults, turn on message headers (which show the CAN ID), line endings between messages and spaces between bytes, and enables long messages. Then issue these commands: ATCM 7FF ATCF 5C5 ATMA The first two commands set the ELM327 to filter for a single message ID, 5C5, the third starts dumping them. You'll get data that looks like this: 5C5 44 00 3C BA 00 0C 00 00 5C5 44 00 3C BA 00 0C 00 00 5C5 44 00 3C BA 00 0C 00 00 ... Type any character to stop the spewing of messages. The first group of three hex digits, 5C5, is the message ID, followed by the message data, bytes 0 through 7. According to the LEAF CAN message spreadsheet, skipping the first byte (44) and taking the next three (00 3C BA) yields the odometer. Sure enough, 003CBA is 15,546 in decimal, which is indeed our Leaf's odometer value. I also confirmed the Gid value documented in message 5B3 for several Gid values in the low 200's. To get an idea of what's happening on the CAR-CAN bus, I wrote a program that marches though all 2048 CAN ID values, listens for each message ID until either 20 messages have been collected or 2.01 seconds goes by with no messages, then moves on to the next ID. Using that program, I found 49 messages that happen between twice and one hundred times per second when the car is parked and turned on in accessory mode. Together, they total up to over 1500 messages per second. So, you'd need an output baud rate around 500,000 bps to monitor all messages, which is totally not happening with a $12 38400 bps gizmo. I've attached a spreadsheet with the list of those messages. I have a text file with 20 sample messages of each type. I'm happy to share if anyone else wants to see it. See the spreadsheet of known LEAF CAN messages to see what's known about what they contain. https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1 ON2xZSzlMUXc#gid=1 Unfortunately, with the sealed plastic $12 gizmo, there's no way to look at the EV-CAN bus, so that will have to wait until I get a better device. I'm considering these three: Mark recommends: http://www.can232.com/?page_id=16 ($140 + cable + shipping) Roadster service techs use: http://gridconnect.com/can-usb.html ($255 + cable + shipping) Sparkfun: https://www.sparkfun.com/products/9555 ($74.85 with cable and shipping) For connecting to the CAN bus, OVMS uses the same pin mapping as the device Mark and Tesla use. Sparkfun uses a different pin mapping which agrees with what OBD2cables.com says is the "de facto standard pinout." http://www.obd2cables.com/products/cable-j1962m-right-angle-to-db9f-4-3-ft.h tml Standards are so awesome, we have at least two! I was surprised to see obd2cables.com claiming a standard that's different from what I expected from Mark's and Tesla's preferred gizmos. Fortunately, it should be easy to make a DB9 adapter to convert between the two standards should the need arise. Tom
Dear Tom, Thanks for so nicely explaining your work. I tried almost similar steps using wifi enabled ELM 327 chipset on my car ( not a electric car ). However did not use the command Can Mask command you suggested . This is useful as with ATMA command , OBD adapter is not able to provide all data so filtering the data is awesome idea.So i believe it will continue to monitor particular parameter unless interrupted ??? @ Dear Mark and all : have you guys worked on ELM 329 chipset. I am not able to understand the difference between ELM 327 and 329. Any help is appreciated . Regards, Avesh On Tue, Feb 11, 2014 at 7:20 AM, Tom Saxton <tom@idleloop.com> wrote:
I bought a tiny $12 ELM327 Bluetooth gizmo that's listed among the devices compatible with LeafSpy.
http://www.amazon.com/gp/product/B008U1MOM8/
I also bought the OBDII Y cable that Mark suggested which looks like a high quality cable and it works.
http://www.amazon.com/gp/product/B00EEDOWU8/
At first I had zero success getting CAN messages from the Leaf's CAR-CAN bus using the ELM327; I got either nothing or garbage data with errors and buffer overflow messages.
This tutorial Mark suggested is inspiring, and illustrates a good general technique for figuring things out, but it has no information on how to get CAN data.
http://theksmith.com/technology/hack-vehicle-bus-cheap-easy-part-1/
I was then led astray by reading the ELM32X data sheet and the Wikipedia page on how OBDII CAN messages work.
http://elmelectronics.com/DSheets/ELM327DS.pdf http://en.wikipedia.org/wiki/OBD-II_PIDs
The specifics of how the messages are formatted is completely wrong for the Leaf. The 11-bit CAN ID values are not used to identify ECUs, they are the message identifiers. Instead of looking at CAN IDs in the range 7E0 to 7EF, you have to look at all CAN IDs from 001 to 7FF.
The next problem is that there is so much traffic on the Leaf's CAR-CAN bus, that a low-bandwidth unit like the cheap Bluetooth gizmos can't possibly keep up. I was able to determine that the output baud rate on the above gizmo is at most 38400 bps. To look at things, you need to filter to only get a subset of the constant stream of traffic on the CAR-CAN bus.
The trick is to use the ATCM (CAN mask) and ATCF (CAN filter) commands to filter for a single message. For example, to view message 0x5C5 which includes the Leaf's odometer value, first set up the chip with these commands:
ATZ ATH1 ATL1 ATS1 ATAL
Those commands in order: reset the chip to defaults, turn on message headers (which show the CAN ID), line endings between messages and spaces between bytes, and enables long messages. Then issue these commands:
ATCM 7FF ATCF 5C5 ATMA
The first two commands set the ELM327 to filter for a single message ID, 5C5, the third starts dumping them. You'll get data that looks like this:
5C5 44 00 3C BA 00 0C 00 00 5C5 44 00 3C BA 00 0C 00 00 5C5 44 00 3C BA 00 0C 00 00 ...
Type any character to stop the spewing of messages. The first group of three hex digits, 5C5, is the message ID, followed by the message data, bytes 0 through 7. According to the LEAF CAN message spreadsheet, skipping the first byte (44) and taking the next three (00 3C BA) yields the odometer. Sure enough, 003CBA is 15,546 in decimal, which is indeed our Leaf's odometer value.
I also confirmed the Gid value documented in message 5B3 for several Gid values in the low 200's.
To get an idea of what's happening on the CAR-CAN bus, I wrote a program that marches though all 2048 CAN ID values, listens for each message ID until either 20 messages have been collected or 2.01 seconds goes by with no messages, then moves on to the next ID. Using that program, I found 49 messages that happen between twice and one hundred times per second when the car is parked and turned on in accessory mode. Together, they total up to over 1500 messages per second. So, you'd need an output baud rate around 500,000 bps to monitor all messages, which is totally not happening with a $12 38400 bps gizmo.
I've attached a spreadsheet with the list of those messages. I have a text file with 20 sample messages of each type. I'm happy to share if anyone else wants to see it.
See the spreadsheet of known LEAF CAN messages to see what's known about what they contain.
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1...
Unfortunately, with the sealed plastic $12 gizmo, there's no way to look at the EV-CAN bus, so that will have to wait until I get a better device. I'm considering these three:
Mark recommends: http://www.can232.com/?page_id=16 ($140 + cable + shipping) Roadster service techs use: http://gridconnect.com/can-usb.html ($255 + cable + shipping) Sparkfun: https://www.sparkfun.com/products/9555 ($74.85 with cable and shipping)
For connecting to the CAN bus, OVMS uses the same pin mapping as the device Mark and Tesla use. Sparkfun uses a different pin mapping which agrees with what OBD2cables.com says is the "de facto standard pinout."
http://www.obd2cables.com/products/cable-j1962m-right-angle-to-db9f-4-3-ft.h...
Standards are so awesome, we have at least two!
I was surprised to see obd2cables.com claiming a standard that's different from what I expected from Mark's and Tesla's preferred gizmos. Fortunately, it should be easy to make a DB9 adapter to convert between the two standards should the need arise.
Tom
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Avesh, That's correct, the ATMA command will spew messages that match your filter (or all messages if you set the CAN filter mask to 000: ATCM 000) until you type a character to interrupt it. I usually hit space or return. Tom On 2/10/14, 11:05 PM, "Avesh Chauhan" <aveshcool@gmail.com> wrote: Dear Tom, Thanks for so nicely explaining your work. I tried almost similar steps using wifi enabled ELM 327 chipset on my car ( not a electric car ). However did not use the command Can Mask command you suggested . This is useful as with ATMA command , OBD adapter is not able to provide all data so filtering the data is awesome idea.So i believe it will continue to monitor particular parameter unless interrupted ??? @ Dear Mark and all : have you guys worked on ELM 329 chipset. I am not able to understand the difference between ELM 327 and 329. Any help is appreciated . Regards, Avesh On Tue, Feb 11, 2014 at 7:20 AM, Tom Saxton <tom@idleloop.com> wrote:
I bought a tiny $12 ELM327 Bluetooth gizmo that's listed among the devices compatible with LeafSpy.
http://www.amazon.com/gp/product/B008U1MOM8/
I also bought the OBDII Y cable that Mark suggested which looks like a high quality cable and it works.
http://www.amazon.com/gp/product/B00EEDOWU8/
At first I had zero success getting CAN messages from the Leaf's CAR-CAN bus using the ELM327; I got either nothing or garbage data with errors and buffer overflow messages.
This tutorial Mark suggested is inspiring, and illustrates a good general technique for figuring things out, but it has no information on how to get CAN data.
http://theksmith.com/technology/hack-vehicle-bus-cheap-easy-part-1/
I was then led astray by reading the ELM32X data sheet and the Wikipedia page on how OBDII CAN messages work.
http://elmelectronics.com/DSheets/ELM327DS.pdf http://en.wikipedia.org/wiki/OBD-II_PIDs
The specifics of how the messages are formatted is completely wrong for the Leaf. The 11-bit CAN ID values are not used to identify ECUs, they are the message identifiers. Instead of looking at CAN IDs in the range 7E0 to 7EF, you have to look at all CAN IDs from 001 to 7FF.
The next problem is that there is so much traffic on the Leaf's CAR-CAN bus, that a low-bandwidth unit like the cheap Bluetooth gizmos can't possibly keep up. I was able to determine that the output baud rate on the above gizmo is at most 38400 bps. To look at things, you need to filter to only get a subset of the constant stream of traffic on the CAR-CAN bus.
The trick is to use the ATCM (CAN mask) and ATCF (CAN filter) commands to filter for a single message. For example, to view message 0x5C5 which includes the Leaf's odometer value, first set up the chip with these commands:
ATZ ATH1 ATL1 ATS1 ATAL
Those commands in order: reset the chip to defaults, turn on message headers (which show the CAN ID), line endings between messages and spaces between bytes, and enables long messages. Then issue these commands:
ATCM 7FF ATCF 5C5 ATMA
The first two commands set the ELM327 to filter for a single message ID, 5C5, the third starts dumping them. You'll get data that looks like this:
5C5 44 00 3C BA 00 0C 00 00 5C5 44 00 3C BA 00 0C 00 00 5C5 44 00 3C BA 00 0C 00 00 ...
Type any character to stop the spewing of messages. The first group of three hex digits, 5C5, is the message ID, followed by the message data, bytes 0 through 7. According to the LEAF CAN message spreadsheet, skipping the first byte (44) and taking the next three (00 3C BA) yields the odometer. Sure enough, 003CBA is 15,546 in decimal, which is indeed our Leaf's odometer value.
I also confirmed the Gid value documented in message 5B3 for several Gid values in the low 200's.
To get an idea of what's happening on the CAR-CAN bus, I wrote a program that marches though all 2048 CAN ID values, listens for each message ID until either 20 messages have been collected or 2.01 seconds goes by with no messages, then moves on to the next ID. Using that program, I found 49 messages that happen between twice and one hundred times per second when the car is parked and turned on in accessory mode. Together, they total up to over 1500 messages per second. So, you'd need an output baud rate around 500,000 bps to monitor all messages, which is totally not happening with a $12 38400 bps gizmo.
I've attached a spreadsheet with the list of those messages. I have a text file with 20 sample messages of each type. I'm happy to share if anyone else wants to see it.
See the spreadsheet of known LEAF CAN messages to see what's known about what they contain.
https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1... 2xZSzlMUXc#gid=1
Unfortunately, with the sealed plastic $12 gizmo, there's no way to look at the EV-CAN bus, so that will have to wait until I get a better device. I'm considering these three:
Mark recommends: http://www.can232.com/?page_id=16 ($140 + cable + shipping) Roadster service techs use: http://gridconnect.com/can-usb.html ($255 + cable + shipping) Sparkfun: https://www.sparkfun.com/products/9555 ($74.85 with cable and shipping)
For connecting to the CAN bus, OVMS uses the same pin mapping as the device Mark and Tesla use. Sparkfun uses a different pin mapping which agrees with what OBD2cables.com says is the "de facto standard pinout."
http://www.obd2cables.com/products/cable-j1962m-right-angle-to-db9f-4-3-ft.htm> l
Standards are so awesome, we have at least two!
I was surprised to see obd2cables.com <http://obd2cables.com> claiming a standard that's different from what I expected from Mark's and Tesla's preferred gizmos. Fortunately, it should be easy to make a DB9 adapter to convert between the two standards should the need arise.
Tom
_______________________________________________ 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
Here's the latest update on my CAN bus tinkering... I picked up the Sparkfun board which is an STN1110 chip on a board with the support parts, a DB9 for connecting to an OBDII port and UART pinouts. I am using their FTDI UART-to-USB breakout board to talk to the STN1110 over USB. OBDII UART board: https://www.sparkfun.com/products/9555 FTDI Basic Breakout: https://www.sparkfun.com/products/9716 OBDII to DB9 cable: https://www.sparkfun.com/products/10087 Before using the OBD board, I updated the firmware to version 3.2.0, which requires running a program on a Windows machine. Except for doing the firmware update, I'm using a MacBook Air running 10.8.5. I did have to track down and install the FTDI drivers. The STN1110 claims to have a superior auto detect function to detect what protocol a vehicle is using on the OBD port, but it fails on the Leaf and the Roadster. I know the Leaf isn't a standard OBD protocol, and I'll bet the same is true of the Roadster. The Leaf won't respond to a 01 00 message, which I believe the STN1110 uses to detect the protocol. The $12 Bluetooth ELM327 clone works just fine at detecting the Leaf's CAN bus settings, but fails on the Roadster because it doesn't support CAN bus speeds above 500 kbps. For the Leaf, I can manually set the STN1110 to talk to the 11-bit 500 kbps CAR-CAN bus (AT SP 6) and set the UART speed to 921600 baud (ST BR 921600). With that setup, I can send a monitor all command (AT MA) and read/record 20,000 CAN messages in 11.813 seconds. My usual terminal program won't let me set the baud rate that high, but I'm using a custom program to talk to the device and add timestamps, and I can set the baud rate that high programmatically. I'm happy to share the source code if anyone wants it. As near as I can tell, there's no way to manually set the CAN bus parameters on the STN1110 nor does the data sheet give any hint at what maximum CAN speed the STN1110 supports. It says the UART supports up to 20 megabits per second. What's the point of that it only supports CAN up to 500 kbps? I've sent an email the the manufacturer, but haven't heard anything back. So the Sparkfun board is great for the Leaf, but the jury is still out for using it on the Roadster. Tom
participants (9)
-
Avesh Chauhan -
Håkon Markussen -
Jeremy Whaling -
Mark Webb-Johnson -
Nikki Gordon-Bloomfield -
Nikki Gordon-Bloomfield -
Nikolay Shishkov -
Robert Sharpe -
Tom Saxton