- OvmsDev - Open Vehicles

ACC and V1 modules
by Mark Webb-Johnson 28 Aug '13

28 Aug '13

The good news is that by doing some juggling around, I've managed to shoe-horn ACC into the V1_Production code for v1 hardware modules. We've got 3,614bytes of flash and 504bytes of RAM free to play with! The sad news is that this is at the expense of DIAG mode. Anyway, if developers really need that, they can build a custom firmware for it anyway, so not too bad. I may be able to bring it back for v1 hardware at a later stage, if we can reduce code-size elsewhere. I also removed the internal gps from the Tesla Roadster V2_TR_Production build config, as it was just wasting space. I revised Tesla Roadster V2 cooldown charge to 13A, and fixed a bug where the car seemed to be able to still attempt cooldown recycles (range->performance->range) even when the car wasn't charging (presumably if a cooldown was interrupted). It was interesting seeing my car switch from standard to performance mode then to range mode automatically, as I left my driveway this morning :-) Anyway, it let me test the geofencing of ACC, as the behavior stopped when I got out of range of my garage! Other than that, the cooldown and ACC seems to be working as expected, but I continue to test. Finally, I merged in the latest thinkcity changes. Regards, Mark.

1 0

Restructuring build configs
by Mark Webb-Johnson 27 Aug '13

27 Aug '13

We're now up to 11 vehicle modules, and flash memory space is getting very tight. We already can't build all modules with all features, and I don't want to have to limit what we can do. Accordingly, I'm splitting the master project build arrangements as follows: V1_Experimental will dropped (V1 features are all production now). V1_Production will be Tesla Roadster only, with as many features as we can fit in. V2_Experimental will be for the experimental (non-production) vehicles, base features. V2_Production will be for production vehicles, base features (currently this will be none, Tesla Roadster, Volt/Ampera and Renault Twizy). V2_TR_Production will be for Tesla Roadster, full features. V2_RT_Production will be for Renault Twizy, full features. Other private V2_??_Experimental build configs can be used by developers for their own work. As other vehicles make it to production status, and have optional extended features, they will get their own V2_??_Production build configs. I think that this approach brings several advantages: We clearly label vehicle support as Production or Experimental. Experimental work can continue with little impact on Production. For vehicle modules that have a lot of functionality (needing flash space), spinning them off to their own build config gives them the full range of flash to work from. The firmware in new modules from China will be based on V2_Production. I plan to commit these changes sometime this week, along with the ACC code that I'm testing in my car now. The logging code also looks stable, and will make it into production with the next release. I've been running this release in my car for about 10 days now, and things are looking good - very very stable with zero crashes and good recovery from poor GSM/GPRS signals. Regards, Mark.

3 4

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