Who's in: Open-source project for CAN?

Hello everyone,

I've been here for a relatively short time, reading and posting comments more or less regularly.

In recent years, I have been involved in the development of open-source CAN solutions (interfaces, diagnostics, simulation) for vehicles.

Based on numerous questions here and in other forums, I am convinced that many people are lacking a flexible and open-source software solution (open in the sense of being largely configurable, thus suitable for various manufacturers, and freely available in the spirit of open-source).

Such a solution would also be suitable as a basis for commercial extensions and could therefore be used professionally if designed to be flexible enough.

My idea is to develop and provide such a solution collaboratively within the community.

Who has enough time and is willing to contribute their ideas and knowledge, and wants to participate?

I have experience in the areas of comfort diagnostics and variant encoding, and I have implemented solutions for these using microcontrollers and the ISO9141, ISO14230, and ISO15765 protocols.

We should discuss together the selection of a suitable IDE platform and development environment. Regarding hardware, I suggest supporting common interfaces with LAWICEL mode, as these are available in many different forms and at affordable prices.

So, I'm looking forward to hearing your feedback!

Best regards, Mike.

Hello Mike,

That's a really good idea.
I would like to participate.
Unfortunately, my time is very limited (I already have two part-time jobs), so I wouldn't be able to actively participate very much.
I would definitely follow the topic and, if appropriate, contribute ideas.

LG
Maxx.

Based on numerous questions here and in other forums, I am convinced that many people are lacking a flexible and open-source software solution (open in the sense of being largely configurable, thus suitable for various manufacturers, and freely available in the spirit of open-source).

(..)
Regarding hardware, I suggest supporting common interfaces with LAWICEL mode, as these are available in many different forms and at affordable prices.




Hi Mike,

What base technology were you thinking of? Microsoft Windows or the fun penguin operating system?

There's already an open-source project for the penguin.

http://developer.berlios.de/projects/socketcan

And if you look closely, there's also a driver there for (all) serial/quasi-serial adapters with the LAWICEL protocol.

https://lists.berlios.de/pipermail/socketcan-commit/2007-February/000140.html

There are also tools available like 'candump' or a color-animated 'cansniffer'.

Not quite a lack of open-source thinking.

Everything's already there!

Oliver.

Hello and thank you for the initial responses to this topic.

Unfortunately, these comments are typical of the kind of feedback I often encounter with similar project approaches: 'I would like to, but...' or, 'It already exists.'

More specifically, what I consider necessary and which has not yet been implemented anywhere is an application framework that allows for the development of various diagnostic applications through an open and flexible design.

I mean none of the usual OBD diagnostic tools with functions like Digimoto and Co., or other, quite nice car-PC gadgets!

For a CAN bus scanner, I don't need a full-fledged PC; a CAN-enabled microcontroller with an EEPROM for data logging and a 2x16 character display as the output unit is sufficient.

I'm envisioning a diagnostic application that, through appropriate configuration files, is capable of diagnosing various electronic control units (ECUs) in a manufacturer- and vehicle-independent manner, and also enabling ECU adjustments (where appropriate and necessary).

I envision the process as involving gathering requirements, discussing them, analyzing them, making decisions, creating a specification document, translating it into a roadmap, defining milestones, and then getting started.

Again, what should such an application be able to do?

- Diagnose of control units.
- Variant encodings enable...
- expandable through definition files (e.g., XML?)
- operate independently of the manufacturer.

Most modern automobiles now allow for diagnostics via CAN, although there are still regrettable examples, such as the RNS-E multimedia system in Audi, which still require a variant encoding to be implemented.

The varying speeds of different manufacturers are not a problem; with the appropriate configuration, this already works seamlessly on much smaller and less flexible platforms than a modern Windows PC.

But it's incomprehensible why you still need to install so many different software tools for just a few basic functions.

While it may not be possible to make every proprietary manufacturer protocol easily transparent through reverse engineering, and new approaches and technologies like authentication and encryption will make it even more difficult in the future, many vehicles today lack a reasonable platform.

Best regards, Mike.

The RNS-E does indeed allow for diagnosis via CAN (see A3 8P, TT II, and R). It's the vehicles in which it's installed (A4, A6, Lambo) that are not yet capable of CAN diagnosis (due to the lack of a CAN gateway between CAN diagnosis and CAN infotainment). With the RNS-E system, both methods can even be used simultaneously. For example, if you connect the K-line to the RNS-E in an A3 8P, you can access the system both via the K-line and the CAN bus.

Well, it seems this topic isn't generating much enthusiasm... so my commercial diagnostic solution will likely remain proprietary.

Okay, I'll start. Upload the source code, upload the source code to a CVS server, and I'll see what I can do.

Hi,

This topic only came to light thanks to spam...

Well, it seems this topic isn't generating much enthusiasm here... so my commercial diagnostic solution will likely remain proprietary for now.

Typical. It won't work like that. Go to SourceForge, upload the stuff there into CVS/SVN, and in 2-3 years, maybe 1 person will contact you (my experience), but if you really want to SHARE in the open-source sense, then you should do it and not play around with pointless maneuvers. Or don't.

Bye.
Manuel.

PS: And just a tip on the side: choose a BSD license, otherwise you're only shooting yourself in the foot, and you won't be allowed to do anything yourself. When it really matters, you usually don't have the money for a good lawyer, but maybe someone else does; then things can get really tough.
Sure, here's the translation:

'PS: Patent?' If you don't have a rich uncle to pay for the registration: publish it, so that no one else can patent it . Bild Zeitung probably does that for free.

The problem is simply:
Even if many nice people come together and start an open-source project, someone will eventually take the idea and use it to make money.
Generally, I'm glad that this (limited) knowledge is confined to a few forums where not too much is posted.

A video converter that I once wrote in C, and which I described as 'open source' for the VW RN S2 CD/DVD player, is now being commercially distributed by a large company.
Even my Easter egg is still in there, and they're now selling it, slightly modified, for the RNS 510.

That's all there is to say about the open source philosophy...