December 2012 - OvmsDev - Open Vehicles

Re: [Ovmsdev] OVMS VIN 4E9->4F1->4E1 (was OVMS VIN 4E9->4F1)
by Mark Webb-Johnson 07 Aug '13

07 Aug '13

Michael, OK. I found some old logs you sent me before and these show: 7.628 R11 4E9 E1 80 00 04 6C 00 7.637 R11 514 47 31 52 39 36 45 34 39 8.647 R11 4F1 41 A1 01 A1 00 36 08 88 The 514 looks fine. But, both 4E9 and 4F1 look wrong. In particular, the 4F1 has '41 A1 01 A1 00' - which is what we are seeing for your VIN. But, id #4E1 has: 8.694 R11 4E1 43 55 31 31 36 34 38 39 If the VIN was in 4E1 and 514, that would give us: 8.694 R11 4E1 43 55 31 31 36 34 38 39 7.637 R11 514 47 31 52 39 36 45 34 39 Or, CU116489G1R96E49 for your car. For RScott, his logs show: 41966.094 R11 4E1 42 55 31 30 32 36 38 39 41966.110 R11 514 47 31 52 44 36 45 34 36 Or, BU102389G1RD6E36 for his car. Is that correct? Reading back through the old eMails, I find this from RScott: > The VIN can be constructed by taking the number "1" and converting the CAN IDs 4E9 and 514 to ASCII. So with "4E1 4255313032363839" and "514 4731524436453436", you would end up with 42 55 31 30 32 36 38 39 47 31 52 44 36 45 34 36, where 42 is ASCII for B, 55 is U, etc. So, I think the whole 4E9 was just a typo, as 4E1 is what is mentioned later in the same sentence. I've committed the code with 4E1 into github now. It works ok on my simulator, and hopefully should be ok in your car now. Can you try? Regards, Mark. On 26 Dec, 2012, at 9:12 PM, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: > Michael, > > I've put this up on my test bench, set to VA vehicle type, and setting my simulator to 500Kbps CAN speed, then transmitting the following three messages once a second: > > ID#206 A0 10 00 00 00 00 00 00 > ID#4F1 42 55 31 30 32 36 38 39 > ID#514 47 31 52 44 D6 45 34 36 > > Then, with the module in SETUP mode, I get: > > S MODULE? > # Module: > VehicleID:TESTCAR > VehicleType:VA > Units:K > Notifications:IP > > DIAG > # DIAG > > # Firmware: 2.1.1/VA/V2 > # SWITCH: 1 > # 12V Line: 14.0 V > # Signal: 0 > > # VIN: BU102689G1RD6E46 (VA) > # SOC: 64% (0 ideal, 0 est miles) > > That all looks ok. > The message from your car is: > > GERMANVOLT rx msg F 2.1.1/V2,A??,24,0,VA,E-Plus > > 00000040 20 6d 73 67 20 46 20 32 2e 31 2e 31 2f 56 32 2c | msg F 2.1.1/V2,| > 00000050 41 a1 01 a1 2c 32 31 2c 30 2c 56 41 2c 45 2d 50 |A...,21,0,VA,E-P| > 00000060 6c 75 73 0a |lus.| > > Your VIN is showing up as 41,A1,01,A1 - as you say: wrong. > > But, the firmware version and car type look ok. Not sure why they would not show up in the App. Perhaps the corrupt VIN# is messing up interpretation of that message? Perhaps the high bit on the A1 is messing it up. > > Not sure what is going on in your car itself. Can you check any captures you have for the exact id#4F1 and id#514 messages you have, and let me know? > > Regards, Mark. > > On 21 Dec, 2012, at 9:33 PM, mikeljo(a)mac.com wrote: > >> Hi, >> >> thanks. >> >> Works. Get the correct infos from my car. >> Implement the SOC calculation from my previous mail. >> >> - GPS ok >> - SOC ok >> >> BUT: >> - no VIN >> - No Car Type >> - no car firmware >> >> Here some Pics from the App: >> >> <IMG_1075.PNG> >> <IMG_1076.PNG> >> <IMG_1077.PNG> >> <IMG_1078.PNG> >> >> >> The App is the 1.3.2 compiled from the git. This is NOT the one from the Store!? >> >> BTW: You see the GSM Signal is -113dBm. When one door is open i got -87dBm. Heavy attenuation. >> I think i must mount the antenna outside the car. GPS is ok. >> >> >> Bye >> michael >> >> >> Am 21.12.2012 um 02:19 schrieb Mark Webb-Johnson <mark(a)webb-johnson.net>: >> >>> Michael, >>> >>> Parameter #14 (PARAM_VEHICLETYPE) holds the selected vehicle type. This can be set either from the smartphone apps, or via the SMS MODULE command. >>> >>> Regards, Mark. >>> >>> On 21 Dec, 2012, at 4:31 AM, mikeljo(a)mac.com wrote: >>> >>>> Hi, >>>> >>>> i checked it out. It compiles without error. >>>> But i think i missed something: how to switch between the cars? I know you do something, but couldn't find the howto. >>>> I found the ROM Parameter "VA" in "vehicle.c", but how to put this in the ROM? >>>> SMS Command? >>>> >>>> Sorry. >>>> >>>> Bye >>>> Michael >>>> >>>> >>>> Am 20.12.2012 um 15:08 schrieb Mark Webb-Johnson <mark(a)webb-johnson.net>: >>>> >>>>> Michael J: >>>>> >>>>> The following commit should fix this: >>>>> >>>>> * 269cd4f (HEAD, origin/master, origin/HEAD, master) Ampera VIN 4E9->4F1 >>>>> >>>>> Can you check the code now in master head, and see if it has everything you need. It builds and compiles on v2 hardware, but you'll need to change the compiler flags to get it building on v1 (just change TESLAROADSTER to VOLTAMPERA). >>>>> >>>>> What was the end result of the SOC range changes? Any ideas on the solution? >>>>> >>>>> Regards, Mark. >>>>> >>>>> On 6 Nov, 2012, at 5:28 AM, mikeljo(a)mac.com wrote: >>>>> >>>>>> Hi mark, >>>>>> >>>>>> do you think at the VIN? >>>>>> >>>>>> 1 + 514 + 4F1 >>>>> >>>> >>> >> >

