October 2014 - 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

Building with free C18 compiler
by Matt Beard 19 Nov '15

19 Nov '15

Have I missed a decision to no longer support the free C18 compiler - or has it been like that for ages? I am trying to fix an issue in the iMiev code, but can no longer build 2.6.5 due to needing the full compiler and no way am I paying £300 for it. Matt Beard

9 13

C2DM is deprecated, no new sign-ups
by Lee Howard 17 Nov '15

17 Nov '15

I've got my own OVMS server going. However, I wasn't seeing notifications on my phone (Android) since moving away from tmc.openvehicles.com. Looking at the ovms_server.pl code it appears that ovms_server.conf requires this section: [c2dm] email=<email> password=<password> accounttype=<unknown> [This "c2dm" section, along with the "server", "master", and "log" sections are undocumented in the docs/HOWTO.server.txt file.] Okay, so it would seem that I need to set-up a C2DM account with Google and put that info into the conf file. But, Google has deprecated C2DM in favour of Google Cloud Messaging (GCM), and Google is not granting any new C2DM accounts... http://developer.android.com/google/gcm/c2dm.html Is the C2DM account used by tmc.openvehicles.com a generic account that can be used by other OVMS servers? I suspect that it is a private account. If so, then push notifications for Android users on independent servers will necessarily require a transition to GCM. Thanks, Lee. -- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard(a)mainpine.com | www.mainpine.com

4 10

v2.6.7
by Mark Webb-Johnson 09 Dec '14

09 Dec '14

Its been a while, and quite a bit has changed, so time for a new firmware. Changes: Twizy updates Think city updates TR VECE updates Fix issue #135 (SMS response messed up for GPRS?, etc) Fix for net_msg handling of SMS LOCK, UNLOCK, VALET, UNVALET (and others) in Tesla Roadster module Make all SMS responses include the time (if possible), but add a carbits feature FEATURE_CB_SSMSTIME to allow this to be suppressed Allow ACC acc_handle_msg to choose to handle a particular message First implemention of net_fnbits NET_FN_CARTIME (as per http://lists.teslaclub.hk/pipermail/ovmsdev/2013-November/001819.html <http://lists.teslaclub.hk/pipermail/ovmsdev/2013-November/001819.html>) For the NET_FN_CARTIME, this is enabled in vehicle modules by setting net_fnbits |= NET_FN_CARTIME during initialisation (see vehicle_obdii.c for an example) and then not adjusting car_time at all. The car_parktime can be set as normal (using car_time as a reference). This is completely untested (I’ve somehow lost GSM connectivity to my workbench in the last week or two, so this is proving hard for me to test). The logic for NET_FN_CARTIME is implemented in three places: The vehicle.c implements initialisation of car_time. The led.c implements an interrupt to increment car_time every second. As we treat 104.8576ms as 105ms, we are 0.1424ms inaccurate for each clock tick, which may build up over time (but is still more accurate than the previous approach). The net.c implements handling the response to +CCLK polls, and adjusts car_time and car_parktime if necessary. I’d appreciate it if someone with better connectivity on their workbench could help test this, and fix as appropriate. Hopefully we can get any bugs in this worked out over the next few days and when it is working change the vehicle modules to use it and then cut a firmware v2.6.7. Regards, Mark.

3 6

module GPRS connection frequency
by Lee Howard 11 Nov '14

11 Nov '14

For those of you using unlimited data plans this may not matter, but for those of us using per-use/per-minute/per-MB plans the frequency at which the OVMS module connects via GPRS to the OVMS server is quite relevant for the long-term cost of using OVMS. For example, I'm using AT&T "GoPhone" per-minute plans which basically result in a $0.01 charge every time the OVMS module connects via GPRS to the OVMS server. The OVMS module does this a bit more-frequently than I had anticipated... about 3X more frequently. Consequently, I was a bit surprised to find what I had hoped to be a $100-per-year account get used faster than that... requiring me to add $100 to the account every four months or so. So the per-minute/per-use/per-MB plan I'm on ends up not really being less-expensive than their $25 per-month plan. I see that the OVMS module is connecting with the OVMS server roughly every 7 minutes... even if the car is stationary and there have been no changes to SOC or other vehicle information. I see this behaviour both with module type "VA" and "XX". I would prefer to see the OVMS module connect with the server with *greater* regularity (like, every 2 minutes) when GPS position is changing (more than the expected 60-meter or so "jitter" that I usually see) or when SOC is changing or some other information changes. However, if the vehicle is stationary and there are no SOC changes or other information changes, then I would prefer to see the OVMS module connect to the OVMS server very infrequently... like only every 30-90 minutes. Is this, by chance, something configurable? Or is this something that I'm going to need to build-into the firmware, myself? Thanks, Lee. -- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard(a)mainpine.com | www.mainpine.com

