I'm so looking forward to being able to easily get the CAC value! In our Roadster, the CAC seems to update when the SOC settles, which is typically about 10 minutes after a charge or drive, although sometimes it takes longer. So it would be perfect to query the CAC: - 30 minutes after a charge - 30 minutes after the car is turned off - when the car is turned on within 30 minutes of a charge or turn off If you don't want to mess with that complexity, (a) and (b) are pretty effective. Based on what I've observed, I would expect (b) and the following (c) to always return the same result for a Roadster, bu it would be interesting to confirm that. Tom on 4/1/13 3:59 AM, Mark Webb-Johnson wrote:

This is now in my car, and running well.

For CAC, I had:

rx msg S 66,K,222,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,0

then, I started a charge, and now get:

rx msg S 66,K,223,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,15694

That's what I would expect - the code will poll for latest CAC whenever (a) a charge starts, (b) the car is turned on, or (c) the car is turned off.

Regards, Mark.

On 1 Apr, 2013, at 5:30 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

Back from the brinkŠ Good grief, there is some nasty stuff coming out of China now.

I managed to spend some time on OVMS firmware today, and built v2.2.5. Change log is:

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) module

All is in github.

I haven't run it in my car yet, but it tests out fine on the bench. It is going into my car in a few minutes time.

Major changes are the experimental support for Tazzari, some bug fixes and 12V work on Twizzy, and support for CAC readings in Tazzari and Tesla Roadster (including protocol extensions to report back to apps).

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.

_______________________________________________ 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

First off: is there currently any difference between production and experimental firmware?

Only for Tesla Roadster - Experimental has the digital speedo option.

On the Ampera there is no more temperature and no more charging indicator.

Urgh. Michael: Can you test this and see if anything was broken?

On the Tazzari there is no value at all. What could be wrong?

Now, that is going to be hard. On my desktop simulator, it worked fine. Can you double check vehicle type is TZ? Do you have any way of getting a CAN bus dump while the OVMS module is connected? That would allow us to see if the polling is working or not. Regards, Mark. On 2 Apr, 2013, at 2:40 AM, Patrick Kapsch <patrick.kapsch@mac.com> wrote:

Mark, I've flashed the 2.2.5 production version to the Tazzari Module as well as the Ampera module. First off: is there currently any difference between production and experimental firmware? On the Ampera there is no more temperature and no more charging indicator. On the Tazzari there is no value at all. What could be wrong?

Patrick

Am 01.04.2013 um 19:16 schrieb Tom Saxton <tom@idleloop.com>:

...

I'm so looking forward to being able to easily get the CAC value!

In our Roadster, the CAC seems to update when the SOC settles, which is typically about 10 minutes after a charge or drive, although sometimes it takes longer. So it would be perfect to query the CAC:

- 30 minutes after a charge - 30 minutes after the car is turned off - when the car is turned on within 30 minutes of a charge or turn off

If you don't want to mess with that complexity, (a) and (b) are pretty effective. Based on what I've observed, I would expect (b) and the following (c) to always return the same result for a Roadster, bu it would be interesting to confirm that.

Tom

on 4/1/13 3:59 AM, Mark Webb-Johnson wrote:

...

This is now in my car, and running well.

For CAC, I had:

rx msg S 66,K,222,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,0

then, I started a charge, and now get:

rx msg S 66,K,223,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,15694

That's what I would expect - the code will poll for latest CAC whenever (a) a charge starts, (b) the car is turned on, or (c) the car is turned off.

Regards, Mark.

On 1 Apr, 2013, at 5:30 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

Back from the brinkŠ Good grief, there is some nasty stuff coming out of China now.

I managed to spend some time on OVMS firmware today, and built v2.2.5. Change log is:

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) module

All is in github.

I haven't run it in my car yet, but it tests out fine on the bench. It is going into my car in a few minutes time.

Major changes are the experimental support for Tazzari, some bug fixes and 12V work on Twizzy, and support for CAC readings in Tazzari and Tesla Roadster (including protocol extensions to report back to apps).

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.

_______________________________________________ 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

Tom, After 24 hours in my car, it has been 156.94 through 2 charges and 2 drives. I'm not sure how Tesla calculates this, but it seems very stable. It was also 156.99 just three weeks ago - Car doesn't like sitting idle while I'm sick :-( There are some app changes being made at the moment - once those are done, I'll get it added to the Info screen on the Apps. Regards, Mark. On 2 Apr, 2013, at 1:16 AM, Tom Saxton <tom@idleloop.com> wrote:

I'm so looking forward to being able to easily get the CAC value!

In our Roadster, the CAC seems to update when the SOC settles, which is typically about 10 minutes after a charge or drive, although sometimes it takes longer. So it would be perfect to query the CAC:

- 30 minutes after a charge - 30 minutes after the car is turned off - when the car is turned on within 30 minutes of a charge or turn off

If you don't want to mess with that complexity, (a) and (b) are pretty effective. Based on what I've observed, I would expect (b) and the following (c) to always return the same result for a Roadster, bu it would be interesting to confirm that.

Tom

on 4/1/13 3:59 AM, Mark Webb-Johnson wrote:

...

This is now in my car, and running well.

For CAC, I had:

rx msg S 66,K,222,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,0

then, I started a charge, and now get:

rx msg S 66,K,223,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,15694

That's what I would expect - the code will poll for latest CAC whenever (a) a charge starts, (b) the car is turned on, or (c) the car is turned off.

Regards, Mark.

On 1 Apr, 2013, at 5:30 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

Back from the brinkŠ Good grief, there is some nasty stuff coming out of China now.

I managed to spend some time on OVMS firmware today, and built v2.2.5. Change log is:

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) module

All is in github.

I haven't run it in my car yet, but it tests out fine on the bench. It is going into my car in a few minutes time.

Major changes are the experimental support for Tazzari, some bug fixes and 12V work on Twizzy, and support for CAC readings in Tazzari and Tesla Roadster (including protocol extensions to report back to apps).

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.

_______________________________________________ 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

