Finding Your Inner Fish Pdf File

In this post I will report about my experiences and studies about vehicle electronics. Last edited on jun 27, 2012 CAVEATS: I found that the generally available informations about this subject on the internet is quite poor and not very clear. While I am trying to do my best in verifying, errors and mistakes could be present. Please feel free to add your critics and comments. This is going to be a long term project, so this page will be improved over time. Cars are complex Cars are getting complex.

Fish are the gill-bearing aquatic craniate animals that lack limbs with digits. They form a sister group to the tunicates, together forming the olfactores. Download a classroom guide for the film in.doc or.pdf format. Download teaching slides and find more information about Tiktaalik at the Tiktaalik roseae site. Find educational resources related to Your Inner Fish and access to thousands of curriculum-targeted digital resources for the classroom at PBS LearningMedia.

Car electronics is really sophisticated, and current cars have dozens of control units for managing devices, sensors, and actions. ECUs: Elecronic Control Units The Control Units talk on local vehicle networks, which are similar to a common computer LAN, but based on different protocols. ECUs, Engine Control Units, were the first to be connected to vehicles network, soon followed by others ECUs (generic Electronic Control Units). To reduce the amount of signal wires among the many electric components of a modern car, digital communication protocols were introduced, and digital electronic interfaces between every electric device and the communication infrastructure. The most important ECU is the Engine Control Unit. Here is a non-exaustive list of Engine Control Unit manufacturers for cars: BOSCH (example: EDC16), MAGNETI MARELLI (example: 95160), SAGEM (example: 95080), SIEMENS (example: TMS374).

Is a PDF file from the chinese company (a supplier of car electronics and diagnostic devices) with pictures of many Engine Control Units. STANDARDS: a terrible headache There are many standards defining protocols, signals, diagnostics. Here is a probably incomplete and maybe wrong list SAE and ISO are the most common standard and documents frameworks, but there are many others is the Society of Automotive Engineers. SAE defines Communications Standard utilized in On-and Off-Road Land-Based Vehicles. In this schema 3 classes of communicating devices are explained: CLASS A: up to 10Kbit/sec, multipurpose, asynchronous, used for non-realtime, smart sensors, wire reduction. CLASS B: in the range 10Kbit/sec up to 125Kbit/sec, used for intermodule data transfer and non-realtime control. SAE J1850 is a CLASS B protocol, currently used for low-cost connectivity between nodes like instrumentation and diagnostic devices.

CLASS C: critical, high speed, realtime communications between device. For these needs, hi-speed CAN is currently used (up to 1Mbit/sec), but there are also faster alternatives, like (up to 10Mbit/sec, firstly implemented in BMW X7 X6 in 2008 ). Describes two different protocols: a low speed single wire VPW (Variable Pulse Width) protocol running at 10.4Kbit/sec and a faster two wire differential PWM (Pulse Width Modulation) protocol running at 41.6Kbit/sec. This is NOT CAN nor is it compatible with CAN. VPW is classically used by GM (General Motors) vehicles. PWM is classically used by Ford vehicles.

ISO_9141-2 is not a signaling protocol, but a diagnostic interface to check vehicle component functionality. It is a serial interface that runs at 9.6Kbit/sec. It is often available in OBD-2 connector. ISO_11992 is a CAN bus used in trucks for communications between the tractor and the trailers. Is a set of specification based on an underlying CAN infrastructure, working with 29bit identifiers and usually with a bit rate of 250kbit/sec. This is normally used in trucks and industrial vehicles.

It is a prerequisite for the FMS (see forward) system to work. An introduction to SAE_J1939 by Marcus Junger can be found on Vector site. Free Jet Photo Studio Free Download - Free Full Version 2016. Other J1939 infos are on. See also, and. According to, SAE_J1939 supersedes SAE_J1708 and SAE_J1587. Is a list of Automotive data buses, by Leroy Davis. Vehicle Networks Actually there are many vehicle networks, eventually based on different standards, different criticality, different protocols, and different communication speeds.

Currently these networks are converging to the CAN standard, but there are many others. Since CAN is now the de-facto standard for vehicle networking, sometimes it is also identified as VDB (Vehicle Data Bus). Despite its popularity, CAN bus is not the only network inside any modern vehicle, and in a single vehicle there are usually different networks (multiple CAN networks and NON-CAN networks). CAN CAN stands for Controller Area Network.

It was originally developed by Bosch, starting in 1983. CAN is used in many automation environments and not only in automotive industry. In a CAN bus all the communicating devices are connected to the same two wires, labeled CAN-High and CAN-Low. All the devices must use the bus at the same speed. At each end, the two wires are connected with a 120 ohm termination resistor. It is not required to have a common ground signal among the communicating devices. Bus maximum length is dependent from the operational speed, and at 1Mbit/sec is about 40m.

