July 2012 - OvmsDev - Open Vehicles

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

Alarm messages
by Jack West 16 Sep '12

16 Sep '12

Developers, Has anyone decoded the alarm message on the can bus of the Roadster? Any ideas where it might be hiding? Thanks, Jack

2 7

Re: [Ovmsdev] Cool down
by Bennett Leeds 11 Sep '12

11 Sep '12

I've been doing 220volt 15 amp charging to cool the battery. Like Tom, I manually stop it when the battery temp reaches 80F. Like Mark, I found that low amp charges didn't cool the battery as much - I'll speculate that Tesla probably sees the low amperage and figures that it can't waste as much juice cooling the battery, and that a slow charge won't really heat it up much. Have you thought about parameters for the CoolDown function? - Desired End Temperature - Amperage to Use - Maximum length of time to run Also, have you considered an "Auto" feature, where when OVMS sees the car is plugged-in but not charging and that the battery temp is high, automatically kicks on to cool it? The max run time parameter is kind of a safety feature to avoid running too long at high prices. - Bennett

2 1

OVMS v2 Simple Hardware
by Mark Webb-Johnson 23 Jul '12

23 Jul '12

Guys, Here are the latest pics. Very neat, and getting close. This was supposed to be the final prototype, but some problems found: 1. Diag port can't tx while pic on. This is caused by the new voltage divider arrangement, and we're trying to add a diode to get it working. 2. 12v ADC measuring circuit doesn't work. Design issue, now ok. 3. GSM/GPRS switch stuck ON. Board design fault, now ok. Other than that, it works perfectly. Can bus is fine, LEDs are the same brightness and easy to read. Transistor circuit for async comms pic->sitcom works great (thanks William). Cable arrangement is fantastic. So, I've got a final prototype board coming in the next week or so. I'll run that in my car for 1 week, and if no issues are found will then give production go ahead. Regards, Mark Color samples: I've chosen C-65, but seriously considered C-15 or C-75. DIAG port and LEDs. Car connector, gsm and gps antennas. Compare vs v1. Under 1/2 size, overall. Board slides out. Cable and size comparison.

4 4

OVMS basic v2
by Mark Webb-Johnson 08 Jul '12

08 Jul '12

We're getting there... Here's the latest sample, with SIM card carrier (about credit card size) for comparison. Pretty final, apart from (a) 'oxidisation process' to be used to give it black color, and (b) laser etched lettering. The design for PCB is also done, with revisions from last week. The two holes are the LEDs for status and error. Regards, Mark

2 1

MAX942
by Mark Webb-Johnson 07 Jul '12

07 Jul '12

For the hardware guys - Michael Stegen, Brian, William - anyone :-) On the v1 board, we have: The MAX942 chip is used for the SIMCOM TX -> PIC RX line, to convert the 3.3v SIMCOM async communication to 5v TTL for the PIC. My understanding of this is that the SIMCOM chip, while expecting 3.3v can accept 5v (TX from PIC, RX to SIMCOM) - and a diode is used on the circuit for this. But on the line from the SIMCOM to the PIC (TX from SIMCOM, RX to PIC), the SIMCOM only gives out 3.3v, but the PIC requires 5v TTL levels. One half of the MAX942 is used for that, and the other half is unused. I've seen some reference designs for such conversion, but all required both 5v and 3.3v power to handle it. In the original design (two separate boards), we had no 3.3v power on the PIC board, so could only do it the MAX942 way. Now, in the new v2 design, we have both 5v and 3.3v power lines on the same board, so perhaps we can do it a simpler way. The MAX942 chip is (relatively) expensive. The China guys are asking what we want to do with this, and suggesting using resistors to handle the 3.3v->5v conversion now. I guess some sort of voltage divider. Has anyone done anything similar? Regards, Mark.

4 11

v2 Basic Hardware
by Mark Webb-Johnson 05 Jul '12

05 Jul '12

I thought you might be interested in seeing some early pictures of the prototypes for the vs basic hardware we've been working on with the China team. Some notes: The design uses a metal rectangular "tube" style case, customised for us and cut to the width of our board. The case ends up about 7cm x 6cm. Labelled end-plates will go on, with cut-outs for the various connectors. The original design called for this to be black in colour, and we're still deciding on that (as the silver doesn't look bad and will be mostly covered with a black sticker anyway). Opening it involves removing the 4 screws on one side and sliding it out. On one side we have the CAN (and power) DB9, GSM and GPS antennas. On the other side we have the DIAG DB9 and expansion bus connectors. Holes for the LEDs are on the bottom of the case, and the LEDs themselves are on the bottom of the board, so that they are as close to the holes as possible. There are zero internal cables, and only one circuit board containing the PIC controller and SIM908 modem - connection to the car is via the main CAN DB9, using custom cables. We have tried to follow ODBII standard pinouts for that connector. For Tesla Roadster, we can use a custom 4 wire connector (Tesla DIAG port connector on one end, DB9 female on the other). For ODBII cars, a similar arrangement can be made. The SIM908 modem chip supports GPS for those cars that don't have it. Still early days, but the design looks workable and should be much easier to assemble and QC than the v1 modules. Rock solid and (probably) bullet proof. It should also have good support for cars other than the Tesla Roadster. Regards, Mark. P.S. I'm also working on a more advanced hardware solution, as a personal project, that may end up being offered. Just experimenting at the moment. William is also working on some solutions for this based on *bone hardware and shields. These are much longer term, and we'll send out more details when we have some progress.

3 4