-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
OVMS vehicle firmware v2.2.5 has been released. It is on github now, and will make its way to Tom's download site. Change log follows:
Major changes are the experimental support for Tazzari Zero, some bug fixes and 12V work on Twizzy, and support for CAC readings in Tazzari and Tesla Roadster. The CAC is a useful indicator of the health of the vehicle's battery, and is being asked for in the Tesla Long Term Battery study. Pending App support, you can get CAC from an SMS "STAT" command.
Regards, Mark.
P.S. I haven't had time to make anything good for 1st April this year (although I did consider an experimental module for Hummer support). Anyway, please consider any bugs in this version just an April fools joke.
Code:
2013-04-01 2.2.5 Firmware 2.2.5
### Fixes for charge notification logic on VA
### Show charge, trunk and alarm notifications in DIAG mode
### Speed, parking, and general tidy-ups for VA
### Switch ambient temperature to PID 0x801f for VA
### Auto-calibration for 12V line reading
### Twizy version 2.6.1 - power line plug-in detection
### Add car_doors5 for rear doors, frunk and 12v charging
### 12v alert by MSG protocol fix
### Rework of 12V reference logic
- Filters out single peaks / misreadings
- Sends "OK" alerts if voltage level restores w/o charging
- 15 minutes calmdown before taking new ref voltage
- No alerts while car is on
### ESS SOC DIAG (for TR)
### Initial support for CAC in TR and TZ modules
### Experimental Tazzari (TZ) module
### Experimental Nissan Leaf (NL) moduleMajor changes are the experimental support for Tazzari Zero, some bug fixes and 12V work on Twizzy, and support for CAC readings in Tazzari and Tesla Roadster. The CAC is a useful indicator of the health of the vehicle's battery, and is being asked for in the Tesla Long Term Battery study. Pending App support, you can get CAC from an SMS "STAT" command.
Regards, Mark.
P.S. I haven't had time to make anything good for 1st April this year (although I did consider an experimental module for Hummer support). Anyway, please consider any bugs in this version just an April fools joke.
I went looking for this yesterday, but couldn't find it. I tried both key fob and little button, but neither showed any messages on the CAN bus we are on.
I also looked through the VDS screens but couldn't find any function to open the trunk from there.
I suspect that this may be hard-wired into the VMS.
If anyone else wants to look, here are the logs around the time the 'open trunk' actions were done (one for kefob and one for little button):
Code:
RD11,4.2876,100,88,0,6E,0,FF,FF,38
RD11,4.2879,100,89,0,FF,FF,7F,FF
RD11,4.2882,100,95,4,7,64,93,A,E,12
RD11,4.4957,402,FA,0,C3,84,2,2,87,F
RD11,4.9180,100,96,6B,0,2,21,C,0,0
RD11,4.9184,420,0,88,88
RD11,4.9187,588,0,0,84
RD11,4.9190,280,0,0,3,0,0,0,0,0
RD11,4.9192,1A0,0,0,0,0
RD11,4.9195,590,1,0,0,0,0,0,0,0
RD11,4.9876,100,88,0,6E,0,FF,FF,38
RD11,4.9879,100,89,0,FF,FF,7F,FF
RD11,4.9882,100,95,4,7,64,93,A,E,12
RD11,5.5045,402,FA,0,C3,84,2,2,87,F
RD11,5.6850,100,80,60,BB,0,64,0,A3,0
RD11,5.6853,100,81,0,0,0,DC,D6,60,51
RD11,5.6855,100,82,12
RD11,5.6858,100,83,3,0,0,9B,4,D2,9
RD11,5.6860,100,84,3,0,0,EF,3D,36,32
RD11,5.6863,100,85,1,E6,0,89,0
RD11,5.6866,100,A4,53,46,5A,52,45,38,42
RD11,5.6869,100,A5,31,35,42,33,30,30,30
RD11,5.6873,100,A6,35,36,39
RD11,5.6953,100,86,0,93,1,F0,FF,FF,FF
RD11,5.6956,100,87,21,FF,FF,0,0,0,0
RD11,5.6958,100,88,0,6E,0,FF,FF,38
RD11,5.6962,100,89,0,FF,FF,7F,FF
RD11,5.6965,100,95,4,7,64,93,A,E,12
RD11,5.6968,100,8B,7,8,82,15,7,16,1E
RD11,5.6971,100,8D,0,93,1,C9,0,C8,0
RD11,5.7131,100,93,0,FF,FF,0,0,0,0
RD11,5.7211,100,A3,14,13,0,0,0,16
RD11,5.7213,100,94,0
RD11,5.7217,100,97,0,13,0,84,2,2,0
RD11,5.7219,100,9B,FA,67,79,6,48,36,8
RD11,5.7221,100,9C,FA,87,F
RD11,5.7225,100,9D,FA,13,0,EC,E4,0,0
RD11,5.7229,100,7,64
RD11,5.9677,100,96,6B,0,2,21,C,0,0
RD11,5.9682,420,0,88,88
RD11,5.9684,588,0,0,84
RD11,5.9689,280,0,0,3,0,0,0,0,0
RD11,5.9692,1A0,0,0,0,0
RD11,5.9694,590,1,0,0,0,0,0,0,0
RD11,5.9779,400,1,1,0,0,0,0,4C,1D
RD11,6.0000,100,96,6B,80,2,21,C,0,0
RD11,6.4291,100,88,0,6E,0,FF,FF,38
RD11,6.4294,100,89,0,FF,FF,7F,FF
RD11,6.4297,100,95,4,7,64,93,A,E,12
RD11,6.5228,402,FA,0,C3,84,2,2,87,F
RD11,6.9778,100,96,6B,80,2,21,C,0,0
RD11,6.9783,420,0,88,88
RD11,6.9786,588,0,0,84
RD11,6.9789,280,0,0,3,0,0,0,0,0
RD11,6.9791,1A0,0,0,0,0
RD11,6.9795,590,1,0,0,0,0,0,0,0and:
Code:
RD11,22.0186,100,88,0,6E,0,FF,FF,38
RD11,22.0189,100,89,0,FF,FF,7F,FF
RD11,22.0192,100,95,4,7,64,93,A,E,12
RD11,22.0197,420,0,88,88
RD11,22.0200,588,0,0,84
RD11,22.0203,280,0,0,3,0,0,0,0,0
RD11,22.0205,1A0,0,0,0,0
RD11,22.0208,590,1,0,0,0,0,0,0,0
RD11,22.2086,100,96,6B,0,2,21,C,0,0OVMS CAN-USB - Call for assistance
As some of you may know, over the past couple of years OVMS has made me passionate about the concept of 'open vehicles', and in particular how smartphone control and monitoring can further the cause of EV adoption. One handicap to this is the expense and difficultly of decoding the vehicle buses.
I've recently launched a new project on github:
https://github.com/markwj/CAN-RE-Tool
With the other OVMS projects on-going, I've got too much on my plate to do this all on my own, so I'm announcing it here and hoping that some one / some people will step forward and offer to help. The main areas I need help with are finalising the hardware design and writing the PIC32 firmware - but longer-term if people want to help out with the CAN-RE-TOOL software, that would be wonderful.
Open Vehicles can sponsor the hardware for developers - so all I'm looking for is donation of your time and enthusiasm to this project. If you can't directly help with the coding / hardware hacking, then perhaps just help by spreading the news about this.
Volunteers please contact me at [email protected].
Background is that I'm pissed how costly CAN-USB adaptors are. For what they are, the cost is too high and the software is terrible. If you want the good software, the hardware cost is beyond ludicrous (thousand of dollars).
Bill of materials for these things is around US$20-US$30. Street price is US$150 upwards (excluding shipping).
I've got a hardware design (based on PIC32 and MCP2551 chips, plus a little power regulator), and I''m working with a China factory to see if we can get these down to US$50-60 (including shipping).
On the software side, I've released the CAN-RE-TOOL source code. This is perl code (but with a few libraries necessary), and pretty neat. Still very much a work-in-progress, but very usable. Some notes:
Here are some screens, to give you an idea of what is possible:
Selecting a CRTD log file as the input source:
Scrolling CAN message display (input is a CRTD log file being played back in real time):
Uniques message display (note the decodes on the right, and message count + interval towards the left):
Coverage message display (everything not '*' is unknown):
The whole point of this is to provide a system to capture messages from the can bus, work out which messages are unique for that particular car, provide a facility to decode the messages to user-readable sensors (speed, SOC, CAC, odometer, etc), and finally to allow the vehicle message documentation to be produced. It does all this today. Perl is used to make this all scriptable and extremely quick/simple to extend.
In future, I'm also interested in providing a facility to simulate a vehicle (we can only do that now by replaying a log file back out). OBDII style support work also be useful (include a PID scanner).
Regards, Mark.
As some of you may know, over the past couple of years OVMS has made me passionate about the concept of 'open vehicles', and in particular how smartphone control and monitoring can further the cause of EV adoption. One handicap to this is the expense and difficultly of decoding the vehicle buses.
I've recently launched a new project on github:
https://github.com/markwj/CAN-RE-Tool
With the other OVMS projects on-going, I've got too much on my plate to do this all on my own, so I'm announcing it here and hoping that some one / some people will step forward and offer to help. The main areas I need help with are finalising the hardware design and writing the PIC32 firmware - but longer-term if people want to help out with the CAN-RE-TOOL software, that would be wonderful.
Open Vehicles can sponsor the hardware for developers - so all I'm looking for is donation of your time and enthusiasm to this project. If you can't directly help with the coding / hardware hacking, then perhaps just help by spreading the news about this.
Volunteers please contact me at [email protected].
Background is that I'm pissed how costly CAN-USB adaptors are. For what they are, the cost is too high and the software is terrible. If you want the good software, the hardware cost is beyond ludicrous (thousand of dollars).
Bill of materials for these things is around US$20-US$30. Street price is US$150 upwards (excluding shipping).
I've got a hardware design (based on PIC32 and MCP2551 chips, plus a little power regulator), and I''m working with a China factory to see if we can get these down to US$50-60 (including shipping).
On the software side, I've released the CAN-RE-TOOL source code. This is perl code (but with a few libraries necessary), and pretty neat. Still very much a work-in-progress, but very usable. Some notes:
- It should be cross platform - just textual curses based. But, only tested on OSX so far. Linux should be easy, but not sure about Windows.
- It works with an Input-Transfrom-Output model, with optional displays. You can define the input as either a disk-based log file (CRTD format) or a CAN-USB adaptor to input from. The output can be discard, disk-based log, or CAN-USB adaptor to output to. The transforms take the input and perform optional transformations. At the start, the main transform is 'Uniques' - which find unique messages and keeps a history of updates to them. The input can be real-time or sped-up/slowed-down.
- Various real-time displays can be called up, including Cyclic and Scrolling real-time message lists, Unique message display, and coverage (which shows just the parts of the unique messages not currently understood).
- The uniques system identifies messages by a combination of CAN arbitration IDs plus optional data bytes within the message (an example being Tesla Roadster using byte #1 of ID 0x100 as a unique message).
- Decoders can be defined, to produce sensors from the messages. These decoders document the protocol and message coverage.
- Everything is implemented as plugins, so it is very very expandable. I've working on a bunch of experimental plugins to do statistical and heuristic style analysis looking for patterns in the messages captured.
- Control is via mouse, keyboard commands, or scripts on disk.
Here are some screens, to give you an idea of what is possible:
Selecting a CRTD log file as the input source:
Scrolling CAN message display (input is a CRTD log file being played back in real time):
Uniques message display (note the decodes on the right, and message count + interval towards the left):
Coverage message display (everything not '*' is unknown):
The whole point of this is to provide a system to capture messages from the can bus, work out which messages are unique for that particular car, provide a facility to decode the messages to user-readable sensors (speed, SOC, CAC, odometer, etc), and finally to allow the vehicle message documentation to be produced. It does all this today. Perl is used to make this all scriptable and extremely quick/simple to extend.
In future, I'm also interested in providing a facility to simulate a vehicle (we can only do that now by replaying a log file back out). OBDII style support work also be useful (include a PID scanner).
Regards, Mark.
A new version of our Android App has been released to Google Play. Primary differences are a change to the logos (from red to blue, to signify our support for cars other than just the Tesla Roadster), and display of CAC in the vehicle info sheet. It is available now.
A new version of the iPhone App has also been sent to Apple for approval. This one has more changes - as well as the logo changes and support for display of CAC, it also includes Open Charge Map integration (with the sponsorship and support of Zero Carbon World, and the Open Charge Map project). The map display has been enhanced to show you two circles around your car denoting your ideal and estimated ranges, as well as all EV charging stations within those ranges. It is nicely integrated to the built-in navigation - press a button and it will give you turn-by-turn directions to the selected charging station. Hopefully this can be released to the iTunes App store later this week.
A new version of the iPhone App has also been sent to Apple for approval. This one has more changes - as well as the logo changes and support for display of CAC, it also includes Open Charge Map integration (with the sponsorship and support of Zero Carbon World, and the Open Charge Map project). The map display has been enhanced to show you two circles around your car denoting your ideal and estimated ranges, as well as all EV charging stations within those ranges. It is nicely integrated to the built-in navigation - press a button and it will give you turn-by-turn directions to the selected charging station. Hopefully this can be released to the iTunes App store later this week.
"Thank You !" to all OVMS contributors. This App (and the related hardware) is much appreciated. 
:smile: Just got everything installed today.
However ...
I would consider the "Battery Temperature" ("BT") to be the most important parameter for monitoring (JMHO). And -- based on current events -- I need to call "foul" on what I am seeing.
Situation: TR1.5. Actual ambient 98F +3/-0F, very sunny hot day. Driven about 40miles (in a bit over 90 minutes with two stops) immediately after reaching a full STD Mode charge with BT=77F (sounds reasonable). Left with second BT bar lit on VDS, and returned with second BT bar lit on VDS -- not overly surprising and consistent with past experience, despite 100F ambient, and "average" driving (few if any aggressive maneuvers). (Due to thermal mass BT only rises to 3rd and 4th blue BT bar after extended time in 100F and more miles and/or more aggressive driving.) After return, App showed BT at 93F. This is unreasonable. The coolant reservoir felt warm, but not "hot". The VDS showed only second BT bar lit. Plugged in at 24A/240V; within 2 minutes BT dropped to 91F (unreasonable -- despite compressor cooling), then 90F, but staid at 90F for 15 minutes, while A/C compressor cooling was already off. Now, after 19minutes, BT=88F.
( The other temps behaved "logically", i.e. the motor & PEM increased slowly (trunk closed during 24A charging), as did the OAT -- from heat accumulating due to A/C cooling. )
I have not yet analyzed VMS logs, but will do so late today or tomorrow. However, in the meantime, I ask: what is the BT (90F above) actually ? Is it possibly the coolant temperature (it felt "warm", but not 90F) ? Is it the maximum of one temp sensor in the ESS ? If the latter is the case, would an average temperature (or reporting min/max/average) serve us better ? Is there a bug in the code ?
In the spirit of constructive feedback ... HTH.
P.S.: Does anyone know what temp ranges are represented by the bars on the VDS for BT, PEM and Motor ?
:smile: Just got everything installed today.However ...
I would consider the "Battery Temperature" ("BT") to be the most important parameter for monitoring (JMHO). And -- based on current events -- I need to call "foul" on what I am seeing.
Situation: TR1.5. Actual ambient 98F +3/-0F, very sunny hot day. Driven about 40miles (in a bit over 90 minutes with two stops) immediately after reaching a full STD Mode charge with BT=77F (sounds reasonable). Left with second BT bar lit on VDS, and returned with second BT bar lit on VDS -- not overly surprising and consistent with past experience, despite 100F ambient, and "average" driving (few if any aggressive maneuvers). (Due to thermal mass BT only rises to 3rd and 4th blue BT bar after extended time in 100F and more miles and/or more aggressive driving.) After return, App showed BT at 93F. This is unreasonable. The coolant reservoir felt warm, but not "hot". The VDS showed only second BT bar lit. Plugged in at 24A/240V; within 2 minutes BT dropped to 91F (unreasonable -- despite compressor cooling), then 90F, but staid at 90F for 15 minutes, while A/C compressor cooling was already off. Now, after 19minutes, BT=88F.
( The other temps behaved "logically", i.e. the motor & PEM increased slowly (trunk closed during 24A charging), as did the OAT -- from heat accumulating due to A/C cooling. )
I have not yet analyzed VMS logs, but will do so late today or tomorrow. However, in the meantime, I ask: what is the BT (90F above) actually ? Is it possibly the coolant temperature (it felt "warm", but not 90F) ? Is it the maximum of one temp sensor in the ESS ? If the latter is the case, would an average temperature (or reporting min/max/average) serve us better ? Is there a bug in the code ?
In the spirit of constructive feedback ... HTH.
P.S.: Does anyone know what temp ranges are represented by the bars on the VDS for BT, PEM and Motor ?
Last edited:
djp
Model 3 Performance
Each brick has its own temperature sensor and the Roadster has data monitoring for max brick temperature, min brick temperature, avg brick temperature and coolant temperature. Based on what you're describing it sounds like OMVS is picking up the max brick reading.
The temperature OVMS shows is the one from CAN bus message ID#100 B1=0xA3.
Temps
B1=0xA3
B2=Tpem (celcius)
B3=Tmotor (celcius)
B7=Tbattery (celcius)
An example message is:
100 A3 2D 33 00 00 00 1A ->VDS TEMPS (Tpem 45) (Tmotor 51) (Tbattery 26)
As you can see, only the 3 temps are shown and the other bytes are zero.
We do know that the Tesla Roadster has:
Tcoolant
tmaxBrick
Tmin (ESS)
Tmax (ESS)
Tave (ESS)
TbrickMax
but some of these are only available if advanced diagnostics screens are enabled on the CAN bus (so we tend to stay away from those where possible).
The A3 message is the easiest to pick up. I suspect that it is showing TmaxBrick (aka TbrickMax). It is definitely not Tcoolant (which we can see drop dramatically during a low-amperage range-mode cooldown charge).
Never really had the inclination to dive deeper into this, as the value we are showing seems quite good as an indication of what we worry about. But, it will be very easy to see - as the Tmin, Tmax, Tave and TmaxBrick should vary quite considerably - and I'll tell you next time I go for a drive (probably tomorrow).
Regards, Mark.
Temps
B1=0xA3
B2=Tpem (celcius)
B3=Tmotor (celcius)
B7=Tbattery (celcius)
An example message is:
100 A3 2D 33 00 00 00 1A ->VDS TEMPS (Tpem 45) (Tmotor 51) (Tbattery 26)
As you can see, only the 3 temps are shown and the other bytes are zero.
We do know that the Tesla Roadster has:
Tcoolant
tmaxBrick
Tmin (ESS)
Tmax (ESS)
Tave (ESS)
TbrickMax
but some of these are only available if advanced diagnostics screens are enabled on the CAN bus (so we tend to stay away from those where possible).
The A3 message is the easiest to pick up. I suspect that it is showing TmaxBrick (aka TbrickMax). It is definitely not Tcoolant (which we can see drop dramatically during a low-amperage range-mode cooldown charge).
Never really had the inclination to dive deeper into this, as the value we are showing seems quite good as an indication of what we worry about. But, it will be very easy to see - as the Tmin, Tmax, Tave and TmaxBrick should vary quite considerably - and I'll tell you next time I go for a drive (probably tomorrow).
Regards, Mark.
Ok ... so it appears we are seeing TmaxBrick. The next question revolves around the CoolDown feature for version 2.5.2. What will be the parameter that controls termination of the CoolDown ? Could Tmax represent a value too far out of line with Tave ? Would it be a "waste" to continue cooling ? Will there be adequate safeguards against drawing down SOC ( for example being plugged in to 120V, or not being plugged in (if that's possible) ) ?
It also appears that the Temps (as reported by OVMS ) are stale after the car sitting overnight. What safeguards will 2.5.2 have to avoid this ? ( Or is there a FEATURE I have missed to avoid stale temps ? )
BTW, this Roadster 1.5 with 2.3.2/TR/V2 does not report CAC ... should it ?
P.S.: Regarding "waste": Even after the Roadster had terminated A/C compressor cooling and (later) reached full STD Mode, OVMS still reported BT of 88F. 88F (31C) is not really a "bad number", but care should be used to avoid "over-cooling". ( My assumption is that the 88F was *NOT* a stale number while still charging, because I observed the Motor Temp changing (up and down -- remember this is a 1.5 ), but the "morning after" BT was also 88F, while actual TmaxBrick was 27C (80.6F).
It also appears that the Temps (as reported by OVMS ) are stale after the car sitting overnight. What safeguards will 2.5.2 have to avoid this ? ( Or is there a FEATURE I have missed to avoid stale temps ? )
BTW, this Roadster 1.5 with 2.3.2/TR/V2 does not report CAC ... should it ?
P.S.: Regarding "waste": Even after the Roadster had terminated A/C compressor cooling and (later) reached full STD Mode, OVMS still reported BT of 88F. 88F (31C) is not really a "bad number", but care should be used to avoid "over-cooling". ( My assumption is that the 88F was *NOT* a stale number while still charging, because I observed the Motor Temp changing (up and down -- remember this is a 1.5 ), but the "morning after" BT was also 88F, while actual TmaxBrick was 27C (80.6F).
Last edited:
I live in a part of China and tend to avoid anything with a number 4 in it. I'm not superstitious, but (when in Rome)...
- - - Updated - - -
At the moment, cooldown is controlled by a minimum-temperature (maxbrick) and maximum time (charge duration) parameter. Defaults for these are in ovms.h:
ovms.h:#define COOLDOWN_DEFAULT_TEMPLIMIT 31
ovms.h:#define COOLDOWN_DEFAULT_TIMELIMIT 60
but can be controlled with parameter #15 (PARAM_COOLDOWN) as templimit:timelimit.
Personally, I am concerned with TmaxBrick, not the average. I want to try to cooldown until the hottest part of the pack is as cool as I want. The cooldown itself is done at 13A, so should not load up too much SOC% in the timelimit time.
Regarding stale temps, the car will turn off its own temperature-monitoring subsystem when it goes to sleep - the temperatures in the app will appear stale. If you want to check those, the only way is to wake up the car (either by physically pressing a door handle / opening charge port, etc, or remotely by tapping on the boot of the car in the App and choosing 'wakeup'). Whenever the car is charging, it is awake and temperatures are available, so this isn't a problem for cooldown.
Regards, Mark.
Sounds good
Is the 13A something of a (british/HK) household current limit, or enforced for distinguishing a cooldown cycle (good idea) ? Or some other reason ? If the VDS was limited to 12A, will it still enforce 13A, and will it revert to 12A for manually initiated charging ?When is 2.5.2 release expected ?
Thanks to your PMs I have learned to turn on CAN-WRITE and can now wake-up the car to get current temps. By-the-way, other than OAT, while CAN-WRITE was OFF, even opening a door did *NOT* update the PEM/Motor/Batt temps -- neither did opening charge-port, even though its status was updated to "white" on the App. Only "major messing" with the VDS did that (while CAN-WRITE was off).
CAC: Again thanks to your PMs, I have CAC in "STAT?" responses so far. Won't expect to see it in the Android App until I drive it tomorrow and complete a charge.
( Thank You ! )
Sounds good
When is 2.5.2 release expected ?
Thanks to your PMs I have learned to turn on CAN-WRITE and can now wake-up the car to get current temps. By-the-way, other than OAT, while CAN-WRITE was OFF, even opening a door did *NOT* update the PEM/Motor/Batt temps -- neither did opening charge-port, even though its status was updated to "white" on the App. Only "major messing" with the VDS did that (while CAN-WRITE was off).
CAC: Again thanks to your PMs, I have CAC in "STAT?" responses so far. Won't expect to see it in the Android App until I drive it tomorrow and complete a charge.
( Thank You ! )
The 13A setting was suggested as a good compromise - too little current and the HVAC won't engage, to much and it charges too much (or costs too much for TOU users).
I can't give anything definitive on 2.5.x yet, as there is so much going into it that it is taking a long time to work out the bugs. It is pretty feature-complete now (just finishing the timezone support for timed charges), and I managed to squish a large number of bugs out at the weekend, so hopefully I can get a binary release of 2.5.3 out for wider testing reasonably soon.
Similar threads