Vehicle network bus speeds are usually below 500Kbit/sec. High speed bus vehicle implementation often adopt twisted pair wires. Ruiz Zafon El Juego Del Angel Pdf Gratis.

In a normal situation, the two wires carry a two-level signal, perfectly specular, and whenever one is high the other is low. Here are two nice pictures (source: ) representing oscilloscope reading of the two wires of a CAN bus. The second image allow a clear understanding of the specular nature of the signals. The CAN Protocol Currently there are two main version of the CAN protocol Standard CAN: 2.0A with 11bits identifiers Extended CAN: 2.0B with 29bits identifiers CAN is defined in ISO_11519 and ISO_11898. ISO 11898-2 defines the high speed CAN, up to 1Mbit/sec ISO 11898-2 high speed ISO 11898-2 is the most used physical layer standard for CAN networks. It describes the bus access unit (implemented as CAN high-speed transceiver) functions as well as some medium-dependent interface features.

In this standard the data rate is defined up to 1 Mbit/s with a theoretically possible bus length of 40 m at 1 Mbit/s. The high-speed standard specifies a two-wire differential bus whereby the number of nodes is limited by the electrical busload. The characteristic line impedance is 120 Ohm, the common mode voltage ranges from -2 V on CAN_L to +7 V on CAN_H. The nominal specific propagation delay of the two-wire bus line is specified at 5 ns/m. All these figures are valid only for a 1 Mbit/s transfer rate and a maximum network length of 40 m. In order to achieve physical compatibility all nodes in the network must use the same or a similar bit-timing. For automotive applications the SAE published the SAE J2284 specification.

For industrial and other non-automotive applications the system designer may use the CiA 102 recommendation. This specification defines the bit-timing for rates of 10 kbit/s to 1 Mbit/s. It also provides recommendations for bus lines and for connectors and pin assignment. ISO 11898-3 (aka ISO 11519-2) defines the fault tolerant (and lower speed) CAN, up to 125Kbit/sec ISO 11898-3 fault-tolerant An alternative form of bus interfacing and arrangement of bus lines is specified in ISO 11898-3 (fault-tolerant CAN). This standard is mainly used for body electronics in the automotive industry.

Since for this specification a short network was assumed, the problem of signal reflection is not as important as for long bus lines. This makes the use of an open bus line possible.

This means low bus drivers can be used for networks with very low power consumption and the bus topology is no longer limited to a linear structure. It is possible to transmit data asymmetrically over just one bus line in case of an electrical failure of one of the bus lines. ISO 11898-3 defines data rates up to 125 kbit/s with the maximum bus length depending on the data rate used and the busload. Up to 32 nodes per network are specified. The common mode voltage ranges between -2 V and +7 V. The power supply is defined at 5 V. Transceiver chips, which support this standard, are available from several companies.

The fault-tolerant transceivers support the complete error management including the detection of bus errors and automatic switching to asymmetrical signal transmission. The preceding two quotes of text about CAN physical layer specifications are taken from here (fetched on dec 4 2010): Also there are other physical layer standards. The following section is shamelessly copied from Staffan Nilsson (with some corrections) ----------------------- ISO 11898-2 voltage levels (CAN High Speed) Signal recessive state dominant state unit min nominal max min nominal max CAN-High 2.0 2.5 3.0 2.75 3.5 4.5 Volt CAN-Low 2.0 2.5 3.0 0.5 1.5 2.25 Volt Note that for the recessive state, nominal voltage for the two wires is the same. This decreases the power drawn from the nodes through the termination resistors. These resistors are 120ohm and are located on each end of the wires.

Some people have played with using central termination resistors (that is, putting them in one place on the bus). This is not recommended, since that configuration will not prevent reflection problems. ISO 11519 voltage levels (CAN Low Speed) Signal recessive state dominant state unit min nominal max min nominal max CAN-High 1.6 1.75 1.9 3.85 4.0 5.0 Volt CAN-Low 3.1 3.25 3.4 0 1.0 1.15 Volt ISO 11519 does not require termination resistors.

They are not necessary because the limited bit rates (maximum 125 kB/s) makes the bus insensitive to reflections. The voltage level on the CAN bus is recessive when the bus is idle.

Bus lengths The maximum bus length for a CAN network depends on the bit rate used. It is required that the wave front of the bit signal has time to travel to the most remote node and back again before the bit is sampled.

This means that if the bus length is near the maximum for the bit rate used, one should choose the sampling point with utmost care - one the other hand, one should always do that! Below is a table of different bus lengths and the corresponding maximum bit rates. Bus length (metres) Maximum bit rate (bit/s) 40 1 Mbit/s 100 500 kbit/s 200 250 kpit/s 500 125 kbit/s 6 km 10 kbit/s Cables According to the ISO 11898 standard, the impedance of the cable shall be 120 +- 12 ohms. It should be twisted pair, shielded or unshielded. Work is in progress on the single-wire standard SAE J2411. ----------------------- CAN frames Here are some informations about CAN data frames the following picture is from The Standard and Extended frames are shown, and the different address field length can be seen.

