Development of DIY Electronic Upgrades

So, did you do this with an aftermarket remote start or the seemingly built in one from Toyota (click sequence using the factory key fob)?

The ECU probably did not like the fact that the vehicle was started and the jamb switch was triggered. I can easily see the ECU being in an "invalid state" with such a sequence.

So basically when you do a remote start, the vehicle is in like an idle state - doors closed, vehicle OFF. Therefore, the next action the ECU expects is that the door gets opened, THEN the vehicle started, not the other way around like your case. This is how they easily slip the "second start" thing into the ECU code - they simply have to check if the vehicle is started when the user opens the door, and if it is, shut the vehicle off.

From a firmware engineering standpoint, I bet you anything that the whole part of the firmware that shuts the vehicle down when the door opens is actually an initialization routine. Basically "make sure everything (engine) is OFF and initialize all variables to 0 when a door opens". This routine most likely runs every time your door opens, but you as the user obviously can't see that. So.. it happens by chance that we get this nasty side effect from our after market remote starts.

Keep in mind that the ECU / BCM is in tight control of the entire state machine. So it knows when the driver side, passenger side, or both doors is open and also if the engine is running or not. There would be a giant state machine describing this, for example to keep the engine running once its already started after a passenger opens the door. Inserting "turn off engine" into one of these states under certain conditions is not that far'fetched of an idea (and extremely easy too!).

(Above speculation at this point)

 

After market starter kit.
My thinking was that if I could keep that door jamb switch in a closed circuit and enter the truck without it shutting off (no dome lights)
and then ???? Not sure.

Of course the alarm should not trigger since the circuit will remain closed all that time utilizing the toggle switch.

I might try my idea with a switch this spring.

 

Yes, but in your sequence, you stated the alarm went off 'after' you released the switch. The sequence was you pressed the door jamb switch, remote started, let the switch go, and the alarm sounded. This is easy to track in a state machine and the ECU found you were in an invalid state and thus sounded the alarm.

