August 2013 - OvmsDev - Open Vehicles

CAN transmit problems - Think City vehicle_thinkcity.c
by Håkon Markussen 26 Aug '13

26 Aug '13

Hi, I've met a problem to which I need some help. I need to request some parameters from one ECU, and try to transmit on the can-bus from the OVMS-module. Whatever I do, the sys_features[FEATURE_CANWRITE] is always "0" and the transmission will never take place. I have tried to set the sys_features[FEATURE_CANWRITE] to "1", but as explained in the dev-doc, the TXB0CONbits.TXREQ will never go true and the module will reboot. The receiver of the request (RX-part) works fine, I've tested that by transmitting manually with PCANView. I have tried to put the TX-statements in the poll1, ticker1 and currently; in an idle poll (as in vehicle.teslaroadster.c) which has a hook in vehicle_fn_idlepoll = &vehicle_thinkcity_idlepoll; I've debugged a bit and found that: FEATURE_CANWRITE = 15 sys_features[FEATURE_CANWRITE] = 0 right before the if-test begin. I would be happy if anyone have some helpful hints :-) BOOL vehicle_thinkcity_idlepoll(void) { if (sys_features[FEATURE_CANWRITE]>0) { while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; // msg 753 03 22 49 67 TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x67; TXB0DLC = 0b0000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission } return FALSE; } Best regards Håkon

2 1

Hardware hacking OVMS module v2, for fun and pleasure
by Mark Webb-Johnson 24 Aug '13

24 Aug '13

Over the past year or so, I've had a few people ask me the same sort of question, so thought a single reply here would help. On the v2 module circuit board there is a unpopulated 9x2 set of holes in the board. You can see it on the attached picture, between the crystal and LEDs. You can find the circuit diagram on github, under vehices/Car Module/v2-base. You can either solder directly to this, or use a header plug/socket arrangement. All the unused pins from the PIC are brought out via that header, as well as GND, +5V and +12V. There are several free analog input pins, as well as digital input/output pins available for expansion. They are all 5V TTL level. If someone wants to use these for something, I suggest you code utils.h/utils.c to provide a function to initialise and control the required ports. Just try to make it fairly non-specific so it is of some use to others. Then, the vehicle module can just call the appropriate utils.c function, presumably in response to an SMS / net_msg command. For bi-directional sync/async comms, things are a little bit more tricky. The I2C pins are used by the LEDs, so you would have to sacrifice those and hack the code to use I2C. You could in theory do a software async, but I think that would be tricky. The DIAG port is just a tap between the PIC and the modem. Probably the best, for something sophisticated, is to use the CAN bus. Regards, Mark. > Together with some of my Think-assosiates, I'm tracking the can-messages for central lock/unlock switch for the Think. We have some good progress and I think I'll be able to implement it. > We also have one interesting idea to expand the usage of the OVMS, by using the Duinomite as a can-to-axillary gateway. > The ovms can send self defined can-messages to the Duino, which again can set one analoge/digital out-pin. E.g. to turn on a Webasto/Eberspächer heater via SMS. > This would of course be easier to implement, if OVMS-module had a few analog output pins that can be set to +12V or to GND.

1 0

Problem creating an array for Think City
by Håkon Markussen 24 Aug '13

24 Aug '13