The CAN controller actually speaks with the device in some way (for example via a serial RS232 interface) and on the other Many manufacturers produce CAN line driver integrated circuits, for example Dallas Semiconductors/MAXIM or Microchip.or Philips. Or Philips/NXP The following picture shows a generic CAN bus with some devices connected. Proper bus termination should be present at each bus end to damp electric signal reflection (echos).

Also it is important to minimize length of the connection between the bus and the transceiver of each connected device (for minimizing undesired echo effects). Such a device is indeed a firewall with sophisticated packet content filtering and rewriting capacity. Here is a document describing a CAN gateway device in a Volkswagen Golf car The following two paragraphs are taken from The role of the Gateway (also known as the Data bus diagnostic interface J533) is the exchange of data between the CAN data bus systems (‘powertrain CAN data bus’, ‘convenience CAN data bus’ and ‘infotainment CAN data bus’) and the conversion of diagnostic data from CAN data bus systems to K-cable and vice versa so the data can be used by vehicle diagnosis, testing and information systems like the dealer VAS tools and Vagcom/VCDS. For various reasons including power drain issues with third generation head units or the addition of new unsupported modules the CAN bus gateway must be upgraded to a newer revision. This guide covers the replacement of the CAN bus gateway in a 2005 MY06 Volkswagen Golf GTI. The upgrade replaces the 1K0 907 530 E (1K0907530E) with a 1K0 907 530 AA (1K0907530AA).

Here is a picture of the Volkswagen/Audi gateway (part no: 1K0907530AA), taken from. This gateway in Volkswagen terms is called 'Data bus diagnostic interface J533'.

It is used in many car models from this vendor. I found an Audi technical document (from Audi A5 owners group website ) describing the 4 different version of this gateway component (differences are in terms of its interfaces), for different car models. It is connected to many different buses (different CANs, LIN, MOST). The document states that the 'transport mode' can be activated on demand. I guess that this transport mode could allow flow of information between the different buses thru the gateway itself (that in this mode acts somewhat like a router).

Check also this about J533 gateway. OBD: On Board Diagnostic Due to the progressive diffusion of electronic devices in the vehicle industry, also diagnostic procedures started to rely on querying these different pieces of electronics, for troubleshooting, and parameter tuning. The On Board Diagnostic (OBD) standards define how these diagnosis can be performed. Each Control Unit has a set of Diagnostic Trouble Codes (DTC) that can help in identifying its status or eventual failures. Actual diagnosis is performed by a technician connecting a probing device to a specific plug inside the vehicle, and performing analysis.

In many vehicles, the OBD connector (currently usually compliant to OBD-2 standard) is within reach from the driver seat, and allows access to at least one of the vehicle CAN buses. Over the years, many different versions of the OBD standard appeared, and the most current one is labeled OBD-2 or OBD-II, which uses a female 16-pin (2x8) SAE J1962 connector on the vehicle. Here is the pinout of its female connector (from ). Specific gateway configurations could be needed so to allow specific Electronic Control Units traffic (filtering) to be available on the OBD-2 CAN interface. Also, depending on the manufacturer and model, CAN bus availability on the OBD-2 connector could require a specific configuration elsewhere (maybe jumpers in the circuit breaker panel). Being present in many vehicles, the OBD-2 connector usually allows access to many diagnostic signals.

