Hi As a owner of a i-Miev I'm interested in OVMS support for the i-Miev/C-Zero/iOn EV. Has anyone looked into supporting those EV? I'm planing to start looking into adding support for those EV. And asking for help to add a vehicle plug-in module stub for those cars, so that naming and so on is correct. Best regards Thomas B
Hi Thomas, I believe there are several people on the list with the Mitsubishi i and derived cars, although there's not a hub stub yet for that car. Maybe Mark could start one? Nikki. On 29 Apr 2013, at 06:56, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi
As a owner of a i-Miev I'm interested in OVMS support for the i-Miev/C-Zero/iOn EV.
Has anyone looked into supporting those EV?
I'm planing to start looking into adding support for those EV. And asking for help to add a vehicle plug-in module stub for those cars, so that naming and so on is correct.
Best regards Thomas B
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Thomas, Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there. It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible: Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility: SOC - battery state of charge - car_SOC Car On/Off (ignition switch, or Park/Drive gear lever) - car_doors1 [bit7] Car Charging (true or false) - car_doors1 [bit 4] If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself. What vehicle two-character abbreviation do you think is suitable: IM or MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster). If you can let me have the can bus specs and information on the above 3 messages, I will create you a stub vehicle implementation. Regards, Mark. P.S. With reference to the development guide (https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/OVM...), these are the current set of parameters that OVMS supports. Vehicle Module Development Checklists Development Checklists You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these. Parameter Purpose Vehicle Support Notes Vehicle Identification car_type Vehicle type identified car_vin Vehicle VIN Parameter Purpose Vehicle Support Notes GPS Status Vehicle GPS Does the vehicle have a built-in GPS? If so, complete the following. car_gpslock Set to record GPS lock car_stale_gps Denotes GPS data staleness car_latitude Latitude of the vehicle car_longitude Longitude of the vehicle car_direction Direction of the vehicle car_altitude Altitude of the vehicle Parameter Purpose Vehicle Support Notes Tire Pressure Monitoring System TPMS Does the vehicle have a TPMS? If so, complete the following. car_stale_tpms Denotes TPMS data staleness car_tpms_t The temperatures of each wheel car_tpms_p The pressures of each wheel Parameter Purpose Vehicle Support Notes Driving Status car_doors1 [bit7] Set if the car ignition is ON car_speed The speed of the vehicle car_trip The vehicle trip counter car_odometer The vehicle odometer Parameter Purpose Vehicle Support Notes Vehicle Environment car_stale_ambient Ambient temperature staleness car_ambient_temp Ambient temperature car_stale_temps Other Temperature staleness car_tpem Temperature of the PEM car_tmotor Temperature of the MOTOR car_tbattery Temperature of the BATTERY car_doors1 [bit 0] Set if front left door OPEN car_doors1 [bit 1] Set if front right door OPEN car_doors2 [bit 6] Set if bonnet is OPEN car_doors2 [bit 7] Set if trunk is OPEN car_doors1 [bit 2] Set if charge port is OPEN car_doors1 [bit 6] Set if handbrake is ON car_doors2 [bit 5] Set if headlights ON car_doors3 [bit 1] Set if vehicle is AWAKE (or if not supported just follow ignition) car_doors2 [bit 4] Set if valet mode is ENABLED car_doors2 [bit 3] Set if vehicle is LOCKED car_lockstate 4=locked, 5=unlocked (deprecated) car_doors4 [bit 2] Set if alarm SOUNDING car_time Time (in seconds) car_parktime Time (seconds) vehicle parked Parameter Purpose Vehicle Support Notes Battery Status car_SOC State of charge percentage car_idealrange Ideal range car_estrange Estimated range Parameter Purpose Vehicle Support Notes Charging Status car_doors1 [bit 3] Set if pilot signal ON car_doors1 [bit 4] Set if vehicle CHARGING car_linevoltage Line voltage while charging car_chargecurrent Line current while charging car_chargemode Vehicle Mode car_chargestate Charging state car_chargesubstate Charging sub-state car_chargelimit Charge current limit car_chargeduration Charge duration (minutes) car_chargekwh Charge kWh put into battery car_stale_timer Charge timer staleness car_timermode Charge timer mode car_timerstart Charge timer schedule On 29 Apr, 2013, at 1:56 PM, Thomas Bergo wrote:
Hi
As a owner of a i-Miev I'm interested in OVMS support for the i-Miev/C-Zero/iOn EV.
Has anyone looked into supporting those EV?
I'm planing to start looking into adding support for those EV. And asking for help to add a vehicle plug-in module stub for those cars, so that naming and so on is correct.
Best regards Thomas B
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
In addition, there's this forum -- http://myimiev.com/forum/viewtopic.php?p=4409 -- which details some of the CAN bus stuff. And some pre-existing work: http://myimiev.com/forum/viewtopic.php?p=4817 Nikki. On 29 Apr 2013, at 07:20, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Thomas,
Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there.
It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible:
Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility:
SOC - battery state of charge - car_SOC Car On/Off (ignition switch, or Park/Drive gear lever) - car_doors1 [bit7] Car Charging (true or false) - car_doors1 [bit 4]
If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself.
What vehicle two-character abbreviation do you think is suitable: IM or MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster).
If you can let me have the can bus specs and information on the above 3 messages, I will create you a stub vehicle implementation.
Regards, Mark.
P.S. With reference to the development guide (https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/OVM...), these are the current set of parameters that OVMS supports.
Vehicle Module Development Checklists
Development Checklists
You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these.
Parameter
Purpose
Vehicle Support Notes
Vehicle Identification
car_type
Vehicle type identified
car_vin
Vehicle VIN
Parameter
Purpose
Vehicle Support Notes
GPS Status
Vehicle GPS
Does the vehicle have a built-in GPS? If so, complete the following.
car_gpslock
Set to record GPS lock
car_stale_gps
Denotes GPS data staleness
car_latitude
Latitude of the vehicle
car_longitude
Longitude of the vehicle
car_direction
Direction of the vehicle
car_altitude
Altitude of the vehicle
Parameter
Purpose
Vehicle Support Notes
Tire Pressure Monitoring System
TPMS
Does the vehicle have a TPMS? If so, complete the following.
car_stale_tpms
Denotes TPMS data staleness
car_tpms_t
The temperatures of each wheel
car_tpms_p
The pressures of each wheel
Parameter
Purpose
Vehicle Support Notes
Driving Status
car_doors1 [bit7]
Set if the car ignition is ON
car_speed
The speed of the vehicle
car_trip
The vehicle trip counter
car_odometer
The vehicle odometer
Parameter
Purpose
Vehicle Support Notes
Vehicle Environment
car_stale_ambient
Ambient temperature staleness
car_ambient_temp
Ambient temperature
car_stale_temps
Other Temperature staleness
car_tpem
Temperature of the PEM
car_tmotor
Temperature of the MOTOR
car_tbattery
Temperature of the BATTERY
car_doors1 [bit 0]
Set if front left door OPEN
car_doors1 [bit 1]
Set if front right door OPEN
car_doors2 [bit 6]
Set if bonnet is OPEN
car_doors2 [bit 7]
Set if trunk is OPEN
car_doors1 [bit 2]
Set if charge port is OPEN
car_doors1 [bit 6]
Set if handbrake is ON
car_doors2 [bit 5]
Set if headlights ON
car_doors3 [bit 1]
Set if vehicle is AWAKE (or if not supported just follow ignition)
car_doors2 [bit 4]
Set if valet mode is ENABLED
car_doors2 [bit 3]
Set if vehicle is LOCKED
car_lockstate
4=locked, 5=unlocked (deprecated)
car_doors4 [bit 2]
Set if alarm SOUNDING
car_time
Time (in seconds)
car_parktime
Time (seconds) vehicle parked
Parameter
Purpose
Vehicle Support Notes
Battery Status
car_SOC
State of charge percentage
car_idealrange
Ideal range
car_estrange
Estimated range
Parameter
Purpose
Vehicle Support Notes
Charging Status
car_doors1 [bit 3]
Set if pilot signal ON
car_doors1 [bit 4]
Set if vehicle CHARGING
car_linevoltage
Line voltage while charging
car_chargecurrent
Line current while charging
car_chargemode
Vehicle Mode
car_chargestate
Charging state
car_chargesubstate
Charging sub-state
car_chargelimit
Charge current limit
car_chargeduration
Charge duration (minutes)
car_chargekwh
Charge kWh put into battery
car_stale_timer
Charge timer staleness
car_timermode
Charge timer mode
car_timerstart
Charge timer schedule
On 29 Apr, 2013, at 1:56 PM, Thomas Bergo wrote:
Hi
As a owner of a i-Miev I'm interested in OVMS support for the i-Miev/C-Zero/iOn EV.
Has anyone looked into supporting those EV?
I'm planing to start looking into adding support for those EV. And asking for help to add a vehicle plug-in module stub for those cars, so that naming and so on is correct.
Best regards Thomas B
_______________________________________________ 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, So far the following CAN messages is discovered by Priusfan published on myimiev forum: SOC RPM Range Battery current Battery voltage Speed Odo Battery cell voltage Battery cell temperature So we still have to find Car On/Off and the charging status. Those messages are available as Mitsubishi has made a CAN Gateway where those data is provided. http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf Regarding the two-character abbreviation I think Brand-Model (MI) as TR and RT is most intuitive. So my vote goes to MI. I'm interested in using the OVMS v1 HW for logging of CAN messages. How to pay for postage? Regards, Thomas mandag 29. april 2013 skrev Mark Webb-Johnson følgende:
Thomas,
Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there.
It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible:
Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility:
1. SOC - battery state of charge - *car_SOC* 2. Car On/Off (ignition switch, or Park/Drive gear lever) - *car_doors1 [bit7]* 3. Car Charging (true or false) - *car_doors1 [bit 4]*
If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself.
What vehicle two-character abbreviation do you think is suitable: IM or MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster).
If you can let me have the can bus specs and information on the above 3 messages, I will create you a stub vehicle implementation.
Regards, Mark.
P.S. With reference to the development guide ( https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/OVM...), these are the current set of parameters that OVMS supports.
Vehicle Module Development Checklists Development Checklists
****
You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these.
*Parameter*
*Purpose*
*Vehicle Support Notes*
* *
*Vehicle Identification*
car_type****
Vehicle type identified****
car_vin****
Vehicle VIN****
** **
*Parameter*
*Purpose*
*Vehicle Support Notes*
* *
*GPS Status*****
Vehicle GPS****
Does the vehicle have a built-in GPS? If so, complete the following.****
car_gpslock****
So we still have to find Car On/Off and the charging status.
Worst case for car on/off, we use parked/notparked (gear shift position). That is normally relatively easy to find. The "CAN gateway" document you quote gives message transmission intervals - that is a big clue and should help to narrow things down. Very feasible. I'll make the stub tonight, based on "MI" as the vehicle type.
I'm interested in using the OVMS v1 HW for logging of CAN messages. How to pay for postage?
Not sure where you are, but US$5 should cover it (the boards are pretty light). Just paypal to mark@webb-johnson.net, then let me know your address (by eMail to mark@webb-johnson.net). Same goes for anyone else who wants one of these. I myself am trying to use one as a CAN-Bluetooth gateway (using an HC-05 style bluetooth module), as a proof-of-concept for the in-car real-time OVMS display. Regards, Mark. On 30 Apr, 2013, at 5:29 AM, Thomas Bergo wrote:
Hi,
So far the following CAN messages is discovered by Priusfan published on myimiev forum:
SOC RPM Range Battery current Battery voltage Speed Odo Battery cell voltage Battery cell temperature
So we still have to find Car On/Off and the charging status.
Those messages are available as Mitsubishi has made a CAN Gateway where those data is provided. http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf
Regarding the two-character abbreviation I think Brand-Model (MI) as TR and RT is most intuitive. So my vote goes to MI.
I'm interested in using the OVMS v1 HW for logging of CAN messages. How to pay for postage?
Regards, Thomas
mandag 29. april 2013 skrev Mark Webb-Johnson følgende: Thomas,
Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there.
It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible:
Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility:
SOC - battery state of charge - car_SOC Car On/Off (ignition switch, or Park/Drive gear lever) - car_doors1 [bit7] Car Charging (true or false) - car_doors1 [bit 4]
If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself.
What vehicle two-character abbreviation do you think is suitable: IM or MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster).
If you can let me have the can bus specs and information on the above 3 messages, I will create you a stub vehicle implementation.
Regards, Mark.
P.S. With reference to the development guide (https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/OVM...), these are the current set of parameters that OVMS supports.
Vehicle Module Development Checklists
Development Checklists
You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these.
Parameter
Purpose
Vehicle Support Notes
Vehicle Identification
car_type
Vehicle type identified
car_vin
Vehicle VIN
Parameter
Purpose
Vehicle Support Notes
GPS Status
Vehicle GPS
Does the vehicle have a built-in GPS? If so, complete the following.
car_gpslock
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I've created a stub file (vehicle_mitsubishi.c), and pushed to github. If you pull head you'll get it. This is just a stub. You'll need to setup the CAN IDs you want to receive (in the filters), and then add the decoding logic to update the car_* variables. Regards, Mark. Regards, Mark. On 30 Apr, 2013, at 5:29 AM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi,
So far the following CAN messages is discovered by Priusfan published on myimiev forum:
SOC RPM Range Battery current Battery voltage Speed Odo Battery cell voltage Battery cell temperature
So we still have to find Car On/Off and the charging status.
Those messages are available as Mitsubishi has made a CAN Gateway where those data is provided. http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf
Regarding the two-character abbreviation I think Brand-Model (MI) as TR and RT is most intuitive. So my vote goes to MI.
I'm interested in using the OVMS v1 HW for logging of CAN messages. How to pay for postage?
Regards, Thomas
mandag 29. april 2013 skrev Mark Webb-Johnson følgende: Thomas,
Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there.
It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible:
Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility:
SOC - battery state of charge - car_SOC Car On/Off (ignition switch, or Park/Drive gear lever) - car_doors1 [bit7] Car Charging (true or false) - car_doors1 [bit 4]
If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself.
What vehicle two-character abbreviation do you think is suitable: IM or MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster).
If you can let me have the can bus specs and information on the above 3 messages, I will create you a stub vehicle implementation.
Regards, Mark.
P.S. With reference to the development guide (https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/OVM...), these are the current set of parameters that OVMS supports.
Vehicle Module Development Checklists
Development Checklists
You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these.
Parameter
Purpose
Vehicle Support Notes
Vehicle Identification
car_type
Vehicle type identified
car_vin
Vehicle VIN
Parameter
Purpose
Vehicle Support Notes
GPS Status
Vehicle GPS
Does the vehicle have a built-in GPS? If so, complete the following.
car_gpslock
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Finally got some time to work on the i-Miev implementation. But I'm facing some issues setting up the car module. - SMS is working and are able to send messages to the car module and get answers. - Problem getting the GPRS to work. Get "Not connected" and "Not connected (0x0041) when sending GPRS? - No connection from the iOS app to server. Only red flashing antenna. Any advise? Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT? Regards, Thomas 2013/5/1 Mark Webb-Johnson <mark@webb-johnson.net>
I've created a stub file (vehicle_mitsubishi.c), and pushed to github. If you pull head you'll get it. This is just a stub. You'll need to setup the CAN IDs you want to receive (in the filters), and then add the decoding logic to update the car_* variables.
Regards, Mark.
Regards, Mark.
On 30 Apr, 2013, at 5:29 AM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi,
So far the following CAN messages is discovered by Priusfan published on myimiev forum:
SOC RPM Range Battery current Battery voltage Speed Odo Battery cell voltage Battery cell temperature
So we still have to find Car On/Off and the charging status.
Those messages are available as Mitsubishi has made a CAN Gateway where those data is provided. http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf
Regarding the two-character abbreviation I think Brand-Model (MI) as TR and RT is most intuitive. So my vote goes to MI.
I'm interested in using the OVMS v1 HW for logging of CAN messages. How to pay for postage?
Regards, Thomas
mandag 29. april 2013 skrev Mark Webb-Johnson følgende:
Thomas,
Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there.
It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible:
Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility:
1. SOC - battery state of charge - *car_SOC* 2. Car On/Off (ignition switch, or Park/Drive gear lever) - *car_doors1 [bit7]* 3. Car Charging (true or false) - *car_doors1 [bit 4]*
If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself.
What vehicle two-character abbreviation do you think is suitable: IM or MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster).
If you can let me have the can bus specs and information on the above 3 messages, I will create you a stub vehicle implementation.
Regards, Mark.
P.S. With reference to the development guide ( https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/OVM...), these are the current set of parameters that OVMS supports.
Vehicle Module Development Checklists Development Checklists
****
You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these.
*Parameter*
*Purpose*
*Vehicle Support Notes*
* *
*Vehicle Identification*
car_type****
Vehicle type identified****
car_vin****
Vehicle VIN****
** **
*Parameter*
*Purpose*
*Vehicle Support Notes*
* *
*GPS Status*****
Vehicle GPS****
Does the vehicle have a built-in GPS? If so, complete the following.****
car_gpslock****
_______________________________________________ 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
Do you have the physical switch on the board in the right location? That messed me up when I set up the new V2 device for our car. Slide it to the position nearest the white connector (v1) or away from the edge of the board (v2). Tom On 9/15/13 2:02 PM, "Thomas Bergo" <thomas.bergo@gmail.com> wrote:
Finally got some time to work on the i-Miev implementation. But I'm facing some issues setting up the car module. - SMS is working and are able to send messages to the car module and get answers. - Problem getting the GPRS to work. Get "Not connected" and "Not connected (0x0041) when sending GPRS? - No connection from the iOS app to server. Only red flashing antenna.
Any advise?
Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?
Regards, Thomas
2013/5/1 Mark Webb-Johnson <mark@webb-johnson.net>
I've created a stub file (vehicle_mitsubishi.c), and pushed to github. If you pull head you'll get it. This is just a stub. You'll need to setup the CAN IDs you want to receive (in the filters), and then add the decoding logic to update the car_* variables.
Regards, Mark.
Regards, Mark.
On 30 Apr, 2013, at 5:29 AM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi, So far the following CAN messages is discovered by Priusfan published on myimiev forum:
SOC RPM Range Battery current Battery voltage Speed Odo Battery cell voltage Battery cell temperature
So we still have to find Car On/Off and the charging status.
Those messages are available as Mitsubishi has made a CAN Gateway where those data is provided. http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf
Regarding the two-character abbreviation I think Brand-Model (MI) as TR and RT is most intuitive. So my vote goes to MI.
I'm interested in using the OVMS v1 HW for logging of CAN messages. How to pay for postage?
Regards, Thomas
mandag 29. april 2013 skrev Mark Webb-Johnson følgende:
Thomas, Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there.
It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible:
Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility:
1. SOC - battery state of charge - car_SOC 2. Car On/Off (ignition switch, or Park/Drive gear lever) - car_doors1 [bit7] 3. Car Charging (true or false) - car_doors1 [bit 4]
If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself.
What vehicle two-character abbreviation do you think is suitable: IM or MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster).
If you can let me have the can bus specs and information on the above 3 messages, I will create you a stub vehicle implementation.
Regards, Mark.
P.S. With reference to the development guide (https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/ OVMS_Development.pdf), these are the current set of parameters that OVMS supports.
Vehicle Module Development Checklists Development Checklists
You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these. Parameter Purpose Vehicle Support Notes
Vehicle Identification car_type Vehicle type identified
car_vin Vehicle VIN
Parameter Purpose Vehicle Support Notes
GPS Status Vehicle GPS Does the vehicle have a built-in GPS? If so, complete the following.
car_gpslock
_______________________________________________ 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
FYI - I have a C-Zero and OVMS with programmer and OBD logger. I have done a bit of work, but am rather limited in time that I can spend on this project, but am able to help out a bit from time to time. I have been planning a small application to hunt through all the CAN traffic for candidate data, but this is way behind! Matt Beard On 15 September 2013 22:02, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Finally got some time to work on the i-Miev implementation.
But I'm facing some issues setting up the car module. - SMS is working and are able to send messages to the car module and get answers. - Problem getting the GPRS to work. Get "Not connected" and "Not connected (0x0041) when sending GPRS? - No connection from the iOS app to server. Only red flashing antenna.
Any advise?
Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?
Regards, Thomas
2013/5/1 Mark Webb-Johnson <mark@webb-johnson.net>
I've created a stub file (vehicle_mitsubishi.c), and pushed to github. If you pull head you'll get it. This is just a stub. You'll need to setup the CAN IDs you want to receive (in the filters), and then add the decoding logic to update the car_* variables.
Regards, Mark.
Regards, Mark.
On 30 Apr, 2013, at 5:29 AM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi,
So far the following CAN messages is discovered by Priusfan published on myimiev forum:
SOC RPM Range Battery current Battery voltage Speed Odo Battery cell voltage Battery cell temperature
So we still have to find Car On/Off and the charging status.
Those messages are available as Mitsubishi has made a CAN Gateway where those data is provided. http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf
Regarding the two-character abbreviation I think Brand-Model (MI) as TR and RT is most intuitive. So my vote goes to MI.
I'm interested in using the OVMS v1 HW for logging of CAN messages. How to pay for postage?
Regards, Thomas
mandag 29. april 2013 skrev Mark Webb-Johnson følgende:
Thomas,
Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there.
It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible:
Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility:
1. SOC - battery state of charge - *car_SOC* 2. Car On/Off (ignition switch, or Park/Drive gear lever) - *car_doors1 [bit7]* 3. Car Charging (true or false) - *car_doors1 [bit 4]*
If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself.
What vehicle two-character abbreviation do you think is suitable: IM or MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster).
If you can let me have the can bus specs and information on the above 3 messages, I will create you a stub vehicle implementation.
Regards, Mark.
P.S. With reference to the development guide ( https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/OVM...), these are the current set of parameters that OVMS supports.
Vehicle Module Development Checklists Development Checklists
****
You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these.
*Parameter*
*Purpose*
*Vehicle Support Notes*
* *
*Vehicle Identification*
car_type****
Vehicle type identified****
car_vin****
Vehicle VIN****
** **
*Parameter*
*Purpose*
*Vehicle Support Notes*
* *
*GPS Status*****
Vehicle GPS****
Does the vehicle have a built-in GPS? If so, complete the following.****
car_gpslock****
_______________________________________________ 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
As Tom, says, please double-check the little GSM/GPRS switch on the board, and make sure it is towards the inside of the board (away from the edge). Other than that, it is worth double-checking the basic configuration. You can send to me (mark@openvehicles.com), responses to the following SMS commands: STAT MODULE? SERVER? GPRS? DIAG Regards, Mark. On 16 Sep, 2013, at 5:02 AM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Finally got some time to work on the i-Miev implementation.
But I'm facing some issues setting up the car module. - SMS is working and are able to send messages to the car module and get answers. - Problem getting the GPRS to work. Get "Not connected" and "Not connected (0x0041) when sending GPRS? - No connection from the iOS app to server. Only red flashing antenna.
Any advise?
Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?
Regards, Thomas
2013/5/1 Mark Webb-Johnson <mark@webb-johnson.net>
I've created a stub file (vehicle_mitsubishi.c), and pushed to github. If you pull head you'll get it. This is just a stub. You'll need to setup the CAN IDs you want to receive (in the filters), and then add the decoding logic to update the car_* variables.
Regards, Mark.
Regards, Mark.
On 30 Apr, 2013, at 5:29 AM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi,
So far the following CAN messages is discovered by Priusfan published on myimiev forum:
SOC RPM Range Battery current Battery voltage Speed Odo Battery cell voltage Battery cell temperature
So we still have to find Car On/Off and the charging status.
Those messages are available as Mitsubishi has made a CAN Gateway where those data is provided. http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf
Regarding the two-character abbreviation I think Brand-Model (MI) as TR and RT is most intuitive. So my vote goes to MI.
I'm interested in using the OVMS v1 HW for logging of CAN messages. How to pay for postage?
Regards, Thomas
mandag 29. april 2013 skrev Mark Webb-Johnson følgende: Thomas,
Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there.
It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible:
Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility:
SOC - battery state of charge - car_SOC Car On/Off (ignition switch, or Park/Drive gear lever) - car_doors1 [bit7] Car Charging (true or false) - car_doors1 [bit 4]
If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself.
What vehicle two-character abbreviation do you think is suitable: IM or MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster).
If you can let me have the can bus specs and information on the above 3 messages, I will create you a stub vehicle implementation.
Regards, Mark.
P.S. With reference to the development guide (https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/OVM...), these are the current set of parameters that OVMS supports.
Vehicle Module Development Checklists
Development Checklists
You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these.
Parameter
Purpose
Vehicle Support Notes
Vehicle Identification
car_type
Vehicle type identified
car_vin
Vehicle VIN
Parameter
Purpose
Vehicle Support Notes
GPS Status
Vehicle GPS
Does the vehicle have a built-in GPS? If so, complete the following.
car_gpslock
_______________________________________________ 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
Thank you. The switch was the problem. Now I'm "live" in the iOS app. Now I need to debug my code. If anyone is interested my fork of the code is available at https://github.com/tbergo/Open-Vehicle-Monitoring-System/ Since I not get any updates, I suspect I have done something wrong setting up the filter part. Please feel free commenting and contribute. SW is not my strong side, as I'm mostly into HW. Regards, Thomas mandag 16. september 2013 skrev Mark Webb-Johnson følgende:
As Tom, says, please double-check the little GSM/GPRS switch on the board, and make sure it is towards the inside of the board (away from the edge).
Other than that, it is worth double-checking the basic configuration. You can send to me (mark@openvehicles.com <javascript:_e({}, 'cvml', 'mark@openvehicles.com');>), responses to the following SMS commands:
STAT MODULE? SERVER? GPRS? DIAG
Regards, Mark.
On 16 Sep, 2013, at 5:02 AM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Finally got some time to work on the i-Miev implementation.
But I'm facing some issues setting up the car module. - SMS is working and are able to send messages to the car module and get answers. - Problem getting the GPRS to work. Get "Not connected" and "Not connected (0x0041) when sending GPRS? - No connection from the iOS app to server. Only red flashing antenna.
Any advise?
Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?
Regards, Thomas
2013/5/1 Mark Webb-Johnson <mark@webb-johnson.net>
I've created a stub file (vehicle_mitsubishi.c), and pushed to github. If you pull head you'll get it. This is just a stub. You'll need to setup the CAN IDs you want to receive (in the filters), and then add the decoding logic to update the car_* variables.
Regards, Mark.
Regards, Mark.
On 30 Apr, 2013, at 5:29 AM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi,
So far the following CAN messages is discovered by Priusfan published on myimiev forum:
SOC RPM Range Battery current Battery voltage Speed Odo Battery cell voltage Battery cell temperature
So we still have to find Car On/Off and the charging status.
Those messages are available as Mitsubishi has made a CAN Gateway where those data is provided. http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf
Regarding the two-character abbreviation I think Brand-Model (MI) as TR and RT is most intuitive. So my vote goes to MI.
I'm interested in using the OVMS v1 HW for logging of CAN messages. How to pay for postage?
Regards, Thomas
mandag 29. april 2013 skrev Mark Webb-Johnson følgende:
Thomas,
Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there.
It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible:
Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility:
1. SOC - battery state of charge - *car_SOC* 2. Car On/Off (ignition switch, or Park/Drive gear lever) - *car_doors1 [bit7]* 3. Car Charging (true or false) - *car_doors1 [bit 4]*
If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself.
What vehicle two-character abbreviation do you think is suitable: IM or MI? Exampl
Hi Thomas, *"Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?" * Are you able to read any CAN-bus values from your iMiEV? I experienced once at my Think City, that the Ovms-module did not read the CAN-bus at all; I got 0% SOC. The problem was I had two external CAN-devices connected at the same time (Duinomite Mega + OVMS). It worked fine when both modules were powered on at the same time, but Ovms failed to read the bus when the Duinomite Mega was powered off. Du you have access to any kind of can-reader tool? This can be used to verify that you are looking at the correct bytes. I've used P-CAN USB adapter http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 and PCANView http://www.computer-solutions.co.uk/gendev/can-basic-dll.htm You can use it to verify you have SOC in msg 0x374 byte 1. To understand the mask and filter, you have to consider the mask as a bit "enable" / "disable". Any zero in the mask bit disables that specific bit. The filter gives a range of bit combinations. Both mask an filter is 11 bit length (0-10), all 8 bits from SIDH + 3 most significant bits from SIDL Your Mask0 (RXM0) is 11111111 000 (0x7F8) which enables bit 3 to 10 Your Filter0 (RXF0) is 01100000 000 In combination with your mask0, this gives the message range from 0x300 to 0x3F8, which covers your messages. 01100000 000 -> 0x300 011111111 000 -> 0x3F8 (however you have an minor error in your comment 0x300 .. 0x3E0) The same goes for mask1 and filter2, filter3, filter4,which applies to poll1(). But you have to make sure that the mask1 enables sufficient number of bits for the corresponding filters. Your mask1 is 11111111 111 so that is OK. Your filter2 is 01010000 101 (0x285) which is OK Your filter 3 is 10000010 010 (0x412) which is OK You have yet not built any vehicle specific SMS function, so the STAT-sms is created in the net_msg.c file . I think it this file prints SOC to SMS regardless of the doorbit status. A hint is using the diag-port for sending SMS (saves you sms cost) for debuging). Br. Håkon 2013/9/15 Thomas Bergo <thomas.bergo@gmail.com>
Finally got some time to work on the i-Miev implementation.
But I'm facing some issues setting up the car module. - SMS is working and are able to send messages to the car module and get answers. - Problem getting the GPRS to work. Get "Not connected" and "Not connected (0x0041) when sending GPRS? - No connection from the iOS app to server. Only red flashing antenna.
Any advise?
Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?
Regards, Thomas
2013/5/1 Mark Webb-Johnson <mark@webb-johnson.net>
I've created a stub file (vehicle_mitsubishi.c), and pushed to github. If you pull head you'll get it. This is just a stub. You'll need to setup the CAN IDs you want to receive (in the filters), and then add the decoding logic to update the car_* variables.
Regards, Mark.
Regards, Mark.
On 30 Apr, 2013, at 5:29 AM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi,
So far the following CAN messages is discovered by Priusfan published on myimiev forum:
SOC RPM Range Battery current Battery voltage Speed Odo Battery cell voltage Battery cell temperature
So we still have to find Car On/Off and the charging status.
Those messages are available as Mitsubishi has made a CAN Gateway where those data is provided. http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf
Regarding the two-character abbreviation I think Brand-Model (MI) as TR and RT is most intuitive. So my vote goes to MI.
I'm interested in using the OVMS v1 HW for logging of CAN messages. How to pay for postage?
Regards, Thomas
mandag 29. april 2013 skrev Mark Webb-Johnson følgende:
Thomas,
Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there.
It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible:
Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility:
1. SOC - battery state of charge - *car_SOC* 2. Car On/Off (ignition switch, or Park/Drive gear lever) - *car_doors1 [bit7]* 3. Car Charging (true or false) - *car_doors1 [bit 4]*
If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself.
What vehicle two-character abbreviation do you think is suitable: IM or MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster).
If you can let me have the can bus specs and information on the above 3 messages, I will create you a stub vehicle implementation.
Regards, Mark.
P.S. With reference to the development guide ( https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/OVM...), these are the current set of parameters that OVMS supports.
Vehicle Module Development Checklists Development Checklists
You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these.
*Parameter*
*Purpose*
*Vehicle Support Notes*
* *
*Vehicle Identification*
car_type
Vehicle type identified
car_vin
Vehicle VIN
*Parameter*
*Purpose*
*Vehicle Support Notes*
* *
*GPS Status*
Vehicle GPS
Does the vehicle have a built-in GPS? If so, complete the following.
car_gpslock
_______________________________________________ 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 - nice clear answer. One other suggestion is that you can put "car_idealrange++; return TRUE;" and "car_estrange++; return TRUE;" in the poll0 and poll1 functions, near the top. A few STAT commands and you can see if the poll functions are actually being called. You can also put "car_idealrange=id; return TRUE;", etc, to get an idea of what IDs are being delivered. It is very nasty trying to debug interrupt handlers, but this approach can help. The diag port mentioned is shown here: http://www.youtube.com/watch?v=-24PoWtHVzk Regards, Mark. On 16 Sep, 2013, at 4:55 PM, Håkon Markussen <hakon.markussen@gmail.com> wrote:
Hi Thomas,
"Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?"
Are you able to read any CAN-bus values from your iMiEV?
I experienced once at my Think City, that the Ovms-module did not read the CAN-bus at all; I got 0% SOC. The problem was I had two external CAN-devices connected at the same time (Duinomite Mega + OVMS). It worked fine when both modules were powered on at the same time, but Ovms failed to read the bus when the Duinomite Mega was powered off.
Du you have access to any kind of can-reader tool? This can be used to verify that you are looking at the correct bytes. I've used P-CAN USB adapter http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 and PCANView http://www.computer-solutions.co.uk/gendev/can-basic-dll.htm
You can use it to verify you have SOC in msg 0x374 byte 1.
To understand the mask and filter, you have to consider the mask as a bit "enable" / "disable". Any zero in the mask bit disables that specific bit. The filter gives a range of bit combinations. Both mask an filter is 11 bit length (0-10), all 8 bits from SIDH + 3 most significant bits from SIDL
Your Mask0 (RXM0) is 11111111 000 (0x7F8) which enables bit 3 to 10 Your Filter0 (RXF0) is 01100000 000 In combination with your mask0, this gives the message range from 0x300 to 0x3F8, which covers your messages. 01100000 000 -> 0x300 011111111 000 -> 0x3F8 (however you have an minor error in your comment 0x300 .. 0x3E0)
The same goes for mask1 and filter2, filter3, filter4,which applies to poll1(). But you have to make sure that the mask1 enables sufficient number of bits for the corresponding filters. Your mask1 is 11111111 111 so that is OK. Your filter2 is 01010000 101 (0x285) which is OK Your filter 3 is 10000010 010 (0x412) which is OK
You have yet not built any vehicle specific SMS function, so the STAT-sms is created in the net_msg.c file . I think it this file prints SOC to SMS regardless of the doorbit status.
A hint is using the diag-port for sending SMS (saves you sms cost) for debuging).
Br. Håkon
2013/9/15 Thomas Bergo <thomas.bergo@gmail.com> Finally got some time to work on the i-Miev implementation.
But I'm facing some issues setting up the car module. - SMS is working and are able to send messages to the car module and get answers. - Problem getting the GPRS to work. Get "Not connected" and "Not connected (0x0041) when sending GPRS? - No connection from the iOS app to server. Only red flashing antenna.
Any advise?
Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?
Regards, Thomas
2013/5/1 Mark Webb-Johnson <mark@webb-johnson.net>
I've created a stub file (vehicle_mitsubishi.c), and pushed to github. If you pull head you'll get it. This is just a stub. You'll need to setup the CAN IDs you want to receive (in the filters), and then add the decoding logic to update the car_* variables.
Regards, Mark.
Regards, Mark.
On 30 Apr, 2013, at 5:29 AM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi,
So far the following CAN messages is discovered by Priusfan published on myimiev forum:
SOC RPM Range Battery current Battery voltage Speed Odo Battery cell voltage Battery cell temperature
So we still have to find Car On/Off and the charging status.
Those messages are available as Mitsubishi has made a CAN Gateway where those data is provided. http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf
Regarding the two-character abbreviation I think Brand-Model (MI) as TR and RT is most intuitive. So my vote goes to MI.
I'm interested in using the OVMS v1 HW for logging of CAN messages. How to pay for postage?
Regards, Thomas
mandag 29. april 2013 skrev Mark Webb-Johnson følgende: Thomas,
Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there.
It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible:
Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility:
SOC - battery state of charge - car_SOC Car On/Off (ignition switch, or Park/Drive gear lever) - car_doors1 [bit7] Car Charging (true or false) - car_doors1 [bit 4]
If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself.
What vehicle two-character abbreviation do you think is suitable: IM or MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster).
If you can let me have the can bus specs and information on the above 3 messages, I will create you a stub vehicle implementation.
Regards, Mark.
P.S. With reference to the development guide (https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/OVM...), these are the current set of parameters that OVMS supports.
Vehicle Module Development Checklists
Development Checklists
You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these.
Parameter
Purpose
Vehicle Support Notes
Vehicle Identification
car_type
Vehicle type identified
car_vin
Vehicle VIN
Parameter
Purpose
Vehicle Support Notes
GPS Status
Vehicle GPS
Does the vehicle have a built-in GPS? If so, complete the following.
car_gpslock
_______________________________________________ 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
Thank you for your help. Fixed some typos and now ODO updates in "STAT?" ODO is still wrong, but at least i get updates. No luck with SOC so far. Have verified that the PID and the data is correct by using a CAN interface on my laptop. Will do some more debugging to verify that both poll0 and poll1 is called. Is there a simple way to print out a value to the DIAG port for debugging? Regards, Thomas 2013/9/17 Mark Webb-Johnson <mark@webb-johnson.net>
Thanks, Håkon - nice clear answer.
One other suggestion is that you can put "car_idealrange++; return TRUE;" and "car_estrange++; return TRUE;" in the poll0 and poll1 functions, near the top. A few STAT commands and you can see if the poll functions are actually being called. You can also put "car_idealrange=id; return TRUE;", etc, to get an idea of what IDs are being delivered. It is very nasty trying to debug interrupt handlers, but this approach can help.
The diag port mentioned is shown here:
http://www.youtube.com/watch?v=-24PoWtHVzk
Regards, Mark.
On 16 Sep, 2013, at 4:55 PM, Håkon Markussen <hakon.markussen@gmail.com> wrote:
Hi Thomas,
*"Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?" *
Are you able to read any CAN-bus values from your iMiEV?
I experienced once at my Think City, that the Ovms-module did not read the CAN-bus at all; I got 0% SOC. The problem was I had two external CAN-devices connected at the same time (Duinomite Mega + OVMS). It worked fine when both modules were powered on at the same time, but Ovms failed to read the bus when the Duinomite Mega was powered off.
Du you have access to any kind of can-reader tool? This can be used to verify that you are looking at the correct bytes. I've used P-CAN USB adapter http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 and PCANView http://www.computer-solutions.co.uk/gendev/can-basic-dll.htm
You can use it to verify you have SOC in msg 0x374 byte 1.
To understand the mask and filter, you have to consider the mask as a bit "enable" / "disable". Any zero in the mask bit disables that specific bit. The filter gives a range of bit combinations. Both mask an filter is 11 bit length (0-10), all 8 bits from SIDH + 3 most significant bits from SIDL
Your Mask0 (RXM0) is 11111111 000 (0x7F8) which enables bit 3 to 10 Your Filter0 (RXF0) is 01100000 000 In combination with your mask0, this gives the message range from 0x300 to 0x3F8, which covers your messages. 01100000 000 -> 0x300 011111111 000 -> 0x3F8 (however you have an minor error in your comment 0x300 .. 0x3E0)
The same goes for mask1 and filter2, filter3, filter4,which applies to poll1(). But you have to make sure that the mask1 enables sufficient number of bits for the corresponding filters. Your mask1 is 11111111 111 so that is OK. Your filter2 is 01010000 101 (0x285) which is OK Your filter 3 is 10000010 010 (0x412) which is OK
You have yet not built any vehicle specific SMS function, so the STAT-sms is created in the net_msg.c file . I think it this file prints SOC to SMS regardless of the doorbit status.
A hint is using the diag-port for sending SMS (saves you sms cost) for debuging).
Br. Håkon
2013/9/15 Thomas Bergo <thomas.bergo@gmail.com>
Finally got some time to work on the i-Miev implementation.
But I'm facing some issues setting up the car module. - SMS is working and are able to send messages to the car module and get answers. - Problem getting the GPRS to work. Get "Not connected" and "Not connected (0x0041) when sending GPRS? - No connection from the iOS app to server. Only red flashing antenna.
Any advise?
Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?
Regards, Thomas
2013/5/1 Mark Webb-Johnson <mark@webb-johnson.net>
I've created a stub file (vehicle_mitsubishi.c), and pushed to github. If you pull head you'll get it. This is just a stub. You'll need to setup the CAN IDs you want to receive (in the filters), and then add the decoding logic to update the car_* variables.
Regards, Mark.
Regards, Mark.
On 30 Apr, 2013, at 5:29 AM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi,
So far the following CAN messages is discovered by Priusfan published on myimiev forum:
SOC RPM Range Battery current Battery voltage Speed Odo Battery cell voltage Battery cell temperature
So we still have to find Car On/Off and the charging status.
Those messages are available as Mitsubishi has made a CAN Gateway where those data is provided. http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf
Regarding the two-character abbreviation I think Brand-Model (MI) as TR and RT is most intuitive. So my vote goes to MI.
I'm interested in using the OVMS v1 HW for logging of CAN messages. How to pay for postage?
Regards, Thomas
mandag 29. april 2013 skrev Mark Webb-Johnson følgende:
Thomas,
Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there.
It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible:
Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility:
1. SOC - battery state of charge - *car_SOC* 2. Car On/Off (ignition switch, or Park/Drive gear lever) - *car_doors1 [bit7]* 3. Car Charging (true or false) - *car_doors1 [bit 4]*
If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself.
What vehicle two-character abbreviation do you think is suitable: IM or MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster).
If you can let me have the can bus specs and information on the above 3 messages, I will create you a stub vehicle implementation.
Regards, Mark.
P.S. With reference to the development guide ( https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/OVM...), these are the current set of parameters that OVMS supports.
Vehicle Module Development Checklists Development Checklists
You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these.
*Parameter*
*Purpose*
*Vehicle Support Notes*
* *
*Vehicle Identification*
car_type
Vehicle type identified
car_vin
Vehicle VIN
*Parameter*
*Purpose*
*Vehicle Support Notes*
* *
*GPS Status*
Vehicle GPS
Does the vehicle have a built-in GPS? If so, complete the following.
car_gpslock
_______________________________________________ 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
Is there a simple way to print out a value to the DIAG port for debugging?
You can just net_puts it, normally prefixed with a "#" sign as a comment. Have a look in diag.c for lots of examples. You will need to type 'ATE1' when going into diag mode, to get the echo output. The way it works is that you send the command to the modem (net_puts()), which discards it as unrecognised, but echos it back to the terminal. But, you can't do that in interrupt handlers - only in normal ticker(), or message handler, style code Regards, Mark. On 18 Sep, 2013, at 8:22 PM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Thank you for your help.
Fixed some typos and now ODO updates in "STAT?" ODO is still wrong, but at least i get updates. No luck with SOC so far.
Have verified that the PID and the data is correct by using a CAN interface on my laptop.
Will do some more debugging to verify that both poll0 and poll1 is called.
Is there a simple way to print out a value to the DIAG port for debugging?
Regards, Thomas
2013/9/17 Mark Webb-Johnson <mark@webb-johnson.net>
Thanks, Håkon - nice clear answer.
One other suggestion is that you can put "car_idealrange++; return TRUE;" and "car_estrange++; return TRUE;" in the poll0 and poll1 functions, near the top. A few STAT commands and you can see if the poll functions are actually being called. You can also put "car_idealrange=id; return TRUE;", etc, to get an idea of what IDs are being delivered. It is very nasty trying to debug interrupt handlers, but this approach can help.
The diag port mentioned is shown here:
http://www.youtube.com/watch?v=-24PoWtHVzk
Regards, Mark.
On 16 Sep, 2013, at 4:55 PM, Håkon Markussen <hakon.markussen@gmail.com> wrote:
Hi Thomas,
"Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?"
Are you able to read any CAN-bus values from your iMiEV?
I experienced once at my Think City, that the Ovms-module did not read the CAN-bus at all; I got 0% SOC. The problem was I had two external CAN-devices connected at the same time (Duinomite Mega + OVMS). It worked fine when both modules were powered on at the same time, but Ovms failed to read the bus when the Duinomite Mega was powered off.
Du you have access to any kind of can-reader tool? This can be used to verify that you are looking at the correct bytes. I've used P-CAN USB adapter http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 and PCANView http://www.computer-solutions.co.uk/gendev/can-basic-dll.htm
You can use it to verify you have SOC in msg 0x374 byte 1.
To understand the mask and filter, you have to consider the mask as a bit "enable" / "disable". Any zero in the mask bit disables that specific bit. The filter gives a range of bit combinations. Both mask an filter is 11 bit length (0-10), all 8 bits from SIDH + 3 most significant bits from SIDL
Your Mask0 (RXM0) is 11111111 000 (0x7F8) which enables bit 3 to 10 Your Filter0 (RXF0) is 01100000 000 In combination with your mask0, this gives the message range from 0x300 to 0x3F8, which covers your messages. 01100000 000 -> 0x300 011111111 000 -> 0x3F8 (however you have an minor error in your comment 0x300 .. 0x3E0)
The same goes for mask1 and filter2, filter3, filter4,which applies to poll1(). But you have to make sure that the mask1 enables sufficient number of bits for the corresponding filters. Your mask1 is 11111111 111 so that is OK. Your filter2 is 01010000 101 (0x285) which is OK Your filter 3 is 10000010 010 (0x412) which is OK
You have yet not built any vehicle specific SMS function, so the STAT-sms is created in the net_msg.c file . I think it this file prints SOC to SMS regardless of the doorbit status.
A hint is using the diag-port for sending SMS (saves you sms cost) for debuging).
Br. Håkon
2013/9/15 Thomas Bergo <thomas.bergo@gmail.com> Finally got some time to work on the i-Miev implementation.
But I'm facing some issues setting up the car module. - SMS is working and are able to send messages to the car module and get answers. - Problem getting the GPRS to work. Get "Not connected" and "Not connected (0x0041) when sending GPRS? - No connection from the iOS app to server. Only red flashing antenna.
Any advise?
Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?
Regards, Thomas
2013/5/1 Mark Webb-Johnson <mark@webb-johnson.net>
I've created a stub file (vehicle_mitsubishi.c), and pushed to github. If you pull head you'll get it. This is just a stub. You'll need to setup the CAN IDs you want to receive (in the filters), and then add the decoding logic to update the car_* variables.
Regards, Mark.
Regards, Mark.
On 30 Apr, 2013, at 5:29 AM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi,
So far the following CAN messages is discovered by Priusfan published on myimiev forum:
SOC RPM Range Battery current Battery voltage Speed Odo Battery cell voltage Battery cell temperature
So we still have to find Car On/Off and the charging status.
Those messages are available as Mitsubishi has made a CAN Gateway where those data is provided. http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf
Regarding the two-character abbreviation I think Brand-Model (MI) as TR and RT is most intuitive. So my vote goes to MI.
I'm interested in using the OVMS v1 HW for logging of CAN messages. How to pay for postage?
Regards, Thomas
mandag 29. april 2013 skrev Mark Webb-Johnson følgende: Thomas,
Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there.
It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible:
Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility:
SOC - battery state of charge - car_SOC Car On/Off (ignition switch, or Park/Drive gear lever) - car_doors1 [bit7] Car Charging (true or false) - car_doors1 [bit 4]
If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself.
What vehicle two-character abbreviation do you think is suitable: IM or MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster).
If you can let me have the can bus specs and information on the above 3 messages, I will create you a stub vehicle implementation.
Regards, Mark.
P.S. With reference to the development guide (https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/OVM...), these are the current set of parameters that OVMS supports.
Vehicle Module Development Checklists
Development Checklists
You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these.
Parameter
Purpose
Vehicle Support Notes
Vehicle Identification
car_type
Vehicle type identified
car_vin
Vehicle VIN
Parameter
Purpose
Vehicle Support Notes
GPS Status
Vehicle GPS
Does the vehicle have a built-in GPS? If so, complete the following.
car_gpslock
_______________________________________________ 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
Yesterday I managed to verify that both poll0 and poll1 interrupt is called. Printed "car_idealrange =id;" from poll0 to see the PID's that triggered the interrupt. Only get id 768 (0x300) printed out. Also tried to do a the printout fom inside case 0x374: but no updates. The strange ting is that I can see a lot of "374" messages, and none "300" when using my laptop. Start wonder if the PID "374" that I find on my laptop is not a hex value? Any one here that has any experiance with CAN-Do SW for analysing CAN mesages? Will do some more testing later. Regards, Thomas onsdag 18. september 2013 skrev Mark Webb-Johnson følgende:
Is there a simple way to print out a value to the DIAG port for debugging?
You can just net_puts it, normally prefixed with a "#" sign as a comment. Have a look in diag.c for lots of examples. You will need to type 'ATE1' when going into diag mode, to get the echo output. The way it works is that you send the command to the modem (net_puts()), which discards it as unrecognised, but echos it back to the terminal.
But, you can't do that in interrupt handlers - only in normal ticker(), or message handler, style code
Regards, Mark.
On 18 Sep, 2013, at 8:22 PM, Thomas Bergo <thomas.bergo@gmail.com<javascript:_e({}, 'cvml', 'thomas.bergo@gmail.com');>> wrote:
Thank you for your help.
Fixed some typos and now ODO updates in "STAT?" ODO is still wrong, but at least i get updates. No luck with SOC so far.
Have verified that the PID and the data is correct by using a CAN interface on my laptop.
Will do some more debugging to verify that both poll0 and poll1 is called.
Is there a simple way to print out a value to the DIAG port for debugging?
Regards, Thomas
2013/9/17 Mark Webb-Johnson <mark@webb-johnson.net <javascript:_e({}, 'cvml', 'mark@webb-johnson.net');>>
Thanks, Håkon - nice clear answer.
One other suggestion is that you can put "car_idealrange++; return TRUE;" and "car_estrange++; return TRUE;" in the poll0 and poll1 functions, near the top. A few STAT commands and you can see if the poll functions are actually being called. You can also put "car_idealrange=id; return TRUE;", etc, to get an idea of what IDs are being delivered. It is very nasty trying to debug interrupt handlers, but this approach can help.
The diag port mentioned is shown here:
OVMS Setup Diagnostics Mode <http://www.youtube.com/watch?v=-24PoWtHVzk>
Regards, Mark.
On 16 Sep, 2013, at 4:55 PM, Håkon Markussen <hakon.markussen@gmail.com<javascript:_e({}, 'cvml', 'hakon.markussen@gmail.com');>> wrote:
Hi Thomas,
*"Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?" *
Are you able to read any CAN-bus values from your iMiEV?
I experienced once at my Think City, that the Ovms-module did not read the CAN-bus at all; I got 0% SOC. The problem was I had two external CAN-devices connected at the same time (Duinomite Mega + OVMS). It worked fine when both modules were powered on at the same time, but Ovms failed to read the bus when the Duinomite Mega was powered off.
Du you have access to any kind of can-reader tool? This can be used to verify that you are looking at the correct bytes. I've used P-CAN USB adapter http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 and PCANView http://www.computer-solutions.co.uk/gendev/can-basic-dll.htm
You can use it to verify you have SOC in msg 0x374 byte 1.
To understand the mask and filter, you have to consider the mask as a bit "enable" / "disable". Any zero in the mask bit disables that specific bit. The filter gives a range of bit combinations. Both mask an filter is 11 bit length (0-10), all 8 bits from SIDH + 3 most significant bits from SIDL
Your Mask0 (RXM0) is 11111111 000 (0x7F8) which enables bit 3 to 10 Your Filter0 (RXF0) is 01100000 000 In combination with your mask0, this gives the message range from 0x300 to 0x3F8, which covers your messages. 01100000 000 -> 0x300 011111111 000 -> 0x3F8 (however you have an minor error in your comment 0x300 .. 0x3E0)
The same goes for mask1 and filter2, filter3, filter4,which applies to poll1(). But you have to make sure that the mask1 enables sufficient number of bits for the corresponding filters. Your mask1 is 11111111 111 so that is OK. Your filter2 is 01010000 101 (0x285) which is OK Your filter 3 is 10000010 010 (0x412) which is OK
You have yet not built any vehicle specific SMS function, so the STAT-sms is created in the net_msg.c file . I think it this file prints SOC to SMS regardless of the doorbit status.
A hint is using the diag-port for sending SMS (saves you sms cost) for debuging).
Br. Håkon
2013/9/15 Thomas Bergo <thomas.bergo@gmail.com <javascript:_e({}, 'cvml', 'thomas.bergo@gmail.com');>>
Finally got some time to work on the i-Miev implementation.
But I'm facing some issues setting up the car module. - SMS is working and are able to send messages to the car module and get answers. - Problem getting the GPRS to work. Get "Not connected" and "Not connected (0x0041) when sending GPRS? - No connection from the iOS app to server. Only red flashing antenna.
Any advise?
Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?
Regards, Thomas
2013/5/1 Mark Webb-Johnson <mark@webb-johnson.net <javascript:_e({}, 'cvml', 'mark@webb-johnson.net');>>
I've created a stub file (vehicle_mitsubishi.c), and pushed to github. If you pull head you'll get it. This is just a stub. You'll need to setup the CAN IDs you want to receive (in the filters), and then add the decoding logic to update the car_* variables.
Regards, Mark.
Regards, Mark.
On 30 Apr, 2013, at 5:29 AM, Thomas Bergo <thomas.bergo@gmail.com<javascript:_e({}, 'cvml', 'thomas.bergo@gmail.com');>> wrote:
Hi,
So far the following CAN messages is discovered by Priusfan published on myimiev forum:
SOC RPM Range Battery current Battery voltage Speed Odo Battery cell voltage Battery cell temperature
So we still have to find Car On/Off and the charging status.
Those messages are available as Mitsubishi has made a CAN Gateway where those data is provided. http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf
Regarding the two-character abbreviation I think Brand-Model (MI) as TR and RT is most intuitive. So my vote goes to MI.
I'm interested in using the OVMS v1 HW for logging of CAN messages. How to pay for postage?
Regards, Thomas
mandag 29. april 2013 skrev Mark Webb-Johnson følgende:
Thomas,
Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there.
It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible:
Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility:
1. SOC - battery state of charge - *car_SOC* 2. Car On/Off (ignition switch, or Park/Drive gear lever) - *car_doors1 [bit7]* 3. Car Charging (true or false) - *car_doors1 [bit 4]*
If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself.
What vehicle two-character abbreviation do you think is suitable: IM or MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster).
If you can let me have the can bus specs and information on the above 3 messages, I will create you a stub vehicle implementation.
Regards, Mark.
P.S. With reference to the development guide ( https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/OVM...), these are the current set of parameters that OVMS supports.
Vehicle Module Development Checklists Development Checklists
You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these.
*Parameter*
*Purpose*
*Vehicle Support Notes*
* *
*Vehicle Identification*
car_type
Vehicle type identified
car_vin
Vehicle VIN
*Parameter*
*Purpose*
*Vehicle Support Notes*
* *
*GPS Status*
Vehicle GPS
Does the vehicle have a built-in GPS? If so, complete the following.
car_gpslock
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <javascript:_e({}, 'cvml', 'OvmsDev@lists.teslaclub.hk');> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <javascript:_e({}, 'cvml', 'OvmsDev@lists.teslaclub.hk');> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <javascript:_e({}, 'cvml', 'OvmsDev@lists.teslaclub.hk');> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <javascript:_e({}, 'cvml', 'OvmsDev@lists.teslaclub.hk');> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <javascript:_e({}, 'cvml', 'OvmsDev@lists.teslaclub.hk');> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <javascript:_e({}, 'cvml', 'OvmsDev@lists.teslaclub.hk');> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi Thomas, Here is some info on the messages that you can see on the Miev CAN bus. 0x210 - accelerator pedal 0x298 - trip meter 0x346 - range 0x373 - amps, volts 0x374 - SOC 0x389 - Amp, Volts 0x412 - speed, odometer 0x418 - shifter position 0x424 - switches and stuff - like lights, etc. 0x6E1, 0x6E2, 0x6E3, 0x6E4 - cell voltages, and temps Once you get familiar with the ovms, maybe you can find it easier to use the Twizy or the Think code, instead of starting from scratch. Hope this helps, Nikolay ________________________________ From: Thomas Bergo <thomas.bergo@gmail.com> To: OVMS Developers <ovmsdev@lists.teslaclub.hk> Sent: Thursday, September 19, 2013 9:01 AM Subject: Re: [Ovmsdev] i-Miev/C-Zero/iOn Yesterday I managed to verify that both poll0 and poll1 interrupt is called. Printed "car_idealrange =id;" from poll0 to see the PID's that triggered the interrupt. Only get id 768 (0x300) printed out. Also tried to do a the printout fom inside case 0x374: but no updates. The strange ting is that I can see a lot of "374" messages, and none "300" when using my laptop. Start wonder if the PID "374" that I find on my laptop is not a hex value? Any one here that has any experiance with CAN-Do SW for analysing CAN mesages? Will do some more testing later. Regards, Thomas onsdag 18. september 2013 skrev Mark Webb-Johnson følgende:
Is there a simple way to print out a value to the DIAG port for debugging?
You can just net_puts it, normally prefixed with a "#" sign as a comment. Have a look in diag.c for lots of examples. You will need to type 'ATE1' when going into diag mode, to get the echo output. The way it works is that you send the command to the modem (net_puts()), which discards it as unrecognised, but echos it back to the terminal.
But, you can't do that in interrupt handlers - only in normal ticker(), or message handler, style code
Regards, Mark.
On 18 Sep, 2013, at 8:22 PM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Thank you for your help.
Fixed some typos and now ODO updates in "STAT?" ODO is still wrong, but at least i get updates. No luck with SOC so far.
Have verified that the PID and the data is correct by using a CAN interface on my laptop.
Will do some more debugging to verify that both poll0 and poll1 is called.
Is there a simple way to print out a value to the DIAG port for debugging?
Regards, Thomas
2013/9/17 Mark Webb-Johnson <mark@webb-johnson.net>
Thanks, Håkon - nice clear answer.
One other suggestion is that you can put "car_idealrange++; return TRUE;" and "car_estrange++; return TRUE;" in the poll0 and poll1 functions, near the top. A few STAT commands and you can see if the poll functions are actually being called. You can also put "car_idealrange=id; return TRUE;", etc, to get an idea of what IDs are being delivered. It is very nasty trying to debug interrupt handlers, but this approach can help.
The diag port mentioned is shown here:
OVMS Setup Diagnostics Mode
Regards, Mark.
On 16 Sep, 2013, at 4:55 PM, Håkon Markussen <hakon.markussen@gmail.com> wrote:
Hi Thomas,
"Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?"
Are you able to read any CAN-bus values from your iMiEV?
I experienced once at my Think City, that the Ovms-module did not read the CAN-bus at all; I got 0% SOC. The problem was I had two external CAN-devices connected at the same time (Duinomite Mega + OVMS). It worked fine when both modules were powered on at the same time, but Ovms failed to read the bus when the Duinomite Mega was powered off.
Du you have access to any kind of can-reader tool? This can be used to verify that you are looking at the correct bytes. I've used P-CAN USB adapter http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 and PCANView http://www.computer-solutions.co.uk/gendev/can-basic-dll.htm
You can use it to verify you have SOC in msg 0x374 byte 1.
To understand the mask and filter, you have to consider the mask as a bit "enable" / "disable". Any zero in the mask bit disables that specific bit.
The filter gives a range of bit combinations.
Both mask an filter is 11 bit length (0-10), all 8 bits from SIDH + 3 most significant bits from SIDL
Your Mask0 (RXM0) is 11111111 000 (0x7F8) which enables bit 3 to 10 Your Filter0 (RXF0) is 01100000 000 In combination with your mask0, this gives the message range from 0x300 to 0x3F8, which covers your messages. 01100000 000 -> 0x300
011111111 000 -> 0x3F8
(however you have an minor error in your comment 0x300 .. 0x3E0)
The same goes for mask1 and filter2, filter3, filter4,which applies to poll1(). But you have to make sure that the mask1 enables sufficient number of bits for the corresponding filters.
Your mask1 is 11111111 111 so that is OK.
Your filter2 is 01010000 101 (0x285) which is OK
Your filter 3 is 10000010 010 (0x412) which is OK
You have yet not built any vehicle specific SMS function, so the STAT-sms is created in the net_msg.c file . I think it this file prints SOC to SMS regardless of the doorbit status.
A hint is using the diag-port for sending SMS (saves you sms cost) for debuging).
Br.
Håkon
2013/9/15 Thomas Bergo <thomas.bergo@gmail.com>
Finally got some time to work on the i-Miev implementation.
But I'm facing some issues setting up the car module. - SMS is working and are able to send messages to the car module and get answers. - Problem getting the GPRS to work. Get "Not connected" and "Not connected (0x0041) when sending GPRS? - No connection from the iOS app to server. Only red flashing antenna.
Any advise?
Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?
Regards, Thomas
2013/5/1 Mark Webb-Johnson <mark@webb-johnson.net>
I've created a stub file (vehicle_mitsubishi.c), and pushed to github. If you pull head you'll get it. This is just a stub. You'll need to setup the CAN IDs you want to receive (in the filters), and then add the decoding logic to update the car_* variables.
Regards, Mark.
Regards, Mark.
On 30 Apr, 2013, at 5:29 AM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi, > > >So far the following CAN messages is discovered by Priusfan published on myimiev forum: > > >SOC >RPM >Range >Battery current >Battery voltage >Speed >Odo >Battery cell voltage >Battery cell temperature > > >So we still have to find Car On/Off and the charging status. > > >Those messages are available as Mitsubishi has made a CAN Gateway where those data is provided. http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf > > > > >Regarding the two-character abbreviation I think Brand-Model (MI) as TR and RT is most intuitive. So my vote goes to MI. > > >I'm interested in using the OVMS v1 HW for logging of CAN messages. How to pay for postage? > > >Regards, Thomas > > >mandag 29. april 2013 skrev Mark Webb-Johnson følgende: > >Thomas, >> >> >>Earlier this year, Matt Beard mentioned he was interested in doing i-Miev support, but I'm not sure of his status. He is on this list, so should see this. There are also several OVMS users who have that car in their stable, so the requirement is definitely there. >> >> >>It is probably worth firstly doing a quick feasibility check, to see what level of OVMS support is possible: >> >> >>Firstly, What are the specs for the CAN bus? What baud rate is it, and what is the connector? There are just three messages that are key to feasibility: >>> >>> >> 1. SOC - battery state of charge - car_SOC >> 2. Car On/Off (ignition switch, or Park/Drive gear lever) - car_doors1 [bit7] >> 3. Car Charging (true or false) - car_doors1 [bit 4] >> >>> >>>If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself. >> >> >>What vehicle two-character abbreviation do you think is suitable: IM or MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster). >> >> >>If you can let me have the can bus specs and information on the above 3 messages, I will create you a stub vehicle implementation. >> >> >>Regards, Mark. >> >> >>P.S. With reference to the development guide (https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/OVM...), these are the current set of parameters that OVMS supports. >> >> >>Vehicle Module Development Checklists >>>Development Checklists >>> >>> >>>You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these. >>>Parameter Purpose Vehicle Support Notes >>> >>>Vehicle Identification >>>car_type Vehicle type identified >>> >>>car_vin Vehicle VIN >>> >>> >>> >>>Parameter Purpose Vehicle Support Notes >>> >>>GPS Status >>>Vehicle GPS Does the vehicle have a built-in GPS? If so, complete the following. >>> >>>car_gpslock >>> >_______________________________________________ >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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Thank you for your attention. This is the same information that i have: SOC shuld be 0x374, byte 1. This I have confirmed using my laptop and the CAN-Do SW. I used the Think code as a template for setting up the filter and poll interupts. So I belived that it shuld be a straight forward task to read the messages. I will post my filter setup and poll1 code later, I belive that you will see what's wrong. Regards, Thomas torsdag 19. september 2013 skrev Nikolay Shishkov følgende:
Hi Thomas,
Here is some info on the messages that you can see on the Miev CAN bus. 0x210 - accelerator pedal 0x298 - trip meter 0x346 - range 0x373 - amps, volts 0x374 - SOC 0x389 - Amp, Volts 0x412 - speed, odometer 0x418 - shifter position 0x424 - switches and stuff - like lights, etc. 0x6E1, 0x6E2, 0x6E3, 0x6E4 - cell voltages, and temps
Once you get familiar with the ovms, maybe you can find it easier to use the Twizy or the Think code, instead of starting from scratch.
Hope this helps, Nikolay
------------------------------ *From:* Thomas Bergo <thomas.bergo@gmail.com <javascript:_e({}, 'cvml', 'thomas.bergo@gmail.com');>> *To:* OVMS Developers <ovmsdev@lists.teslaclub.hk <javascript:_e({}, 'cvml', 'ovmsdev@lists.teslaclub.hk');>> *Sent:* Thursday, September 19, 2013 9:01 AM *Subject:* Re: [Ovmsdev] i-Miev/C-Zero/iOn
Yesterday I managed to verify that both poll0 and poll1 interrupt is called.
Printed "car_idealrange =id;" from poll0 to see the PID's that triggered the interrupt. Only get id 768 (0x300) printed out.
Also tried to do a the printout fom inside case 0x374: but no updates. The strange ting is that I can see a lot of "374" messages, and none "300" when using my laptop.
Start wonder if the PID "374" that I find on my laptop is not a hex value? Any one here that has any experiance with CAN-Do SW for analysing CAN mesages?
Will do some more testing later.
Regards, Thomas
onsdag 18. september 2013 skrev Mark Webb-Johnson følgende:
Is there a simple way to print out a value to the DIAG port for debugging?
You can just net_puts it, normally prefixed with a "#" sign as a comment. Have a look in diag.c for lots of examples. You will need to type 'ATE1' when going into diag mode, to get the echo output. The way it works is that you send the command to the modem (net_puts()), which discards it as unrecognised, but echos it back to the terminal.
But, you can't do that in interrupt handlers - only in normal ticker(), or message handler, style code
Regards, Mark.
On 18 Sep, 2013, at 8:22 PM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Thank you for your help.
Fixed some typos and now ODO updates in "STAT?" ODO is still wrong, but at least i get updates. No luck with SOC so far.
Have verified that the PID and the data is correct by using a CAN interface on my laptop.
Will do some more debugging to verify that both poll0 and poll1 is called.
Is there a simple way to print out a value to the DIAG port for debugging?
Regards, Thomas
2013/9/17 Mark Webb-Johnson <mark@webb-johnson.net>
Thanks, Håkon - nice clear answer.
One other suggestion is that you can put "car_idealrange++; return TRUE;" and "car_estrange++; return TRUE;" in the poll0 and poll1 functions, near the top. A few STAT commands and you can see if the poll functions are actually being called. You can also put "car_idealrange=id; return TRUE;", etc, to get an idea of what IDs are being delivered. It is very nasty trying to debug interrupt handlers, but this approach can help.
The diag port mentioned is shown here:
OVMS Setup Diagnostics Mode <http://www.youtube.com/watch?v=-24PoWtHVzk>
Regards, Mark.
On 16 Sep, 2013, at 4:55 PM, Håkon Markussen <hakon.markussen@gmail.com> wrote:
Hi Thomas,
*"Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?" *
Are you able to read any CAN-bus values from your iMiEV?
I experienced once at my Think City, that the Ovms-module did not read the CAN-bus at all; I got 0% SOC. The problem was I had two external CAN-devices connected at the same time (Duinomite Mega + OVMS). It worked fine when both modules were powered on at the same time, but Ovms failed to read the bus when the Duinomite Mega was powered off.
Du you have access to any kind of can-reader tool? This can be used to verify that you are looking at the correct bytes. I've used P-CAN USB adapter http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 and PCANView http://www.computer-solutions.co.uk/gendev/can-basic-dll.htm
You can use it to verify you have SOC in msg 0x374 byte 1.
To understand the mask and filter, you have to consider the mask as a bit "enable" / "disable". Any zero in the mask bit disables that
@Thomas: Are you sure this calculation is correct for iMiEV? *car_SOC = (char)(((int)can_databuffer[1] - 10) / 2); * This means byte 1 can be: Ah (d10) = 0% SOC (minimum) 6Eh (d110) = 50% SOC D2h (d210) = 100% SOC (maximum) Br. Håkon 2013/9/19 Thomas Bergo <thomas.bergo@gmail.com>
Thank you for your attention.
This is the same information that i have:
SOC shuld be 0x374, byte 1. This I have confirmed using my laptop and the CAN-Do SW.
I used the Think code as a template for setting up the filter and poll interupts. So I belived that it shuld be a straight forward task to read the messages.
I will post my filter setup and poll1 code later, I belive that you will see what's wrong.
Regards, Thomas
torsdag 19. september 2013 skrev Nikolay Shishkov følgende:
Hi Thomas,
Here is some info on the messages that you can see on the Miev CAN bus. 0x210 - accelerator pedal 0x298 - trip meter 0x346 - range 0x373 - amps, volts 0x374 - SOC 0x389 - Amp, Volts 0x412 - speed, odometer 0x418 - shifter position 0x424 - switches and stuff - like lights, etc. 0x6E1, 0x6E2, 0x6E3, 0x6E4 - cell voltages, and temps
Once you get familiar with the ovms, maybe you can find it easier to use the Twizy or the Think code, instead of starting from scratch.
Hope this helps, Nikolay
------------------------------ *From:* Thomas Bergo <thomas.bergo@gmail.com> *To:* OVMS Developers <ovmsdev@lists.teslaclub.hk> *Sent:* Thursday, September 19, 2013 9:01 AM *Subject:* Re: [Ovmsdev] i-Miev/C-Zero/iOn
Yesterday I managed to verify that both poll0 and poll1 interrupt is called.
Printed "car_idealrange =id;" from poll0 to see the PID's that triggered the interrupt. Only get id 768 (0x300) printed out.
Also tried to do a the printout fom inside case 0x374: but no updates. The strange ting is that I can see a lot of "374" messages, and none "300" when using my laptop.
Start wonder if the PID "374" that I find on my laptop is not a hex value? Any one here that has any experiance with CAN-Do SW for analysing CAN mesages?
Will do some more testing later.
Regards, Thomas
onsdag 18. september 2013 skrev Mark Webb-Johnson følgende:
Is there a simple way to print out a value to the DIAG port for debugging?
You can just net_puts it, normally prefixed with a "#" sign as a comment. Have a look in diag.c for lots of examples. You will need to type 'ATE1' when going into diag mode, to get the echo output. The way it works is that you send the command to the modem (net_puts()), which discards it as unrecognised, but echos it back to the terminal.
But, you can't do that in interrupt handlers - only in normal ticker(), or message handler, style code
Regards, Mark.
On 18 Sep, 2013, at 8:22 PM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Thank you for your help.
Fixed some typos and now ODO updates in "STAT?" ODO is still wrong, but at least i get updates. No luck with SOC so far.
Have verified that the PID and the data is correct by using a CAN interface on my laptop.
Will do some more debugging to verify that both poll0 and poll1 is called.
Is there a simple way to print out a value to the DIAG port for debugging?
Regards, Thomas
2013/9/17 Mark Webb-Johnson <mark@webb-johnson.net>
Thanks, Håkon - nice clear answer.
One other suggestion is that you can put "car_idealrange++; return TRUE;" and "car_estrange++; return TRUE;" in the poll0 and poll1 functions, near the top. A few STAT commands and you can see if the poll functions are actually being called. You can also put "car_idealrange=id; return TRUE;", etc, to get an idea of what IDs are being delivered. It is very nasty trying to debug interrupt handlers, but this approach can help.
The diag port mentioned is shown here:
OVMS Setup Diagnostics Mode <http://www.youtube.com/watch?v=-24PoWtHVzk>
Regards, Mark.
On 16 Sep, 2013, at 4:55 PM, Håkon Markussen <hakon.markussen@gmail.com> wrote:
Hi Thomas,
*"Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?" *
Are you able to read any CAN-bus values from your iMiEV?
I experienced once at my Think City, that the Ovms-module did not read the CAN-bus at all; I got 0% SOC. The problem was I had two external CAN-devices connected at the same time (Duinomite Mega + OVMS). It worked fine when both modules were powered on at the same time, but Ovms failed to read the bus when the Duinomite Mega was powered off.
Du you have access to any kind of can-reader tool? This can be used to verify that you are looking at the correct bytes. I've used P-CAN USB adapter http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 and PCANView http://www.computer-solutions.co.uk/gendev/can-basic-dll.htm
You can use it to verify you have SOC in msg 0x374 byte 1.
To understand the mask and filter, you have to consider the mask as a bit "enable" / "disable". Any zero in the mask bit disables that
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I'm pretty sure. I got this calculation from Xavier, he made the first version of the Canion app. A Android app to visualize data from the can-bus on i-Miev, iOn and C-Zero. https://play.google.com/store/apps/details?id=emobility.canion&hl=no The calculation also seams to be correct when i logged the can bus during charging yesterday, I had 14 bars and SOC was 85% with this calculation. Regards, Thomas 2013/9/19 Håkon Markussen <hakon.markussen@gmail.com>
@Thomas: Are you sure this calculation is correct for iMiEV? *car_SOC = (char)(((int)can_databuffer[1] - 10) / 2); *
This means byte 1 can be: Ah (d10) = 0% SOC (minimum) 6Eh (d110) = 50% SOC D2h (d210) = 100% SOC (maximum)
Br. Håkon
2013/9/19 Thomas Bergo <thomas.bergo@gmail.com>
Thank you for your attention.
This is the same information that i have:
SOC shuld be 0x374, byte 1. This I have confirmed using my laptop and the CAN-Do SW.
I used the Think code as a template for setting up the filter and poll interupts. So I belived that it shuld be a straight forward task to read the messages.
I will post my filter setup and poll1 code later, I belive that you will see what's wrong.
Regards, Thomas
torsdag 19. september 2013 skrev Nikolay Shishkov følgende:
Hi Thomas,
Here is some info on the messages that you can see on the Miev CAN bus. 0x210 - accelerator pedal 0x298 - trip meter 0x346 - range 0x373 - amps, volts 0x374 - SOC 0x389 - Amp, Volts 0x412 - speed, odometer 0x418 - shifter position 0x424 - switches and stuff - like lights, etc. 0x6E1, 0x6E2, 0x6E3, 0x6E4 - cell voltages, and temps
Once you get familiar with the ovms, maybe you can find it easier to use the Twizy or the Think code, instead of starting from scratch.
Hope this helps, Nikolay
------------------------------ *From:* Thomas Bergo <thomas.bergo@gmail.com> *To:* OVMS Developers <ovmsdev@lists.teslaclub.hk> *Sent:* Thursday, September 19, 2013 9:01 AM *Subject:* Re: [Ovmsdev] i-Miev/C-Zero/iOn
Yesterday I managed to verify that both poll0 and poll1 interrupt is called.
Printed "car_idealrange =id;" from poll0 to see the PID's that triggered the interrupt. Only get id 768 (0x300) printed out.
Also tried to do a the printout fom inside case 0x374: but no updates. The strange ting is that I can see a lot of "374" messages, and none "300" when using my laptop.
Start wonder if the PID "374" that I find on my laptop is not a hex value? Any one here that has any experiance with CAN-Do SW for analysing CAN mesages?
Will do some more testing later.
Regards, Thomas
onsdag 18. september 2013 skrev Mark Webb-Johnson følgende:
Is there a simple way to print out a value to the DIAG port for debugging?
You can just net_puts it, normally prefixed with a "#" sign as a comment. Have a look in diag.c for lots of examples. You will need to type 'ATE1' when going into diag mode, to get the echo output. The way it works is that you send the command to the modem (net_puts()), which discards it as unrecognised, but echos it back to the terminal.
But, you can't do that in interrupt handlers - only in normal ticker(), or message handler, style code
Regards, Mark.
On 18 Sep, 2013, at 8:22 PM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Thank you for your help.
Fixed some typos and now ODO updates in "STAT?" ODO is still wrong, but at least i get updates. No luck with SOC so far.
Have verified that the PID and the data is correct by using a CAN interface on my laptop.
Will do some more debugging to verify that both poll0 and poll1 is called.
Is there a simple way to print out a value to the DIAG port for debugging?
Regards, Thomas
2013/9/17 Mark Webb-Johnson <mark@webb-johnson.net>
Thanks, Håkon - nice clear answer.
One other suggestion is that you can put "car_idealrange++; return TRUE;" and "car_estrange++; return TRUE;" in the poll0 and poll1 functions, near the top. A few STAT commands and you can see if the poll functions are actually being called. You can also put "car_idealrange=id; return TRUE;", etc, to get an idea of what IDs are being delivered. It is very nasty trying to debug interrupt handlers, but this approach can help.
The diag port mentioned is shown here:
OVMS Setup Diagnostics Mode <http://www.youtube.com/watch?v=-24PoWtHVzk>
Regards, Mark.
On 16 Sep, 2013, at 4:55 PM, Håkon Markussen <hakon.markussen@gmail.com> wrote:
Hi Thomas,
*"Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?" *
Are you able to read any CAN-bus values from your iMiEV?
I experienced once at my Think City, that the Ovms-module did not read the CAN-bus at all; I got 0% SOC. The problem was I had two external CAN-devices connected at the same time (Duinomite Mega + OVMS). It worked fine when both modules were powered on at the same time, but Ovms failed to read the bus when the Duinomite Mega was powered off.
Du you have access to any kind of can-reader tool? This can be used to verify that you are looking at the correct bytes. I've used P-CAN USB adapter http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 and PCANView http://www.computer-solutions.co.uk/gendev/can-basic-dll.htm
You can use it to verify you have SOC in msg 0x374 byte 1.
To understand the mask and filter, you have to consider the mask as a bit "enable" / "disable". Any zero in the mask bit disables that
_______________________________________________ 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 is the code I'm trying for reading the SOC, *Filter:* // Filters: low byte bits 7..5 are the low 3 bits of the filter, and bits 4..0 are all zeros // high byte bits 7..0 are the high 8 bits of the filter // So total is 11 bits // Buffer 0 (filters 0, 1) for extended PID responses RXB0CON = 0b00000000; // Mask0 = 0b11111111000 (0x7F8), filterbit 0,1,2 deactivated RXM0SIDL = 0b00000000; RXM0SIDH = 0b11111111; // Filter0 0b01100000000 (0x300..0x3F8) RXF0SIDL = 0b00000000; RXF0SIDH = 0b01100000; *Can_poll*: //////////////////////////////////////////////////////////////////////// // can_poll() // This function is an entry point from the main() program loop, and // gives the CAN framework an opportunity to poll for data. // BOOL vehicle_mitsubishi_poll0(void) { unsigned int id = ((unsigned int)RXB0SIDL >>5) + ((unsigned int)RXB0SIDH <<3); can_datalength = RXB0DLC & 0x0F; // number of received bytes can_databuffer[0] = RXB0D0; can_databuffer[1] = RXB0D1; can_databuffer[2] = RXB0D2; can_databuffer[3] = RXB0D3; can_databuffer[4] = RXB0D4; can_databuffer[5] = RXB0D5; can_databuffer[6] = RXB0D6; can_databuffer[7] = RXB0D7; RXB0CONbits.RXFUL = 0; // All bytes read, Clear flag car_estrange = id; //debug switch (id) { /* case 0x346: car_estrange = MiFromKm((unsigned int)can_databuffer[7]); // Range car_idealrange = car_estrange; break; case 0x373: // BatCurr & BatVolt break; */ case 0x374: car_idealrange = id; //debug car_SOC = (char)(((int)can_databuffer[1] - 10) / 2); //SOC break; case 0x389: car_linevoltage = (unsigned int)can_databuffer[1]; car_chargecurrent = ((unsigned int)can_databuffer[6] / 10); break; } return TRUE; } I using car_estrange and car_idealrange for debug. car_estrange gets updates, but car_idealrange is never updated and are always 0. Have also tried car_estrange++; in the code, and I can see that the number increases for each DIAG message. Regards, Thomas 2013/9/19 Thomas Bergo <thomas.bergo@gmail.com>
I'm pretty sure. I got this calculation from Xavier, he made the first version of the Canion app. A Android app to visualize data from the can-bus on i-Miev, iOn and C-Zero. https://play.google.com/store/apps/details?id=emobility.canion&hl=no
The calculation also seams to be correct when i logged the can bus during charging yesterday, I had 14 bars and SOC was 85% with this calculation.
Regards, Thomas
2013/9/19 Håkon Markussen <hakon.markussen@gmail.com>
@Thomas: Are you sure this calculation is correct for iMiEV? *car_SOC = (char)(((int)can_databuffer[1] - 10) / 2); *
This means byte 1 can be: Ah (d10) = 0% SOC (minimum) 6Eh (d110) = 50% SOC D2h (d210) = 100% SOC (maximum)
Br. Håkon
2013/9/19 Thomas Bergo <thomas.bergo@gmail.com>
Thank you for your attention.
This is the same information that i have:
SOC shuld be 0x374, byte 1. This I have confirmed using my laptop and the CAN-Do SW.
I used the Think code as a template for setting up the filter and poll interupts. So I belived that it shuld be a straight forward task to read the messages.
I will post my filter setup and poll1 code later, I belive that you will see what's wrong.
Regards, Thomas
torsdag 19. september 2013 skrev Nikolay Shishkov følgende:
Hi Thomas,
Here is some info on the messages that you can see on the Miev CAN bus. 0x210 - accelerator pedal 0x298 - trip meter 0x346 - range 0x373 - amps, volts 0x374 - SOC 0x389 - Amp, Volts 0x412 - speed, odometer 0x418 - shifter position 0x424 - switches and stuff - like lights, etc. 0x6E1, 0x6E2, 0x6E3, 0x6E4 - cell voltages, and temps
Once you get familiar with the ovms, maybe you can find it easier to use the Twizy or the Think code, instead of starting from scratch.
Hope this helps, Nikolay
------------------------------ *From:* Thomas Bergo <thomas.bergo@gmail.com> *To:* OVMS Developers <ovmsdev@lists.teslaclub.hk> *Sent:* Thursday, September 19, 2013 9:01 AM *Subject:* Re: [Ovmsdev] i-Miev/C-Zero/iOn
Yesterday I managed to verify that both poll0 and poll1 interrupt is called.
Printed "car_idealrange =id;" from poll0 to see the PID's that triggered the interrupt. Only get id 768 (0x300) printed out.
Also tried to do a the printout fom inside case 0x374: but no updates. The strange ting is that I can see a lot of "374" messages, and none "300" when using my laptop.
Start wonder if the PID "374" that I find on my laptop is not a hex value? Any one here that has any experiance with CAN-Do SW for analysing CAN mesages?
Will do some more testing later.
Regards, Thomas
onsdag 18. september 2013 skrev Mark Webb-Johnson følgende:
Is there a simple way to print out a value to the DIAG port for debugging?
You can just net_puts it, normally prefixed with a "#" sign as a comment. Have a look in diag.c for lots of examples. You will need to type 'ATE1' when going into diag mode, to get the echo output. The way it works is that you send the command to the modem (net_puts()), which discards it as unrecognised, but echos it back to the terminal.
But, you can't do that in interrupt handlers - only in normal ticker(), or message handler, style code
Regards, Mark.
On 18 Sep, 2013, at 8:22 PM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Thank you for your help.
Fixed some typos and now ODO updates in "STAT?" ODO is still wrong, but at least i get updates. No luck with SOC so far.
Have verified that the PID and the data is correct by using a CAN interface on my laptop.
Will do some more debugging to verify that both poll0 and poll1 is called.
Is there a simple way to print out a value to the DIAG port for debugging?
Regards, Thomas
2013/9/17 Mark Webb-Johnson <mark@webb-johnson.net>
Thanks, Håkon - nice clear answer.
One other suggestion is that you can put "car_idealrange++; return TRUE;" and "car_estrange++; return TRUE;" in the poll0 and poll1 functions, near the top. A few STAT commands and you can see if the poll functions are actually being called. You can also put "car_idealrange=id; return TRUE;", etc, to get an idea of what IDs are being delivered. It is very nasty trying to debug interrupt handlers, but this approach can help.
The diag port mentioned is shown here:
OVMS Setup Diagnostics Mode<http://www.youtube.com/watch?v=-24PoWtHVzk>
Regards, Mark.
On 16 Sep, 2013, at 4:55 PM, Håkon Markussen <hakon.markussen@gmail.com> wrote:
Hi Thomas,
*"Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?" *
Are you able to read any CAN-bus values from your iMiEV?
I experienced once at my Think City, that the Ovms-module did not read the CAN-bus at all; I got 0% SOC. The problem was I had two external CAN-devices connected at the same time (Duinomite Mega + OVMS). It worked fine when both modules were powered on at the same time, but Ovms failed to read the bus when the Duinomite Mega was powered off.
Du you have access to any kind of can-reader tool? This can be used to verify that you are looking at the correct bytes. I've used P-CAN USB adapter http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 and PCANView http://www.computer-solutions.co.uk/gendev/can-basic-dll.htm
You can use it to verify you have SOC in msg 0x374 byte 1.
To understand the mask and filter, you have to consider the mask as a bit "enable" / "disable". Any zero in the mask bit disables that
_______________________________________________ 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
My understanding of the way the CAN filtering works is that the mask is not correct in the above code. vehicle_mitsubishi_poll0() is attempting to accept messages with SIDs 0x346, 0x373, 0x374, 0x389, but the filter SID is set to 0x300 with mask 0x7f8 meaning that only messages with SIDs 0x30n where n is 8-f would be received. To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700, but I am worried that may cause a flood of messages. I will see if I can try the following: // Buffer 0 (filters 0, 1) for extended PID responses RXB0CON = 0b00000000; // Mask0 = 0b11100000000 (0x700), filterbit 0,1,2 deactivated RXM0SIDL = 0b00000000; RXM0SIDH = 0b11100000; // Filter0 0b01100000000 (0x300..0x3F8) RXF0SIDL = 0b00000000; RXF0SIDH = 0b01100000; I may also try modifying the RX0 mask during the 1-second poll so that it cycles through filtering a single SID each time, meaning that it will take 4 seconds for a full update. I don't think this will be an issue as none of this data is fast changing. Matt Beard On 19 September 2013 16:10, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Here is the code I'm trying for reading the SOC,
*Filter:*
// Filters: low byte bits 7..5 are the low 3 bits of the filter, and bits 4..0 are all zeros // high byte bits 7..0 are the high 8 bits of the filter // So total is 11 bits
// Buffer 0 (filters 0, 1) for extended PID responses RXB0CON = 0b00000000; // Mask0 = 0b11111111000 (0x7F8), filterbit 0,1,2 deactivated RXM0SIDL = 0b00000000; RXM0SIDH = 0b11111111;
// Filter0 0b01100000000 (0x300..0x3F8) RXF0SIDL = 0b00000000; RXF0SIDH = 0b01100000;
*Can_poll*:
//////////////////////////////////////////////////////////////////////// // can_poll() // This function is an entry point from the main() program loop, and // gives the CAN framework an opportunity to poll for data. // BOOL vehicle_mitsubishi_poll0(void) { unsigned int id = ((unsigned int)RXB0SIDL >>5) + ((unsigned int)RXB0SIDH <<3);
can_datalength = RXB0DLC & 0x0F; // number of received bytes can_databuffer[0] = RXB0D0; can_databuffer[1] = RXB0D1; can_databuffer[2] = RXB0D2; can_databuffer[3] = RXB0D3; can_databuffer[4] = RXB0D4; can_databuffer[5] = RXB0D5; can_databuffer[6] = RXB0D6; can_databuffer[7] = RXB0D7;
RXB0CONbits.RXFUL = 0; // All bytes read, Clear flag
car_estrange = id; //debug
switch (id) { /* case 0x346: car_estrange = MiFromKm((unsigned int)can_databuffer[7]); // Range car_idealrange = car_estrange; break;
case 0x373: // BatCurr & BatVolt break; */
case 0x374: car_idealrange = id; //debug car_SOC = (char)(((int)can_databuffer[1] - 10) / 2); //SOC break;
case 0x389: car_linevoltage = (unsigned int)can_databuffer[1]; car_chargecurrent = ((unsigned int)can_databuffer[6] / 10); break; }
return TRUE; }
I using car_estrange and car_idealrange for debug. car_estrange gets updates, but car_idealrange is never updated and are always 0. Have also tried car_estrange++; in the code, and I can see that the number increases for each DIAG message.
Regards, Thomas
2013/9/19 Thomas Bergo <thomas.bergo@gmail.com>
I'm pretty sure. I got this calculation from Xavier, he made the first version of the Canion app. A Android app to visualize data from the can-bus on i-Miev, iOn and C-Zero. https://play.google.com/store/apps/details?id=emobility.canion&hl=no
The calculation also seams to be correct when i logged the can bus during charging yesterday, I had 14 bars and SOC was 85% with this calculation.
Regards, Thomas
2013/9/19 Håkon Markussen <hakon.markussen@gmail.com>
@Thomas: Are you sure this calculation is correct for iMiEV? *car_SOC = (char)(((int)can_databuffer[1] - 10) / 2); *
This means byte 1 can be: Ah (d10) = 0% SOC (minimum) 6Eh (d110) = 50% SOC D2h (d210) = 100% SOC (maximum)
Br. Håkon
2013/9/19 Thomas Bergo <thomas.bergo@gmail.com>
Thank you for your attention.
This is the same information that i have:
SOC shuld be 0x374, byte 1. This I have confirmed using my laptop and the CAN-Do SW.
I used the Think code as a template for setting up the filter and poll interupts. So I belived that it shuld be a straight forward task to read the messages.
I will post my filter setup and poll1 code later, I belive that you will see what's wrong.
Regards, Thomas
torsdag 19. september 2013 skrev Nikolay Shishkov følgende:
Hi Thomas,
Here is some info on the messages that you can see on the Miev CAN bus. 0x210 - accelerator pedal 0x298 - trip meter 0x346 - range 0x373 - amps, volts 0x374 - SOC 0x389 - Amp, Volts 0x412 - speed, odometer 0x418 - shifter position 0x424 - switches and stuff - like lights, etc. 0x6E1, 0x6E2, 0x6E3, 0x6E4 - cell voltages, and temps
Once you get familiar with the ovms, maybe you can find it easier to use the Twizy or the Think code, instead of starting from scratch.
Hope this helps, Nikolay
------------------------------ *From:* Thomas Bergo <thomas.bergo@gmail.com> *To:* OVMS Developers <ovmsdev@lists.teslaclub.hk> *Sent:* Thursday, September 19, 2013 9:01 AM *Subject:* Re: [Ovmsdev] i-Miev/C-Zero/iOn
Yesterday I managed to verify that both poll0 and poll1 interrupt is called.
Printed "car_idealrange =id;" from poll0 to see the PID's that triggered the interrupt. Only get id 768 (0x300) printed out.
Also tried to do a the printout fom inside case 0x374: but no updates. The strange ting is that I can see a lot of "374" messages, and none "300" when using my laptop.
Start wonder if the PID "374" that I find on my laptop is not a hex value? Any one here that has any experiance with CAN-Do SW for analysing CAN mesages?
Will do some more testing later.
Regards, Thomas
onsdag 18. september 2013 skrev Mark Webb-Johnson følgende:
Is there a simple way to print out a value to the DIAG port for debugging?
You can just net_puts it, normally prefixed with a "#" sign as a comment. Have a look in diag.c for lots of examples. You will need to type 'ATE1' when going into diag mode, to get the echo output. The way it works is that you send the command to the modem (net_puts()), which discards it as unrecognised, but echos it back to the terminal.
But, you can't do that in interrupt handlers - only in normal ticker(), or message handler, style code
Regards, Mark.
On 18 Sep, 2013, at 8:22 PM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Thank you for your help.
Fixed some typos and now ODO updates in "STAT?" ODO is still wrong, but at least i get updates. No luck with SOC so far.
Have verified that the PID and the data is correct by using a CAN interface on my laptop.
Will do some more debugging to verify that both poll0 and poll1 is called.
Is there a simple way to print out a value to the DIAG port for debugging?
Regards, Thomas
2013/9/17 Mark Webb-Johnson <mark@webb-johnson.net>
Thanks, Håkon - nice clear answer.
One other suggestion is that you can put "car_idealrange++; return TRUE;" and "car_estrange++; return TRUE;" in the poll0 and poll1 functions, near the top. A few STAT commands and you can see if the poll functions are actually being called. You can also put "car_idealrange=id; return TRUE;", etc, to get an idea of what IDs are being delivered. It is very nasty trying to debug interrupt handlers, but this approach can help.
The diag port mentioned is shown here:
OVMS Setup Diagnostics Mode<http://www.youtube.com/watch?v=-24PoWtHVzk>
Regards, Mark.
On 16 Sep, 2013, at 4:55 PM, Håkon Markussen < hakon.markussen@gmail.com> wrote:
Hi Thomas,
*"Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?" *
Are you able to read any CAN-bus values from your iMiEV?
I experienced once at my Think City, that the Ovms-module did not read the CAN-bus at all; I got 0% SOC. The problem was I had two external CAN-devices connected at the same time (Duinomite Mega + OVMS). It worked fine when both modules were powered on at the same time, but Ovms failed to read the bus when the Duinomite Mega was powered off.
Du you have access to any kind of can-reader tool? This can be used to verify that you are looking at the correct bytes. I've used P-CAN USB adapter http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 and PCANView http://www.computer-solutions.co.uk/gendev/can-basic-dll.htm
You can use it to verify you have SOC in msg 0x374 byte 1.
To understand the mask and filter, you have to consider the mask as a bit "enable" / "disable". Any zero in the mask bit disables that
_______________________________________________ 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
You may read this post, it contains a lot of good examples of how to use masks and filters: http://www.microchip.com/forums/tm.aspx?m=318430&mpage=1 Br. Håkon 2013/9/21 Matt Beard OVMS <smvo@mxf.org.uk>
My understanding of the way the CAN filtering works is that the mask is not correct in the above code.
vehicle_mitsubishi_poll0() is attempting to accept messages with SIDs 0x346, 0x373, 0x374, 0x389, but the filter SID is set to 0x300 with mask 0x7f8 meaning that only messages with SIDs 0x30n where n is 8-f would be received.
To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700, but I am worried that may cause a flood of messages.
I will see if I can try the following:
// Buffer 0 (filters 0, 1) for extended PID responses RXB0CON = 0b00000000; // Mask0 = 0b11100000000 (0x700), filterbit 0,1,2 deactivated RXM0SIDL = 0b00000000; RXM0SIDH = 0b11100000;
// Filter0 0b01100000000 (0x300..0x3F8) RXF0SIDL = 0b00000000; RXF0SIDH = 0b01100000;
I may also try modifying the RX0 mask during the 1-second poll so that it cycles through filtering a single SID each time, meaning that it will take 4 seconds for a full update. I don't think this will be an issue as none of this data is fast changing.
Matt Beard
On 19 September 2013 16:10, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Here is the code I'm trying for reading the SOC,
*Filter:*
// Filters: low byte bits 7..5 are the low 3 bits of the filter, and bits 4..0 are all zeros // high byte bits 7..0 are the high 8 bits of the filter // So total is 11 bits
// Buffer 0 (filters 0, 1) for extended PID responses RXB0CON = 0b00000000; // Mask0 = 0b11111111000 (0x7F8), filterbit 0,1,2 deactivated RXM0SIDL = 0b00000000; RXM0SIDH = 0b11111111;
// Filter0 0b01100000000 (0x300..0x3F8) RXF0SIDL = 0b00000000; RXF0SIDH = 0b01100000;
*Can_poll*:
//////////////////////////////////////////////////////////////////////// // can_poll() // This function is an entry point from the main() program loop, and // gives the CAN framework an opportunity to poll for data. // BOOL vehicle_mitsubishi_poll0(void) { unsigned int id = ((unsigned int)RXB0SIDL >>5) + ((unsigned int)RXB0SIDH <<3);
can_datalength = RXB0DLC & 0x0F; // number of received bytes can_databuffer[0] = RXB0D0; can_databuffer[1] = RXB0D1; can_databuffer[2] = RXB0D2; can_databuffer[3] = RXB0D3; can_databuffer[4] = RXB0D4; can_databuffer[5] = RXB0D5; can_databuffer[6] = RXB0D6; can_databuffer[7] = RXB0D7;
RXB0CONbits.RXFUL = 0; // All bytes read, Clear flag
car_estrange = id; //debug
switch (id) { /* case 0x346: car_estrange = MiFromKm((unsigned int)can_databuffer[7]); // Range car_idealrange = car_estrange; break;
case 0x373: // BatCurr & BatVolt break; */
case 0x374: car_idealrange = id; //debug car_SOC = (char)(((int)can_databuffer[1] - 10) / 2); //SOC break;
case 0x389: car_linevoltage = (unsigned int)can_databuffer[1]; car_chargecurrent = ((unsigned int)can_databuffer[6] / 10); break; }
return TRUE; }
I using car_estrange and car_idealrange for debug. car_estrange gets updates, but car_idealrange is never updated and are always 0. Have also tried car_estrange++; in the code, and I can see that the number increases for each DIAG message.
Regards, Thomas
2013/9/19 Thomas Bergo <thomas.bergo@gmail.com>
I'm pretty sure. I got this calculation from Xavier, he made the first version of the Canion app. A Android app to visualize data from the can-bus on i-Miev, iOn and C-Zero. https://play.google.com/store/apps/details?id=emobility.canion&hl=no
The calculation also seams to be correct when i logged the can bus during charging yesterday, I had 14 bars and SOC was 85% with this calculation.
Regards, Thomas
2013/9/19 Håkon Markussen <hakon.markussen@gmail.com>
@Thomas: Are you sure this calculation is correct for iMiEV? *car_SOC = (char)(((int)can_databuffer[1] - 10) / 2); *
This means byte 1 can be: Ah (d10) = 0% SOC (minimum) 6Eh (d110) = 50% SOC D2h (d210) = 100% SOC (maximum)
Br. Håkon
2013/9/19 Thomas Bergo <thomas.bergo@gmail.com>
Thank you for your attention.
This is the same information that i have:
SOC shuld be 0x374, byte 1. This I have confirmed using my laptop and the CAN-Do SW.
I used the Think code as a template for setting up the filter and poll interupts. So I belived that it shuld be a straight forward task to read the messages.
I will post my filter setup and poll1 code later, I belive that you will see what's wrong.
Regards, Thomas
torsdag 19. september 2013 skrev Nikolay Shishkov følgende:
Hi Thomas,
Here is some info on the messages that you can see on the Miev CAN bus. 0x210 - accelerator pedal 0x298 - trip meter 0x346 - range 0x373 - amps, volts 0x374 - SOC 0x389 - Amp, Volts 0x412 - speed, odometer 0x418 - shifter position 0x424 - switches and stuff - like lights, etc. 0x6E1, 0x6E2, 0x6E3, 0x6E4 - cell voltages, and temps
Once you get familiar with the ovms, maybe you can find it easier to use the Twizy or the Think code, instead of starting from scratch.
Hope this helps, Nikolay
------------------------------ *From:* Thomas Bergo <thomas.bergo@gmail.com> *To:* OVMS Developers <ovmsdev@lists.teslaclub.hk> *Sent:* Thursday, September 19, 2013 9:01 AM *Subject:* Re: [Ovmsdev] i-Miev/C-Zero/iOn
Yesterday I managed to verify that both poll0 and poll1 interrupt is called.
Printed "car_idealrange =id;" from poll0 to see the PID's that triggered the interrupt. Only get id 768 (0x300) printed out.
Also tried to do a the printout fom inside case 0x374: but no updates. The strange ting is that I can see a lot of "374" messages, and none "300" when using my laptop.
Start wonder if the PID "374" that I find on my laptop is not a hex value? Any one here that has any experiance with CAN-Do SW for analysing CAN mesages?
Will do some more testing later.
Regards, Thomas
onsdag 18. september 2013 skrev Mark Webb-Johnson følgende:
Is there a simple way to print out a value to the DIAG port for debugging?
You can just net_puts it, normally prefixed with a "#" sign as a comment. Have a look in diag.c for lots of examples. You will need to type 'ATE1' when going into diag mode, to get the echo output. The way it works is that you send the command to the modem (net_puts()), which discards it as unrecognised, but echos it back to the terminal.
But, you can't do that in interrupt handlers - only in normal ticker(), or message handler, style code
Regards, Mark.
On 18 Sep, 2013, at 8:22 PM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Thank you for your help.
Fixed some typos and now ODO updates in "STAT?" ODO is still wrong, but at least i get updates. No luck with SOC so far.
Have verified that the PID and the data is correct by using a CAN interface on my laptop.
Will do some more debugging to verify that both poll0 and poll1 is called.
Is there a simple way to print out a value to the DIAG port for debugging?
Regards, Thomas
2013/9/17 Mark Webb-Johnson <mark@webb-johnson.net>
Thanks, Håkon - nice clear answer.
One other suggestion is that you can put "car_idealrange++; return TRUE;" and "car_estrange++; return TRUE;" in the poll0 and poll1 functions, near the top. A few STAT commands and you can see if the poll functions are actually being called. You can also put "car_idealrange=id; return TRUE;", etc, to get an idea of what IDs are being delivered. It is very nasty trying to debug interrupt handlers, but this approach can help.
The diag port mentioned is shown here:
OVMS Setup Diagnostics Mode<http://www.youtube.com/watch?v=-24PoWtHVzk>
Regards, Mark.
On 16 Sep, 2013, at 4:55 PM, Håkon Markussen < hakon.markussen@gmail.com> wrote:
Hi Thomas,
*"Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?" *
Are you able to read any CAN-bus values from your iMiEV?
I experienced once at my Think City, that the Ovms-module did not read the CAN-bus at all; I got 0% SOC. The problem was I had two external CAN-devices connected at the same time (Duinomite Mega + OVMS). It worked fine when both modules were powered on at the same time, but Ovms failed to read the bus when the Duinomite Mega was powered off.
Du you have access to any kind of can-reader tool? This can be used to verify that you are looking at the correct bytes. I've used P-CAN USB adapter http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 and PCANView http://www.computer-solutions.co.uk/gendev/can-basic-dll.htm
You can use it to verify you have SOC in msg 0x374 byte 1.
To understand the mask and filter, you have to consider the mask as a bit "enable" / "disable". Any zero in the mask bit disables that
_______________________________________________ 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
This seems to have worked - I am now getting SOC reported as 99% with 43 miles range predicted. It looks like the range from the car is already in miles, so it is being reduced by a factor of ~1.6 erroneously. I will do a bit more testing, then report. Matt On 21 September 2013 10:32, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
My understanding of the way the CAN filtering works is that the mask is not correct in the above code.
vehicle_mitsubishi_poll0() is attempting to accept messages with SIDs 0x346, 0x373, 0x374, 0x389, but the filter SID is set to 0x300 with mask 0x7f8 meaning that only messages with SIDs 0x30n where n is 8-f would be received.
To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700, but I am worried that may cause a flood of messages.
I will see if I can try the following:
// Buffer 0 (filters 0, 1) for extended PID responses RXB0CON = 0b00000000; // Mask0 = 0b11100000000 (0x700), filterbit 0,1,2 deactivated RXM0SIDL = 0b00000000; RXM0SIDH = 0b11100000;
// Filter0 0b01100000000 (0x300..0x3F8) RXF0SIDL = 0b00000000; RXF0SIDH = 0b01100000;
I may also try modifying the RX0 mask during the 1-second poll so that it cycles through filtering a single SID each time, meaning that it will take 4 seconds for a full update. I don't think this will be an issue as none of this data is fast changing.
Matt Beard
On 19 September 2013 16:10, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Here is the code I'm trying for reading the SOC,
*Filter:*
// Filters: low byte bits 7..5 are the low 3 bits of the filter, and bits 4..0 are all zeros // high byte bits 7..0 are the high 8 bits of the filter // So total is 11 bits
// Buffer 0 (filters 0, 1) for extended PID responses RXB0CON = 0b00000000; // Mask0 = 0b11111111000 (0x7F8), filterbit 0,1,2 deactivated RXM0SIDL = 0b00000000; RXM0SIDH = 0b11111111;
// Filter0 0b01100000000 (0x300..0x3F8) RXF0SIDL = 0b00000000; RXF0SIDH = 0b01100000;
*Can_poll*:
//////////////////////////////////////////////////////////////////////// // can_poll() // This function is an entry point from the main() program loop, and // gives the CAN framework an opportunity to poll for data. // BOOL vehicle_mitsubishi_poll0(void) { unsigned int id = ((unsigned int)RXB0SIDL >>5) + ((unsigned int)RXB0SIDH <<3);
can_datalength = RXB0DLC & 0x0F; // number of received bytes can_databuffer[0] = RXB0D0; can_databuffer[1] = RXB0D1; can_databuffer[2] = RXB0D2; can_databuffer[3] = RXB0D3; can_databuffer[4] = RXB0D4; can_databuffer[5] = RXB0D5; can_databuffer[6] = RXB0D6; can_databuffer[7] = RXB0D7;
RXB0CONbits.RXFUL = 0; // All bytes read, Clear flag
car_estrange = id; //debug
switch (id) { /* case 0x346: car_estrange = MiFromKm((unsigned int)can_databuffer[7]); // Range car_idealrange = car_estrange; break;
case 0x373: // BatCurr & BatVolt break; */
case 0x374: car_idealrange = id; //debug car_SOC = (char)(((int)can_databuffer[1] - 10) / 2); //SOC break;
case 0x389: car_linevoltage = (unsigned int)can_databuffer[1]; car_chargecurrent = ((unsigned int)can_databuffer[6] / 10); break; }
return TRUE; }
I using car_estrange and car_idealrange for debug. car_estrange gets updates, but car_idealrange is never updated and are always 0. Have also tried car_estrange++; in the code, and I can see that the number increases for each DIAG message.
Regards, Thomas
2013/9/19 Thomas Bergo <thomas.bergo@gmail.com>
I'm pretty sure. I got this calculation from Xavier, he made the first version of the Canion app. A Android app to visualize data from the can-bus on i-Miev, iOn and C-Zero. https://play.google.com/store/apps/details?id=emobility.canion&hl=no
The calculation also seams to be correct when i logged the can bus during charging yesterday, I had 14 bars and SOC was 85% with this calculation.
Regards, Thomas
2013/9/19 Håkon Markussen <hakon.markussen@gmail.com>
@Thomas: Are you sure this calculation is correct for iMiEV? *car_SOC = (char)(((int)can_databuffer[1] - 10) / 2); *
This means byte 1 can be: Ah (d10) = 0% SOC (minimum) 6Eh (d110) = 50% SOC D2h (d210) = 100% SOC (maximum)
Br. Håkon
2013/9/19 Thomas Bergo <thomas.bergo@gmail.com>
Thank you for your attention.
This is the same information that i have:
SOC shuld be 0x374, byte 1. This I have confirmed using my laptop and the CAN-Do SW.
I used the Think code as a template for setting up the filter and poll interupts. So I belived that it shuld be a straight forward task to read the messages.
I will post my filter setup and poll1 code later, I belive that you will see what's wrong.
Regards, Thomas
torsdag 19. september 2013 skrev Nikolay Shishkov følgende:
Hi Thomas,
Here is some info on the messages that you can see on the Miev CAN bus. 0x210 - accelerator pedal 0x298 - trip meter 0x346 - range 0x373 - amps, volts 0x374 - SOC 0x389 - Amp, Volts 0x412 - speed, odometer 0x418 - shifter position 0x424 - switches and stuff - like lights, etc. 0x6E1, 0x6E2, 0x6E3, 0x6E4 - cell voltages, and temps
Once you get familiar with the ovms, maybe you can find it easier to use the Twizy or the Think code, instead of starting from scratch.
Hope this helps, Nikolay
------------------------------ *From:* Thomas Bergo <thomas.bergo@gmail.com> *To:* OVMS Developers <ovmsdev@lists.teslaclub.hk> *Sent:* Thursday, September 19, 2013 9:01 AM *Subject:* Re: [Ovmsdev] i-Miev/C-Zero/iOn
Yesterday I managed to verify that both poll0 and poll1 interrupt is called.
Printed "car_idealrange =id;" from poll0 to see the PID's that triggered the interrupt. Only get id 768 (0x300) printed out.
Also tried to do a the printout fom inside case 0x374: but no updates. The strange ting is that I can see a lot of "374" messages, and none "300" when using my laptop.
Start wonder if the PID "374" that I find on my laptop is not a hex value? Any one here that has any experiance with CAN-Do SW for analysing CAN mesages?
Will do some more testing later.
Regards, Thomas
onsdag 18. september 2013 skrev Mark Webb-Johnson følgende:
Is there a simple way to print out a value to the DIAG port for debugging?
You can just net_puts it, normally prefixed with a "#" sign as a comment. Have a look in diag.c for lots of examples. You will need to type 'ATE1' when going into diag mode, to get the echo output. The way it works is that you send the command to the modem (net_puts()), which discards it as unrecognised, but echos it back to the terminal.
But, you can't do that in interrupt handlers - only in normal ticker(), or message handler, style code
Regards, Mark.
On 18 Sep, 2013, at 8:22 PM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Thank you for your help.
Fixed some typos and now ODO updates in "STAT?" ODO is still wrong, but at least i get updates. No luck with SOC so far.
Have verified that the PID and the data is correct by using a CAN interface on my laptop.
Will do some more debugging to verify that both poll0 and poll1 is called.
Is there a simple way to print out a value to the DIAG port for debugging?
Regards, Thomas
2013/9/17 Mark Webb-Johnson <mark@webb-johnson.net>
Thanks, Håkon - nice clear answer.
One other suggestion is that you can put "car_idealrange++; return TRUE;" and "car_estrange++; return TRUE;" in the poll0 and poll1 functions, near the top. A few STAT commands and you can see if the poll functions are actually being called. You can also put "car_idealrange=id; return TRUE;", etc, to get an idea of what IDs are being delivered. It is very nasty trying to debug interrupt handlers, but this approach can help.
The diag port mentioned is shown here:
OVMS Setup Diagnostics Mode<http://www.youtube.com/watch?v=-24PoWtHVzk>
Regards, Mark.
On 16 Sep, 2013, at 4:55 PM, Håkon Markussen < hakon.markussen@gmail.com> wrote:
Hi Thomas,
*"Still has some debugging to do on the i-Miev code, as i'm only get "SOC: 0%" from STAT?" *
Are you able to read any CAN-bus values from your iMiEV?
I experienced once at my Think City, that the Ovms-module did not read the CAN-bus at all; I got 0% SOC. The problem was I had two external CAN-devices connected at the same time (Duinomite Mega + OVMS). It worked fine when both modules were powered on at the same time, but Ovms failed to read the bus when the Duinomite Mega was powered off.
Du you have access to any kind of can-reader tool? This can be used to verify that you are looking at the correct bytes. I've used P-CAN USB adapter http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 and PCANView http://www.computer-solutions.co.uk/gendev/can-basic-dll.htm
You can use it to verify you have SOC in msg 0x374 byte 1.
To understand the mask and filter, you have to consider the mask as a bit "enable" / "disable". Any zero in the mask bit disables that
_______________________________________________ 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
OK, The iMiev/iOn/C-Zero code currently works with the attached source file. The charge state and SOC work, as do the charge voltage and current it seems. Estimated range works, and I made the "ideal range" assume that 100% would ideally get you 80miles. I added battery temperature, based on the average of 24 of the 64 available temperature values, and this seems to work. I also tried to set tPEM to min cell temperature and tMotor to max cell temperature, but seem to have done something wrong! I have run out of time, so feel free to look at what I have done and fiddle! Matt P.S. I don't know how to tell if odo and speed are correct, but I changed them as I am pretty certain that the values on the CAN bus are in miles and mph when the car is set to miles. P.P.S. We need some iMiev pictures in the app now! On 21 September 2013 13:21, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
This seems to have worked - I am now getting SOC reported as 99% with 43 miles range predicted.
It looks like the range from the car is already in miles, so it is being reduced by a factor of ~1.6 erroneously.
I will do a bit more testing, then report.
Matt
On 21 September 2013 10:32, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
My understanding of the way the CAN filtering works is that the mask is not correct in the above code.
vehicle_mitsubishi_poll0() is attempting to accept messages with SIDs 0x346, 0x373, 0x374, 0x389, but the filter SID is set to 0x300 with mask 0x7f8 meaning that only messages with SIDs 0x30n where n is 8-f would be received.
To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700, but I am worried that may cause a flood of messages.
I will see if I can try the following:
// Buffer 0 (filters 0, 1) for extended PID responses RXB0CON = 0b00000000; // Mask0 = 0b11100000000 (0x700), filterbit 0,1,2 deactivated RXM0SIDL = 0b00000000; RXM0SIDH = 0b11100000;
// Filter0 0b01100000000 (0x300..0x3F8) RXF0SIDL = 0b00000000; RXF0SIDH = 0b01100000;
I may also try modifying the RX0 mask during the 1-second poll so that it cycles through filtering a single SID each time, meaning that it will take 4 seconds for a full update. I don't think this will be an issue as none of this data is fast changing.
Matt Beard
On 19 September 2013 16:10, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Here is the code I'm trying for reading the SOC,
*Filter:*
// Filters: low byte bits 7..5 are the low 3 bits of the filter, and bits 4..0 are all zeros // high byte bits 7..0 are the high 8 bits of the filter // So total is 11 bits
// Buffer 0 (filters 0, 1) for extended PID responses RXB0CON = 0b00000000; // Mask0 = 0b11111111000 (0x7F8), filterbit 0,1,2 deactivated RXM0SIDL = 0b00000000; RXM0SIDH = 0b11111111;
// Filter0 0b01100000000 (0x300..0x3F8) RXF0SIDL = 0b00000000; RXF0SIDH = 0b01100000;
*Can_poll*:
//////////////////////////////////////////////////////////////////////// // can_poll() // This function is an entry point from the main() program loop, and // gives the CAN framework an opportunity to poll for data. // BOOL vehicle_mitsubishi_poll0(void) { unsigned int id = ((unsigned int)RXB0SIDL >>5) + ((unsigned int)RXB0SIDH <<3);
can_datalength = RXB0DLC & 0x0F; // number of received bytes can_databuffer[0] = RXB0D0; can_databuffer[1] = RXB0D1; can_databuffer[2] = RXB0D2; can_databuffer[3] = RXB0D3; can_databuffer[4] = RXB0D4; can_databuffer[5] = RXB0D5; can_databuffer[6] = RXB0D6; can_databuffer[7] = RXB0D7;
RXB0CONbits.RXFUL = 0; // All bytes read, Clear flag
car_estrange = id; //debug
switch (id) { /* case 0x346: car_estrange = MiFromKm((unsigned int)can_databuffer[7]); // Range car_idealrange = car_estrange; break;
case 0x373: // BatCurr & BatVolt break; */
case 0x374: car_idealrange = id; //debug car_SOC = (char)(((int)can_databuffer[1] - 10) / 2); //SOC break;
case 0x389: car_linevoltage = (unsigned int)can_databuffer[1]; car_chargecurrent = ((unsigned int)can_databuffer[6] / 10); break; }
return TRUE; }
I using car_estrange and car_idealrange for debug. car_estrange gets updates, but car_idealrange is never updated and are always 0. Have also tried car_estrange++; in the code, and I can see that the number increases for each DIAG message.
Regards, Thomas
2013/9/19 Thomas Bergo <thomas.bergo@gmail.com>
I'm pretty sure. I got this calculation from Xavier, he made the first version of the Canion app. A Android app to visualize data from the can-bus on i-Miev, iOn and C-Zero. https://play.google.com/store/apps/details?id=emobility.canion&hl=no
The calculation also seams to be correct when i logged the can bus during charging yesterday, I had 14 bars and SOC was 85% with this calculation.
Regards, Thomas
2013/9/19 Håkon Markussen <hakon.markussen@gmail.com>
@Thomas: Are you sure this calculation is correct for iMiEV? *car_SOC = (char)(((int)can_databuffer[1] - 10) / 2); *
This means byte 1 can be: Ah (d10) = 0% SOC (minimum) 6Eh (d110) = 50% SOC D2h (d210) = 100% SOC (maximum)
Br. Håkon
2013/9/19 Thomas Bergo <thomas.bergo@gmail.com>
Thank you for your attention.
This is the same information that i have:
SOC shuld be 0x374, byte 1. This I have confirmed using my laptop and the CAN-Do SW.
I used the Think code as a template for setting up the filter and poll interupts. So I belived that it shuld be a straight forward task to read the messages.
I will post my filter setup and poll1 code later, I belive that you will see what's wrong.
Regards, Thomas
torsdag 19. september 2013 skrev Nikolay Shishkov følgende:
Hi Thomas, > > Here is some info on the messages that you can see on the Miev CAN > bus. > 0x210 - accelerator pedal > 0x298 - trip meter > 0x346 - range > 0x373 - amps, volts > 0x374 - SOC > 0x389 - Amp, Volts > 0x412 - speed, odometer > 0x418 - shifter position > 0x424 - switches and stuff - like lights, etc. > 0x6E1, 0x6E2, 0x6E3, 0x6E4 - cell voltages, and temps > > Once you get familiar with the ovms, maybe you can find it easier to > use the Twizy or the Think code, instead of starting from scratch. > > Hope this helps, > Nikolay > > ------------------------------ > *From:* Thomas Bergo <thomas.bergo@gmail.com> > *To:* OVMS Developers <ovmsdev@lists.teslaclub.hk> > *Sent:* Thursday, September 19, 2013 9:01 AM > *Subject:* Re: [Ovmsdev] i-Miev/C-Zero/iOn > > Yesterday I managed to verify that both poll0 and poll1 interrupt is > called. > > Printed "car_idealrange =id;" from poll0 to see the PID's that > triggered the interrupt. Only get id 768 (0x300) printed out. > > Also tried to do a the printout fom inside case 0x374: but no > updates. The strange ting is that I can see a lot of "374" messages, > and none "300" when using my laptop. > > Start wonder if the PID "374" that I find on my laptop is not a hex > value? Any one here that has any experiance with CAN-Do SW for analysing CAN > mesages? > > Will do some more testing later. > > Regards, Thomas > > onsdag 18. september 2013 skrev Mark Webb-Johnson følgende: > > > Is there a simple way to print out a value to the DIAG port for > debugging? > > > You can just net_puts it, normally prefixed with a "#" sign as a > comment. Have a look in diag.c for lots of examples. You will need to type > 'ATE1' when going into diag mode, to get the echo output. The way it works > is that you send the command to the modem (net_puts()), which discards it > as unrecognised, but echos it back to the terminal. > > But, you can't do that in interrupt handlers - only in normal > ticker(), or message handler, style code > > Regards, Mark. > > On 18 Sep, 2013, at 8:22 PM, Thomas Bergo <thomas.bergo@gmail.com> > wrote: > > Thank you for your help. > > Fixed some typos and now ODO updates in "STAT?" ODO is still wrong, > but at least i get updates. No luck with SOC so far. > > Have verified that the PID and the data is correct by using a CAN > interface on my laptop. > > Will do some more debugging to verify that both poll0 and poll1 is > called. > > Is there a simple way to print out a value to the DIAG port for > debugging? > > Regards, Thomas > > > 2013/9/17 Mark Webb-Johnson <mark@webb-johnson.net> > > > Thanks, Håkon - nice clear answer. > > One other suggestion is that you can put "car_idealrange++; return > TRUE;" and "car_estrange++; return TRUE;" in the poll0 and poll1 functions, > near the top. A few STAT commands and you can see if the poll functions are > actually being called. You can also put "car_idealrange=id; return TRUE;", > etc, to get an idea of what IDs are being delivered. It is very nasty > trying to debug interrupt handlers, but this approach can help. > > The diag port mentioned is shown here: > > OVMS Setup Diagnostics Mode<http://www.youtube.com/watch?v=-24PoWtHVzk> > > > Regards, Mark. > > On 16 Sep, 2013, at 4:55 PM, Håkon Markussen < > hakon.markussen@gmail.com> wrote: > > Hi Thomas, > > *"Still has some debugging to do on the i-Miev code, as i'm only > get "SOC: 0%" from STAT?" > * > > Are you able to read any CAN-bus values from your iMiEV? > > I experienced once at my Think City, that the Ovms-module did not > read the CAN-bus at all; I got 0% SOC. > The problem was I had two external CAN-devices connected at the same > time (Duinomite Mega + OVMS). It worked fine when both modules were powered > on at the same time, but Ovms failed to read the bus when the Duinomite > Mega was powered off. > > Du you have access to any kind of can-reader tool? This can be used > to verify that you are looking at the correct bytes. > I've used P-CAN USB adapter > http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 > and PCANView > http://www.computer-solutions.co.uk/gendev/can-basic-dll.htm > > You can use it to verify you have SOC in msg 0x374 byte 1. > > To understand the mask and filter, you have to consider the mask as > a bit "enable" / "disable". Any zero in the mask bit disables that > > _______________________________________________ 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, You can only set the Mask and Filter in a Configuraton Mode. From Datasheet: 23.3.1 CONFIGURATION MODE The CAN module has to be initialized before the activation. This is only possible if the module is in the Configuration mode. The Configuration mode is requested by setting the REQOP2 bit. Only when the status bit, OPMODE2, has a high level can the initial- ization be performed. Afterwards, the Configuration registers, the Acceptance Mask registers and the Acceptance Filter registers can be written. The module is activated by setting the REQOP control bits to zero. The module will protect the user from accidentally violating the CAN protocol through programming errors. All registers which control the configuration of the module can not be modified while the module is on- line. The CAN module will not be allowed to enter the Configuration mode while a transmission or reception is taking place. The Configuration mode serves as a lock to protect the following registers: • ConfigurationRegisters • FunctionalModeSelectionRegisters • BitTimingRegisters • IdentifierAcceptanceFilterRegisters • IdentifierAcceptanceMaskRegisters • FilterandMaskControlRegisters • MaskSelectionRegisters In the Configuration mode, the module will not transmit or receive. The error counters are cleared and the interrupt flags remain unchanged. The programmer will have access to Configuration registers that are access restricted in other modes. ----------- I don't believe that it will work without bad sideeffects. Bye michael Am 21.09.2013 um 11:32 schrieb Matt Beard OVMS <smvo@mxf.org.uk>:
I may also try modifying the RX0 mask during the 1-second poll so that it cycles through filtering a single SID each time, meaning that it will take 4 seconds for a full update. I don't think this will be an issue as none of this data is fast changing.
Thanks to you all for participate. Managed to spend some time on this project yesterday and this this evening. Yesterday i was able to fix the ODO. And thanks to Matt i was able test the SOC, ideal range and Charge state. Added the battery temperature reading form Matt's code. My car is reporting range and ODO in Km, so added support to handle both miles and Km for ODO and Range based on can_mileskm. *"To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700, but I am worried that may cause a flood of messages."* The current code runs with this filter and mask, ans seems to be stable so far. Still see some errors with the ideal range and the temperature reading. The app is reporting PEM: -125C, Motor: 144C and Battery: 5C Pushed the code with updates from Matt to GitHub. Regards, Thomas 2013/9/21 Michael Jochum <mikeljo@mac.com>
Hi,
You can only set the Mask and Filter in a Configuraton Mode.
From Datasheet:
23.3.1 CONFIGURATION MODE
The CAN module has to be initialized before the activation. This is only possible if the module is in the Configuration mode. The Configuration mode is requested by setting the REQOP2 bit. Only when the status bit, OPMODE2, has a high level can the initial- ization be performed. Afterwards, the Configuration registers, the Acceptance Mask registers and the Acceptance Filter registers can be written. The module is activated by setting the REQOP control bits to zero.
The module will protect the user from accidentally violating the CAN protocol through programming errors. All registers which control the configuration of the module can not be modified while the module is on- line. The CAN module will not be allowed to enter the Configuration mode while a transmission or reception is taking place. The Configuration mode serves as a lock to protect the following registers:
• ConfigurationRegisters • FunctionalModeSelectionRegisters • BitTimingRegisters • IdentifierAcceptanceFilterRegisters • IdentifierAcceptanceMaskRegisters • FilterandMaskControlRegisters • MaskSelectionRegisters
In the Configuration mode, the module will not transmit or receive. The error counters are cleared and the interrupt flags remain unchanged. The programmer will have access to Configuration registers that are access restricted in other modes.
-----------
I don't believe that it will work without bad sideeffects.
Bye michael
Am 21.09.2013 um 11:32 schrieb Matt Beard OVMS <smvo@mxf.org.uk>:
I may also try modifying the RX0 mask during the 1-second poll so that it cycles through filtering a single SID each time, meaning that it will take 4 seconds for a full update. I don't think this will be an issue as none of this data is fast changing.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hello, its my first time posting here. I'm the primary developer for the GEVCU project. I have been watching the discussion about canbus filtering. This reminded me of the first time I found this project. I have to wonder why the OVMS project does not abstract away hardware implementation details. I find it odd that code to interface with a certain car is expected to directly use hardware registers. Why is that? Wouldn't it be better to have a canbus library that handles hardware access for everything else? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Welcome Colin, I'm a big fan of the GEVCU project and hope we can find ways of working on common hardware and software projects for the benefit of all EV drivers. All the best, Kevin Sharpe | Zero Carbon World
On 22 Sep 2013, at 02:11, "Collin Kidder" <collink@kkmfg.com> wrote:
Hello, its my first time posting here. I'm the primary developer for the GEVCU project. I have been watching the discussion about canbus filtering. This reminded me of the first time I found this project. I have to wonder why the OVMS project does not abstract away hardware implementation details. I find it odd that code to interface with a certain car is expected to directly use hardware registers. Why is that? Wouldn't it be better to have a canbus library that handles hardware access for everything else? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Collin, Good to have you involved. The GEVCU is an impressive project. I guess the answer to your question comes from the growth of OVMS from a project supporting one single EV to where it is today. When we switched from the single-vehicle model, to the vehicle.{h,c} plugin(sic) vehicle module arrangement, we did largely abstract out the interrupt handler and CAN message reception (so that the vehicle module gets the incoming CAN bus message in a simple subroutine callback), but we haven't done much to abstract either message transmission or CAN bus initialisation. Both would be sensible to do at this stage, as there is now considerable duplication in the individual vehicle modules. I think this can be cleanly done by extensions to vehicle.{h,c}. In particular, the polling arrangements for OBD-II style arrangements are good candidates for this. We do have to be careful, as that would be shared code and would increase firmware size for modules not using it (in particular the v1 hardware support we are trying to maintain). Regarding using a CAN bus library, the answer is that I don't know of a good one. There is a Microchip PIC18C version, but it really does little other than very trivial abstraction. Do you, or anyone else, know of any good PIC18 CAN/ECAN libraries suitable for adoption? Regards, Mark. On 22 Sep, 2013, at 5:35 AM, Collin Kidder <collink@kkmfg.com> wrote:
Hello, its my first time posting here. I'm the primary developer for the GEVCU project. I have been watching the discussion about canbus filtering. This reminded me of the first time I found this project. I have to wonder why the OVMS project does not abstract away hardware implementation details. I find it odd that code to interface with a certain car is expected to directly use hardware registers. Why is that? Wouldn't it be better to have a canbus library that handles hardware access for everything else? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity._______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I figured that the reason was something along those lines. Our progress with GEVCU has been a bit slow at times because we're actively trying to find such situations where things are too heavily tied to hardware and abstract. Of course, we're using an ARM Cortex M3 which is 84MHz and almost all instructions are single cycle. You're using a PIC chip and I assume you run 16-20MHz which puts your processor speed at somewhere around 4-5MIPS instead of the 84MIPS I've got to work with. So, I'm sensitive to the fact that you can't really go the gonzo C++ abstract everything route that we did. I actually have done a lot of PIC18 programming in the past, including CANBus programming. However, I was using the CCS compiler which has its own canbus library. So, actually I don't really know of a good library suitable for adoption. However, you've got it all right there in your code base anyway. I don't see much reason that a library could not be bootstrapped by copy/pasting canbus initialization and transmit to a new file and making them a little more generic so that each car module can call them. From there it would be necessary to decide just how all encompassing the library should end up being. I'm actually the primary author of the canbus library for the Arduino Due and I'm thinking of making that library easy enough to use that one could write a line like this: CAN.setFilter(2, 600, 620, CAN_STD); in order to create a filter for mailbox 2 that allows canbus frames with id's from 600 to 620. Currently the library requires one to input the mask and filter but I'm wondering if the end programmers really need to care that much about how canbus works. It seems like the average programmer will be more interested in getting the code to work with their car. They know the ids of the frames they need so asking for the id range seems easier on the programmer. Sure, it's harder on the writer of the library but you only have to do it once. I don't have any OVMS hardware but I do still have several PIC18 based devices hanging around so maybe I'll try to come up with a decent PIC18 canbus library that isn't encumbered by license restrictions. Refresh my memory, which compiler are you using? The free, non optimizing one you can get with MPLAB? On Mon, Sep 23, 2013 at 3:03 AM, Mark Webb-Johnson <mark@webb-johnson.net>wrote:
I guess the answer to your question comes from the growth of OVMS from a project supporting one single EV to where it is today.
When we switched from the single-vehicle model, to the vehicle.{h,c} plugin(sic) vehicle module arrangement, we did largely abstract out the interrupt handler and CAN message reception (so that the vehicle module gets the incoming CAN bus message in a simple subroutine callback), but we haven't done much to abstract either message transmission or CAN bus initialisation. Both would be sensible to do at this stage, as there is now considerable duplication in the individual vehicle modules. I think this can be cleanly done by extensions to vehicle.{h,c}. In particular, the polling arrangements for OBD-II style arrangements are good candidates for this. We do have to be careful, as that would be shared code and would increase firmware size for modules not using it (in particular the v1 hardware support we are trying to maintain).
Regarding using a CAN bus library, the answer is that I don't know of a good one. There is a Microchip PIC18C version, but it really does little other than very trivial abstraction. Do you, or anyone else, know of any good PIC18 CAN/ECAN libraries suitable for adoption?
Regards, Mark.
Yes, we're using the MCC18 compiler from Microchip. Any help you can provide for this would be most appreciated. For the less experienced developers, the initialisation code (masks, etc) is tough to understand. As you say, all they want is the IDs. One thing I can do quite easily is to re-work the vehicle.{h,c} interface for vehicle_fn_poll0 and vehicle_fn_poll1. These are the two CAN callbacks. We can easily extract the filter, message ID, and 8 bytes of message, and pass them as arguments to the function. Every vehicle module I've seen does pretty much the same thing with these and putting all that code in one place would save us some flash. Regards, Mark. On 23 Sep, 2013, at 8:46 PM, Collin Kidder <collink@kkmfg.com> wrote:
I figured that the reason was something along those lines. Our progress with GEVCU has been a bit slow at times because we're actively trying to find such situations where things are too heavily tied to hardware and abstract. Of course, we're using an ARM Cortex M3 which is 84MHz and almost all instructions are single cycle. You're using a PIC chip and I assume you run 16-20MHz which puts your processor speed at somewhere around 4-5MIPS instead of the 84MIPS I've got to work with. So, I'm sensitive to the fact that you can't really go the gonzo C++ abstract everything route that we did.
I actually have done a lot of PIC18 programming in the past, including CANBus programming. However, I was using the CCS compiler which has its own canbus library. So, actually I don't really know of a good library suitable for adoption. However, you've got it all right there in your code base anyway. I don't see much reason that a library could not be bootstrapped by copy/pasting canbus initialization and transmit to a new file and making them a little more generic so that each car module can call them. From there it would be necessary to decide just how all encompassing the library should end up being. I'm actually the primary author of the canbus library for the Arduino Due and I'm thinking of making that library easy enough to use that one could write a line like this: CAN.setFilter(2, 600, 620, CAN_STD); in order to create a filter for mailbox 2 that allows canbus frames with id's from 600 to 620. Currently the library requires one to input the mask and filter but I'm wondering if the end programmers really need to care that much about how canbus works. It seems like the average programmer will be more interested in getting the code to work with their car. They know the ids of the frames they need so asking for the id range seems easier on the programmer. Sure, it's harder on the writer of the library but you only have to do it once.
I don't have any OVMS hardware but I do still have several PIC18 based devices hanging around so maybe I'll try to come up with a decent PIC18 canbus library that isn't encumbered by license restrictions. Refresh my memory, which compiler are you using? The free, non optimizing one you can get with MPLAB?
On Mon, Sep 23, 2013 at 3:03 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I guess the answer to your question comes from the growth of OVMS from a project supporting one single EV to where it is today.
When we switched from the single-vehicle model, to the vehicle.{h,c} plugin(sic) vehicle module arrangement, we did largely abstract out the interrupt handler and CAN message reception (so that the vehicle module gets the incoming CAN bus message in a simple subroutine callback), but we haven't done much to abstract either message transmission or CAN bus initialisation. Both would be sensible to do at this stage, as there is now considerable duplication in the individual vehicle modules. I think this can be cleanly done by extensions to vehicle.{h,c}. In particular, the polling arrangements for OBD-II style arrangements are good candidates for this. We do have to be careful, as that would be shared code and would increase firmware size for modules not using it (in particular the v1 hardware support we are trying to maintain).
Regarding using a CAN bus library, the answer is that I don't know of a good one. There is a Microchip PIC18C version, but it really does little other than very trivial abstraction. Do you, or anyone else, know of any good PIC18 CAN/ECAN libraries suitable for adoption?
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Have tested and fixed a lot of errors this weekend. and i believe that the code is now in a state where it can be merged into the main project. Have pushed a release 1.3 to my fork on GitHub. Changes: 1.3 23.09.13 (Thomas) - Fixed charging notification when battery is full, SOC=100% - TODO: Fix battery temperature reading. 1.2 22.09.13 (Thomas) - Fixed Ideal range - Added parking timer - Added detection of car is asleep. 1.1 21.09.13 (Thomas) - Fixed ODO - Fixed filter and mask for poll0 (thanks to Matt Beard) - Verified estimated range - Verified SOC - Verified Charge state - Added battery temperature reading (thanks to Matt Beard) 1.0 Initial release Regards, Thomas 2013/9/21 Thomas Bergo <thomas.bergo@gmail.com>
Thanks to you all for participate.
Managed to spend some time on this project yesterday and this this evening.
Yesterday i was able to fix the ODO. And thanks to Matt i was able test the SOC, ideal range and Charge state. Added the battery temperature reading form Matt's code.
My car is reporting range and ODO in Km, so added support to handle both miles and Km for ODO and Range based on can_mileskm.
*"To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700, but I am worried that may cause a flood of messages."* The current code runs with this filter and mask, ans seems to be stable so far.
Still see some errors with the ideal range and the temperature reading. The app is reporting PEM: -125C, Motor: 144C and Battery: 5C
Pushed the code with updates from Matt to GitHub.
Regards, Thomas
2013/9/21 Michael Jochum <mikeljo@mac.com>
Hi,
You can only set the Mask and Filter in a Configuraton Mode.
From Datasheet:
23.3.1 CONFIGURATION MODE
The CAN module has to be initialized before the activation. This is only possible if the module is in the Configuration mode. The Configuration mode is requested by setting the REQOP2 bit. Only when the status bit, OPMODE2, has a high level can the initial- ization be performed. Afterwards, the Configuration registers, the Acceptance Mask registers and the Acceptance Filter registers can be written. The module is activated by setting the REQOP control bits to zero.
The module will protect the user from accidentally violating the CAN protocol through programming errors. All registers which control the configuration of the module can not be modified while the module is on- line. The CAN module will not be allowed to enter the Configuration mode while a transmission or reception is taking place. The Configuration mode serves as a lock to protect the following registers:
• ConfigurationRegisters • FunctionalModeSelectionRegisters • BitTimingRegisters • IdentifierAcceptanceFilterRegisters • IdentifierAcceptanceMaskRegisters • FilterandMaskControlRegisters • MaskSelectionRegisters
In the Configuration mode, the module will not transmit or receive. The error counters are cleared and the interrupt flags remain unchanged. The programmer will have access to Configuration registers that are access restricted in other modes.
-----------
I don't believe that it will work without bad sideeffects.
Bye michael
Am 21.09.2013 um 11:32 schrieb Matt Beard OVMS <smvo@mxf.org.uk>:
I may also try modifying the RX0 mask during the 1-second poll so that it cycles through filtering a single SID each time, meaning that it will take 4 seconds for a full update. I don't think this will be an issue as none of this data is fast changing.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Fantastic work, Thomas. A really useful addition to the project. I've merged in your changes to master (the pull request you sent was exactly how it should work). Regards, Mark. On 23 Sep, 2013, at 5:24 PM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Have tested and fixed a lot of errors this weekend. and i believe that the code is now in a state where it can be merged into the main project.
Have pushed a release 1.3 to my fork on GitHub.
Changes: 1.3 23.09.13 (Thomas) - Fixed charging notification when battery is full, SOC=100% - TODO: Fix battery temperature reading. 1.2 22.09.13 (Thomas) - Fixed Ideal range - Added parking timer - Added detection of car is asleep. 1.1 21.09.13 (Thomas) - Fixed ODO - Fixed filter and mask for poll0 (thanks to Matt Beard) - Verified estimated range - Verified SOC - Verified Charge state - Added battery temperature reading (thanks to Matt Beard) 1.0 Initial release
Regards, Thomas
2013/9/21 Thomas Bergo <thomas.bergo@gmail.com> Thanks to you all for participate.
Managed to spend some time on this project yesterday and this this evening.
Yesterday i was able to fix the ODO. And thanks to Matt i was able test the SOC, ideal range and Charge state. Added the battery temperature reading form Matt's code.
My car is reporting range and ODO in Km, so added support to handle both miles and Km for ODO and Range based on can_mileskm.
"To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700, but I am worried that may cause a flood of messages." The current code runs with this filter and mask, ans seems to be stable so far.
Still see some errors with the ideal range and the temperature reading. The app is reporting PEM: -125C, Motor: 144C and Battery: 5C
Pushed the code with updates from Matt to GitHub.
Regards, Thomas
2013/9/21 Michael Jochum <mikeljo@mac.com> Hi,
You can only set the Mask and Filter in a Configuraton Mode.
From Datasheet: 23.3.1 CONFIGURATION MODE
The CAN module has to be initialized before the activation. This is only possible if the module is in the Configuration mode. The Configuration mode is requested by setting the REQOP2 bit. Only when the status bit, OPMODE2, has a high level can the initial- ization be performed. Afterwards, the Configuration registers, the Acceptance Mask registers and the Acceptance Filter registers can be written. The module is activated by setting the REQOP control bits to zero.
The module will protect the user from accidentally violating the CAN protocol through programming errors. All registers which control the configuration of the module can not be modified while the module is on- line. The CAN module will not be allowed to enter the Configuration mode while a transmission or reception is taking place. The Configuration mode serves as a lock to protect the following registers:
• ConfigurationRegisters • FunctionalModeSelectionRegisters • BitTimingRegisters • IdentifierAcceptanceFilterRegisters • IdentifierAcceptanceMaskRegisters • FilterandMaskControlRegisters • MaskSelectionRegisters
In the Configuration mode, the module will not transmit or receive. The error counters are cleared and the interrupt flags remain unchanged. The programmer will have access to Configuration registers that are access restricted in other modes.
-----------
I don't believe that it will work without bad sideeffects.
Bye michael
Am 21.09.2013 um 11:32 schrieb Matt Beard OVMS <smvo@mxf.org.uk>:
I may also try modifying the RX0 mask during the 1-second poll so that it cycles through filtering a single SID each time, meaning that it will take 4 seconds for a full update. I don't think this will be an issue as none of this data is fast changing.
_______________________________________________ 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
OK - either this code is broken, or my OVMS is. I flashed the code and set the unit up - no go, kept rebooting and the GPRS does not work. Rebuild from clean. Reflashed, reloaded settings and still constant rebooting and GPRS does not work. Matt On 23 September 2013 10:24, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Have tested and fixed a lot of errors this weekend. and i believe that the code is now in a state where it can be merged into the main project.
Have pushed a release 1.3 to my fork on GitHub.
Changes: 1.3 23.09.13 (Thomas) - Fixed charging notification when battery is full, SOC=100% - TODO: Fix battery temperature reading. 1.2 22.09.13 (Thomas) - Fixed Ideal range - Added parking timer - Added detection of car is asleep. 1.1 21.09.13 (Thomas) - Fixed ODO - Fixed filter and mask for poll0 (thanks to Matt Beard) - Verified estimated range - Verified SOC - Verified Charge state - Added battery temperature reading (thanks to Matt Beard) 1.0 Initial release
Regards, Thomas
2013/9/21 Thomas Bergo <thomas.bergo@gmail.com>
Thanks to you all for participate.
Managed to spend some time on this project yesterday and this this evening.
Yesterday i was able to fix the ODO. And thanks to Matt i was able test the SOC, ideal range and Charge state. Added the battery temperature reading form Matt's code.
My car is reporting range and ODO in Km, so added support to handle both miles and Km for ODO and Range based on can_mileskm.
*"To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700, but I am worried that may cause a flood of messages."* The current code runs with this filter and mask, ans seems to be stable so far.
Still see some errors with the ideal range and the temperature reading. The app is reporting PEM: -125C, Motor: 144C and Battery: 5C
Pushed the code with updates from Matt to GitHub.
Regards, Thomas
2013/9/21 Michael Jochum <mikeljo@mac.com>
Hi,
You can only set the Mask and Filter in a Configuraton Mode.
From Datasheet:
23.3.1 CONFIGURATION MODE
The CAN module has to be initialized before the activation. This is only possible if the module is in the Configuration mode. The Configuration mode is requested by setting the REQOP2 bit. Only when the status bit, OPMODE2, has a high level can the initial- ization be performed. Afterwards, the Configuration registers, the Acceptance Mask registers and the Acceptance Filter registers can be written. The module is activated by setting the REQOP control bits to zero.
The module will protect the user from accidentally violating the CAN protocol through programming errors. All registers which control the configuration of the module can not be modified while the module is on- line. The CAN module will not be allowed to enter the Configuration mode while a transmission or reception is taking place. The Configuration mode serves as a lock to protect the following registers:
• ConfigurationRegisters • FunctionalModeSelectionRegisters • BitTimingRegisters • IdentifierAcceptanceFilterRegisters • IdentifierAcceptanceMaskRegisters • FilterandMaskControlRegisters • MaskSelectionRegisters
In the Configuration mode, the module will not transmit or receive. The error counters are cleared and the interrupt flags remain unchanged. The programmer will have access to Configuration registers that are access restricted in other modes.
-----------
I don't believe that it will work without bad sideeffects.
Bye michael
Am 21.09.2013 um 11:32 schrieb Matt Beard OVMS <smvo@mxf.org.uk>:
I may also try modifying the RX0 mask during the 1-second poll so that it cycles through filtering a single SID each time, meaning that it will take 4 seconds for a full update. I don't think this will be an issue as none of this data is fast changing.
_______________________________________________ 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 did a rebuild from clean to ensure that i running the exact same code. My OVMS module is booting as expected, and only the green led is blinking OK (one blink] Which version of the OVMS FW are you running? I have only tested with the 2.5.2 FW. Are there any significant changes from 2.5.2 that can impact the code to constantly reboot? Regards, Thomas 2013/9/23 Matt Beard OVMS <smvo@mxf.org.uk>
OK - either this code is broken, or my OVMS is.
I flashed the code and set the unit up - no go, kept rebooting and the GPRS does not work.
Rebuild from clean. Reflashed, reloaded settings and still constant rebooting and GPRS does not work.
Matt
On 23 September 2013 10:24, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Have tested and fixed a lot of errors this weekend. and i believe that the code is now in a state where it can be merged into the main project.
Have pushed a release 1.3 to my fork on GitHub.
Changes: 1.3 23.09.13 (Thomas) - Fixed charging notification when battery is full, SOC=100% - TODO: Fix battery temperature reading. 1.2 22.09.13 (Thomas) - Fixed Ideal range - Added parking timer - Added detection of car is asleep. 1.1 21.09.13 (Thomas) - Fixed ODO - Fixed filter and mask for poll0 (thanks to Matt Beard) - Verified estimated range - Verified SOC - Verified Charge state - Added battery temperature reading (thanks to Matt Beard) 1.0 Initial release
Regards, Thomas
2013/9/21 Thomas Bergo <thomas.bergo@gmail.com>
Thanks to you all for participate.
Managed to spend some time on this project yesterday and this this evening.
Yesterday i was able to fix the ODO. And thanks to Matt i was able test the SOC, ideal range and Charge state. Added the battery temperature reading form Matt's code.
My car is reporting range and ODO in Km, so added support to handle both miles and Km for ODO and Range based on can_mileskm.
*"To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700, but I am worried that may cause a flood of messages."* The current code runs with this filter and mask, ans seems to be stable so far.
Still see some errors with the ideal range and the temperature reading. The app is reporting PEM: -125C, Motor: 144C and Battery: 5C
Pushed the code with updates from Matt to GitHub.
Regards, Thomas
2013/9/21 Michael Jochum <mikeljo@mac.com>
Hi,
You can only set the Mask and Filter in a Configuraton Mode.
From Datasheet:
23.3.1 CONFIGURATION MODE
The CAN module has to be initialized before the activation. This is only possible if the module is in the Configuration mode. The Configuration mode is requested by setting the REQOP2 bit. Only when the status bit, OPMODE2, has a high level can the initial- ization be performed. Afterwards, the Configuration registers, the Acceptance Mask registers and the Acceptance Filter registers can be written. The module is activated by setting the REQOP control bits to zero.
The module will protect the user from accidentally violating the CAN protocol through programming errors. All registers which control the configuration of the module can not be modified while the module is on- line. The CAN module will not be allowed to enter the Configuration mode while a transmission or reception is taking place. The Configuration mode serves as a lock to protect the following registers:
• ConfigurationRegisters • FunctionalModeSelectionRegisters • BitTimingRegisters • IdentifierAcceptanceFilterRegisters • IdentifierAcceptanceMaskRegisters • FilterandMaskControlRegisters • MaskSelectionRegisters
In the Configuration mode, the module will not transmit or receive. The error counters are cleared and the interrupt flags remain unchanged. The programmer will have access to Configuration registers that are access restricted in other modes.
-----------
I don't believe that it will work without bad sideeffects.
Bye michael
Am 21.09.2013 um 11:32 schrieb Matt Beard OVMS <smvo@mxf.org.uk>:
I may also try modifying the RX0 mask during the 1-second poll so that it cycles through filtering a single SID each time, meaning that it will take 4 seconds for a full update. I don't think this will be an issue as none of this data is fast changing.
_______________________________________________ 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
Matt: I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module? Regards, Thomas 2013/9/23 Thomas Bergo <thomas.bergo@gmail.com>
I did a rebuild from clean to ensure that i running the exact same code. My OVMS module is booting as expected, and only the green led is blinking OK (one blink]
Which version of the OVMS FW are you running? I have only tested with the 2.5.2 FW. Are there any significant changes from 2.5.2 that can impact the code to constantly reboot?
Regards, Thomas
2013/9/23 Matt Beard OVMS <smvo@mxf.org.uk>
OK - either this code is broken, or my OVMS is.
I flashed the code and set the unit up - no go, kept rebooting and the GPRS does not work.
Rebuild from clean. Reflashed, reloaded settings and still constant rebooting and GPRS does not work.
Matt
On 23 September 2013 10:24, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Have tested and fixed a lot of errors this weekend. and i believe that the code is now in a state where it can be merged into the main project.
Have pushed a release 1.3 to my fork on GitHub.
Changes: 1.3 23.09.13 (Thomas) - Fixed charging notification when battery is full, SOC=100% - TODO: Fix battery temperature reading. 1.2 22.09.13 (Thomas) - Fixed Ideal range - Added parking timer - Added detection of car is asleep. 1.1 21.09.13 (Thomas) - Fixed ODO - Fixed filter and mask for poll0 (thanks to Matt Beard) - Verified estimated range - Verified SOC - Verified Charge state - Added battery temperature reading (thanks to Matt Beard) 1.0 Initial release
Regards, Thomas
2013/9/21 Thomas Bergo <thomas.bergo@gmail.com>
Thanks to you all for participate.
Managed to spend some time on this project yesterday and this this evening.
Yesterday i was able to fix the ODO. And thanks to Matt i was able test the SOC, ideal range and Charge state. Added the battery temperature reading form Matt's code.
My car is reporting range and ODO in Km, so added support to handle both miles and Km for ODO and Range based on can_mileskm.
*"To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700, but I am worried that may cause a flood of messages."* The current code runs with this filter and mask, ans seems to be stable so far.
Still see some errors with the ideal range and the temperature reading. The app is reporting PEM: -125C, Motor: 144C and Battery: 5C
Pushed the code with updates from Matt to GitHub.
Regards, Thomas
2013/9/21 Michael Jochum <mikeljo@mac.com>
Hi,
You can only set the Mask and Filter in a Configuraton Mode.
From Datasheet:
23.3.1 CONFIGURATION MODE
The CAN module has to be initialized before the activation. This is only possible if the module is in the Configuration mode. The Configuration mode is requested by setting the REQOP2 bit. Only when the status bit, OPMODE2, has a high level can the initial- ization be performed. Afterwards, the Configuration registers, the Acceptance Mask registers and the Acceptance Filter registers can be written. The module is activated by setting the REQOP control bits to zero.
The module will protect the user from accidentally violating the CAN protocol through programming errors. All registers which control the configuration of the module can not be modified while the module is on- line. The CAN module will not be allowed to enter the Configuration mode while a transmission or reception is taking place. The Configuration mode serves as a lock to protect the following registers:
• ConfigurationRegisters • FunctionalModeSelectionRegisters • BitTimingRegisters • IdentifierAcceptanceFilterRegisters • IdentifierAcceptanceMaskRegisters • FilterandMaskControlRegisters • MaskSelectionRegisters
In the Configuration mode, the module will not transmit or receive. The error counters are cleared and the interrupt flags remain unchanged. The programmer will have access to Configuration registers that are access restricted in other modes.
-----------
I don't believe that it will work without bad sideeffects.
Bye michael
Am 21.09.2013 um 11:32 schrieb Matt Beard OVMS <smvo@mxf.org.uk>:
I may also try modifying the RX0 mask during the 1-second poll so that it cycles through filtering a single SID each time, meaning that it will take 4 seconds for a full update. I don't think this will be an issue as none of this data is fast changing.
_______________________________________________ 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
Thomas, That would be really useful. I am worried that the module may have failed. I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails. Matt On Monday, September 23, 2013, Thomas Bergo wrote:
Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
Regards, Thomas
2013/9/23 Thomas Bergo <thomas.bergo@gmail.com>
I did a rebuild from clean to ensure that i running the exact same code. My OVMS module is booting as expected, and only the green led is blinking OK (one blink]
Which version of the OVMS FW are you running? I have only tested with the 2.5.2 FW. Are there any significant changes from 2.5.2 that can impact the code to constantly reboot?
Regards, Thomas
2013/9/23 Matt Beard OVMS <smvo@mxf.org.uk>
OK - either this code is broken, or my OVMS is.
I flashed the code and set the unit up - no go, kept rebooting and the GPRS does not work.
Rebuild from clean. Reflashed, reloaded settings and still constant rebooting and GPRS does not work.
Matt
On 23 September 2013 10:24, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Have tested and fixed a lot of errors this weekend. and i believe that the code is now in a state where it can be merged into the main project.
Have pushed a release 1.3 to my fork on GitHub.
Changes: 1.3 23.09.13 (Thomas) - Fixed charging notification when battery is full, SOC=100% - TODO: Fix battery temperature reading. 1.2 22.09.13 (Thomas) - Fixed Ideal range - Added parking timer - Added detection of car is asleep. 1.1 21.09.13 (Thomas) - Fixed ODO - Fixed filter and mask for poll0 (thanks to Matt Beard) - Verified estimated range - Verified SOC - Verified Charge state - Added battery temperature reading (thanks to Matt Beard) 1.0 Initial release
Regards, Thomas
2013/9/21 Thomas Bergo <thomas.bergo@gmail.com>
Thanks to you all for participate.
Managed to spend some time on this project yesterday and this this evening.
Yesterday i was able to fix the ODO. And thanks to Matt i was able test the SOC, ideal range and Charge state. Added the battery temperature reading form Matt's code.
My car is reporting range and ODO in Km, so added support to handle both miles and Km for ODO and Range based on can_mileskm.
*"To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700, but I am worried that may cause a flood of messages."* The current code runs with this filter and mask, ans seems to be stable so far.
Still see some errors with the ideal range and the temperature reading. The app is reporting PEM: -125C, Motor: 144C and Battery: 5C
Pushed the code with updates from Matt to GitHub.
Regards, Thomas
2013/9/21 Michael Jochum <mikeljo@mac.com>
Hi,
You can only set the Mask and Filter in a Configuraton Mode.
From Datasheet:
2
Attached is the hex file, this is the exact same that is running om my module now. Regards, Thomas 2013/9/23 Matt Beard <matt@beard.tv>
Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote:
Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
Regards, Thomas
2013/9/23 Thomas Bergo <thomas.bergo@gmail.com>
I did a rebuild from clean to ensure that i running the exact same code. My OVMS module is booting as expected, and only the green led is blinking OK (one blink]
Which version of the OVMS FW are you running? I have only tested with the 2.5.2 FW. Are there any significant changes from 2.5.2 that can impact the code to constantly reboot?
Regards, Thomas
2013/9/23 Matt Beard OVMS <smvo@mxf.org.uk>
OK - either this code is broken, or my OVMS is.
I flashed the code and set the unit up - no go, kept rebooting and the GPRS does not work.
Rebuild from clean. Reflashed, reloaded settings and still constant rebooting and GPRS does not work.
Matt
On 23 September 2013 10:24, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Have tested and fixed a lot of errors this weekend. and i believe that the code is now in a state where it can be merged into the main project.
Have pushed a release 1.3 to my fork on GitHub.
Changes: 1.3 23.09.13 (Thomas) - Fixed charging notification when battery is full, SOC=100% - TODO: Fix battery temperature reading. 1.2 22.09.13 (Thomas) - Fixed Ideal range - Added parking timer - Added detection of car is asleep. 1.1 21.09.13 (Thomas) - Fixed ODO - Fixed filter and mask for poll0 (thanks to Matt Beard) - Verified estimated range - Verified SOC - Verified Charge state - Added battery temperature reading (thanks to Matt Beard) 1.0 Initial release
Regards, Thomas
2013/9/21 Thomas Bergo <thomas.bergo@gmail.com>
Thanks to you all for participate.
Managed to spend some time on this project yesterday and this this evening.
Yesterday i was able to fix the ODO. And thanks to Matt i was able test the SOC, ideal range and Charge state. Added the battery temperature reading form Matt's code.
My car is reporting range and ODO in Km, so added support to handle both miles and Km for ODO and Range based on can_mileskm.
*"To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700, but I am worried that may cause a flood of messages."* The current code runs with this filter and mask, ans seems to be stable so far.
Still see some errors with the ideal range and the temperature reading. The app is reporting PEM: -125C, Motor: 144C and Battery: 5C
Pushed the code with updates from Matt to GitHub.
Regards, Thomas
2013/9/21 Michael Jochum <mikeljo@mac.com>
Hi,
You can only set the Mask and Filter in a Configuraton Mode.
From Datasheet:
2
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Thanks Thomas, That has confirmed for me that my hardware has died. Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced! I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop. Matt On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv>
Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote:
Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
Regards, Thomas
2013/9/23 Thomas Bergo <thomas.bergo@gmail.com>
I did a rebuild from clean to ensure that i running the exact same code. My OVMS module is booting as expected, and only the green led is blinking OK (one blink]
Which version of the OVMS FW are you running? I have only tested with the 2.5.2 FW. Are there any significant changes from 2.5.2 that can impact the code to constantly reboot?
Regards, Thomas
2013/9/23 Matt Beard OVMS <smvo@mxf.org.uk>
OK - either this code is broken, or my OVMS is.
I flashed the code and set the unit up - no go, kept rebooting and the GPRS does not work.
Rebuild from clean. Reflashed, reloaded settings and still constant rebooting and GPRS does not work.
Matt
On 23 September 2013 10:24, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Have tested and fixed a lot of errors this weekend. and i believe that the code is now in a state where it can be merged into the main project.
Have pushed a release 1.3 to my fork on GitHub.
Changes: 1.3 23.09.13 (Thomas) - Fixed charging notification when battery is full, SOC=100% - TODO: Fix battery temperature reading. 1.2 22.09.13 (Thomas) - Fixed Ideal range - Added parking timer - Added detection of car is asleep. 1.1 21.09.13 (Thomas) - Fixed ODO - Fixed filter and mask for poll0 (thanks to Matt Beard) - Verified estimated range - Verified SOC - Verified Charge state - Added battery temperature reading (thanks to Matt Beard) 1.0 Initial release
Regards, Thomas
2013/9/21 Thomas Bergo <thomas.bergo@gmail.com>
Thanks to you all for participate.
Managed to spend some time on this project yesterday and this this evening.
Yesterday i was able to fix the ODO. And thanks to Matt i was able test the SOC, ideal range and Charge state. Added the battery temperature reading form Matt's code.
My car is reporting range and ODO in Km, so added support to handle both miles and Km for ODO and Range based on can_mileskm.
*"To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700, but I am worried that may cause a flood of messages."* The current code runs with this filter and mask, ans seems to be stable so far.
Still see some errors with the ideal range and the temperature reading. The app is reporting PEM: -125C, Motor: 144C and Battery: 5C
Pushed the code with updates from Matt to GitHub.
Regards, Thomas
2013/9/21 Michael Jochum <mikeljo@mac.com>
Hi,
You can only set the Mask and Filter in a Configuraton Mode.
From Datasheet:
2
_______________________________________________ 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
Matt, I have modules with me for replacement, if necessary. I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues. I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs. Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you. Regards, Mark. On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com> wrote: Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv> Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote: Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
Regards, Thomas
2013/9/23 Thomas Bergo <thomas.bergo@gmail.com> I did a rebuild from clean to ensure that i running the exact same code. My OVMS module is booting as expected, and only the green led is blinking OK (one blink]
Which version of the OVMS FW are you running? I have only tested with the 2.5.2 FW. Are there any significant changes from 2.5.2 that can impact the code to constantly reboot?
Regards, Thomas
2013/9/23 Matt Beard OVMS <smvo@mxf.org.uk> OK - either this code is broken, or my OVMS is.
I flashed the code and set the unit up - no go, kept rebooting and the GPRS does not work.
Rebuild from clean. Reflashed, reloaded settings and still constant rebooting and GPRS does not work.
Matt
On 23 September 2013 10:24, Thomas Bergo <thomas.bergo@gmail.com> wrote: Have tested and fixed a lot of errors this weekend. and i believe that the code is now in a state where it can be merged into the main project.
Have pushed a release 1.3 to my fork on GitHub.
Changes: 1.3 23.09.13 (Thomas) - Fixed charging notification when battery is full, SOC=100% - TODO: Fix battery temperature reading. 1.2 22.09.13 (Thomas) - Fixed Ideal range - Added parking timer - Added detection of car is asleep. 1.1 21.09.13 (Thomas) - Fixed ODO - Fixed filter and mask for poll0 (thanks to Matt Beard) - Verified estimated range - Verified SOC - Verified Charge state - Added battery temperature reading (thanks to Matt Beard) 1.0 Initial release
Regards, Thomas
2013/9/21 Thomas Bergo <thomas.bergo@gmail.com> Thanks to you all for participate.
Managed to spend some time on this project yesterday and this this evening.
Yesterday i was able to fix the ODO. And thanks to Matt i was able test the SOC, ideal range and Charge state. Added the battery temperature reading form Matt's code.
My car is reporting range and ODO in Km, so added support to handle both miles and Km for ODO and Range based on can_mileskm.
"To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700, but I am worried that may cause a flood of messages." The current code runs with this filter and mask, ans seems to be stable so far.
Still see some errors with the ideal range and the temperature reading. The app is reporting PEM: -125C, Motor: 144C and Battery: 5C
Pushed the code with updates from Matt to GitHub.
Regards, Thomas
2013/9/21 Michael Jochum <mikeljo@mac.com> Hi,
You can only set the Mask and Filter in a Configuraton Mode.
From Datasheet: 2
_______________________________________________ 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
The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide? Nikki. On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt,
I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com> wrote: Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv> Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote: Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
Regards, Thomas
2013/9/23 Thomas Bergo <thomas.bergo@gmail.com> I did a rebuild from clean to ensure that i running the exact same code. My OVMS module is booting as expected, and only the green led is blinking OK (one blink]
Which version of the OVMS FW are you running? I have only tested with the 2.5.2 FW. Are there any significant changes from 2.5.2 that can impact the code to constantly reboot?
Regards, Thomas
2013/9/23 Matt Beard OVMS <smvo@mxf.org.uk> OK - either this code is broken, or my OVMS is.
I flashed the code and set the unit up - no go, kept rebooting and the GPRS does not work.
Rebuild from clean. Reflashed, reloaded settings and still constant rebooting and GPRS does not work.
Matt
On 23 September 2013 10:24, Thomas Bergo <thomas.bergo@gmail.com> wrote: Have tested and fixed a lot of errors this weekend. and i believe that the code is now in a state where it can be merged into the main project.
Have pushed a release 1.3 to my fork on GitHub.
Changes: 1.3 23.09.13 (Thomas) - Fixed charging notification when battery is full, SOC=100% - TODO: Fix battery temperature reading. 1.2 22.09.13 (Thomas) - Fixed Ideal range - Added parking timer - Added detection of car is asleep. 1.1 21.09.13 (Thomas) - Fixed ODO - Fixed filter and mask for poll0 (thanks to Matt Beard) - Verified estimated range - Verified SOC - Verified Charge state - Added battery temperature reading (thanks to Matt Beard) 1.0 Initial release
Regards, Thomas
2013/9/21 Thomas Bergo <thomas.bergo@gmail.com> Thanks to you all for participate.
Managed to spend some time on this project yesterday and this this evening.
Yesterday i was able to fix the ODO. And thanks to Matt i was able test the SOC, ideal range and Charge state. Added the battery temperature reading form Matt's code.
My car is reporting range and ODO in Km, so added support to handle both miles and Km for ODO and Range based on can_mileskm.
"To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700, but I am worried that may cause a flood of messages." The current code runs with this filter and mask, ans seems to be stable so far.
Still see some errors with the ideal range and the temperature reading. The app is reporting PEM: -125C, Motor: 144C and Battery: 5C
Pushed the code with updates from Matt to GitHub.
Regards, Thomas
2013/9/21 Michael Jochum <mikeljo@mac.com> Hi,
You can only set the Mask and Filter in a Configuraton Mode.
From Datasheet: 2
_______________________________________________ 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
Actually, running it with stock firmware as OBDII in our ICE is next on my list of checks. Matt On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote:
The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide?
Nikki.
On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt,
I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv>
Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote:
Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
Regards, Thomas
2013/9/23 Thomas Bergo <thomas.bergo@gmail.com>
I did a rebuild from clean to ensure that i running the exact same code. My OVMS module is booting as expected, and only the green led is blinking OK (one blink]
Which version of the OVMS FW are you running? I have only tested with the 2.5.2 FW. Are there any significant changes from 2.5.2 that can impact the code to constantly reboot?
Regards, Thomas
2013/9/23 Matt Beard OVMS <smvo@mxf.org.uk>
OK - either this code is broken, or my OVMS is.
I flashed the code and set the unit up - no go, kept rebooting and the GPRS does not work.
Rebuild from clean. Reflashed, reloaded settings and still constant rebooting and GPRS does not work.
Matt
On 23 September 2013 10:24, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Great. In addition, you might want to try and attach something to the diagnostics port. You should be able to read through the port any AT commands, to make sure it's working correctly. I believe there's a list somewhere of the messages you'll get from the diagnostic port for that chip.. 901 is it? (I can't remember, but it's what we used to diagnose the SIM card was at fault.) Nikki. P.S. What SIM are you using? Global? O2? On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote:
Actually, running it with stock firmware as OBDII in our ICE is next on my list of checks.
Matt
On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote: The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide?
Nikki.
On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt,
I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com> wrote: Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv> Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote: Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
Regards, Thomas
2013/9/23 Thomas Bergo <thomas.bergo@gmail.com> I did a rebuild from clean to ensure that i running the exact same code. My OVMS module is booting as expected, and only the green led is blinking OK (one blink]
Which version of the OVMS FW are you running? I have only tested with the 2.5.2 FW. Are there any significant changes from 2.5.2 that can impact the code to constantly reboot?
Regards, Thomas
2013/9/23 Matt Beard OVMS <smvo@mxf.org.uk> OK - either this code is broken, or my OVMS is.
I flashed the code and set the unit up - no go, kept rebooting and the GPRS does not work.
Rebuild from clean. Reflashed, reloaded settings and still constant rebooting and GPRS does not work.
Matt
On 23 September 2013 10:24, Thomas Bergo <thomas.bergo@gmail.com> wrote:
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I'm using a Global SIM. I may try the diag port if I can find something that reads RS-232 in this day and age! I must try and get a USB adapter. Matt On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote:
Great. In addition, you might want to try and attach something to the diagnostics port. You should be able to read through the port any AT commands, to make sure it's working correctly.
I believe there's a list somewhere of the messages you'll get from the diagnostic port for that chip.. 901 is it? (I can't remember, but it's what we used to diagnose the SIM card was at fault.)
Nikki.
P.S. What SIM are you using? Global? O2?
On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv <javascript:_e({}, 'cvml', 'matt@beard.tv');>> wrote:
Actually, running it with stock firmware as OBDII in our ICE is next on my list of checks.
Matt
On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote:
The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide?
Nikki.
On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt,
I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv>
Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote:
Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
Regards, Thomas
2013/9/23 Thomas Bergo <thomas.bergo@gmail.com>
I did a rebuild from clean to ensure that i running the exact same code. My OVMS module is booting as expected, and only the green led is blinking OK (one blink]
Which version of the OVMS FW are you running? I have only tested with the 2.5.2 FW. Are there any significant changes from 2.5.2 that can impact the code to constantly reboot?
Regards, Thomas
2013/9/23 Matt Beard OVMS <smvo@mxf.org.uk>
OK - either this code is broken, or my OVMS is.
I flashed the code and set the unit up - no go, kept rebooting and the GPRS does not work.
Rebuild from clean. Reflashed, reloaded settings and still constant rebooting and GPRS does not work.
Matt
On 23 September 2013 10:24, Thomas Bergo <thomas.bergo@gmail.com> wrote:
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <javascript:_e({}, 'cvml', 'OvmsDev@lists.teslaclub.hk');> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
There is delivered some Citroen C-Zero with a smaller battery pack (13 KWh VS 16 KWh.) The ideal range for the 13 KWh battery I believe is 80 miles and for the 16 KWh battery the ideal range is 150km (93 miles). To calculate the ideal range correctly for both battery size we need a way to distinguish between them. Do you think that there will be any issues by using the Feature 14, Car bits, to indicate which battery pack the car has? Regards, Thomas 2013/9/24 Matt Beard <matt@beard.tv>
I'm using a Global SIM.
I may try the diag port if I can find something that reads RS-232 in this day and age! I must try and get a USB adapter.
Matt
On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote:
Great. In addition, you might want to try and attach something to the diagnostics port. You should be able to read through the port any AT commands, to make sure it's working correctly.
I believe there's a list somewhere of the messages you'll get from the diagnostic port for that chip.. 901 is it? (I can't remember, but it's what we used to diagnose the SIM card was at fault.)
Nikki.
P.S. What SIM are you using? Global? O2?
On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote:
Actually, running it with stock firmware as OBDII in our ICE is next on my list of checks.
Matt
On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote:
The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide?
Nikki.
On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt,
I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv>
Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote:
Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
Regards, Thomas
2013/9/23 Thomas Bergo <thomas.bergo@gmail.com>
I did a rebuild from clean to ensure that i running the exact same code. My OVMS module is booting as expected, and only the green led is blinking OK (one blink]
Which version of the OVMS FW are you running? I have only tested with the 2.5.2 FW. Are there any significant changes from 2.5.2 that can impact the code to constantly reboot?
Regards, Thomas
2013/9/23 Matt Beard OVMS <smvo@mxf.org.uk>
OK - either this code is broken, or my OVMS is.
I flashed the code and set the unit up - no go, kept rebooting and the GPRS does not work.
Rebuild from clean. Reflashed, reloaded settings and still constant rebooting and GPRS does not work.
Matt
On 23 September 2013 10:24, Thomas Bergo <thomas.bergo@gmail.com> wrote:
_______________________________________________ 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
You can tell how many cells from the 6en messages, but I heard that the range is the same, but the unused capacity is less so the batteries don't last as well. This needs to be confirmed. Matt On Tuesday, September 24, 2013, Thomas Bergo wrote:
There is delivered some Citroen C-Zero with a smaller battery pack (13 KWh VS 16 KWh.) The ideal range for the 13 KWh battery I believe is 80 miles and for the 16 KWh battery the ideal range is 150km (93 miles).
To calculate the ideal range correctly for both battery size we need a way to distinguish between them.
Do you think that there will be any issues by using the Feature 14, Car bits, to indicate which battery pack the car has?
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
I'm using a Global SIM.
I may try the diag port if I can find something that reads RS-232 in this day and age! I must try and get a USB adapter.
Matt
On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote:
Great. In addition, you might want to try and attach something to the diagnostics port. You should be able to read through the port any AT commands, to make sure it's working correctly.
I believe there's a list somewhere of the messages you'll get from the diagnostic port for that chip.. 901 is it? (I can't remember, but it's what we used to diagnose the SIM card was at fault.)
Nikki.
P.S. What SIM are you using? Global? O2?
On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote:
Actually, running it with stock firmware as OBDII in our ICE is next on my list of checks.
Matt
On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote:
The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide?
Nikki.
On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt,
I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv>
Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote:
Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
I read some rumors that some cars imported from Denmark to Norway had a smaller battery pack. Have to look some more to find where i read about this. Regards, Thomas 2013/9/24 Matt Beard <matt@beard.tv>
You can tell how many cells from the 6en messages, but I heard that the range is the same, but the unused capacity is less so the batteries don't last as well.
This needs to be confirmed.
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
There is delivered some Citroen C-Zero with a smaller battery pack (13 KWh VS 16 KWh.) The ideal range for the 13 KWh battery I believe is 80 miles and for the 16 KWh battery the ideal range is 150km (93 miles).
To calculate the ideal range correctly for both battery size we need a way to distinguish between them.
Do you think that there will be any issues by using the Feature 14, Car bits, to indicate which battery pack the car has?
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
I'm using a Global SIM.
I may try the diag port if I can find something that reads RS-232 in this day and age! I must try and get a USB adapter.
Matt
On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote:
Great. In addition, you might want to try and attach something to the diagnostics port. You should be able to read through the port any AT commands, to make sure it's working correctly.
I believe there's a list somewhere of the messages you'll get from the diagnostic port for that chip.. 901 is it? (I can't remember, but it's what we used to diagnose the SIM card was at fault.)
Nikki.
P.S. What SIM are you using? Global? O2?
On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote:
Actually, running it with stock firmware as OBDII in our ICE is next on my list of checks.
Matt
On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote:
The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide?
Nikki.
On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt,
I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv>
Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote:
Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I think my hardware may have a dodgy connection as it is working again! I am using the hex file Thomas sent (one that failed yesterday!) I noticed that the charge level is reported wrongly. I am using a 16A charger (and the car does charge at > 13A) yet the C-Zero code is reporting the charge type as "STANDARD 13A" and the charge current is showing as 12A. Matt On 24 September 2013 19:22, Thomas Bergo <thomas.bergo@gmail.com> wrote:
I read some rumors that some cars imported from Denmark to Norway had a smaller battery pack. Have to look some more to find where i read about this.
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
You can tell how many cells from the 6en messages, but I heard that the range is the same, but the unused capacity is less so the batteries don't last as well.
This needs to be confirmed.
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
There is delivered some Citroen C-Zero with a smaller battery pack (13 KWh VS 16 KWh.) The ideal range for the 13 KWh battery I believe is 80 miles and for the 16 KWh battery the ideal range is 150km (93 miles).
To calculate the ideal range correctly for both battery size we need a way to distinguish between them.
Do you think that there will be any issues by using the Feature 14, Car bits, to indicate which battery pack the car has?
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
I'm using a Global SIM.
I may try the diag port if I can find something that reads RS-232 in this day and age! I must try and get a USB adapter.
Matt
On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote:
Great. In addition, you might want to try and attach something to the diagnostics port. You should be able to read through the port any AT commands, to make sure it's working correctly.
I believe there's a list somewhere of the messages you'll get from the diagnostic port for that chip.. 901 is it? (I can't remember, but it's what we used to diagnose the SIM card was at fault.)
Nikki.
P.S. What SIM are you using? Global? O2?
On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote:
Actually, running it with stock firmware as OBDII in our ICE is next on my list of checks.
Matt
On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote:
The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide?
Nikki.
On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt,
I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv>
Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote:
Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
_______________________________________________ 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
The charger is only able to deliver 3 KW to the battery, so the car will maximum use 13A from the grid. I therefor hardcoded the charging to "STANDARD 13A" Regards, Thomas 2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
I think my hardware may have a dodgy connection as it is working again!
I am using the hex file Thomas sent (one that failed yesterday!)
I noticed that the charge level is reported wrongly. I am using a 16A charger (and the car does charge at > 13A) yet the C-Zero code is reporting the charge type as "STANDARD 13A" and the charge current is showing as 12A.
Matt
On 24 September 2013 19:22, Thomas Bergo <thomas.bergo@gmail.com> wrote:
I read some rumors that some cars imported from Denmark to Norway had a smaller battery pack. Have to look some more to find where i read about this.
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
You can tell how many cells from the 6en messages, but I heard that the range is the same, but the unused capacity is less so the batteries don't last as well.
This needs to be confirmed.
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
There is delivered some Citroen C-Zero with a smaller battery pack (13 KWh VS 16 KWh.) The ideal range for the 13 KWh battery I believe is 80 miles and for the 16 KWh battery the ideal range is 150km (93 miles).
To calculate the ideal range correctly for both battery size we need a way to distinguish between them.
Do you think that there will be any issues by using the Feature 14, Car bits, to indicate which battery pack the car has?
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
I'm using a Global SIM.
I may try the diag port if I can find something that reads RS-232 in this day and age! I must try and get a USB adapter.
Matt
On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote:
Great. In addition, you might want to try and attach something to the diagnostics port. You should be able to read through the port any AT commands, to make sure it's working correctly.
I believe there's a list somewhere of the messages you'll get from the diagnostic port for that chip.. 901 is it? (I can't remember, but it's what we used to diagnose the SIM card was at fault.)
Nikki.
P.S. What SIM are you using? Global? O2?
On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote:
Actually, running it with stock firmware as OBDII in our ICE is next on my list of checks.
Matt
On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote:
The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide?
Nikki.
On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt,
I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com>wrote:
Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv>
Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote:
Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
_______________________________________________ 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
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA. If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V. What does the Roadster version set - does it use the input current, or some version of the output current? I notice that the Volt/Ampera code sets 16A as the charge limit. Matt On 24 September 2013 19:58, Thomas Bergo <thomas.bergo@gmail.com> wrote:
The charger is only able to deliver 3 KW to the battery, so the car will maximum use 13A from the grid. I therefor hardcoded the charging to "STANDARD 13A"
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
I think my hardware may have a dodgy connection as it is working again!
I am using the hex file Thomas sent (one that failed yesterday!)
I noticed that the charge level is reported wrongly. I am using a 16A charger (and the car does charge at > 13A) yet the C-Zero code is reporting the charge type as "STANDARD 13A" and the charge current is showing as 12A.
Matt
On 24 September 2013 19:22, Thomas Bergo <thomas.bergo@gmail.com> wrote:
I read some rumors that some cars imported from Denmark to Norway had a smaller battery pack. Have to look some more to find where i read about this.
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
You can tell how many cells from the 6en messages, but I heard that the range is the same, but the unused capacity is less so the batteries don't last as well.
This needs to be confirmed.
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
There is delivered some Citroen C-Zero with a smaller battery pack (13 KWh VS 16 KWh.) The ideal range for the 13 KWh battery I believe is 80 miles and for the 16 KWh battery the ideal range is 150km (93 miles).
To calculate the ideal range correctly for both battery size we need a way to distinguish between them.
Do you think that there will be any issues by using the Feature 14, Car bits, to indicate which battery pack the car has?
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
I'm using a Global SIM.
I may try the diag port if I can find something that reads RS-232 in this day and age! I must try and get a USB adapter.
Matt
On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote:
Great. In addition, you might want to try and attach something to the diagnostics port. You should be able to read through the port any AT commands, to make sure it's working correctly.
I believe there's a list somewhere of the messages you'll get from the diagnostic port for that chip.. 901 is it? (I can't remember, but it's what we used to diagnose the SIM card was at fault.)
Nikki.
P.S. What SIM are you using? Global? O2?
On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote:
Actually, running it with stock firmware as OBDII in our ICE is next on my list of checks.
Matt
On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote:
The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide?
Nikki.
On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt,
I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com>wrote:
Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv>
Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote:
Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
_______________________________________________ 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 don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging. This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS. [image: Innebygd bilde 1] Regards, Thomas 2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output current?
I notice that the Volt/Ampera code sets 16A as the charge limit.
Matt
On 24 September 2013 19:58, Thomas Bergo <thomas.bergo@gmail.com> wrote:
The charger is only able to deliver 3 KW to the battery, so the car will maximum use 13A from the grid. I therefor hardcoded the charging to "STANDARD 13A"
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
I think my hardware may have a dodgy connection as it is working again!
I am using the hex file Thomas sent (one that failed yesterday!)
I noticed that the charge level is reported wrongly. I am using a 16A charger (and the car does charge at > 13A) yet the C-Zero code is reporting the charge type as "STANDARD 13A" and the charge current is showing as 12A.
Matt
On 24 September 2013 19:22, Thomas Bergo <thomas.bergo@gmail.com> wrote:
I read some rumors that some cars imported from Denmark to Norway had a smaller battery pack. Have to look some more to find where i read about this.
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
You can tell how many cells from the 6en messages, but I heard that the range is the same, but the unused capacity is less so the batteries don't last as well.
This needs to be confirmed.
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
There is delivered some Citroen C-Zero with a smaller battery pack (13 KWh VS 16 KWh.) The ideal range for the 13 KWh battery I believe is 80 miles and for the 16 KWh battery the ideal range is 150km (93 miles).
To calculate the ideal range correctly for both battery size we need a way to distinguish between them.
Do you think that there will be any issues by using the Feature 14, Car bits, to indicate which battery pack the car has?
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
I'm using a Global SIM.
I may try the diag port if I can find something that reads RS-232 in this day and age! I must try and get a USB adapter.
Matt
On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote:
Great. In addition, you might want to try and attach something to the diagnostics port. You should be able to read through the port any AT commands, to make sure it's working correctly.
I believe there's a list somewhere of the messages you'll get from the diagnostic port for that chip.. 901 is it? (I can't remember, but it's what we used to diagnose the SIM card was at fault.)
Nikki.
P.S. What SIM are you using? Global? O2?
On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote:
Actually, running it with stock firmware as OBDII in our ICE is next on my list of checks.
Matt
On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote:
The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide?
Nikki.
On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt,
I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com>wrote:
Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv>
Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote:
Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
_______________________________________________ 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
Yeah - it's just info for the app user, but I would rather it is a) reasonably accurate and b) consistent across all vehicles. Matt On 24 September 2013 21:23, Thomas Bergo <thomas.bergo@gmail.com> wrote:
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output current?
I notice that the Volt/Ampera code sets 16A as the charge limit.
Matt
On 24 September 2013 19:58, Thomas Bergo <thomas.bergo@gmail.com> wrote:
The charger is only able to deliver 3 KW to the battery, so the car will maximum use 13A from the grid. I therefor hardcoded the charging to "STANDARD 13A"
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
I think my hardware may have a dodgy connection as it is working again!
I am using the hex file Thomas sent (one that failed yesterday!)
I noticed that the charge level is reported wrongly. I am using a 16A charger (and the car does charge at > 13A) yet the C-Zero code is reporting the charge type as "STANDARD 13A" and the charge current is showing as 12A.
Matt
On 24 September 2013 19:22, Thomas Bergo <thomas.bergo@gmail.com>wrote:
I read some rumors that some cars imported from Denmark to Norway had a smaller battery pack. Have to look some more to find where i read about this.
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
You can tell how many cells from the 6en messages, but I heard that the range is the same, but the unused capacity is less so the batteries don't last as well.
This needs to be confirmed.
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
> There is delivered some Citroen C-Zero with a smaller battery pack > (13 KWh VS 16 KWh.) The ideal range for the 13 KWh battery I believe is 80 > miles and for the 16 KWh battery the ideal range is 150km (93 miles). > > To calculate the ideal range correctly for both battery size we need > a way to distinguish between them. > > Do you think that there will be any issues by using the Feature 14, > Car bits, to indicate which battery pack the car has? > > Regards, Thomas > > > 2013/9/24 Matt Beard <matt@beard.tv> > > I'm using a Global SIM. > > I may try the diag port if I can find something that reads RS-232 in > this day and age! I must try and get a USB adapter. > > Matt > > > On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote: > > Great. In addition, you might want to try and attach something to > the diagnostics port. You should be able to read through the port any AT > commands, to make sure it's working correctly. > > I believe there's a list somewhere of the messages you'll get from > the diagnostic port for that chip.. 901 is it? (I can't remember, but it's > what we used to diagnose the SIM card was at fault.) > > Nikki. > > P.S. What SIM are you using? Global? O2? > > > On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote: > > Actually, running it with stock firmware as OBDII in our ICE is next > on my list of checks. > > Matt > > > On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote: > > The other suggestion I would have is to plug the ODBII module into > another car -- or power it from a bench supply using the method detailed in > the development guide? > > Nikki. > > On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> > wrote: > > Matt, > > I have modules with me for replacement, if necessary. > > I am concerned about your comments regarding soldering. All the v2 > modules are supposed to be machine soldered, and we have had almost zero > returns of broken modules.I would be grateful if you could let me know the > serial number of your module, the approximate date you received it, and if > possible a picture of the soldering issues. > > I too am perplexed why the module would work SMS but not GPRS. > Perhaps you can try setting the vehicle type to 'XX', which would eliminate > any can bus/message issues, and see if the problem still occurs. > > Please eMail me, off list, as mark (at) openvehicles (dot) com, and > I'll work through this with you. > > Regards, Mark. > > On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> > wrote: > > Thanks Thomas, > > That has confirmed for me that my hardware has died. > > Looking at the circuit board the soldering on the GSM modem is > shocking, but I don't understand how it can work for SMS, but crash with > GPRS. Looks like I will be spending most of my effort in the coming days > trying to get the hardware replaced! > > I have confirmed that the unit functions perfectly (though is pretty > useless) with the GPRS switch set to disabled. If it is booted with the > switch enabled it dies as soon as I set the GPRS parameters, then enters an > endless reboot loop. > > Matt > > > > > > On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com>wrote: > > Attached is the hex file, this is the exact same that is running om > my module now. > > Regards, Thomas > > > 2013/9/23 Matt Beard <matt@beard.tv> > > Thomas, > > That would be really useful. I am worried that the module may have > failed. > > I did not keep a copy of the last working hex file (lesson learned!) > but did save the sources. Rebuilt from previous sources and loaded. It > still fails. > > Matt > > > > On Monday, September 23, 2013, Thomas Bergo wrote: > > Matt: > > I can send you the hex file i'm running in my OVMS module, so you > can try if that woking in your module? > > _______________________________________________ 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
Nice work Thomas, Your attached image reminds me that I should implement the car_time and car_parktime in the Think City module :-) Regards to max charge rate "STANDARD xxA": The variable car_chargelimit should contain the maximum available mains current, which is set by the EVSE. This is done in vehicle_thinkcity.c and I assume this can-message is available in a iMiEV and could replace the hardcoded "13A". The evse sends a pilot signal controlling the charger max rate, which can be adjusted by the user in steps depending on the evse type. The first evse's for iMiEV was delivered with two charging steps (maybe 10-16A) and got popular among Leaf-owners. Running up to 16A over the Schuko-connector is bad firesafety, so the later evse's were replaced with 13A. (I guess) limit max. This one is a nice one(mode 2, type 2 delivered with different charging connectors: http://salto.no/produkter/ladekabel-justerbar-13-a-type-2-shuko/ When the max charge current is set by the evse, e.g. 13A the ac-charge current (which can be measured or viewed in a can-message) will never exceed this limit. Br. Håkon 2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output current?
I notice that the Volt/Ampera code sets 16A as the charge limit.
Matt
On 24 September 2013 19:58, Thomas Bergo <thomas.bergo@gmail.com> wrote:
The charger is only able to deliver 3 KW to the battery, so the car will maximum use 13A from the grid. I therefor hardcoded the charging to "STANDARD 13A"
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
I think my hardware may have a dodgy connection as it is working again!
I am using the hex file Thomas sent (one that failed yesterday!)
I noticed that the charge level is reported wrongly. I am using a 16A charger (and the car does charge at > 13A) yet the C-Zero code is reporting the charge type as "STANDARD 13A" and the charge current is showing as 12A.
Matt
On 24 September 2013 19:22, Thomas Bergo <thomas.bergo@gmail.com>wrote:
I read some rumors that some cars imported from Denmark to Norway had a smaller battery pack. Have to look some more to find where i read about this.
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
You can tell how many cells from the 6en messages, but I heard that the range is the same, but the unused capacity is less so the batteries don't last as well.
This needs to be confirmed.
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
> There is delivered some Citroen C-Zero with a smaller battery pack > (13 KWh VS 16 KWh.) The ideal range for the 13 KWh battery I believe is 80 > miles and for the 16 KWh battery the ideal range is 150km (93 miles). > > To calculate the ideal range correctly for both battery size we need > a way to distinguish between them. > > Do you think that there will be any issues by using the Feature 14, > Car bits, to indicate which battery pack the car has? > > Regards, Thomas > > > 2013/9/24 Matt Beard <matt@beard.tv> > > I'm using a Global SIM. > > I may try the diag port if I can find something that reads RS-232 in > this day and age! I must try and get a USB adapter. > > Matt > > > On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote: > > Great. In addition, you might want to try and attach something to > the diagnostics port. You should be able to read through the port any AT > commands, to make sure it's working correctly. > > I believe there's a list somewhere of the messages you'll get from > the diagnostic port for that chip.. 901 is it? (I can't remember, but it's > what we used to diagnose the SIM card was at fault.) > > Nikki. > > P.S. What SIM are you using? Global? O2? > > > On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote: > > Actually, running it with stock firmware as OBDII in our ICE is next > on my list of checks. > > Matt > > > On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote: > > The other suggestion I would have is to plug the ODBII module into > another car -- or power it from a bench supply using the method detailed in > the development guide? > > Nikki. > > On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> > wrote: > > Matt, > > I have modules with me for replacement, if necessary. > > I am concerned about your comments regarding soldering. All the v2 > modules are supposed to be machine soldered, and we have had almost zero > returns of broken modules.I would be grateful if you could let me know the > serial number of your module, the approximate date you received it, and if > possible a picture of the soldering issues. > > I too am perplexed why the module would work SMS but not GPRS. > Perhaps you can try setting the vehicle type to 'XX', which would eliminate > any can bus/message issues, and see if the problem still occurs. > > Please eMail me, off list, as mark (at) openvehicles (dot) com, and > I'll work through this with you. > > Regards, Mark. > > On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> > wrote: > > Thanks Thomas, > > That has confirmed for me that my hardware has died. > > Looking at the circuit board the soldering on the GSM modem is > shocking, but I don't understand how it can work for SMS, but crash with > GPRS. Looks like I will be spending most of my effort in the coming days > trying to get the hardware replaced! > > I have confirmed that the unit functions perfectly (though is pretty > useless) with the GPRS switch set to disabled. If it is booted with the > switch enabled it dies as soon as I set the GPRS parameters, then enters an > endless reboot loop. > > Matt > > > > > > On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com>wrote: > > Attached is the hex file, this is the exact same that is running om > my module now. > > Regards, Thomas > > > 2013/9/23 Matt Beard <matt@beard.tv> > > Thomas, > > That would be really useful. I am worried that the module may have > failed. > > I did not keep a copy of the last working hex file (lesson learned!) > but did save the sources. Rebuilt from previous sources and loaded. It > still fails. > > Matt > > > > On Monday, September 23, 2013, Thomas Bergo wrote: > > Matt: > > I can send you the hex file i'm running in my OVMS module, so you > can try if that woking in your module? > > _______________________________________________ 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
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A. I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A. The can message for current limit set by EVSE is not know for the i-Miev, so until this information is available we need to hardcode a value to be displayed in "STANDARD xxA" in the app. Regards, Thomas 2013/9/24 Håkon Markussen <hakon.markussen@gmail.com>
Nice work Thomas,
Your attached image reminds me that I should implement the car_time and car_parktime in the Think City module :-)
Regards to max charge rate "STANDARD xxA": The variable car_chargelimit should contain the maximum available mains current, which is set by the EVSE. This is done in vehicle_thinkcity.c and I assume this can-message is available in a iMiEV and could replace the hardcoded "13A".
The evse sends a pilot signal controlling the charger max rate, which can be adjusted by the user in steps depending on the evse type. The first evse's for iMiEV was delivered with two charging steps (maybe 10-16A) and got popular among Leaf-owners. Running up to 16A over the Schuko-connector is bad firesafety, so the later evse's were replaced with 13A. (I guess) limit max. This one is a nice one(mode 2, type 2 delivered with different charging connectors: http://salto.no/produkter/ladekabel-justerbar-13-a-type-2-shuko/
When the max charge current is set by the evse, e.g. 13A the ac-charge current (which can be measured or viewed in a can-message) will never exceed this limit.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output current?
I notice that the Volt/Ampera code sets 16A as the charge limit.
Matt
On 24 September 2013 19:58, Thomas Bergo <thomas.bergo@gmail.com> wrote:
The charger is only able to deliver 3 KW to the battery, so the car will maximum use 13A from the grid. I therefor hardcoded the charging to "STANDARD 13A"
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
I think my hardware may have a dodgy connection as it is working again!
I am using the hex file Thomas sent (one that failed yesterday!)
I noticed that the charge level is reported wrongly. I am using a 16A charger (and the car does charge at > 13A) yet the C-Zero code is reporting the charge type as "STANDARD 13A" and the charge current is showing as 12A.
Matt
On 24 September 2013 19:22, Thomas Bergo <thomas.bergo@gmail.com>wrote:
I read some rumors that some cars imported from Denmark to Norway had a smaller battery pack. Have to look some more to find where i read about this.
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
> You can tell how many cells from the 6en messages, but I heard that > the range is the same, but the unused capacity is less so the batteries > don't last as well. > > This needs to be confirmed. > > Matt > > > On Tuesday, September 24, 2013, Thomas Bergo wrote: > >> There is delivered some Citroen C-Zero with a smaller battery pack >> (13 KWh VS 16 KWh.) The ideal range for the 13 KWh battery I believe is 80 >> miles and for the 16 KWh battery the ideal range is 150km (93 miles). >> >> To calculate the ideal range correctly for both battery size we >> need a way to distinguish between them. >> >> Do you think that there will be any issues by using the Feature 14, >> Car bits, to indicate which battery pack the car has? >> >> Regards, Thomas >> >> >> 2013/9/24 Matt Beard <matt@beard.tv> >> >> I'm using a Global SIM. >> >> I may try the diag port if I can find something that reads RS-232 >> in this day and age! I must try and get a USB adapter. >> >> Matt >> >> >> On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote: >> >> Great. In addition, you might want to try and attach something to >> the diagnostics port. You should be able to read through the port any AT >> commands, to make sure it's working correctly. >> >> I believe there's a list somewhere of the messages you'll get from >> the diagnostic port for that chip.. 901 is it? (I can't remember, but it's >> what we used to diagnose the SIM card was at fault.) >> >> Nikki. >> >> P.S. What SIM are you using? Global? O2? >> >> >> On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote: >> >> Actually, running it with stock firmware as OBDII in our ICE is >> next on my list of checks. >> >> Matt >> >> >> On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote: >> >> The other suggestion I would have is to plug the ODBII module into >> another car -- or power it from a bench supply using the method detailed in >> the development guide? >> >> Nikki. >> >> On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> >> wrote: >> >> Matt, >> >> I have modules with me for replacement, if necessary. >> >> I am concerned about your comments regarding soldering. All the v2 >> modules are supposed to be machine soldered, and we have had almost zero >> returns of broken modules.I would be grateful if you could let me know the >> serial number of your module, the approximate date you received it, and if >> possible a picture of the soldering issues. >> >> I too am perplexed why the module would work SMS but not GPRS. >> Perhaps you can try setting the vehicle type to 'XX', which would eliminate >> any can bus/message issues, and see if the problem still occurs. >> >> Please eMail me, off list, as mark (at) openvehicles (dot) com, and >> I'll work through this with you. >> >> Regards, Mark. >> >> On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> >> wrote: >> >> Thanks Thomas, >> >> That has confirmed for me that my hardware has died. >> >> Looking at the circuit board the soldering on the GSM modem is >> shocking, but I don't understand how it can work for SMS, but crash with >> GPRS. Looks like I will be spending most of my effort in the coming days >> trying to get the hardware replaced! >> >> I have confirmed that the unit functions perfectly (though is >> pretty useless) with the GPRS switch set to disabled. If it is booted with >> the switch enabled it dies as soon as I set the GPRS parameters, then >> enters an endless reboot loop. >> >> Matt >> >> >> >> >> >> On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com>wrote: >> >> Attached is the hex file, this is the exact same that is running om >> my module now. >> >> Regards, Thomas >> >> >> 2013/9/23 Matt Beard <matt@beard.tv> >> >> Thomas, >> >> That would be really useful. I am worried that the module may have >> failed. >> >> I did not keep a copy of the last working hex file (lesson >> learned!) but did save the sources. Rebuilt from previous sources and >> loaded. It still fails. >> >> Matt >> >> >> >> On Monday, September 23, 2013, Thomas Bergo wrote: >> >> Matt: >> >> I can send you the hex file i'm running in my OVMS module, so you >> can try if that woking in your module? >> >> > _______________________________________________ > 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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
More strange behaviour with my C-Zero. Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again? Matt On Tuesday, September 24, 2013, Thomas Bergo wrote:
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A.
The can message for current limit set by EVSE is not know for the i-Miev, so until this information is available we need to hardcode a value to be displayed in "STANDARD xxA" in the app.
Regards, Thomas
2013/9/24 Håkon Markussen <hakon.markussen@gmail.com>
Nice work Thomas,
Your attached image reminds me that I should implement the car_time and car_parktime in the Think City module :-)
Regards to max charge rate "STANDARD xxA": The variable car_chargelimit should contain the maximum available mains current, which is set by the EVSE. This is done in vehicle_thinkcity.c and I assume this can-message is available in a iMiEV and could replace the hardcoded "13A".
The evse sends a pilot signal controlling the charger max rate, which can be adjusted by the user in steps depending on the evse type. The first evse's for iMiEV was delivered with two charging steps (maybe 10-16A) and got popular among Leaf-owners. Running up to 16A over the Schuko-connector is bad firesafety, so the later evse's were replaced with 13A. (I guess) limit max. This one is a nice one(mode 2, type 2 delivered with different charging connectors: http://salto.no/produkter/ladekabel-justerbar-13-a-type-2-shuko/
When the max charge current is set by the evse, e.g. 13A the ac-charge current (which can be measured or viewed in a can-message) will never exceed this limit.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output current?
I notice that the Volt/Ampera code sets 16A as the charge limit.
Matt
On 24 September 2013 19:58, Thomas Bergo <thomas.bergo@gmail.com> wrote:
The charger is only able to deliver 3 KW to the battery, so the car will maximum use 13A from the grid. I therefor hardcoded the charging to "STANDARD 13A"
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
I think my hardware may have a dodgy connection as it is working again!
I am using the hex file Thomas sent (one that failed yesterday!)
I noticed that the charge level is reported wrongly. I am using a 16A charger (and the car does charge at > 13A) yet the C-Zero code is reporting the
Was the SOC approximately 70% ? The Car takes a pause and stops charging for some time at 70%. I belive this is to level the charge state of the cells. After some time the charging will continue. Regards, Thomas tirsdag 24. september 2013 skrev Matt Beard følgende:
More strange behaviour with my C-Zero.
Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again?
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A.
The can message for current limit set by EVSE is not know for the i-Miev, so until this information is available we need to hardcode a value to be displayed in "STANDARD xxA" in the app.
Regards, Thomas
2013/9/24 Håkon Markussen <hakon.markussen@gmail.com>
Nice work Thomas,
Your attached image reminds me that I should implement the car_time and car_parktime in the Think City module :-)
Regards to max charge rate "STANDARD xxA": The variable car_chargelimit should contain the maximum available mains current, which is set by the EVSE. This is done in vehicle_thinkcity.c and I assume this can-message is available in a iMiEV and could replace the hardcoded "13A".
The evse sends a pilot signal controlling the charger max rate, which can be adjusted by the user in steps depending on the evse type. The first evse's for iMiEV was delivered with two charging steps (maybe 10-16A) and got popular among Leaf-owners. Running up to 16A over the Schuko-connector is bad firesafety, so the later evse's were replaced with 13A. (I guess) limit max. This one is a nice one(mode 2, type 2 delivered with different charging connectors: http://salto.no/produkter/ladekabel-justerbar-13-a-type-2-shuko/
When the max charge current is set by the evse, e.g. 13A the ac-charge current (which can be measured or viewed in a can-message) will never exceed this limit.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output current?
I notice that the Volt/Ampera code sets 16A as the charge limit.
Matt
On 24 September 2013 19:58, Thomas Bergo <thomas.bergo@gmail.com> wrote:
The charger is only able to deliver 3 KW to the battery, so the car will maximum use 13A from the grid. I therefor hardcoded the charging to "STANDARD 13A"
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
I think my hardware may have a dodgy connection as it is working again!
I am using the hex file Thomas sent (one that failed yesterday!)
I noticed that the charge level is reported wrongly. I am using a 16A charger (and the car does charge at > 13A) yet the C-Zero code is reporting
The SOC was about 25% Matt On Tuesday, 24 September 2013, Thomas Bergo wrote:
Was the SOC approximately 70% ?
The Car takes a pause and stops charging for some time at 70%. I belive this is to level the charge state of the cells. After some time the charging will continue.
Regards, Thomas
tirsdag 24. september 2013 skrev Matt Beard følgende:
More strange behaviour with my C-Zero.
Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again?
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A.
The can message for current limit set by EVSE is not know for the i-Miev, so until this information is available we need to hardcode a value to be displayed in "STANDARD xxA" in the app.
Regards, Thomas
2013/9/24 Håkon Markussen <hakon.markussen@gmail.com>
Nice work Thomas,
Your attached image reminds me that I should implement the car_time and car_parktime in the Think City module :-)
Regards to max charge rate "STANDARD xxA": The variable car_chargelimit should contain the maximum available mains current, which is set by the EVSE. This is done in vehicle_thinkcity.c and I assume this can-message is available in a iMiEV and could replace the hardcoded "13A".
The evse sends a pilot signal controlling the charger max rate, which can be adjusted by the user in steps depending on the evse type. The first evse's for iMiEV was delivered with two charging steps (maybe 10-16A) and got popular among Leaf-owners. Running up to 16A over the Schuko-connector is bad firesafety, so the later evse's were replaced with 13A. (I guess) limit max. This one is a nice one(mode 2, type 2 delivered with different charging connectors: http://salto.no/produkter/ladekabel-justerbar-13-a-type-2-shuko/
When the max charge current is set by the evse, e.g. 13A the ac-charge current (which can be measured or viewed in a can-message) will never exceed this limit.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output current?
I notice that the Volt/Ampera code sets 16A as the charge limit.
Matt
On 24 September 2013 19:58, Thomas Bergo <thomas.bergo@gmail.com> wrote:
The charger is only
It could be that the car do some leveling of the cells at this levels and at 70%? Just noticed my car was reporting 0A at 71% just before your email. Now it has started to charge at 13A. :-) Regards, Thomas onsdag 25. september 2013 skrev Matt Beard følgende:
The SOC was about 25%
Matt
On Tuesday, 24 September 2013, Thomas Bergo wrote:
Was the SOC approximately 70% ?
The Car takes a pause and stops charging for some time at 70%. I belive this is to level the charge state of the cells. After some time the charging will continue.
Regards, Thomas
tirsdag 24. september 2013 skrev Matt Beard følgende:
More strange behaviour with my C-Zero.
Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again?
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A.
The can message for current limit set by EVSE is not know for the i-Miev, so until this information is available we need to hardcode a value to be displayed in "STANDARD xxA" in the app.
Regards, Thomas
2013/9/24 Håkon Markussen <hakon.markussen@gmail.com>
Nice work Thomas,
Your attached image reminds me that I should implement the car_time and car_parktime in the Think City module :-)
Regards to max charge rate "STANDARD xxA": The variable car_chargelimit should contain the maximum available mains current, which is set by the EVSE. This is done in vehicle_thinkcity.c and I assume this can-message is available in a iMiEV and could replace the hardcoded "13A".
The evse sends a pilot signal controlling the charger max rate, which can be adjusted by the user in steps depending on the evse type. The first evse's for iMiEV was delivered with two charging steps (maybe 10-16A) and got popular among Leaf-owners. Running up to 16A over the Schuko-connector is bad firesafety, so the later evse's were replaced with 13A. (I guess) limit max. This one is a nice one(mode 2, type 2 delivered with different charging connectors: http://salto.no/produkter/ladekabel-justerbar-13-a-type-2-shuko/
When the max charge current is set by the evse, e.g. 13A the ac-charge current (which can be measured or viewed in a can-message) will never exceed this limit.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output curre
How did the rest of the charging go? Any other hick ups? Regards,Thomas onsdag 25. september 2013 skrev Matt Beard følgende:
The SOC was about 25%
Matt
On Tuesday, 24 September 2013, Thomas Bergo wrote:
Was the SOC approximately 70% ?
The Car takes a pause and stops charging for some time at 70%. I belive this is to level the charge state of the cells. After some time the charging will continue.
Regards, Thomas
tirsdag 24. september 2013 skrev Matt Beard følgende:
More strange behaviour with my C-Zero.
Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again?
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A.
The can message for current limit set by EVSE is not know for the i-Miev, so until this information is available we need to hardcode a value to be displayed in "STANDARD xxA" in the app.
Regards, Thomas
2013/9/24 Håkon Markussen <hakon.markussen@gmail.com>
Nice work Thomas,
Your attached image reminds me that I should implement the car_time and car_parktime in the Think City module :-)
Regards to max charge rate "STANDARD xxA": The variable car_chargelimit should contain the maximum available mains current, which is set by the EVSE. This is done in vehicle_thinkcity.c and I assume this can-message is available in a iMiEV and could replace the hardcoded "13A".
The evse sends a pilot signal controlling the charger max rate, which can be adjusted by the user in steps depending on the evse type. The first evse's for iMiEV was delivered with two charging steps (maybe 10-16A) and got popular among Leaf-owners. Running up to 16A over the Schuko-connector is bad firesafety, so the later evse's were replaced with 13A. (I guess) limit max. This one is a nice one(mode 2, type 2 delivered with different charging connectors: http://salto.no/produkter/ladekabel-justerbar-13-a-type-2-shuko/
When the max charge current is set by the evse, e.g. 13A the ac-charge current (which can be measured or viewed in a can-message) will never exceed this limit.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output curre
Having disconnected OVMS and power-cycled the car the charge seemed to be going OK, so I connected the unit back up and let it go the last 50% or so with OVMS and it was still fine. So, looks like something set a bad value! Maybe there is a "set max % charge" CAN message and it got set due to noise on the bus. Wish I knew what it was! Matt On 25 September 2013 14:35, Thomas Bergo <thomas.bergo@gmail.com> wrote:
How did the rest of the charging go? Any other hick ups?
Regards,Thomas
onsdag 25. september 2013 skrev Matt Beard følgende:
The SOC was about 25%
Matt
On Tuesday, 24 September 2013, Thomas Bergo wrote:
Was the SOC approximately 70% ?
The Car takes a pause and stops charging for some time at 70%. I belive this is to level the charge state of the cells. After some time the charging will continue.
Regards, Thomas
tirsdag 24. september 2013 skrev Matt Beard følgende:
More strange behaviour with my C-Zero.
Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again?
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A.
The can message for current limit set by EVSE is not know for the i-Miev, so until this information is available we need to hardcode a value to be displayed in "STANDARD xxA" in the app.
Regards, Thomas
2013/9/24 Håkon Markussen <hakon.markussen@gmail.com>
Nice work Thomas,
Your attached image reminds me that I should implement the car_time and car_parktime in the Think City module :-)
Regards to max charge rate "STANDARD xxA": The variable car_chargelimit should contain the maximum available mains current, which is set by the EVSE. This is done in vehicle_thinkcity.c and I assume this can-message is available in a iMiEV and could replace the hardcoded "13A".
The evse sends a pilot signal controlling the charger max rate, which can be adjusted by the user in steps depending on the evse type. The first evse's for iMiEV was delivered with two charging steps (maybe 10-16A) and got popular among Leaf-owners. Running up to 16A over the Schuko-connector is bad firesafety, so the later evse's were replaced with 13A. (I guess) limit max. This one is a nice one(mode 2, type 2 delivered with different charging connectors: http://salto.no/produkter/ladekabel-justerbar-13-a-type-2-shuko/
When the max charge current is set by the evse, e.g. 13A the ac-charge current (which can be measured or viewed in a can-message) will never exceed this limit.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output curre
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Matt: Do you get the ODO in the "STAT?" SMS message? I did until two days ago, did a cleanup of the code before push to GitHub. After that i haven't got ODO. Can't see any changes to the code from the previous version ether. Regards, Thomas 2013/9/25 Matt Beard OVMS <smvo@mxf.org.uk>
Having disconnected OVMS and power-cycled the car the charge seemed to be going OK, so I connected the unit back up and let it go the last 50% or so with OVMS and it was still fine. So, looks like something set a bad value! Maybe there is a "set max % charge" CAN message and it got set due to noise on the bus. Wish I knew what it was!
Matt
On 25 September 2013 14:35, Thomas Bergo <thomas.bergo@gmail.com> wrote:
How did the rest of the charging go? Any other hick ups?
Regards,Thomas
onsdag 25. september 2013 skrev Matt Beard følgende:
The SOC was about 25%
Matt
On Tuesday, 24 September 2013, Thomas Bergo wrote:
Was the SOC approximately 70% ?
The Car takes a pause and stops charging for some time at 70%. I belive this is to level the charge state of the cells. After some time the charging will continue.
Regards, Thomas
tirsdag 24. september 2013 skrev Matt Beard følgende:
More strange behaviour with my C-Zero.
Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again?
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A.
The can message for current limit set by EVSE is not know for the i-Miev, so until this information is available we need to hardcode a value to be displayed in "STANDARD xxA" in the app.
Regards, Thomas
2013/9/24 Håkon Markussen <hakon.markussen@gmail.com>
Nice work Thomas,
Your attached image reminds me that I should implement the car_time and car_parktime in the Think City module :-)
Regards to max charge rate "STANDARD xxA": The variable car_chargelimit should contain the maximum available mains current, which is set by the EVSE. This is done in vehicle_thinkcity.c and I assume this can-message is available in a iMiEV and could replace the hardcoded "13A".
The evse sends a pilot signal controlling the charger max rate, which can be adjusted by the user in steps depending on the evse type. The first evse's for iMiEV was delivered with two charging steps (maybe 10-16A) and got popular among Leaf-owners. Running up to 16A over the Schuko-connector is bad firesafety, so the later evse's were replaced with 13A. (I guess) limit max. This one is a nice one(mode 2, type 2 delivered with different charging connectors: http://salto.no/produkter/ladekabel-justerbar-13-a-type-2-shuko/
When the max charge current is set by the evse, e.g. 13A the ac-charge current (which can be measured or viewed in a can-message) will never exceed this limit.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output curre
_______________________________________________ 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
My STAT? gives: Not charging SOC: 100% Ideal Range: 93 mi Est. Range 68 mi On 26 September 2013 10:02, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Matt: Do you get the ODO in the "STAT?" SMS message? I did until two days ago, did a cleanup of the code before push to GitHub. After that i haven't got ODO. Can't see any changes to the code from the previous version ether.
Regards, Thomas
2013/9/25 Matt Beard OVMS <smvo@mxf.org.uk>
Having disconnected OVMS and power-cycled the car the charge seemed to be going OK, so I connected the unit back up and let it go the last 50% or so with OVMS and it was still fine. So, looks like something set a bad value! Maybe there is a "set max % charge" CAN message and it got set due to noise on the bus. Wish I knew what it was!
Matt
On 25 September 2013 14:35, Thomas Bergo <thomas.bergo@gmail.com> wrote:
How did the rest of the charging go? Any other hick ups?
Regards,Thomas
onsdag 25. september 2013 skrev Matt Beard følgende:
The SOC was about 25%
Matt
On Tuesday, 24 September 2013, Thomas Bergo wrote:
Was the SOC approximately 70% ?
The Car takes a pause and stops charging for some time at 70%. I belive this is to level the charge state of the cells. After some time the charging will continue.
Regards, Thomas
tirsdag 24. september 2013 skrev Matt Beard følgende:
More strange behaviour with my C-Zero.
Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again?
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A.
The can message for current limit set by EVSE is not know for the i-Miev, so until this information is available we need to hardcode a value to be displayed in "STANDARD xxA" in the app.
Regards, Thomas
2013/9/24 Håkon Markussen <hakon.markussen@gmail.com>
Nice work Thomas,
Your attached image reminds me that I should implement the car_time and car_parktime in the Think City module :-)
Regards to max charge rate "STANDARD xxA": The variable car_chargelimit should contain the maximum available mains current, which is set by the EVSE. This is done in vehicle_thinkcity.c and I assume this can-message is available in a iMiEV and could replace the hardcoded "13A".
The evse sends a pilot signal controlling the charger max rate, which can be adjusted by the user in steps depending on the evse type. The first evse's for iMiEV was delivered with two charging steps (maybe 10-16A) and got popular among Leaf-owners. Running up to 16A over the Schuko-connector is bad firesafety, so the later evse's were replaced with 13A. (I guess) limit max. This one is a nice one(mode 2, type 2 delivered with different charging connectors: http://salto.no/produkter/ladekabel-justerbar-13-a-type-2-shuko/
When the max charge current is set by the evse, e.g. 13A the ac-charge current (which can be measured or viewed in a can-message) will never exceed this limit.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output curre
_______________________________________________ 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
Ok, then you have the same issue. Will look into this later. Regards, Thomas 2013/9/26 Matt Beard OVMS <smvo@mxf.org.uk>
My STAT? gives:
Not charging SOC: 100% Ideal Range: 93 mi Est. Range 68 mi
On 26 September 2013 10:02, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Matt: Do you get the ODO in the "STAT?" SMS message? I did until two days ago, did a cleanup of the code before push to GitHub. After that i haven't got ODO. Can't see any changes to the code from the previous version ether.
Regards, Thomas
2013/9/25 Matt Beard OVMS <smvo@mxf.org.uk>
Having disconnected OVMS and power-cycled the car the charge seemed to be going OK, so I connected the unit back up and let it go the last 50% or so with OVMS and it was still fine. So, looks like something set a bad value! Maybe there is a "set max % charge" CAN message and it got set due to noise on the bus. Wish I knew what it was!
Matt
On 25 September 2013 14:35, Thomas Bergo <thomas.bergo@gmail.com> wrote:
How did the rest of the charging go? Any other hick ups?
Regards,Thomas
onsdag 25. september 2013 skrev Matt Beard følgende:
The SOC was about 25%
Matt
On Tuesday, 24 September 2013, Thomas Bergo wrote:
Was the SOC approximately 70% ?
The Car takes a pause and stops charging for some time at 70%. I belive this is to level the charge state of the cells. After some time the charging will continue.
Regards, Thomas
tirsdag 24. september 2013 skrev Matt Beard følgende:
More strange behaviour with my C-Zero.
Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again?
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A.
The can message for current limit set by EVSE is not know for the i-Miev, so until this information is available we need to hardcode a value to be displayed in "STANDARD xxA" in the app.
Regards, Thomas
2013/9/24 Håkon Markussen <hakon.markussen@gmail.com>
Nice work Thomas,
Your attached image reminds me that I should implement the car_time and car_parktime in the Think City module :-)
Regards to max charge rate "STANDARD xxA": The variable car_chargelimit should contain the maximum available mains current, which is set by the EVSE. This is done in vehicle_thinkcity.c and I assume this can-message is available in a iMiEV and could replace the hardcoded "13A".
The evse sends a pilot signal controlling the charger max rate, which can be adjusted by the user in steps depending on the evse type. The first evse's for iMiEV was delivered with two charging steps (maybe 10-16A) and got popular among Leaf-owners. Running up to 16A over the Schuko-connector is bad firesafety, so the later evse's were replaced with 13A. (I guess) limit max. This one is a nice one(mode 2, type 2 delivered with different charging connectors: http://salto.no/produkter/ladekabel-justerbar-13-a-type-2-shuko/
When the max charge current is set by the evse, e.g. 13A the ac-charge current (which can be measured or viewed in a can-message) will never exceed this limit.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output curre
_______________________________________________ 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
Has anyone seen a CAN log from a rapid charge? Is the OBD port active at all during rapid charge? I found nothing gets reported during RC. Matt On 26 September 2013 10:29, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Ok, then you have the same issue.
Will look into this later.
Regards, Thomas
2013/9/26 Matt Beard OVMS <smvo@mxf.org.uk>
My STAT? gives:
Not charging SOC: 100% Ideal Range: 93 mi Est. Range 68 mi
On 26 September 2013 10:02, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Matt: Do you get the ODO in the "STAT?" SMS message? I did until two days ago, did a cleanup of the code before push to GitHub. After that i haven't got ODO. Can't see any changes to the code from the previous version ether.
Regards, Thomas
2013/9/25 Matt Beard OVMS <smvo@mxf.org.uk>
Having disconnected OVMS and power-cycled the car the charge seemed to be going OK, so I connected the unit back up and let it go the last 50% or so with OVMS and it was still fine. So, looks like something set a bad value! Maybe there is a "set max % charge" CAN message and it got set due to noise on the bus. Wish I knew what it was!
Matt
On 25 September 2013 14:35, Thomas Bergo <thomas.bergo@gmail.com>wrote:
How did the rest of the charging go? Any other hick ups?
Regards,Thomas
onsdag 25. september 2013 skrev Matt Beard følgende:
The SOC was about 25%
Matt
On Tuesday, 24 September 2013, Thomas Bergo wrote:
Was the SOC approximately 70% ?
The Car takes a pause and stops charging for some time at 70%. I belive this is to level the charge state of the cells. After some time the charging will continue.
Regards, Thomas
tirsdag 24. september 2013 skrev Matt Beard følgende:
More strange behaviour with my C-Zero.
Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again?
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A.
The can message for current limit set by EVSE is not know for the i-Miev, so until this information is available we need to hardcode a value to be displayed in "STANDARD xxA" in the app.
Regards, Thomas
2013/9/24 Håkon Markussen <hakon.markussen@gmail.com>
Nice work Thomas,
Your attached image reminds me that I should implement the car_time and car_parktime in the Think City module :-)
Regards to max charge rate "STANDARD xxA": The variable car_chargelimit should contain the maximum available mains current, which is set by the EVSE. This is done in vehicle_thinkcity.c and I assume this can-message is available in a iMiEV and could replace the hardcoded "13A".
The evse sends a pilot signal controlling the charger max rate, which can be adjusted by the user in steps depending on the evse type. The first evse's for iMiEV was delivered with two charging steps (maybe 10-16A) and got popular among Leaf-owners. Running up to 16A over the Schuko-connector is bad firesafety, so the later evse's were replaced with 13A. (I guess) limit max. This one is a nice one(mode 2, type 2 delivered with different charging connectors: http://salto.no/produkter/ladekabel-justerbar-13-a-type-2-shuko/
When the max charge current is set by the evse, e.g. 13A the ac-charge current (which can be measured or viewed in a can-message) will never exceed this limit.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output curre
_______________________________________________ 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, it could be that i missed something..... But couldn't find anything about. @Mark: how about support for Model S? I thing some owners of Model S are not happy with "myTesla" (Server down, ....) In different Forums they start asking about this. PS: no i don't have one. :-( Looking for a sponsor! ;-) Bye Michael
Michael, I haven't heard of anyone actively working on this - just a few rumors and enquiries. One owner did try the diag connector behind the cubby, but couldn't get much from it. We don't have Model S here in Asia yet, so not much I can do at the moment. I would love to see a CAN bus dump. Regards, Mark
On 29 Sep, 2013, at 1:26 am, Michael Jochum <mikeljo@mac.com> wrote:
Hi,
it could be that i missed something..... But couldn't find anything about.
@Mark: how about support for Model S?
I thing some owners of Model S are not happy with "myTesla" (Server down, ....) In different Forums they start asking about this.
PS: no i don't have one. :-( Looking for a sponsor! ;-)
Bye Michael
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I've just made a post at the Norwegian EV-forum asking for OVMS contributors. http://elbilforum.no/forum/index.php/topic,9625.0.html (the link might not be accessible from all countries). Norway is at the moment top prioritized marked for Tesla, and we are currently getting hundreds of Model S each month, so there is a hope that some of the new owners also are interested in programming. Unfortunately, no Model S is seen in my garage ... ;) Best regards Håkon 2013/9/29 Mark Webb-Johnson <mark@webb-johnson.net>
Michael,
I haven't heard of anyone actively working on this - just a few rumors and enquiries. One owner did try the diag connector behind the cubby, but couldn't get much from it.
We don't have Model S here in Asia yet, so not much I can do at the moment. I would love to see a CAN bus dump.
Regards, Mark
On 29 Sep, 2013, at 1:26 am, Michael Jochum <mikeljo@mac.com> wrote:
Hi,
it could be that i missed something..... But couldn't find anything about.
@Mark: how about support for Model S?
I thing some owners of Model S are not happy with "myTesla" (Server down, ....) In different Forums they start asking about this.
PS: no i don't have one. :-( Looking for a sponsor! ;-)
Bye Michael
_______________________________________________ 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 tried sniffing the can bus on a Model S a while ago, but I couldn't get anything. It was a quick test so I didn't investigate any further, but the obd port looked pretty standard. I tried different CAN speeds but couldn't get any data, and I didn't have my scope with me... Sorry! MG 2013/9/29 Mark Webb-Johnson <mark@webb-johnson.net>
Michael,
I haven't heard of anyone actively working on this - just a few rumors and enquiries. One owner did try the diag connector behind the cubby, but couldn't get much from it.
We don't have Model S here in Asia yet, so not much I can do at the moment. I would love to see a CAN bus dump.
Regards, Mark
On 29 Sep, 2013, at 1:26 am, Michael Jochum <mikeljo@mac.com> wrote:
Hi,
it could be that i missed something..... But couldn't find anything about.
@Mark: how about support for Model S?
I thing some owners of Model S are not happy with "myTesla" (Server down, ....) In different Forums they start asking about this.
PS: no i don't have one. :-( Looking for a sponsor! ;-)
Bye Michael
_______________________________________________ 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 think most likely is the DIAG connector behind the cubby under touchscreen. It seems similar to roadster version.
On 29 Sep, 2013, at 9:15 pm, Mastro Gippo <gipmad@gmail.com> wrote:
I tried sniffing the can bus on a Model S a while ago, but I couldn't get anything. It was a quick test so I didn't investigate any further, but the obd port looked pretty standard. I tried different CAN speeds but couldn't get any data, and I didn't have my scope with me... Sorry! MG
2013/9/29 Mark Webb-Johnson <mark@webb-johnson.net>
Michael,
I haven't heard of anyone actively working on this - just a few rumors and enquiries. One owner did try the diag connector behind the cubby, but couldn't get much from it.
We don't have Model S here in Asia yet, so not much I can do at the moment. I would love to see a CAN bus dump.
Regards, Mark
On 29 Sep, 2013, at 1:26 am, Michael Jochum <mikeljo@mac.com> wrote:
Hi,
it could be that i missed something..... But couldn't find anything about.
@Mark: how about support for Model S?
I thing some owners of Model S are not happy with "myTesla" (Server down, ....) In different Forums they start asking about this.
PS: no i don't have one. :-( Looking for a sponsor! ;-)
Bye Michael
_______________________________________________ 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 was wrong about the bus being quiet during RC and have figured out how to detect rapid charging. Also I've found the AC charger temperature (which should probably go in PEM temperature) and I'm pretty certain I have found the motor temperature (but I need to do more testing). What I really want is the ambient temperature, but no sign yet. Any ideas? Matt Beard On Friday, September 27, 2013, Matt Beard OVMS wrote:
Has anyone seen a CAN log from a rapid charge?
Is the OBD port active at all during rapid charge? I found nothing gets reported during RC.
Matt
On 26 September 2013 10:29, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Ok, then you have the same issue.
Will look into this later.
Regards, Thomas
2013/9/26 Matt Beard OVMS <smvo@mxf.org.uk>
My STAT? gives:
Not charging SOC: 100% Ideal Range: 93 mi Est. Range 68 mi
On 26 September 2013 10:02, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Matt: Do you get the ODO in the "STAT?" SMS message? I did until two days ago, did a cleanup of the code before push to GitHub. After that i haven't got ODO. Can't see any changes to the code from the previous version ether.
Regards, Thomas
2013/9/25 Matt Beard OVMS <smvo@mxf.org.uk>
Having disconnected OVMS and power-cycled the car the charge seemed to be going OK, so I connected the unit back up and let it go the last 50% or so with OVMS and it was still fine. So, looks like something set a bad value! Maybe there is a "set max % charge" CAN message and it got set due to noise on the bus. Wish I knew what it was!
Matt
On 25 September 2013 14:35, Thomas Bergo <thomas.bergo@gmail.com> wrote:
How did the rest of the charging go? Any other hick ups?
Regards,Thomas
onsdag 25. september 2013 skrev Matt Beard følgende:
The SOC was about 25%
Matt
On Tuesday, 24 September 2013, Thomas Bergo wrote:
Was the SOC approximately 70% ?
The Car takes a pause and stops charging for some time at 70%. I belive this is to level the charge state of the cells. After some time the charging will continue.
Regards, Thomas
tirsdag 24. september 2013 skrev Matt Beard følgende:
More strange behaviour with my C-Zero.
Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again?
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A.
The can message for current limit set by EVSE is not know for the i-Miev, so until this information
Greate work. If you share your discoveries and your code, I can also do some testing. Regards, Thomas onsdag 16. oktober 2013 skrev Matt Beard følgende:
I was wrong about the bus being quiet during RC and have figured out how to detect rapid charging.
Also I've found the AC charger temperature (which should probably go in PEM temperature) and I'm pretty certain I have found the motor temperature (but I need to do more testing). What I really want is the ambient temperature, but no sign yet. Any ideas?
Matt Beard
On Friday, September 27, 2013, Matt Beard OVMS wrote:
Has anyone seen a CAN log from a rapid charge?
Is the OBD port active at all during rapid charge? I found nothing gets reported during RC.
Matt
On 26 September 2013 10:29, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Ok, then you have the same issue.
Will look into this later.
Regards, Thomas
2013/9/26 Matt Beard OVMS <smvo@mxf.org.uk>
My STAT? gives:
Not charging SOC: 100% Ideal Range: 93 mi Est. Range 68 mi
On 26 September 2013 10:02, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Matt: Do you get the ODO in the "STAT?" SMS message? I did until two days ago, did a cleanup of the code before push to GitHub. After that i haven't got ODO. Can't see any changes to the code from the previous version ether.
Regards, Thomas
2013/9/25 Matt Beard OVMS <smvo@mxf.org.uk>
Having disconnected OVMS and power-cycled the car the charge seemed to be going OK, so I connected the unit back up and let it go the last 50% or so with OVMS and it was still fine. So, looks like something set a bad value! Maybe there is a "set max % charge" CAN message and it got set due to noise on the bus. Wish I knew what it was!
Matt
On 25 September 2013 14:35, Thomas Bergo <thomas.bergo@gmail.com> wrote:
How did the rest of the charging go? Any other hick ups?
Regards,Thomas
onsdag 25. september 2013 skrev Matt Beard følgende:
The SOC was about 25%
Matt
On Tuesday, 24 September 2013, Thomas Bergo wrote:
Was the SOC approximately 70% ?
The Car takes a pause and stops charging for some time at 70%. I belive this is to level the charge state of the cells. After some time the charging will continue.
Regards, Thomas
tirsdag 24. september 2013 skrev Matt Beard følgende:
More strange behaviour with my C-Zero.
Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again?
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A.
The can message for current limit set by EVSE is not know for the i-Miev, so until this information
I hope to be able to do so in the next day or so. Matt On Wednesday, October 16, 2013, Thomas Bergo wrote:
Greate work.
If you share your discoveries and your code, I can also do some testing.
Regards, Thomas
onsdag 16. oktober 2013 skrev Matt Beard følgende:
I was wrong about the bus being quiet during RC and have figured out how to detect rapid charging.
Also I've found the AC charger temperature (which should probably go in PEM temperature) and I'm pretty certain I have found the motor temperature (but I need to do more testing). What I really want is the ambient temperature, but no sign yet. Any ideas?
Matt Beard
On Friday, September 27, 2013, Matt Beard OVMS wrote:
Has anyone seen a CAN log from a rapid charge?
Is the OBD port active at all during rapid charge? I found nothing gets reported during RC.
Matt
On 26 September 2013 10:29, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Ok, then you have the same issue.
Will look into this later.
Regards, Thomas
2013/9/26 Matt Beard OVMS <smvo@mxf.org.uk>
My STAT? gives:
Not charging SOC: 100% Ideal Range: 93 mi Est. Range 68 mi
On 26 September 2013 10:02, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Matt: Do you get the ODO in the "STAT?" SMS message? I did until two days ago, did a cleanup of the code before push to GitHub. After that i haven't got ODO. Can't see any changes to the code from the previous version ether.
Regards, Thomas
2013/9/25 Matt Beard OVMS <smvo@mxf.org.uk>
Having disconnected OVMS and power-cycled the car the charge seemed to be going OK, so I connected the unit back up and let it go the last 50% or so with OVMS and it was still fine. So, looks like something set a bad value! Maybe there is a "set max % charge" CAN message and it got set due to noise on the bus. Wish I knew what it was!
Matt
On 25 September 2013 14:35, Thomas Bergo <thomas.bergo@gmail.com> wrote:
How did the rest of the charging go? Any other hick ups?
Regards,Thomas
onsdag 25. september 2013 skrev Matt Beard følgende:
The SOC was about 25%
Matt
On Tuesday, 24 September 2013, Thomas Bergo wrote:
Was the SOC approximately 70% ?
The Car takes a pause and stops charging for some time at 70%. I belive this is to level the charge state of the cells. After some time the charging will continue.
Regards, Thomas
tirsdag 24. september 2013 skrev Matt Beard følgende:
More strange behaviour with my C-Zero.
Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again?
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit.
OK, I've done a bit more testing and it looks promising. What I have found is the following: Charger Temperature I spotted a value in byte 3 of PID 286 that rises gradually during charging, then falls slowly afterwards. It seems likely this is charger temperature of some kind. This seems to settle at about 40 higher than the current outdoor temperature in Celsius. It seems odd to be having a different offset to the battery temperature values, but the outside air temperature here is 9.7C and the PID 286 value is 50 with battery sensor average value 65. This would mean the charger is almost exactly ambient and the batteries 5C higher. I have added this as PEM temp. Motor Temperature I found that PID 298, which has the suspected motor RPM, has a set of 4 values in a similar range to the possible charger temperature reading. These seem to rise while driving, the forth of them (byte 3) rises fastest and highest. I suspect that these are intimately linked to the motor, either a direct motor temperature, or the motor drive electronics. Again, they settle to about 40 above ambient in C when not in use. I have added this as motor temp. I have found that the charger temperature rises a little while driving, and the motor temperature possibly a tad while charging (but not much). This could simply be because the two are physically close, or the charger could be involved in regenerative braking. Rapid/quick charge detection. During RC the bus has PID 346 messages, but the range in byte 7 is 255 rather than a valid estimated range. I have seen logs showing 255 for a few samples at startup, so maybe we need to add a test for this 255 being stable for more than a second or two. Of course the problem now is that we have lost the predicted range. We have "ideal" range, but that is a bit of a chocolate teapot as you are never going to get that range and it is not correctly calculated in my opinion (due to unusable SOC at the bottom of the battery). I have studied some of my charging records and it seems that the predicted range hits 0 at about 10% SOC, and it is roughly linear to 100% from there. The slope of the line depends on the recent driving style. I have used this to code a replacement "guess-o-meter" for use during rapid charge. The way it works is as follows: I constantly record valid SOC and est_range until either of them gets too low to be reliable (20% SOC or 5 range) - this gives me an indication of the slope that should be used for the line. During RC I calculate est_range = (SOC-10%) * Slope, where Slope = (Old_Range / (Old_SOC-10%)). This works, but I have only tried one RC with this code and the ranges it gave me were a bit higher than I expected. This might need some debugging. I have attached the revised code. You will see that I have also optimised the PID filtering a bit to try and reduce load while still capturing the increased number of PIDs we are now monitoring. I wonder how easy it is to check how close we are to running out of CPU capacity in the read code. Matt Beard On 17 October 2013 07:10, Matt Beard <matt@beard.tv> wrote:
I hope to be able to do so in the next day or so.
Matt
On Wednesday, October 16, 2013, Thomas Bergo wrote:
Greate work.
If you share your discoveries and your code, I can also do some testing.
Regards, Thomas
onsdag 16. oktober 2013 skrev Matt Beard følgende:
I was wrong about the bus being quiet during RC and have figured out how to detect rapid charging.
Also I've found the AC charger temperature (which should probably go in PEM temperature) and I'm pretty certain I have found the motor temperature (but I need to do more testing). What I really want is the ambient temperature, but no sign yet. Any ideas?
Matt Beard
On Friday, September 27, 2013, Matt Beard OVMS wrote:
Has anyone seen a CAN log from a rapid charge?
Is the OBD port active at all during rapid charge? I found nothing gets reported during RC.
Matt
On 26 September 2013 10:29, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Ok, then you have the same issue.
Will look into this later.
Regards, Thomas
2013/9/26 Matt Beard OVMS <smvo@mxf.org.uk>
My STAT? gives:
Not charging SOC: 100% Ideal Range: 93 mi Est. Range 68 mi
On 26 September 2013 10:02, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Matt: Do you get the ODO in the "STAT?" SMS message? I did until two days ago, did a cleanup of the code before push to GitHub. After that i haven't got ODO. Can't see any changes to the code from the previous version ether.
Regards, Thomas
2013/9/25 Matt Beard OVMS <smvo@mxf.org.uk>
Having disconnected OVMS and power-cycled the car the charge seemed to be going OK, so I connected the unit back up and let it go the last 50% or so with OVMS and it was still fine. So, looks like something set a bad value! Maybe there is a "set max % charge" CAN message and it got set due to noise on the bus. Wish I knew what it was!
Matt
On 25 September 2013 14:35, Thomas Bergo <thomas.bergo@gmail.com> wrote:
How did the rest of the charging go? Any other hick ups?
Regards,Thomas
onsdag 25. september 2013 skrev Matt Beard følgende:
The SOC was about 25%
Matt
On Tuesday, 24 September 2013, Thomas Bergo wrote:
Was the SOC approximately 70% ?
The Car takes a pause and stops charging for some time at 70%. I belive this is to level the charge state of the cells. After some time the charging will continue.
Regards, Thomas
tirsdag 24. september 2013 skrev Matt Beard følgende:
More strange behaviour with my C-Zero.
Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again?
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit.
Matt, Thomas, Looks good. When ready for this to be merged to mainline, please let me know. Regards, Mark. On 18 Oct, 2013, at 5:08 pm, Matt Beard <matt@beard.tv> wrote:
OK, I've done a bit more testing and it looks promising.
What I have found is the following:
Charger Temperature I spotted a value in byte 3 of PID 286 that rises gradually during charging, then falls slowly afterwards. It seems likely this is charger temperature of some kind. This seems to settle at about 40 higher than the current outdoor temperature in Celsius. It seems odd to be having a different offset to the battery temperature values, but the outside air temperature here is 9.7C and the PID 286 value is 50 with battery sensor average value 65. This would mean the charger is almost exactly ambient and the batteries 5C higher. I have added this as PEM temp.
Motor Temperature I found that PID 298, which has the suspected motor RPM, has a set of 4 values in a similar range to the possible charger temperature reading. These seem to rise while driving, the forth of them (byte 3) rises fastest and highest. I suspect that these are intimately linked to the motor, either a direct motor temperature, or the motor drive electronics. Again, they settle to about 40 above ambient in C when not in use. I have added this as motor temp.
I have found that the charger temperature rises a little while driving, and the motor temperature possibly a tad while charging (but not much). This could simply be because the two are physically close, or the charger could be involved in regenerative braking.
Rapid/quick charge detection. During RC the bus has PID 346 messages, but the range in byte 7 is 255 rather than a valid estimated range. I have seen logs showing 255 for a few samples at startup, so maybe we need to add a test for this 255 being stable for more than a second or two. Of course the problem now is that we have lost the predicted range. We have "ideal" range, but that is a bit of a chocolate teapot as you are never going to get that range and it is not correctly calculated in my opinion (due to unusable SOC at the bottom of the battery).
I have studied some of my charging records and it seems that the predicted range hits 0 at about 10% SOC, and it is roughly linear to 100% from there. The slope of the line depends on the recent driving style. I have used this to code a replacement "guess-o-meter" for use during rapid charge. The way it works is as follows: I constantly record valid SOC and est_range until either of them gets too low to be reliable (20% SOC or 5 range) - this gives me an indication of the slope that should be used for the line. During RC I calculate est_range = (SOC-10%) * Slope, where Slope = (Old_Range / (Old_SOC-10%)). This works, but I have only tried one RC with this code and the ranges it gave me were a bit higher than I expected. This might need some debugging.
I have attached the revised code. You will see that I have also optimised the PID filtering a bit to try and reduce load while still capturing the increased number of PIDs we are now monitoring. I wonder how easy it is to check how close we are to running out of CPU capacity in the read code.
Matt Beard
On 17 October 2013 07:10, Matt Beard <matt@beard.tv> wrote: I hope to be able to do so in the next day or so. Matt
On Wednesday, October 16, 2013, Thomas Bergo wrote: Greate work.
If you share your discoveries and your code, I can also do some testing.
Regards, Thomas
onsdag 16. oktober 2013 skrev Matt Beard følgende: I was wrong about the bus being quiet during RC and have figured out how to detect rapid charging.
Also I've found the AC charger temperature (which should probably go in PEM temperature) and I'm pretty certain I have found the motor temperature (but I need to do more testing). What I really want is the ambient temperature, but no sign yet. Any ideas?
Matt Beard
On Friday, September 27, 2013, Matt Beard OVMS wrote: Has anyone seen a CAN log from a rapid charge?
Is the OBD port active at all during rapid charge? I found nothing gets reported during RC.
Matt
On 26 September 2013 10:29, Thomas Bergo <thomas.bergo@gmail.com> wrote: Ok, then you have the same issue.
Will look into this later.
Regards, Thomas
2013/9/26 Matt Beard OVMS <smvo@mxf.org.uk> My STAT? gives:
Not charging SOC: 100% Ideal Range: 93 mi Est. Range 68 mi
On 26 September 2013 10:02, Thomas Bergo <thomas.bergo@gmail.com> wrote: Matt: Do you get the ODO in the "STAT?" SMS message? I did until two days ago, did a cleanup of the code before push to GitHub. After that i haven't got ODO. Can't see any changes to the code from the previous version ether.
Regards, Thomas
2013/9/25 Matt Beard OVMS <smvo@mxf.org.uk> Having disconnected OVMS and power-cycled the car the charge seemed to be going OK, so I connected the unit back up and let it go the last 50% or so with OVMS and it was still fine. So, looks like something set a bad value! Maybe there is a "set max % charge" CAN message and it got set due to noise on the bus. Wish I knew what it was!
Matt
On 25 September 2013 14:35, Thomas Bergo <thomas.bergo@gmail.com> wrote: How did the rest of the charging go? Any other hick ups?
Regards,Thomas
onsdag 25. september 2013 skrev Matt Beard følgende:
The SOC was about 25%
Matt
On Tuesday, 24 September 2013, Thomas Bergo wrote: Was the SOC approximately 70% ?
The Car takes a pause and stops charging for some time at 70%. I belive this is to level the charge state of the cells. After some time the charging will continue.
Regards, Thomas
tirsdag 24. september 2013 skrev Matt Beard følgende: More strange behaviour with my C-Zero.
Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again?
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote: The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit.
<vehicle_mitsubishi.c>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I have also upped the value claimed for the charge limit when AC charging from 13A to 16A (in my local code) because I have found currents higher than 13A being drawn at times from a charging post. I have attached an example. Matt On 21 October 2013 02:03, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt, Thomas,
Looks good.
When ready for this to be merged to mainline, please let me know.
Regards, Mark.
On 18 Oct, 2013, at 5:08 pm, Matt Beard <matt@beard.tv> wrote:
OK, I've done a bit more testing and it looks promising.
What I have found is the following:
Charger Temperature I spotted a value in byte 3 of PID 286 that rises gradually during charging, then falls slowly afterwards. It seems likely this is charger temperature of some kind. This seems to settle at about 40 higher than the current outdoor temperature in Celsius. It seems odd to be having a different offset to the battery temperature values, but the outside air temperature here is 9.7C and the PID 286 value is 50 with battery sensor average value 65. This would mean the charger is almost exactly ambient and the batteries 5C higher. I have added this as PEM temp.
Motor Temperature I found that PID 298, which has the suspected motor RPM, has a set of 4 values in a similar range to the possible charger temperature reading. These seem to rise while driving, the forth of them (byte 3) rises fastest and highest. I suspect that these are intimately linked to the motor, either a direct motor temperature, or the motor drive electronics. Again, they settle to about 40 above ambient in C when not in use. I have added this as motor temp.
I have found that the charger temperature rises a little while driving, and the motor temperature possibly a tad while charging (but not much). This could simply be because the two are physically close, or the charger could be involved in regenerative braking.
Rapid/quick charge detection. During RC the bus has PID 346 messages, but the range in byte 7 is 255 rather than a valid estimated range. I have seen logs showing 255 for a few samples at startup, so maybe we need to add a test for this 255 being stable for more than a second or two. Of course the problem now is that we have lost the predicted range. We have "ideal" range, but that is a bit of a chocolate teapot as you are never going to get that range and it is not correctly calculated in my opinion (due to unusable SOC at the bottom of the battery).
I have studied some of my charging records and it seems that the predicted range hits 0 at about 10% SOC, and it is roughly linear to 100% from there. The slope of the line depends on the recent driving style. I have used this to code a replacement "guess-o-meter" for use during rapid charge. The way it works is as follows: I constantly record valid SOC and est_range until either of them gets too low to be reliable (20% SOC or 5 range) - this gives me an indication of the slope that should be used for the line. During RC I calculate est_range = (SOC-10%) * Slope, where Slope = (Old_Range / (Old_SOC-10%)). This works, but I have only tried one RC with this code and the ranges it gave me were a bit higher than I expected. This might need some debugging.
I have attached the revised code. You will see that I have also optimised the PID filtering a bit to try and reduce load while still capturing the increased number of PIDs we are now monitoring. I wonder how easy it is to check how close we are to running out of CPU capacity in the read code.
Matt Beard
On 17 October 2013 07:10, Matt Beard <matt@beard.tv> wrote:
I hope to be able to do so in the next day or so. Matt
On Wednesday, October 16, 2013, Thomas Bergo wrote:
Greate work.
If you share your discoveries and your code, I can also do some testing.
Regards, Thomas
onsdag 16. oktober 2013 skrev Matt Beard følgende:
I was wrong about the bus being quiet during RC and have figured out how to detect rapid charging.
Also I've found the AC charger temperature (which should probably go in PEM temperature) and I'm pretty certain I have found the motor temperature (but I need to do more testing). What I really want is the ambient temperature, but no sign yet. Any ideas?
Matt Beard
On Friday, September 27, 2013, Matt Beard OVMS wrote:
Has anyone seen a CAN log from a rapid charge?
Is the OBD port active at all during rapid charge? I found nothing gets reported during RC.
Matt
On 26 September 2013 10:29, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Ok, then you have the same issue.
Will look into this later.
Regards, Thomas
2013/9/26 Matt Beard OVMS <smvo@mxf.org.uk>
My STAT? gives:
Not charging SOC: 100% Ideal Range: 93 mi Est. Range 68 mi
On 26 September 2013 10:02, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Matt: Do you get the ODO in the "STAT?" SMS message? I did until two days ago, did a cleanup of the code before push to GitHub. After that i haven't got ODO. Can't see any changes to the code from the previous version ether.
Regards, Thomas
2013/9/25 Matt Beard OVMS <smvo@mxf.org.uk>
Having disconnected OVMS and power-cycled the car the charge seemed to be going OK, so I connected the unit back up and let it go the last 50% or so with OVMS and it was still fine. So, looks like something set a bad value! Maybe there is a "set max % charge" CAN message and it got set due to noise on the bus. Wish I knew what it was!
Matt
On 25 September 2013 14:35, Thomas Bergo <thomas.bergo@gmail.com> wrote:
How did the rest of the charging go? Any other hick ups?
Regards,Thomas
onsdag 25. september 2013 skrev Matt Beard følgende:
The SOC was about 25%
Matt
On Tuesday, 24 September 2013, Thomas Bergo wrote:
Was the SOC approximately 70% ?
The Car takes a pause and stops charging for some time at 70%. I belive this is to level the charge state of the cells. After some time the charging will continue.
Regards, Thomas
tirsdag 24. september 2013 skrev Matt Beard følgende:
More strange behaviour with my C-Zero.
Trying to investigate charging current today I discovered that the car would not charge for longer than a couple of minutes with the OVMS connected (with Thomas' image loaded). It would start charging, then the current would drop to zero, but the charge light stayed on. After a while it stopped even trying to charge. Disconnecting the OVMS didn't fix it until I also turned the car on and off again (with the OVMS not connected). Did can noise cause problems again?
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit.
<vehicle_mitsubishi.c>_______________________________________________
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 Matt I have started to look into the QC code. And i have one concern. Have you seen if the voltage and charging current (PID 0x389) is reported during QC? If not, we are not able to detect that the car is charging during QC with current code. Thomas
I believe I have figured out a way to handle the QC state. Is testing a new version with following changes: - Added Motor and PEM temperature reading (thanks to Matt Beard) - Added calculation of estimated range during QC (thanks to Matt Beard) - Added detection of quick charging - Changed calculation of ideal range to reflect that SOC below 10% not usable. - Changed hard coded charge limit to 16A for standardization. - Fixed temperature stale in app. - Fixed charge status on charge interruption. Will update on GitHub after some more testing. Regards, Thomas. 2013/10/27 Thomas Bergo <thomas.bergo@gmail.com>
Hi Matt
I have started to look into the QC code. And i have one concern. Have you seen if the voltage and charging current (PID 0x389) is reported during QC? If not, we are not able to detect that the car is charging during QC with current code.
Thomas
Hi Thomas, During QC you don't get valid values reported in 0x389 - it seems to be constant 255V, 0A during QC. My code is relying on the fact that the estimated range only ever seems to be reported as 255 during QC (except for the first few messages at startup, but those are easy to filter out). In my testing so far this seems to work for detecting the start and end of QC. I am going to be doing 3 more tests today with my latest code and will report back later. Matt On 27 October 2013 20:13, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi Matt
I have started to look into the QC code. And i have one concern. Have you seen if the voltage and charging current (PID 0x389) is reported during QC? If not, we are not able to detect that the car is charging during QC with current code.
Thomas
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Matt, Please report back when you have done some testing on the QC. If the car report 0A while QC, the current code will not detect that we are charging. So then we need to rely on the estimated range reported as 255 to detecting that the car is QC. Regards, Thomas 2013/10/30 Matt Beard OVMS <smvo@mxf.org.uk>
Hi Thomas,
During QC you don't get valid values reported in 0x389 - it seems to be constant 255V, 0A during QC.
My code is relying on the fact that the estimated range only ever seems to be reported as 255 during QC (except for the first few messages at startup, but those are easy to filter out). In my testing so far this seems to work for detecting the start and end of QC. I am going to be doing 3 more tests today with my latest code and will report back later.
Matt
On 27 October 2013 20:13, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi Matt
I have started to look into the QC code. And i have one concern. Have you seen if the voltage and charging current (PID 0x389) is reported during QC? If not, we are not able to detect that the car is charging during QC with current code.
Thomas
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark, Was testing the new 2.6.2 code on i-Miev today. Two observations: - Lots of restarts and "Vehicle authentication failed" messages in the iOS app - No CAN bus messages form PID in poll0, while messages in poll1 is working OK. Programmed the OVMS module with a version, and verified that the module was OK. Regards, Thomas 2013/10/30 Thomas Bergo <thomas.bergo@gmail.com>
Matt,
Please report back when you have done some testing on the QC.
If the car report 0A while QC, the current code will not detect that we are charging. So then we need to rely on the estimated range reported as 255 to detecting that the car is QC.
Regards, Thomas
2013/10/30 Matt Beard OVMS <smvo@mxf.org.uk>
Hi Thomas,
During QC you don't get valid values reported in 0x389 - it seems to be constant 255V, 0A during QC.
My code is relying on the fact that the estimated range only ever seems to be reported as 255 during QC (except for the first few messages at startup, but those are easy to filter out). In my testing so far this seems to work for detecting the start and end of QC. I am going to be doing 3 more tests today with my latest code and will report back later.
Matt
On 27 October 2013 20:13, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi Matt
I have started to look into the QC code. And i have one concern. Have you seen if the voltage and charging current (PID 0x389) is reported during QC? If not, we are not able to detect that the car is charging during QC with current code.
Thomas
_______________________________________________ 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
Thomas, Strange. So far, I see 4 cars using 2.6.2, but only one (presumably yours) is showing authentication errors. I also can't see any changes to the vehicle_mitsubishi.c code that would cause poll0 to stop working. It is certainly working in other vehicle modules. I'll keep looking, but would be grateful if you could try to narrow down the poll0 problem. Regards, Mark. On 22 Jan, 2014, at 5:00 am, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Mark,
Was testing the new 2.6.2 code on i-Miev today.
Two observations: - Lots of restarts and "Vehicle authentication failed" messages in the iOS app - No CAN bus messages form PID in poll0, while messages in poll1 is working OK.
Programmed the OVMS module with a version, and verified that the module was OK.
Regards, Thomas
2013/10/30 Thomas Bergo <thomas.bergo@gmail.com> Matt,
Please report back when you have done some testing on the QC.
If the car report 0A while QC, the current code will not detect that we are charging. So then we need to rely on the estimated range reported as 255 to detecting that the car is QC.
Regards, Thomas
2013/10/30 Matt Beard OVMS <smvo@mxf.org.uk> Hi Thomas,
During QC you don't get valid values reported in 0x389 - it seems to be constant 255V, 0A during QC.
My code is relying on the fact that the estimated range only ever seems to be reported as 255 during QC (except for the first few messages at startup, but those are easy to filter out). In my testing so far this seems to work for detecting the start and end of QC. I am going to be doing 3 more tests today with my latest code and will report back later.
Matt
On 27 October 2013 20:13, Thomas Bergo <thomas.bergo@gmail.com> wrote: Hi Matt
I have started to look into the QC code. And i have one concern. Have you seen if the voltage and charging current (PID 0x389) is reported during QC? If not, we are not able to detect that the car is charging during QC with current code.
Thomas
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark Do you know what code the 4 cars is using? Production or experimental? Regards, Thomas Den onsdag 22. januar 2014 skrev Mark Webb-Johnson <mark@webb-johnson.net> følgende:
Thomas,
Strange. So far, I see 4 cars using 2.6.2, but only one (presumably yours) is showing authentication errors.
I also can't see any changes to the vehicle_mitsubishi.c code that would cause poll0 to stop working. It is certainly working in other vehicle modules.
I'll keep looking, but would be grateful if you could try to narrow down the poll0 problem.
Regards, Mark.
On 22 Jan, 2014, at 5:00 am, Thomas Bergo <thomas.bergo@gmail.com<javascript:_e({}, 'cvml', 'thomas.bergo@gmail.com');>> wrote:
Mark,
Was testing the new 2.6.2 code on i-Miev today.
Two observations: - Lots of restarts and "Vehicle authentication failed" messages in the iOS app - No CAN bus messages form PID in poll0, while messages in poll1 is working OK.
Programmed the OVMS module with a version, and verified that the module was OK.
Regards, Thomas
2013/10/30 Thomas Bergo <thomas.bergo@gmail.com <javascript:_e({}, 'cvml', 'thomas.bergo@gmail.com');>>
Matt,
Please report back when you have done some testing on the QC.
If the car report 0A while QC, the current code will not detect that we are charging. So then we need to rely on the estimated range reported as 255 to detecting that the car is QC.
Regards, Thomas
2013/10/30 Matt Beard OVMS <smvo@mxf.org.uk <javascript:_e({}, 'cvml', 'smvo@mxf.org.uk');>>
Hi Thomas,
During QC you don't get valid values reported in 0x389 - it seems to be constant 255V, 0A during QC.
My code is relying on the fact that the estimated range only ever seems to be reported as 255 during QC (except for the first few messages at startup, but those are easy to filter out). In my testing so far this seems to work for detecting the start and end of QC. I am going to be doing 3 more tests today with my latest code and will report back later.
Matt
On 27 October 2013 20:13, Thomas Bergo <thomas.bergo@gmail.com<javascript:_e({}, 'cvml', 'thomas.bergo@gmail.com');>
wrote:
Hi Matt
I have started to look into the QC code. And i have one concern. Have you seen if the voltage and charging current (PID 0x389) is reported during QC? If not, we are not able to detect that the car is charging during QC with current code.
Thomas
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <javascript:_e({}, 'cvml', 'OvmsDev@lists.teslaclub.hk');> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <javascript:_e({}, 'cvml', 'OvmsDev@lists.teslaclub.hk');> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <javascript:_e({}, 'cvml', 'OvmsDev@lists.teslaclub.hk');> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Thomas, 2x RT 1x TR 1x MI I don't know the actual builds (whether the V2_experimental or V2_RT_production) for the twizzies. Mine is the TR and that is V2_TR_production. It is conceivably that you are the only one running the V2_experimental at the moment. Can someone else try? Regards, Mark. On 22 Jan, 2014, at 2:43 pm, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Mark
Do you know what code the 4 cars is using? Production or experimental?
Regards, Thomas
Den onsdag 22. januar 2014 skrev Mark Webb-Johnson <mark@webb-johnson.net> følgende: Thomas,
Strange. So far, I see 4 cars using 2.6.2, but only one (presumably yours) is showing authentication errors.
I also can't see any changes to the vehicle_mitsubishi.c code that would cause poll0 to stop working. It is certainly working in other vehicle modules.
I'll keep looking, but would be grateful if you could try to narrow down the poll0 problem.
Regards, Mark.
On 22 Jan, 2014, at 5:00 am, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Mark,
Was testing the new 2.6.2 code on i-Miev today.
Two observations: - Lots of restarts and "Vehicle authentication failed" messages in the iOS app - No CAN bus messages form PID in poll0, while messages in poll1 is working OK.
Programmed the OVMS module with a version, and verified that the module was OK.
Regards, Thomas
2013/10/30 Thomas Bergo <thomas.bergo@gmail.com> Matt,
Please report back when you have done some testing on the QC.
If the car report 0A while QC, the current code will not detect that we are charging. So then we need to rely on the estimated range reported as 255 to detecting that the car is QC.
Regards, Thomas
2013/10/30 Matt Beard OVMS <smvo@mxf.org.uk> Hi Thomas,
During QC you don't get valid values reported in 0x389 - it seems to be constant 255V, 0A during QC.
My code is relying on the fact that the estimated range only ever seems to be reported as 255 during QC (except for the first few messages at startup, but those are easy to filter out). In my testing so far this seems to work for detecting the start and end of QC. I am going to be doing 3 more tests today with my latest code and will report back later.
Matt
On 27 October 2013 20:13, Thomas Bergo <thomas.bergo@gmail.com> wrote: Hi Matt
I have started to look into the QC code. And i have one concern. Have you seen if the voltage and charging current (PID 0x389) is reported during QC? If not, we are not able to detect that the car is charging during QC with current code.
Thomas
_______________________________________________ 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
Mark, if the Mitsubishi code does not use the new polling hooks, poll0() will not be called if the polling code is compiled in. I had the same problem for the Twizy, that's why I introduced the OVMS_POLLER compiler switch. Regards, Michael Am 22.01.2014 02:18, schrieb Mark Webb-Johnson:
Thomas,
Strange. So far, I see 4 cars using 2.6.2, but only one (presumably yours) is showing authentication errors.
I also can't see any changes to the vehicle_mitsubishi.c code that would cause poll0 to stop working. It is certainly working in other vehicle modules.
I'll keep looking, but would be grateful if you could try to narrow down the poll0 problem.
Regards, Mark.
On 22 Jan, 2014, at 5:00 am, Thomas Bergo <thomas.bergo@gmail.com <mailto:thomas.bergo@gmail.com>> wrote:
Mark,
Was testing the new 2.6.2 code on i-Miev today.
Two observations: - Lots of restarts and "Vehicle authentication failed" messages in the iOS app - No CAN bus messages form PID in poll0, while messages in poll1 is working OK.
Programmed the OVMS module with a version, and verified that the module was OK.
Regards, Thomas
2013/10/30 Thomas Bergo <thomas.bergo@gmail.com <mailto:thomas.bergo@gmail.com>>
Matt,
Please report back when you have done some testing on the QC.
If the car report 0A while QC, the current code will not detect that we are charging. So then we need to rely on the estimated range reported as 255 to detecting that the car is QC.
Regards, Thomas
2013/10/30 Matt Beard OVMS <smvo@mxf.org.uk <mailto:smvo@mxf.org.uk>>
Hi Thomas,
During QC you don't get valid values reported in 0x389 - it seems to be constant 255V, 0A during QC.
My code is relying on the fact that the estimated range only ever seems to be reported as 255 during QC (except for the first few messages at startup, but those are easy to filter out). In my testing so far this seems to work for detecting the start and end of QC. I am going to be doing 3 more tests today with my latest code and will report back later.
Matt
On 27 October 2013 20:13, Thomas Bergo <thomas.bergo@gmail.com <mailto:thomas.bergo@gmail.com>> wrote:
Hi Matt
I have started to look into the QC code. And i have one concern. Have you seen if the voltage and charging current (PID 0x389) is reported during QC? If not, we are not able to detect that the car is charging during QC with current code.
Thomas
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto: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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
Michael, Yep, that’s it. Problem is OVMS_POLLER is a compile-time definition, so it must be shared by all cars in the configuration. I’ve re-worked it slightly to call the poll0 function even there is no poll list defined: diff --git a/vehicle/OVMS.X/vehicle.c b/vehicle/OVMS.X/vehicle.c index 9c1e9d9..a706bf1 100644 --- a/vehicle/OVMS.X/vehicle.c +++ b/vehicle/OVMS.X/vehicle.c @@ -295,15 +295,21 @@ void high_isr(void) can_databuffer[7] = RXB0D7; RXB0CONbits.RXFUL = 0; // All bytes read, Clear flag #ifdef OVMS_POLLER - if ((vehicle_poll_plist != NULL)&& - (can_id >= vehicle_poll_moduleid_low)&& - (can_id <= vehicle_poll_moduleid_high)) + if (vehicle_poll_plist != NULL) { - if (vehicle_poll_poll0()) + if ((can_id >= vehicle_poll_moduleid_low)&& + (can_id <= vehicle_poll_moduleid_high)) { - vehicle_fn_poll0(); + if (vehicle_poll_poll0()) + { + vehicle_fn_poll0(); + } } } + else + { + vehicle_fn_poll0(); + } #else // #ifdef OVMS_POLLER vehicle_fn_poll0(); #endif //#ifdef OVMS_POLLER I hope this fixes it. Thomas: Can you try to build this version (it is in github master now). Regards, Mark. On 23 Jan, 2014, at 4:29 pm, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
if the Mitsubishi code does not use the new polling hooks, poll0() will not be called if the polling code is compiled in.
I had the same problem for the Twizy, that's why I introduced the OVMS_POLLER compiler switch.
Regards, Michael
Am 22.01.2014 02:18, schrieb Mark Webb-Johnson:
Thomas,
Strange. So far, I see 4 cars using 2.6.2, but only one (presumably yours) is showing authentication errors.
I also can't see any changes to the vehicle_mitsubishi.c code that would cause poll0 to stop working. It is certainly working in other vehicle modules.
I'll keep looking, but would be grateful if you could try to narrow down the poll0 problem.
Regards, Mark.
On 22 Jan, 2014, at 5:00 am, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Mark,
Was testing the new 2.6.2 code on i-Miev today.
Two observations: - Lots of restarts and "Vehicle authentication failed" messages in the iOS app - No CAN bus messages form PID in poll0, while messages in poll1 is working OK.
Programmed the OVMS module with a version, and verified that the module was OK.
Regards, Thomas
2013/10/30 Thomas Bergo <thomas.bergo@gmail.com> Matt,
Please report back when you have done some testing on the QC.
If the car report 0A while QC, the current code will not detect that we are charging. So then we need to rely on the estimated range reported as 255 to detecting that the car is QC.
Regards, Thomas
2013/10/30 Matt Beard OVMS <smvo@mxf.org.uk> Hi Thomas,
During QC you don't get valid values reported in 0x389 - it seems to be constant 255V, 0A during QC.
My code is relying on the fact that the estimated range only ever seems to be reported as 255 during QC (except for the first few messages at startup, but those are easy to filter out). In my testing so far this seems to work for detecting the start and end of QC. I am going to be doing 3 more tests today with my latest code and will report back later.
Matt
On 27 October 2013 20:13, Thomas Bergo <thomas.bergo@gmail.com> wrote: Hi Matt
I have started to look into the QC code. And i have one concern. Have you seen if the voltage and charging current (PID 0x389) is reported during QC? If not, we are not able to detect that the car is charging during QC with current code.
Thomas
_______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Is there an simple explanation somewhere of the change to the polling system? Matt Beard On 23 January 2014 12:11, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Michael,
Yep, that’s it.
Problem is OVMS_POLLER is a compile-time definition, so it must be shared by all cars in the configuration. I’ve re-worked it slightly to call the poll0 function even there is no poll list defined:
diff --git a/vehicle/OVMS.X/vehicle.c b/vehicle/OVMS.X/vehicle.c index 9c1e9d9..a706bf1 100644 --- a/vehicle/OVMS.X/vehicle.c +++ b/vehicle/OVMS.X/vehicle.c @@ -295,15 +295,21 @@ void high_isr(void) can_databuffer[7] = RXB0D7; RXB0CONbits.RXFUL = 0; // All bytes read, Clear flag #ifdef OVMS_POLLER - if ((vehicle_poll_plist != NULL)&& - (can_id >= vehicle_poll_moduleid_low)&& - (can_id <= vehicle_poll_moduleid_high)) + if (vehicle_poll_plist != NULL) { - if (vehicle_poll_poll0()) + if ((can_id >= vehicle_poll_moduleid_low)&& + (can_id <= vehicle_poll_moduleid_high)) { - vehicle_fn_poll0(); + if (vehicle_poll_poll0()) + { + vehicle_fn_poll0(); + } } } + else + { + vehicle_fn_poll0(); + } #else // #ifdef OVMS_POLLER vehicle_fn_poll0(); #endif //#ifdef OVMS_POLLER
I hope this fixes it.
Thomas: Can you try to build this version (it is in github master now).
Regards, Mark.
On 23 Jan, 2014, at 4:29 pm, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
if the Mitsubishi code does not use the new polling hooks, poll0() will not be called if the polling code is compiled in.
I had the same problem for the Twizy, that's why I introduced the OVMS_POLLER compiler switch.
Regards, Michael
Am 22.01.2014 02:18, schrieb Mark Webb-Johnson:
Thomas,
Strange. So far, I see 4 cars using 2.6.2, but only one (presumably yours) is showing authentication errors.
I also can't see any changes to the vehicle_mitsubishi.c code that would cause poll0 to stop working. It is certainly working in other vehicle modules.
I'll keep looking, but would be grateful if you could try to narrow down the poll0 problem.
Regards, Mark.
On 22 Jan, 2014, at 5:00 am, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Mark,
Was testing the new 2.6.2 code on i-Miev today.
Two observations: - Lots of restarts and "Vehicle authentication failed" messages in the iOS app - No CAN bus messages form PID in poll0, while messages in poll1 is working OK.
Programmed the OVMS module with a version, and verified that the module was OK.
Regards, Thomas
2013/10/30 Thomas Bergo <thomas.bergo@gmail.com>
Matt,
Please report back when you have done some testing on the QC.
If the car report 0A while QC, the current code will not detect that we are charging. So then we need to rely on the estimated range reported as 255 to detecting that the car is QC.
Regards, Thomas
2013/10/30 Matt Beard OVMS <smvo@mxf.org.uk>
Hi Thomas,
During QC you don't get valid values reported in 0x389 - it seems to be constant 255V, 0A during QC.
My code is relying on the fact that the estimated range only ever seems to be reported as 255 during QC (except for the first few messages at startup, but those are easy to filter out). In my testing so far this seems to work for detecting the start and end of QC. I am going to be doing 3 more tests today with my latest code and will report back later.
Matt
On 27 October 2013 20:13, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi Matt
I have started to look into the QC code. And i have one concern. Have you seen if the voltage and charging current (PID 0x389) is reported during QC? If not, we are not able to detect that the car is charging during QC with current code.
Thomas
_______________________________________________ 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 listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
<dexter.vcf>_______________________________________________
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Matt, From a developer's point of view? No, I haven't updated the developers guide yet. The best (and only) example code that uses it is in vehicle_obdii.c. Rough description is: To use the new OBDII polling code, create a rom-based structure detailing what PIDs you want to poll. For the base obdii vehicle, it looks like this: rom vehicle_pid_t vehicle_obdii_polls[] = { { 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x05, { 0, 30, 30 } }, // Engine coolant temp { 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x0c, { 10, 10, 10 } }, // Engine RPM { 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x0d, { 0, 10, 10 } }, // Speed { 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x0f, { 0, 30, 30 } }, // Engine air intake temp { 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x2f, { 0, 30, 30 } }, // Fuel level { 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x46, { 0, 30, 30 } }, // Ambiant temp { 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x5c, { 0, 30, 30 } }, // Engine oil temp { 0x7df, VEHICLE_POLL_TYPE_OBDIIVEHICLE, 0x02, {999,999,999 } }, // VIN { 0, 0x00, 0x00, { 0, 0, 0 } } }; It is an array of arrays. Each row is one PID to be polled, and the last row should be all zeros. The columns are: moduleid (CAN id of the request message) type (see VEHICLE_POLL_TYPE_* in vehicle.h) pid (the PID to be polled) poll time (in seconds, three entries - one for each poll state) The system supports 3 poll states. You can use these how you want, but a typical example would be IDLE, CHARGING, DRIVING. These states are completely under your control, and allow you to set different poll times for different PIDs in different states. By setting poll time to 0, for a particular state, you can disable polling. You set the poll state in the global vehicle_poll_state variable via the vehicle_poll_setstate() call. Once you've got everything setup, you need to start the polling, in your initialisation function: vehicle_fn_poll0 = &vehicle_obdii_poll0; vehicle_poll_setpidlist(vehicle_obdii_polls); vehicle_poll_setstate(0); You tell the poller about you rom poll list with vehicle_poll_setpidlist(), and will be called back with poll results via the vehicle_fn_poll0() hook. You will also need to 'tickle' the vehicle_poll_busactive global variable. The polling code will stop polling of vehicle_poll_busactive<=0. Normally, you would just set this to 60 (seconds) when you want polling to be active, and then decrement it in a ticker function (so it decrements to zero and stops polling automatically, unless the ticker is reset). Alternatively, you can just use it as an on/off switch (1 or 0). The poll results will be delivered via the vehicle_fn_poll0() hook, in the normal way. It is your responsibility to extract the data from the can_databuffer as normal. In the case of multi-message responses (for some poll types like VEHICLE_POLL_TYPE_OBDIIVEHICLE), the system will maintain a global vehicle_poll_ml_offset variable, recording the current offset and vehicle_poll_ml_remain recording the number of bytes remaining. See the example in vehicle_obdii.c for how to handle this: case 0x02: // VIN (multi-line response) for (value1=0;value1<can_datalength;value1++) { car_vin[value1+(vehicle_poll_ml_offset-can_datalength)] = can_databuffer[value1]; } if (vehicle_poll_ml_remain==0) car_vin[value1+vehicle_poll_ml_offset] = 0; This is a base framework, that can be extended over time (as different vehicles use different polling frameworks). It does remove the majority of the tedious polling work from Hope the above helps. I'll use it as the basis for the developer's guide update. Regards, Mark. On 23 Jan, 2014, at 10:34 pm, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Is there an simple explanation somewhere of the change to the polling system?
Matt Beard
On 23 January 2014 12:11, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Michael,
Yep, that’s it.
Problem is OVMS_POLLER is a compile-time definition, so it must be shared by all cars in the configuration. I’ve re-worked it slightly to call the poll0 function even there is no poll list defined:
diff --git a/vehicle/OVMS.X/vehicle.c b/vehicle/OVMS.X/vehicle.c index 9c1e9d9..a706bf1 100644 --- a/vehicle/OVMS.X/vehicle.c +++ b/vehicle/OVMS.X/vehicle.c @@ -295,15 +295,21 @@ void high_isr(void) can_databuffer[7] = RXB0D7; RXB0CONbits.RXFUL = 0; // All bytes read, Clear flag #ifdef OVMS_POLLER - if ((vehicle_poll_plist != NULL)&& - (can_id >= vehicle_poll_moduleid_low)&& - (can_id <= vehicle_poll_moduleid_high)) + if (vehicle_poll_plist != NULL) { - if (vehicle_poll_poll0()) + if ((can_id >= vehicle_poll_moduleid_low)&& + (can_id <= vehicle_poll_moduleid_high)) { - vehicle_fn_poll0(); + if (vehicle_poll_poll0()) + { + vehicle_fn_poll0(); + } } } + else + { + vehicle_fn_poll0(); + } #else // #ifdef OVMS_POLLER vehicle_fn_poll0(); #endif //#ifdef OVMS_POLLER
I hope this fixes it.
Thomas: Can you try to build this version (it is in github master now).
Regards, Mark.
On 23 Jan, 2014, at 4:29 pm, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
if the Mitsubishi code does not use the new polling hooks, poll0() will not be called if the polling code is compiled in.
I had the same problem for the Twizy, that's why I introduced the OVMS_POLLER compiler switch.
Regards, Michael
Am 22.01.2014 02:18, schrieb Mark Webb-Johnson:
Thomas,
Strange. So far, I see 4 cars using 2.6.2, but only one (presumably yours) is showing authentication errors.
I also can't see any changes to the vehicle_mitsubishi.c code that would cause poll0 to stop working. It is certainly working in other vehicle modules.
I'll keep looking, but would be grateful if you could try to narrow down the poll0 problem.
Regards, Mark.
On 22 Jan, 2014, at 5:00 am, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Mark,
Was testing the new 2.6.2 code on i-Miev today.
Two observations: - Lots of restarts and "Vehicle authentication failed" messages in the iOS app - No CAN bus messages form PID in poll0, while messages in poll1 is working OK.
Programmed the OVMS module with a version, and verified that the module was OK.
Regards, Thomas
2013/10/30 Thomas Bergo <thomas.bergo@gmail.com> Matt,
Please report back when you have done some testing on the QC.
If the car report 0A while QC, the current code will not detect that we are charging. So then we need to rely on the estimated range reported as 255 to detecting that the car is QC.
Regards, Thomas
2013/10/30 Matt Beard OVMS <smvo@mxf.org.uk> Hi Thomas,
During QC you don't get valid values reported in 0x389 - it seems to be constant 255V, 0A during QC.
My code is relying on the fact that the estimated range only ever seems to be reported as 255 during QC (except for the first few messages at startup, but those are easy to filter out). In my testing so far this seems to work for detecting the start and end of QC. I am going to be doing 3 more tests today with my latest code and will report back later.
Matt
On 27 October 2013 20:13, Thomas Bergo <thomas.bergo@gmail.com> wrote: Hi Matt
I have started to look into the QC code. And i have one concern. Have you seen if the voltage and charging current (PID 0x389) is reported during QC? If not, we are not able to detect that the car is charging during QC with current code.
Thomas
_______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________
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
Have tested the new 2.6.2 code since yesterday, and so far it's look good. Needed to move some of the data converting out of the interrupt routine. Have also added reading of VIN and corrected some error on cars using miles. Regards, Thomas 2014/1/24 Mark Webb-Johnson <mark@webb-johnson.net>
Matt,
From a developer's point of view?
No, I haven't updated the developers guide yet. The best (and only) example code that uses it is in vehicle_obdii.c.
Rough description is:
To use the new OBDII polling code, create a rom-based structure detailing what PIDs you want to poll. For the base obdii vehicle, it looks like this:
rom vehicle_pid_t vehicle_obdii_polls[]
=
{
{ 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x05, { 0, 30, 30 } }, // Engine coolant temp
{ 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x0c, { 10, 10, 10 } }, // Engine RPM
{ 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x0d, { 0, 10, 10 } }, // Speed
{ 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x0f, { 0, 30, 30 } }, // Engine air intake temp
{ 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x2f, { 0, 30, 30 } }, // Fuel level
{ 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x46, { 0, 30, 30 } }, // Ambiant temp
{ 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x5c, { 0, 30, 30 } }, // Engine oil temp
{ 0x7df, VEHICLE_POLL_TYPE_OBDIIVEHICLE, 0x02, {999,999,999 } }, // VIN
{ 0, 0x00, 0x00, { 0, 0, 0 } }
};
It is an array of arrays. Each row is one PID to be polled, and the last row should be all zeros. The columns are:
- moduleid (CAN id of the request message) - type (see VEHICLE_POLL_TYPE_* in vehicle.h) - pid (the PID to be polled) - poll time (in seconds, three entries - one for each poll state)
The system supports 3 poll states. You can use these how you want, but a typical example would be IDLE, CHARGING, DRIVING. These states are completely under your control, and allow you to set different poll times for different PIDs in different states. By setting poll time to 0, for a particular state, you can disable polling. You set the poll state in the global vehicle_poll_state variable via the vehicle_poll_setstate() call.
Once you've got everything setup, you need to start the polling, in your initialisation function:
vehicle_fn_poll0 = &vehicle_obdii_poll0; vehicle_poll_setpidlist(vehicle_obdii_polls); vehicle_poll_setstate(0);
You tell the poller about you rom poll list with vehicle_poll_setpidlist(), and will be called back with poll results via the vehicle_fn_poll0() hook.
You will also need to 'tickle' the vehicle_poll_busactive global variable. The polling code will stop polling of vehicle_poll_busactive<=0. Normally, you would just set this to 60 (seconds) when you want polling to be active, and then decrement it in a ticker function (so it decrements to zero and stops polling automatically, unless the ticker is reset). Alternatively, you can just use it as an on/off switch (1 or 0).
The poll results will be delivered via the vehicle_fn_poll0() hook, in the normal way. It is your responsibility to extract the data from the can_databuffer as normal.
In the case of multi-message responses (for some poll types like VEHICLE_POLL_TYPE_OBDIIVEHICLE), the system will maintain a global vehicle_poll_ml_offset variable, recording the current offset and vehicle_poll_ml_remain recording the number of bytes remaining. See the example in vehicle_obdii.c for how to handle this:
case 0x02: // VIN (multi-line response) for (value1=0;value1<can_datalength;value1++) { car_vin[value1+(vehicle_poll_ml_offset-can_datalength)] = can_databuffer[value1]; } if (vehicle_poll_ml_remain==0) car_vin[value1+vehicle_poll_ml_offset] = 0;
This is a base framework, that can be extended over time (as different vehicles use different polling frameworks). It does remove the majority of the tedious polling work from
Hope the above helps. I'll use it as the basis for the developer's guide update.
Regards, Mark.
On 23 Jan, 2014, at 10:34 pm, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Is there an simple explanation somewhere of the change to the polling system?
Matt Beard
On 23 January 2014 12:11, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Michael,
Yep, that’s it.
Problem is OVMS_POLLER is a compile-time definition, so it must be shared by all cars in the configuration. I’ve re-worked it slightly to call the poll0 function even there is no poll list defined:
diff --git a/vehicle/OVMS.X/vehicle.c b/vehicle/OVMS.X/vehicle.c index 9c1e9d9..a706bf1 100644 --- a/vehicle/OVMS.X/vehicle.c +++ b/vehicle/OVMS.X/vehicle.c @@ -295,15 +295,21 @@ void high_isr(void) can_databuffer[7] = RXB0D7; RXB0CONbits.RXFUL = 0; // All bytes read, Clear flag #ifdef OVMS_POLLER - if ((vehicle_poll_plist != NULL)&& - (can_id >= vehicle_poll_moduleid_low)&& - (can_id <= vehicle_poll_moduleid_high)) + if (vehicle_poll_plist != NULL) { - if (vehicle_poll_poll0()) + if ((can_id >= vehicle_poll_moduleid_low)&& + (can_id <= vehicle_poll_moduleid_high)) { - vehicle_fn_poll0(); + if (vehicle_poll_poll0()) + { + vehicle_fn_poll0(); + } } } + else + { + vehicle_fn_poll0(); + } #else // #ifdef OVMS_POLLER vehicle_fn_poll0(); #endif //#ifdef OVMS_POLLER
I hope this fixes it.
Thomas: Can you try to build this version (it is in github master now).
Regards, Mark.
On 23 Jan, 2014, at 4:29 pm, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
if the Mitsubishi code does not use the new polling hooks, poll0() will not be called if the polling code is compiled in.
I had the same problem for the Twizy, that's why I introduced the OVMS_POLLER compiler switch.
Regards, Michael
Am 22.01.2014 02:18, schrieb Mark Webb-Johnson:
Thomas,
Strange. So far, I see 4 cars using 2.6.2, but only one (presumably yours) is showing authentication errors.
I also can't see any changes to the vehicle_mitsubishi.c code that would cause poll0 to stop working. It is certainly working in other vehicle modules.
I'll keep looking, but would be grateful if you could try to narrow down the poll0 problem.
Regards, Mark.
On 22 Jan, 2014, at 5:00 am, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Mark,
Was testing the new 2.6.2 code on i-Miev today.
Two observations: - Lots of restarts and "Vehicle authentication failed" messages in the iOS app - No CAN bus messages form PID in poll0, while messages in poll1 is working OK.
Programmed the OVMS module with a version, and verified that the module was OK.
Regards, Thomas
2013/10/30 Thomas Bergo <thomas.bergo@gmail.com>
Matt,
Please report back when you have done some testing on the QC.
If the car report 0A while QC, the current code will not detect that we are charging. So then we need to rely on the estimated range reported as 255 to detecting that the car is QC.
Regards, Thomas
2013/10/30 Matt Beard OVMS <smvo@mxf.org.uk>
Hi Thomas,
During QC you don't get valid values reported in 0x389 - it seems to be constant 255V, 0A during QC.
My code is relying on the fact that the estimated range only ever seems to be reported as 255 during QC (except for the first few messages at startup, but those are easy to filter out). In my testing so far this seems to work for detecting the start and end of QC. I am going to be doing 3 more tests today with my latest code and will report back later.
Matt
On 27 October 2013 20:13, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi Matt
I have started to look into the QC code. And i have one concern. Have you seen if the voltage and charging current (PID 0x389) is reported during QC? If not, we are not able to detect that the car is charging during QC with current code.
Thomas
_______________________________________________ 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 listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
<dexter.vcf>_______________________________________________
OvmsDev mailing list OvmsDev@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
It's alive!! Your last fix did it, I'm now on 2.6.2 FW. Den torsdag 23. januar 2014 skrev Mark Webb-Johnson <mark@webb-johnson.net> følgende:
Michael,
Yep, that’s it.
Problem is OVMS_POLLER is a compile-time definition, so it must be shared by all cars in the configuration. I’ve re-worked it slightly to call the poll0 function even there is no poll list defined:
diff --git a/vehicle/OVMS.X/vehicle.c b/vehicle/OVMS.X/vehicle.c index 9c1e9d9..a706bf1 100644 --- a/vehicle/OVMS.X/vehicle.c +++ b/vehicle/OVMS.X/vehicle.c @@ -295,15 +295,21 @@ void high_isr(void) can_databuffer[7] = RXB0D7; RXB0CONbits.RXFUL = 0; // All bytes read, Clear flag #ifdef OVMS_POLLER - if ((vehicle_poll_plist != NULL)&& - (can_id >= vehicle_poll_moduleid_low)&& - (can_id <= vehicle_poll_moduleid_high)) + if (vehicle_poll_plist != NULL) { - if (vehicle_poll_poll0()) + if ((can_id >= vehicle_poll_moduleid_low)&& + (can_id <= vehicle_poll_moduleid_high)) { - vehicle_fn_poll0(); + if (vehicle_poll_poll0()) + { + vehicle_fn_poll0(); + } } } + else + { + vehicle_fn_poll0(); + } #else // #ifdef OVMS_POLLER vehicle_fn_poll0(); #endif //#ifdef OVMS_POLLER
I hope this fixes it.
Thomas: Can you try to build this version (it is in github master now).
Regards, Mark.
On 23 Jan, 2014, at 4:29 pm, Michael Balzer <dexter@expeedo.de<javascript:_e({}, 'cvml', 'dexter@expeedo.de');>> wrote:
Mark,
if the Mitsubishi code does not use the new polling hooks, poll0() will not be called if the polling code is compiled in.
I had the same problem for the Twizy, that's why I introduced the OVMS_POLLER compiler switch.
Regards, Michael
Am 22.01.2014 02:18, schrieb Mark Webb-Johnson:
Thomas,
Strange. So far, I see 4 cars using 2.6.2, but only one (presumably yours) is showing authentication errors.
I also can't see any changes to the vehicle_mitsubishi.c code that would cause poll0 to stop working. It is certainly working in other vehicle modules.
I'll keep looking, but would be grateful if you could try to narrow down the poll0 problem.
Regards, Mark.
On 22 Jan, 2014, at 5:00 am, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Mark,
Was testing the new 2.6.2 code on i-Miev today.
Two observations: - Lots of restarts and "Vehicle authentication failed" messages in the iOS app - No CAN bus messages form PID in poll0, while messages in poll1 is working OK.
Programmed the OVMS module with a version, and verified that the module was OK.
Regards, Thomas
2013/10/30 Thomas Bergo <thomas.bergo@gmail.com>
Matt,
Please report back when you have done some testing on the QC.
If the car report 0A while QC, the current code will not detect that we are charging. So then we need to rely on the estimated range reported as 255 to detecting that the car is QC.
<dexter.vcf>_______________________________________________ OvmsDev mailing list
I'm not sure what type of home charger you have Thomas, but having a 16A label gives no guarantee for its pilot signal to actually request 16A. To be 100% sure you have to read the pwm duty-cycle of the evse pilot, eighter by a scope or by connecting your evse to a car with available (known) can-message for charge current limit. If you have this wall mounted "pod-point" evse's, I would expect the pilot signal to request 16A. In that case the iMiEV-charger does overwrite the pilot. This was done on the early Think City A306 cars (gen0 PCU), which had a weak charger. Br. Håkon 2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A.
The can message for current limit set by EVSE is not know for the i-Miev, so until this information is available we need to hardcode a value to be displayed in "STANDARD xxA" in the app.
Regards, Thomas
2013/9/24 Håkon Markussen <hakon.markussen@gmail.com>
Nice work Thomas,
Your attached image reminds me that I should implement the car_time and car_parktime in the Think City module :-)
Regards to max charge rate "STANDARD xxA": The variable car_chargelimit should contain the maximum available mains current, which is set by the EVSE. This is done in vehicle_thinkcity.c and I assume this can-message is available in a iMiEV and could replace the hardcoded "13A".
The evse sends a pilot signal controlling the charger max rate, which can be adjusted by the user in steps depending on the evse type. The first evse's for iMiEV was delivered with two charging steps (maybe 10-16A) and got popular among Leaf-owners. Running up to 16A over the Schuko-connector is bad firesafety, so the later evse's were replaced with 13A. (I guess) limit max. This one is a nice one(mode 2, type 2 delivered with different charging connectors: http://salto.no/produkter/ladekabel-justerbar-13-a-type-2-shuko/
When the max charge current is set by the evse, e.g. 13A the ac-charge current (which can be measured or viewed in a can-message) will never exceed this limit.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output current?
I notice that the Volt/Ampera code sets 16A as the charge limit.
Matt
On 24 September 2013 19:58, Thomas Bergo <thomas.bergo@gmail.com>wrote:
The charger is only able to deliver 3 KW to the battery, so the car will maximum use 13A from the grid. I therefor hardcoded the charging to "STANDARD 13A"
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
I think my hardware may have a dodgy connection as it is working again!
I am using the hex file Thomas sent (one that failed yesterday!)
I noticed that the charge level is reported wrongly. I am using a 16A charger (and the car does charge at > 13A) yet the C-Zero code is reporting the charge type as "STANDARD 13A" and the charge current is showing as 12A.
Matt
On 24 September 2013 19:22, Thomas Bergo <thomas.bergo@gmail.com>wrote:
> I read some rumors that some cars imported from Denmark to Norway > had a smaller battery pack. > Have to look some more to find where i read about this. > > Regards, Thomas > > > 2013/9/24 Matt Beard <matt@beard.tv> > >> You can tell how many cells from the 6en messages, but I heard >> that the range is the same, but the unused capacity is less so the >> batteries don't last as well. >> >> This needs to be confirmed. >> >> Matt >> >> >> On Tuesday, September 24, 2013, Thomas Bergo wrote: >> >>> There is delivered some Citroen C-Zero with a smaller battery pack >>> (13 KWh VS 16 KWh.) The ideal range for the 13 KWh battery I believe is 80 >>> miles and for the 16 KWh battery the ideal range is 150km (93 miles). >>> >>> To calculate the ideal range correctly for both battery size we >>> need a way to distinguish between them. >>> >>> Do you think that there will be any issues by using the Feature >>> 14, Car bits, to indicate which battery pack the car has? >>> >>> Regards, Thomas >>> >>> >>> 2013/9/24 Matt Beard <matt@beard.tv> >>> >>> I'm using a Global SIM. >>> >>> I may try the diag port if I can find something that reads RS-232 >>> in this day and age! I must try and get a USB adapter. >>> >>> Matt >>> >>> >>> On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote: >>> >>> Great. In addition, you might want to try and attach something to >>> the diagnostics port. You should be able to read through the port any AT >>> commands, to make sure it's working correctly. >>> >>> I believe there's a list somewhere of the messages you'll get from >>> the diagnostic port for that chip.. 901 is it? (I can't remember, but it's >>> what we used to diagnose the SIM card was at fault.) >>> >>> Nikki. >>> >>> P.S. What SIM are you using? Global? O2? >>> >>> >>> On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote: >>> >>> Actually, running it with stock firmware as OBDII in our ICE is >>> next on my list of checks. >>> >>> Matt >>> >>> >>> On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote: >>> >>> The other suggestion I would have is to plug the ODBII module into >>> another car -- or power it from a bench supply using the method detailed in >>> the development guide? >>> >>> Nikki. >>> >>> On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> >>> wrote: >>> >>> Matt, >>> >>> I have modules with me for replacement, if necessary. >>> >>> I am concerned about your comments regarding soldering. All the v2 >>> modules are supposed to be machine soldered, and we have had almost zero >>> returns of broken modules.I would be grateful if you could let me know the >>> serial number of your module, the approximate date you received it, and if >>> possible a picture of the soldering issues. >>> >>> I too am perplexed why the module would work SMS but not GPRS. >>> Perhaps you can try setting the vehicle type to 'XX', which would eliminate >>> any can bus/message issues, and see if the problem still occurs. >>> >>> Please eMail me, off list, as mark (at) openvehicles (dot) com, >>> and I'll work through this with you. >>> >>> Regards, Mark. >>> >>> On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> >>> wrote: >>> >>> Thanks Thomas, >>> >>> That has confirmed for me that my hardware has died. >>> >>> Looking at the circuit board the soldering on the GSM modem is >>> shocking, but I don't understand how it can work for SMS, but crash with >>> GPRS. Looks like I will be spending most of my effort in the coming days >>> trying to get the hardware replaced! >>> >>> I have confirmed that the unit functions perfectly (though is >>> pretty useless) with the GPRS switch set to disabled. If it is booted with >>> the switch enabled it dies as soon as I set the GPRS parameters, then >>> enters an endless reboot loop. >>> >>> Matt >>> >>> >>> >>> >>> >>> On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com>wrote: >>> >>> Attached is the hex file, this is the exact same that is running >>> om my module now. >>> >>> Regards, Thomas >>> >>> >>> 2013/9/23 Matt Beard <matt@beard.tv> >>> >>> Thomas, >>> >>> That would be really useful. I am worried that the module may have >>> failed. >>> >>> I did not keep a copy of the last working hex file (lesson >>> learned!) but did save the sources. Rebuilt from previous sources and >>> loaded. It still fails. >>> >>> Matt >>> >>> >>> >>> On Monday, September 23, 2013, Thomas Bergo wrote: >>> >>> Matt: >>> >>> I can send you the hex file i'm running in my OVMS module, so you >>> can try if that woking in your module? >>> >>> >> _______________________________________________ >> 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
_______________________________________________ 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 have a Open EVSE charger at home. And it is set to 16A. But this can be wrong, I have not measured the duty-cycle myself. Maybe I should do that one day:-) Matt: I can change the settings to 16A and send you a new hex file tomorrow? Regards, Thomas onsdag 25. september 2013 skrev Håkon Markussen følgende:
I'm not sure what type of home charger you have Thomas, but having a 16A label gives no guarantee for its pilot signal to actually request 16A.
To be 100% sure you have to read the pwm duty-cycle of the evse pilot, eighter by a scope or by connecting your evse to a car with available (known) can-message for charge current limit.
If you have this wall mounted "pod-point" evse's, I would expect the pilot signal to request 16A. In that case the iMiEV-charger does overwrite the pilot. This was done on the early Think City A306 cars (gen0 PCU), which had a weak charger.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A.
The can message for current limit set by EVSE is not know for the i-Miev, so until this information is available we need to hardcode a value to be displayed in "STANDARD xxA" in the app.
Regards, Thomas
2013/9/24 Håkon Markussen <hakon.markussen@gmail.com>
Nice work Thomas,
Your attached image reminds me that I should implement the car_time and car_parktime in the Think City module :-)
Regards to max charge rate "STANDARD xxA": The variable car_chargelimit should contain the maximum available mains current, which is set by the EVSE. This is done in vehicle_thinkcity.c and I assume this can-message is available in a iMiEV and could replace the hardcoded "13A".
The evse sends a pilot signal controlling the charger max rate, which can be adjusted by the user in steps depending on the evse type. The first evse's for iMiEV was delivered with two charging steps (maybe 10-16A) and got popular among Leaf-owners. Running up to 16A over the Schuko-connector is bad firesafety, so the later evse's were replaced with 13A. (I guess) limit max. This one is a nice one(mode 2, type 2 delivered with different charging connectors: http://salto.no/produkter/ladekabel-justerbar-13-a-type-2-shuko/
When the max charge current is set by the evse, e.g. 13A the ac-charge current (which can be measured or viewed in a can-message) will never exceed this limit.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output current?
I notice that the Volt/Ampera code sets 16A as the charge limit.
Matt
On 24 September 2013 19:58, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Hi, Thanks for the offer, but I can do the mod here. I am more concerned that what gets released to other users is consistent with the other versions. Matt On Tuesday, September 24, 2013, Thomas Bergo wrote:
I have a Open EVSE charger at home. And it is set to 16A. But this can be wrong, I have not measured the duty-cycle myself. Maybe I should do that one day:-)
Matt: I can change the settings to 16A and send you a new hex file tomorrow?
Regards, Thomas
onsdag 25. september 2013 skrev Håkon Markussen følgende:
I'm not sure what type of home charger you have Thomas, but having a 16A label gives no guarantee for its pilot signal to actually request 16A.
To be 100% sure you have to read the pwm duty-cycle of the evse pilot, eighter by a scope or by connecting your evse to a car with available (known) can-message for charge current limit.
If you have this wall mounted "pod-point" evse's, I would expect the pilot signal to request 16A. In that case the iMiEV-charger does overwrite the pilot. This was done on the early Think City A306 cars (gen0 PCU), which had a weak charger.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
The first models (2011) was delivered with a 16A cable. This was changed for the later models (2012 ->) to 10A cable do to firesafty. At home i use a 16A cable for charging, but the car only draw 13A.
I'm not sure what is the correct info, EVSE limit or the charger limit. Any way the car will only draw 13A.
The can message for current limit set by EVSE is not know for the i-Miev, so until this information is available we need to hardcode a value to be displayed in "STANDARD xxA" in the app.
Regards, Thomas
2013/9/24 Håkon Markussen <hakon.markussen@gmail.com>
Nice work Thomas,
Your attached image reminds me that I should implement the car_time and car_parktime in the Think City module :-)
Regards to max charge rate "STANDARD xxA": The variable car_chargelimit should contain the maximum available mains current, which is set by the EVSE. This is done in vehicle_thinkcity.c and I assume this can-message is available in a iMiEV and could replace the hardcoded "13A".
The evse sends a pilot signal controlling the charger max rate, which can be adjusted by the user in steps depending on the evse type. The first evse's for iMiEV was delivered with two charging steps (maybe 10-16A) and got popular among Leaf-owners. Running up to 16A over the Schuko-connector is bad firesafety, so the later evse's were replaced with 13A. (I guess) limit max. This one is a nice one(mode 2, type 2 delivered with different charging connectors: http://salto.no/produkter/ladekabel-justerbar-13-a-type-2-shuko/
When the max charge current is set by the evse, e.g. 13A the ac-charge current (which can be measured or viewed in a can-message) will never exceed this limit.
Br. Håkon
2013/9/24 Thomas Bergo <thomas.bergo@gmail.com>
I don't remember to have seen any documentation. There is a common understanding in Norway that the car only can drain 13A. I have also measured hove much current the car use when charging.
This setting is only for information in the app, as no information is send to the car from the car module. There is no way that the car module can impact on the charge current. The voltage and current (13A) is reported by the car and not limited by the OVMS.
[image: Innebygd bilde 1]
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output current?
I notice that the Volt/Ampera code sets 16A as the charge limit.
Matt
On 24 September 2013 19:58, Thomas Bergo <
The Roadster displays input current drawn (and actual input voltage). Tom On 9/24/13 1:06 PM, "Matt Beard OVMS" <smvo@mxf.org.uk> wrote:
Do you have a source for this 13A maximum claim? Mitsubishi claim that the on-board charger in the iMiev runs at 240V 15A in the USA.
If you want to use the output rating of the charger you need to reduce the figure to 9A as the output is 330V.
What does the Roadster version set - does it use the input current, or some version of the output current?
I notice that the Volt/Ampera code sets 16A as the charge limit.
Matt
On 24 September 2013 19:58, Thomas Bergo <thomas.bergo@gmail.com> wrote:
The charger is only able to deliver 3 KW to the battery, so the car will maximum use 13A from the grid. I therefor hardcoded the charging to "STANDARD 13A"
Regards, Thomas
2013/9/24 Matt Beard OVMS <smvo@mxf.org.uk>
I think my hardware may have a dodgy connection as it is working again!
I am using the hex file Thomas sent (one that failed yesterday!)
I noticed that the charge level is reported wrongly. I am using a 16A charger (and the car does charge at > 13A) yet the C-Zero code is reporting the charge type as "STANDARD 13A" and the charge current is showing as 12A.
Matt
On 24 September 2013 19:22, Thomas Bergo <thomas.bergo@gmail.com> wrote:
I read some rumors that some cars imported from Denmark to Norway had a smaller battery pack. Have to look some more to find where i read about this.
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
You can tell how many cells from the 6en messages, but I heard that the range is the same, but the unused capacity is less so the batteries don't last as well. This needs to be confirmed.
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
There is delivered some Citroen C-Zero with a smaller battery pack (13 KWh VS 16 KWh.) The ideal range for the 13 KWh battery I believe is 80 miles and for the 16 KWh battery the ideal range is 150km (93 miles).
To calculate the ideal range correctly for both battery size we need a way to distinguish between them.
Do you think that there will be any issues by using the Feature 14, Car bits, to indicate which battery pack the car has?
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
I'm using a Global SIM. I may try the diag port if I can find something that reads RS-232 in this day and age! I must try and get a USB adapter.
Matt
On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote:
Great. In addition, you might want to try and attach something to the diagnostics port. You should be able to read through the port any AT commands, to make sure it's working correctly.
I believe there's a list somewhere of the messages you'll get from the diagnostic port for that chip.. 901 is it? (I can't remember, but it's what we used to diagnose the SIM card was at fault.)
Nikki.
P.S. What SIM are you using? Global? O2?
On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote:
Actually, running it with stock firmware as OBDII in our ICE is next on my list of checks. Matt
On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote:
The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide?
Nikki.
On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt, I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Attached is the hex file, this is the exact same that is running om my module now. Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv>
Thomas, That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote:
Matt: I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
_______________________________________________ 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
Matt: I believe you are right. From datasheets the range is rated to 150 km with 16 KWh and 14.5 KWh battery. I believe the battery is the same, and 16 KWh is theoretical capacity and 14.5 KWh is usable capacity. For the 2013 i-Miev the rated range is 160 km with the same battery as previous MY. Regards, Thomas 2013/9/24 Matt Beard <matt@beard.tv>
You can tell how many cells from the 6en messages, but I heard that the range is the same, but the unused capacity is less so the batteries don't last as well.
This needs to be confirmed.
Matt
On Tuesday, September 24, 2013, Thomas Bergo wrote:
There is delivered some Citroen C-Zero with a smaller battery pack (13 KWh VS 16 KWh.) The ideal range for the 13 KWh battery I believe is 80 miles and for the 16 KWh battery the ideal range is 150km (93 miles).
To calculate the ideal range correctly for both battery size we need a way to distinguish between them.
Do you think that there will be any issues by using the Feature 14, Car bits, to indicate which battery pack the car has?
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv>
I'm using a Global SIM.
I may try the diag port if I can find something that reads RS-232 in this day and age! I must try and get a USB adapter.
Matt
On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote:
Great. In addition, you might want to try and attach something to the diagnostics port. You should be able to read through the port any AT commands, to make sure it's working correctly.
I believe there's a list somewhere of the messages you'll get from the diagnostic port for that chip.. 901 is it? (I can't remember, but it's what we used to diagnose the SIM card was at fault.)
Nikki.
P.S. What SIM are you using? Global? O2?
On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote:
Actually, running it with stock firmware as OBDII in our ICE is next on my list of checks.
Matt
On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote:
The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide?
Nikki.
On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt,
I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv>
Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote:
Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
We could use carbits, which is what we did with the roadster originally. However, in general I think it best to try to determine the version based on CAN bus data. The current roadster logic is based on that (actually, it sets carbits based on what is sees on the bus). Regards, Mark. On 25 Sep, 2013, at 2:09 AM, Thomas Bergo <thomas.bergo@gmail.com> wrote:
There is delivered some Citroen C-Zero with a smaller battery pack (13 KWh VS 16 KWh.) The ideal range for the 13 KWh battery I believe is 80 miles and for the 16 KWh battery the ideal range is 150km (93 miles).
To calculate the ideal range correctly for both battery size we need a way to distinguish between them.
Do you think that there will be any issues by using the Feature 14, Car bits, to indicate which battery pack the car has?
Regards, Thomas
2013/9/24 Matt Beard <matt@beard.tv> I'm using a Global SIM.
I may try the diag port if I can find something that reads RS-232 in this day and age! I must try and get a USB adapter.
Matt
On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote: Great. In addition, you might want to try and attach something to the diagnostics port. You should be able to read through the port any AT commands, to make sure it's working correctly.
I believe there's a list somewhere of the messages you'll get from the diagnostic port for that chip.. 901 is it? (I can't remember, but it's what we used to diagnose the SIM card was at fault.)
Nikki.
P.S. What SIM are you using? Global? O2?
On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote:
Actually, running it with stock firmware as OBDII in our ICE is next on my list of checks.
Matt
On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote: The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide?
Nikki.
On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt,
I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com> wrote: Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv> Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote: Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
Regards, Thomas
2013/9/23 Thomas Bergo <thomas.bergo@gmail.com> I did a rebuild from clean to ensure that i running the exact same code. My OVMS module is booting as expected, and only the green led is blinking OK (one blink]
Which version of the OVMS FW are you running? I have only tested with the 2.5.2 FW. Are there any significant changes from 2.5.2 that can impact the code to constantly reboot?
Regards, Thomas
2013/9/23 Matt Beard OVMS <smvo@mxf.org.uk> OK - either this code is broken, or my OVMS is.
I flashed the code and set the unit up - no go, kept rebooting and the GPRS does not work.
Rebuild from clean. Reflashed, reloaded settings and still constant rebooting and GPRS does not work.
Matt
On 23 September 2013 10:24, Thomas Bergo <thomas.bergo@gmail.com> wrote:
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, i think it is NOT a good Idea to send a hex File plain. I sometimes receive and send some hex Files (AVR). They are ALL corrupt. It ONLY works (in my case) to zip or rar the hex and send this. Then they work ALL. The bad thing is that they can sometimes flash into the µC without crc error. But didn't work. Bye Michael Am 24.09.2013 um 11:42 schrieb Matt Beard <matt@beard.tv>:
I'm using a Global SIM.
I may try the diag port if I can find something that reads RS-232 in this day and age! I must try and get a USB adapter.
Matt
On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote: Great. In addition, you might want to try and attach something to the diagnostics port. You should be able to read through the port any AT commands, to make sure it's working correctly.
I believe there's a list somewhere of the messages you'll get from the diagnostic port for that chip.. 901 is it? (I can't remember, but it's what we used to diagnose the SIM card was at fault.)
Nikki.
P.S. What SIM are you using? Global? O2?
On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote:
Actually, running it with stock firmware as OBDII in our ICE is next on my list of checks.
Matt
On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote: The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide?
Nikki.
On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt,
I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com> wrote: Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv> Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote: Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
Regards, Thomas
2013/9/23 Thomas Bergo <thomas.bergo@gmail.com> I did a rebuild from clean to ensure that i running the exact same code. My OVMS module is booting as expected, and only the green led is blinking OK (one blink]
Which version of the OVMS FW are you running? I have only tested with the 2.5.2 FW. Are there any significant changes from 2.5.2 that can impact the code to constantly reboot?
Regards, Thomas
2013/9/23 Matt Beard OVMS <smvo@mxf.org.uk> OK - either this code is broken, or my OVMS is.
I flashed the code and set the unit up - no go, kept rebooting and the GPRS does not work.
Rebuild from clean. Reflashed, reloaded settings and still constant rebooting and GPRS does not work.
Matt
On 23 September 2013 10:24, Thomas Bergo <thomas.bergo@gmail.com> wrote:
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 Attached is the hex file compressed with rar Regards, Thomas 2013/9/24 Michael Jochum <mikeljo@mac.com>
Hi,
i think it is NOT a good Idea to send a hex File plain. I sometimes receive and send some hex Files (AVR). They are ALL corrupt. It ONLY works (in my case) to zip or rar the hex and send this. Then they work ALL. The bad thing is that they can sometimes flash into the µC without crc error. But didn't work.
Bye Michael
Am 24.09.2013 um 11:42 schrieb Matt Beard <matt@beard.tv>:
I'm using a Global SIM.
I may try the diag port if I can find something that reads RS-232 in this day and age! I must try and get a USB adapter.
Matt
On Tuesday, 24 September 2013, Nikki Gordon-Bloomfield wrote:
Great. In addition, you might want to try and attach something to the diagnostics port. You should be able to read through the port any AT commands, to make sure it's working correctly.
I believe there's a list somewhere of the messages you'll get from the diagnostic port for that chip.. 901 is it? (I can't remember, but it's what we used to diagnose the SIM card was at fault.)
Nikki.
P.S. What SIM are you using? Global? O2?
On 24 Sep 2013, at 09:16, Matt Beard <matt@beard.tv> wrote:
Actually, running it with stock firmware as OBDII in our ICE is next on my list of checks.
Matt
On Tuesday, September 24, 2013, Nikki Gordon-Bloomfield wrote:
The other suggestion I would have is to plug the ODBII module into another car -- or power it from a bench supply using the method detailed in the development guide?
Nikki.
On 24 Sep 2013, at 08:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Matt,
I have modules with me for replacement, if necessary.
I am concerned about your comments regarding soldering. All the v2 modules are supposed to be machine soldered, and we have had almost zero returns of broken modules.I would be grateful if you could let me know the serial number of your module, the approximate date you received it, and if possible a picture of the soldering issues.
I too am perplexed why the module would work SMS but not GPRS. Perhaps you can try setting the vehicle type to 'XX', which would eliminate any can bus/message issues, and see if the problem still occurs.
Please eMail me, off list, as mark (at) openvehicles (dot) com, and I'll work through this with you.
Regards, Mark.
On 24 Sep, 2013, at 5:13 AM, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Thanks Thomas,
That has confirmed for me that my hardware has died.
Looking at the circuit board the soldering on the GSM modem is shocking, but I don't understand how it can work for SMS, but crash with GPRS. Looks like I will be spending most of my effort in the coming days trying to get the hardware replaced!
I have confirmed that the unit functions perfectly (though is pretty useless) with the GPRS switch set to disabled. If it is booted with the switch enabled it dies as soon as I set the GPRS parameters, then enters an endless reboot loop.
Matt
On 23 September 2013 21:18, Thomas Bergo <thomas.bergo@gmail.com> wrote:
Attached is the hex file, this is the exact same that is running om my module now.
Regards, Thomas
2013/9/23 Matt Beard <matt@beard.tv>
Thomas,
That would be really useful. I am worried that the module may have failed.
I did not keep a copy of the last working hex file (lesson learned!) but did save the sources. Rebuilt from previous sources and loaded. It still fails.
Matt
On Monday, September 23, 2013, Thomas Bergo wrote:
Matt:
I can send you the hex file i'm running in my OVMS module, so you can try if that woking in your module?
Regards, Thomas
2013/9/23 Thomas Bergo <thomas.bergo@gmail.com>
I did a rebuild from clean to ensure that i running the exact same code. My OVMS module is booting as expected, and only the green led is blinking OK (one blink]
Which version of the OVMS FW are you running? I have only tested with the 2.5.2 FW. Are there any significant changes from 2.5.2 that can impact the code to constantly reboot?
Regards, Thomas
2013/9/23 Matt Beard OVMS <smvo@mxf.org.uk>
OK - either this code is broken, or my OVMS is.
I flashed the code and set the unit up - no go, kept rebooting and the GPRS does not work.
Rebuild from clean. Reflashed, reloaded settings and still constant rebooting and GPRS does not work.
Matt
On 23 September 2013 10:24, Thomas Bergo <thomas.bergo@gmail.com> wrote:
_______________________________________________ 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, I have a C-Zero and would like OVMS support. I am currently considering buying a unit and would be able to help with development if/when I get one. Matt Beard On Monday, April 29, 2013, Thomas Bergo wrote:
Hi
As a owner of a i-Miev I'm interested in OVMS support for the i-Miev/C-Zero/iOn EV.
Has anyone looked into supporting those EV?
I'm planing to start looking into adding support for those EV. And asking for help to add a vehicle plug-in module stub for those cars, so that naming and so on is correct.
Best regards Thomas B
HI Matt, Thomas, I'd suggest at least one of you will need some form of CAN logger. Either a purpose-built device, or something that you can connect to a serial or USB port to pull date from your car? See the roadster logs in GitHub ;) I'd also recommend your read the development doc here: https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/OV... :) Nikki. On 29 Apr 2013, at 07:22, Matt Beard <matt@beard.tv> wrote:
Hi, I have a C-Zero and would like OVMS support. I am currently considering buying a unit and would be able to help with development if/when I get one.
Matt Beard
On Monday, April 29, 2013, Thomas Bergo wrote: Hi
As a owner of a i-Miev I'm interested in OVMS support for the i-Miev/C-Zero/iOn EV.
Has anyone looked into supporting those EV?
I'm planing to start looking into adding support for those EV. And asking for help to add a vehicle plug-in module stub for those cars, so that naming and so on is correct.
Best regards Thomas B
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Nikki, Thanks for the links. Following on from links-to-links-to-links, and my schoolboy french: http://prius-touring-club.com/vbf/showthread.php?t=3830 They talk there about PIDs for SOC, speed, battery current (to see charging / discharging), range, etc. (terminology-wise, I don't think these are OBDII PIDs, but probably CAN arbitration IDs). The update from priusfan is interesting, as he's managed to query the BMU and got back a bunch of useful information. Si vous voulez comprendre la iMiev vous devez apprendre le français. Seems to be the bus is on standard OBDII pins, so the standard OVMS OBDII cable should work just fine. It is 500kbps, 11 bit IDs. Regards, Mark. On 29 Apr, 2013, at 2:26 PM, Nikki Gordon-Bloomfield wrote:
HI Matt, Thomas,
I'd suggest at least one of you will need some form of CAN logger. Either a purpose-built device, or something that you can connect to a serial or USB port to pull date from your car?
See the roadster logs in GitHub ;)
I'd also recommend your read the development doc here: https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/OV... :)
Nikki.
On 29 Apr 2013, at 07:22, Matt Beard <matt@beard.tv> wrote:
Hi, I have a C-Zero and would like OVMS support. I am currently considering buying a unit and would be able to help with development if/when I get one.
Matt Beard
On Monday, April 29, 2013, Thomas Bergo wrote: Hi
As a owner of a i-Miev I'm interested in OVMS support for the i-Miev/C-Zero/iOn EV.
Has anyone looked into supporting those EV?
I'm planing to start looking into adding support for those EV. And asking for help to add a vehicle plug-in module stub for those cars, so that naming and so on is correct.
Best regards Thomas B
_______________________________________________ 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 would hope that there is a way to use OVMS hardware for CAN logging. It seems pointless to need a separate CAN logger when the OVMS hardware has everything needed to log the bus. Matt On Monday, April 29, 2013, Nikki Gordon-Bloomfield wrote:
HI Matt, Thomas,
I'd suggest at least one of you will need some form of CAN logger. Either a purpose-built device, or something that you can connect to a serial or USB port to pull date from your car?
See the roadster logs in GitHub ;)
I'd also recommend your read the development doc here: https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/OV...:)
Nikki.
On 29 Apr 2013, at 07:22, Matt Beard <matt@beard.tv <javascript:_e({}, 'cvml', 'matt@beard.tv');>> wrote:
Hi, I have a C-Zero and would like OVMS support. I am currently considering buying a unit and would be able to help with development if/when I get one.
Matt Beard
On Monday, April 29, 2013, Thomas Bergo wrote:
Hi
As a owner of a i-Miev I'm interested in OVMS support for the i-Miev/C-Zero/iOn EV.
Has anyone looked into supporting those EV?
I'm planing to start looking into adding support for those EV. And asking for help to add a vehicle plug-in module stub for those cars, so that naming and so on is correct.
Best regards Thomas B
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <javascript:_e({}, 'cvml', 'OvmsDev@lists.teslaclub.hk');> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Matt, It has everything needed to _capture_, but limited storage and no serial port (ok, it has one, but it is connected to the modem). There is a sneaky way of doing it (turn on modem echo, then output the logs to the modem and capture the echo-back on the DIAG port), but that is limited in speed and very kludgy. Regards, Mark. On 29 Apr, 2013, at 3:09 PM, Matt Beard wrote:
I would hope that there is a way to use OVMS hardware for CAN logging. It seems pointless to need a separate CAN logger when the OVMS hardware has everything needed to log the bus.
Matt
On Monday, April 29, 2013, Nikki Gordon-Bloomfield wrote: HI Matt, Thomas,
I'd suggest at least one of you will need some form of CAN logger. Either a purpose-built device, or something that you can connect to a serial or USB port to pull date from your car?
See the roadster logs in GitHub ;)
I'd also recommend your read the development doc here: https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/OV... :)
Nikki.
On 29 Apr 2013, at 07:22, Matt Beard <matt@beard.tv> wrote:
Hi, I have a C-Zero and would like OVMS support. I am currently considering buying a unit and would be able to help with development if/when I get one.
Matt Beard
On Monday, April 29, 2013, Thomas Bergo wrote: Hi
As a owner of a i-Miev I'm interested in OVMS support for the i-Miev/C-Zero/iOn EV.
Has anyone looked into supporting those EV?
I'm planing to start looking into adding support for those EV. And asking for help to add a vehicle plug-in module stub for those cars, so that naming and so on is correct.
Best regards Thomas B
_______________________________________________ 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, next to the Ampera, my wife drive an I-MiEV - so i could capture anything too, if I could connect my hardware and the Scanner with a cable to the i-MiEV port. Regards, Johannes Von meinem iPad gesendet Am 29.04.2013 um 09:12 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:
Matt,
It has everything needed to _capture_, but limited storage and no serial port (ok, it has one, but it is connected to the modem).
There is a sneaky way of doing it (turn on modem echo, then output the logs to the modem and capture the echo-back on the DIAG port), but that is limited in speed and very kludgy.
Regards, Mark.
On 29 Apr, 2013, at 3:09 PM, Matt Beard wrote:
I would hope that there is a way to use OVMS hardware for CAN logging. It seems pointless to need a separate CAN logger when the OVMS hardware has everything needed to log the bus.
Matt
On Monday, April 29, 2013, Nikki Gordon-Bloomfield wrote:
HI Matt, Thomas,
I'd suggest at least one of you will need some form of CAN logger. Either a purpose-built device, or something that you can connect to a serial or USB port to pull date from your car?
See the roadster logs in GitHub ;)
I'd also recommend your read the development doc here: https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/OV... :)
Nikki.
On 29 Apr 2013, at 07:22, Matt Beard <matt@beard.tv> wrote:
Hi, I have a C-Zero and would like OVMS support. I am currently considering buying a unit and would be able to help with development if/when I get one.
Matt Beard
On Monday, April 29, 2013, Thomas Bergo wrote:
Hi
As a owner of a i-Miev I'm interested in OVMS support for the i-Miev/C-Zero/iOn EV.
Has anyone looked into supporting those EV?
I'm planing to start looking into adding support for those EV. And asking for help to add a vehicle plug-in module stub for those cars, so that naming and so on is correct.
Best regards Thomas B
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
One thought: there is _one_ way to do this. The old OVMS v1 hardware PIC board is just a small piggy-back board designed to fit on top of the modem. Without the modem, it has a TTL-level serial port available. Put it through a TTL-RS232 converter circuit (many available as plug-in modules), or a TTL-USB converter (again, modules available like this one from sparkfun). Then, roll-your-own software (not hard - just rip out everything from base ovms project, set a mask to pickup all can traffic, then output as ascii to serial port). If anyone wants to try this, just pay postage (a couple of bucks) as the boards are lying around as warranty spares. Regards, Mark On 29 Apr, 2013, at 3:12 PM, Mark Webb-Johnson wrote:
Matt,
It has everything needed to _capture_, but limited storage and no serial port (ok, it has one, but it is connected to the modem).
There is a sneaky way of doing it (turn on modem echo, then output the logs to the modem and capture the echo-back on the DIAG port), but that is limited in speed and very kludgy.
Regards, Mark.
On 29 Apr, 2013, at 3:09 PM, Matt Beard wrote:
I would hope that there is a way to use OVMS hardware for CAN logging. It seems pointless to need a separate CAN logger when the OVMS hardware has everything needed to log the bus.
Matt
On Monday, April 29, 2013, Nikki Gordon-Bloomfield wrote: HI Matt, Thomas,
I'd suggest at least one of you will need some form of CAN logger. Either a purpose-built device, or something that you can connect to a serial or USB port to pull date from your car?
See the roadster logs in GitHub ;)
I'd also recommend your read the development doc here: https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/OV... :)
Nikki.
On 29 Apr 2013, at 07:22, Matt Beard <matt@beard.tv> wrote:
Hi, I have a C-Zero and would like OVMS support. I am currently considering buying a unit and would be able to help with development if/when I get one.
Matt Beard
On Monday, April 29, 2013, Thomas Bergo wrote: Hi
As a owner of a i-Miev I'm interested in OVMS support for the i-Miev/C-Zero/iOn EV.
Has anyone looked into supporting those EV?
I'm planing to start looking into adding support for those EV. And asking for help to add a vehicle plug-in module stub for those cars, so that naming and so on is correct.
Best regards Thomas B
_______________________________________________ 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
participants (15)
-
Collin Kidder -
Håkon Markussen -
Johannes Güntert -
Kevin Sharpe ZCW -
Mark Webb-Johnson -
Mastro Gippo -
Matt Beard -
Matt Beard OVMS -
Michael Balzer -
Michael Jochum -
Nikki Gordon-Bloomfield -
Nikki Gordon-Bloomfield -
Nikolay Shishkov -
Thomas Bergo -
Tom Saxton