Tricky. It is just a tap into the modem comms. But, there is an expansion connector on the board itself. The part labelled "HEADER 9X2" is a standard layout for expansion plugs, or holes are there to directly solder to the board. The I/O is 5v digital on those pins, and there are quite a few spare I/O pins that you can use. There is also GND, +12V and +5V if you need power. If you have a use for this, it would be quite simple to control some of these pins on/off on command (similar to the way home link works). Regards, Mark. On 2 Apr, 2013, at 8:56 PM, Nikki Gordon-Bloomfield <nikki@littlecollie.com> wrote:

Guys,

Is there any scope for enabling IO from the diagnostic port to operate an relay, either directly or through some opto-isolators?

Nikki. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Nikki, Technically, it seems fine. When you get home with such an arrangement, you would need to plug in two cables? One for the charger and the other for OVMS (connecting the relay to the charger)? Seems bit onerous. Is there any way of making this wireless? The problem is keeping it simple - we just want digital on/off signals not serial control (otherwise X10 modules or something like that would be easy). I got given an electric imp development kit - which is about US$40 (for the board and the imp) and gives wifi. The digital I/O of that could go to the OVMS module and allow on/off control of Internet services. Couple that with an Internet-controlled power socket (belkin?). Or, the existing OVMS 3G modem and server connection could be used to control. Or are you thinking of wiring up the relay to the car side power inlet? Regards, Mark. On 14 Apr, 2013, at 7:01 PM, Nikki Gordon-Bloomfield <nikki@littlecollie.com> wrote:

I've been thinking about this some more, and I think I've come up with a plan.

If I could pull the IO out there and connect it to a relay driver chip, I think it could be possible to give Twizy owners the same remote on/off charge capabilities as the Tesla.

My thoughts:

1) use output one from OVMS to drive a relay which is NO. When the IO output from OVMS goes high, we use that to close the relay, and let power flow, turning on the charger. When it goes low, the relay opens, and the charger turns off.

2) use a second IO on the OVMS to sense when a switch is pressed on the dash. This allows us to start/stop charging from the vehicle using a simple push-to-make switch.

3) using a home instance of perl and OVMS client software, write a cron job which turns on the car's charging on/off at a given time every day, or have perl listen for SOC and shut off charging when we reach 80% SOC.

My goal? To give Twizy owners the ability to use time-of-use metering to get cheaper charging of the Twizy at night-time. And also to allow users to set 80% SOC rather than 100% SOC. It would require folks to run a perl script all the time on their home computers though.

Nikki.

On 2 Apr 2013, at 14:05, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

Tricky. It is just a tap into the modem comms.

But, there is an expansion connector on the board itself.

The part labelled "HEADER 9X2" is a standard layout for expansion plugs, or holes are there to directly solder to the board. The I/O is 5v digital on those pins, and there are quite a few spare I/O pins that you can use.

There is also GND, +12V and +5V if you need power.

If you have a use for this, it would be quite simple to control some of these pins on/off on command (similar to the way home link works).

Regards, Mark.

<PastedGraphic-1.pdf>

<20120814-boarddesign.pdf>

On 2 Apr, 2013, at 8:56 PM, Nikki Gordon-Bloomfield <nikki@littlecollie.com> wrote:

...

Guys,

Is there any scope for enabling IO from the diagnostic port to operate an relay, either directly or through some opto-isolators?

Nikki. _______________________________________________ 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

Aha - that now makes sense. Is the socket there easy to hack? Presumably you'd just need to relay the live wire. You could even wire it normally-closed so OVMS has to be present to stop it from charging. I'll have a look at the wiring diagram. It should be fairly easy to pick say 4 digital inputs, 4 digital outputs and 2 ADs and support them directly in utils.h/utils.c and via net_msg commands. Regards, Mark. On 14 Apr, 2013, at 11:08 PM, Nikki Gordon-Bloomfield wrote:

Hi Mark,

I'm thinking car side rather than socket side. So you only plug one thing in. ;)

Nikki

Sent from my iPhone

On 14 Apr 2013, at 15:37, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

Nikki,

Technically, it seems fine.

When you get home with such an arrangement, you would need to plug in two cables? One for the charger and the other for OVMS (connecting the relay to the charger)? Seems bit onerous.

Is there any way of making this wireless? The problem is keeping it simple - we just want digital on/off signals not serial control (otherwise X10 modules or something like that would be easy). I got given an electric imp development kit - which is about US$40 (for the board and the imp) and gives wifi. The digital I/O of that could go to the OVMS module and allow on/off control of Internet services. Couple that with an Internet-controlled power socket (belkin?). Or, the existing OVMS 3G modem and server connection could be used to control.

Or are you thinking of wiring up the relay to the car side power inlet?

Regards, Mark.

On 14 Apr, 2013, at 7:01 PM, Nikki Gordon-Bloomfield <nikki@littlecollie.com> wrote:

...

I've been thinking about this some more, and I think I've come up with a plan.

If I could pull the IO out there and connect it to a relay driver chip, I think it could be possible to give Twizy owners the same remote on/off charge capabilities as the Tesla.

My thoughts:

1) use output one from OVMS to drive a relay which is NO. When the IO output from OVMS goes high, we use that to close the relay, and let power flow, turning on the charger. When it goes low, the relay opens, and the charger turns off.

2) use a second IO on the OVMS to sense when a switch is pressed on the dash. This allows us to start/stop charging from the vehicle using a simple push-to-make switch.

3) using a home instance of perl and OVMS client software, write a cron job which turns on the car's charging on/off at a given time every day, or have perl listen for SOC and shut off charging when we reach 80% SOC.

My goal? To give Twizy owners the ability to use time-of-use metering to get cheaper charging of the Twizy at night-time. And also to allow users to set 80% SOC rather than 100% SOC. It would require folks to run a perl script all the time on their home computers though.

Nikki.

On 2 Apr 2013, at 14:05, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

Tricky. It is just a tap into the modem comms.

But, there is an expansion connector on the board itself.

The part labelled "HEADER 9X2" is a standard layout for expansion plugs, or holes are there to directly solder to the board. The I/O is 5v digital on those pins, and there are quite a few spare I/O pins that you can use.

There is also GND, +12V and +5V if you need power.

If you have a use for this, it would be quite simple to control some of these pins on/off on command (similar to the way home link works).

Regards, Mark.

<PastedGraphic-1.pdf>

<20120814-boarddesign.pdf>

