I've started a Blog
#1
Lead Lap
Thread Starter
I've started a Blog
All, I have set up a blog to cover my planned modifications and research. I think that the level of detail involved is probably pretty limiting for a forum, so I will be posting the bulk of my progress over there.
I've never blogged before, so expect it to change over time.
If I can figure out how to get it running smoothly, I am hoping it will become a nice repository of technical information about the SC430 that is hopefully easy to navigate.
And of course, this doesn't mean I am leaving here. It just means the majority won't need to read my long-winded technical posts here
I think you can subscribe to the blog if you are interested.
I've allowed comments on the posts with moderation for now (not sure how spammy these free blogs can get.)
Feel free to stop over and say, 'Hi' if the sort of posts I have been making here are interesting to you.
http://retrosc430.blogspot.com/
I've never blogged before, so expect it to change over time.
If I can figure out how to get it running smoothly, I am hoping it will become a nice repository of technical information about the SC430 that is hopefully easy to navigate.
And of course, this doesn't mean I am leaving here. It just means the majority won't need to read my long-winded technical posts here
I think you can subscribe to the blog if you are interested.
I've allowed comments on the posts with moderation for now (not sure how spammy these free blogs can get.)
Feel free to stop over and say, 'Hi' if the sort of posts I have been making here are interesting to you.
http://retrosc430.blogspot.com/
#4
I'll be following the blog also. Interesting stuff!
Please don't be like most bloggers: flurry of posts in the first month, dead silence for six months, then a post saying "been too long, gonna get back to blogging" which is inevitably the last post.
Please don't be like most bloggers: flurry of posts in the first month, dead silence for six months, then a post saying "been too long, gonna get back to blogging" which is inevitably the last post.
#5
Retro,
I checked the Blog but didn't see how to say Hi there. LOL. ...but wanted to let you know I really appreciate your efforts (...and I'm sure I'm not alone here, in that regard).
I'll be following it with much anticipation, and obviously hoping for your complete success. I do have a couple of generic questions that would help me better-understand the methods you intend to use, as well as your end-goal, based on my own very-limited-understanding of the sequences of operation, for this car:
WHEN you've successfully reverse-engineered the Gateway and have determined the binary frames/packets/ & commands required to be sent over a given network (BEAN/CAN/AV) for certain functions (such as rolling down the QTR windows/etc) --- will this be accomplished :
-----via capturing those network commands on a working car (?), (assuming Toyota hasn't and won't published this info); and
AFTER you have the command set: Are you and then planning to add in a new ECU on the network (via Arduino/Ras-PI/Etc) to be able to duplicate those serial commands ?
And what do you envision seeing as the Final user-input-device that would communicate with the new ECU ? Laptop/New-Switch-bank/Smartphone over BT/Wifi/All-of-the-above?
FWIW: I'm willing to assist you in your efforts, if you think of something you need and don't have, such as documentation/washing-your-car-while-u-work/etc, --- as your stated goal is a definitely worthwhile project.
...and one final technical question:
Based on the knowledge of this car's network that you've amassed thus far, do you think there could be anything stored in any of the the existing ECUs' firmware, that might cause it to reject a command from a new ECU (that has a new ECU-Address) --- when it would normally accept that command from an existing ECU with a known address?
i.e. Does the info in the Frame-packet need to match the original command "completely", or does the "controlled" ECU simply ignore the source of the command ?
Thanks
_____________________________
2007 SC430
Starfire Pearl/Ecru
Vais SLX w/XM;
NavTool 3.0-HDMI for AppleTV,
BU Camera & BlindSpot Cam.
I checked the Blog but didn't see how to say Hi there. LOL. ...but wanted to let you know I really appreciate your efforts (...and I'm sure I'm not alone here, in that regard).
I'll be following it with much anticipation, and obviously hoping for your complete success. I do have a couple of generic questions that would help me better-understand the methods you intend to use, as well as your end-goal, based on my own very-limited-understanding of the sequences of operation, for this car:
WHEN you've successfully reverse-engineered the Gateway and have determined the binary frames/packets/ & commands required to be sent over a given network (BEAN/CAN/AV) for certain functions (such as rolling down the QTR windows/etc) --- will this be accomplished :
-----via capturing those network commands on a working car (?), (assuming Toyota hasn't and won't published this info); and
AFTER you have the command set: Are you and then planning to add in a new ECU on the network (via Arduino/Ras-PI/Etc) to be able to duplicate those serial commands ?
And what do you envision seeing as the Final user-input-device that would communicate with the new ECU ? Laptop/New-Switch-bank/Smartphone over BT/Wifi/All-of-the-above?
FWIW: I'm willing to assist you in your efforts, if you think of something you need and don't have, such as documentation/washing-your-car-while-u-work/etc, --- as your stated goal is a definitely worthwhile project.
...and one final technical question:
Based on the knowledge of this car's network that you've amassed thus far, do you think there could be anything stored in any of the the existing ECUs' firmware, that might cause it to reject a command from a new ECU (that has a new ECU-Address) --- when it would normally accept that command from an existing ECU with a known address?
i.e. Does the info in the Frame-packet need to match the original command "completely", or does the "controlled" ECU simply ignore the source of the command ?
Thanks
_____________________________
2007 SC430
Starfire Pearl/Ecru
Vais SLX w/XM;
NavTool 3.0-HDMI for AppleTV,
BU Camera & BlindSpot Cam.
#7
Lead Lap
Thread Starter
Retro,
I checked the Blog but didn't see how to say Hi there. LOL. ...but wanted to let you know I really appreciate your efforts (...and I'm sure I'm not alone here, in that regard).
I'll be following it with much anticipation, and obviously hoping for your complete success. I do have a couple of generic questions that would help me better-understand the methods you intend to use, as well as your end-goal, based on my own very-limited-understanding of the sequences of operation, for this car:
WHEN you've successfully reverse-engineered the Gateway and have determined the binary frames/packets/ & commands required to be sent over a given network (BEAN/CAN/AV) for certain functions (such as rolling down the QTR windows/etc) --- will this be accomplished :
-----via capturing those network commands on a working car (?), (assuming Toyota hasn't and won't published this info); and
AFTER you have the command set: Are you and then planning to add in a new ECU on the network (via Arduino/Ras-PI/Etc) to be able to duplicate those serial commands ?
And what do you envision seeing as the Final user-input-device that would communicate with the new ECU ? Laptop/New-Switch-bank/Smartphone over BT/Wifi/All-of-the-above?
FWIW: I'm willing to assist you in your efforts, if you think of something you need and don't have, such as documentation/washing-your-car-while-u-work/etc, --- as your stated goal is a definitely worthwhile project.
...and one final technical question:
Based on the knowledge of this car's network that you've amassed thus far, do you think there could be anything stored in any of the the existing ECUs' firmware, that might cause it to reject a command from a new ECU (that has a new ECU-Address) --- when it would normally accept that command from an existing ECU with a known address?
i.e. Does the info in the Frame-packet need to match the original command "completely", or does the "controlled" ECU simply ignore the source of the command ?
Thanks
I checked the Blog but didn't see how to say Hi there. LOL. ...but wanted to let you know I really appreciate your efforts (...and I'm sure I'm not alone here, in that regard).
I'll be following it with much anticipation, and obviously hoping for your complete success. I do have a couple of generic questions that would help me better-understand the methods you intend to use, as well as your end-goal, based on my own very-limited-understanding of the sequences of operation, for this car:
WHEN you've successfully reverse-engineered the Gateway and have determined the binary frames/packets/ & commands required to be sent over a given network (BEAN/CAN/AV) for certain functions (such as rolling down the QTR windows/etc) --- will this be accomplished :
-----via capturing those network commands on a working car (?), (assuming Toyota hasn't and won't published this info); and
AFTER you have the command set: Are you and then planning to add in a new ECU on the network (via Arduino/Ras-PI/Etc) to be able to duplicate those serial commands ?
And what do you envision seeing as the Final user-input-device that would communicate with the new ECU ? Laptop/New-Switch-bank/Smartphone over BT/Wifi/All-of-the-above?
FWIW: I'm willing to assist you in your efforts, if you think of something you need and don't have, such as documentation/washing-your-car-while-u-work/etc, --- as your stated goal is a definitely worthwhile project.
...and one final technical question:
Based on the knowledge of this car's network that you've amassed thus far, do you think there could be anything stored in any of the the existing ECUs' firmware, that might cause it to reject a command from a new ECU (that has a new ECU-Address) --- when it would normally accept that command from an existing ECU with a known address?
i.e. Does the info in the Frame-packet need to match the original command "completely", or does the "controlled" ECU simply ignore the source of the command ?
Thanks
1. A generic Dealer Option "ECU" that can be programmed to do pretty much whatever you want (within the vehicle's capabilities.) This generic ECU would then also be able to communicate with other generic ECUs to expand features even further. If I can pull it off (my programming sucks), I will try to come up with a simple application that allows you to customize the ECU without a bunch of technical knowledge.
2. Replicate the LuxLink with a much easier install.
3. USB interface to the bus that allows a computer to snag and send packets to react to events with more complex software.
As for whether or not it will accept a foreign ECU... as far as I have gathered so far, there is no real security present. The BEAN bus was designed to run on slow 8-bit microcontrollers in 1992. The gateway will check to make sure that the packet is valid and not malformed using a CRC. But the BEAN was specifically designed to add "Dealer Options" (aftermarket ECUs) to the network.
I am working on a pretty detailed paper right now which I hope will allow even a layman to have a basic understanding of it all works with enough detail for hardware/software guys to whet their whistles as well. I need it for my own clarity as much as anyone. The information right now is in various bits all over the place.
My methodology will employ several tricks. I am reverse engineering the Techstream software to learn what I can, building up a sniffer to listen in on the bus in a healthy car, and putting together a test-bench which will allow me to reduce the overall traffic so I can zero in on commands.
There will also be some attempts to dump the firmware from the different ECUs. This would be the holy grail as it should reveal all commands as well as opening up the possibility of upgrading firmware to add features.
Basically, I will be using every tool at my disposal. This is really the core of the system I had envisioned installing. There are harder ways to do it such as running wires all over the hacking into switches, adding relays, etc... but if I could simply plug something into just one connector and take control...
Last edited by Retroplay; 02-23-16 at 01:20 PM.
Trending Topics
#8
Lead Lap
Thread Starter
A little preview of the mother of all papers I am working on:
There are three separate BEAN buses in the SC430. This is to reduce traffic congestion. The critical components are all on one bus. Each ECU can just directly talk to each other, or they can bridge over to another bus using the gateway.
Some more examples would be how the the transponder and theft ECU can jump over and command the tilt/telescopic steering wheel to activate when the key is in the ignition. Or how the theft ECU can jump over to the MPL bus and tell the lights to blink when you lock/unlock the doors. The mayday controller can monitor the airbag ECU on the MPI bus to trigger on the crash sensors, etc.
This would make it possible, for example, to have virtual dashboards, OBD diagnostics, and control over various functions directly from the built in multidisplay (if it had the software to do it.)
I was pretty thorough looking through several documents trying to identify all of the ECUs, but it is possible that some are missing, to be discovered later.
The MPI bus is the Instrument Panel Bus, MPD is the Door bus, and MPL appears to be majority lighting control. The door bus does most of the really fun stuff.
There are three separate BEAN buses in the SC430. This is to reduce traffic congestion. The critical components are all on one bus. Each ECU can just directly talk to each other, or they can bridge over to another bus using the gateway.
Some more examples would be how the the transponder and theft ECU can jump over and command the tilt/telescopic steering wheel to activate when the key is in the ignition. Or how the theft ECU can jump over to the MPL bus and tell the lights to blink when you lock/unlock the doors. The mayday controller can monitor the airbag ECU on the MPI bus to trigger on the crash sensors, etc.
This would make it possible, for example, to have virtual dashboards, OBD diagnostics, and control over various functions directly from the built in multidisplay (if it had the software to do it.)
I was pretty thorough looking through several documents trying to identify all of the ECUs, but it is possible that some are missing, to be discovered later.
The MPI bus is the Instrument Panel Bus, MPD is the Door bus, and MPL appears to be majority lighting control. The door bus does most of the really fun stuff.
Last edited by Retroplay; 02-23-16 at 01:17 PM.
#9
Lead Lap
Thread Starter
I'll do my best. My interest hasn't waned yet, so hopefully that propels me to the finish line. My biggest problem right now is too many different project ideas and not always easy to focus on just one. I am expecting the blog will help with that by allowing me to switch around fleshing out the various mods as I go.
I am not expecting it to cover just one project, but all of them including performance mods, aesthetic mods, LED conversions, etc...
#10
Pit Crew
Another follower here. Great project.
#11
Great questions. My end goal is to design a few things, actually.
1. A generic Dealer Option "ECU" that can be programmed to do pretty much whatever you want (within the vehicle's capabilities.) This generic ECU would then also be able to communicate with other generic ECUs to expand features even further. If I can pull it off (my programming sucks), I will try to come up with a simple application that allows you to customize the ECU without a bunch of technical knowledge.
2. Replicate the LuxLink with a much easier install.
3. USB interface to the bus that allows a computer to snag and send packets to react to events with more complex software.
As for whether or not it will accept a foreign ECU... as far as I have gathered so far, there is no real security present. The BEAN bus was designed to run on slow 8-bit microcontrollers in 1992. The gateway will check to make sure that the packet is valid and not malformed using a CRC. But the BEAN was specifically designed to add "Dealer Options" (aftermarket ECUs) to the network.
I am working on a pretty detailed paper right now which I hope will allow even a layman to have a basic understanding of it all works with enough detail for hardware/software guys to whet their whistles as well. I need it for my own clarity as much as anyone. The information right now is in various bits all over the place.
My methodology will employ several tricks. I am reverse engineering the Techstream software to learn what I can, building up a sniffer to listen in on the bus in a healthy car, and putting together a test-bench which will allow me to reduce the overall traffic so I can zero in on commands.
There will also be some attempts to dump the firmware from the different ECUs. This would be the holy grail as it should reveal all commands as well as opening up the possibility of upgrading firmware to add features.
Basically, I will be using every tool at my disposal. This is really the core of the system I had envisioned installing. There are harder ways to do it such as running wires all over the hacking into switches, adding relays, etc... but if I could simply plug something into just one connector and take control...
1. A generic Dealer Option "ECU" that can be programmed to do pretty much whatever you want (within the vehicle's capabilities.) This generic ECU would then also be able to communicate with other generic ECUs to expand features even further. If I can pull it off (my programming sucks), I will try to come up with a simple application that allows you to customize the ECU without a bunch of technical knowledge.
2. Replicate the LuxLink with a much easier install.
3. USB interface to the bus that allows a computer to snag and send packets to react to events with more complex software.
As for whether or not it will accept a foreign ECU... as far as I have gathered so far, there is no real security present. The BEAN bus was designed to run on slow 8-bit microcontrollers in 1992. The gateway will check to make sure that the packet is valid and not malformed using a CRC. But the BEAN was specifically designed to add "Dealer Options" (aftermarket ECUs) to the network.
I am working on a pretty detailed paper right now which I hope will allow even a layman to have a basic understanding of it all works with enough detail for hardware/software guys to whet their whistles as well. I need it for my own clarity as much as anyone. The information right now is in various bits all over the place.
My methodology will employ several tricks. I am reverse engineering the Techstream software to learn what I can, building up a sniffer to listen in on the bus in a healthy car, and putting together a test-bench which will allow me to reduce the overall traffic so I can zero in on commands.
There will also be some attempts to dump the firmware from the different ECUs. This would be the holy grail as it should reveal all commands as well as opening up the possibility of upgrading firmware to add features.
Basically, I will be using every tool at my disposal. This is really the core of the system I had envisioned installing. There are harder ways to do it such as running wires all over the hacking into switches, adding relays, etc... but if I could simply plug something into just one connector and take control...
So if I read that correctly, your "human-interface" would be the Nav Touchscreen (and/or wireless mouse/touchpad)? ----- using the USB interface to the car's network ---- to allow you to call up, for example, ---- a custom screen from the Car-PC onto the nav screen,---and use the touch interface to lower windows/drop the top/whatever? Is that the gist?
Similar to how we utilize Crestron touch panels with customized screens, --- to control components in some of the higher-end-AV-Systems, we design.
If so, I like that interface better than, say, using a smartphone connected to a WIFI OBDII to send the commands, --- although I'm sure that WHEN you get the first part working, adding smartphone-control to the mix would be a walk in the park.
Keep up the outstanding work. Let me know if I can help.
Nic
_____________________________
2007 SC430
Starfire Pearl/Ecru
Vais SLX w/XM;
NavTool 3.0-HDMI for AppleTV,
BU Camera & BlindSpot Cam.
#12
Lead Lap
Thread Starter
TarheelNic, the reason I am listing 3 possibilities is that I have a vision for my own vehicle, but I also have a vision for a product for others that want to stay mostly stock.
In mine, the OEM nav system will be replaced. But, I don't expect everyone to be able to or even want to go as extensive as I am planning.
The main point is the generic ECU concept. Once I establish that, there can be numerous iterations of the concept, as you noted. The only difference between them is whether it is standalone, or upstream computer controlled.
If you reduce down all of the ideas I have presented over the last couple of months, the ECU is the core of all of them.
The main problem with putting a carPC in a car is figuring out why you need one, honestly. Many do it just to play MP3s and lose interest quickly because there are many systems that do that already. For me, I would only do it if it adds convenience features for me. And to do that, it needs full integration into the car.
In short - what I have done is reduced all my various ideas down to this one key part, the ECU, and have zoomed in on it. Once we have that, all sorts of different ideas are possible.
In mine, the OEM nav system will be replaced. But, I don't expect everyone to be able to or even want to go as extensive as I am planning.
The main point is the generic ECU concept. Once I establish that, there can be numerous iterations of the concept, as you noted. The only difference between them is whether it is standalone, or upstream computer controlled.
If you reduce down all of the ideas I have presented over the last couple of months, the ECU is the core of all of them.
The main problem with putting a carPC in a car is figuring out why you need one, honestly. Many do it just to play MP3s and lose interest quickly because there are many systems that do that already. For me, I would only do it if it adds convenience features for me. And to do that, it needs full integration into the car.
In short - what I have done is reduced all my various ideas down to this one key part, the ECU, and have zoomed in on it. Once we have that, all sorts of different ideas are possible.
#13
Retro,
I stumbled across something today that may be of some interest to you. A Kickstarter project called CAN-Bus Triple apparently created a product that can be connected to a car's network to read and send controls (via arduino), and it has apparently reached fruition. Thought you might be interested. Looks like they sell them for $79.
https://canb.us
_____________________________
2007 SC430
Starfire Pearl/Ecru
Vais SLX w/XM;
NavTool 3.0-HDMI for AppleTV,
BU Camera & BlindSpot Cam.
I stumbled across something today that may be of some interest to you. A Kickstarter project called CAN-Bus Triple apparently created a product that can be connected to a car's network to read and send controls (via arduino), and it has apparently reached fruition. Thought you might be interested. Looks like they sell them for $79.
https://canb.us
_____________________________
2007 SC430
Starfire Pearl/Ecru
Vais SLX w/XM;
NavTool 3.0-HDMI for AppleTV,
BU Camera & BlindSpot Cam.
#14
Lead Lap
Thread Starter
Retro,
I stumbled across something today that may be of some interest to you. A Kickstarter project called CAN-Bus Triple apparently created a product that can be connected to a car's network to read and send controls (via arduino), and it has apparently reached fruition. Thought you might be interested. Looks like they sell them for $79.
https://canb.us
I stumbled across something today that may be of some interest to you. A Kickstarter project called CAN-Bus Triple apparently created a product that can be connected to a car's network to read and send controls (via arduino), and it has apparently reached fruition. Thought you might be interested. Looks like they sell them for $79.
https://canb.us
These earlier models use only BEAN, AVC-LAN, and ISO 9141
So not only am I trying to reverse engineer all the commands, I need to reverse engineer a not-so-well documented network protocol as well.
#15
Lead Lap
Thread Starter
Yes, I am still around and still working on this. I will be posting a couple more articles to the blog in the next couple of weeks. My time was becoming limited again and I figured it was better used focusing on the project than frequent posts.
I am working with another member here with better experience in software, so things should start moving quickly now.
Here's a teaser for any other geeks in the room:
A single BEAN network frame
I've been gathering hopefully enough information that I can decipher that and then we write some code to start reading the messages and monitoring it inside the car to sort out what the various ECU addresses are and what commands are available. The holy grail will be telling the quarter windows to roll down/up with just a single wire.
I'll come back and let you all know when new posts are up on the blog.
I am working with another member here with better experience in software, so things should start moving quickly now.
Here's a teaser for any other geeks in the room:
A single BEAN network frame
I've been gathering hopefully enough information that I can decipher that and then we write some code to start reading the messages and monitoring it inside the car to sort out what the various ECU addresses are and what commands are available. The holy grail will be telling the quarter windows to roll down/up with just a single wire.
I'll come back and let you all know when new posts are up on the blog.