Sometimes more than one CAN bus is made available on the connector, on different pins. Here is the pinout of the FIAT OBD-2 connector: Some 'rules' about the OBD-2 connector (info from and ) If pin 5,6,14,16 are connected, the pins 6 and 14 are CAN-HI/LOW (ISO_15765-4 / SAE_J2284), while pin 5 is ground and pin 16 is 12Vcc If pins 5,7,16 and optionally 15 are connected, the connector supports access to ISO_9141-2 (aka KWP): pin 5 is ground, pin 16 is 12Vcc, pin 7 is ISO-data (aka ISO_K-line), as well as optional pin 15 which is older ISO_9141-2 (aka ISO_L-line). If pins 2,5,16 are connected, the connector supports access to VPW_J1850: pin 5 is ground, pin 16 is 12Vcc, and pin 2 is VPW-data If pins 2,5,10,16 are connected, the connector supports access to PWM_J1850: pin 5 is ground, pin 16 is 12Vcc, and pin 2 and 10 are PWM-data Connector Pins 1,3,8,9,11,12,13 (if connected) are used differently from different vehicle manufacturers, and the OBD-2 standard does not define their role. Contact usage of some manufacturers (table from ): Pin SAE J1979, ISO 15031 GM Fiat Opel Saab Isuzu GM-LAN since 5.2002 1 Manufacturer mandated second UART ABS, Brakes, K-Line reserved Saab Instruments (+) SIR (GM8192 Prot.) SW-LS-CAN (33kB) or DW-FT-CAN (+) (. Peugeot BSI is connected and 'coupled' to Engine Control Unit, and there are protections to avoid tampering by non official dealers or auto-repair technicians. Here are a set of warnings related to Peugeot BSI-ECU maintenance: is a picture of a Peugeot BSI. Peugeot/PSA cars used to implement their own version of CAN bus, called VAN (Vehicle Area Network Comfort data VAN bus / Body Control Data bus).

I found some clever guys who did some awesome job in collecting information about VAN: Graham Auld, and Alessandro Zummo. Check and I got to these sites via webpage. Accessing CAN in trucks Specifically for trucks, there is another standard, to have a uniform access to vehicle data, and targeted for the needs of driving monitoring devices. This FMS (Fleet Management System) standard is very important for allowing access to specific truck information like the tachometer and odometer, which are needed to be read in the devices to control the driver activity (digital tachographs).

FMS requires a SAE J1939 CAN 29-bit 250kbit/sec underlying standard. For european digital tachographs, check In order to be compliant with FMS standard, truck manufacturers implement a specific gateway ECU which reads the informations required by the standard from all the suitable places and thru all the required standard, complying with internal vehicle-brand-specific protocols, and makes all these informations available thru a specific CAN bus to which the tachometer device is connected. In this way, an FMS compliant digital tachometer devices can be easily connected to any FMS compliant truck.

Different connection cables (this section needs work and it is partially outdated by what I wrote in the OBD-2 connector section) A number of different ready made cables exist to access car diagnostics, usually via the aforementioned ODB-2 connector here is a list of their names, but I am far from understanding their differences SAE J1850 (can be a dual wire differential 41.6 Kbit/s PWM -Pulse Width Modulation-, or a 10.4Kbit/s VPW singlewire -Variable Pulse Width- ). See intel document. SAE J2534 (this is a PWM protocol used in Ford, Lincoln, Mercury, Mazda vehicles) K-LINE and L-LINE (ISO 9141-2) (to be explained: i need to study) ISO 14230-4 (also known as KWP) PWM CAN HS-CAN (iso 15765) VAG-COM is not a cable, but a product by Ross-Tech. It is a diagnostic windows software for Volkswagen/Audi.

Some cables to be used with this software are labeled VAG-COM ELM 32x are integrated circuits, (here is description), sold by and based on. These ELM chips act as generic ODB2 decoders and are able to identify and decode many of the different signals available on the ODB2 plug, converting them to RS232, suitable for connection to a PC. Many different PC diagnostic software are capable of interfacing with car electronics via an ELM based adaptor, like (To Be fixed) Arduino and CAN It is possible to interface an Arduino 2009 board with CAN bus, via a specific CAN shield I successfully used, to connect to an Audi A6 (2003) and I was able (using the provided sample application) to successfully read RPM (revolutions per minute) data from the engine using a polling mechanism. We are currently working on improving the code provided with the shield so to have more sophisticated functions. Oct 2011 Note: As Rick (in an anonymous comment) said, Sk-Pang shield uses a library taken from Fabien Greif code ( here is the main site: ).The code can be improved, and I hope I will have some time to dedicate to this. OBDuino This is a project, started in 2009, to use a custom Arduino-like board to interface to car CAN-Bus and build a The project is described in this wikipedia page: and the code repository, along with some pictures of prototypes, is in a google-code page, here: MPGuino This project is targeted to build a fuel measurement computer, with an Arduino like device, analyzing the impulses to the fuel injectors, and having tables for calculating the specific fuel injected basing on impulse duration.

The signals have to be directly read/taken from the main engine ECU connections to the fuel injectors. Data appears extremely accurate.

Here is the link: Teltonika FM4200 This is a device specifically designed to interface with FMS CAN interface in trucks. I am also testing device, which uses a NXP LPC2368 microcontroller which is (incidentally) the same uc used by the project. Is some info about the microcontroller which includes a CAN controller (but not a CAN transceiver). The FM4200 circuits utilizes a Texas Instruments 3.3V CAN transceiver. I will write more about this device, as soon as I will have performed more thoroughful tests. CAN Bus data reverse engineering: For a Toyota Prius car, by Attila Vass: For a SAAB car by Tomi Liljemark: General References and links The great CAN-CIA site: which is probably the best and more reliable reference site available.

The: contains a definition of most of the acronyms and abbreviations. Staffan Nilsson's great page about CAN: Bosch CAN 2.0. Mike J Schofield pages: (non working url: - there is a mirror in Staffan Nilsson site) CAN analysis and equipment vendors: I bought an EMS-Wuensche CPC-USB/ARM7 with galvanic optoinsulation and lowspeed transceiver (TJA1054) for automotive.

Received the object (2010.dec.10), and first impression is good: seems very well built and reliable. Will soon test it on the field. CAN bus in motorcycles Of course, also motorcycles electronic utilizes digital protocols. Is a page about CAN bus in BMW motorcycles.

An affordable and cheap Oscilloscope Actually I ordered this, but I am still waiting the device to arrive. Will be able to report on its features, as soon as I evaluate it. Here are informations about the scope: Software FreeDiag: FiatECUScan is a software for analyzing Italian made cars (fiat/alfa/lancia branded). Comes in free version and in paid version, with different features.. Here is a of the vehicles supported by current version of FiatECUScan. FAQ: Q&A Here are some questions I received by email and the answers I sent. Q: Is it possible to read value of XXX connecting to the can bus of my car?

A: As quick answer I would just say that it is not possible. But this impossibility is normally not due to physical reasons. Each ECU manufacturer uses its own set of rules & codes to craft data packets on their vehicles networks. These informations and data formats are not readily available, and there are no shared rules followed by different manufacturers. Fm4200 is designed to be able to decode FMS CAN, which is a standard data format representation accepted and shared by all industrial vehicles (trucks). The target is to allow tachometer interconnect with vehicle dashboard. Tachometers are devices that in many countries MUST be installed on trucks so to monitor driver behavior and work activities.

Since there are many tachometer devices, which are built and installed by many countries certified suppliers, a standard was needed, so FMS was born. Non-professional access to tachometer data connection is generally prohibited. Thru car databus reverse engineering techniques, mostly based on trial and error and/or leaked informations, it is theoretically possible to map some of the CAN data packets to their meanings. Generally read only approach is safe. But problems could arise when vehicle software maintenance is performed, because data packet meaning could change, and current manufacturers are not expected to openly disclose these details. Write access to the drivetrain and engine bus is to be considered critical and is generally explicitely forbidden or strongly not recommended. For sure it could be great if all the data was understandable and accessible, but there are important security implications if people irresponsibly tamper with these things.

Vehicle security, insurance coverage and road safety could be impacted. So, be careful and play always on the safe side.

My suggestion is to NEVER connect untrusted devices, unknown or potentially unreliable closed source software to critical systems. Always study, learn and understand before playing.

And always share responsibly your discoveries. Best, Marco ------ Marco (@mgua on Twitter). Marco Gaurdigli. First off I'd like to thank you for the detailed and interesting article. I already have an Arduino board and I'm considering buying a SkPang Arduino CAN-Bus shield.

Initially I'm interested in reading RPM data. I know there are cheaper ways to read RPM, like from magnetic disturbance in 12v signal but it's not as precise as reading the CAN. Also, learning how CAN works may be really useful for future projects. My concern is that I need to read RPM from different vehicles without having to implement a new code to each car. Is it possible? Regards, Marco Correa. I agree with you that best way to read RPM data is from vehicle digital body bus.

On which car models are you working? I personally tested SkPang Arduino CAN-shield on on an Audi A6 car and it works exactly like is shown in the video in its website. It went smooth at first try, showing RPM and engine temperature. We tried it also on the Volkswagen Fox, Mercedes E270 which are cars we have access to, and are equally equipped with OBD-2 connector, but on these cars nothing is output. The device turns on, power is present, displays works, but it fails to communicate with ECU, and does not read anything. We tried to tune the arduino code, and also studied carefully the MC Microchip library, but without results.

Our current hypothesis is that CAN bus could not be available by default on OBD-2 pin 6/14 of these cars. We are going to test this hypothesis with the aid of an oscilloscope. I ordered a Rigol scope from DXExtreme, but after 2 months I am still waiting for it. (It seems that it is stuck in the customs somewhere and we are trying to release it).

As soon as I will have more valid information I will post it. Helder, To my knowledge the Teltonika FM 4200 device is able to connect to FMS compliant truck can-bus.

In my opinion, other diagnostics coming from OBD-2 interface (whatever the protocol or pin) can be collected thru it, but an interconnecting interface is needed, so to bring specific information on one of the FM4200 analog or digital input ports. One of my colleagues in Latvia is working directly with a Teltonika guy who designs the firmware, so I could direct to him a more specific question from you, if needed. Let me know something more about your design.

Marco (@mgua). I am currently trying to trace the cause of a 00470 code on a 2005 Jetta.

I thought that the VW/Audi gateway, the same as the one pictured in your article may have been at fault. I looked at the data on the Comfort System bus and both high and low looked OK, ie. There was no short in either line. This does not have directional headlights. I read on IATN that these could be an issue.

I replaced the gateway today. I bought one from the dealer, but was unable to longcode it.

I believe that it was because it has a trouble code. Data Bus Fault, I think it was. I checked the three power and two grounds at the gateway.

I am using a Launch scanner which seems to be capable at doing the long code. I used a Vision II to look at the data signals. The CAN signals don't look very strong at the DLC as they do on the comfort system bus wires. I lost communication to the Launch at one point but it returned soon after so I was able to print out the Long Code data. I am lucky that the place where I work is allowing me extra time to solve this. The initial complaint was battery drain. I believe that the comfort system was not allowed to go to sleep.

I also have an issue with the alarm horn which I found is drawing some current but I so far haven't been able to inplug it since it and it's protective housing is riveted to the body above the right inner fender liner behind the shock tower. I thought that perhaps you could give me some direction in how to diagnose this not just for this one time but for other times I might run into similar problems. Your's truly. Anonymous said. Hi Marco I recently bought the arduino shield that is shown in this article. With it I downloaded some of the sample sketches shown on the SK Pang website.

I always get compiling errors when trying to upload the code to the board. I have been through the code and have some posible errors, but nothing that seems to jump out at me. I must also state that I am no expert at programing. I am just doing this as a bit of side project for some university work.

(I study at Oxford Brookes uni, doing Motorsport Engineering). Is it possible that you could email me the sketch that you used for your Audi and any library files you used? Any help would be greatly appreciated. Hi Marco, I first apologize for not being into programming at all when I'm asking you the following: Do you think it would be technically possible to convert Canbus data to MIDI data thru the Skpang CB Shield and specific programming? Imagine a live stream of data where a single and identified event running non the Can is translated into a mapped MIDI event such CC or MIDI Note etc.

I know it might sound silly but i'll tell you this would be of great interest for some multimedia project i'm working on with the Plymouth UNI. As i can get from your discussion these opportunities are actually locked to the step of intercepting CB data. Considering the Arduino abilities for MIDI do you think that a specific programming for the conversion would be a major effort? Thank you for your article a for your attention. Diego, If I get it right, what you are asking is to traduce the reading of some variables accessible thru CAN bus in MIDI data.

Of course this can be done, but we need to figure out 1) what to read 2) how to perform translation 3) maybe how to 'detect' specific events and perform predefined MIDI sound sequences. As an example, you could read the data from the engine route per minutes, and also the temperature of the engine oil, or the speed in km/hr.