3 6

Re: [Ovmsdev] Contents of OvmsDev digest...
by Gianluca Magalotti 30 Oct '14

30 Oct '14

Flame on > or tell auto-pilot to drive the car to my location. Wow! mark do you think would be possible to add such feature in ovms in next firmware release? Flame off :) I think the only ovms limit is the communication layer and the vehicle - server - client model (that I prefer over the local communication one because of the wider list of functionalities that this model can provide). I think the real problem is the very heterogeneous markets of data plans. Maybe an umts modem would make simpler connection matters but wouldn't resolve that. When m2m sim would be commodities all over the world (and moving toward an IOT era this cannot be delayed more) this won't be a problem any longer. Until then maybe would be nice to let "switch off" some communication behaviors (position, battery status and so on) or throated as "on demand".

1 0

Re: [Ovmsdev] Tick math
by Gianluca Magalotti 23 Oct '14

23 Oct '14

Ok, so you every 104.8576ms will add 5243MarkSecs (just invented a new time unit) right? And when the counter reaches or pass 50000 you add one second and subtract 50000 to the count. This way you are over 0.0024ms per timer interrupt, roughly 0.022ms per second, that is less than 2s per day (that is, every 43690s we count one second more.) Please check my math.... But you won! Gianluca Magalotti dal mio iPad mini > Il giorno 22/ott/2014, alle ore 06:00, ovmsdev-request(a)lists.teslaclub.hk ha scritto: > > Sorry, in my P.S., I think I miscalculated the improvement. > > 1] Current methodology: > > Signed 16 bit integer > Every 104.8576ms timer interrupt, add 105ms to the counter. > If counter >1,000 treat it as 1 second and deduct 1,000 from counter. > > Accuracy: loses 0.1424ms per timer interrupt. > > 2] 50ms methodology: > > Signed 16 bit integer > Every 104.7576ms timer interrupt, add 5243 to the counter. > That is equivalent to 5242.88 50ms chunks. > Difference is 0.88 / 50 ms > Accuracy: loses 0.01760ms per timer interrupt > > Or, is my new maths wrong? Is the inaccuracy 0.01760ms or 0.12ms per timer tick? > > Confused, I am. > > Mark.

5 7

Re: [Ovmsdev] The meaning of life and universe
by Gianluca Magalotti 22 Oct '14

22 Oct '14

And with this feeling we can look at the sky! :-) Gianluca Magalotti ITIL® 2011 Foundation Certified Cobit 5 Foundation Certified email: gianluca(a)magalotti.net Mob: +39 3474 3474 25 Linkedin: http://www.linkedin.com/in/gianlucamagalotti/ > Il giorno 22/ott/2014, alle ore 15:37, ovmsdev-request(a)lists.teslaclub.hk ha scritto: > > I think that is about 0.39 seconds a day, but we have solved the answer to life the universe and everything.

1 0

Forums
by Mark Webb-Johnson 22 Oct '14

22 Oct '14

Just a short note to say that I've had to take the forums on www.openvehicles.com offline. A few reasons: Most of the questions there were support questions, and the questions weren't getting answered. The forums were almost never used - just one or two posts a week. The forum module itself has very few features and no notification capability. Too many spammers signing up for accounts so that they can write forums posts about how much their sister is earning per hour. Bottom line is that it was just wasting too much time, and that is time better spent on the project itself. I've kept the old content for the moment - just disabled it for everyone except administrators. Regards, Mark.

1 0