Hi, I'm trying to create a fault/error SMS function for the vehicle_thinkcity.c The idea is making a two columns array, where the first column keeps different alarm messages available, while the second column keeps the state-variables of the corresponding error. Later on, only active errors, which has it's state-variable flag set, will be sent in the SMS (and the number of active errors). Unfortunately my code did not work, and I therefor ask you for some help. *The code is currently:* *void vehicle_thinkcity_fault_prepmsg(void)* *{* * * * rom char vehicle_thinkcity_fault_txttable[][] = * * {* * "MnyFailCel", // -> tc_bit_manyfailedcells;* * "Crash", // -> tc_bit_crash;* * "GenErr", // -> tc_bit_generalerr;* * "IsoErr", // -> tc_bit_isoerr;* * "IntIso", // -> tc_bit_intisoerr;* * "ExtIso", // -> tc_bit_extisoerr;* * "ThermIso", // -> tc_bit_thermalisoerr;* * "EmgEPO", // -> tc_bit_epoemerg;* * "ChgWaitTemp", // -> tc_bit_chgwaittemp;* * "ReachEOC", // -> tc_bit_reacheocplease;* * "WaitOkTpDcg", // -> tc_bit_waitoktmpdisch;* * "CrgWaitTp2", // -> tc_bit_chgwaitttemp2;* * "NoChgCur", // -> tc_bit_nochgcurr;* * "ChgOverVolt", // -> tc_bit_chgovervolt;* * "ChgOverCur", // -> tc_bit_chgovercurr;* * ""* * };* * * * rom char vehicle_thinkcity_fault_vartable[] = * * {* * tc_bit_manyfailedcells,* * tc_bit_crash,* * tc_bit_generalerr,* * tc_bit_isoerr,* * tc_bit_intisoerr,* * tc_bit_extisoerr,* * tc_bit_thermalisoerr,* * tc_bit_epoemerg,* * tc_bit_chgwaittemp,* * tc_bit_reacheocplease,* * tc_bit_waitoktmpdisch,* * tc_bit_chgwaitttemp2,* * tc_bit_nochgcurr,* * tc_bit_chgovervolt,* * tc_bit_chgovercurr* * };* * * * * * char *s;* * int k;* * int errcount = 0 ;* * * * * * s = strchr(net_scratchpad, 0);* * s = stp_rom(s, "Act err:");* * * * //additional info for error-print* * if (tc_pack_failedcells != 0)* * {* * s = stp_i(s, "\rFailCel:", tc_pack_failedcells);* * errcount++;* * }* * // end additional info * * * * for (k = 0; vehicle_thinkcity_fault_txttable[k][0] != 0; k++)* * {* * if (vehicle_thinkcity_fault_vartable[k] != 0)* * {* * s = stp_i(s, "\r", vehicle_thinkcity_fault_txttable[k]);* * k++;* * errcount++;* * }* * }* * s = stp_i(s, "\rTot err: ", errcount);* * * * * * * *}* Best regards Håkon

2 1

Problem creating an array for Think City
by Håkon Markussen 22 Aug '13

22 Aug '13

Hi, I'm trying to create a fault/error SMS function for the vehicle_thinkcity.c The idea is making a two columns array, where the first column keeps different alarm messages available, while the second column keeps the state-variables of the corresponding error. Later on, only active errors, which has it's state-variable flag set, will be sent in the SMS (and the number of active errors). Unfortunately my code did not work, and I therefor ask you for some help. *The code is currently:* *void vehicle_thinkcity_fault_prepmsg(void)* *{* * * * rom char vehicle_thinkcity_fault_txttable[][] = * * {* * "MnyFailCel", // -> tc_bit_manyfailedcells;* * "Crash", // -> tc_bit_crash;* * "GenErr", // -> tc_bit_generalerr;* * "IsoErr", // -> tc_bit_isoerr;* * "IntIso", // -> tc_bit_intisoerr;* * "ExtIso", // -> tc_bit_extisoerr;* * "ThermIso", // -> tc_bit_thermalisoerr;* * "EmgEPO", // -> tc_bit_epoemerg;* * "ChgWaitTemp", // -> tc_bit_chgwaittemp;* * "ReachEOC", // -> tc_bit_reacheocplease;* * "WaitOkTpDcg", // -> tc_bit_waitoktmpdisch;* * "CrgWaitTp2", // -> tc_bit_chgwaitttemp2;* * "NoChgCur", // -> tc_bit_nochgcurr;* * "ChgOverVolt", // -> tc_bit_chgovervolt;* * "ChgOverCur", // -> tc_bit_chgovercurr;* * ""* * };* * * * rom char vehicle_thinkcity_fault_vartable[] = * * {* * tc_bit_manyfailedcells,* * tc_bit_crash,* * tc_bit_generalerr,* * tc_bit_isoerr,* * tc_bit_intisoerr,* * tc_bit_extisoerr,* * tc_bit_thermalisoerr,* * tc_bit_epoemerg,* * tc_bit_chgwaittemp,* * tc_bit_reacheocplease,* * tc_bit_waitoktmpdisch,* * tc_bit_chgwaitttemp2,* * tc_bit_nochgcurr,* * tc_bit_chgovervolt,* * tc_bit_chgovercurr* * };* * * * * * char *s;* * int k;* * int errcount = 0 ;* * * * * * s = strchr(net_scratchpad, 0);* * s = stp_rom(s, "Act err:");* * * * //additional info for error-print* * if (tc_pack_failedcells != 0)* * {* * s = stp_i(s, "\rFailCel:", tc_pack_failedcells);* * errcount++;* * }* * // end additional info * * * * for (k = 0; vehicle_thinkcity_fault_txttable[k][0] != 0; k++)* * {* * if (vehicle_thinkcity_fault_vartable[k] != 0)* * {* * s = stp_i(s, "\r", vehicle_thinkcity_fault_txttable[k]);* * k++;* * errcount++;* * }* * }* * s = stp_i(s, "\rTot err: ", errcount);* * * * * * * *}* Best regards Håkon

1 0

USSD Signaling
by Mark Webb-Johnson 21 Aug '13

21 Aug '13

I've had a proposal from a M2M provider that is interesting, so thought I'd distribute it here, and get feedback. A very low-level protocol in the GSM standard is called USSD. It involves the transmission of a single alpha-numeric message of up to about 120 characters. Our protocol messages would fit perfectly into it. The USSD protocol is routed at a very low level, and is a datagram-syle protocol (it may be discarded by the network if there is no cellular connectivity, kind of like UDP). The protocol is supposedly better able to make it through congested and low-signal areas than even SMS, and certainly much better than GPRS. Message transit times are faster than SMS at around 1 second (of course, depending on cellular coverage). The interesting things about the protocol are than (a) it is free (or flat-rate, at least), and (b) it supports roaming. One SIM, flat rate, globally. The M2M provider suggests that we buy SIMs from them with unlimited USSD plans. Once activated, the SIMs would work globally on hundreds of partner carriers, and would only support USSD (not SMS or GPRS data). The way it would work for OVMS would be: Every OVMS module would be provided with a USSD SIM already onboard. It would work globally. The owner would go to the www.openvehicles.com website and create a vehicle record as normal, but also enter the serial number of the SIM. When the OVMS module powers on, it would read the serial number from the SIM then send a single USSD message to us to request provisioning (vehicleid, server password, etc). The OVMS server would send back a USSD message to provision the module in the car. From then onwards, USSD messages would be used to encapsulate our current OVMS protocol messages. The USSD messages are bi-directionally gatewayed to the OVMS server via the M2M provider, over the Internet. There would need to be some small changes to the encryption protocol we use. The OVMS firmware could support this as a special operation mode - based on the prefix of the SIM inserted. So, it could work in normal SMS/GPRS mode as well as USSD mode (switched by the SIM in the module). Cost wise, this would increase the cost of the module by less than US$10 (price of the SIM). A monthly flat-rate "unlimited" USSD plan would be around US$8-US$10 per month. What do people think? Regards, Mark

4 12

Data logging
by Mastro Gippo 20 Aug '13

20 Aug '13

Hello, I'm working on a project to log and analyze data from different electric vehicles, and I'm testing the OVMS on a Renault Twizy. Basically, my goal is to log all important data relative to the battery health, like single cell voltages and temperatures, every time these details are sent through the CAN bus. The last update from Mark about Drive and Charge logging looked interesting to me, so I have recompiled and uploaded the last version from github and now I have a few questions. - By setting bits of feature #13, do you mean sending a command like "S FEATURE 13 3" to set them both? - How much data will be recorded? Will it record cell voltages every second, for example? I'm also having a few problems with the server, I'm running it from my pc, but I keep getting this error: 2013-08-20 03:11:09.570207 -0700 info main: #8 - new ovms connection from 83.224.73.48:36348 2013-08-20 03:11:11.176338 -0700 info main: #8 - - rx MP-C 0 5OnUlqzQRG/M9iLIp+XEVa j11lelnvojoURvQHwe1zlg== Test123 2013-08-20 03:11:11.177198 -0700 error main: #8 TEST123 error - Incorrect client authentication - aborting connection I tried to change passwords and encryption scheme from the DB, but I still get that error. I'd also like to know if you think that the OVMS is a good option for my needs, because it looks like the goal of the OVMS is too different from mine, so I may need to rewrite the PIC firmware to just dump the data from the CAN bus and push it through to my server, then parse it later. Regards Mastro Gippo

2 2

Think City files and images (for iOS) committed to GitHub
by Håkon Markussen 16 Aug '13

16 Aug '13

Hi all, I have now uploaded 5 new images for Think City to Github Open-Vehicle-iOS and have made a pull request. The images are committed for ( with px-size ol = 304 x 606 car_ 654 x 302). They can be seen here: http://elbilforum.no/forum/index.php/topic,6755.msg109601.html#msg109601 I have also committed 4 files to Github Open-Vehicle-Monitoring-System and made a pull request for them as well: - vehicle_thinkcity.c - net_msg.c - ovms.c - ovms.h I had a hard time to understand the Github-client (please have me excused), so I'm not 100% sure if all is correct. If there is anything wrong please let me know. Best regards. Håkon

2 1

Ovms for Think City - definition of variable car_tbattery
by Håkon Markussen 15 Aug '13

15 Aug '13

Hi all, I'm a new user and have starting to develop/configure on the OVMS for Think City. Currently I've made success with both SMS and App interrogation and it works well! The result and some screenshots can be viewed at the Norwegian EV-forum in this post: http://elbilforum.no/forum/index.php/topic,6755.0.html Due to some problems with the definition of global variables (changing more files than vehicle_thinkcity.c), I've been doing my development locally, not uploaded anything to GitHub. The main problem is that the variable car_tbattery is defined as signed char. Most Think City EV's have a "Zebra-battery" which operating temperature is about 270 degrees celcius (oC). E.g. sending temperature 264 oC requires 9 bits -> 1 0000 10000 I think the signed char offers only 8 bits (bit 7 is set for negative numbers), and turns my value into 0000 1000 -> 8 oC ... I understand that the OVMS-server (and the App) knows that car_tbattery is signed char, so to get around this I will ask if it's possible to redefine car_tbattery as signed int ? As a second priority request, I would also ask if it's possible to add pack_voltage and pack_current to the global variables ovms.c unsigned int car_pack_voltage = 0; // Zebra battery pack voltage signed int car_pack_current = 0; // Zebra battery pack temp ovms.h extern unsigned int car_pack_voltage; // Zebra battery pack voltage extern signed int car_pack_current; // Zebra battery pack temp I'm not sure how things are done here, so have me excused if I ask a little too much. Best regards Håkon

2 1

OBD-II Cables
by Mark Webb-Johnson 11 Aug '13

11 Aug '13

I'm going to order another batch of OBD-II cables (changing factory because the one I used the last few times is so unresponsive). Is the current 1metre cable length good, or should I order them longer? Regards, Mark.

4 5

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