On 2 Apr, 2013, at 8:56 PM, Nikki Gordon-Bloomfield <nikki@littlecollie.com> wrote:

...

Guys,

Is there any scope for enabling IO from the diagnostic port to operate an relay, either directly or through some opto-isolators?

Nikki. _______________________________________________ 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

Michael, For the clock, can we use the GPS clock? I know that some cellular networks also support time services, but I'm appalled that they are often several minutes inaccurate. The virtual car model actually has a car_time (second counter) which is supported on the Tesla Roadster. For other cars, we could standardise this and have it periodically synced to gps time (when available). I think the main thing we are missing is time zone offset (which tomsax was also asking for) - my concern is things like daylight savings time complicating things. Regards, Mark. On 15 Apr, 2013, at 4:01 AM, Michael Balzer wrote:

Mark, that reminds me: a clock would be nice on the next hardware to enable cron jobs on the module.

Until then, we could introduce some time info sent from the server to the car.

Nikki, this kind of charge control could also be used to sync the charge to solar panel peak output time.

Regards, Michael

Am 14.04.2013 13:01, schrieb Nikki Gordon-Bloomfield:

...

I've been thinking about this some more, and I think I've come up with a plan.

If I could pull the IO out there and connect it to a relay driver chip, I think it could be possible to give Twizy owners the same remote on/off charge capabilities as the Tesla.

My thoughts:

1) use output one from OVMS to drive a relay which is NO. When the IO output from OVMS goes high, we use that to close the relay, and let power flow, turning on the charger. When it goes low, the relay opens, and the charger turns off.

2) use a second IO on the OVMS to sense when a switch is pressed on the dash. This allows us to start/stop charging from the vehicle using a simple push-to-make switch.

3) using a home instance of perl and OVMS client software, write a cron job which turns on the car's charging on/off at a given time every day, or have perl listen for SOC and shut off charging when we reach 80% SOC.

My goal? To give Twizy owners the ability to use time-of-use metering to get cheaper charging of the Twizy at night-time. And also to allow users to set 80% SOC rather than 100% SOC. It would require folks to run a perl script all the time on their home computers though.

Nikki.

On 2 Apr 2013, at 14:05, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

Tricky. It is just a tap into the modem comms.

But, there is an expansion connector on the board itself.

The part labelled "HEADER 9X2" is a standard layout for expansion plugs, or holes are there to directly solder to the board. The I/O is 5v digital on those pins, and there are quite a few spare I/O pins that you can use.

There is also GND, +12V and +5V if you need power.

If you have a use for this, it would be quite simple to control some of these pins on/off on command (similar to the way home link works).

Regards, Mark.

<PastedGraphic-1.pdf>

<20120814-boarddesign.pdf>

On 2 Apr, 2013, at 8:56 PM, Nikki Gordon-Bloomfield <nikki@littlecollie.com> wrote:

...

Guys,

Is there any scope for enabling IO from the diagnostic port to operate an relay, either directly or through some opto-isolators?

Nikki. _______________________________________________ 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

Time is easy (hours*3600 + mins*60 + secs), but date is tricky. How about this: http://aa.usno.navy.mil/faq/docs/JD_Formula.php INTEGER FUNCTION JD (YEAR,MONTH,DAY) C C---COMPUTES THE JULIAN DATE (JD) GIVEN A GREGORIAN CALENDAR C DATE (YEAR,MONTH,DAY). C INTEGER YEAR,MONTH,DAY,I,J,K C I= YEAR J= MONTH K= DAY C JD= K-32075+1461*(I+4800+(J-14)/12)/4+367*(J-2-(J-14)/12*12) 2 /12-3*((I+4900+(J-14)/12)/100)/4 C RETURN END Fortran! Brilliant :-) I feel so nostalgic... Regards, Mark. On 16 Apr, 2013, at 3:41 AM, Michael Balzer wrote:

Mark,

thanks for the reminder: of course, the GPS clock should be usable. In fact I already gave it a try once but had to put it back, because the C18 libs seem to lack support for time functions. So we just need to port at least the basic time functions to convert textual representation to UNIX time.

Regards, Michael

Am 15.04.2013 02:54, schrieb Mark Webb-Johnson:

...

Michael,

For the clock, can we use the GPS clock? I know that some cellular networks also support time services, but I'm appalled that they are often several minutes inaccurate.

The virtual car model actually has a car_time (second counter) which is supported on the Tesla Roadster. For other cars, we could standardise this and have it periodically synced to gps time (when available).

I think the main thing we are missing is time zone offset (which tomsax was also asking for) - my concern is things like daylight savings time complicating things.

Regards, Mark.

On 15 Apr, 2013, at 4:01 AM, Michael Balzer wrote:

...

Mark, that reminds me: a clock would be nice on the next hardware to enable cron jobs on the module.

Until then, we could introduce some time info sent from the server to the car.

Nikki, this kind of charge control could also be used to sync the charge to solar panel peak output time.

Regards, Michael

Am 14.04.2013 13:01, schrieb Nikki Gordon-Bloomfield:

...

I've been thinking about this some more, and I think I've come up with a plan.

If I could pull the IO out there and connect it to a relay driver chip, I think it could be possible to give Twizy owners the same remote on/off charge capabilities as the Tesla.

My thoughts:

1) use output one from OVMS to drive a relay which is NO. When the IO output from OVMS goes high, we use that to close the relay, and let power flow, turning on the charger. When it goes low, the relay opens, and the charger turns off.

2) use a second IO on the OVMS to sense when a switch is pressed on the dash. This allows us to start/stop charging from the vehicle using a simple push-to-make switch.

3) using a home instance of perl and OVMS client software, write a cron job which turns on the car's charging on/off at a given time every day, or have perl listen for SOC and shut off charging when we reach 80% SOC.

My goal? To give Twizy owners the ability to use time-of-use metering to get cheaper charging of the Twizy at night-time. And also to allow users to set 80% SOC rather than 100% SOC. It would require folks to run a perl script all the time on their home computers though.

Nikki.

On 2 Apr 2013, at 14:05, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

Tricky. It is just a tap into the modem comms.

But, there is an expansion connector on the board itself.