Here's the other thing. I believe there are some other posts out there that detail the exact thing you want to do; however, there can be draw backs. The first, like you mentioned is the dome lights. The second is that your vehicle will still be in an invalid state when you try to drive it. Remember vehicle expects: jamb switch, THEN engine started, not engine started, THEN jamb switch. It's quite possible that the vehicle flags this condition when you go and press the brake pedal or try to shift into gear. The overall issue is that the remote start system has no way of 'notifying' the ECU that it was a valid start, because Toyota does not expose an authorized method of doing that (otherwise we wouldn't be in this discussion). Therefore, to the ECU, its sitting there fat dumb and stupid and can only rely on the state machine with the sensors it does have.

Lastly, the other major issue is that most remote start systems are programmed with a time limit (for obvious reasons). After that time limit, your engine would shut down.. even on the road (again ECU doesn't know what the remote start is doing). The time limit is there to prevent your vehicle from staying on, for example if you butt dialed, remote started by accident, and never knew your vehicle was on. If your vehicle stays on, the gas will slowly but eventually be depleted, etc. etc.. (enter other bad things here)

I honestly would not condone doing this, but if you are adventurous, you could just tape the switch down or something and see if the vehicle will let you drive around. But be advised... of the above issues. I wouldn't want to see injuries here.

 

You made a lot of valid points, my method is to experiment in steps. After gaining access to my running truck and sitting there trying to figure out a way to transfer the operation back to the truck without it shutting down.

I'm sure many others have tried this unsuccessfully though. But I'm kind of a mechanical madman and will try anything twice.

There has to be a way around it.

 

Question:

When you remote started with the jamb sensor pressed as in the first post, was your vehicle key fob in range?

Nextly,
I am not really sure if this has been tested before.. but try this:

1. Bring your key fob and remote starter into the vehicle and start the vehicle normally (shut door, brake pedal, PTS)
2. Shut down the vehicle normally (PTS). Keep the doors closed
3. Remote start the vehicle
4. Once the vehicle starts, open the door.

What happens?

 

Go for it. I buy just about everything and your starter and head unit ideas would be two I wish were available today. I love it when people try to improve an already great product.

 

I think I read somewhere that after a Toyota is remotely started, it will also shut off if it is put into drive. Presumably this is to keep it from being stolen when it is remotely started. Even if you break the window and crawl in, you can't drive away in it.

What you could do, is buy or build something to plug into the phone to ping the key fob and pick up the signal it responds with. Then have a cell in the truck to rebroadcast the fob's signal. Think of it like the key fob retransmitters the thieves use, except you're using phones to retransmit it over any distance. All you need is that plus a simulated push to the start button. As far as the truck knows, the key fob is in the truck, and you pushed the button.

The problem with this, is that the vehicle could be stolen very easily while running in this mode, but this can be dealt with.

I think this approach would be more likely to succeed.

BTW, I'm an embedded SW engineer too.

 

ksJoe:
So let me test my understanding here. Let's assume we are in the ECU "master" case.

When the user initiates a normal start sequence, its all mechanical switches. So the user presses unlock on the handle, door opens, brake pedal, PTS. At each stage the ECU 'pings' the fob normally to see if its there. What you are suggesting is that you have an LTE modem in the car that intercepts the ping request, re transmits this over cell data (for example) to a second phone. The second phone pings the actual fob and then intercepts its response. The second phone then transmits the response back to the first using cell data and then broadcasts back to the ECU.

I will admit that might have a better chance of working than reverse engineering the comms; however, there are two issues

1. Speed. I have no idea what the speed of this would be, and I can almost guarantee there is an ECU request timeout. When the fob gets pinged normally, its through RF and is extremely speedy (low latency). Cell data could be very fast but high latency. Its possible the transaction won't complete in time.
2. RF - I can foresee there maybe being RF issues like being able to intercept the signals and re transmitting reliably. I will admit, I don't have tons of experience in the RF realm. This is why I suggested a comm reverse engineering approach, because the RF transactions are more directed and would be much more reliable out of the gate. Only one transmission (SMS) from a phone to the module inside the vehicle to an LTE modem.

With regards to security, the method I posited is more secure, because I would be able to ping the fob electronically any time I wanted, since I would be in control of the communication between the immobilizer and ECU. Therefore, I just tap into the same signals as the ECU such as the brake pedal and gear indicators. When the car is being shifted out of park, I can ping the fob and flag it if I need to.

With your method, there is no real way to ping the fob on demand, because we are relying on the ECU itself to indirectly send ping requests when the car is put into the correct state by spoofing the signals and the PTS switch is press spoofed.

 

I don't think that's correct. I believe Toyotas shutoff when the door is opened. I believe if you were able to get in to the truck without opening the door, you would be able to drive-off. There was just another thread on here that someone tested this, I believe they remote started their truck while they were in it, left their key at home, and was able to go for a drive.

 

The button camera overide is already done too.

 

Interesting. That is a surprising security issue. Any time you see a Toyota warming up, break the window and its yours. It can (and should) be safter than leaving a car warming up with an old fashioned key in it.

 

calecbc:
Yes I thought that was the case too. I read around and heard that the "dumb" reason they used the jamb switch for the shutoff was because they had no signal to tap into for a gear indication (it didn't exist in the Toyota to save money). However, I also learned the transmission is electronic....... so...... not sure.. maybe its a 'relative' electronic system where they only know if the transmission is in one particular gear. We know there is a reverse / 'not' reverse signal on the head unit for the rear camera. What I mean by 'relative' electronic system is that it could work like a relative encoder. The encoder doesn't know its position, therefore needs a starting reference and can only detect UP / DOWN by 1. So in order to go from park to neutral, it would be several steps, but you need to go through everything in between.

Cudgel:
I referenced this in my OP. If I make a head unit, I would want this functionality to be integrated electronically into the graphics display. There would not necessarily be a dedicated button like the system that can be found in the forums. You would be able to get the rear camera display through opening that app on a touch screen or whatever.

ksJoe:
You would not need to ping the fob on demand just for a remote start, no. I am saying that if you wanted the added security, then yes, I would need to ping it on demand. If I "takeover" the car by using one of our sequences, the car is now ours. I can press on the brake and the ECU doesn't need to determine if the fob is there. However, if I remote start... its possible the fob has NEVER been in range. Therefore, on the first gear switch / brake depress, I need to ping the fob to see if it's there (on demand)

Imagine the exact case you detailed. The car is not secure, because it has been remote started and taken over by your system. Therefore, anybody can just run up - smash the window and drive away.

If we want the security after the takeover, we have to do it ourselves by pinging on demand.

 

@LostTime77

Latency would be an issue if you were on the other side of the world, but typical ip network latencies are low ms if you're within hundreds of miles. I'd be surprised if it was an issue within a few hundred miles.

I was thinking: As you start up your ap, it turns on the bi-directional fob range extender. I assume the car is occasionally pinging to wake up nearby fobs (I've heard storing fobs near the car can run down the fob battery faster). So once the app enables the bidirectional range extender, the next ping from the car will wake the fob and you're good to go.

For security, make sure the cell module you get for the vehicle has gps, and have the app tell the car where the phone is. If the door opens, or it is put in gear with the gps locations more than a few feet apart, kill it and blast the horn.

 

So here's another idea. What if the ECU is pinging the fob every time its put into gear or there is an action taken? What if it's doing it occasionally to make sure the fob is there (every minute)?

If this is the case, security is not an issue, because the ECU will do the work for us.

Imagine the scenario where I put the car in a gear other than park and it just so happens to stay in place (level ground). Then I leave the vehicle with my fob and a wild thief appears! They could steal the vehicle and run. I really wonder if the vehicle is pinging every so often.

I think we should actually do the experiment to gather more data on the subject to see if we can understand what it is doing better so we can design a proper system without overwork. The security aspect to me is not a huge deal, because I think we can solve it with methods that are on par or better than what Toyota currently implements.

Testing this would not be a huge deal.. we can just implement your system and see the periodic data transfers.

 

On my IS350 (also a Toyota product), I can get out of the car while its running, and it starts beeping. It keeps running, and it will drive just fine. But it beeps the whole time to warn you that the key fob is gone. I assume this is to warn you if your passenger had your keys and you let them out. You'd want to know you can't restart it if you shut it off.

So clearly on the IS350, the car is periodically pinging the fob.

I won't have my taco for a couple weeks, so I can't test if the taco is the same.

 

So as a reseller of remote starts I sell on here I have tried to bypass the Tacoma system. What is interesting when using the evo all on my wife’s Mazda CX-9 pts it shuts down on door open. If I use the evo one then I have pts takeover. It’s two different harnesses and modules for the the same car. My guess there has to be a wire to allow takeover, just haven’t looked into it enough. The pts tacoma takes the evo all and the hkey takes evo one.

Even if you bypass the door pin, as soon as you hit the brake the vehicle will shut off, with or without the keyfob in vehicle and hitting the pts doesn’t do anything.

 

@jmeitz

Yes, I think I detailed why I think this is the case with the door pin shutting the vehicle off in the previous posts.

Here is the difference between COTS remote starts and my idea. My idea is that I want to go through the "human" process of starting the vehicle, which the COTS system do not seem to do. The COTS systems seem to just try and brute force start the vehicle on command.

What I want to do is spoof the signals leading up to a normal start sequence. Therefore we spoof the door opening, the brake being depressed, and the PTS being pressed. Therefore it would be just like a human did a normal start on the vehicle. If we have access to the mechanical switches to the various sensors (door jamb sensor, brake sensor, PTS switch), spoofing the signals is very easy.

Using my method, the vehicle would have no clue if it was started by a human normally or not. Add to this @ksJoe 's idea of the retransmitter system and that can get us by the immobilizer and key fob issues.

@ksJoe

Interesting. Unfortunately, I am going to need help in the field testing department. I live in an apartment complex right now where I am not allowed to work on my vehicle and or make noise with it. I will have to save my own field tests for dedicated time slots that I plan, such as visiting my family.

I think we can at the very least test the re transmitter theory very easily. For example, just testing if we can lock / unlock the doors at a long range where the fob is not there.

 

OP, you said "embedded software" and I got...excited . I'm not qualified aside from an education and self-taught/driven secondary job application. But I do program and love that. A kickass head unit is a pipe dream of mine. A sort of one-stop-shop. Something for which I can write my own programs, design my own GUIs, and add/remove/tweak features as I see fit, coupled with hardware solutions (something like an spod or switch pro). Also CANBUS.

A lot of these "wheels" have already been invented but I don't like the way they look or the fact that I can't change them to a triangle if I really wanted to.

I'm curious to see what you come up with. Number of forum posts != experience or ability to bring something to the fight.

 

Yeah, for the head unit I was thinking of just slapping a desktop class system in there and putting windows 10 on it. Apparently you can run it in a special kiosk mode. I need to research it more. However, doing it this way, you get the power of the windows OS and programming however the hell you want - C / C++, Python, .NET (what I would be using). Think of kiosk mode like running a program that takes over the entire OS so you have full control of the UI and doing whatever you want on the low level.

You would have the desktop class system connected up to one or more serial converters which can then be connected to microcontrollers to do the low level GPIO control for stuff like HVAC interfacing, USB C cabling, power delivery, etc..

The other option is to use an Android class system like raspberry pi; however, I am a windows guy at heart. I have developed with Android / Linux systems in the past and windows "just works". Yes, it will consume more power than the pi, but considering we are connected to a vehicle with an abundance of power, it probably is not a huge issue.

The head unit idea is complete WIP and needs much more thinking. My biggest issue is that I want 'good' GPS integration inside with turn by turn nav audio connected to the car audio. This is not a simple thing to accomplish, because all of the GPS systems out there (Garmin, Waze, etc..) do not provide an easy way to mute background audio channels (music) when a nav alert occurs.

I was thinking that an OBD diagnostics program could be made for the head unit since it is connected to the CAN bus in the wiring. This way you could read codes or whatever without needing to connect to the separate OBD port under the steering wheel.

I don't think I would go as far as to make plug in modules. However, the plans and schematics would be available for you to easily tinker with what you wanted. If I did sell anything, I would charge for the price of the hardware and also a fee on top of that for the "development" work. You would then of course have access to modify anything else you wanted to by yourself.

Remote start is the priority right now.

 

Windows 10 is more robust than a Pi, but a Pi seems more versatile across the spectrum of OS choice and hardware ability (based on my totally professional research). Either way, programs can be made. OBD via HU wiring instead of filling the actual port would be ideal with the goal to have an API to use and display info. For hardware plug-ins, what I'm after is a switch & relay system for devices and connections for multiple cameras with potential for recording.

Hopefully your remote start pursuit bears fruit so we can eliminate a huge first-world problem and various threads borne from a lack of searching.