Ford Radio Code V Serial Software Linux

Start by going to the Device Manager. Once there do the following: Expand the Ports ‘(COM& LPT)’ You should be looking at something like this: As you can see Windows has set the port to COM10. However many legacy applications expect the port to be between 1-4. Let’s change that: Right click on the device and click on ‘Properties’. Click on ‘Port Settings’. Then click on ‘Advanced’.

You are capabole to solve this issue whit our ford radio code generator free software that works on any ford radio model. We are 100% sure that. (Good news for everyone, the Ford radio code generator tool works perfectly with any operative system that your computer has, Linux, Windows and Mac. Additionally, you can. You will find the serial number printed on a label or engraved into the casing of the radio. All Ford V Radio Codes. Free Ford Radio Code Entry Instructions are.

Once you’re in ‘Advanced Settings for COM10’ on the bottom you can see the ‘COM Port Number: COM10’. Click on that to change it to the lowest possible number (between 1-4).

Then click ‘OK’ on all open Property Windows. Now the device should look like this.

I found a code that allows you to remove old associations to COM Ports. You can then plug your adapter in and then associate it with the COM Port you need. Start, All Programs, Accessories, Right-click “Command Prompt” in Accessories and choose “Run as Administrator” 2. Enter “set devmgr_show_nonpresent_devices=1″ – without the quotes obviously 3. Enter “start devmgmt.msc” 4. In the box that opens, select “Show hidden devices” in the ‘view’ menu. Now if you expand the section on COM ports, all the COM ports that have ever been created will be displayed, the non present ones being in grey.

You can uninstall away anything that you don’t want (right click, select uninstall). I also have the problem where the Prolific USB to serial is installed on com11 and the “advanced” button leads to anohter screen, but there is no provision for changing com port there. Might be IT department blocks that on company PC. I blame the device driver installation software -it SHOULD show defaults and ASK the user if they want to make changes before installing. No nothings can just push the button to install defaults, those of use who know what settings we need could then get it right. • Brad Fluharty.

Hi Bernie – I’m not sure if your postings on this topic has closed. I had an “Ham” HF radio connected to a desktop XP and a logging program via RS-232. As I changed bands on the radio, the log program would follow, recording time and date and the frequency of operation. Then, the PC was struck by lightning and I got another PC with new motherboard running Windows 7. I now have a radio that runs a USB cable that controls a Contest Logging program However when using an RS232 cable to control my normal logging for contacts, the program does not see the radio or the cable.

I have tried changing the port numbers but the program still does not see the radio. The two existing ports are 1 and 3 both with Nuvoton Drivers. I tried deleting them but then can not create a new COM1. With the drivers back into the PC, I tried using COM3 for the Ham Logging program but there is still no ‘comms’ between the radio and PC. Please HELP!!

Ham/Sam • Jeanie. Hi Jeanie I’m a complete computer illiterate!!

Still not sorted yet. I used to run Swisslog with my TS-2000S using a serial cable. A few months ago, I acquired a TS-590S after selling the TS-2000., I entered a small contest and had N1MM installed using a USB cable. The RS-232 port was used to control the Experk 1K-FA linear.

During the contest, N1MM and the linear worked fine. After the contest, I tried running SwissLog but the program could not see the COM port. Reading user comments that N1MM and any logging program can not run together, I removed N1MM although they were on different COM ports Now, I keep getting a message that the Com port I am setting up for Swisslog is being used by another device although there are no other devices connected to the PC. I’ve tried changing the Start and Stop bits and tried various combinations and getting more frustrated!

I trust that your dad will have better luck Regards Sam • Richard. Hi, I am trying to connect a UT61B multimeter to my dell laptop win7 home via a usb to serial cable. They do not specify one.The meter comes with a female 9 pin connector which works fine when connected to an older WXP desktop unit with traditional com ports. I borrowed a Prolific (green) cable to try it on the Dell laptop; loaded the software and can see the cable identified in the Device Manager; set the com port to 1 as required by the meter, but no data is transferred from the meter. The local computer shop says that the BIOS needs to be set up for the USB ports to be seen as COM ports, but the Dell BIOS has nothing that appears to affect this.

I believe it’s a hardware problem, maybe a bad green cable. Any comments? • David Roberts. Thanks for posting your question. There should be no need to set up COM ports in the BIOS for USB serial. Windows does this in software. We have sometimes seen difficulties with multimeters that expected higher voltages for RS-232 than with our serial that uses the Prolific chip.

The chip itself only provides TTL logic outputs, and then a serial interface chip takes those outputs and changes them to RS-232, with +7 volts for a one and -7 volts for a zero. The RS-232 standard allows up to +/-15 volts, and some multimeters appear ot require more than the +/-7 volts our chip supplies.

Also, you didn’t mention if your adapter was from Plugable. We don’t supply any green cables. Some devices that claim Prolific chips actually have clones that won’t work with the latest Prolific drivers. If you have a Plugable device, please contact us at, and we can help.

• Paul Aeberli. Hello, I want to ask about COM ports when there are multiple users on a PC. We use a piece of document tracking software at work which has barcode scanners attached by USB to each machine.

The software has to be configured to look on a specific port for the scanner, which is a global setting for the PC. However, when someone different logs on to the PC, Windows 7 assigns a different COM port number to the scanner for that person (presumably the first available) and this does not always match the COM which has been set up in the software, so needs to be reconfigured each time. The scanners don’t usually get unplugged. Is there a way to fix the COM port for a specific device so it never gets changed, regardless of who is logged in? This would save us considerable effort if these is a way. Thanks Dicegirly • David Roberts. Hi, I am using a device which requires COM1.

I made this change successfully some while ago but I want to understand what I did and why I did it. I just followed instructions like yours (except that on my computer it is necessary to click on ‘view’ in the Device Manager and select ‘show hidden devices’ in order to bring up Ports (COM & LPT) and a few other options) but was left wondering if I should change all my ports to COM1 so that I had choice as to where to plug in my device when using it, or whether I should leave the other ports well alone on the principle that whoever set them at whatever COM they were originally set them knew what they were doing and set them like that for a reason. Could you please explain in very simple language what it’s all about. When I clicked on Properties without the machine plugged in the window told me the device wasn’t plugged in, and when I plugged it in it told me the device was working properly. And yet I have lots of devices, all of which must have drivers, so why is it recognising this one machine in this way? The whole thing is a mystery to me.

And why do the COM options range from 1 to 256? Who could possibly use 256 of them, when I have only to select a COM value for one of my devices and all the others have apparently no preference. And what is it about COM10 that Windows sets it at that by default? If it would take you too much time to explain all this to me, can you tell me where I can find a layman’s explanation, please. It has bugged me for a very long time. • David Roberts.

The COM port setting in Windows is an arbitrary number that points to a particular address in the computer’s memory where data that is sent back and forth over a serial connection. If that number has not already been put into use to support a serial device, Windows will let you assign it to any serial device you have currently connected to the computer, such as Plugable’s serial adapter. Since the Port number is assigned by Windows when you connect a serial port, and released when you disconnect it, there would be no advantage in setting all ports to COM1. If two ports were set to COM1 and in use at the same time, this would cause problems, because one serial device would overwrite the information from the other in memory.

However, this shouldn’t happen because Windows will not let you assign a COM port to more than one device at a time. The COM ports are arbitrarily assigned by Windows. They are not set with any purpose, so feel free to change to any open COM port when necessary. Some serial communications software will only work with a specified COM port or only with COM1 through COM4.

In those cases, you have to select an appropriate port in the Port Settings window. The numbers range from 1 to 256 in modern Windows versions to allow a large number of serial devices to be attached without causing problems. Modern computers have plenty of memory available, so there is no problem of setting aside enough memory to support 256 ports. The number 256 is selected because it represents the maximum number of ports that can be addressed with one byte (eight bits) of information. When you plug in a device known to Windows, it automatically loads the driver for it. When you unplug that device, Windows automatically unloads the driver. Devices that are similar to each other can use the same driver, and Windows just copies in into memory to be used to control a particular device on a particular COM port.

When using USB serial devices, Windows tends to assign the same COM port number to devices plugged into the same USB port. That may be why you are frequently seeing COM10. I hope this helps.

David Plugable Support •. Windows checks the USB Vendor ID(VID), Product ID (PID) and device serial number each time a USB-Serial device is plugged in, and assigns the next unoccupied COM port if it has not seen that combination of VID, PID, and serial number before. Also, if another serial device is set to use the COM port usually assigned to the Plugable adapter, a new port will be assigned to the PLugable adapter since its previous port is no longer available. There is no setting in Windows that will prevent this behavior.

If you only use one Plugable USB-Serial adapter on this computer, it is possible to set the registry so that Windows ignores the serial number of the adapter, and thereby assigns the same port to any Plugable adapter that is plugged in, but if you are using multiple Plugable adapters, this will make the situation worse. If you would like more information, please contact us directly at with some details about your setup, such as how many serial devices are connected, and how many Plugable devices are being used, and we can give more specific information.

Hi there, great writeup! I am very interested in your open-usb-can project. I have different hardware, an STM32f4 with 2 can controllers, I plan to eventually use both by making my firmware present 2 USB interface descriptors. For now I have been coding firmware in the hope that I can just use your kernel module, by making my hardware appear to be the same as yours from the host’s point of view. I have got the device/interface/endpoint descriptors working, and can set the hw config, and start the interface. But I cannot figure out how you start the data flow.

The urb’s callbacks in the kernel module do not seem to ever be called. I can make data go out, for a short while using cangen, but never get anything back in. I can see in the ep0.c control values that do not seem to ever be sent by the driver.

But which appear to be needed to start the data flow. ATUSB_SPI_WRITE1/ATUSB_SPI_WRITE2 and ATUSB_SPI_READ1/ATUSB_SPI_READ2 The Write one seems to be the only place the ep in callback gets set. Am I missing something? Are these parts of the code actually used? Thanks in advance, Dan. I was actually in the process of redesigning my open-usb-can with an STM32F103, as I abandoned the AVR based design for performance reasons, but then I stalled the project to work on other stuff Anyway, I’m happy that you’re using my kernel module as a base!

That’s actually quite simple because the firmware uses socketcan compatible data structures and you can easily do the same. You may also be interested into a discussion on the linux-can list about USB-CAN protocols () and maybe even join the list!

The firmware code is actually based on the ATUSB Ben-WPAN project () so you may find some debugging/helper code still there and not used by the kernel module, and that’s the case for the ATUSB_SPI_* calls – the AVR to CAN controller SPI data is not exposed on the USB side for normal operation. As for the data flow, the stuff you find in ep0.c is only for the control endpoint (&eps[0]), and that’s used only for device configuration/start/stop.

The actual bulk traffic is handled in buffer.c, where you can find references to usb_send(&eps[2], ) and usb_recv[&eps[1], ). Those two maps to the two kernel queues: usb_sndbulkpipe(dev->udev, 1) and usb_rcvbulkpipe(dev->udev, 2) and relative callbacks. There may be a *ton* of reasons why your traffic doesn’t go trough, and you may want to double check your descriptors and the hardware USB controller configuration on the STM32, especially for the endpoint sizes. In this situation I would search for an working example project to run on the STM32 that uses bulk endpoint and adapt it to your configuration until you find what breaks. On the Linux side you can use the usbmon module to see the raw traffic. Also, one of my favorite utilities for hacking on USB is the usbtool application from the v-usb package, you can find it here hidden into the examples/usbtool directory.

It allows you send and receive arbitrary USB traffic, it uses libusb internally. If you use that just keep in mind that it doesn’t flip between the DATA0/1 packet id, so it will actually work only for the first packet but that’s often enough!:-).