The part labelled "HEADER 9X2" is a standard layout for expansion plugs, or holes are there to directly solder to the board. The I/O is 5v digital on those pins, and there are quite a few spare I/O pins that you can use.

There is also GND, +12V and +5V if you need power.

If you have a use for this, it would be quite simple to control some of these pins on/off on command (similar to the way home link works).

Regards, Mark.

<PastedGraphic-1.pdf>

<20120814-boarddesign.pdf>

On 2 Apr, 2013, at 8:56 PM, Nikki Gordon-Bloomfield <nikki@littlecollie.com> wrote:

...

Guys,

Is there any scope for enabling IO from the diagnostic port to operate an relay, either directly or through some opto-isolators?

Nikki. _______________________________________________ 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

-- 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

Mark, thanks for the feedback, can you provide more detail? I.e. what alerts at which voltages and charging states. Thanks, Michael Am 02.04.2013 14:48, schrieb Mark Webb-Johnson:

I was getting 12v alerts in my roadster. I don't think the new logic is compatible with the roadster battery behaviour.

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

I had taken the higher voltage during driving into account. What I missed was that the module could be turned on or reset while the car is turned on. It would then take the first 12v reading as the first reference, resulting in the first ref being too high. I just changed the initialization logic to also wait 15 minutes after boot / reset before taking the reference. Can you please try again? @all: not sure if we will need the 12V alert system on the roadster at all, so feedback from other car types will be helpful to refine any remaining problems. Thanks! Michael Am 02.04.2013 15:27, schrieb Mark Webb-Johnson:

Here are the last 2.

Seems to be when I drive the voltage is higher than when I park (car goes to sleep).

Regards, Mark

On 2 Apr, 2013, at 9:23 PM, Michael Balzer <dexter@expeedo.de> wrote:

...

Mark,

thanks for the feedback, can you provide more detail? I.e. what alerts at which voltages and charging states.

Thanks, Michael

Am 02.04.2013 14:48, schrieb Mark Webb-Johnson:

...

I was getting 12v alerts in my roadster. I don't think the new logic is compatible with the roadster battery behaviour. -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

---

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

Mark, besides using the DIAG command you can also see voltage and reference in the net message "D". I posted the Twizy V2.6.3 update 5 days ago on the german Twizy forum. That did not include your V2.2.6 framework changes, but they should have no effect on the Twizy version. There have been no bug reports up to now... but maybe Nikki will find some :-) Regards, Michael Am 03.04.2013 03:12, schrieb Mark Webb-Johnson:

Michael,

I'll try to rebuild tonight. I see the DIAG SMS command shows the line voltage and reference - so even though alerts are now off in the roadster we can still check the levels.

Regarding the Twizy support: is this v2.2.6 now ok for you? Everything stable?

Regards, Mark.

On 3 Apr, 2013, at 2:13 AM, Michael Balzer wrote:

...

I had taken the higher voltage during driving into account. What I missed was that the module could be turned on or reset while the car is turned on. It would then take the first 12v reading as the first reference, resulting in the first ref being too high. I just changed the initialization logic to also wait 15 minutes after boot / reset before taking the reference.

Can you please try again?

@all: not sure if we will need the 12V alert system on the roadster at all, so feedback from other car types will be helpful to refine any remaining problems.

Thanks! Michael

Am 02.04.2013 15:27, schrieb Mark Webb-Johnson:

...

Here are the last 2.

Seems to be when I drive the voltage is higher than when I park (car goes to sleep).

Regards, Mark

On 2 Apr, 2013, at 9:23 PM, Michael Balzer<dexter@expeedo.de> wrote:

...

Mark,

thanks for the feedback, can you provide more detail? I.e. what alerts at which voltages and charging states.

Thanks, Michael

Am 02.04.2013 14:48, schrieb Mark Webb-Johnson:

...

I was getting 12v alerts in my roadster. I don't think the new logic is compatible with the roadster battery behaviour. -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

---

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 <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

Links to the v2.2.6 firmware are now up on my firmware download page: http://www.idleloop.com/tesla/ovms/ The release notes link points to the entry for v2.2.5, which is probably close enough. Tom on 4/2/13 5:48 AM, Mark Webb-Johnson wrote:

I was getting 12v alerts in my roadster. I don't think the new logic is compatible with the roadster battery behaviour.

Anyway, I've rolled v2.2.6 with the following changes:

2013-04-02 2.2.6 Firmware 2.2.6 ## Volt Ampera fixes (from Michael) ## Support net_fnbits NET_FN_12VMONITOR and NET_FN_SOCMONITOR to allow vehicle module to control what is monitored

I brought in the Volt Ampera fixes pending from Michael (some changes to the source of SOC).

I also added NET_FN_12VMONITOR and NET_FN_SOCMONITOR to net_fnbits, to allow the vehicle modules to turn on/off those monitoring. I changed the vehicle modules appropriately (in particular 12VMONITOR is off in the Tesla Roadster, and SOCMONITOR is off in the Volt/Ampera).

Now testing this v2.2.6 in my car, but it will likely be 24 hours before I know if it is behaving better.

Regards, Mark.

On 1 Apr, 2013, at 6:59 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

This is now in my car, and running well.

For CAC, I had:

rx msg S 66,K,222,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,0

then, I started a charge, and now get:

rx msg S 66,K,223,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,15694

That's what I would expect - the code will poll for latest CAC whenever (a) a charge starts, (b) the car is turned on, or (c) the car is turned off.

Regards, Mark.

On 1 Apr, 2013, at 5:30 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

Back from the brinkŠ Good grief, there is some nasty stuff coming out of China now.

I managed to spend some time on OVMS firmware today, and built v2.2.5. Change log is:

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) module

All is in github.

I haven't run it in my car yet, but it tests out fine on the bench. It is going into my car in a few minutes time.

Major changes are the experimental support for Tazzari, some bug fixes and 12V work on Twizzy, and support for CAC readings in Tazzari and Tesla Roadster (including protocol extensions to report back to apps).

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.

_______________________________________________ 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

Nikki, for the Twizy: I think the V2 "developer version" still does not include the battery monitor -- I had to add the compiler switch again after my last local merge. If you compile yourself, check the configuration for the OVMS_TWIZY_BATTMON define. Or let me know if you need a precompiled image. Regards, Michael Am 02.04.2013 22:08, schrieb Nikki Gordon-Bloomfield:

