Has anyone tried using Propellers with CANBUS or other vehicle busses?
redheadedrod
Posts: 78
I am in the beginning stages of a major project I am undertaking.
In this project I am totally computerizing my Truck. It currently has a variety of computer modules controlling everything already but I want to tie into the systems and be able to control them with my PC or ARM boards.
At this time I expect to use 3 different "levels" of computers.
1. Currently have an i3 based PC that will be running windows to interface into the truck while running. It will be the entertainment hub as well.
2. Multiple ARM based boards to run specialized interfaces such as a voice based AI system, 3d vision and/or radar object detection etc.
3. Microprocessor based machines. I see no reason to go anywhere other than the Propeller chips. I will be using these to do most of my actual hardware interfacing and due to their simplicity will use them wherever possible.
Has anyone had any experience interfacing Propellers into the data bus of a vehicle? I will likely start out making a ODBII device emulator since all this will require is a USB interface and some programming. I want to evolve this into something that could be placed on a CAN bus of a vehicle to act as a new module or control other devices on the bus. For an example of such an application look no further than currently available car start units that use the CANBUS to do everything from a microprocessor run module. I will likely start out using an ELM type ODBII to serial chip to get it working and eventually try to drop the ELM chip all together if the Prop can do the same thing easily.
Eventually I want to build a system that could easily be confused as being a real life version of a "knightrider" vehicle.
I have an alarm going into the truck in the next week I can control from my phone which I will try to reverse engineer so I can duplicate it and control it from my computer. This will likely be my first actual use of a prop in my truck. But I also hope to potentially replace or tie into every switch and control in my truck so I can access it via my computer. If I can access it from my computer I will also be able to control it from my phone. And where it makes sense I will fully automate functions that take switches now.
I am looking at what screen I can install into my truck now so I can install the PC. I will be using the PC initially in place to scan the vehicle buses and learn their codes.
So I am thinking I want to make a generic prop based canbus board that can be accessed via the computer and could be networked with other canbus boards either directly or over the vehicle bus with unused outputs available to be used to control whatever device intended. Or potentially have a "man in the middle" type of dual canbus device that can allow me to use the OEM switches but intercept messages to allow customized controls.
As an example, the winshield wipers are controlled by canbus but if I try to over ride the wiper switch with ODBII commands it will only work until the next update is done by the switch. If I intercept the messages I can let the switch still work but also allow the PC to over ride the switch easily.
I can think of many other functions as well. I may be able to make a self driving vehicle in this manner eventually by typing into everything in my truck. But I would rather make a generic module I can base everything off of to start with so I am curious if anyone has done any work tying into a vehicle bus with a prop. I am sure the Prop is much more powerful than the ELM chips that are commonly available.
Window Roll up "module" is another example.
Rodney
In this project I am totally computerizing my Truck. It currently has a variety of computer modules controlling everything already but I want to tie into the systems and be able to control them with my PC or ARM boards.
At this time I expect to use 3 different "levels" of computers.
1. Currently have an i3 based PC that will be running windows to interface into the truck while running. It will be the entertainment hub as well.
2. Multiple ARM based boards to run specialized interfaces such as a voice based AI system, 3d vision and/or radar object detection etc.
3. Microprocessor based machines. I see no reason to go anywhere other than the Propeller chips. I will be using these to do most of my actual hardware interfacing and due to their simplicity will use them wherever possible.
Has anyone had any experience interfacing Propellers into the data bus of a vehicle? I will likely start out making a ODBII device emulator since all this will require is a USB interface and some programming. I want to evolve this into something that could be placed on a CAN bus of a vehicle to act as a new module or control other devices on the bus. For an example of such an application look no further than currently available car start units that use the CANBUS to do everything from a microprocessor run module. I will likely start out using an ELM type ODBII to serial chip to get it working and eventually try to drop the ELM chip all together if the Prop can do the same thing easily.
Eventually I want to build a system that could easily be confused as being a real life version of a "knightrider" vehicle.
I have an alarm going into the truck in the next week I can control from my phone which I will try to reverse engineer so I can duplicate it and control it from my computer. This will likely be my first actual use of a prop in my truck. But I also hope to potentially replace or tie into every switch and control in my truck so I can access it via my computer. If I can access it from my computer I will also be able to control it from my phone. And where it makes sense I will fully automate functions that take switches now.
I am looking at what screen I can install into my truck now so I can install the PC. I will be using the PC initially in place to scan the vehicle buses and learn their codes.
So I am thinking I want to make a generic prop based canbus board that can be accessed via the computer and could be networked with other canbus boards either directly or over the vehicle bus with unused outputs available to be used to control whatever device intended. Or potentially have a "man in the middle" type of dual canbus device that can allow me to use the OEM switches but intercept messages to allow customized controls.
As an example, the winshield wipers are controlled by canbus but if I try to over ride the wiper switch with ODBII commands it will only work until the next update is done by the switch. If I intercept the messages I can let the switch still work but also allow the PC to over ride the switch easily.
I can think of many other functions as well. I may be able to make a self driving vehicle in this manner eventually by typing into everything in my truck. But I would rather make a generic module I can base everything off of to start with so I am curious if anyone has done any work tying into a vehicle bus with a prop. I am sure the Prop is much more powerful than the ELM chips that are commonly available.
Window Roll up "module" is another example.
Rodney
Comments
http://forums.parallax.com/showthread.php/87581-CANbus-for-the-Propeller-is-nearly-here
But not sure if that really applies...
For anyone wondering why... I have a number of projects to do in this truck that will require interfacing into the vehicle bus to monitor or manipulate. If I use an ELM device each time it can get expensive and not very flexible. If I can build a Prop board to do this instead I have a programmable interface I can do whatever I want with.
Are you talking small truck ( ford f-150 or GMC 1500) or large truck ? The protocol is very different, cars and trucks use obd II and heavy trucks and equipment uses J1939 or some variant. The OBD 2 is fairly easy to talk too ,but J1939 is a little more complicated.
Brian
My basic understanding at this time is that it has 2 ODBII buses with one being high speed and one being low speed. There may be another bus for specialized stuff as well but I believe this to be an inverted RS232 which should be easy to drive with the Prop. (+12 is the same as a standard rs232 low and 0V is the same as standard rs232 hi. Uses 8,n,1 otherwise)
I will be reverse engineering the radio system as well. In my truck I have the rear entertainment system, Xm radio and I will likely add steering wheel controls as well. Currently these are all driven through the radio and all of the system chimes are as well. I want to build a Prop or something similar that will replace the radio in the system and allow me to interface the computer directly to the system. I could actually sell a product if I get this figured out. There are a bunch of people looking to be able to control their computer with their steering wheel controls and be able to use the factory radio add ons such as the XM radio or an add on cd player etc.
Another area I will be playing with is the Dash cluster. I want to replace the cluster with flat screens and will likely try using a Prop to interface here too. The cluster uses an ODBII data connection to pull RPM, Speed, temps but the trouble lights are driven directly from the body control module so I would have to setup triggers to read those lights. Since the Prop isn't powerful enough to also do a fully animated display I would likely pair this with one of my ARM boards and use that board to do the actual display. The arm board DOES have a CAN driver build into it but I may use the Prop so I can offload all of the data collection to the prop and just use the ARM for displaying it. Anyone that has seen the CES2013 Bentley QNX demo can see where I am going with this. Would be really cool if I could have the prop (or a secondary prop) do the display for the speedo and gear selector and just use the ARM for other stuff on another screen but not sure the prop is powerful enough to be able to show a full needle type speedo. The gear selector can be simply text which is easy. If I can figure out how to read the display I may also try to show that as well instead of using the clusters display. (I will likely use this in parallel with the original cluster to keep the mileage in the cluster and just overlay the screens over the cluster. I can remove the needle motors and the small character displays it has now to have room for the monitors. )
The point of this project is first of all this will be cool as heck and be a great mobile resume for me to get a nice job after I retire from my current job in just over 7 years. Plus I need a Capstone for each of my Degrees and this will have aspects I can use for both my programming and my security degrees. (I won't even get into the plans I have to have an automated "pen testing" setup on this truck I will be able to run from my phone since that is not related to Props...) The idea of the mobile automated pen testing platform is to be able to park my truck and have it do automated pen testing while sitting in the parking lot. With prior written permission of course. So not only will this be a cool truck but a thief would have a very bad day if they flat bedded this truck and brought it back to their shop... Assuming they have WiFi in their shop and don't block cell access to the truck...
The Radio related aspects are something I posted about on an Avalanche specific site and I already have people asking me for more information. So I could very easily build a device I could sell to interface into the current controls and tie them to a computer since no one has done anything past the steering wheel controls at this time. Plus then I could also get them working with after market radios as well.
The dash cluster replacement is another product I could sell and I also want to build a system to replace the HVAC controls in my truck. I have manual controls but they communicate via ODBII to the HVAC module. I may have to drive stepper motors and linear actuators but that should be easy to do with a Prop with all of the robotics stuff out there. With this module I would love to be able to just send the prop a couple of settings and let it do the work automatically. I need to remove the HVAC controls so I can replace the current radio and HVAC controls with another screen and don't want to re locate the HVAC controls. With the number of people doing CarPC's now it would be a simple thing to sell if I could build an HVAC controller to replace the factory one. Might need to add a simple touch screen to the Prop for this if I do sell it since I will be accessing it from an ARM and from the PC. Others may want to access it via the computer and a more reliable touch screen directly attached.
Rodney
And at this point maybe I need to look at what I need for a circuit to connect to my bus?
I am also hoping that work I do on my truck will head me towards a project I have been dreaming of since I bought my first LT1 Edit program. I want to build a universal Vehicle Bus system that will make connecting to any vehicle as easy as hooking to a printer. The Prop would be a great tool to make this work since it could be setup to connect to any vehicle bus and provide a USB based communication back to the PC. The idea is the PC will recognize the car as easily as it would a printer and be able to use very generic software to communicate. The aspects of what would be available on the vehicle would only be limited by the interfaces added to the vehicle. So one car could have multiple interfaces and the computer wouldn't care. It would only know what options it has available to it. This could then be used in an older ODBI car as well when a connector is built and proper driver written. You could also build other components to interface into older non data bus vehicles and make them work too. And the prop would be a great tool to make those interfaces as well. I have an older '94 Caprice I would use for a test bed for the ODBI stuff and non ODB interfacing of things like the windows and HVAC.
Personally I think if I develop a system that works with my truck others will "latch on" as they have with other projects. And I could potentially use other project resources in my more universal project.
So I am certainly interested in work that has already been done getting props to work with vehicles.
I just looked briefly at the link you provided ChrisGadd, I am extremly interested in your project. If you have a forum thread where you discuss this could you forward that to me or at a minimum could you help me with getting some hardware up and running with your software to give me a place to start?
Thanks!
Rodney
I helped another user turn it into a general-purpose CANbus monitor in this thread, where we also discussed the hardware - just a MCP2551 transceiver to drive the CANH and CANL lines and some resistors and a capacitor for line termination. I used the CAN primer from Keil as the basis of the circuit, and got the PID listing from Wikipedia, along with some more information on CANbus.
I didn't really look at any other traffic on the bus, other than to note that it is a very busy bus, and that a stuck driver can make all sorts of bad things happen to the dash cluster, as in RPM and fuel level needles bouncing, chimes sounding, announciator lights turning on, etc. Fortunately everything returned to normal after disconnecting. I'd just assumed that the bus was more segregated than it was; that the only traffic on the OBD-ii connector would be OBD-ii messages always in standard frames with 8 data bytes. That was all with a much earlier version of the driver, and I haven't had any problems with the latest version in the OBEX which pays attention to the IDE and data-length bits.
Chris
Here's a screenshot of my object reading a 2009 Chevy Cobalt:
I will also be making a can sniffer to pull up codes I don't already have.
Rodney
I have yet to start playing with my propeller. I have a "starter kit" that has a couple books on how to program the propeller in Spin and I believe a "board of education". It has a bread board on it. This was a package deal that Parallax had on sale at the time...
Anyhow I looked at the information Chris provided and read up on the other thread he is currently involved with so I am hoping he stops back by this thread...
I am probably a month or so away from playing with this but I wanted to throw some feelers out there about how I should be approaching this.
I will be "sniffing" a 2003 Chevy Pickup. My understanding is there is a fast bus (Probably very similar to the 500k bus in the 2009 cobalt) and a slower Single Wire bus that is used by the convenience and entertainment systems. I believe this bus to be 1k (But could be 10k) but otherwise is compatible with a standard CAN Bus. It is called the GMLAN or Class 2 databus but is similar in either case.
This bus is also a single wire bus. I have read you can use a standard CAN BUS device by hooking the CAN Lo to ground and the CAN Hi to the single wire data line.
I am thinking of building what I am calling a relay sniffer. The intent is to hook two CAN BUS transceivers to a propeller and cut the current data link at the device I want to sniff. I would then have a bus connected transceiver and a Device connected transceiver. The Propeller then will have to pickup all messages on the bus and pass them through to the device un modified. The Responses by the device then would then be passed back in the same manner. This would allow me to isolate the device and insure I am catching all commands related to it. I would also denote wither an entry was captured from the bus or from the device.
Will this be possible with a Propeller?
Also I saw that the Transceiver used was set at 500k. Can this be used at slower speeds? I am assuming that the Propeller should be fast enough to be mostly idle at even 10k and only using one COG.
Other options I am considering. I am thinking I want to be able to have multiple "sniffers" in my system to be able to see how the different devices interact at the same time. If I do this I would like to have multiple Props used and they should be able to be synced to one another time wise. Maybe a RTC with the props synchronizing every so often over a connection of some sort. I was also thinking it would be nice to have more memory onboard available for the prop to save to so I wouldn't have to have a PC connected in real time to capture the data. Maybe to a large SD card or something. Although in an automotive environment an SDcard may not be hardy enough. I could also connect all of them to a PC to download the data through the USB port.
Am I biting off too much for a Propeller or am I in the right ball park?
Not having actually worked with a Propeller yet I do not know what they are capable of.
Anyhow I am thinking maybe one cog is able to do the relaying and maybe save the log to some sort of common memory that all of the cogs can access. Have another cog transfer from this common memory to an SDcard or other more durable memory for storage. A 4th cog could be used to check for the existence of a connection over the USB port and if there is one download all the data and clear it off the SDcard.
Thanks for any suggestion given. If the prop is powerful enough maybe I could even install up to 4 CAN BUS transceivers so I could sniff two devices at a time?
I may have already mentioned this but I have an i5 based computer in my truck now and I hope to eventually be able to remove the OEM radio and use this PC in its place while being able to communicate to the devices connected to the radio. I also want to remove the HVAC controls and be able to interface into some other items as well. Once I am able to remove the OEM radio and the HVAC controls I will be replacing them with a large touch screen. I am hoping to maintain the operation of the system chime, the rear seat entertainment system, the XM radio module and the steering wheel controls. I think these will be easy to find once I am able to connect to them. I also have an aftermarket alarm that starts the vehicle and does some other stuff as well that I would like to be able to do with the computer and get rid of the alarm all together. (Will likely replace the alarm brain with a Propeller, or low powered ARM device.)
Rodney
Your relay-sniffer sounds plausible, absolutely possible with a Prop, and I can't see any problems with duplicating the sniffer on multiple Props to monitor multiple nodes. I'm not too sure about synchronizing them. Each node waits for a lull before sending, but since you're effectively creating multiple busses, there's a chance that every node would see a lull on their relays at the same time. The relays would all be connected together through a single bus so the messages would eventually be sorted out, though the precise order of which node sent first would be lost. It seems to me that if you capture the message traffic at each relay, you can use the logs to determine when each node sent which message.
More concerning to me is that if a Prop gets hung up, the node that you've isolated will be effectively cut off, which could cause Bad Things to happen.
It was my understanding that each node used a particular set of identifiers anyhow. Simply filtering messages based on the Ident should let you know the origin of each message, without having to isolate any nodes.
For storage, I can't say how susceptible to noise the SD card objects are; the only time I used one in the car was on a standalone GPS datalogger. I can say that even a small-by-today's standards 4GB card should be able to store over 300 million messages, providing storage for over 18 hours of non-stop traffic.
Regarding cog usage, my Prop-based drivers require one cog for writing and one cog for reading (up to 500Kbps). I do have also have a version that uses a single cog to do both, but not at the same timethe Prop isn't able to read an incoming message that wins arbitration over an outgoing message, so it's not a good idea for a relay. Should work fine if you're sending one query and waiting for a response before sending the next query though.
Also, other members on the forum have reported problems with the way my drivers send acknowledge pulses. I've compared my drivers against a MCP2515 and haven't been able to spot any difference in the bitstreams on a logic analyzer. In case you want to play it safe and use a bona fide MCP2515, I've also submitted a driver for that to the Obex here.
The sniffing I would be doing is things such as the HVAC, radio controls and other features such as window switches etc.
I figured this might also let me modify controls that come from the bus to the device while isolating the device from the bus and causing other issues.
Also sounds like if I use the prop and use it as a relay I should assign 2 cogs for one direction and 2 cogs for the other direction. This might work just fine. Then I would just be lining up both sides of the communication. I may find out that this isn't necessary but my intent is to be able to eventually replace, compliment or add computer controls to some of the components. Also sniffing the already installed alarm system will allow me to bypass the security side of it without needing to know the authorization algorithm that I would otherwise have to guess as well to be able to start the truck.
The dash cluster has a series of connections directly to the BCM and the Class 2 Data bus connection for its displays. I plan to access this to figure out how it communicates in preparation of overlaying flat screen displays over the factory cluster. (Leaving the original cluster base, pulling off all of the motors etc.. This allows it to track the odometer so I can revert back if I ever decide to.)
Would be great if I can just use a PROP but items such as the ELM327 chips are pretty cheap if it gets too hairy.
Rodney
For GMLAN, it sounds like you might be able to get away with just a simple transistor driver or somesuch. One of the first hits on Google mentions 0-5V signalling, with 12V to 'wake it up.'
My truck has 2 data buses in it. One is the high speed side which has everything on it. I could probably do all of my work on this bus but there is a bunch of Smile on the bus and I believe the BCM actually works as a "transfer station" between the high and low speed buses. The majority of my interest at this time is on the low speed bus which is labeled as a "Class 2 databus" but appears to be the same as the later "GMLAN". I don't know if the GMLAN has some additional protocols or what but I have not been able to tell a difference other than somewhere around the year of my truck the Class 2 Databus became the GMLAN. I believe the low speed lan will only be dealing with the "entertainment and convenience " devices and do so directly without having to relay through the BCM. I could just use a standard CAN bus setup to the main ODBII bus and be done with it but from what I am understanding I am best served if I can stay on the low speed bus for my stuff. Plus I believe the radio talks directly to some of the modules. So however I look at it hooking to the GMLAN is my best bet.
I have seen three different modes of connecting to this SW low speed bus.
1.Use of transistors and line inputs into a microprocessor or arduino. I believe this is what you are refering to.
2.I have also seen mention of using a modified RS232 setup to convert the voltages to the proper range.
3. Use a CANBUS or ODBII connection device and just wire the CAN-Lo to the ground and Can-Hi to the data line.
Modes 1 & 2 I have seen mention of decent reading capability but issues when trying to write back to the data bus. The only mode I have seen where anyone has had any success writing back to the databus was when using a Can Bus device.
So getting back to the MCP2551 and MCP2515 I will have to look at what they are defined as but what do they actually do and why do we need to use both?
Is one the hardware connection and the other the software protocol that uses the hardware connection? In that case you are duplicating the software protocol in a Propeller program?
My background is mostly in programming with very little hardware knowledge. Although I have soldered on memory upgrades to computers and had to trouble shoot them in the past and have made my own simple circuits on a bread board I really don't have much of a clue building circuits. Let alone building my own circuit boards.
Thanks for your help!
A local community college near me does have classes that could teach me most of this basic stuff and even go into building my own circuit boards. Maybe they might be worth taking. Although I am currently working on a software engineering degree.
Rodney
A standard frame looks like this:
RTR (Remote-transmission request bit) CRC delimiter | IDE (Extended frame bit) | ACK SOF | | Data length (0 - 8) | | ACK delimiter | Ident | | R0 | Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 CRC | | | EOF | | | | | | | | | | | | | | | | | | | 0_xxxxxxxxxxx_0_0_0_1000_xxxxxxxx_xxxxxxxx_xxxxxxxx_xxxxxxxx_xxxxxxxx_xxxxxxxx_xxxxxxxx_xxxxxxxx_xxxxxxxxxxxxxxx_1_i_1_1111111Also, CAN uses transitions on the bus to maintain synchronization. If there are five consecutive high or low bits, the controller forces a transition by adding a stuffed bit. The controller also does all of this in reverse to receive a message by unstuffing the message and parsing the bytes after verifying the checksum.So the job of the controller is to encode and decode data bytes in frames for transmitting and receiving.
The job of the CAN transceiver (MCP2551) is to convert the signal between the logic levels of the controller (0 - 3.3V) and the CANbus levels (1V & 4V - 2.5V).
As for the why of my Prop-based controller... One of the most common criticisms of the Prop is that it doesn't have built-in peripherals, no ADCs, no UARTs, no I2C, etc. The common response to that criticism is that the Prop doesn't need built-in peripherals because it has eight cogs that can be used to provide virtual peripherals. I therefore found it somewhat perplexing that whenever anyone asked for advice on using CAN with the Prop, the response was always to use a MCP2515 controller, and decided to see for myself what the big deal was about creating a virtual CAN driver. Also, something just appeals to me being able to do as much as possible without adding extra hardware.
As it turns out, it ain't no picnic, but then the MCP2515 isn't exactly a simple device either. The Serial-Peripheral-Interface (SPI) used to communicate with the MCP2515 is simple enough, but configuring all of the registers to get it to do what I wanted took a bit of studying of the datasheet before I was even ready to start writing Prop methods.
All of that work is now done, the Prop-based drivers and the MCP2515 driver provide much of the same functionality. There are high-level Spin-based methods that I've tried to make as easy to use as possible.
I might need to look into this Class 2 Databus some more. One of my misbegotten federally-mandated tire pressure sensors is on the fritz, and it would be nice to be able to get rid of them entirely. I definitely agree that staying on the "entertainment and convenience" bus is a good idea if at all possible.
So if I am understanding things.. To compare, a standard LAN connection has 7 different layers..
As I am seeing it now CANBUS seems to have 3 (Or more) with the bottom 2 being able to be controlled with the mentioned chips. The actual communications of the device chatter would fully need to be done by the Prop and is what I am calling the third layer.
Do you have any schematics on how to wire up either solution? (prop/controller/transceiver or prop/transceiver)
And does using only the transceiver with the Prop as the controller take a significant amount of processing power from the prop? I would likely just go the full hardware route leaving the prop available to do as much work as possible.
Based on what you have said Chris, I am guessing If I just do a sniffer I would only need one set of chips. if I decide to go to the extent of the relay I can see needing 4 sets... Seems a bit complex for me. (one for reading the main bus, one for writing to the device bus,one for reading from the device bus, one for writing to the main bus)
For PC to ODBII connections there are some solutions available that use an ELM327 chip or compatible. I am assuming this is like having the transceiver, controller and a microprocessor all on board with the logic to be able to communicate between the PC and vehicle. There is buffering and much other stuff to make life easier. The chip is controlled with a HAYES modem type command set. I have read it is only for diagnostic purposes and is somewhat limited. For instance if you want to download or upload a new PROM to a vehicle module you are out of luck. While this solution handles all the different protocols for you and makes things simpler in the short term I am thinking the limitations and the cost are limiting factors. (I can probably get a ELM compatible chip somewhat cheap but would have to dig for one. Scantools has a DIP package that is more powerful than standard ELM chip but it is over $40 last time I checked.)
Since it appears my truck is CAN BUS compatible on both the high speed CAN BUS and the slow speed E & C (GMLAN, Class 2 Data bus) I see the ELM solution as over kill. Using the transceiver either with or without the controller with a prop I am assuming the only limitations accessing the CAN BUS will be my knowledge of the actual data and commands that gets transmitted between the devices in my truck. For instance I emailed briefly with a company that sells a product that allows you to modify the ECM program to adjust for new engine upgrades etc. The sales person told me the ELM devices were limited and did not support what was needed to access the ECM to reprogram it. I have also seen mention from security researchers that the ELM devices would not work for their research because of their limitations so they purchased multiple CAN BUS testers. When I priced those out they were in the $1000 range apiece and they used 2 or 3.
So I am guessing by using your solution I would have similar access to the CAN BUS as these $1000 devices?
Not sure what all they did but sure sounded impressive. And way overkill for what I want to do.
Thanks again!
Rodney
The controllers and transceivers are bi-directional, so a single transceiver sends to and receives from the CANbus, and a single controller writes to and reads from the transceiver. A sniffer would require one of each, a relay would require two of each. Thats for the hardware controller, my Prop-based controller does have separate objects for reading and writing, so a Prop-based sniffer uses 2 cogs and a relay uses 4 cogs. Given the slow speed of the class-2 databus, Ive little doubt that the objects could be modified to enable a single cog to write and read, without missing any messages due to arbitration. I still havent managed to find any sort of document discussing the nitty gritty of the protocol, specifically the speed.
So to compare:
The MCP2515 requires 3 or 4 pins for SPI (clock and MISO/MOSI can be shared with other SPI devices), and requires an external oscillator that can be provided by another Prop pin. On the plus side, it can be run from the main method using a Spin-based SPI driver for slow speeds, or a single cog running a PASM-based driver for faster speeds. Note thats the speed that the Prop talks to the MCP2515, and is independent of the CANbus bitrate.
The Prop-based controller only requires 2 pins (RxD and TxD), but on the minus side requires 1 cog for writing and 1 for reading. A combined reader/writer object exists that only needs a single cog, but the possibility of missing messages makes it an issue for a relay, maybe acceptable for a sniffer. The Prop-based controllers are a bit more flexible, providing instant access to the messages as they come in rather than having to poll a status register and transfer over SPI.
So hardware with extra pins vs. software with extra cogs, both routes use about 400 longs.
The $1000 devices likely had lots of proprietary codes built in. The MCP2515 and the Prop-based controller both produce and decode the same messages. Determining what the messages mean is the trick.
I have a Propeller Demo board at home and I have seen where the two chips you mention are less than $5 so I would like to try the combination of both chips and just the transciever with the prop I have now and see what happens.
I am at a basic hardware level. I took some classes, can solder pretty decent (not SMD components yet.) I can probably put a board together if I know the components and how they line up.
When you mentioned the prop needs to feed the transciever a frequency I am assuming using a dedicated cog and some code to produce a frequency off one of the I/O lines. Likely in assembly if spin isn't fast enough. But I am also assuming this is included in your object.
I hope to get something up and running shortly. I have seen a sparkfun board that can be hooked to a microprocessor that has both on it and I have seen some arduino shields with them on it but I am assuming it is simple to hook to a prop. Might end up getting a Prop prototyping board once I get it working with the demo board I have and make a more permanent solution.
Thanks for your help so far!
Will of course offer up anything I find out as well. I do have some links related to the GMLAN that I have saved if you would be interested in those. I am sure if you have been searching you already have seen a couple of them.
Rodney
http://elmelectronics.com/DSheets/ELM329DS.pdf
http://elmelectronics.com/obdic.html
https://www.kickstarter.com/projects/etx/canbus-triple-the-car-hacking-platform
It's still up to you to figure out how to connect it to the class 2 databus, which should be on the top-left pin of the OBD2 connector (as facing the vehicle connector).
The oscillator frequency is needed by the MCP2515 controller, not the transceiver. Each cog has two counters, I simply use one of them for a 20MHz clock. Setting the bitrate on the MCP2515 is somewhat involved, determined by the oscillator frequency, a baud-rate-prescaler, and some time-quanta. The datasheet gives all the details.
Might be worth checking out that Arduino solution but I would think the Propeller is more powerful than the arduino's.
Rodney
The connection to the car is just a simple PNP transistor driver for transmitting and a current limiting resistor for the receiver. I tried to make a single-pin object, but the Propeller doesn't quite have the chutzpah to drive the line above the threshold voltage. GMLAN idles the bus low, and the signalling is inverted. A dominant 0 bit drives the bus up to ~4V, a recessive 1 bit floats the bus to ground.
Anyhow, here it is, I'm holding off on submitting it to the Obex until I figure out these ID's and byte codes.
GMLAN Demo - Archive.zip
Here's an example of my message traffic.
GMLAN traffic.txt
And how do you hook up the transistor?
I am a hardware newbie so please be kind...
I have been a programmer for many years but I have never built a working transistor circuit. And been a while since I played with voltage dividers or anything like that.
I would like to prototype up something in the next couple weeks with this and see what happens. I may not be able to find time however until this semester finishes up. But kind of excited you were able to get it working. When I have it working I will be putting it on the radio data bus. I believe the radio is hooked to the normal GMLAN but then the radio has a class 2 data line that goes to its accessories to talk to them without clatter from the rest of the vehicle. I could be wrong but I believe that is how it works. So it is very encouraging to hear you have it working for what sounds like very cheaply. Do you suggest anything special to power the circuit? A specific voltage regulator to drop the automotive voltage?
Thanks again for your work on this. With your help I might just be able to build my own radio harness adapter that also works to allow me to use all of the other components with my computer such as factory amplifier, rear seat entertainment controls and XM radio.
Rodney
The components are what I had near to hand, I suspect most any PNP transistor should do. The resistors are all common values, the only part that gave me any trouble was the voltage divider needed to drop the supply voltage from 5V to ~4V. Definitely need some drop there as a straight 5V causes Bad Things™ on the dashboard, too little and the Prop can't send messages, and with too much impedance the receiver will be intermittent. This circuit will get the job done, at least for experimenting.
Chris
This uses a CAN unit to communicate with the GMLAN:
http://developer.mbed.org/users/foxdie/code/GMLAN-Sniffer/
A couple other "modder" sites that have information on them are:
http://www.carmodder.com/portal.php
http://www.gmupfitter.com/
Another good site to get information is:
http://www.scantool.net/
Scantool is the manufacturer of a series of ELM compatible ODBII devices but the forums under "support" have lots of interesting information.
So what did you use as a power supply within your car? Did you use a Ciglighter/USB charger and just wire it to the input on your board?
A couple other "bus hacking" links:
http://www.canbushack.com/blog/index.php
http://gmlanhack.blogspot.com/
Rodney
Regarding the power supply, I probably should've mentioned that all of my testing has been in the garage with the engine off, using a wall-wart plugged into a powered breadboard. I have previously drawn +12V from the bottom right pin of the OBD-II connector, regulated it to 9 volts with a 7809, and used that to power a demo board. Or you could simply use a 9-volt battery.
Does the ODBII connector provide a regulated 12 volt or is it a common automotive power supply? (aka 13.5+ volts while running)
Rodney