11 85

Merging in Twizy and Volt/Ampera work
by Mark Webb-Johnson 20 Jan '13

20 Jan '13

A while ago, Michael Balzer suggested to me that it would be best to have one firmware supporting all cars. I agreed, but at the time, flash space was tight in the v1 hardware and I was concerned we would run out of flash. So, we implemented two separate builds. Now that the v2 hardware is out, I think that is much less of an issue than it was, as the v2 hardware has 50% more flash (taking away the baseline code, that at least triples the amount of free flash we have) - there should be plenty of space to support the cars that need it for the forceable future. In the coming few months, as the Volt/Ampera and Renault Twizy code becomes usable and usable by end-users (rather than developers), it would be much easier to be providing modules pre-flashed with a single version of firmware supporting all the cars. As the work on Twizy and Volt/Ampera is now progressing so fast, I think it best to make the change now rather than later. What I suggest is: We leave the current car modules basically as they are: can_teslaroadster, can_voltampera, and can_twizy. We leave the v1 firmware build basically as it is - just using can_teslaroadster. All the v2 hardware users are Tesla Roadster users. We move the 'shared' interrupt code (can_int_service, high_isr) out of the car_* modules into a can_canbus module. We create a mechanism for car_* modules to register themselves at startup. We create an eeprom parameter to define the vehicle type, and a switch at startup to hook the module supporting the currently defined car. It might be interesting in future to create a car_autodetect module to auto-detect the vehicle type from can bus traffic, but for the moment I think a manual parameter is acceptable. The existing V2_T2, V2_VA and V2_RT build configurations would disappear and be replaced with a single V2 firmware that would include all three car_* modules. I'm not sure of the exact mechanism for [4] and [5], but it should not be too hard to do. I really want to avoid having a single list of the cars anywhere. I'd much rather just have the existence of code in the can_* modules cause the code to be included. Does this sound sensible to everyone? Any better suggestions, or comments? Regards, Mark.