I'll be updating it tomorrow!

Sent from my iPhone

On 2 Apr 2013, at 20:35, Tom Saxton <tom@idleloop.com> wrote:

...

Links to the v2.2.6 firmware are now up on my firmware download page:

http://www.idleloop.com/tesla/ovms/

The release notes link points to the entry for v2.2.5, which is probably close enough.

Tom

on 4/2/13 5:48 AM, Mark Webb-Johnson wrote:

...

I was getting 12v alerts in my roadster. I don't think the new logic is compatible with the roadster battery behaviour.

Anyway, I've rolled v2.2.6 with the following changes:

2013-04-02 2.2.6 Firmware 2.2.6 ## Volt Ampera fixes (from Michael) ## Support net_fnbits NET_FN_12VMONITOR and NET_FN_SOCMONITOR to allow vehicle module to control what is monitored

I brought in the Volt Ampera fixes pending from Michael (some changes to the source of SOC).

I also added NET_FN_12VMONITOR and NET_FN_SOCMONITOR to net_fnbits, to allow the vehicle modules to turn on/off those monitoring. I changed the vehicle modules appropriately (in particular 12VMONITOR is off in the Tesla Roadster, and SOCMONITOR is off in the Volt/Ampera).

Now testing this v2.2.6 in my car, but it will likely be 24 hours before I know if it is behaving better.

Regards, Mark.

On 1 Apr, 2013, at 6:59 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

This is now in my car, and running well.

For CAC, I had:

rx msg S 66,K,222,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,0

then, I started a charge, and now get:

rx msg S 66,K,223,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,15694

That's what I would expect - the code will poll for latest CAC whenever (a) a charge starts, (b) the car is turned on, or (c) the car is turned off.

Regards, Mark.

On 1 Apr, 2013, at 5:30 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

Back from the brinkŠ Good grief, there is some nasty stuff coming out of China now.

I managed to spend some time on OVMS firmware today, and built v2.2.5. Change log is:

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) module

All is in github.

I haven't run it in my car yet, but it tests out fine on the bench. It is going into my car in a few minutes time.

Major changes are the experimental support for Tazzari, some bug fixes and 12V work on Twizzy, and support for CAC readings in Tazzari and Tesla Roadster (including protocol extensions to report back to apps).

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.

_______________________________________________ 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

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

Nikki, firmware zip attached. Regards, Michael Am 03.04.2013 12:17, schrieb Nikki Gordon-Bloomfield:

Hi Michael,

Because of time constraints, that'd be grand. Could you zip up the firmware and send over?

Cheers,

Nikki.

On 3 Apr 2013, at 10:54, Michael Balzer <dexter@expeedo.de> wrote:

...

Nikki,

for the Twizy: I think the V2 "developer version" still does not include the battery monitor -- I had to add the compiler switch again after my last local merge.

If you compile yourself, check the configuration for the OVMS_TWIZY_BATTMON define.

Or let me know if you need a precompiled image.

Regards, Michael

Am 02.04.2013 22:08, schrieb Nikki Gordon-Bloomfield:

...

I'll be updating it tomorrow!

Sent from my iPhone

On 2 Apr 2013, at 20:35, Tom Saxton <tom@idleloop.com> wrote:

...

Links to the v2.2.6 firmware are now up on my firmware download page:

http://www.idleloop.com/tesla/ovms/

The release notes link points to the entry for v2.2.5, which is probably close enough.

Tom

on 4/2/13 5:48 AM, Mark Webb-Johnson wrote:

...

I was getting 12v alerts in my roadster. I don't think the new logic is compatible with the roadster battery behaviour.

Anyway, I've rolled v2.2.6 with the following changes:

2013-04-02 2.2.6 Firmware 2.2.6 ## Volt Ampera fixes (from Michael) ## Support net_fnbits NET_FN_12VMONITOR and NET_FN_SOCMONITOR to allow vehicle module to control what is monitored

I brought in the Volt Ampera fixes pending from Michael (some changes to the source of SOC).

I also added NET_FN_12VMONITOR and NET_FN_SOCMONITOR to net_fnbits, to allow the vehicle modules to turn on/off those monitoring. I changed the vehicle modules appropriately (in particular 12VMONITOR is off in the Tesla Roadster, and SOCMONITOR is off in the Volt/Ampera).

Now testing this v2.2.6 in my car, but it will likely be 24 hours before I know if it is behaving better.

Regards, Mark.

On 1 Apr, 2013, at 6:59 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

This is now in my car, and running well.

For CAC, I had:

rx msg S 66,K,222,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,0

then, I started a charge, and now get:

rx msg S 66,K,223,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,15694

That's what I would expect - the code will poll for latest CAC whenever (a) a charge starts, (b) the car is turned on, or (c) the car is turned off.

Regards, Mark.

On 1 Apr, 2013, at 5:30 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

> Back from the brinkŠ Good grief, there is some nasty stuff coming out of > China now. > > I managed to spend some time on OVMS firmware today, and built v2.2.5. > Change log is: > > 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) module > > All is in github. > > I haven't run it in my car yet, but it tests out fine on the bench. It is > going into my car in a few minutes time. > > Major changes are the experimental support for Tazzari, some bug fixes and > 12V work on Twizzy, and support for CAC readings in Tazzari and Tesla > Roadster (including protocol extensions to report back to apps). > > 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. > > _______________________________________________ > 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 -- 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

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

Michael, I just checked, and that OVMS_TWIZY_BATTMON takes ram from 426 bytes free to 208. A little bit scary, given that I am about to add the trip logging functions. I'm really not sure what happens with the stack, and if it is counted in those 208 bytes. Can we get to zero? But, I see this as a useful function for Twizy owners. How about I create a new firmware config V2_FullTwizy that includes just the Twizy module but also OVMS_TWIZY_BATTMON? Regards, Mark. On 3 Apr, 2013, at 5:54 PM, Michael Balzer <dexter@expeedo.de> wrote:

Nikki,

for the Twizy: I think the V2 "developer version" still does not include the battery monitor -- I had to add the compiler switch again after my last local merge.

If you compile yourself, check the configuration for the OVMS_TWIZY_BATTMON define.

