May 2016 - OvmsDev - Open Vehicles

OVMS logo
by Mark Webb-Johnson 06 Jun '17

06 Jun '17

We need to change the OVMS logo, to better reflect the vehicle independence. The existing logo is too much Tesla. Felix has kindly prepared a couple of options for us, attached below. My preference is for the one with the car outline (even though it retains a hint of Tesla), as it emphasizes the vehicle comms aspect. This is quite urgent, as the Teslive people are pushing for artwork. What do you guys/gals think? Regards, Mark

8 14

OVMS v3
by Mastro Gippo 20 May '17

20 May '17

Hi all, I'd like to resurrect an old conversation. As we know, the current PIC is quickly running out of resources and maybe it's time to switch to a better platform. Two CAN buses are now desirable too. A microSD slot and direct USB connectivity wouldn't hurt either. I will probably have to design a similar hardware for myself, so I'd like to contribute to the OVMS by sharing the HW platform if you want; no strings attached of course, if you decide that there's no need for the upgrade, I'll keep on working on my project by myself! :) That said, I'd like to throw a few ideas to the table. - MCU: I'd like to use an STM32 micro. They seem to be emerging as the standard choice for diy ARM projects, and this offers a few interesting opportunities: -Programming it in c/c++ with the manufacturer CMSIS standard libraries (boring) -Programming it with the mbed.org SDK. Unfortunately no dev boards are available with dual CAN bus, but it will be easy to move to the correct micro of the same series once most of the software is ironed out on a dev board like the https://mbed.org/platforms/ST-Nucleo-F302R8/ -Programming it with an RTOS. NuttX would be my choice, as it's the one used in the Ardupilot Pixhawk platform, and I'd like to learn it. This would mean a steeper starting curve, but a lot of flexibility later as a lot of stuff is handled on the OS level (network stacks, SD card & filesystems, multitasking...). FreeRTOS is a nice option too. I'd like to use the STM32F405RG as it's the most similar to the one found on the Pixhawk, but of course I'm biased because of that, and that micro is quite overkill for the task. We can of course use a lower specced part and lose some RTOS fuctionality as long as it has 2 CAN buses. - MODEM: I have no experience in this field; is the SIM908 still a good choice or does anyone think that we should try new platforms? I like this, but I don't know if the price puts it out of budget: http://www.telit.com/telit/Pulsar/en_US.Store.display.1001./ge864-gps On the bright side, it can be programmed in python, so we can offload some of the work to the modem. This *could* allow us to free some space on the PIC, and keep that platform without changing MCU.. - Enclosure: I think that, even with the new MCU, we can still fit the old enclosure. Is that ok, or should we think about a more automotive-friendly one? Maybe waterproof for the twizy? And that's it. I think that the core SW developers should voice their opinion, as there is a lot of work to be done on that front. A huge problem will be keeping backwards compatibility to add features for the v2 users, so we should discuss about this too. Regards MG

18 70

SIM808 and v2.8.6
by Mark Webb-Johnson 10 Jun '16

10 Jun '16

Glad to say the ordeal with SIM808 support is over. With Michael Balzer’s help, we’ve got the GPS working well and the final firmware is built. To keep things as small as possible, we’ve split to two different sets of configuration files and firmware builds types for the V2 hardware. Here is the full list of firmware files: V1_production_908.hex V1 Hardware Module, SIM908 modem, production firmware V2_production_808.hex V2 Hardware Module, SIM808 modem, production firmware V2_production_908.hex V2 Hardware Module, SIM908 modem, production firmware V2_experimental_808.hex V2 Hardware Module, SIM808 modem, experimental firmware V2_experimental_908.hex V2 Hardware Module, SIM908 modem, experimental firmware V2_RT_production_808.hex V2 Hardware Module, SIM808 modem, Renault Twizy full firmware V2_RT_production_908.hex V2 Hardware Module, SIM908 modem, Renault Twizy full firmware V2_TR_production_808.hex V2 Hardware Module, SIM808 modem, Tesla Roadster full firmware V2_TR_production_908.hex V2 Hardware Module, SIM908 modem, Tesla Roadster full firmware The v2.8.6 firmware is now live on github. You can tell the difference between a SIM808 and SIM908 module by looking at the board. The big white chip is clearly marked. This production firmware is going to the factory now. Hopefully the modules (SIM808) will be back in stock at Fasttech within the coming week. We’ve also taken this opportunity to merge in a bunch of changes from various contributors. The full change log is: 2016-05-29 2.8.6 Firmware 2.8.6 SIM808 GSM/GPS production support # Framework: - Support for separate charger temperature (car_tcharger) # Twizy user guide v1.8 (BMS power limit bypass) # Twizy documentation: - Added command overview # Twizy documentation: - Added limiter designer to powermap calculator # Twizy documentation: - Added some more registers to SDO list # Leaf: reformat using mplabx 'whitesmiths' formatting rules, no code changes # Merge carrott/nissan-leaf-reformat enhancements for Nissan Leaf # Twizy: minor documentation fixes & additions # Merged Kia Soul 0.46 06 Mar 2016 (Geir Øyvind Vælidalo) # Leaf: - TCU messages aren't suitable for car state selection # Leaf: - Use presence of inverter messages to indicate car on and driving # Leaf: - Use bus inactivity to indicate car off # Leaf: - use presence of ABS messages to indicate driving - add some TODO # Leaf: extract car on-off to a function # Leaf: when ABS messages stop, car must be off, even if CAN bus is still active # Leaf: understand waiting for charge timer # Leaf: Refactor charger status logic # Leaf: extract gids out to a separate value # Leaf: turn off polling as it causes a relay to click every 20 seconds while charging # Leaf: don't update charger state when the can bus goes quiet as charger has already told us what happened # Leaf: use J1772 pilot maximum current to set the pilot and charge door bits # Leaf: use unambiguous variable types # Leaf: initialize SOC and SOC alert to avoid SMS on startup # Merge pull request #147 from carrott/nissan-leaf # Deterministic TRISC & PORTC init in each module # led_set should turn on the chosen led, not OVMS_LED_O - 1 == RC3 when digit == OVMS_LED_ON # Merge pull request #148 from carrott/deterministic-portc # Fix for twizy to allow production builds with OVMS_TWIZY_BATTMON # Firmware build restructuring for SIM808 support, and basic GPS support for SIM808 # SIM808 GPS fetch & coordinate processing - "GPS?" command optimized GM link, extended by OSM link # Added modem power up on module power up - Diag mode clients reworked for SIM808 operation # RT documentation: added modem terminal speed fix for diag mode 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 A big thank you to Michael Balzer for his help with this, as well as to all the other contributors. Regards, Mark.

