January 2017 - OvmsDev - Open Vehicles

OVMS logo
by Mark Webb-Johnson 06 Jun '17

06 Jun '17

We need to change the OVMS logo, to better reflect the vehicle independence. The existing logo is too much Tesla. Felix has kindly prepared a couple of options for us, attached below. My preference is for the one with the car outline (even though it retains a hint of Tesla), as it emphasizes the vehicle comms aspect. This is quite urgent, as the Teslive people are pushing for artwork. What do you guys/gals think? Regards, Mark

8 14

OVMS v3
by Mastro Gippo 20 May '17

20 May '17

Hi all, I'd like to resurrect an old conversation. As we know, the current PIC is quickly running out of resources and maybe it's time to switch to a better platform. Two CAN buses are now desirable too. A microSD slot and direct USB connectivity wouldn't hurt either. I will probably have to design a similar hardware for myself, so I'd like to contribute to the OVMS by sharing the HW platform if you want; no strings attached of course, if you decide that there's no need for the upgrade, I'll keep on working on my project by myself! :) That said, I'd like to throw a few ideas to the table. - MCU: I'd like to use an STM32 micro. They seem to be emerging as the standard choice for diy ARM projects, and this offers a few interesting opportunities: -Programming it in c/c++ with the manufacturer CMSIS standard libraries (boring) -Programming it with the mbed.org SDK. Unfortunately no dev boards are available with dual CAN bus, but it will be easy to move to the correct micro of the same series once most of the software is ironed out on a dev board like the https://mbed.org/platforms/ST-Nucleo-F302R8/ -Programming it with an RTOS. NuttX would be my choice, as it's the one used in the Ardupilot Pixhawk platform, and I'd like to learn it. This would mean a steeper starting curve, but a lot of flexibility later as a lot of stuff is handled on the OS level (network stacks, SD card & filesystems, multitasking...). FreeRTOS is a nice option too. I'd like to use the STM32F405RG as it's the most similar to the one found on the Pixhawk, but of course I'm biased because of that, and that micro is quite overkill for the task. We can of course use a lower specced part and lose some RTOS fuctionality as long as it has 2 CAN buses. - MODEM: I have no experience in this field; is the SIM908 still a good choice or does anyone think that we should try new platforms? I like this, but I don't know if the price puts it out of budget: http://www.telit.com/telit/Pulsar/en_US.Store.display.1001./ge864-gps On the bright side, it can be programmed in python, so we can offload some of the work to the modem. This *could* allow us to free some space on the PIC, and keep that platform without changing MCU.. - Enclosure: I think that, even with the new MCU, we can still fit the old enclosure. Is that ok, or should we think about a more automotive-friendly one? Maybe waterproof for the twizy? And that's it. I think that the core SW developers should voice their opinion, as there is a lot of work to be done on that front. A huge problem will be keeping backwards compatibility to add features for the v2 users, so we should discuss about this too. Regards MG

18 70

SIM808 GPS float bug
by Edward Cheeseman 13 Feb '17

13 Feb '17

Hello, I am new to OVMS. I have a Gen2 Leaf on Dexters server. Tom has helped me set it up. I found my GPS data was off up to two degrees. I’ve traced it to myatof() in utils.c. It adds the fractional part with both positive and negative numbers, where it should subtract for negative numbers. myatof() is used in SIM808 lat and long conversions, and somewhere in Twizy which I didn’t look into. I suppose there isn’t that many SIM808 based OVMSs in the Southern or Western hemispheres? It is easy to fix, but maybe going through float in the first place isn’t necessary? Looks like there is 31bits of information coming out of the GPS where float will drop this to 23bits. I’ve started rewriting gps2latlon() to use a long long (64bit) integer multiply and divide. I see reference to SIM808 and 908 on an arduino shield, so I might have a look to see what they have done. Edward

5 25

Nissan Leaf remote climate control update
by Tom Parker 20 Jan '17

20 Jan '17

I spent some time with a friend's Gen 2 Nissan Leaf and got to the bottom of why the remote climate control works on some cars and not others. It turns out that if you have CARWINGS (now called NissanConnect) hardware in your car, the Nissan TCU module sends "Status" (0x4e) and "Idle" (0x86) messages on CAN frame 0x56e. These override the "CC On" (0x4e) message (0x4e) I'm sending with the OVMS and shut the car down. If you have a TCU module, the solution is to unplug it. I haven't noticed any problems doing this, I unplugged my TCU (on my Gen 1 I had to do this to access the hardware wakeup wiring) about 6 months ago. My friend has been going a few days in his Gen 2 with no problems. Unplugging isn't terribly difficult on a right hand drive car, you have to remove a panel above the driver's feet and then contort yourself in to press the release latch and pull out the big plug. I didn't bother unplugging the antenna and USB connection to the AV unit, and I coudln't work out how to release the entire module without taking more of the car apart. I do notice a check engine light when I use the remote climate control but it goes away after your turn the car off an on again and doesn't affect the performance of the car. I'm guessing something notices that the OVMS isn't faithfully emulating all the TCU funcitons. If anyone has a working NissanConnect and could capture the can bus for an entire remote climate control session, from startup to shutdown, maybe I can get rid of this problem. I've sent a pull request that decodes the HVAC status, allowing the android app to show whether it's on or off. Is the iOS app still maintained? I'd like to remove the Homelink hack (where remote climate control is available on homelink 1 (on) and homelink 2 (off)) when it has the new HVAC command.

2 1

Framework V3.1
by Michael Balzer 18 Jan '17

18 Jan '17

Happy new year everyone :) As you may have seen, I submitted a rework of the network framework yesterday. My goals were to a) eliminate hard coded delays as far as possible to get faster command responses, b) more stable/reliable tickers and c) higher frequency logging. I've managed to achieve goals a & b. Commands are now processed in around one second instead of three, and logging is now very stable, for example GPS streaming will be very close to one entry every three seconds. Higher frequency logging would be possible, but I've run into a hardware issue with this: the modem (both 908 and 808 versions) runs into under voltage problems if GPRS sends occur faster than once every three seconds on average. This will even work when the GSM cell does not change, but if the modem also needs to switch cells on the road, it occasionally just powers down without warning. This may also happen when the modem needs very high send power levels, i.e. if the next GSM tower is far away. The hardware design document says: /"The transmitting burst will cause voltage drop and the power supply must be able to provide sufficient current up to 2A. For the VBAT// //input, a decoupling capacitor (low ESR) such as a 100 μF is strongly recommended."// / ...and the same problem could be solved here by adding a 10 µF buffer capacitor to the power supply line: https://forums.tessel.io/t/gprs-module-turns-off-randomly/250/7 So higher frequency logging may be possible when the modem does not need to power up its own GPS circuit, i.e. when the car supplies GPS coordinates. One GPS (speed) mark every three seconds is still sufficient, now it's stable. Btw, I also think I fixed the buffer overrun issue. I could reproduce the bug by timing a command send to arrive at the module at the moment the module starts a send itself. I then found some potential buffer problems with this case in the net_poll() code. Since fixing them I had no more events and can no longer trigger the bug with that command timing. Please let me know if you run into new issues with this rework. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 17

Open Source Renault Twizy?
by Nikki Gordon-Bloomfield 05 Jan '17

05 Jan '17

http://media.renault.com/global/en-gb/renaultgroup/Media/PressRelease.aspx?… Just dropped into my inbox from CES. I’ll be on the show floor later, so I’ll try and find out more. If you want me to ask specific questions let me know! [image: --] Nikki Gordon-Bloomfield [image: https://]about.me/aminorjourney <https://about.me/aminorjourney?promo=email_sig>

2 1