Need help on Project viability
sun-tracker 2014-05-07 13:29:21 10828 Views7 Replies Hello all,
Am hoping somebody can help me determine if what I want to do is feasible.
I've read through the product pages and believe that the OBD-II Adapter with GPS ([url=http://arduinodev.com/store/index.php?route=product/product&path=20&product_id=52]http://arduinodev.com/store/index.php?route=product/product&path=20&product_id=52[/url]) should be a good starting point.
Here are my questions:
1. Since the adapter linked above includes an embedded arduino, do I have complete control over that arduino (via uploaded sketches) to poll / aggregate data coming out of the OBD-II Port?
2. If yes to the above, am I able to then push that data via bluetooth to another controller elsewhere in the vehicle? (I'm pretty sure you can, just want to confirm)
3. If yes to #1, what cable do I need to program the on-board Arduino?
4. Related to the above, I have no idea what "Leadout Cable" or "Cable Connector" to select... what are these cables used for?
5. Is there any reason I would choose Bluetooth 2.1 over 4.0 if my receiving unit is 4.0-capable?
6. Is this device able to utilize the full bandwidth of Bluetooth 4.0 (BLE) and push data out as it is received from the ECU?
My ultimate goal is to transmit OBD-II data to another computer in the vehicle for display on the OEM radio screen.
Thanks in advance!
Am hoping somebody can help me determine if what I want to do is feasible.
I've read through the product pages and believe that the OBD-II Adapter with GPS ([url=http://arduinodev.com/store/index.php?route=product/product&path=20&product_id=52]http://arduinodev.com/store/index.php?route=product/product&path=20&product_id=52[/url]) should be a good starting point.
Here are my questions:
1. Since the adapter linked above includes an embedded arduino, do I have complete control over that arduino (via uploaded sketches) to poll / aggregate data coming out of the OBD-II Port?
2. If yes to the above, am I able to then push that data via bluetooth to another controller elsewhere in the vehicle? (I'm pretty sure you can, just want to confirm)
3. If yes to #1, what cable do I need to program the on-board Arduino?
4. Related to the above, I have no idea what "Leadout Cable" or "Cable Connector" to select... what are these cables used for?
5. Is there any reason I would choose Bluetooth 2.1 over 4.0 if my receiving unit is 4.0-capable?
6. Is this device able to utilize the full bandwidth of Bluetooth 4.0 (BLE) and push data out as it is received from the ECU?
My ultimate goal is to transmit OBD-II data to another computer in the vehicle for display on the OEM radio screen.
Thanks in advance!
2014-05-15 08:17:06 Yes you can 'write' things to the BUS. For example, on some vehicles you can roll down/up windows, change radio stations, etc. by putting ("spoofing") messages -- the receiving module wouldn't be able to tell you sent it unless it requires encryption.
I'm sure that setting things like engine timing are not accessible unless you have access to Level 2 or Level 3 (which requires decryption). To be honest I wouldn't personally want my device to be able to mess with something like cruise control -- too dangerous in my opinion.
If you watch some of the videos on the middle link I posted, you'll see that he was able to send text ("HACKED!") to his in-dash message display. sun-tracker
I'm sure that setting things like engine timing are not accessible unless you have access to Level 2 or Level 3 (which requires decryption). To be honest I wouldn't personally want my device to be able to mess with something like cruise control -- too dangerous in my opinion.
If you watch some of the videos on the middle link I posted, you'll see that he was able to send text ("HACKED!") to his in-dash message display.
sun-tracker 2014-05-14 10:48:17 So after some more digging, it is apparent that I actually need to access the CAN network(s) in the vehicle and go 'deeper' than what OBD-II typically provides. On many vehicles, one of the CAN lines can be exposed on the OBD-II Port (CAN-High and CAN-Low pins) which provides the ability to directly observe traffic on the bus.
Here are some links I've found:
[url=http://fabiobaltieri.com/2013/07/23/hacking-into-a-vehicle-can-bus-toyothack-and-socketcan/]http://fabiobaltieri.com/2013/07/23/hacking-into-a-vehicle-can-bus-toyothack-and-socketcan/[/url]
[url=http://chadgibbons.com/2013/12/29/hacking-the-jeep-interior-can-bus/]http://chadgibbons.com/2013/12/29/hacking-the-jeep-interior-can-bus/[/url] (his youtube videos 3,4,5 are especially interesting)
[url=http://hackaday.com/2013/10/21/can-hacking-introductions/]http://hackaday.com/2013/10/21/can-hacking-introductions/[/url]
I've also read that data on the CAN networks typically fall into one of 3 Levels. Level 1 is auto-shop / dealership level which may/may-not be encoded, Level 2 is third-party development/manufacturing and is almost always encoded, and Level 3 is the lowest/deepest level of data available and closely guarded by the primary manufacturer (Toyota, Ford, etc.). With everything I'm looking to do, level 1 should be sufficient and in many cases is not encoded. What's interesting is that Toyota specifically stated they are not concerned with in-car (physical) reverse-engineering of those codes; they are only concerned about remote (over the air) attacks, so if somebody were to get down to level 2 and level 3 data on the CAN networks, they wouldn't be breaking any laws as far as Toyota is concerned (can't speak on other manufacturers).
Here's the quote:
[quote]Toyota and Ford have publicly played down the research. The researchers provided both auto companies with their white paper, but neither firm has promised any fixes. Ford said in a statement for a "Today" show segment featuring Miller and Valasek's research that "This particular attack was not performed remotely over-the-air, but as a highly aggressive direct physical manipulation of one vehicle ... which would not be a risk to customers."
Miller says Toyota's response was similar, saying its focus was on remote attacks and that this research didn't constitute hacking. It's unlikely that Ford or Toyota will address the security issues in the end, he says. "It's not enough to get them to do anything. And it's not a Web browser bug, where you could release a patch.[/quote]
sun-tracker
Here are some links I've found:
[url=http://fabiobaltieri.com/2013/07/23/hacking-into-a-vehicle-can-bus-toyothack-and-socketcan/]http://fabiobaltieri.com/2013/07/23/hacking-into-a-vehicle-can-bus-toyothack-and-socketcan/[/url]
[url=http://chadgibbons.com/2013/12/29/hacking-the-jeep-interior-can-bus/]http://chadgibbons.com/2013/12/29/hacking-the-jeep-interior-can-bus/[/url] (his youtube videos 3,4,5 are especially interesting)
[url=http://hackaday.com/2013/10/21/can-hacking-introductions/]http://hackaday.com/2013/10/21/can-hacking-introductions/[/url]
I've also read that data on the CAN networks typically fall into one of 3 Levels. Level 1 is auto-shop / dealership level which may/may-not be encoded, Level 2 is third-party development/manufacturing and is almost always encoded, and Level 3 is the lowest/deepest level of data available and closely guarded by the primary manufacturer (Toyota, Ford, etc.). With everything I'm looking to do, level 1 should be sufficient and in many cases is not encoded. What's interesting is that Toyota specifically stated they are not concerned with in-car (physical) reverse-engineering of those codes; they are only concerned about remote (over the air) attacks, so if somebody were to get down to level 2 and level 3 data on the CAN networks, they wouldn't be breaking any laws as far as Toyota is concerned (can't speak on other manufacturers).
Here's the quote:
[quote]Toyota and Ford have publicly played down the research. The researchers provided both auto companies with their white paper, but neither firm has promised any fixes. Ford said in a statement for a "Today" show segment featuring Miller and Valasek's research that "This particular attack was not performed remotely over-the-air, but as a highly aggressive direct physical manipulation of one vehicle ... which would not be a risk to customers."
Miller says Toyota's response was similar, saying its focus was on remote attacks and that this research didn't constitute hacking. It's unlikely that Ford or Toyota will address the security issues in the end, he says. "It's not enough to get them to do anything. And it's not a Web browser bug, where you could release a patch.[/quote]
sun-tracker 2014-05-12 20:56:12 That is possible according to: [url=http://en.wikipedia.org/wiki/OBD-II_PIDs#Non-standard_PIDs]http://en.wikipedia.org/wiki/OBD-II_PIDs#Non-standard_PIDs[/url] , best way get the info you are looking for is probably a forum specific to your car model or contact directly the manufacturer of your car.
The C0041 you mentioned, however seems to be an error code, those can be read (and often deleted) by the cheap ebay BT dongle and an android app like Torque, not really a signal of some sort like individual wheel speeds. Often to read very car/model specific data, you need to get your hands on the manufacturer specific diagnose tools, that are often not directly sold to the public and are also very expensive, sometimes there are illegal versions circulating, but those are often not the newest versions and of course illegal ;) orpheus88
The C0041 you mentioned, however seems to be an error code, those can be read (and often deleted) by the cheap ebay BT dongle and an android app like Torque, not really a signal of some sort like individual wheel speeds. Often to read very car/model specific data, you need to get your hands on the manufacturer specific diagnose tools, that are often not directly sold to the public and are also very expensive, sometimes there are illegal versions circulating, but those are often not the newest versions and of course illegal ;)
orpheus88 2014-05-12 09:11:15 Is it true that some extended PID's are 'encoded' and the only way to get the decrypt key is to pay a sizable fee (a professional tool, for example)? sun-tracker
sun-tracker 2014-05-10 04:39:24 You can directly use the PIDs defined in OBD.h ([url=http://arduinodev.com/obd_library_pids_update/]http://arduinodev.com/obd_library_pids_update/[/url])
If you define other Mode 1 PIDs ([url=http://en.wikipedia.org/wiki/OBD-II_PIDs#Mode_01]http://en.wikipedia.org/wiki/OBD-II_PIDs#Mode_01[/url]) yourself like they are defined in OBD.h those should be no problem either, if you want to access stuff thats not accessible with Mode 1, you will probably have to change the functions if the hardware supports it at all.
I have one, but so far it has been much work to get things to run smoothly and for example parsing gps data on the device still doesn't work properly, see my thread [url=http://www.dfrobot.com/forum/index.php?topic=18368.0]http://www.dfrobot.com/forum/index.php?topic=18368.0[/url]
I have it logging now without parsing gps just logging the GPS NMEA data, which works well and I built myself a script to extract the actual GPS data from the nmea messages and format them in the way that Freematics GPS OBD Charting requires. But even the Charting Service doesn't always work, today I get time outs and error messages from it, but maybe its because of the layout changes to the website. orpheus88
If you define other Mode 1 PIDs ([url=http://en.wikipedia.org/wiki/OBD-II_PIDs#Mode_01]http://en.wikipedia.org/wiki/OBD-II_PIDs#Mode_01[/url]) yourself like they are defined in OBD.h those should be no problem either, if you want to access stuff thats not accessible with Mode 1, you will probably have to change the functions if the hardware supports it at all.
I have one, but so far it has been much work to get things to run smoothly and for example parsing gps data on the device still doesn't work properly, see my thread [url=http://www.dfrobot.com/forum/index.php?topic=18368.0]http://www.dfrobot.com/forum/index.php?topic=18368.0[/url]
I have it logging now without parsing gps just logging the GPS NMEA data, which works well and I built myself a script to extract the actual GPS data from the nmea messages and format them in the way that Freematics GPS OBD Charting requires. But even the Charting Service doesn't always work, today I get time outs and error messages from it, but maybe its because of the layout changes to the website.
orpheus88 2014-05-09 12:17:45 Thanks for the reply!
It appears you're right about BT 2.1 vs 4.0! Thanks for pointing that out. This video seems to explain it fairly well:
[url=https://www.youtube.com/watch?v=SynyKRkbLh8]https://www.youtube.com/watch?v=SynyKRkbLh8[/url]
Looks like BT 2.1 is designed for continuous/streaming data while 4.0 (BLE) is for periodic low-power transmissions of small amounts of data.
I have 2 other questions if you don't mind.
1) Do I have full flexibility/power to access everything the ECU is putting out? (In other words, is EVERY PID available to read, or only a small subset?). I'm particularly trying to read individual wheel speeds (which I believe an example PID for that is C0041).
2) Do you have one and does it work to your satisfaction?
Thanks again. sun-tracker
It appears you're right about BT 2.1 vs 4.0! Thanks for pointing that out. This video seems to explain it fairly well:
[url=https://www.youtube.com/watch?v=SynyKRkbLh8]https://www.youtube.com/watch?v=SynyKRkbLh8[/url]
Looks like BT 2.1 is designed for continuous/streaming data while 4.0 (BLE) is for periodic low-power transmissions of small amounts of data.
I have 2 other questions if you don't mind.
1) Do I have full flexibility/power to access everything the ECU is putting out? (In other words, is EVERY PID available to read, or only a small subset?). I'm particularly trying to read individual wheel speeds (which I believe an example PID for that is C0041).
2) Do you have one and does it work to your satisfaction?
Thanks again.
sun-tracker 2014-05-08 22:30:37 [quote="sun-tracker"]
Hello all,
Am hoping somebody can help me determine if what I want to do is feasible.
I've read through the product pages and believe that the OBD-II Adapter with GPS ([url=http://arduinodev.com/store/index.php?route=product/product&path=20&product_id=52]http://arduinodev.com/store/index.php?route=product/product&path=20&product_id=52[/url]) should be a good starting point.
Here are my questions:
1. Since the adapter linked above includes an embedded arduino, do I have complete control over that arduino (via uploaded sketches) to poll / aggregate data coming out of the OBD-II Port?
2. If yes to the above, am I able to then push that data via bluetooth to another controller elsewhere in the vehicle? (I'm pretty sure you can, just want to confirm)
3. If yes to #1, what cable do I need to program the on-board Arduino?
4. Related to the above, I have no idea what "Leadout Cable" or "Cable Connector" to select... what are these cables used for?
5. Is there any reason I would choose Bluetooth 2.1 over 4.0 if my receiving unit is 4.0-capable?
6. Is this device able to utilize the full bandwidth of Bluetooth 4.0 (BLE) and push data out as it is received from the ECU?
My ultimate goal is to transmit OBD-II data to another computer in the vehicle for display on the OEM radio screen.
Thanks in advance!
[/quote]
1 yes
2 should be possible, from the looks of it the stock firmware seems to be configured to do that over BLE
3 I've ordered with usbasp and got a connecting cable that can also be used when programming with another arduino (as isp) see [url=http://arduinodev.com/programming-guide-for-freematics-obd-ii-adapter-v2/,]http://arduinodev.com/programming-guide-for-freematics-obd-ii-adapter-v2/,[/url] but you can not programm the Freematics with just the USBASP as power source, you have to either programm it when plugged into OBD so it gets powered of that or connect the cables to another 5V power source (I use another Arduinio Uno)
4 Lead out cable is for data communication with other devices, like other arduinos or displays or other stuff, BUT the freematics already uses UART and I2C, as far as I can see, to connect to its built-in devices like dfrobot/GPS/OBD, so I'am not sure if you can actually use the lead out option, when also using all the built in hardware
5 don't know, I ordered 2.1 also because not all of my androids have BT4, but mostly because stanley wrote that you should use 2.1 so its compatible with existing apps, the elm327emu-sketch however doesn't work with for example Torque (widely used Android OBD app)
6 don't know either, but judging from the config options the baud rate for 2.1 is 38400kbits while 4.0 is just 9600kbit, so it might actually be slower
You should definitely ask any questions you have directly to stanley and order afterwards, because he seems not really active in terms of after sales support. orpheus88
Hello all,
Am hoping somebody can help me determine if what I want to do is feasible.
I've read through the product pages and believe that the OBD-II Adapter with GPS ([url=http://arduinodev.com/store/index.php?route=product/product&path=20&product_id=52]http://arduinodev.com/store/index.php?route=product/product&path=20&product_id=52[/url]) should be a good starting point.
Here are my questions:
1. Since the adapter linked above includes an embedded arduino, do I have complete control over that arduino (via uploaded sketches) to poll / aggregate data coming out of the OBD-II Port?
2. If yes to the above, am I able to then push that data via bluetooth to another controller elsewhere in the vehicle? (I'm pretty sure you can, just want to confirm)
3. If yes to #1, what cable do I need to program the on-board Arduino?
4. Related to the above, I have no idea what "Leadout Cable" or "Cable Connector" to select... what are these cables used for?
5. Is there any reason I would choose Bluetooth 2.1 over 4.0 if my receiving unit is 4.0-capable?
6. Is this device able to utilize the full bandwidth of Bluetooth 4.0 (BLE) and push data out as it is received from the ECU?
My ultimate goal is to transmit OBD-II data to another computer in the vehicle for display on the OEM radio screen.
Thanks in advance!
[/quote]
1 yes
2 should be possible, from the looks of it the stock firmware seems to be configured to do that over BLE
3 I've ordered with usbasp and got a connecting cable that can also be used when programming with another arduino (as isp) see [url=http://arduinodev.com/programming-guide-for-freematics-obd-ii-adapter-v2/,]http://arduinodev.com/programming-guide-for-freematics-obd-ii-adapter-v2/,[/url] but you can not programm the Freematics with just the USBASP as power source, you have to either programm it when plugged into OBD so it gets powered of that or connect the cables to another 5V power source (I use another Arduinio Uno)
4 Lead out cable is for data communication with other devices, like other arduinos or displays or other stuff, BUT the freematics already uses UART and I2C, as far as I can see, to connect to its built-in devices like dfrobot/GPS/OBD, so I'am not sure if you can actually use the lead out option, when also using all the built in hardware
5 don't know, I ordered 2.1 also because not all of my androids have BT4, but mostly because stanley wrote that you should use 2.1 so its compatible with existing apps, the elm327emu-sketch however doesn't work with for example Torque (widely used Android OBD app)
6 don't know either, but judging from the config options the baud rate for 2.1 is 38400kbits while 4.0 is just 9600kbit, so it might actually be slower
You should definitely ask any questions you have directly to stanley and order afterwards, because he seems not really active in terms of after sales support.
orpheus88 