Thankyou for such an in depth reply. I have managed to get data flowing to the host, it was something to do with the FIFO buffer settings, I do not fully understand how these are allocated and used at present so need to investigate. I had based my CAN vender specific driver on the stm cdc example class, removing the command endpoint so I just have the control endpoint and two bulk end points as you do, but had over looked the FIFO settings. I have used lsusb with -v option to confirm the descriptors are all correct. Although data flows to the host it is presently split in to tiny packets, I am only sending 17 bytes and it seems to send this as 12 bytes followed by the remaining 5 bytes.My wxPacket sizes for both the in and out Endpoint are set way higher than this, 64 and 32 bytes. So I have some work todo to find out why this is happening, but once resolved I am nearly there:). I have been using usbmon module with wireshark, and also a libusb test program adapted from something else I found online.

I will investigate the other things you suggested. Thanks again Dan. Hi Fabio I work with “PEAK-SYSTEM- CAN card ”, I can connect two can interface, I generate CAN data in one can interface and dump can data in other inteface. But I want reverse engineering on PLD engine controller and dump can data in this controller. You can find specific of this controller in this link () but I can not receive any data with my interface! However I can connect it with car diagnostic and receive CAN data!

I try to determine output signal with oscilloscope and saw voltage level of this controller are 9 V & 12 V for CAN-H and CAN-L. But in my interface output level are -1.5 and +1.5 V. If I can connect this controller with my interface? How I should connect this controller physically?