Or let me know if you need a precompiled image.

Regards, Michael

Am 02.04.2013 22:08, schrieb Nikki Gordon-Bloomfield:

...

I'll be updating it tomorrow!

Sent from my iPhone

On 2 Apr 2013, at 20:35, Tom Saxton <tom@idleloop.com> wrote:

...

Links to the v2.2.6 firmware are now up on my firmware download page:

http://www.idleloop.com/tesla/ovms/

The release notes link points to the entry for v2.2.5, which is probably close enough.

Tom

on 4/2/13 5:48 AM, Mark Webb-Johnson wrote:

...

I was getting 12v alerts in my roadster. I don't think the new logic is compatible with the roadster battery behaviour.

Anyway, I've rolled v2.2.6 with the following changes:

2013-04-02 2.2.6 Firmware 2.2.6 ## Volt Ampera fixes (from Michael) ## Support net_fnbits NET_FN_12VMONITOR and NET_FN_SOCMONITOR to allow vehicle module to control what is monitored

I brought in the Volt Ampera fixes pending from Michael (some changes to the source of SOC).

I also added NET_FN_12VMONITOR and NET_FN_SOCMONITOR to net_fnbits, to allow the vehicle modules to turn on/off those monitoring. I changed the vehicle modules appropriately (in particular 12VMONITOR is off in the Tesla Roadster, and SOCMONITOR is off in the Volt/Ampera).

Now testing this v2.2.6 in my car, but it will likely be 24 hours before I know if it is behaving better.

Regards, Mark.

On 1 Apr, 2013, at 6:59 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

This is now in my car, and running well.

For CAC, I had:

rx msg S 66,K,222,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,0

then, I started a charge, and now get:

rx msg S 66,K,223,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,15694

That's what I would expect - the code will poll for latest CAC whenever (a) a charge starts, (b) the car is turned on, or (c) the car is turned off.

Regards, Mark.

On 1 Apr, 2013, at 5:30 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

Back from the brinkŠ Good grief, there is some nasty stuff coming out of China now.

I managed to spend some time on OVMS firmware today, and built v2.2.5. Change log is:

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) module

All is in github.

I haven't run it in my car yet, but it tests out fine on the bench. It is going into my car in a few minutes time.

Major changes are the experimental support for Tazzari, some bug fixes and 12V work on Twizzy, and support for CAC readings in Tazzari and Tesla Roadster (including protocol extensions to report back to apps).

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.

_______________________________________________ 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

-- 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

Mark, I once looked up the stack issue and found it as being reserved outside the variable RAM, so basically we can get to zero. I think your memory map linker option also confirmed this. I and the other german users have had this config in our Twizys for many months now without any problems. A special config is an option if there is a problem, but that means Twizy OVMS users will need to flash their modules if they want full functionality. I think we should deliver factory OVMS with full functionality if possible. Also, as all battery monitor ram usage is in the overlay section, the other car modules should not be affected (and can use that space for their own purposes later on). How about an extended test from all developers using the full featured firmware to see if there are really any problems with this -- I don't think so. Regards, Michael Am 03.04.2013 14:19, schrieb Mark Webb-Johnson:

Michael,

I just checked, and that OVMS_TWIZY_BATTMON takes ram from 426 bytes free to 208. A little bit scary, given that I am about to add the trip logging functions. I'm really not sure what happens with the stack, and if it is counted in those 208 bytes. Can we get to zero?

But, I see this as a useful function for Twizy owners.

How about I create a new firmware config V2_FullTwizy that includes just the Twizy module but also OVMS_TWIZY_BATTMON?

Regards, Mark.

On 3 Apr, 2013, at 5:54 PM, Michael Balzer <dexter@expeedo.de> wrote:

...

Nikki,

for the Twizy: I think the V2 "developer version" still does not include the battery monitor -- I had to add the compiler switch again after my last local merge.

If you compile yourself, check the configuration for the OVMS_TWIZY_BATTMON define.

Or let me know if you need a precompiled image.

Regards, Michael

Am 02.04.2013 22:08, schrieb Nikki Gordon-Bloomfield:

...

I'll be updating it tomorrow!

Sent from my iPhone

On 2 Apr 2013, at 20:35, Tom Saxton <tom@idleloop.com> wrote:

...

Links to the v2.2.6 firmware are now up on my firmware download page:

http://www.idleloop.com/tesla/ovms/

The release notes link points to the entry for v2.2.5, which is probably close enough.

Tom

on 4/2/13 5:48 AM, Mark Webb-Johnson wrote:

...

I was getting 12v alerts in my roadster. I don't think the new logic is compatible with the roadster battery behaviour.

Anyway, I've rolled v2.2.6 with the following changes:

2013-04-02 2.2.6 Firmware 2.2.6 ## Volt Ampera fixes (from Michael) ## Support net_fnbits NET_FN_12VMONITOR and NET_FN_SOCMONITOR to allow vehicle module to control what is monitored

I brought in the Volt Ampera fixes pending from Michael (some changes to the source of SOC).

I also added NET_FN_12VMONITOR and NET_FN_SOCMONITOR to net_fnbits, to allow the vehicle modules to turn on/off those monitoring. I changed the vehicle modules appropriately (in particular 12VMONITOR is off in the Tesla Roadster, and SOCMONITOR is off in the Volt/Ampera).

Now testing this v2.2.6 in my car, but it will likely be 24 hours before I know if it is behaving better.

Regards, Mark.

On 1 Apr, 2013, at 6:59 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

This is now in my car, and running well.

For CAC, I had:

rx msg S 66,K,222,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,0

then, I started a charge, and now get:

rx msg S 66,K,223,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,15694

That's what I would expect - the code will poll for latest CAC whenever (a) a charge starts, (b) the car is turned on, or (c) the car is turned off.

Regards, Mark.

On 1 Apr, 2013, at 5:30 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

> Back from the brinkŠ Good grief, there is some nasty stuff coming out of > China now. > > I managed to spend some time on OVMS firmware today, and built v2.2.5. > Change log is: > > 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) module > > All is in github. > > I haven't run it in my car yet, but it tests out fine on the bench. It is > going into my car in a few minutes time. > > Major changes are the experimental support for Tazzari, some bug fixes and > 12V work on Twizzy, and support for CAC readings in Tazzari and Tesla > Roadster (including protocol extensions to report back to apps). > > 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. > > _______________________________________________ > 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 -- 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

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