2 2

Leaf Update
by Tom Parker 14 May '16

14 May '16

Hi, I've sent a pull request with some change to the Leaf vehicle. Nothing particularly exciting. I improved the state decoding when the car is plugged in but waiting for the charge timer and I disabled the polling for VIN and Speed as these don't work on my car and cause a relay to click. While learning about both the OVMS code and the Leaf CAN bus I tried to simplify and document or make self-documenting the CAN message decoding and OVMS state logic. Hopefully I've succeeded. I got remote climate control and remote charging working on my Gen 1 Leaf! I added a FET driving a reed relay glued to the top of the circuit board and connected +12v through the relay to the Ring Indicate pin on the DIAG connector. I went through one of the DB9 connector's supporting holes to access the bottom of the circuit board without having to go around the edge and foul the case. Ring Indicate seems like a good pin to use because it's an output from the DCE and we're literally saying "hey something is happening pay attention". RS232 has +12v logic so that's all good. I unplugged the TCU and connected my new signal to pin 11 of the plug (see Page 160 of https://carmanuals2.com/nissan/leaf-2012-audio-visual-system-section-av-478… ). This successfully activates the system and the car will respond to climate control and remote charging messages. So far the car hasn't complained that the TCU is unplugged. I didn't unplug the connection to the AV system head unit or the antenna, and I haven't looked at the AV system diagnostic to see if it has noticed. Something in the OVMS startup briefly activates the car. net.c sets TRISC to set the output pins to outputs but doesn't set the initial values of the outputs. The data sheet says in "INITIALIZATION CONDITIONS FOR ALL REGISTERS" that the initial state is undefined on power up and doesn't change on reset. Would anyone object to setting the initial value of output_gpo[0-3] low before switching them to outputs so the behavior is consistent? Something got upset and caused the OVMS crash very often. I think this is related to running out of credit with my cell phone provider but unfortunately I didn't log the comms with the modem to confirm. I think my cell phone provider may sometimes allow packet data for a short time after startup even when you've run out of credit, and I think something in the "no you've can't talk anymore" caused the OVMS to crash. This wouldn't have been a problem except it took a while to work out what was wrong because it would work for a few hours or minutes and then stop. When it eventually stopped sending any data to the server at all and the OVMS stopped crashing too. Whatever the cause was, this ran the 12v battery flat overnight twice. Semi related story, my battery is very weak due to leaving the interior light on all day and when I received the SMS from the OVMS that battery was dead (nice feature, but the threshold was too low) there was a misunderstanding and the car was turned on but not on enough to charge the battery -- it was plugged in so refused to activate the EV system and so the DCDC didn't start. When I got home the battery was at 6 volts. This is related because I turned on the light to program the OVMS one morning and forgot to turn it off before going to work. I'm going to document the GEN 1 modification and tidy up the climate control code and send a pull request. I've put changing the SOC calculations on hold for now as I want to get the climate control stuff in first.

1 0

Nissan Leaf Remote Climate Control working on Gen 2
by Tom Parker 08 May '16

08 May '16