You could then build some translation functions between a variable reading and a corresponding MIDI output. You could generate sound of changing peak creating a correspondance between sound peak and engine RPMs. Or you could have brake lights generate some sound, and maybe have a music 'beat' in time with windscreen wipers speed. Such a thing would not be easy to debug. And also would be a little risky. Feasibility and security issues nonwithstanding, I guess that you can find easier and funnier ways to generate music from reality readings performed by sensors connected to an Arduino. Your Arduino MIDI music box could easily read ligh, sound, temperature, humidity, vibrations, compass heading and if you desire even your kitchen sink water level, without having to mess with CAN reading.

Hi Marco, Thank you for your prompt answer. I Got your point. The purpose of my project is to build an 'augmented reality' UI experience on the vehicle, performing basically the same thing is done when you, for example, choose the Mac OsX to play a sound when a window is opened or the light level of the screen is increased etc. Imagine that when you close the side window of the car or turn the starting key etc. With this idea in mind any possible event running on the CAN-bus could be useful if not necessary. What i'm looking for is a shield/software tool allowing the Arduino to perform the CAN-bus to MIDI translation on a flexible mapping basis.

I'm thinking about a tool where a common user is able on a friendly sw interface to route a specific CANbus event/signal to whatever MIDI event/channel he wants. So the example you did: 'brake lights generate a sound or play a sample' it perfectly fits the point but this 'relation' has to be mapped by the user without operating on the deeper lever of the arduino but on a specific mapping sw interface, so that the system is flexible and can grow as you recognize new logical relations between a car event and a distinctive sound event. I dunno if it's clear maybe it needs some more explanation. Sadly, I'm not even that much aware of typical arduino capabilities.