Nikki, no, that's too far below average... just kidding ;) FYI: my usage averages at only 90 miles/week, top average in the german forum has been around 300 miles/week. I read about a german pizza delivery service using several Twizys each now around 15.000 miles -- they needed to replace their brake discs... recuperation is not strong enough for pizza boys it seems ;) Thanks! Michael Am 03.04.2013 15:03, schrieb Nikki Gordon-Bloomfield:

Michael, Mark.

I'm going to be doing about 150 miles a week in my Twizy from next week. Does this count as being a thorough enough test? ;)

Nikki.

On 3 Apr 2013, at 13:49, Michael Balzer <dexter@expeedo.de> wrote:

...

Mark,

I once looked up the stack issue and found it as being reserved outside the variable RAM, so basically we can get to zero. I think your memory map linker option also confirmed this. I and the other german users have had this config in our Twizys for many months now without any problems.

A special config is an option if there is a problem, but that means Twizy OVMS users will need to flash their modules if they want full functionality. I think we should deliver factory OVMS with full functionality if possible.

Also, as all battery monitor ram usage is in the overlay section, the other car modules should not be affected (and can use that space for their own purposes later on).

How about an extended test from all developers using the full featured firmware to see if there are really any problems with this -- I don't think so.

Regards, Michael

Am 03.04.2013 14:19, schrieb Mark Webb-Johnson:

...

Michael,

I just checked, and that OVMS_TWIZY_BATTMON takes ram from 426 bytes free to 208. A little bit scary, given that I am about to add the trip logging functions. I'm really not sure what happens with the stack, and if it is counted in those 208 bytes. Can we get to zero?

But, I see this as a useful function for Twizy owners.

How about I create a new firmware config V2_FullTwizy that includes just the Twizy module but also OVMS_TWIZY_BATTMON?

Regards, Mark.

On 3 Apr, 2013, at 5:54 PM, Michael Balzer <dexter@expeedo.de> wrote:

...

Nikki,

for the Twizy: I think the V2 "developer version" still does not include the battery monitor -- I had to add the compiler switch again after my last local merge.

If you compile yourself, check the configuration for the OVMS_TWIZY_BATTMON define.

Or let me know if you need a precompiled image.

Regards, Michael

Am 02.04.2013 22:08, schrieb Nikki Gordon-Bloomfield:

...

I'll be updating it tomorrow!

Sent from my iPhone

On 2 Apr 2013, at 20:35, Tom Saxton <tom@idleloop.com> wrote:

...

Links to the v2.2.6 firmware are now up on my firmware download page:

http://www.idleloop.com/tesla/ovms/

The release notes link points to the entry for v2.2.5, which is probably close enough.

Tom

on 4/2/13 5:48 AM, Mark Webb-Johnson wrote:

> I was getting 12v alerts in my roadster. I don't think the new logic is > compatible with the roadster battery behaviour. > > Anyway, I've rolled v2.2.6 with the following changes: > > 2013-04-02 2.2.6 Firmware 2.2.6 > ## Volt Ampera fixes (from Michael) > ## Support net_fnbits NET_FN_12VMONITOR and > NET_FN_SOCMONITOR to allow vehicle module to control what is monitored > > I brought in the Volt Ampera fixes pending from Michael (some changes to the > source of SOC). > > I also added NET_FN_12VMONITOR and NET_FN_SOCMONITOR to net_fnbits, to allow > the vehicle modules to turn on/off those monitoring. I changed the vehicle > modules appropriately (in particular 12VMONITOR is off in the Tesla Roadster, > and SOCMONITOR is off in the Volt/Ampera). > > Now testing this v2.2.6 in my car, but it will likely be 24 hours before I > know if it is behaving better. > > Regards, Mark. > > On 1 Apr, 2013, at 6:59 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote: > >> This is now in my car, and running well. >> >> For CAC, I had: >> >> rx msg S 66,K,222,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,0 >> >> then, I started a charge, and now get: >> >> rx msg S 66,K,223,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,15694 >> >> That's what I would expect - the code will poll for latest CAC whenever (a) a >> charge starts, (b) the car is turned on, or (c) the car is turned off. >> >> Regards, Mark. >> >> On 1 Apr, 2013, at 5:30 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote: >> >>> Back from the brinkŠ Good grief, there is some nasty stuff coming out of >>> China now. >>> >>> I managed to spend some time on OVMS firmware today, and built v2.2.5. >>> Change log is: >>> >>> 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) module >>> >>> All is in github. >>> >>> I haven't run it in my car yet, but it tests out fine on the bench. It is >>> going into my car in a few minutes time. >>> >>> Major changes are the experimental support for Tazzari, some bug fixes and >>> 12V work on Twizzy, and support for CAC readings in Tazzari and Tesla >>> Roadster (including protocol extensions to report back to apps). >>> >>> 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. >>> >>> _______________________________________________ >>> 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 -- 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 -- 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

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

Michael, I'll add it to the V2_experimental config, then we'll see how we get on (particularly when we add the charge/drive logs). Regards, Mark. On 3 Apr, 2013, at 8:49 PM, Michael Balzer wrote:

Mark,

I once looked up the stack issue and found it as being reserved outside the variable RAM, so basically we can get to zero. I think your memory map linker option also confirmed this. I and the other german users have had this config in our Twizys for many months now without any problems.

A special config is an option if there is a problem, but that means Twizy OVMS users will need to flash their modules if they want full functionality. I think we should deliver factory OVMS with full functionality if possible.

Also, as all battery monitor ram usage is in the overlay section, the other car modules should not be affected (and can use that space for their own purposes later on).

How about an extended test from all developers using the full featured firmware to see if there are really any problems with this -- I don't think so.

Regards, Michael

Am 03.04.2013 14:19, schrieb Mark Webb-Johnson:

...

Michael,

I just checked, and that OVMS_TWIZY_BATTMON takes ram from 426 bytes free to 208. A little bit scary, given that I am about to add the trip logging functions. I'm really not sure what happens with the stack, and if it is counted in those 208 bytes. Can we get to zero?

