- OvmsDev - Open Vehicles

V3 Hardware / Roll Your own
by Chris Perez 27 Feb '17

27 Feb '17

Just wondering if you are still on track to hit your 1Q17 target for the new hardware release. Interested in beta testing the new HW!

4 8

Re: [Ovmsdev] V3 Hardware / Roll Your own
by Chris Perez 26 Feb '17

26 Feb '17

Thanks Mark. A few more questions. 1. When will the schematics/component selections be published on GitHub? 2. What programming language are you planning on moving to seeing as how the PIC code will not translate directly to the ESP32? 3. Will the modem be moving to LTE Cat M1.NB1 for a little future proofing? I am toying with the idea of ordering a https://www.pycom.io/product/gpy-preorder-shipping-may-2017/ board and converting the OVMS code base+vehicle specifics to Python leveraging private MQTT. But I don’t want to fork too far away :/ Chris, Julien, I hear you. Just waiting for the latest processor stepping from Espressif, then should be ok for a run of developer boards. Still no modular certification, so stuck as a DIY until that is resolved. I appreciate that the delays are frustrating - for me too. Just a huge steep learning curve with this new platform. Regards, Mark.

2 1

SIM808 GPS float bug
by Edward Cheeseman 12 Feb '17

12 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

ODB CAN message decoder?
by Greg D. 08 Feb '17

08 Feb '17

3 7

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

19 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 04 Jan '17

04 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

Nissan Leaf Climate Control
by Tom Parker 25 Dec '16

25 Dec '16

I sent a pull request with Nissan Leaf remote climate control support. I also wrote up a quick blog post with a photo of my gen 1 wakeup circuit: https://carrott.org/blog/archives/158-OVMS-Nissan-Leaf-Remote-Climate-Contr… I'll post a schematic of the circuit. Gen 2 doesn't require any hardware modifications. I added #define CMD_ClimateControl 43 // (ON or OFF) with argument 'on' and 'off'. I'm using temporary hack to enable climate control via the homelink buttons. If CMD_ClimateControl is suitable, could we add support in the Apps for a better button to toggle it on and off? I see there is a car_doors5bits.HVAC to signal that climate control is on, but I don't think that is exposed in the android interface. This would be a good candidate to provide feedback that the climate control is on.

3 5

Fwd: Please pass onto your software developer friends
by Mark Webb-Johnson 22 Dec '16

22 Dec '16

Robert has asked me to distribute this, as it may be of interest and relevant to members here. Regards, Mark P.S. I’ve cc’d Robert to this eMail, so you can reply directly. Hi, I am a start-up looking for a developer to come on board as a co-founder and would very much appreciate it if you could share the following with your developer contacts. Want to help save the planet? We believe that technology can do that and we are committed to making it happen. Every year vehicles dump nearly 3 billion-tonnes of CO2 into the atmosphere. Electric vehicles represent a clean alternative and we're focussed on maximising their take-up by making them easy to use. Our software overcomes the problems associated with highly variable range and charging times, by providing sat navs with the data to support electric vehicles quickly & easily. With over one million people worldwide already driving electric vehicles and with more and more manufacturers entering the market place, electric vehicles are becoming a reality. We are a start-up business in Basingstoke looking for a talented and effective senior developer to join as a co-founder. We currently have a prototype system that we want to develop into a commercial product. As well as product implementation this is an ideal opportunity to lead the company's technical development with the potential to progress to a CTO role. The ideal person will be experienced in the following areas Fluent in at least 3 programming languages (including one object orientated language) JavaScript SQL databases HTML/CSS UI/UX design scalable server management So if you want to help save the planet this is the opportunity for you. For more information or an informal chat please feel free to contact me Regards, Robert Sharpe (Managing Director) 07711 252971 Your Plugged-in Partner Evergreen Consulting is the trading name of Sharpe Consultants Ltd

1 0

Re: [Ovmsdev] OVMS update
by Julien Banchet 14 Dec '16

14 Dec '16

Hi Mark, Many Thanks for the update, I honestly can't wait as every single point of features are great! Just a couple of questions: - Do you forsee a data envelope to have on the mobile provider ? (payload * rythme might go up) I suppose most of the things can(/will) be configurable on the backend/provisionning side ("discard this"/"limit these to once an hour"...) - Will the backend be rewritten? I suppose it will have to, as this is nothing alike before... What language will it be based on? Honestly, I have loved Perl in the past, and even though I'm far from being Python fluent, the latter might be a better pick in terms of adoption. Again, Thanks ! JaXX./. On Wed, Dec 14, 2016 at 2:00 AM, Mark Webb-Johnson <mark(a)openvehicles.com> wrote: > A short update on OVMS. > > We are working hard on OVMS v3. The development environment for the > microcontroller we chose for v3 has finally stabilised to a point where we > can rely on it. There will be a new revision of hardware silicon around the > end of 2017Q1 and we'll most likely try to time the first production > releases of OVMS v3 to use that as soon as it is available. But, the good > news is that we have the production development environments available now, > and the CAN driver (although early beta) is working well. All the > components are finally in place and usable. This has caused us delays in > our plans, but we are confident that our choice of microcontroller was the > right one. This will give us a great platform for the future and most > importantly allow us to keep costs down without being constrained by > RAM/Flash memory storage (as was the case for the v2 PIC18 platform). > Bluetooth and Wifi support are a bonus. Work on the firmware for OVMS v3 is > ongoing, and we're hoping to release this to the open source team any day > now. Some highlights of the coming features for OVMS v3 include: > > > - Use of the industry standard MQTT protocol, for easier third party > integration (in particular to IOT and home automation systems) > - Event driven model for scripting events in the car (such as > geofencing, homelink, charge settings, etc) > - 3G > - Wifi > - Bluetooth > - SD-CARD support > - Reduced power consumption, and low-power sleep modes > - Dramatically more RAM and FLASH memory, to overcome limits of PIC18 > architecture used by OVMS v2 > - Firmware updates via SD-CARD and USB, without any special > programming tools > - Over-The-Air (OTA) firmware updates via wifi and/or 3G > - Expansion slot and port for extra functionality > > > In the meantime, we continue to support OVMS v2. The hardware is still > available on fasttech site, but we are over half way through what we think > will be the very last batch. > > In other news, we have partnered with hologram.io to provide a cellular > network for OVMS users (both v2 and v3). Early feedback from our users has > been fantastic, and this is now running in a bunch of OVMS cars. Use of > this is entirely optional, and the cost-effectiveness will depend on where > you are in the world and what other cellular options you have. We're not > forcing you to use Hologram; just making it easy for you to choose them if > you want. OVMS v3 will come with hologram.io SIMs included as standard > (but easily replaced if you choose not to use it). For OVMS v2 users in > USA, with the imminent shutdown of the AT&T 2G network, we recommend > Hologram.IO now. You can get SIMs from Hologram directly at > https://hologram.io/store/, and Tom has penned an excellent write-up of > how to switch to Hologram at https://www.idleloop.com/ > tesla/ovms/hologram.php. > > Regards, Mark. > >

3 3