I do agree that readings could be performed by arduino sensors but i've got too many applications in mind that are strictly related to CANbus data. Sorry for my poor tech competences.

Could you possibly point me to someone who could be interested in help me further with this? Thanks a lot.

Diego, My opinion is that Arduino is not a sufficiently powerful platform to take care of efficient event to sound translation, neither it is able to directly drive a good audio output suited for your project. Arduino and CANshield could work as an interface to CAN, and maybe re-route on a bluetooth channel the data you are interested in, towards another application, maybe on a tablet or on a smartphone, that could perform sound mapping, drive an interface, a screen and so on.

I suggest you to think and clarify your ideas as much as possible, before trying the implementation. Work to describe your project in a few lines, without too many technical terms, stating what you want to do, and which could be usage target. It is not a problem if you are not into hacking or programming, if you know what you want and how to explain it. Anonymous said. The skpang arduino shield demo code doesn't setup and filters or masks on the mcp2515. On many german cars the canbus on the diag port get tons of traffic as soon as the key is turned on. I glanced at the code in the sk-pang example and it looks like it would not properly handle a bus with lot's of messages already on it.

It seems like VW's diagnostic gateway keeps the obd2 port somewhat quiet compared to the car I tested on (2010 BMW). Hence the demo code worked on my vw, but not on my bmw. Even though both are the same 500k 11-bit canbus and the commands and ID's ARE correct. It would be best to set a mask and filter in the mcp2515 (which, sk-pang stripped those functions out of the mcp2515 library they modded, so you would need to re-add them) to only allow messages from 7E8 (which the ecu will reply on) and then it will work on many more cars. Then there is the issue of 29bit vs 11bit.