If I should run specific command for connect and dump CAN data without “candump can0”? Please help me:-) thanks a lot. Hi Yousef, there are many things you should check to troubleshoot the problem: first make sure that you are able to display error messages from the CAN interface (candump has some specific flags), then it may be possible that the bus you are using generates data only when triggered (check for activity with the scope). It may be useful for you to build a split cable to connect the diagnostic tool and your CAN interface at the same time, so that you can check if you receive the same data from both. For the voltage level, is actually quite high and may be saturating the transceiver. You should check which transceiver p/n is used in your CAN interface, and make sure it works with common mode voltage as high as ~10V. Ideally you would also use an isolated interface (if you are on a laptop using it from the battery may be enough).

Firstly, what a great post. Thanks very much! I have quite a bit of experience with CAN, and always get the question how to read fuel consumption from many different manufacturer’s CAN bus. Yet, this signal is very difficult to reverse-engineer, I find, because many other signals (engine torque for example) look very similar. I see you have fuel usage identified on the toyota. How could you be sure it is the right signal?

Any tips will be greatly appreciated!:-) Again, thanks very much for an excellent article. Hello Marius! Thanks for the comment, I agree that most of this is very hard to reverse engineer Even after you isolated some counter, everything spins up as soon as you rev up the engine!:-) For the fuel consumption I’m afraid I found a hint on some other website for similar projects on other Toyotas, and the value seems to change together with the instant consumption on the dashboard. My first idea would be to try to see if the those two updates together but if that doesn’t work I guess you should compare with some other car diagnostic tool. Hey, out of curiosity – what other sites did you see discussion of Toyota CANbus traffic on? I have a 2006 Sienna and while some of the CAN-IDs are the same as yours (and in fact have identical information for 1-2 of them), there are quite a few differences. Well actually it’s the family’s Sienna – I’ve traded with my 2009 Outback for a few weeks for various reasons.

