Open Vehicle Monitoring System

[PV-EV]

Got it. Looks good. Thanks for all your hard work.

 

[markwj]

Dear OVMS users,

The first batch of OVMS hardware to developers has started to arrive, and so have the first questions, so I just wanted to let you all know the location of two mini-FAQs, and how to get help and contribute.

Firstly, there is a pretty basic HOWTO guide available under github:

docs/HOWTO.car.teslaroadster.txt at master from markwj/Open-Vehicle-Monitoring-System - GitHub

It covers most of the basics of getting the hardware programmed, configured, and into the car.

When programming for the first time, we recommend you use the 1.0 github branch as it appears to be the most stable. The MASTER HEAD is very raw and a lot of work is currently being done on it. So, use the stable 1.0 branch to begin with, then when you are more comfortable and ready to contribute then move on to the bleeding edge MASTER HEAD.

Secondly, we have created a mini-forum system on the Open Vehicle Systems website, for us all to discuss and ask questions. It is really basic, and we're not sure if it will work out long-term or not, but worth a try. We don't really want to pollute these TMC forums with our development / project discussions, at this early stage. You can find the Installation thread at:

Installation questions | Open Vehicle Systems

and the forums themselves at:

Forums | Open Vehicle Systems

I'm really glad that the hardware for the first batch is arriving before the xmas holidays. Hopefully you guys can get it installed and let us know your experience with the system. We need this running in lots of different versions of the cars and cellular networks, to get experience before a wider release. At the moment, the biggest thing you can contribute back is feedback. Let us know what version of cr you had, and any issues you had (or didn't have - let us know!).

After that, the next thing we need help with is installation documentation. We're working on a short getting started guide and video, and once the basic version of that is done (hopefully within the next few days), I hope you guys can contribute to it and extend it with your own experience and hints/tips. I'm particularly interested in how you guys handle installation. In Hong Kong, we've done it one way, and I'm already hearing of different alternatives that we wouldn't have thought of here (eg; antennas high up on the passenger door frame, under the speedometer cowling, etc). It will also be interesting to see the LHD vs RHD differences.

The second batch of hardware is going out now, and hopefully you should receive this in the coming few days. From this point on we have stock for anyone that wants it. We're still holding-off on a non-developer release until we've got more experience and the code has had time to stabilise.

If you need anything, please let us know - either by email or the forums (TMC, openvehicles, whatever).

Thanks for your support of this project, and I hope you all have a very good xmas (with OVMS in your cars).

Regards, Mark.

 

[markwj]

A couple of nice features just got added to OVMS:

1] A digital speedometer

Spoofing CAN bus message ID#0x400 B1=0x02 (which is the source of the dashboard display for battery meter, range and amps), we can display the speed on the little orange dashboard display.

Code v1.0.7 has this as an optional (defaults: off) experimental feature that is active when the car is ON (and deactivates itself when the car is turned OFF).

2] Parking timer

The timer starts automatically when you turn the car OFF, and is shown on the apps. Other functionality could be added by the apps themselves (such as alarm timers for a user-defined parking meter time).

The car code v1.0.7 supports this, and the iOS (iPhone, iPad, iPod Touch) App has been updated. We'll probably hold-off releasing this to Apple App Store until the v1.1 changes are ready, as we don't expect that to be too long. Android support will follow soon.

As we work in the open, all this code is on the github repository.

Regarding the end-user release, we're getting there. Just getting this code in as many developer cars as possible to gain experience and ensuring that there are no problems. So far, it is looking good, and we are real close. Thanks for your patience.

Regards, Mark.

 

[tomsax]

A digital speedometer.

That's pretty damn cool!

 

[jcstp]

I wonder if OVMS will be applicabel in the new RAV EV. It has the TESLA drivetrain, so it might be possible!

 

[markwj]

I wonder if OVMS will be applicabel in the new RAV EV. It has the TESLA drivetrain, so it might be possible!

It should be applicable to any car with a CAN bus (i.e.; any modern car). EVs in particular.

There has also been interest in using the platform for other things (such as data logging).

The biggest issue is decoding the CAN bus messages. Without a manual documenting them, it is a challenge. As you say, perhaps the RAV EV would be similar as it shares a lot of the Tesla design.

 

[dsm363]

Since the Roadster will no longer be built, do you think Tesla would be willing to share some documentation or answer questions from you about what messages do what? They probably wouldn't but would make your project easier since they're not willing to do that work.

 

[widodh]

It should be applicable to any car with a CAN bus (i.e.; any modern car). EVs in particular.

There has also been interest in using the platform for other things (such as data logging).

The biggest issue is decoding the CAN bus messages. Without a manual documenting them, it is a challenge. As you say, perhaps the RAV EV would be similar as it shares a lot of the Tesla design.

I can't wait till mine is in!

I ordered my machine2machine SIM today with a 5MB dataplan, should be sufficient.

I plan to log all the data from the roadster coming into the server and maybe use it for some other cool stuff, cool graphs or so!

 

[Fuzzylogic]

5MB is more then enough.
I'm using a Simyo prepaid card (KPN network), i have been using the OVMS module since December the 14th, so far it used only Eur 0,48 total for data.

 

[markwj]

Since the Roadster will no longer be built, do you think Tesla would be willing to share some documentation or answer questions from you about what messages do what? They probably wouldn't but would make your project easier since they're not willing to do that work.

I doubt it. They might share under NDA, but as we are open source, that is not possible.

At this stage, we understand and have documented 95% of the important messages anyway.

 

[vfx]