The sk-pang code assumes 11-bit id's are used. A 2010 honda for example uses 29bit id's and would need the code adjusted accordingly. An auto-detect function would be pretty easy. Anonymous said. Marco, No problem. I've used the mcp2515 with AVRs for a while.

I do obd requests much differently than skpang does. Basically I have 6-7 PID's that I,by using a hardware timer triggered function, request at different intervals. For example, RPM would be requested 5 times per second, but I only request coolant temp once every 2 seconds. I then use an actual pin triggered interrupt handler (because the filters only allow obd responses) to parse each PID reply as it comes in. The interrupt is triggered when a message from 7E8(on 11-bit) passes the filters, then I just do a switch case on the PID response to parse it and save the updated variable to the globals for those sensor values. This way I can run whatever code I want in the main loop and canbus hums along in the background without missing a beat (and without halting the rest of my program to wait for an obd reply) The receive interrupt from the mcp2515 also works nicely to wake the AVR from sleep mode when canbus activity starts up. Hi Marco, I am just trying to read the basic can messages via obd2 or I can directly tap the can-h and can-l (eventually want to do that) of my 2007 VW Passat which does have CAN.

I have an Arduino uno r3 and the can-bus shield mounted on it. Every time I mounted the shield on my uno my serial monitor would freeze up. I tried it again without the reset pin attached and it doesn't freeze anymore but I still don't get what I want. 1)I read somewhere that you need to attach the reset of the can-bus to 5v. Is that true? I can't read anything from my obd2. Should I be running a specific program on my arduino?

I tried the analogserialread and the serialcallresponseascii (which seems like the best option) and nothing gives me anything to work with. When I try and run the joystick demo with the fixed digitalwrite(up, high) etc. I don't get any serial response when I move the joystick in any direction.I tried changing the pins to the A1, A2, etc and that didn't work either. I replaced my atmega microcontroller that's on my uno because I thought I heard that short out when I tried to attach the simple 5v, gnd, canh, canl on the shield.Still nothing. I just need some direction as this is my first arduino/microcontroller experience. Dear Marco, The article is awesome and it gave lots of clarity to me, as I am new to this field. I have two specific questions I would like to clarify.

I am trying to use Teltonika FM4200 device to read the CAN data. But as I understood from this article, I might need another device to decode the data. Is this right? Since Teltonika does not tell anything about it in their manual. I have a Suzuki WagonR car. When I checked the OBD II port I found only 5, 7 and 16 are connected. From this, can I confirm that this vehicle does not use CAN?

Thanks for the information in article and hope I could get some answer. Regards, Thiagu. @Thiagu 1) Teltonika FM4200 offers a CAN bus interface capable of reading FMS packets over CAN. FMS is a CAN based standard that was developed for trucks. CAN is a network layer specification, like ethernet.