For example I’ve found a single vehicle speed value (appears to be km/h*256), but no individual wheelspeed values (likely due to older vehicle without stability control). I’ve found an oddball signal that seems to be approximately RPM*2 most of the time, but varies from that value.

(Usually gradually increases above RPM, but occasionally drops to 0). From what I remember the only external reference I had when I wrote this was a report from some university group on another Toyota car. I remember observing something similar to what you described: some frame IDs matched but the content was slightly different, which probably reflect some different evolution of the various ECUs and the communication protocols used, or just different requirements on what data needs to be shared between ECUs. The lack of individual wheel speed may mean that the ABS unit obtains the information by some other mean other than the CANBUS. No clue about the RPM*2 one maybe some other control signal loosely related to the engine speed.

Are you going to try and do some test on the Outback? Would be curious to see what you find I would expect that car to be quite more sophisticated and have multiple buses though.:-).

Nice job on decoding the CAN-frames. Now that you have a CAN-OBD-interface it would be really simple to add functionality to also log supported OBD-PIDS for your vehicle Have a look at for a very nice guide. Basically, for the supported PIDS of your vehicle you just send a CAN-message and wait for respeonse.

The list of supported PIDS is obtained by simpy asking, which is always supported (for non-electric vehicle). Example: Supported PIDs are obtained by sending a can message with [02,01,00,0,0,0,0,0], respone contains PIDS-supported.

Lets say PID=0x0A (fuel pressure) is supported, just send [02,01,0A,0,0,0,0,0] and wait for response. Response should be something like: CAN-Sender-ID=0x7E8 (message from main ecu), [numBytes, 0x41, PID=0x0A, A, B, C,D, E, ] and actual fuel pressure is A*3 according to wikipedia. Thank you for this informative post. Although as a medical diagnostic imaging engineer I am familiar with CAN bus, what I am working with is pretty much presented by the manufacturers in hardware and software, as is the case with OBD II and OBD II readers. Your presentation differs in that it probes down to the signal level, which then may determine if a component is actually bad or if the signal is just bad. I wish you had described a step by step use of the “socket can” for us who are less familiar with programming.

Have you done any work into hacking the other CAN bus in cars, namely the Navigation-Radio-CD changer-Telephone-etc. From following the various automotive forums there seems to be an awful lot of problems in that area. I wonder why the power train CAN is so reliable and the entertainment CAN is not.

(Greater product liability?). Yes you are just about right, I would not really say “signal” though as I did not really put too much effort on electrical signals but rather at the lowest digital layer – the raw transmission and receiving of CAN frames, such as if they were IP packets. The socketcan part is actually easy if you get familiar with normal “internet” sockets before, and that is just the API used to interface applications with TCP and UDP (and more!) streams.

SocketCAN is just an extension of that to use CAN frames with the well-known socket API, and it’s actually a huge step forward compared to previous implementation of low level CAN APIs in Linux, which would not do too much other than exposing the controller to the application. I did not really do much in cars other than what I described here, and I think CAN it’s used for infotrainment devices just because “it’s already there” One problem is that there is still low interoperability between devices, since even if they share the bus they still implement vendor specific protocols on top of it (think of after-market stereo or dashboards). If you hear about reliability problems it’s probably juts because those are just less important busses and receive less attention to reliable design as a consequence Maybe the cables and connectors are lower quality (gauge, twisting), have longer trunks (worse signal integrity), moves through hinges and other stuff. I’m sure the drivetrain bus receive more attention and there’s much more than the protocol itself in designing a reliable field bus system. Hey Fabio, Hi! I am Sarthak Jain.

I was currently analysing the CAN bus via ELM327. I captured some packets for window up and down. But when I replay those packets using ELM327, then I do not see any action other than flickering of ‘check engine light’.

After asking some people, I came to know that the speed of ELM may be slow which is causing conflicts on the CAN bus. I came across this module –. I need to know if I send those packets using this hardware, I would not get the same problem of speed as with ELM. Can you please comment upon this? There is one more module – ‘ECOM’ cable which is being used for hacking the CAN bus. Are you aware of this?

Hey, The speed is that of the CAN packets which I am sending via ‘pyserial’ package. Actually I am using OBD-II UART board which provides a serial interface to send and receive packets to the OBD-II bus. I used ELM 327 AT commands to analyse the traffic, reverse-engineered some of the packets, found the ones which change when, say window go up or down. But when I replay those packets using ‘pyserial’, all I get is ‘flickering of check engine light’. By the way, USB2CAN device provides a serial interface or some other? Right, so if the OBD adapter is passing through a standard UART to communicate with the host, it may be saturating that link. I think that’s a poor design in general, but it’s particularly bad if it’s using a real UART and a converter, limited to a specific bit rate, rather than a “virtual serial” implemented directly on the USB controller.

