- OvmsDev - Open Vehicles

Twizy 45 & disabled battery limits
by Michael Balzer 18 Apr '16

18 Apr '16

@Twizy 45 drivers: If some of you decided to try the battery limit deactivation, I'd appreciate some data feedback on this. In the user guide I wrote the STOP warning does come on driving only, not on braking. In the meantime I discovered it comes on braking as well: it seems the threshold to activate it is exceeding the current battery limit by more than 5000 W in any direction -- on a T80. I would like to know if the same threshold applies to a T45, if the controlling SDOs differ and how the T45 performs in "unlimited mode". If you don't want to make this public, contact me at dexter(a)dexters-web.de. Thanks & regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Re: [Ovmsdev] OvmsDev Digest, Vol 51, Issue 1
by John Link 12 Apr '16

12 Apr '16

Hello, Since the DNS change I can't seem to get curl to work any more to retrieve data from the server. this is the error message I am getting: curl: (51) SSL: certificate subject name (www.openvehicles.com) does not match target host name 'api.openvehicles.com' Does your ssl cert need to be updated for the new host name? Thanks On Mon, Apr 4, 2016 at 9:00 PM, <ovmsdev-request(a)lists.teslaclub.hk> wrote: > Send OvmsDev mailing list submissions to > ovmsdev(a)lists.teslaclub.hk > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > or, via email, send a message with subject or body 'help' to > ovmsdev-request(a)lists.teslaclub.hk > > You can reach the person managing the list at > ovmsdev-owner(a)lists.teslaclub.hk > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OvmsDev digest..." > > > Today's Topics: > > 1. api.openvehicles.com (Mark Webb-Johnson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 5 Apr 2016 11:51:01 +0800 > From: Mark Webb-Johnson <mark(a)webb-johnson.net> > Subject: [Ovmsdev] api.openvehicles.com > To: OVMS Developers <OvmsDev(a)lists.teslaclub.hk> > Message-ID: <FB00A027-1D7A-4859-95F9-EB1C0212536F(a)webb-johnson.net> > Content-Type: text/plain; charset="utf-8" > > > I?ll be moving all users of either IP 54.197.255.127 or DNS name > tmc.openvehicles.com <http://tmc.openvehicles.com/> to DNS name > api.openvehicles.com <http://api.openvehicles.com/> later today. Also > switching DNS record for tmc.openvehicles.com < > http://tmc.openvehicles.com/> to be api.openvehicles.com < > http://api.openvehicles.com/>. This will be done by the server at > 54.197.255.127 issuing an OVMS protocol message to change parameter > PARAM_SERVERIP (#4) to ?api.openvehicles.com?. > > In general, going forward, using DNS name api.openvehicles.com < > http://api.openvehicles.com/>, on both the car module and Apps, will be > the recommended approach. That will allow us to do server maintenance and > migrations without requiring everyone to change their settings. > > If you would like to test this before the actual event later today, then > just change your car module parameter #4 (SERVERIP) to > api.openvehicles.com <http://api.openvehicles.com/> now. > > Regards, Mark. > >

2 1

Kia Soul user guide
by Michael Balzer 11 Apr '16

11 Apr '16

FYI: the Kia Soul team just submitted the first version of their user guide, see https://github.com/openvehicles/Open-Vehicle-Monitoring-System/tree/master/… Thanks, Jörg & Tom, great work! @Geir: can you create a pull request for the firmware version matching the guide? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 7

Source Code Formatting
by Tom Parker 10 Apr '16

10 Apr '16

Hi, I've made a few improvements to the nissan leaf code (see https://carrott.org/git/Open-Vehicle-Monitoring-System.git/log/refs/heads/n… and the climate control branch on the same server ) and I noticed it had a mix of code styles. I'd like to reformat it to be consistent (mostly because I can't write consistently formatted code without a code formatter) and wanted to know if there is an agreed format to use -- there is nothing worse than trying to trace changes through a code formatting war in the history? I'm currently using the default mplabx code format configuration which suits me but is different from most of the rest of the OVMS code. Is there a configuration for mplabx I can import? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

3 4

api.openvehicles.com
by Mark Webb-Johnson 04 Apr '16

04 Apr '16

I’ll be moving all users of either IP 54.197.255.127 or DNS name tmc.openvehicles.com <http://tmc.openvehicles.com/> to DNS name api.openvehicles.com <http://api.openvehicles.com/> later today. Also switching DNS record for tmc.openvehicles.com <http://tmc.openvehicles.com/> to be api.openvehicles.com <http://api.openvehicles.com/>. This will be done by the server at 54.197.255.127 issuing an OVMS protocol message to change parameter PARAM_SERVERIP (#4) to ‘api.openvehicles.com’. In general, going forward, using DNS name api.openvehicles.com <http://api.openvehicles.com/>, on both the car module and Apps, will be the recommended approach. That will allow us to do server maintenance and migrations without requiring everyone to change their settings. If you would like to test this before the actual event later today, then just change your car module parameter #4 (SERVERIP) to api.openvehicles.com <http://api.openvehicles.com/> now. Regards, Mark.

1 0

v2.8.5
by Mark Webb-Johnson 27 Mar '16

27 Mar '16

OK, everything looks good to go and I am going to give manufacturing go-ahead for a batch using SIM808 modules tonight. The v2.8.5 firmware is required for SIM808 support, and I’ve built binaries of those ready for release. Please play with this, and let us know if you find any issues. Regards, Mark. 2016-03-14 2.8.5 Firmware 2.8.5 SIM808 GSM/GPS module support # Fix for Twizy build w/o BATTMON # Twizy: ideal range calculated with temperature influence approximation # Twizy: Battery capacity estimation # Twizy: Charge start restarts SOC window (to get most recent BMS SOC) # Twizy: Charge interruption no longer restarts power sums & SOC window # Added vehicle_version to net msg "F" # New vehicle: Kia Soul EV, initial version 0.1 (alpha/untested) # Kia Soul: VIN, car status, doors & charging status, SOC, estimated range, speed # Framework: OBDII polling support for modes 02, 10 & 21 # Kia Soul: DEBUG diag output fixed for SMS size limit # Kia Soul: ISR optimization - OBD diag data init & length debugging # Kia Soul: Buffer overflow protection for OBDII multi frame polls # Kia Soul: Init CAN RX filter 1 to avoid noise triggers # Twizy: optional current limit modification # Added compiler switch OVMS_NO_CRASHDEBUG # Twizy V3.7.0: - CFG POWER: max current control, higher torque & power levels # Framework v2.8.2: DIAG mode: support backspace & ctrl-a / ctrl-c (= abort/clear) # Framework v2.8.2: DIAG mode perl clients added # Framework v2.8.2: DIAG mode documentation extended # Add hints on 0x100/0x96 and 0x400/0x01 # Framework: Fixed base64decode(), removed bug workarounds # Framework: base64encode(): return pointer to end of base64 string # Framework: New net_assert_caller(): check caller, fallback to REGPHONE # Framework: net_put RAM redirection now uses net_buf[] # Framework: Code cleanup, size and stack depth optimization # Framework: Fix: stack overflow/underflow flags cleared after crash # Framework: Perl diagmode clients: missing license info added # Twizy: Flux map optimization # Twizy: Fix: "CA?" outputs ETR SOC if ETR range is zero # Twizy: CAN control bits to disable emergency reset, kickdown & autopower # Twizy: Flux & saturation maps added to documentation # Twizy: Updated SDO list & limits # MPLABX 3.1x support, and OVMS_BUILDCONFIG to show selected build config in version strings # Add pics and docs on Tesla Model S new style DIAG connector seen in late 2015 cars onwards # Re-work GPS initialisation for SIM808 # Use AT+CGPSRST=0 for cold start of GPS # Fix SMS VERSION command

4 5

Twizy firmware 3.7.2 & Android App 3.11.3
by Michael Balzer 25 Mar '16

25 Mar '16

http://dexters-web.de/downloads/en http://dexters-web.de/ovms-twizy-3.7.2-text_73.en.htm Twizy V3.7.2: - Command "CA?" now shows SOC ETR if range ETR is zero - CAN write control bitmap - Motor and PEM temperatures fixed - Charger temperature added http://dexters-web.de/openvehicleapp-release-3.11.3-text_67.en.htm V3.11.3 (2016-03-25): - Added charger temperature - Added battery power limits to power chart - Update of chart library, axis label optimizations Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Activating a sleeping Gen 1 Leaf
by Tom Parker 21 Mar '16

21 Mar '16

Quick update, I contorted myself into the driver's foot well of my right hand drive Japanese domestic manufacture 2012 gen 1 Leaf and unplugged the TCU. I can confirm that connecting pin 1 (battery +ve) to pin 11 (EV System Activation Request) causes a beep from the front of the car and a few relay clicks. I didn't try to activate climate control to confirm that it works, I'll try that later this week and if it does, hook it up to the OVMS. Splice into the loom in the cramped conditions under the dashboard won't be fun. I wouldn't be totally surprised if the TCU does the charge timer wakeup, so preserving the existing circuit is a good idea. http://www.mynissanleaf.com/viewtopic.php?p=438109#p438109 says the Gen 2 Leaf doesn't need this circuit, and the same source describes CAN message to do the wakeup. If anyone wants to test that I can add that message to see if it works. Has anyone seen a message on the EV CAN Bus that would distinguish a Gen 1 from a Gen 2?

2 4

Re: [Ovmsdev] Twizzy Rental Service
by Mark Webb-Johnson 13 Mar '16

13 Mar '16

An update on SIM808. It is just a stop-gap solution, but it buys us some time. The changes I’ve made / problems I’ve had: Power button needs to be held for 1 second to power down/up the modem (SIM908 was much faster). Not a bad issue, but it did waste a week going back and forth trying to find the cause. The SIM808 doesn’t echo LineFeed characters. That is a pain for DIAG mode console, but doesn’t affect anything else. Only workaround possible is to use a terminal program that can map CR->CRLF, or CF->LF (and live with the horrible display in DIAG mode). We’ll just develop on SIM908 modules or use a fancy terminal emulator. I guess if people are using scripts to talk to DIAG mode, they may need some tuning if they are expecting CRLF and just getting CR now. GPS initialisation (this is the biggy - more below). Build profile in version string. This is just a simple fix to include a #define in the build profiles, and to include that where we show the version string. It means that as well as the version of firmware, we can now see the build profile. Helpful for support of new users. The biggest issue has been with GPS initialisation. Looking at the current code: #ifdef OVMS_INTERNALGPS // Using internal SIM908 GPS: rom char NET_INIT1[] = "AT+CGPSPWR=1;+CGPSRST=0;+CSMINS?\r"; rom char NET_REQGPS[] = "AT+CGPSINF=2;+CGPSINF=64;+CGPSPWR=1\r"; #else // Using external GPS from car: rom char NET_INIT1[] = "AT+CSMINS?\r"; #endif So, if the build profile includes OVMS_INTERNALGPS (ie; one or more vehicles in the profile require GPS), then we use a big sequence of initialisations "AT+CGPSPWR=1;+CGPSRST=0;+CSMINS?\r”. We have two issues with this: We’re powering up the GPS, even if the actual vehicle we selected doesn’t need SIM908/808 GPS. That costs watts - and with my new fancy bench power supply I got for OVMS v3 development (ok, cheap chinese ebay) I can now see exactly how much ;-). The SIM808 randomly doesn’t like AT+CGPSPWR=1 and in particular seems to hate it 100% of the time it is included with other options. You get an ERROR response back from the modem, and as this is done in NET_STATE_DOINIT, it looks like a SIM card error (but is nothing to do with SIM card). We just never saw AT+CGPSPWR=1 fail on SIM908. Now, as well as the #defined OVMS_INTERNALGPS to enable the SIM908/808 GPS, we’ve also got NET_FN_INTERNALGPS in net_fnbits which is set during vehicle module initialisation. The first brings in the code, the second should turn it on. Except it doesn’t. The first one turns it on. Accordingly, I’m having to change the net.{h,c} layer to split off GPS initialisation into its own states and use a simple AT+CGPSPWR=1 for vehicles that require SIM908/808 GPS and AT+CGPSPWR=0 for vehicles that don’t. I’ve taken the opportunity to switch from using OVMS_INTERNALGPS to using NET_FN_INTERNALGPS in net_fnbits as the decision as to whether to power up the SIM908/808 GPS or not. Building and testing that has taken me the most time. It is almost done, and I should be able to commit the code soon. Production firmware then goes to the manufacturer in China, and we give the go-ahead for the production run. We should have the modules back in stock towards the end of March / first thing in April. Regards, Mark. P.S. I can actually recommend that cheap(ish) chinese ebay power supply. It’s available from various eBay sellers, or banggood <http://www.banggood.com/CPS-3205C-0-32V-0-5A-Portable-Adjustable-DC-Power-S…>. Controls are precise, output is rock solid, ammeter is as accurate as my multi-meter, and it is built like a tank.

2 5

Re: [Ovmsdev] OvmsDev Digest, Vol 49, Issue 25
by Thor 25 Feb '16

25 Feb '16

nice! Sorry can't help with the developing, since it's not my field of programming. But have you considered setting up a donation for leaf development? there has been a demand for leaf-alternative a long time, and the devs here that worked on it have left. One of the devs Jermey has no leaf no more, so no pushing for the leaf. It's very important that the leaf development now pushes forward to get somewhere and not halt before we get there. How will your code be with the new hardware that is comming? Anyways. I did a poll last year on how many that where interested in changing to a opensource alternative for carwings/nissan connect. and like 30-40 said yes. I estimate that atleast 60 leafs are interested in norway. ps: I think the number for opensource alternative might be even higher now after the Nissan disaster: http://www.troyhunt.com/2016/02/controlling-vehicle-features-of-nissan.html… I tested the security hole yesterday, and it was wide open. today it's partialy closed. look at the response time before nissan acted on it. it's a disaster. On 21 February 2016 at 05:00, <ovmsdev-request(a)lists.teslaclub.hk> wrote: > Send OvmsDev mailing list submissions to > ovmsdev(a)lists.teslaclub.hk > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > or, via email, send a message with subject or body 'help' to > ovmsdev-request(a)lists.teslaclub.hk > > You can reach the person managing the list at > ovmsdev-owner(a)lists.teslaclub.hk > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OvmsDev digest..." > > > Today's Topics: > > 1. Nissan Leaf Remote Climate Control (Tom Parker) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 21 Feb 2016 12:16:35 +1300 > From: Tom Parker <tom(a)carrott.org> > Subject: [Ovmsdev] Nissan Leaf Remote Climate Control > To: OVMS Developers <ovmsdev(a)lists.teslaclub.hk> > Message-ID: <56C8F3D3.2090406(a)carrott.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > I got remote climate control on & off working, but only during charge. > I've abused the alert and homelink commands for now: > > > https://carrott.org/git/Open-Vehicle-Monitoring-System.git/commitdiff/84a65… > > I can't promise I won't force-push into this branch until it's ready for > merging, so if you are from the future you may need to look at the > branch > > https://carrott.org/git/Open-Vehicle-Monitoring-System.git/shortlog/refs/he… > > > Tested on my 2012 Gen 1 JDM Leaf with Carwings (Apparently the TCU and > hence Carwings doesn't work in New Zealand due to incompatible cell > network). > > Next is to investigate the wakeup logic line between the TCU and VCU. > I've got > http://docslide.us/documents/nissan-leaf-2011-2012-ev-control-system.html > which > describes two EV System Activation Request Signal connections (on page > 88), both on the VCU E63 connector. Pin 96 is from the charger (on page > 84) and pin 84 is from the TCU (on page 85). > > I'm guessing I can observe how the charger wakes up the VCU and add some > GPIO output hardware to the OVMS do the same thing to on the TCU line. > > Remote charging will probably work the same way, but I can't test it > since the only way I can currently get the car to pay attention to these > messages is for it to be charging already. > > > ------------------------------ > > _______________________________________________ > OvmsDev mailing list > OvmsDev(a)lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > > > End of OvmsDev Digest, Vol 49, Issue 25 > *************************************** >

2 1