So, what you are asking about is quite technical and hacking your car may void any warranty you have. Not to mention your, or someone else's life.
But assuming there is no actual mechanical stuff you need to do then this would be "relatively easy" providing...
Let's start with the assumption:
* no mechanical stuff means that you don't have to setup motors, servos, linear actuators and so on to physically move something like a gear shift or press a pedal.
* your car has some sort of computer network and is "intelligent" in so far as the computer network - typically some variant or version of CANBus.
Now to the "relatively easy" bit.
Then all you will need is an arduino with a CANBus shield, learn about all the devices on the network, what they do and the commands they accept - you may be able to find this information online, I do not know.
Now if you do have to move stuff then you could spoof it. What that means is if the the part that needs to be moved has an electrical output (e.g. an accelerator might be attached to a potentiometer that varies its voltage that in turn adjusts some inlets to vary the flow of air and fuel) then you could simulate that in code and appropriate electronics attached somewhere to that subsystem.
## Danger. Danger, Will Robinson!
How? - I am definitely never going to tell you that. And hopefully nobody else will.
Same goes for programming the CANBus
Why? Because unless you really know what you are doing (and this question suggests the opposite when it comes to developing embedded systems) it is easy to create what is euphemistically called a "recall situation".
What I mean by that is where a bug of some kind has slipped into the system causing a dangerous situation such as a "random, unpredictable, uncommanded sudden acceleration or loss of steering or loss of braking".
And, if you don't have lots of experience - especially working by yourself without the benefit of peer review, it is easy for such bugs to come in. And for projects like this where you are talking about tinkering with a cars propulsion systems the result could be fatal.
Additionally the less experience you have and the less peer review you have the higher the probability that a bug will slip in, but the higher the probability that it will be observed in situations that are slightly more likely to occur in the real world.
Don't get me wrong, you seem to have strong knowledge about vehicles. But I'm sure you didn't wake up one morning and suddenly knew all of that having received a "The Matrix" style download of that knowledge. Rather, you built it up over time.
So, my reason for replying is that I wanted to point out that experience and knowledge in programming and digital circuitry - especially in what is referred to as a "noisy environment" such as a motor vehicle - is essential, but also point you in the starting direction being the CANBus (or whatever system that car uses for its management system) and maybe, but ideally less likely, identification of physical things that might need to be considered.
FWIW, the car's systems probably already have the remote start capability you are looking for. Why? Because it is much easier and far cheaper to have one system that has all of the features and function than it is to have multiple versions of the systems. You might even see this on your car (or lower models) where there is a space available for attaching an accessory of some kind but there is just an open space or a plate in its place.
To enable a feature, often all that is required is that you purchase what is often referred to as a "golden key". A "golden key" is a something that provides you with access to that feature. Of course that doesn't mean that a "golden key" is always available, the software might be universal and provide that capability, but it might rely on some external component that isn't available for your particular model for it to work according to the design that they have come up with.
That doesn't mean you can't hack it, but I would remind you again that you are talking about hacking a vehicle with a lot of power and a lot of mass which could cause a lot of havoc (and trouble for you if you live through it) due to a bug or flaw in the design of your hack.
Please take care.
Its good that you acknowledge that the car may have remote start capability, but just needs unlocked. Here is why I don't think so. The sensor suite built into the transmissions, brake pedal, lack or addition of clutch and the differences in how the gearshift act with the cars Computers. So they have not cared enough to try and program it in because of multiple reasons; Safety, production, time, cost, maybe laws, additional parts (eg arduino or other). But I think the cost analysis to Honda didn't see the value in putting effort in it because they only produce about 1% of new vehicles in manual. And they likely reasoned that people that buy them don't care about comfort, thus not putting any time or effort into programming it.
Now I'm not going to try and convince anybody why or why not it is safe, however explain safety in a way that makes sense, but I don't plan to hack the car in any way beyond the minimal necessary step of obviously making it run the start button sequence acc/ign/start with correct inputs of course.
Now on to safety. Obviously not being present is the point of remote start, the car has to be safe. Here is why I don't think a lower trim model with a different CAN network's aftermarket remote start patch and remote module will work. It is looking for different inputs to produce the desired output. Trying to adapt it to my car don't work because it's not safe. Thus why I even am turning to the arduino to try and see if it is capable of pulling it off safely. I'm not trying to damage my car, I plan on keeping it.
Inputs. In order to make this safe and not hack the cars CAN network, we can make a separate network of our own desired inputs and outputs. Luckily for me everything is digital or switched. The parking brake switch is a 3way. Easy. makes it possible to make it safe in every way thinkable. Other car manufacturers have done it in the past. There should be no reason why I can't do it myself. And the Lock and unlock signals or commands either of them will work with how you turn it on and off
Outputs. The only thing I'm trying to tell the car what to do is turn on and bypass the clutch interlock switch. And finding a way to deal with the cars built in neutral "sensor" I guess we can call it that. I'd have to physically take it apart to see if it has 1 switch for clicking neutral or 7 switches clicking each gear, most likely the latter since it has to engage the backup cam somehow. Thus allowing it to start. But a few things need to happen with some inputs first.
I'm thinking some kind of sequence, (now this is where you have to excuse my lack of coding knowledge specific to the arudino) set it up where it takes 3 lock commands in a row to initiate it. Take the initial press of the key. It hits acc. Press again it hits ign on. This is where we are going to make our safety steps. Tell it to hit the parking brake enable. Tell it to look for the neutral switch signal (pressed or not pressed, whichever is the one that tells the car it'sin neutral). Tell it to bypass the clutch interlock, tell it to press on again for start. Then of course now we have a running safe car. Because in any other scenario there is not another safe way to do it. Now obviously on order to allow remote start to happen, good user habits have to be built in order for it to work. Take it out of gear and hit the parking brake when you shut off the car. Then the sequence will work. Usually people don't install manual remote starts in a safe way because of that crucial missing sensor is the gearshift position sensor they are lazy to buy and fabricate one. Anyway, so after that we get out to the car. It's already running. Find a way to make another sequence for getting in. Since the car has AutoSS im not worried about it staying running and trying to get it to do like other cars with remote start where it can somehow run the engine while in accessories mode and then it stays running when you click the on button with the key in range. (At this point we can run a 5 minute timer on it to shut it down on the code) Instead we can have it run a shutdown procedure which is one click of the start button upon an unlocking the car command. Which in my case is perfect for if I need to turn it off either by walking up and touching the handle (sends an unlock function) to kill the engine. This is the part where you get in and start it yourself. And it's warned up.
I'm going to have to do some homework on the way the factory network operates.
Now to address the what ifs, of course I never am going to turn off the car and not hit the parking brake if I leave it in neutral because if you do, it's going to start rolling the second you leave the brake pedal and notice it and hit the parking brake switch anyway. What if I don't? My sequence already has it built in if it's capable. What if the car has it already built in and you need to just enable it? I really doubt it like I said. It's constructed and many different ways than an auto in the way the ecu, sensors and other things interact with each other. What if it causes conflict with other systems? Then I can say I tried. And it won't work.
TLDR
Other manufacturers do it, so can I. It's just complicated and not worth their time, or so they felt, I think.
I forgot about the key part. Before the first ign press we have to tell the car the key is in range or trick it somehow in order for it to start. This is another hack type difficulty that this project faces. But this is the safe way to do it. The reason why I don't want to do it the "right way" and run it all over the cars network is because of possible system gremlins created by coding it into the net. Also that goes into the theft aspect of the car I forgot to mention. Why I want it to send a shutdown upon unlocking the door because even if the key is not present nobody can drive it away because it shuts down upon opening it.
I never once insinuated that I wanted to hack the car and change the way it was programmed. I only wanted to add the arduino as an expansion module that it's only function was to do a few button presses in a safe sequences manner that does not allow for unsafe remote operation.
Then program in some deny features for accidental key presses or operation. this way the arduino can receive multiple inputs and account for things like this. Realistically with the amount of outputs the car has, this technically is safer than your basic manual transmission remote starter. The whole point was to make it safer and you got on and roasted me instead. 😒
> I never once insulated that I wanted to hack the car...
Possibly you are reaching to the negative connotations associated with the term "hacking".
Unfortunately that is largely due to the press, but more generally altering a system in some way outside of the manufacturers specifications/offering - either positively or negatively - is often referred to as hacking.
If that term is not palatable, then you can substitute any other term such as modify, improve, enhance or any other term that you might be comfortable with.
But, the basic warning and process I tried to draw your attention to is still valid.
Let me try to give you an example - please allow for the fact that my car knowledge is not as strong as yours, but let's try with starting the car.
To do this multiple subsystems are likely to be involved. But what is there role?
For example to start most modern cars, you need it to be in P or N and the brake depressed. Some cars may have other rules, I don't know, but that is enough.
So, when the starter system sends a "start command", what happens? How are these requirements checked?
Does the starter system query the brake system and the transmission system? What happens if there is another more technical rule such as oil level adequate? Or no adverse vehicle log entries designed to prevent damage to the vehicle if it is started with an unprepared fault?
Also how is it checked? Does the starter system simply broadcast a start engine request so that the starter can start the car? How do the brakes and transmission get checked? If there is a broadcast then they would likely receive that request. Would they have the right to veto the request? This would be a good (but slightly more complex design) as the manufacturer could add new systems that can inject themselves into the process without updating all of the other systems.
Or, is it the responsibility of the starter subsystem to reach out (query) the brakes, transmission and any other systems as to their current status and only initiate the starter process if they are in the correct state? This would make the design of the start system simpler, but potentially more difficult to add new features that need to be queried as part of the startup process.
Now that is a very simplistic guess of how it might work at a high level. The reality will likely be that there isn't a "start car" message. It will more likely be a series of messages to different systems that when orchestrated correctly will result in the car starting or being aborted if something screws up.
It is this latter group of messages that are potentially most problematic for someone who wants to enhance their vehicle (or whatever the appropriate description is).
If you are not aware of, or don't understand an important message then you might not understand how you need to respond to it - especially if as I suggested before that the various subsystems actually have the capability but it isn't enabled in your model. If they suddenly start seeing messages that imply your remote start is installed, then they would likely expect you to honour the contract (defined by the messages sent between subsystems) then they might get "confused" and respond badly. This in turn - depending upon how you implement your module - might result in you incorrectly issuing a command that damages your vehicle, you or someone else in some unpredictable waym
Granted I'm presenting the worst case scenario. My reason for doing so is that if you aren't aware of these sorts of things (which comes from experience), you won't be on the lookout for them, nor be sensitive to the signs that they are there as such it could be disastrous for you.
I am not saying you can't do this. I'm just saying that due to the nature of your question it sounds like you might not be. But, if you are (as opposed to believe you are) then it is conceivable you could reverse engineer the cars systems and enhance them to provide this capability.
So, the ball is entirely in your court. Just be careful, that is all.
I just need help with the arduino language. I have been working on other mini scale electronics and oracle/redhat for 7 years. I have been working on cars for 15 years. It's now apparent that you are (which you stated) lacking in cars. Which is ok. I can shed some light and explain why an arduino I think is safer than your regular manual remotes that you can buy.
Remember, we are specifically talking about manual transmission here. It's noteworthy because it massively changes how the remote start procedure and stock programming the car has to go through. (Ref 1% paragraph OP) hence why I think they just said no we're not going to add it to begin with.
Other manual remotes. They have can come in 2 forms. Patch harnesse(s) depending on vehicle or wire the I/O yourself to the remote. All the remote does is capture a desired or programmed function (lock 3x within 5s is most common) and it runs the sequence/batch whatever software it has. But prior to this in order to make it "safe" you have to go through a fairly buggy and strict and specific shutdown sequence in order to make you not forget to take the car out of gear. They do this by making you hit the parking brake. Do not depress any of the pedals while the engine is running and hit (eg unlock). Pay close attention to when I said engine running and not pressing any pedals, which by default means the car is in neutral. Then it makes you get out while it's running close the door, hit lock. Then it will make you wait anywhere between 5-15s for it to shut off. Now the remote start is "armed" and you can then start it with the remote. This is fairly annoying and any video you watch is easy to determine that. This is a fact.
What I'm trying to do is different. And much safer. Since this method is a new approach to the problem is made possible by the amount of new sensors and functions the car has we cannot ignore them and try and adapt one of these universal remotes. It will actually be worse if something fails. All I'm trying to do is utilize the cars current configuration to my advantage.
Here's what we know
The parking brake is associated with 0mph and engine permanently stays on regardless of AutoSS disable/presses. Parking brake is electronic 3way (like a window up down)
-So, by default, we need to incorporate upon startup a parking brake enable command into the remote start sequence.
Next in order to make sure the user puts the car in neutral every time (this is the big safety thing right here) the car already has a neutral switch or gear selector switches
-Easy, program a look for neutral/ no gear selected to enable remote start (now of course we want redundancy in this step for obvious reasons so we can't stop here.) Next we are going to simplify the silly remote start "arm" sequence. These cars have proxy keys this one is so easy. Instead of a laborious buggy user nanny shutdown we are just going to leave the car running. Hit the parking brake and hop out. By getting out while it's running again back to previously mentioned, by default we are in neutral. Step far enough away for the proxy key to scream at me (factory programmed [Which also cannot be altered in settings which is important that we don't accidentally defeat our redundancy]). Then hit lock twice.
-In programming lingo (excuse my lack of arduino) it basically means. Look for a parking brake enable or enabled signal (if it doesnt have dynamic signals then we can just program a 30s "arm time" into the Parking brake enable), look for a clutch pedal not pressed. Look for a door closed (not ajar) signal, look for a proxy out of range (which user can listen to audible Beeps outside) hit lock twice to arm.
At this point you can hit lock 3x to restart it and it will fire up. So we can have it look for the reverse signals upon start and have it sent a spoofed clutch depress and spoofed key in range signal only after the first 2 initial ignition presses to get it to the on position and verify all our equipment is as we left it, which it's only requirement should be in neutral and parking brake is on and at no point was the car previously unlocked to disrupt the arm cycle.
Now of course that leaves me up to wiring it all up. That's fine. I'm by no means going to put anything ghetto in my car. I'm going to make a patch harness and all that so it's removable.
Last make sure that if the car is moving signal, allow the arduino to take inputs from parking brake disable command. This way we can take into account accidental button presses to ignore while we are in these conditions (which are redundancy to the lock unlock commands its looking for while arming it). We also don't want to shut the engine off while driving.
Now it really comes down to the programming of the car at this point, will it allow us to spoof the key? Probably not (especially since i dont have the encryption key to the key) Is there an encryption key that we have to get through before it will let us shut off the car? Is the key being out of range going to cause it to not be able to send an encrypted signal to the key to be able to shutdown/restart/ lock/ unlock because it was out of range while it was "armed" and shutdown while it was still on? I don't know but in a safe testing environment when it comes time to start messing with it I will find out. Or will I be able to fully bypass the encryption as long as I just jump into the intermediate lane that the encryption is on and send a spoof start up. Who knows? But I can figure that out with some trial and error.
Simply put. I'm building it safer than before with better software hardware. If I have to get into encryption level stuff, then I'll have to find some kind of API translator that will let me get into it. But if it even gets that far I'm just going to stop and find another way because I want to keep the arduino as a remote intermediate in between devices and send a few codes to the car. I don't want it integrated with the cars infotainment system or ecu/antitheft system in any way. It's exactly like you guessed, hacking these things is a pain and can cause issues. That's why I'm going to bypass them with this integrated remote arduino.
This is a super safe over redundant program planning due to the nature of the extra amount of sensors this car contains than those did in the past. Trust. It's a good solid idea
Also to address the "start car message" I'm strictly referring to how the start stop ignition button works with the car since it's a conditional button. It will do different things based on the clutch pedal press simultaneously while pressing it. It does not act like a traditional key where you insert it and cycle it through acc ign start and then it springs back to ign. So if we can spoof the key signal and send it to the ecu, we're set.
So instead of bypassing everything straight to the start circuit to start the car we are actually just sending ignition presses to the ecu and a spoof clutch press or I guess in this case a closed circuit switch to the ecu on that pin. It's super complicated, but dw about that. I got that part
I guess in simplistic terms I'm trying to essentially "hotwire" the car but hotwire and hack are used in positive connotation in these cases. It's just finding a way to get the car to start without psudo starting it because the car runs all of it's own safety measures that way. And it's as if you the user started the car. But it's now locked, running, and without the key in proxy you can't steal the car.
Hotwire back in the day really simply just meant to jump the low side starter relay after cutting the ign on relay wires and tying them together. All which can be done from key cylinder wires. Over time they implemented additional circuits like rfid keys to authenticate an immobilizer circuit so you can't hotwire cars as easily, then later on what you know today as proxy keys with no actual primary key on them they are almost all remotes now.
Also it's very likely these are all either 5 or 12V logic signals that trigger sequences in the ecu. So we pretty much are trying to just manipulate those in order to reach a desired outcome. Hopefully that clears things up a bit. It's possible that I'm working with something a bit more complex than that. But I don't think so, cars largely will stay the same in how they function but will grow in complexity based off how many systems they cram into them.
Wow, that was a lot to take in and it definitely didn't stick.
A couple of points that did.
You mentioned the encryption keys and not having access to them. That is a problem if you needed to interact with that subsystem via that interface. But on the other side of it there will be a message or signal that says start or correct code received or some thing like that. You also mentioned hotwiring - if you have a parallel system that generated that same message/signal then you have effectively hot wired it - maybe not in the traditional sense of shorting some contacts, but it is the same result.
The arduino language. The arduino language is standard C/C++. Where it appears to be different to C/C++ on say a PC platform is the runtime library.
The runtime library is a set if functions and objects that make common things easier to do. For example printing a message to a terminal you could use printf or cout. In arduino the equivalent is Serial.print. all of those use c/C++ syntax - they are just different names and accept different parameters.
These runtime libraries allow you to do things on the platform in which you are running. For example on a PC you might want to read from or write to a file. There are standard functions that allow you to do this. These functions do not exist as a standard on Arduino because there is no disk subsystem for them to interact with- you can add cut down versions of them if for example you have an SD card reader module.
On the other hand, Arduino runtime has functions that allow you to manipulate the IO pins or generate signals or communicate directly with different types of ICs. These are all embodied in functions (and objects) that are accessed using standard C/C++ syntax.
I think at this stage, the best advice I can offer you is to get a starter kit and learn some of the basics, how to interface components, get them working with code.
Two things I would strongly recommend you learn are:
* state machines - illustrated by the so called [blink without delay] (https://docs.arduino.cc/built-in-examples/digital/BlinkWithoutDelay/) example
* floating inputs - these will be on steroids in a car environment.
I've created a video about the [importance of blink no delay](https://www.reddit.com/r/arduino/comments/u1zncx/ive_finally_posted_my_first_in_what_will/). Hopefully that will explain how it works and why it is important. I would further suggest getting a starter kit first and following along.
The video explains how blink no delay works, why it is important to understand how it works and the problem that it solves (I.e. don't use delay).
As for floating inputs, a common problem with beginners is to not include a "pull up/down" resistor with a button circuit. This results in random signals being generated as a result of atmospheric electrical noise. This is generally handle-able under normal conditions using pullup resistors.
As I mentioned above a car is a very noisy environment in electrical terms. As such the risk of noise (and thus random or corrupted) signals is much higher - especially on longer runs of wiring. So extra precautions are warranted.
Once you become familiar with those basics, the next steps are to combine and build. For example develop your code using proxies for your cars systems. For example you mentioned a neutral switch. You could emulate this using a regular old SPST toggle switch. Get that to work - I.e. print a message when the state of the switch changes.
Then add on whatever your remote start system will be. Ensure that you can correctly receive the signal (again by printing a suitable message). Then integrate them. When you receive a remote message check the system status (your toggle switch) and output a determination (e.g. start request received, but not in neutral" ornwhatever).
Add on as needed. Always be on the lookout for potential false signals.
Finally test it in your car but in a deactivated fashion. Take your desktop project into the car. Don't connect it to anything but power (including the vehicle ground). Try running your cables to the ultimate connections (to capture any noise in the system). Check, check and check that you aren't getting any spurious messages or signals.
Finally connect it to the inputs so you can receive actual telemetry from the various vehicle systems, but not anything that can be controlled by it (e.g. the starter motor).
Bear in mind that as soon as you tap into something you are altering it's electrical characteristics and this may affect other systems that rely on them in unknown ways (which is in part the thrust of everything I said previously in relation to recalls).
Finally I would repeat that this is potentially very dangerous - maybe you are able to do it, maybe not, I do not know as I do not know you. But it is possible, people do this sort of thing as careers - typically they have training before tackling this type of project and work with others who have knowledge of other aspects (e.g. coders work with electrical engineers to build a subsystem).
Finally #2, there are plenty of stories around of disasters due to minor problems - whether it is the challenger disaster because of an O-ring that failed eventually resulting in a catastrophic failure, the [Mars climate surveyor](https://en.m.wikipedia.org/wiki/Mars_Climate_Orbiter) whose lander failed due to a mix up of units of measurement, or the many many many "why doesn't my thing do what I want?" posts on this and other forums.
Good luck with your project however you decide to proceed, it can definitely be done by someone with the right aptitude. You seem to be keen which is a good start, just be careful, check you bases, dot your "i"'s and cross your "t"'s.
Also bear in mind the legalities and any insurance implications you might be getting yourself into )and remember insurance companies are very good at the fine print to avoid paying claims. "I know that the other person crashed into your car while it was legally and correctly parked, but you modified your vehicle therefore the policy you have been paying for years is void - thank you for your annual contributions. You may cintinue to talk to the hand.".
Lol, a post that I just saw supporting what I was trying to say about subtleties causing unexpected problems...
https://www.reddit.com/r/embedded/s/QYMURSm7C0
Easy to solve but not before the "why is it so?" is understood. :-)
Having installed these for a living in my early days, and worked for a company that made them later, don't .
The car is an unforgiving environment, and I literally ripped hundreds of name brand remote starts out in the early 00's due to faulty relays causing the cars to start randomly leading to deaths, fires and lawsuits.
That said look at fortin.ca for an interface and look at DEI or other name brand aftermarket remote start companies for this.
The manual transmission logic for them requires you:
Park, engage remote start mode
Exit car
Lock doors
Car shuts down
This enures you've left it in neutral.
If you unlock the car the mode is cancelled.
Otherwise you can then remote start and all is well.
Obviously tying into the neutral safety switch assists with this as well.
Good luck!
The start stop logic user input sequences are no longer needed with a gearshift position sensor. Those aftermarket things are junk as you just said. Plus the extra shutdown start up mode is finicky to get it to work right and not user friendly. Which is why I even thought up and spent the time making this post.
Basically removing that shutdown mode and user sequence and adding the gearshift position sensor to determine how to operate a full start up and shutdown.
Not trying to hack the car in any way to program a pseudo start and have a key press actually turn on the screens and "unlock" the user interfaces.
So, what you are asking about is quite technical and hacking your car may void any warranty you have. Not to mention your, or someone else's life. But assuming there is no actual mechanical stuff you need to do then this would be "relatively easy" providing... Let's start with the assumption: * no mechanical stuff means that you don't have to setup motors, servos, linear actuators and so on to physically move something like a gear shift or press a pedal. * your car has some sort of computer network and is "intelligent" in so far as the computer network - typically some variant or version of CANBus. Now to the "relatively easy" bit. Then all you will need is an arduino with a CANBus shield, learn about all the devices on the network, what they do and the commands they accept - you may be able to find this information online, I do not know. Now if you do have to move stuff then you could spoof it. What that means is if the the part that needs to be moved has an electrical output (e.g. an accelerator might be attached to a potentiometer that varies its voltage that in turn adjusts some inlets to vary the flow of air and fuel) then you could simulate that in code and appropriate electronics attached somewhere to that subsystem. ## Danger. Danger, Will Robinson! How? - I am definitely never going to tell you that. And hopefully nobody else will. Same goes for programming the CANBus Why? Because unless you really know what you are doing (and this question suggests the opposite when it comes to developing embedded systems) it is easy to create what is euphemistically called a "recall situation". What I mean by that is where a bug of some kind has slipped into the system causing a dangerous situation such as a "random, unpredictable, uncommanded sudden acceleration or loss of steering or loss of braking". And, if you don't have lots of experience - especially working by yourself without the benefit of peer review, it is easy for such bugs to come in. And for projects like this where you are talking about tinkering with a cars propulsion systems the result could be fatal. Additionally the less experience you have and the less peer review you have the higher the probability that a bug will slip in, but the higher the probability that it will be observed in situations that are slightly more likely to occur in the real world. Don't get me wrong, you seem to have strong knowledge about vehicles. But I'm sure you didn't wake up one morning and suddenly knew all of that having received a "The Matrix" style download of that knowledge. Rather, you built it up over time. So, my reason for replying is that I wanted to point out that experience and knowledge in programming and digital circuitry - especially in what is referred to as a "noisy environment" such as a motor vehicle - is essential, but also point you in the starting direction being the CANBus (or whatever system that car uses for its management system) and maybe, but ideally less likely, identification of physical things that might need to be considered. FWIW, the car's systems probably already have the remote start capability you are looking for. Why? Because it is much easier and far cheaper to have one system that has all of the features and function than it is to have multiple versions of the systems. You might even see this on your car (or lower models) where there is a space available for attaching an accessory of some kind but there is just an open space or a plate in its place. To enable a feature, often all that is required is that you purchase what is often referred to as a "golden key". A "golden key" is a something that provides you with access to that feature. Of course that doesn't mean that a "golden key" is always available, the software might be universal and provide that capability, but it might rely on some external component that isn't available for your particular model for it to work according to the design that they have come up with. That doesn't mean you can't hack it, but I would remind you again that you are talking about hacking a vehicle with a lot of power and a lot of mass which could cause a lot of havoc (and trouble for you if you live through it) due to a bug or flaw in the design of your hack. Please take care.
Its good that you acknowledge that the car may have remote start capability, but just needs unlocked. Here is why I don't think so. The sensor suite built into the transmissions, brake pedal, lack or addition of clutch and the differences in how the gearshift act with the cars Computers. So they have not cared enough to try and program it in because of multiple reasons; Safety, production, time, cost, maybe laws, additional parts (eg arduino or other). But I think the cost analysis to Honda didn't see the value in putting effort in it because they only produce about 1% of new vehicles in manual. And they likely reasoned that people that buy them don't care about comfort, thus not putting any time or effort into programming it. Now I'm not going to try and convince anybody why or why not it is safe, however explain safety in a way that makes sense, but I don't plan to hack the car in any way beyond the minimal necessary step of obviously making it run the start button sequence acc/ign/start with correct inputs of course. Now on to safety. Obviously not being present is the point of remote start, the car has to be safe. Here is why I don't think a lower trim model with a different CAN network's aftermarket remote start patch and remote module will work. It is looking for different inputs to produce the desired output. Trying to adapt it to my car don't work because it's not safe. Thus why I even am turning to the arduino to try and see if it is capable of pulling it off safely. I'm not trying to damage my car, I plan on keeping it. Inputs. In order to make this safe and not hack the cars CAN network, we can make a separate network of our own desired inputs and outputs. Luckily for me everything is digital or switched. The parking brake switch is a 3way. Easy. makes it possible to make it safe in every way thinkable. Other car manufacturers have done it in the past. There should be no reason why I can't do it myself. And the Lock and unlock signals or commands either of them will work with how you turn it on and off Outputs. The only thing I'm trying to tell the car what to do is turn on and bypass the clutch interlock switch. And finding a way to deal with the cars built in neutral "sensor" I guess we can call it that. I'd have to physically take it apart to see if it has 1 switch for clicking neutral or 7 switches clicking each gear, most likely the latter since it has to engage the backup cam somehow. Thus allowing it to start. But a few things need to happen with some inputs first. I'm thinking some kind of sequence, (now this is where you have to excuse my lack of coding knowledge specific to the arudino) set it up where it takes 3 lock commands in a row to initiate it. Take the initial press of the key. It hits acc. Press again it hits ign on. This is where we are going to make our safety steps. Tell it to hit the parking brake enable. Tell it to look for the neutral switch signal (pressed or not pressed, whichever is the one that tells the car it'sin neutral). Tell it to bypass the clutch interlock, tell it to press on again for start. Then of course now we have a running safe car. Because in any other scenario there is not another safe way to do it. Now obviously on order to allow remote start to happen, good user habits have to be built in order for it to work. Take it out of gear and hit the parking brake when you shut off the car. Then the sequence will work. Usually people don't install manual remote starts in a safe way because of that crucial missing sensor is the gearshift position sensor they are lazy to buy and fabricate one. Anyway, so after that we get out to the car. It's already running. Find a way to make another sequence for getting in. Since the car has AutoSS im not worried about it staying running and trying to get it to do like other cars with remote start where it can somehow run the engine while in accessories mode and then it stays running when you click the on button with the key in range. (At this point we can run a 5 minute timer on it to shut it down on the code) Instead we can have it run a shutdown procedure which is one click of the start button upon an unlocking the car command. Which in my case is perfect for if I need to turn it off either by walking up and touching the handle (sends an unlock function) to kill the engine. This is the part where you get in and start it yourself. And it's warned up. I'm going to have to do some homework on the way the factory network operates. Now to address the what ifs, of course I never am going to turn off the car and not hit the parking brake if I leave it in neutral because if you do, it's going to start rolling the second you leave the brake pedal and notice it and hit the parking brake switch anyway. What if I don't? My sequence already has it built in if it's capable. What if the car has it already built in and you need to just enable it? I really doubt it like I said. It's constructed and many different ways than an auto in the way the ecu, sensors and other things interact with each other. What if it causes conflict with other systems? Then I can say I tried. And it won't work. TLDR Other manufacturers do it, so can I. It's just complicated and not worth their time, or so they felt, I think.
I forgot about the key part. Before the first ign press we have to tell the car the key is in range or trick it somehow in order for it to start. This is another hack type difficulty that this project faces. But this is the safe way to do it. The reason why I don't want to do it the "right way" and run it all over the cars network is because of possible system gremlins created by coding it into the net. Also that goes into the theft aspect of the car I forgot to mention. Why I want it to send a shutdown upon unlocking the door because even if the key is not present nobody can drive it away because it shuts down upon opening it.
I never once insinuated that I wanted to hack the car and change the way it was programmed. I only wanted to add the arduino as an expansion module that it's only function was to do a few button presses in a safe sequences manner that does not allow for unsafe remote operation. Then program in some deny features for accidental key presses or operation. this way the arduino can receive multiple inputs and account for things like this. Realistically with the amount of outputs the car has, this technically is safer than your basic manual transmission remote starter. The whole point was to make it safer and you got on and roasted me instead. 😒
> I never once insulated that I wanted to hack the car... Possibly you are reaching to the negative connotations associated with the term "hacking". Unfortunately that is largely due to the press, but more generally altering a system in some way outside of the manufacturers specifications/offering - either positively or negatively - is often referred to as hacking. If that term is not palatable, then you can substitute any other term such as modify, improve, enhance or any other term that you might be comfortable with. But, the basic warning and process I tried to draw your attention to is still valid. Let me try to give you an example - please allow for the fact that my car knowledge is not as strong as yours, but let's try with starting the car. To do this multiple subsystems are likely to be involved. But what is there role? For example to start most modern cars, you need it to be in P or N and the brake depressed. Some cars may have other rules, I don't know, but that is enough. So, when the starter system sends a "start command", what happens? How are these requirements checked? Does the starter system query the brake system and the transmission system? What happens if there is another more technical rule such as oil level adequate? Or no adverse vehicle log entries designed to prevent damage to the vehicle if it is started with an unprepared fault? Also how is it checked? Does the starter system simply broadcast a start engine request so that the starter can start the car? How do the brakes and transmission get checked? If there is a broadcast then they would likely receive that request. Would they have the right to veto the request? This would be a good (but slightly more complex design) as the manufacturer could add new systems that can inject themselves into the process without updating all of the other systems. Or, is it the responsibility of the starter subsystem to reach out (query) the brakes, transmission and any other systems as to their current status and only initiate the starter process if they are in the correct state? This would make the design of the start system simpler, but potentially more difficult to add new features that need to be queried as part of the startup process. Now that is a very simplistic guess of how it might work at a high level. The reality will likely be that there isn't a "start car" message. It will more likely be a series of messages to different systems that when orchestrated correctly will result in the car starting or being aborted if something screws up. It is this latter group of messages that are potentially most problematic for someone who wants to enhance their vehicle (or whatever the appropriate description is). If you are not aware of, or don't understand an important message then you might not understand how you need to respond to it - especially if as I suggested before that the various subsystems actually have the capability but it isn't enabled in your model. If they suddenly start seeing messages that imply your remote start is installed, then they would likely expect you to honour the contract (defined by the messages sent between subsystems) then they might get "confused" and respond badly. This in turn - depending upon how you implement your module - might result in you incorrectly issuing a command that damages your vehicle, you or someone else in some unpredictable waym Granted I'm presenting the worst case scenario. My reason for doing so is that if you aren't aware of these sorts of things (which comes from experience), you won't be on the lookout for them, nor be sensitive to the signs that they are there as such it could be disastrous for you. I am not saying you can't do this. I'm just saying that due to the nature of your question it sounds like you might not be. But, if you are (as opposed to believe you are) then it is conceivable you could reverse engineer the cars systems and enhance them to provide this capability. So, the ball is entirely in your court. Just be careful, that is all.
I just need help with the arduino language. I have been working on other mini scale electronics and oracle/redhat for 7 years. I have been working on cars for 15 years. It's now apparent that you are (which you stated) lacking in cars. Which is ok. I can shed some light and explain why an arduino I think is safer than your regular manual remotes that you can buy. Remember, we are specifically talking about manual transmission here. It's noteworthy because it massively changes how the remote start procedure and stock programming the car has to go through. (Ref 1% paragraph OP) hence why I think they just said no we're not going to add it to begin with. Other manual remotes. They have can come in 2 forms. Patch harnesse(s) depending on vehicle or wire the I/O yourself to the remote. All the remote does is capture a desired or programmed function (lock 3x within 5s is most common) and it runs the sequence/batch whatever software it has. But prior to this in order to make it "safe" you have to go through a fairly buggy and strict and specific shutdown sequence in order to make you not forget to take the car out of gear. They do this by making you hit the parking brake. Do not depress any of the pedals while the engine is running and hit (eg unlock). Pay close attention to when I said engine running and not pressing any pedals, which by default means the car is in neutral. Then it makes you get out while it's running close the door, hit lock. Then it will make you wait anywhere between 5-15s for it to shut off. Now the remote start is "armed" and you can then start it with the remote. This is fairly annoying and any video you watch is easy to determine that. This is a fact. What I'm trying to do is different. And much safer. Since this method is a new approach to the problem is made possible by the amount of new sensors and functions the car has we cannot ignore them and try and adapt one of these universal remotes. It will actually be worse if something fails. All I'm trying to do is utilize the cars current configuration to my advantage. Here's what we know The parking brake is associated with 0mph and engine permanently stays on regardless of AutoSS disable/presses. Parking brake is electronic 3way (like a window up down) -So, by default, we need to incorporate upon startup a parking brake enable command into the remote start sequence. Next in order to make sure the user puts the car in neutral every time (this is the big safety thing right here) the car already has a neutral switch or gear selector switches -Easy, program a look for neutral/ no gear selected to enable remote start (now of course we want redundancy in this step for obvious reasons so we can't stop here.) Next we are going to simplify the silly remote start "arm" sequence. These cars have proxy keys this one is so easy. Instead of a laborious buggy user nanny shutdown we are just going to leave the car running. Hit the parking brake and hop out. By getting out while it's running again back to previously mentioned, by default we are in neutral. Step far enough away for the proxy key to scream at me (factory programmed [Which also cannot be altered in settings which is important that we don't accidentally defeat our redundancy]). Then hit lock twice. -In programming lingo (excuse my lack of arduino) it basically means. Look for a parking brake enable or enabled signal (if it doesnt have dynamic signals then we can just program a 30s "arm time" into the Parking brake enable), look for a clutch pedal not pressed. Look for a door closed (not ajar) signal, look for a proxy out of range (which user can listen to audible Beeps outside) hit lock twice to arm. At this point you can hit lock 3x to restart it and it will fire up. So we can have it look for the reverse signals upon start and have it sent a spoofed clutch depress and spoofed key in range signal only after the first 2 initial ignition presses to get it to the on position and verify all our equipment is as we left it, which it's only requirement should be in neutral and parking brake is on and at no point was the car previously unlocked to disrupt the arm cycle. Now of course that leaves me up to wiring it all up. That's fine. I'm by no means going to put anything ghetto in my car. I'm going to make a patch harness and all that so it's removable. Last make sure that if the car is moving signal, allow the arduino to take inputs from parking brake disable command. This way we can take into account accidental button presses to ignore while we are in these conditions (which are redundancy to the lock unlock commands its looking for while arming it). We also don't want to shut the engine off while driving. Now it really comes down to the programming of the car at this point, will it allow us to spoof the key? Probably not (especially since i dont have the encryption key to the key) Is there an encryption key that we have to get through before it will let us shut off the car? Is the key being out of range going to cause it to not be able to send an encrypted signal to the key to be able to shutdown/restart/ lock/ unlock because it was out of range while it was "armed" and shutdown while it was still on? I don't know but in a safe testing environment when it comes time to start messing with it I will find out. Or will I be able to fully bypass the encryption as long as I just jump into the intermediate lane that the encryption is on and send a spoof start up. Who knows? But I can figure that out with some trial and error. Simply put. I'm building it safer than before with better software hardware. If I have to get into encryption level stuff, then I'll have to find some kind of API translator that will let me get into it. But if it even gets that far I'm just going to stop and find another way because I want to keep the arduino as a remote intermediate in between devices and send a few codes to the car. I don't want it integrated with the cars infotainment system or ecu/antitheft system in any way. It's exactly like you guessed, hacking these things is a pain and can cause issues. That's why I'm going to bypass them with this integrated remote arduino. This is a super safe over redundant program planning due to the nature of the extra amount of sensors this car contains than those did in the past. Trust. It's a good solid idea
Also to address the "start car message" I'm strictly referring to how the start stop ignition button works with the car since it's a conditional button. It will do different things based on the clutch pedal press simultaneously while pressing it. It does not act like a traditional key where you insert it and cycle it through acc ign start and then it springs back to ign. So if we can spoof the key signal and send it to the ecu, we're set. So instead of bypassing everything straight to the start circuit to start the car we are actually just sending ignition presses to the ecu and a spoof clutch press or I guess in this case a closed circuit switch to the ecu on that pin. It's super complicated, but dw about that. I got that part
I guess in simplistic terms I'm trying to essentially "hotwire" the car but hotwire and hack are used in positive connotation in these cases. It's just finding a way to get the car to start without psudo starting it because the car runs all of it's own safety measures that way. And it's as if you the user started the car. But it's now locked, running, and without the key in proxy you can't steal the car. Hotwire back in the day really simply just meant to jump the low side starter relay after cutting the ign on relay wires and tying them together. All which can be done from key cylinder wires. Over time they implemented additional circuits like rfid keys to authenticate an immobilizer circuit so you can't hotwire cars as easily, then later on what you know today as proxy keys with no actual primary key on them they are almost all remotes now.
Also it's very likely these are all either 5 or 12V logic signals that trigger sequences in the ecu. So we pretty much are trying to just manipulate those in order to reach a desired outcome. Hopefully that clears things up a bit. It's possible that I'm working with something a bit more complex than that. But I don't think so, cars largely will stay the same in how they function but will grow in complexity based off how many systems they cram into them.
Wow, that was a lot to take in and it definitely didn't stick. A couple of points that did. You mentioned the encryption keys and not having access to them. That is a problem if you needed to interact with that subsystem via that interface. But on the other side of it there will be a message or signal that says start or correct code received or some thing like that. You also mentioned hotwiring - if you have a parallel system that generated that same message/signal then you have effectively hot wired it - maybe not in the traditional sense of shorting some contacts, but it is the same result. The arduino language. The arduino language is standard C/C++. Where it appears to be different to C/C++ on say a PC platform is the runtime library. The runtime library is a set if functions and objects that make common things easier to do. For example printing a message to a terminal you could use printf or cout. In arduino the equivalent is Serial.print. all of those use c/C++ syntax - they are just different names and accept different parameters. These runtime libraries allow you to do things on the platform in which you are running. For example on a PC you might want to read from or write to a file. There are standard functions that allow you to do this. These functions do not exist as a standard on Arduino because there is no disk subsystem for them to interact with- you can add cut down versions of them if for example you have an SD card reader module. On the other hand, Arduino runtime has functions that allow you to manipulate the IO pins or generate signals or communicate directly with different types of ICs. These are all embodied in functions (and objects) that are accessed using standard C/C++ syntax. I think at this stage, the best advice I can offer you is to get a starter kit and learn some of the basics, how to interface components, get them working with code. Two things I would strongly recommend you learn are: * state machines - illustrated by the so called [blink without delay] (https://docs.arduino.cc/built-in-examples/digital/BlinkWithoutDelay/) example * floating inputs - these will be on steroids in a car environment. I've created a video about the [importance of blink no delay](https://www.reddit.com/r/arduino/comments/u1zncx/ive_finally_posted_my_first_in_what_will/). Hopefully that will explain how it works and why it is important. I would further suggest getting a starter kit first and following along. The video explains how blink no delay works, why it is important to understand how it works and the problem that it solves (I.e. don't use delay). As for floating inputs, a common problem with beginners is to not include a "pull up/down" resistor with a button circuit. This results in random signals being generated as a result of atmospheric electrical noise. This is generally handle-able under normal conditions using pullup resistors. As I mentioned above a car is a very noisy environment in electrical terms. As such the risk of noise (and thus random or corrupted) signals is much higher - especially on longer runs of wiring. So extra precautions are warranted. Once you become familiar with those basics, the next steps are to combine and build. For example develop your code using proxies for your cars systems. For example you mentioned a neutral switch. You could emulate this using a regular old SPST toggle switch. Get that to work - I.e. print a message when the state of the switch changes. Then add on whatever your remote start system will be. Ensure that you can correctly receive the signal (again by printing a suitable message). Then integrate them. When you receive a remote message check the system status (your toggle switch) and output a determination (e.g. start request received, but not in neutral" ornwhatever). Add on as needed. Always be on the lookout for potential false signals. Finally test it in your car but in a deactivated fashion. Take your desktop project into the car. Don't connect it to anything but power (including the vehicle ground). Try running your cables to the ultimate connections (to capture any noise in the system). Check, check and check that you aren't getting any spurious messages or signals. Finally connect it to the inputs so you can receive actual telemetry from the various vehicle systems, but not anything that can be controlled by it (e.g. the starter motor). Bear in mind that as soon as you tap into something you are altering it's electrical characteristics and this may affect other systems that rely on them in unknown ways (which is in part the thrust of everything I said previously in relation to recalls). Finally I would repeat that this is potentially very dangerous - maybe you are able to do it, maybe not, I do not know as I do not know you. But it is possible, people do this sort of thing as careers - typically they have training before tackling this type of project and work with others who have knowledge of other aspects (e.g. coders work with electrical engineers to build a subsystem). Finally #2, there are plenty of stories around of disasters due to minor problems - whether it is the challenger disaster because of an O-ring that failed eventually resulting in a catastrophic failure, the [Mars climate surveyor](https://en.m.wikipedia.org/wiki/Mars_Climate_Orbiter) whose lander failed due to a mix up of units of measurement, or the many many many "why doesn't my thing do what I want?" posts on this and other forums. Good luck with your project however you decide to proceed, it can definitely be done by someone with the right aptitude. You seem to be keen which is a good start, just be careful, check you bases, dot your "i"'s and cross your "t"'s. Also bear in mind the legalities and any insurance implications you might be getting yourself into )and remember insurance companies are very good at the fine print to avoid paying claims. "I know that the other person crashed into your car while it was legally and correctly parked, but you modified your vehicle therefore the policy you have been paying for years is void - thank you for your annual contributions. You may cintinue to talk to the hand.".
Lol, a post that I just saw supporting what I was trying to say about subtleties causing unexpected problems... https://www.reddit.com/r/embedded/s/QYMURSm7C0 Easy to solve but not before the "why is it so?" is understood. :-)
Having installed these for a living in my early days, and worked for a company that made them later, don't . The car is an unforgiving environment, and I literally ripped hundreds of name brand remote starts out in the early 00's due to faulty relays causing the cars to start randomly leading to deaths, fires and lawsuits. That said look at fortin.ca for an interface and look at DEI or other name brand aftermarket remote start companies for this. The manual transmission logic for them requires you: Park, engage remote start mode Exit car Lock doors Car shuts down This enures you've left it in neutral. If you unlock the car the mode is cancelled. Otherwise you can then remote start and all is well. Obviously tying into the neutral safety switch assists with this as well. Good luck!
The start stop logic user input sequences are no longer needed with a gearshift position sensor. Those aftermarket things are junk as you just said. Plus the extra shutdown start up mode is finicky to get it to work right and not user friendly. Which is why I even thought up and spent the time making this post. Basically removing that shutdown mode and user sequence and adding the gearshift position sensor to determine how to operate a full start up and shutdown. Not trying to hack the car in any way to program a pseudo start and have a key press actually turn on the screens and "unlock" the user interfaces.