In the case of the ELM controller I guess that the design made sense since you are supposed to use it to communicate with the ELM chip using AT commands (let’s call it legacy), and that link should not require much bandwidth, but if you try to turn that into a CAN interface you are surely going to get very poor performances. None of the devices I listed in this post are implemented like that AFAIK, and all are using proper USB endpoints (and works with socketcan). That said, I doubt that’s the problem that leads to your “check engine flickering” thing, you are more likely sending wrong data or just sending something that gets quickly overridden by some other periodic frame on the bus. Hey, yeah you are right that my data is being overridden by some other frames. I have one more question. The OBD-II UART board is having MCP2551 CAN transreceiver and STN1110 as its controller. Clearly STN1110 is ELM based and is not CAN controller.

But we can select CAN as one of its protocols and then we can talk to ecu and get sensors data. It means it can talk to the CAN bus without any problem. But I guess the only issue is that of speed of the serial port which is causing trouble. I hope this trouble goes away by using USB2CAN device? Well, the fact that you only have a CAN transceiver on the board means that the STN1110 does have a hardware CAN interface (it’s probably some commercial microcontroller pre-programmed and custom branded), and the controller can surely operate on a full-speed bus (that’s 1Mbps), but that does not immediately translate in the fact that you can use it as a generic CAN interface and transfer the whole data stream of the bus on the control interface (your serial).

The serial port speed is surely the first concern on that, but that’s far from being the only limitations. CAN based micros are designed with some kind of frame filter to be able to silently discard most data present on the bus, and only activate the CPU to process the essential frames. If you use the micro as a bus sniffer, thus opening the filters to grab the whole data stream, the micro may not even have enough power to unqueue the frames fast enough to prevent overrun, and that may even happen if the bus is lightly loaded but bursty. Those ODB chips are nice in that they can implement the OBD protocols (on top of CAN and other busses), but they are not designed to be used as a raw CAN sniffer device (access the full bus data even in heavy load or bursty conditions – which as I understand is what you are trying to achieve here).

If that is what you want to do you would surely have better results with something like the USB2CAN. They give complete schematics on the website:, the setup is an MCP2551 + STR750FV2. On the lock question, hard to say, it depends how the information on the frames is interpreted it may not be that easy, and you are still racing with the frames sent by the original controller on the bus, and injecting/replying frames may or may not work depending on how the protocol is designed. The very fact that your check engine light blinks when you send stuff is telling you that something is detecting an erroneous condition on the bus (checksum?

Sequencing?) which then resolves with the normal traffic. I don’t have any literature for that, you may find something about the OBD stuff (which AFAIK is a request-response based protocol implemented on top of a pair of CAN IDs), but everything else is proprietary, vendor and model specific stuff If you find something is either leaked or reverse engineered (well, this post is about reverse engineering it after all). Hi Askshay, I think you are overestimating my abilities to see through the matrix, I can barely tell that those are extended CAN frames but that’s about it.:-) Anyway, the details you asked are not really related to that dump, those are part of the CAN framing, and does not really show up at application level. What you dumped are basically just the ID, the DLC (always 8 in your case) and the data — not sure about the last number. I don’t really have any documentation for reading *that* specific data (the frame specs are ECU specific), though if you are interested in CANBUS in general there is plenty of literature on manufacturer websites, just Google it. Akshay, I know this is a long time from your original post but I just got into Toyota’s and found this site courtesy of Google.

The CAN traffic you posted is very typical of the interaction between a tester(something like a dealer scan tool, ELM327etc) and one or more modules. I think for what your looking for you don’t need to worry so much about all those things you numbered off. The things you are interested in are the Id and the data.

Using your first line as an example: 18DAF130 X 8 02 7E 00 55 55 55 55 55 5076 The Id is 18DAF130. The 18DA is a standard identifier for physically addressed signals(the tool is asking one module for a response). You may also see 18DB which is a way for one tool to ask all of the modules for data(functionally addressed). F1 lets you know a “tester” is asking for this information as opposed to another module onboard.

30 is the destination address. This could be any module on that particular bus(engine, trans, body, HVAC.). The X is just to let you know this is an extended message(29 bit identifier). Mechwarrior Rpg Handbook To Higher there. 8 is the length of the message data to follow. This is the data that you actually care about: 02 7E 00 55 55 55 55 55 02 is the length of the data in this message that is significant(not counting itself) 7E is a standard identifier indicating a “tester present” message 00 is the “mode” for lack of a better term. There are a bunch of different modes that do different things mainly it indicates whether or not this message should be acknowledged by the receiving module.

In this case it appears 00 means it does not require acknowledgement. The rest of the 55’s are just padding. I know that because the 02 in the first byte told me there was only two bytes of significant data.