I doubt it. They might share under NDA, but as we are open source, that is not possible.

At this stage, we understand and have documented 95% of the important messages anyway.

Linux?

 

[markwj]

Any drupal / php developers out there willing to urgently give some time for the OVMS project? Pulling my hair (what little I have left) out trying to get the vehicle management module done.

 

[W.Petefish]

Any plans to implement any of the battery charging features? (i.e. change from standard to range mode)

 

[markwj]

Any plans to implement any of the battery charging features? (i.e. change from standard to range mode)

Short story:

This is a US$100k+ car that we're plugging into, and we're being cautious with what we do.

Developer firmware has the ability to do this, and support is currently being added. It will appear reasonably soon.

End-user firmware runs in listen-only mode and doesn't transmit on the bus in any way, so can't do this in its default config (by choice). But, things may change in future (when we have more experience with this and we are running in more vehicles).

I normally run end-user firmware in my car (personal choice), but play sometimes ;-)

Long story:

There are three ways (software configuration of the CAN bus hardware driver chip) that we can connect to the CAN bus:

1] LISTEN only mode - the module just "taps" the bus, never acknowledges any messages and can never transmit anything onto the bus.

2] ACTIVE read-only mode - the module participates on the bus, can acknowledge bus messages, but won't transmit messages (but only because we have chosen not to).

3] ACTIVE read-write mode - the module participates on the bus, can acknowledge bus messages, and transmits messages.

To do something like the SPEEDO feature, or change charge mode, requires ACTIVE read-write mode (3). To just listen on the bus and show what the car is doing requires LISTEN mode (1). Obviously, transmitting on the bus is far more invasive than just listening.

The choice of mode is set in software. Developers can set it however they want when they build and flash the firmware.

We want to minimise the impact on the car as much as possible, so for the default end-user firmware we have currently chosen mode 1 (LISTEN). This has almost no possibility of impacting the car - with the worse case being a hardware fault causing a short on the bus - that will stop car systems like VMS working but removing the short immediately resolves the problem. This is the absolute safest way of doing this. We're still discussing this, and nothing is fixed, but that is what we are leaning towards for the short-term.

The developer firmware works in mode 3. For mode 3, we have recently added support for messages App->Server->Car and we have messages to start the charge, stop the charge, and change the charge mode (range, standard, etc). Those functions should be implemented in the apps real soon - or someone can step up and implement them sooner ;-) The messages themselves are identical to the car messages we have reverse-engineered and confirmed in real cars, so should be relatively safe - but we are spoofing the messages (as if they can from the VDS).

Regards, Mark.

 

[markwj]

We want to minimise the impact on the car as much as possible, so for the default end-user firmware we have currently chosen mode 1 (LISTEN). This has almost no possibility of impacting the car - with the worse case being a hardware fault causing a short on the bus - that will stop car systems like VMS working but removing the short immediately resolves the problem. This is the absolute safest way of doing this. We're still discussing this, and nothing is fixed, but that is what we are leaning towards for the short-term.

It would be interesting to hear members / potential user feedback on this.

Would you like:
a) The safest possible device, but with read-only monitoring functions
b) A device that could transmit messages on the bus (mode 2 at least), but with the transmission turned off by default (but able to be enabled by the user)
c) The whole lot - full functionality enabled by default

My vote would be either (a) or (b), and I'm on the line as to which.

 

[widodh]

I'd say A or B. We had such a device in the Roadster, but it was doing something weird on the CAN-bus and causing all kinds of errors in the VMS and even preventing you from 'changing gear'.

Ofcourse, changing charge mode would be great, but I wouldn't enable it by default.

 

[Kevin Sharpe]

I'd run with A for now and build up a user base to confirm solid hardware and firmware. This will make debugging B much easier :wink:

 

[W.Petefish]

IF it was easily enabled B. Or like I have the developer version C.

 

[felixtb]

i am not a developer but I think B or C since the whole point of having the device is to be able to change charging mode and interact with the car. so unless the system is extremely buggy I would go with B or C or just wait to release until you have the worst bugs out of the system with the current developer base!

thats my two cents

 

[markwj]

i am not a developer but I think B or C since the whole point of having the device is to be able to change charging mode and interact with the car.

I see a core set of requirements, and then a large number of pet 'wants'. And, that is the whole point of the project - to serve as a common base that a large number of enthusiasts can get behind, so we can leverage each other's work.

Since installing OVMS, I have never needed to change charging mode remotely. But, the recent automatic parking feature came from one developer's requirement, same for Minimum SOC alerts - and I never thought I would need those either ;-)

I suspect that there will be many more such features that are nice-to-have.

I'd say A or B.

I'd run with A for now and build up a user base to confirm solid hardware and firmware.

IF it was easily enabled B. Or like I have the developer version C.

so unless the system is extremely buggy I would go with B or C or just wait to release until you have the worst bugs out of the system with the current developer base!

Thanks for the feedback (and from others off-list).

Given the issues with end-users updating firmware, what we've decided is something along the lines of A+B.

We're going to move the bus mode switch out of compile-time and make it a run-time option. Similar for most of the other functions.

We have a 'sys_features' facility where things can be turned on/off by the user at run-time. So, the write-enable switch, and other such functions, will be moved into sys_features, and default to off. That way, they are available if the user wants to enable them (and live with the increased risk).

The end-result is a system that by default behaves like A, but can be moved to B or C by the end-user.

I think this will give us the best of both worlds - a stable tested base, but with the ability for the end-users to enable more 'experimental' features on a case-by-case basis.

Regards, Mark.