Hi, I ported over support for Gen 2 Chargers and polling for the battery Ah capacity and the "Hx" value in https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/9 3 Questions: In v2 we checked whether transmit mode was enabled, I'm not seeing similar logic in the Telsa Roadster module. I've commented out the checks in the leaf code for the time being. In v2 I abstracted the hardware interactions necesary to write to the canbus into a function void vehicle_nissanleaf_send_can_message(short id, unsigned char length, unsigned char *data). In v3 we call canbus::Write(const CAN_frame_t* p_frame). Do we want to add a similar simpler "send to this buffer with this can id" method to the canbus object? The Leaf doesn't use any of the extended can features so a simple interface for the simple case seems to make sense. For the moment I've implemented it within the leaf codebase, see void OvmsVehicleNissanLeaf::SendCanMessage(uint16_t id, uint8_t length, uint8_t *data) in the pull request. I've also porting over the remote command features, I like the interface presented to the car modules to implement these. I need to wait until tomorrow to test these on a real car so haven't sent a pull request yet. I'm very close to finished on porting the leaf support!
Tom,
In v2 we checked whether transmit mode was enabled, I'm not seeing similar logic in the Telsa Roadster module. I've commented out the checks in the leaf code for the time being.
In v3, I haven’t bother with listen-only. Looking at connections to api.openvehicles.com <http://api.openvehicles.com/>, all but 2 vehicles have feature 15=1 (and those are probably mistakes by the end-user).
In v2 I abstracted the hardware interactions necesary to write to the canbus into a function void vehicle_nissanleaf_send_can_message(short id, unsigned char length, unsigned char *data). In v3 we call canbus::Write(const CAN_frame_t* p_frame). Do we want to add a similar simpler "send to this buffer with this can id" method to the canbus object? The Leaf doesn't use any of the extended can features so a simple interface for the simple case seems to make sense. For the moment I've implemented it within the leaf codebase, see void OvmsVehicleNissanLeaf::SendCanMessage(uint16_t id, uint8_t length, uint8_t *data) in the pull request.
No harm in adding that, if you think it is useful. Please go ahead.
I've also porting over the remote command features, I like the interface presented to the car modules to implement these. I need to wait until tomorrow to test these on a real car so haven't sent a pull request yet. I'm very close to finished on porting the leaf support!
Fantastic. Tesla Roadster is at a similar state. Regards, Mark
On 19 Nov 2017, at 10:46 AM, Tom Parker <tom@carrott.org> wrote:
Hi,
I ported over support for Gen 2 Chargers and polling for the battery Ah capacity and the "Hx" value in https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/9
3 Questions:
In v2 we checked whether transmit mode was enabled, I'm not seeing similar logic in the Telsa Roadster module. I've commented out the checks in the leaf code for the time being.
In v2 I abstracted the hardware interactions necesary to write to the canbus into a function void vehicle_nissanleaf_send_can_message(short id, unsigned char length, unsigned char *data). In v3 we call canbus::Write(const CAN_frame_t* p_frame). Do we want to add a similar simpler "send to this buffer with this can id" method to the canbus object? The Leaf doesn't use any of the extended can features so a simple interface for the simple case seems to make sense. For the moment I've implemented it within the leaf codebase, see void OvmsVehicleNissanLeaf::SendCanMessage(uint16_t id, uint8_t length, uint8_t *data) in the pull request.
I've also porting over the remote command features, I like the interface presented to the car modules to implement these. I need to wait until tomorrow to test these on a real car so haven't sent a pull request yet.
I'm very close to finished on porting the leaf support!
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 20/11/17 02:49, Mark Webb-Johnson wrote:
In v3, I haven’t bother with listen-only. Looking at connections to api.openvehicles.com <http://api.openvehicles.com>, all but 2 vehicles have feature 15=1 (and those are probably mistakes by the end-user).
OK I won't worry about porting that code.
In v2 I abstracted the hardware interactions necesary to write to the canbus into a function void vehicle_nissanleaf_send_can_message(short id, unsigned char length, unsigned char *data). In v3 we call canbus::Write(const CAN_frame_t* p_frame). Do we want to add a similar simpler "send to this buffer with this can id" method to the canbus object? The Leaf doesn't use any of the extended can features so a simple interface for the simple case seems to make sense. For the moment I've implemented it within the leaf codebase, see void OvmsVehicleNissanLeaf::SendCanMessage(uint16_t id, uint8_t length, uint8_t *data) in the pull request.
No harm in adding that, if you think it is useful. Please go ahead.
I've updated https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/9 I used method overloading, which I've previously learnt isn't as straightforward as it is in Java. Please advise if this is an appropriate way to add two Write methods to the canbus object.
Tom, For your canbus::Write, the approach is reasonable and useful. But, you are missing the message type (standard or extended). You are using uint16_t for the id, so only support standard. Perhaps change the name to canbus::WriteStandard(…), and also have a canbus::WriteExtended(uint32_t id, …)? Regarding the OvmsVehicleNissanLeaf Ticker functions, you don’t need to register the event for these. Tickers for 1, 10, 60, 300, 600 and 3600 are already implemented in the base class. You just need to make a void TickerXXX(uint32_t ticker) function in your code, and it will get called appropriately. Have a look at vehicle_demo.{h,cpp} for an example. Regards, Mark
On 26 Nov 2017, at 6:06 AM, Tom Parker <tom@carrott.org> wrote:
On 20/11/17 02:49, Mark Webb-Johnson wrote:
In v3, I haven’t bother with listen-only. Looking at connections to api.openvehicles.com <http://api.openvehicles.com/>, all but 2 vehicles have feature 15=1 (and those are probably mistakes by the end-user).
OK I won't worry about porting that code.
In v2 I abstracted the hardware interactions necesary to write to the canbus into a function void vehicle_nissanleaf_send_can_message(short id, unsigned char length, unsigned char *data). In v3 we call canbus::Write(const CAN_frame_t* p_frame). Do we want to add a similar simpler "send to this buffer with this can id" method to the canbus object? The Leaf doesn't use any of the extended can features so a simple interface for the simple case seems to make sense. For the moment I've implemented it within the leaf codebase, see void OvmsVehicleNissanLeaf::SendCanMessage(uint16_t id, uint8_t length, uint8_t *data) in the pull request.
No harm in adding that, if you think it is useful. Please go ahead.
I've updated https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/9 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/9>
I used method overloading, which I've previously learnt isn't as straightforward as it is in Java. Please advise if this is an appropriate way to add two Write methods to the canbus object.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 27/11/17 13:50, Mark Webb-Johnson wrote:
For your canbus::Write, the approach is reasonable and useful. But, you are missing the message type (standard or extended). You are using uint16_t for the id, so only support standard. Perhaps change the name to canbus::WriteStandard(…), and also have a canbus::WriteExtended(uint32_t id, …)?
I renamed it WriteStandard and added a similar WriteExtended. I tested the WriteExtended and it seems to work on my desktop can bus setup. I haven't tried with anything else.
Regarding the OvmsVehicleNissanLeaf Ticker functions, you don’t need to register the event for these. Tickers for 1, 10, 60, 300, 600 and 3600 are already implemented in the base class. You just need to make a void TickerXXX(uint32_t ticker) function in your code, and it will get called appropriately. Have a look at vehicle_demo.{h,cpp} for an example.
Nice, I've updated them. See https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/9
participants (2)
-
Mark Webb-Johnson -
Tom Parker