You do not assume that every packet flowing on a network is obeying the same set of rules (i.e. Translation devices (like aforementioned QuasarElectronic's) allow translations from vehicle-proprietary-protocols-over-CAN to FMS-over-CAN, so that you can use FMS/CAN compliant devices (like Teltonika FM4200) to identify and process them. 2) The fact CAN bus is not terminated in your OBD2 port does not mean your vehicle does not use CAN. Hallo Marco, I bothered you years ago with some question on possible CANbus to MIDi conversion. The idea restarted to gain our interest.

We prepared a basic note to explain it. The scheme is simple CANbus>OBDShield>Arduino>MIDIShield>PC+DAW software for sound generation. We are now looking for someone to seriously try to do the thing for us.

Could you help me? How could I send you our note?

Would you point me to someone skilled on this matter? Thank you for your kind attention. Have a nice day. Hello Marco,I see you are quite aware of automotive electronics and would like to ask if you know any website where is described in detail the design and operation of the engine electronic control module? I have a problem with an module Magneti Marelli IAW 8P for Peugeot 306 and I need to understand in more detail the way it works. I searched in the Internet but could not find enough comprehensive information. I would be grateful if you could help me and congratulations for the nice article!

Hi, I removed the car radio from a Fiat Grande Punto and I want to keep it on while it is on the workbench. I provided 12v and ground, but unfortunately after some minutes it goes off. The connector has two pins labeled 'CAN A' and 'CAN B', may be the radio sense the engine or the ECU on that bus. Can be feasible to sniff CAN-BUS packets from the car radio connector and then play them back to the radio on the workbench? Everything is aimed to keep the radio on for a sufficient time, because the message 'RADIO BLOCKED / WAIT' is displayed, and I had to wait for the 'ENTER CODE' message. And no, the radio was not stolen!

It was blocked probably due of a faulty contact. Hi, Is there a way to snoop a working Car CANBus, find packets I'm interested in. Then on my engine swap project pump CANBus packets to the ECU telling him everything is working fine and run the engine correctly. More specifically, I putting a 2015 Subaru FB25 engine in my VW Vanagon camper bus. I removed a bunch of unneeded controllers such as VDC. But the ECU goes into limp mode without the VDC and I want to correct this.

I dead in the water with my engine swap need help. Thanks much, Bill. @vijay Hi Vijay. Unfortunately I am not working anymore on vehicle electronics these days, so I am not able to give you a satisfying answer. Consider this: whatever digital signal appears in the OBD2 port comes from a specific gateway device which has the main task of selectively allowing authorized diagnostic operations thru specific brand-dependent diagnostic equipment. To my knowledge each brand has very proprietary diagnostic equipment, and even in the same brand, different firmware on the gateway device generate different behaviours. Probably the best cross-brand tools to read OBD port signals are the ELM Electronics chips which are used in many diagnostic devices (but beware because there are a lot of fake devices not using the original chips).

Specifically ELM has a CAN only chip (ELM329) which allows state-of-the-art can protocol decoding from can signals on OBD2 port and is able to interpret several CAN based protocols like FMS J1939. I am in no way affiliated to Elm Electronics. Anonymous said.

Hi Marco, I have a problem with the BSI of my fiat stilo 1.9 jtd 115hp. I found a used one, functioning I hope, and would like to swap the eeprom that contains the code of my car in order not to change the whole lot. The problem is that I can't find the datasheet of this magneti marelli bsi, so don't have a clue about which IC I have to swap.

Is it the 14 pins CAN interface or an 8pin ic? Please I really need this if you can help, it would be very much appreciated. I'm italian and live in france. Best regards Erwin Di Benedetto erwinwizzy@gmail.com. @erwin: I am not an expert in car security, but I think your approach is not going to work.

Firmware compatibility matrix is to be respected. You can maybe swap a board between components with same release and versions, but there are probably checks in the code to protect the systems from unauthorized tampering. Also the mismatch would probably become evident if and when your car is checked thru an authorized diagnostic tool. I also do not understand the problem you want to solve by swapping firmware chips.

Datasheet is for chips or electronic components. You need to consider firmware levels, which is something different being software not hardware. Good luck and play safe. Anonymous said. Hi I was wondering if you know the answer to my query. If you broadcast a id and message into the canbus which is the same as what is coming from one of the vehicles ecu's but is different, what happens?

I have a arduino canbus sheild on an vw. It is broadcasting into the canbus 'change up a gear now'. It is sending 'id 440 message 5 00 A1 0 0 0 ' at the right time. Will it clash with the vehicles original gear shifter ecu? I had it programmed to only broadcast it once which failed sometimes so i programmed it to do it 3 times. It works but sometimes the gearbox ecu recognises something is wrong and puts the car into safe mode and will not change gear untill i restart everything.

So emulating another ecu to get a result i want is working but eventually the vehicle is recognising im fooling it. How should one approach this correctly to avoid message clashes and tripping fault conditions in the canbus system? @anonymous What you are doing is injecting spoofed commands in your car drivetrain can bus.

This is extremely dangerous, and you should not do it. Doing so would bring the software state within the car controller out of sync with real state.

The embedded software has many embedded security procedures and multiple checks, but can not deal with cospicuous inconsistencies. These potentially dangerous situations are probably logged somewhere and reported to factory lab. Try to put yourself in the place of the main ecu: it receives an 'official' gear set, consults a number of tables with data coming from many other sensors, and adjusts engine injection parameters accordingly. Before proceeding with parameter setting, it could also post a query to the originating controller asking for confirmation, and get an answer. Injecting fake informations in this control loop would bring the main software in unknown and uncharted territories, and decisions would be probably taken according to 'anomalous condition' rules, which are to be used in emergency, and far from being efficiency or performance optimized. Do not joke with safety. Be responsible.

Anonymous said. I understand however I thought about all that and proceeded carefully. All I am really doing is sending it the same commands that comes from the gearshifter when you control the gear lever manually.

So if the gear shift algorithms are not happy to act my wishes it does not change gear anyway. Upon testing (not on a road!) This is confirmed. If the canbus id copy trick causes clashing and cant be made to work then i may have to give up the canbus write commands and connect something up to the sensors of the actuall gear shift sensors instead and emulate them.

That way it really is ecactly the same as manually shifting it. This is simply trying to create my own shift pattern. Vw did a terrible job of the original shift map and it wears out the clutch packs!