Long story short, this message was just a signal from some tool on the bus to a specific module to let it know it was there. Not too excitingThere are 5 different modules this tool to talking to (30, 28, 10, 53 and 60). I don’t know which modules those numbers correspond to but you can probably figure it out with enough internet searching. This is the interesting message: 18DA30F1 X 8 03 22 48 00 00 00 00 00 417576 This is the tester asking module 30 for some Mode$22 data from PID 4800.

Module $30 then responded with 59 bytes of significant data. Who knows what information is contained within this message(it is proprietary but again you may be able to figure it out with some internet searches) but something in your car is asking for it. Clear as mud? After I posted this, I realized I screwed it up. I swapped the sender and receiver in my head. It should read: “The Id is 18DAF130. The 18DA is a standard identifier for physically addressed signals(the tool is asking one module for a response).

You may also see 18DB which is a way for one tool to ask all of the modules for data(functionally addressed). F1 lets you know a “tester” is receiving this information as opposed to another module onboard. 30 is the sender’s address. This could be any module on that particular bus(engine, trans, body, HVAC.).

The X is just to let you know this is an extended message(29 bit identifier). 8 is the length of the message data to follow. This is the data that you actually care about: 02 7E 00 55 55 55 55 55 02 is the length of the data in this message that is significant(not counting itself) 7E is a standard identifier indicating a “tester present acknowledged” message 00 is the “mode” for lack of a better term. There are a bunch of different modes that can be sent from the tester which do different things. Mainly it indicates whether or not this message should be acknowledged by the receiving module. In this case The tester did require an acknowledgement. The rest of the 55’s are just padding.

I know that because the 02 in the first byte told me there was only two bytes of significant data. Long story short, this message was just a response from some module on the bus to the tester in response to its original tester present message(not included in your data dump). Not too excitingThere are 5 different modules responding to the tester’s message (30, 28, 10, 53 and 60). I don’t know which modules those numbers correspond to but you can probably figure it out with enough internet searching.” Sorry about that, its been a long day. Dear Dave, Thank a lot for your reply, i was toying with the idea of decoding the data packet earlier and once again i am approaching it as it has become a necessity. I have understood what you have explained in the above post and would like to thank you for explaining it in such detail.

Considerin’g the above the data dump, you have clearly explained what 18DAF130 refers to and also about “DB”. Clearly there are several notations which i need to be aware of if i have to understand the lines of data. Are their any literature where one could read through the different sets of identifiers.

18DA10F1 X 8 30 00 00 00 00 00 00 00 384 18DA10F1 refer to 18DA being the standard identifier and what does 10 refers to? F1 refers to the tester present. Whereas 30 refer to length of the data am i right? Also can you please elaborate what exactly you meant by the following ” this message was just a response from some module on the bus to the tester in response to its original tester present message(not included in your data dump).” Thank you Warm Regards Akshay. Thank you for the reply sir, The reason i asked you is that i am trying to understand the data dump.

I have gone through few notes and pdf’s on the net and with respect to CANBUS they have mentioned Arbitration Data, CRC,ACK etc i am just starting to get my head around it, but there is no success. Also the packet data that i have collected, how do i identify what they correspond to? For example: I have my throttle wide open and i am seeing bits of data streaming across my screen and i would like to identify which among those streams of data does my vehicle RPM correspond to?

Now sir please tell me is this the right way decipher the data dump or is their any other way?? And what does the Bit 8 refer to in the following 18DAF160 X 8 02 7E 00 55 55 55 55 55 797 Last thing is Sir could you suggest me some literature that has an in depth explanation of CANBUS protocols and other K line, K-L line protocols and also how to reverse engineer the data dump?? Thank you With Regards Akshay. Right, so what you are looking at is just the frame identifier (18DAF160) and the payload (02 7E 00 55 55 55 55 55), CRC, ACK and other framing stuff shows up at a lower level and you don’t really care. What you need to do is figure out a way of understand the meaning of the data, and how to do it is up to you. What I did was taking one frame id at a time, observe how the data changed and try to correlate with the event in the car (from the video recording).

That’s what this post is about. The “8” digit is probably the DLC, which is a just fancy name for the size of the payload (8 bytes). I don’t really have any in-depth literature on CANBUS, the protocol is not that complicated to understand, especially if you only care about application level stuff (i.e. You are not writing a driver or implementing a controller or a circuit board). For how to reverse it up to you, this post contains a description of my process already.

Hi, I am not able to reply on the above thread. But here we are. As I told you, I used an USB2CAN converter. As soon as I connected this to the OBD-II port without actually powering it, I saw an unusual change in the dashboard lights and data.

The cable which I used is OBD-II to DB-9 cable which you also suggested in your blog. I tried various baud rates – 500, 250, 50 kbps and also set the listen-only mode on, but as soon as tried the “candump” command, I did not get anything.

