- OvmsDev - Open Vehicles

Think City EV
by Mark Webb-Johnson 31 Dec '12

31 Dec '12

Nikolay, I'll create the stub vehicle code for Think City EV for you. We'll need a vehicle name and ID. I suggest: Module: vehicle_thinkcity.* ID: TCEV Is that ok? If so, I'll create it today. Regards, Mark.

2 6

Problem building the project
by Nikolay Shishkov 29 Dec '12

29 Dec '12

Hello, This is my first message, I am trying to get the module talking to Think City EV. I installed the iDE and compiler, downloaded the repository, opened the project and did "Clean and Build Project" and got this error. Error - section '.code_vehicle.o' can not fit the section. Section '.code_vehicle.o' length=0x000004f4 I searched the list, and the forum and did not find any reference to this error. Any idea? Could it be that I have not connected the pic3 and the board? Thanks in advance, Nikolay

5 16

Volt/Ampera
by Mark Webb-Johnson 27 Dec '12

27 Dec '12

For the Volt/Ampera, I think we've now got GPS location, altitude and heading (from OVMS GPS, not from the car), VIN and SOC (auto-ranging). To make this useful, we need: Whether the car is ON or OFF. Whether the car is charging or not. Speed Estimated / Ideal ranges Temperatures Perhaps we need to get inventive? For example, if we know the car is off, speed is zero, and energy is going into the battery we can assume it is charging. If we see the car charging, then energy going into the battery is zero (or goes negative) for a time, then we can assume the charging has stopped. We can even alert if that happens and the battery SOC is not close to 100%. Previously, it was mentioned that speed was available on: > 3E9 Bytes 1-2 Speed 1/100 MPH 55MPH would be 5500 (0x157c) Assuming the speed is ok, I can add that. But, any ideas about the other messages? Regards, Mark.

2 1

Wrong Roadster Data
by Tom Saxton 20 Dec '12

20 Dec '12

There's something odd going on with OVMS and my Roadster this morning. I'm seeing data that claims to be live, but which is totally wrong. I got home last night with a 50% charge and set the Roadster to charge at 2 am. When I checked it this morning at 6:20, OVMS said the car was at 73%, live, parked for 5 minutes, and locked. When I checked the car, none of those were true. The car's at 97%, has been parked 9.5 hours, and is unlocked. I've never seen OVMS be wrong and claim to be "live". Tom

2 5

OBDII
by Mark Webb-Johnson 18 Dec '12

18 Dec '12

OVMS to OBDII

1 0

Android code for OVMS
by Mark Webb-Johnson 13 Dec '12

13 Dec '12

It appears that we're in a mess with the Android code base. The Android project Sonny had worked on containing updates to the OVMS Android App has been accidentally deleted, and the latest updates to the code lost. The NAS backup arrangement that Sonny had in place has also failed, and there is no backup. Sonny apologizes, and has tried hard to recover the files, but cannot. He is also still tied up with work commitments, and can't help much for the next month or two. We still have the code base in github, but that is quite old as it has not been updated with the improvements made in recent months. Primarily the settings screen, partial support for groups, and support for tablets. It is the tablet support that is causing problems with new high-res phones (as it is incorrectly identifying these as tablets) - I suspect that the settings code is the main thing we want to retain. I have tried to reverse-compile the Android code from the APK in the marketplace, and while the resulting code looks pretty good, the resources are not reverse-compilable, and look like they would take a significant amount of work to repair. My approach has been to take the github version, compile it, decompile it, and compare that with the decompiled version of the latest android market APK - applying patch duffs where necessary. The code looks good, and seems to only need minor tidy-ups. But, the resources are a mess. It seems the decompile process retains code symbols, but not resource symbols. The resource IDs and tags end up as numbers. I'm really not familiar with Android development, so am not sure how feasible that approach would be. It looked very easy and successful to start with. So, we are faced with a decision: 1. Someone more experienced with Android development comes up with a brilliant solution to finish off the reverse compilation of the APK to get back the latest version. I don't mind stepping in with the 'donkey work', but I really don't know where to start. What are those "R" class files - they look like they may be the key? 2. We start again with the code as it was a few months ago, and try to take it forward from there. 3. We investigate cross-platform development environments that could perhaps give us a more unified appearance across the the different platforms, as well as support for Windows Phone and others. What do people think? Mark

3 7

Twizy module 2.1
by Michael Balzer 11 Dec '12

11 Dec '12

https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/e527b9088… - temperature function updated to new formula (A - 40) - cell alert thresholds changed to fixed absolute deviations 3 °C temperature / 100 mV (watch thresholds = stddev as before) - battery monitor reset now bound to "key on" event instead of full charge cycle - cell mean value / deviation calculations now done with rounding - battery text alert now also sent by MSG protocol ("PA") and triggered immediately after every alert status change - Twizy battery monitor compiler switch: OVMS_TWIZY_BATTMON current ressource usage: 6% RAM (193 byte) + 10% ROM -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

2 2

Twizy
by Mark Webb-Johnson 10 Dec '12

10 Dec '12

Twizy support seems to be coming along nicely, thanks to the amazing work Michael is doing. Some good functionality there already. I'm starting to see some Twizy users register on openvehicles.com. Perhaps the word is getting out? Some questions / requests: Michael: Can you let me have the details on the cable pinouts and parts you are using at the moment? Is it a standard cable, or are you having to make something up? How is charge control on the Twizy done? Is there any way of stopping or starting (topup) a charge from within the car, or is it just controlled by plugging? Any chance of can bus control of this? Can anyone help with the car images for the Twizy? There are lots of nice images available, but they need to be photoshopped to the right dimensions and transparent background png. Regards, Mark.

5 17

Developer documentation
by Michael Balzer 03 Dec '12

03 Dec '12

Mark, Michael, I have written down some first hints for new developers, including some kick-off steps to get going and all of the "little problems" that gave me some headache up to now -- or at least those I haven't yet erased from my memory ;-) https://github.com/dexterbg/Open-Vehicle-Monitoring-System/blob/v2/docs/Fir… Mark, I know you've already begun on the firmware API documentation. Maybe we can put the docs together to get a complete developer documentation. Please comment and/or extend. Regards, Michael -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

1 0

Twizy module V2.0: battery monitoring
by Michael Balzer 02 Dec '12

02 Dec '12

Hi all, first release of the battery monitoring system: https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commits/v2 - PEM and motor temperatures - Battery cell temperatures: 7 cell modules of 2 cells each (overall battery temperature = average of modules) - Battery pack and cell voltages - Battery monitoring system: - history of min/max/max deviation during usage cycle - ...tagging of suspicious cells (dev > std dev) - ...tagging of cell alerts (dev > 2 * std dev) (thresholds may need refinement) - ...sends SMS+MSG on alert state change - First draft of battery state data MSG protocol extension (to be discussed on the developer list) - Development/debug utility: CAN simulator w/ battery data sim data can be injected any time by issuing the DEBUG command with desired sim data chunk number (i.e. SMS "DEBUG 12" / MSG "200,12") - Minor code cleanups & bug fixes If other Twizy OVMS users are here, I really could use some feedback on this. Especially on the watch/alert thresholds. I have to gather more real data to see if we need a configuration for the alert sensitivity, or if we need to introduce some minimum deviation level. I also sometimes got single deviations that must be completely wrong, although I implemented two levels of value consistency assertion. I'm still searching for the source of those. As the Apps do not support this feature yet, please send me your SMS outputs, i.e. - "BATT" (same as last alert if you get some) - "BATT V" - "BATT VD" - "BATT T" - "BATT TD" Thanks! Michael -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

1 1