Front wheel speed sensor retrofit ideas?
It's basically like an "electronic" cable between the speed sensor and the speedo instead of a mechanical one. You wouldn't be using it like a position control like I think you are thinking.
Yep, that was exactly my assumption; that it would move to a positions as the speed changed, not rotate. But your description makes sense.
The one thing that is potentially a drawback with my Raspberry setup is the really low signaling voltage. I'm not sure if the Pico has the same limits, though it does have some built in analog I/O, so I'm a bit more optimistic. The standard Pis only tolerate 3.3v for I/O, which is really pretty low for the electrically noisy environment of a vehicle. A lot of sensors don't even like to read or output that low, though the Honeywell 1GT sensor is open collector I believe, so I think it can basically run on whatever you want to feed it. You can get around that some with level shifters and whatnot, but the Arduino does at least bump that up to 5v I believe, which is more common.
In theory I would only have a couple of inputs besides the wheel sensor and those should just be either a voltage sense or (if I simplified the wiring and used resistors) check for variable voltages on one wire. The wheel sensor will be the unknown though.
I thought I saw a 5v output on the pin outs for the Pico , but it wasn't anything I was looking for so I could be wrong.
The epiphany I finally had with the stepper motor idea was realizing how the stock cable drive works. The cable directly connects the odometer to the tailshaft and the speedo is magnetically coupled from there. In the case of the speedos I have at least, 1000 rotations of a cable translates to 1 mile traveled. So the only thing I need to do is make sure that whatever is connected to the speedo rotates 1000 revolutions every time I travel a mile. A stepper motor makes that really easy. Say it takes 128 steps for a full rotation of the motor. I just have to make sure the motor takes 128,000 steps in a mile. If my wheel speed sensor is 5 pulses per mile and my tires are something like 700 revs per mile, that's 3500 pulses per mile, or roughly 36.5 steps per pulse of the speed sensor. The main concern I would have at that point though is how jumpy or jittery it might be. It would be like turning the shaft 1/4 turn at a time, so it could be less than smooth. I'd still be interested to try it though.
Make sure you get it tested before I get to that point so I don't have to.
:rofl:
Sounds like you're running the stock drive by wire if you're using the stock controller?
Yes, planning to run a 2009 PCM from a Challenger. Everything has it's drawbacks and the stock PCM won't allow me to build a DIY traction control setup like you have, but it does come with things like CC logic built in. And since I am cutting down harnesses myself, should be cheaper, too.
For CC, just seems like it would be clean and simple since the stock logic should take care of things like wheel spin and how it takes control and lets go as well. My Dakota has CC and when I turn it off the throttle just slams shut and is very rough. I would assume the stock CC logic in the NGC controller would be much smoother.
That would probably makes things easier in a way, assuming you can get the messages figured out.
As far as the messages, the output from the CC stalk should be simple enough. I plan to source a stalk, clock spring and SCCM and use whatever chip I need to sniff the CANBus messages as I push the buttons.
The one I am worried about getting is the speed message header and format. Just hoping that won't be too difficult when I get to that point.
