SC430 - 2nd Gen (2001-2010)

I've started a Blog

Thread Tools
 
Search this Thread
 
Old 02-22-16, 03:07 PM
  #1  
Retroplay
Lead Lap
Thread Starter
 
Retroplay's Avatar
 
Join Date: Aug 2015
Location: Florida
Posts: 769
Received 79 Likes on 55 Posts
Default 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/
Old 02-22-16, 10:12 PM
  #2  
texsexlex
Racer
iTrader: (3)
 
texsexlex's Avatar
 
Join Date: Jan 2009
Location: texas
Posts: 1,712
Received 111 Likes on 96 Posts
Default

...they are very interesting,although i don't understand them all...lol
Old 02-23-16, 09:33 AM
  #3  
2ksoftail
Pit Crew
 
2ksoftail's Avatar
 
Join Date: Feb 2012
Location: NC
Posts: 148
Received 38 Likes on 17 Posts
Default

I will follow, you are far more knowledgeable than me on our little cars and I'm looking forward to learning.THANKS
Old 02-23-16, 10:18 AM
  #4  
JohnnyCake
Racer
 
JohnnyCake's Avatar
 
Join Date: Feb 2007
Location: DC
Posts: 1,637
Received 51 Likes on 38 Posts
Default

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.
Old 02-23-16, 10:19 AM
  #5  
TarheelNic
Rookie
 
TarheelNic's Avatar
 
Join Date: Jan 2016
Location: SC
Posts: 61
Likes: 0
Received 2 Likes on 2 Posts
Default

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.
Old 02-23-16, 10:41 AM
  #6  
mrblister
Pole Position
 
mrblister's Avatar
 
Join Date: Nov 2007
Location: Pa
Posts: 2,624
Received 64 Likes on 56 Posts
Default

Iam down with your blog and await seeing
Old 02-23-16, 01:00 PM
  #7  
Retroplay
Lead Lap
Thread Starter
 
Retroplay's Avatar
 
Join Date: Aug 2015
Location: Florida
Posts: 769
Received 79 Likes on 55 Posts
Default

Originally Posted by TarheelNic
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
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...

Last edited by Retroplay; 02-23-16 at 01:20 PM.
Old 02-23-16, 01:08 PM
  #8  
Retroplay
Lead Lap
Thread Starter
 
Retroplay's Avatar
 
Join Date: Aug 2015
Location: Florida
Posts: 769
Received 79 Likes on 55 Posts
Default

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.

Last edited by Retroplay; 02-23-16 at 01:17 PM.
Old 02-23-16, 01:25 PM
  #9  
Retroplay
Lead Lap
Thread Starter
 
Retroplay's Avatar
 
Join Date: Aug 2015
Location: Florida
Posts: 769
Received 79 Likes on 55 Posts
Default

Originally Posted by JohnnyCake
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.

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...
Old 02-23-16, 02:29 PM
  #10  
Neil E
Pit Crew
 
Neil E's Avatar
 
Join Date: Apr 2008
Location: W.Sussex UK
Posts: 171
Received 81 Likes on 44 Posts
Default

Another follower here. Great project.
Old 02-23-16, 04:16 PM
  #11  
TarheelNic
Rookie
 
TarheelNic's Avatar
 
Join Date: Jan 2016
Location: SC
Posts: 61
Likes: 0
Received 2 Likes on 2 Posts
Default

Originally Posted by Retroplay
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...
Retro,

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.
Old 02-23-16, 09:35 PM
  #12  
Retroplay
Lead Lap
Thread Starter
 
Retroplay's Avatar
 
Join Date: Aug 2015
Location: Florida
Posts: 769
Received 79 Likes on 55 Posts
Default

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.
Old 02-27-16, 07:43 PM
  #13  
TarheelNic
Rookie
 
TarheelNic's Avatar
 
Join Date: Jan 2016
Location: SC
Posts: 61
Likes: 0
Received 2 Likes on 2 Posts
Default

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.
Old 02-27-16, 08:02 PM
  #14  
Retroplay
Lead Lap
Thread Starter
 
Retroplay's Avatar
 
Join Date: Aug 2015
Location: Florida
Posts: 769
Received 79 Likes on 55 Posts
Default

Originally Posted by TarheelNic
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
Unfortunately CAN bus isn't used in the SC430 prior to 2005 (I think). However, your 2007 does have it. Having CAN bus access would make things infinitely easier.

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.
Old 04-13-16, 03:03 PM
  #15  
Retroplay
Lead Lap
Thread Starter
 
Retroplay's Avatar
 
Join Date: Aug 2015
Location: Florida
Posts: 769
Received 79 Likes on 55 Posts
Default

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.


Quick Reply: I've started a Blog



All times are GMT -7. The time now is 11:18 PM.