Hi, I had a chance to test my updated Nissan Leaf firmware on a Gen 2 Leaf and it just works. I still haven't made a circuit to interface with the wakeup wire on my Gen 1, but this isn't necessary for Gen 2. Currently I'm abusing the Homelink and Alert commands to turn on and off Climate Control. Is there a more suitable pair of commands? I've got the android app and I don't see an obvious user interface for controlling the air conditioning. Should climate control require a pin like unlock and valet mode do? I'm thinking it doesn't need one because it's already protected by the SMS source phone number and the module password? Even if the source phone number can be spoofed, the impact isn't too great. I also implemented remote charging (since it's the same CAN message with a different value), I haven't tested that. See https://carrott.org/git/Open-Vehicle-Monitoring-System.git/shortlog/refs/he… for this firmware.

3 5

Storing Calibration Data
by Tom Parker 08 May '16

08 May '16

Hi, The Leaf's range estimate is pretty wonky as it's strongly influenced by your recent consumption. A much better range estimate is obtained from the current gids (approximately the kWh stored in the battery) and a Wh/km value. The Gen 2 Leaf is a little more efficient and I'm guessing people might want to adjust the value, so this efficiency probably shouldn't be hard coded into the firmware. I'm currently using the gids value to calculate state of charge, based on the maximum gids that the car can hold (as the battery degrades it can't store so many gids, so the SOC calculation needs to know this. I'm currently using the largest gids value seen since startup. Every period, I set the maximum gids to the largest I've seen in the period (currently 60 days) to allow the maximum gids to sink as the battery degrades. I've since found the BMS's state of charge field and may abandon this complex gids based SOC and use whatever the Lithium Battery Controller thinks the state of charge is. The car also knows it's Wh/km (it's displayed on the dashboard) so if I could locate that data in the CAN bus, I could replace the hard coded efficiency with something based off that. In the meantime, I'd like to store both the efficiency and the maximum gids in parameters so they're visible to the user and they can be changed. Is it safe to use Parameter 0x14 and 0x15 (20 and 21 in the app) to store calibration data? These parameters don't seem to be defined or used and the android app will let you modify them. Thanks.

5 16

Calculating Leaf Rated Miles
by Tom Saxton 08 May '16

08 May '16

I think exposing Gids would be fine, but it's not as user friendly as rated miles. Now that I've looked at it some more, I don't think it matters which model Leaf it is. The 24 kWh Leaf has an EPA rated range of 84 miles and a nominal full pack has 281 Gids. The 30 kWh Leaf is rated at 107 miles and has a nominal full pack around 363 Gids (that's the value James Pollock, aka Turbo3, the creator of LeafSpy recommended I use to convert Gids to percent for the Plug In America Leaf survey). Gids * 84 / 281 = Gids * 0.298932 Gids * 107 / 363 = Gids * 0.294765 Split the difference as 0.296849 which can be approximated very closely and rounded with integer math as: (Gids * 19 + 32) / 64 That's much closer to the target average than the average is to the two model-specific numbers, and won't overflow uint16_t until 3448 Gids. It has a maximum error of 1 rated mile compared to either the 24- or 30-kWh calculation in floating point and rounded through the range from 0 to 370, and an average absolute error just under 0.39 for both. The early Leafs had a lower rated range, but that was at least partially because of the methodology used by the EPA. Since the early Leafs has an option to charge to 80%, the EPA took the range with an 80% charge and averaged that with the 100% charge range. That's why Nissan took away the 80% charge option. Or so the story goes. As an owner of one of those early Leafs, I'd be totally happy with a rated miles calculation based on the later model's rated range. Tom On 5/7/16, 4:09 PM, "Tom Parker" <ovmsdev-bounces(a)lists.teslaclub.hk on behalf of tom(a)carrott.org> wrote: >On 05/04/2016 04:13 AM, Tom Saxton wrote: >> In C, integer calculations truncates instead of rounding. 99/100 = 0. Adding half of the denominator to the numerator causes the calculation to round up, i.e., (99 + 50) / 100 = 1. That's great for positive values, the case here, but isn't the right thing for negative values. Gary Gidding's original SOC meter didn't round, so that's been the de facto standard in the Leaf world. > >Thanks for the explanation, I've already removed the 140 and it sounds >like putting it back will move further from Gary's algorithm so I won't >put it back. > >> As for configuration, I think there's real value in having a pack energy number, like rated miles, that isn't configurable so it can be compared between owners. If the parameters change, I think it should be based on model configuration (which I'm hoping can be determined from the CAN bus), and not from owner configuration. > >Would it be better to expose the raw number of gids for comparison, so >there's no confusion about what the numbers mean? I've got some >rudimentary historical data reporting that sends the current gids. I >don't think there is a way to see the historical data other than the >HTTP api? > >I've not yet tried to be compatible with the Twizzy historical format, >and I don't have anything to visualize the data I am sending (I've >mostly used it as a channel for debugging). >_______________________________________________ >OvmsDev mailing list >OvmsDev(a)lists.teslaclub.hk >http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >

1 1

net.c SOC alert obsolete?
by Michael Balzer 08 May '16

08 May '16

Hi everyone, we've currently two low SOC alerts in the framework, one is the configurable (feature #9) min SOC alert in vehicle_ticker(), the other is the OVMS_SOCALERT code in net_state_ticker600(). The latter is fixed to 5% and does not respect user channel & notification configuration. Is there still a use case for this or is it obsolete? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

6 9