Can it be a problem of device itself? Right, so, the fact the both that cable and the CAN interface have a DE9 connector does not mean that they are meant to be plugged together. In fact they are not, that cable () is using some pinout commonly found in OBD scanners (I think.), but the 8-devices converter () is using the standardized CiA D-sub pinout ( page 9), which is what you expect in automation devices. You should cut the end of the cable and rewire it (which is what I did as well, I had a custom connector in my USB interface). What you did shorted some random signal together, hence the error lights on the dashboard.

It probably did not blow anything but be careful with that, as far as I remember the OBD connector has a +12V line straight from the battery, which is probably limited by a 10A fuse or something. That’s potentially lethal to any non protected signal transceiver.:-). I have been working on a similar project and I have been using the STM32F.

I have this working with the 105 series, and 407 series. I am working on an OBD2 simulator and was able to get it working with very little code at least for proof of concept. My goal is to have a fully open source OBD2 simulator with all protocols.

CAN was pretty easy using the MCP2551 chips, but now I need to develop the others, specifically 9141 LIN protocol. I am using the SN65HVDA195-Q1 lin transiever, which I have also succsesfuly got working on my own LIN network.

Next goal is to get it working with the 5 baud init then switch to the 10500, but I have run into a problem with time. Would anyone be interested in working on the ISO 9141 OBD protocol? BTW, I have been using the STM32F discovery boards. They use the STM32F407 and they are only $15 from digikey. Hi, Thanks for your assistance to let us know more about CAN. I have used a phyton sniffer and arduino can-bus shiled to analyse the data.

Im trying to figure out how aircon works. I have found all the related CAN-BUS ids and datas for the aircon. When i send them back it doesn’t care my data it keeps sending its own data. I used this way to lock unlock the doors, open the windows, move the seats, lights and so on. I used the aircon id and data for same brand car but different model it worked.

I wonder that it maybe LIN-BUS or something else? Here is my id and sample data for fan level and temperature: CAN ID: 856, data: 0, 0, 0, 0, 21, 21, 153, 17 CAN ID: 856, data: 0, 0, 0, 0, 21, 21, 153, 34 CAN ID: 856, data: 0, 0, 0, 0, 21, 21, 153, 51 17,34 and 51 are for fan level and 21 is for temperature The car is 2015 Model. Hey Chris, I think that cars with multiple bus commonly include that functionality in some node.

You want to make sure to not overrun on the slow bus write queue. I would suggest you to avoid using a rPI for this, unless you can connect a CAN interface that can handle the two busses at full speed. It’s tempting to use an SPI controller (the MCP2515 is very common), but that has terrible performances on highly loaded fast busses, and you will end up with problem such as RX buffer underruns and out-of-order frames. You should look into SoCs with two embedded controllers, the AM335x used in the BeagleBone Black with an appropriate cape may be ok – but whatever design you take make sure to load test it.

Hey Daksh, sort of. First, there’s no such thing as a negative ACK as far as I’m aware of: once a frame is on the wire it either gets ACKed from at least one of the other nodes or not (see the note about ACK slot in the frame format I posted). ACKs in CANBUS are weird, depending on how transmitter and receiver nodes are configured you may have different things happening: – the receiver ACKs anything that matches the acceptance filter unless it’s in listen-only mode. I don’t know if any CAN controller can go into listen-only mode and expose whether a frame has been ACKed by some other node or not, but the MCP2515, the SJA1000 and socketcan itself does not seem to support this. Django Dumpdata Unable To Serialize Database. – if the transmitter is sending in one-shot mode, it’s just going to put the frame on the wire and stop regardless of the fact that any other node acknowledged or not.