5 47

RFC: Battery status MSG protocol
by Michael Balzer 07 Jan '13

07 Jan '13

Hi Mark, this is my first draft of a battery data protocol as implemented in the Twizy module 2.0 (see vehicle_twizy_battstatus_msgp()). For each battery pack (min 1), a message of type "B" transports the current state and collected min/max values: // Output pack status: // MP-0 B,<packnr>,<nr_of_cells> // ,<volt_alertstatus>,<temp_alertstatus> // ,<soc>,<soc_min>,<soc_max> // ,<volt_act>,<volt_act_cellnom> // ,<volt_min>,<volt_min_cellnom> // ,<volt_max>,<volt_max_cellnom> // ,<temp_act>,<temp_min>,<temp_max> The units now are 1/100 % for the SOCs, 1/100 V for the voltages and 1 °C for the temperatures. Maybe floats are more readable / standard for SOC & V? Alert status are enums of... 0 = unknown 1 = nominal 2 = suspicious 3 = alert 4 = fail For each cell in each pack, a message of type "H" transports the cell details accordingly: // Output cell status: // MP-0 H,<packnr>,<cellnr> // ,<volt_alertstatus>,<temp_alertstatus>, // ,<volt_act>,<volt_min>,<volt_max>,<volt_maxdev> // ,<temp_act>,<temp_min>,<temp_max>,<temp_maxdev> Numbering of packs and cells begins at "1" to reserve "0" for an "all" selector. Alert status uses the same enum scheme as on the pack level. Voltages on the cell level are in unit mV, temperatures in °C. The maximum deviations are signed to reflect the direction of the deviation. Of course, a cell need not be a physical cell, it's just the smallest monitorable unit in a pack. Monitoring huge packs will not be possible with the current OVMS hardware, unless we consider streaming all sensor data to the server. I thought about how much could be stored in the server now and had a first look at the current server implementation. The primary key of table "ovms_carmessages" would need to be changed, as it currently is bound to just the message type character (and also case insensitive, reducing the number of possible message types). The key would need to be extended by the packnr on "B" messages and the pack + cellnr on "H" messages. So, generally speaking, we could introduce 2-3 key extension columns that can be used dynamically based on the message type. That would also enable storing of other historical records. To keep the database clean, an expire mechanism could drop all rows older than e.g. 24 hours. Please comment. Regards, Michael -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

3 49

OVMS OBDII Cables now available
by Mark Webb-Johnson 04 Jan '13

04 Jan '13

We received the cables yesterday, and they look good. The factory seems to have done a good job. I tested 5 - all ok - and even put one in my wife's Nissan to power up an OVMS module. Now, if only her car had a can bus :-( OVMS vehicle cables for connection to can-bus equipped OBDII vehicles are now available from our FastTech logistics partner. You can find them here: OVMS OBDII Cable @FastTech This cable connects the OVMS module to the vehicle CAN bus, via the industry standard OBDII socket. It is 1 metre in length, and uses a right-angle OBDII plug (J1962-M) to help with cable management and routing. The cable is intended to be used in Renault Twizy, Chevy Volt, Opel/Vauxhall Ampera, and other cars using OBDII connectors. OVMS OBDII Cable Pinout J1962-M DB9-F Signal 4 3 Chassis/Power GND 6 7 CAN-H 14 2 CAN-L 16 9 +12V Vehicle Power

3 5

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