But, I see this as a useful function for Twizy owners.

How about I create a new firmware config V2_FullTwizy that includes just the Twizy module but also OVMS_TWIZY_BATTMON?

Regards, Mark.

On 3 Apr, 2013, at 5:54 PM, Michael Balzer <dexter@expeedo.de> wrote:

...

Nikki,

for the Twizy: I think the V2 "developer version" still does not include the battery monitor -- I had to add the compiler switch again after my last local merge.

If you compile yourself, check the configuration for the OVMS_TWIZY_BATTMON define.

Or let me know if you need a precompiled image.

Regards, Michael

Am 02.04.2013 22:08, schrieb Nikki Gordon-Bloomfield:

...

I'll be updating it tomorrow!

Sent from my iPhone

On 2 Apr 2013, at 20:35, Tom Saxton <tom@idleloop.com> wrote:

...

Links to the v2.2.6 firmware are now up on my firmware download page:

http://www.idleloop.com/tesla/ovms/

The release notes link points to the entry for v2.2.5, which is probably close enough.

Tom

on 4/2/13 5:48 AM, Mark Webb-Johnson wrote:

...

I was getting 12v alerts in my roadster. I don't think the new logic is compatible with the roadster battery behaviour.

Anyway, I've rolled v2.2.6 with the following changes:

2013-04-02 2.2.6 Firmware 2.2.6 ## Volt Ampera fixes (from Michael) ## Support net_fnbits NET_FN_12VMONITOR and NET_FN_SOCMONITOR to allow vehicle module to control what is monitored

I brought in the Volt Ampera fixes pending from Michael (some changes to the source of SOC).

I also added NET_FN_12VMONITOR and NET_FN_SOCMONITOR to net_fnbits, to allow the vehicle modules to turn on/off those monitoring. I changed the vehicle modules appropriately (in particular 12VMONITOR is off in the Tesla Roadster, and SOCMONITOR is off in the Volt/Ampera).

Now testing this v2.2.6 in my car, but it will likely be 24 hours before I know if it is behaving better.

Regards, Mark.

On 1 Apr, 2013, at 6:59 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

> This is now in my car, and running well. > > For CAC, I had: > > rx msg S 66,K,222,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,0 > > then, I started a charge, and now get: > > rx msg S 66,K,223,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,15694 > > That's what I would expect - the code will poll for latest CAC whenever (a) a > charge starts, (b) the car is turned on, or (c) the car is turned off. > > Regards, Mark. > > On 1 Apr, 2013, at 5:30 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote: > >> Back from the brinkŠ Good grief, there is some nasty stuff coming out of >> China now. >> >> I managed to spend some time on OVMS firmware today, and built v2.2.5. >> Change log is: >> >> 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) module >> >> All is in github. >> >> I haven't run it in my car yet, but it tests out fine on the bench. It is >> going into my car in a few minutes time. >> >> Major changes are the experimental support for Tazzari, some bug fixes and >> 12V work on Twizzy, and support for CAC readings in Tazzari and Tesla >> Roadster (including protocol extensions to report back to apps). >> >> 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. >> >> _______________________________________________ >> 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 -- 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

-- 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

Tom, Thanks. I've updated the release notes to v2.2.6 to match what you have. So far v2.2.6 seems good for me. CAC is working, and no more 12v alerts on the Tesla Roadster. By the way, I'm working hard towards a stable v2.2.x. The factory is doing a new production run, and needs an up-to-date firmware to flash before shipping to Fasttech (and end-users). What we have looks good, but I just want to (a) stabilise Twizy support so that it is production-ok with existing functionality (seems ok now), (b) stabilise Volt/Ampera so that it is production-ok for monitoring functionality, and (c) get the VDS error messages reporting back from the Tesla Roadster (as well as a framework for this in other cars). Tom's charge-time predictor code will have to wait until this v2.2.x is stable, as that will need quite a bit of testing. I'll put the code in as soon as v2.2.x is out. Now that we have CAC, it should be relatively simple. Regards, Mark. On 3 Apr, 2013, at 3:35 AM, Tom Saxton wrote:

Links to the v2.2.6 firmware are now up on my firmware download page:

http://www.idleloop.com/tesla/ovms/

The release notes link points to the entry for v2.2.5, which is probably close enough.

Tom

on 4/2/13 5:48 AM, Mark Webb-Johnson wrote:

...

I was getting 12v alerts in my roadster. I don't think the new logic is compatible with the roadster battery behaviour.

Anyway, I've rolled v2.2.6 with the following changes:

2013-04-02 2.2.6 Firmware 2.2.6 ## Volt Ampera fixes (from Michael) ## Support net_fnbits NET_FN_12VMONITOR and NET_FN_SOCMONITOR to allow vehicle module to control what is monitored

I brought in the Volt Ampera fixes pending from Michael (some changes to the source of SOC).

I also added NET_FN_12VMONITOR and NET_FN_SOCMONITOR to net_fnbits, to allow the vehicle modules to turn on/off those monitoring. I changed the vehicle modules appropriately (in particular 12VMONITOR is off in the Tesla Roadster, and SOCMONITOR is off in the Volt/Ampera).

Now testing this v2.2.6 in my car, but it will likely be 24 hours before I know if it is behaving better.

Regards, Mark.

On 1 Apr, 2013, at 6:59 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

This is now in my car, and running well.

For CAC, I had:

rx msg S 66,K,222,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,0

then, I started a charge, and now get:

rx msg S 66,K,223,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,15694

That's what I would expect - the code will poll for latest CAC whenever (a) a charge starts, (b) the car is turned on, or (c) the car is turned off.

Regards, Mark.

On 1 Apr, 2013, at 5:30 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

Back from the brink… Good grief, there is some nasty stuff coming out of China now.

I managed to spend some time on OVMS firmware today, and built v2.2.5. Change log is:

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) module

All is in github.

I haven't run it in my car yet, but it tests out fine on the bench. It is going into my car in a few minutes time.

Major changes are the experimental support for Tazzari, some bug fixes and 12V work on Twizzy, and support for CAC readings in Tazzari and Tesla Roadster (including protocol extensions to report back to apps).

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.

_______________________________________________ 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