– if the transmitter is in normal mode and no other node ACKs a frame, the frame gets re-sent indefinitely (you can see this happening on a listen-only node). Either way, to get the information on what’s going on with the ACKs on the bus I think you may need to use a logic analyzer that supports CANBUS decoding, so that you can tap into a live bus and see if anything is transmitting dominant bits on the ACK slot. Hey Xavier, yeah totally, as you can see from the code this has very few dependencies. Basically you need the compiler (native or cross), the kernel headers for the userspace (that’s needed for the various #include ), and the ncurses libraries and headers (for the #include. For the former, from how I’ve set up the makefile you need to have ncurses5-config in the PATH).

If you have everything give it a “make” and it should build. If you are cross compiling make sure to specify the cross compiler, something like “CC=arm-linux-gnueabi-gcc make”. First off this is an awesome post. I have been putting this method to work on a few cars at home. I am doing an experiment with a VW E-Golf and I need the% charge of the battery, which is unfortunately not available through OBD2.

I have been successfully in decoding some CAN data on other cars, however on the E-Golf, only one pid is returned every couple of second. I thought it could be and error frame (only because I had not seen any of these yet). The values of the frame stay the same and are 20 01 00 00 00 00 00 80. I tried hitting buttons and driving and they didn’t change. I tried to print just the error frames using the 0~0 on socketcan and still nothing. Is it possible that I need to access another CANBUS on the car? Or does this seem odd to you as well.

I would think (from what I have seen and read) that there should be more than one pid on the system. I had set the bitrate to 500,000 and thought maybe I had that setting wrong. I tried the other standard rates 10k,20k,100k,125k,250k,800k,1000k and they all print nothing.

A VW manual for the BUS system stated that 500k was used for high speed data rates. If you could shed any light on the matter, it would be greatly appreciated. Hey Dan, that’s a nice modern car packed with electronics I would not be surprised if the CAN on the OBD connector is for OBD only and there are one or two other dedicated busses for high speed critical stuff. I’ve actually read of other cars with this setup (some Volvo). If you want to be sure you can check the signal with a scope but since you are getting something reasonable it may be indeed all that is in that bus.

The charge status and other information should be sent to the central dashboard somehow. I would start by taking that off the console and look for a twisted pair on the data connector on its back. Then you can either figure if that also ends on the OBD port in some of the vendor specific pins, or just splice a tap from there and start looking for your number.

Good luck with that! Can’t wait to hear the progress.:-). Currently I’ve been trying to reprogram my instrument cluster for information display changes.My current project is on a Toyota Corolla 2014. Current information display have the following options available to the user: Average Fuel Consumption Cruising Range until empty Trip Elapsed Time Average Speed Realtime Fuel Consuption Setting (for brightness etc) The display cluster is controlled by a single button for switching displays. My project consists of changing ( or possibly ) adding a menu.

For the displays that is subject to change, I want to replace the Average Speed display to Current Speed. Also, if possible, I want to add a menu for displaying Engine Load and Voltage Meter.

How can I reprogram the instrument cluster? Can i do it via OBD2? Also, what tools do i need? Any feedback would be greatly appreciated. I got inspired by your project, studied around and finally got to purchase a USB2CAN interface () and a an OBD to DB9 cable however as soon as I initialize the interface, everything goes crazy in the car.

I get every possible error, and usually after I take the interface out and restart the car all is good. My car is a Peugeot 508, and I found out it’s using 11bit 500kbps CAN protocol. I assume I am doing something wrong? The interface supports up to 1Mbit buses, and everybody was praising it. I wanted to use it to capture information, and mostly just learn since it’s also a hybrid liek your toyota:) If you have any hints or things I should try, let me know. I would start by verifying that the cable is wired correctly for the device. From what I remember the OBD-DB9 wiring on common cables was different from the DB9 CANBUS wiring commonly used in industrial applications (which is surely the one for the 8devices adapter).

I’ve always used a custom cable for my tests (terminated on a 8P8C actually). If you are confident that the wiring is correct, make sure to put the interface in listen-only mode. That way even if you get the wrong bitrate, it should not make noise on the bus.

Keep us posted! Well you were right, that’s what I suspected too, that the cable is wrong, and I ordered a different one. Now works perfectly, I initialized it and works, I can see the entire bus:) Now I don’t know what bus is exposed on the OBD port, I do know it runs at 500kbps. Mostly I want to enter the comfort bus and learn it, but of course, the big dissapointment now will be identifying the packets. I found a very interesting provider, they claim to sell CAN packet databases for different brands, I will see if I can get something, even if I have to buy it, I don’t mind, I want to build a better navigator.

Here is the site btw: Of course if you know a place I could find something, unfortunately since it’s a french care I am aware I may have to learn french:). Hi there, great job at experimenting with the Yaris. I have a question though; I have a spare instrument cluster (the electronic one just like yours since I changed to the analogue cluster in my 2007 yaris), and I want to find a way to drive the cluster, by information from racing simulators on PC. I have seen videos doing that with an arduino but with German vehicles’ clusters.

I was lucky enough to stumble upon your video with the exact same instrument cluster as mine. Do you by any chance have any idea on how to tackle this? I want the RPM, speed and other data synced with the game’s on screen speed RPM etc.

How possible do you think it is with this particular cluster? Cheers from Greece, George.

Yeah it’s definitely doable, I did an external custom gear indicator and shiftlight myself for LFS many years ago. You need to figure how to power up and inject the data on the real display, so get a power supply, a CANBUS interface, and try putting some valid speed and rpm frame on the bus (you have the format from my software). If you can get that working you need to find the documentation for external display for your racing simulator and just glue the two together.

For LFS it was a simple UDP based interface, you tell the game where to send the data to and your application would get periodic status updates, look for OutGauge in. Any other game, I’ve no idea.:-) Keep us posted! Would you be willing to share one of your CAN dumps? I’m trying to hack the electrical power steering from a similar Toyota into my car and I’m curious to see if I can convince the power steering ECU that is talking to a car by just playing some data back.

With a little hacking I should be able to modify the wheelspeed CAN messages and maybe (hopefully) have the steering assist change. The motor I’ll be using is from a 2007 Yaris, but I’m still missing the Yaris steering control ECU (should be acquired shortly).