JKOwners Forum banner

21 - 40 of 65 Posts

·
Registered
Joined
·
24 Posts
I'd think the stability control would go nuts with the lockers locked at any kind of speed.
Why is that? I haven't heard of anyone having issues after wiring switches to bypass the lockers.

I would think the ESC would be fine. It would never detect any slippage because all tires would always be spinning the same speed
 

·
Premium Member
Joined
·
4,087 Posts
Why is that? I haven't heard of anyone having issues after wiring switches to bypass the lockers.

I would think the ESC would be fine. It would never detect any slippage because all tires would always be spinning the same speed
I could be wrong but, isn't ESC looking for steering wheel input and both wheels turning the same speed? As would happen with understeer.

Like I said, I could be completely wrong. Though, there's a reason that Jeep did what they did. I'd think avoiding conflicts between systems would have been part of it.
 

·
Registered
Joined
·
24 Posts
Yes I guess you may be right. I wasnt 100% on how the ESC works. However, like I said, if it does cause issues, I would think we would have heard about it from people who are overriding the factory limitations by other means. As to why Chrysler didn't allow it from the factory, I think its more about preventing the average Joe from locking them when its not necessary and causing damage or premature wear.

A related note is that one feature shown of the Gladiators. The rear locker can be locked in 4 Hi
 

·
Registered
Joined
·
960 Posts
Discussion Starter #24
This is awesome! Is there anyway, this same thing could be done with the Rubi lockers for High Range usage? To my knowledge, they also use their own module. Could be wrong though. I feel like someone could make some money offering a plug and play solution that utilizes the factory switches and maintains the factory light indicators full functinality.
No this would be really tricky. The sway bar is easy because the button talks to the sway bar, and the sway bar talks to the dash light. Since the sway bar is fully self contained it's really easy to throw a hack board inline with it.

The lockers on the other hand are controlled by the TIPM, and the actuation sensor is read by the TIPM. Once you're in that box, good luck hacking it because the TIPM does so many things it's just not going to be practical to do any simple hacks. Not going to say impossible, but the effort is not justified in even trying.
 

·
Registered
Joined
·
3 Posts
CAN ID 994 (0x3E2) works
data byte controls dash light

seems that only 3d and 4th bit is only used

xxxx00xx ( 0-3 ) - off
xxxx01xx ( 4 - 7 ) - on
xxxx10xx ( 8 - b ) - slow blink ( i think originally this is used while sway bar is engaging/disengaging )
xxxx11xx ( c - f ) - fast blink ( indicates error )
 

·
Registered
Joined
·
301 Posts
I don't think I've ever heard of anyone else pulling this off. I realize this won't be all that useful to most people as it requires fairly significant electrical and software engineering background but hey, maybe someone wants to do this! None of these CAN commands are documented anywhere on the internet and it took quite some effort to reverse engineer this so maybe I can save someone some time.

The result is the dashboard sway bar button working perfectly at all speeds and in 2Hi, and the indicator light even works perfectly and stays on if disconnected at speed and flashes normally during connect/disconnect events.


This requires active hardware unfortunately, it's not a one-time reprogramming (and we'll never have that unless a truly gifted hacker spends a very long-time finding a vulnerability in the sway bar and then decompiling the software). Just cut the CAN-bus wires to the sway bar and insert a board in between that has a microcontroller and two CAN bus ports. We'll call CANj the Jeep's CAN-C bus, and CANs a new CAN-bus you're adding to the vehicle that just communicates to the sway bar.

I designed a little circuit board to do this, but you could probably use something like an Arduino with some CAN shields for a slightly less favorable form factor if you didn't want to go through making a custom board:


And now the good bits to save you a few days of sniffing the bus staring at hex values trying to figure out how this thing works:
  • For any message transmitted on CANs (from the sway bar), re-transmit untouched on CANj. This sets the state of the LED on the dash.
  • If CANj receives message ID 0x215, ignore its contents and transmit a length-7 message containing 0x8F000000000000 on CANs
  • If CANj receives message ID 0x428, ignore its contents and transmit a length-7 message containing 0x00007E00001001 on CANs
  • If CANj receives message ID 0x325, take its 6th-byte and replace the blank in 0xFD__1EE1C00F0C with that byte, and transmit that on CANs
  • For all other messages received on CANj, ignore it and do nothing
And now you can sway around town whenever you want or wheel at 25MPH without having it re-connect, all from the comfort of OEM controls. Drove it around town at up to 50MPH disconnecting and reconnecting and never got any engine codes and the sway bar light worked perfect and of course the sway bar behaved as desired.
Very very impressive!!!
Such an awesome job!!!
I have mine hooked up in my sport via an off/on/mom switch and relay, and do always have to be super careful of holding the switch too long.
I do wish there was a way to wire into the control board to utilize the factory limit switch, but I am no way smart enough to figure that out.

Again, fantastic job!!!
 

·
Registered
Joined
·
34 Posts
Hey guys I was SO glad to come across this thread. I am trying to do something somewhat similar. Difference is I am using an Arduino to control some other stuff and plan to control OEM motor and brake directly with some relays but I want to keep stock sway bar control and dash light.

So far I have been able to connect to and monitor CANbus "C" by tapping in where my (now dead) sway bar logic board went. I believe I have identified swaybar button signal relayed from interior bus as 0x348 and 0x392 (button press and button release). I tried sending a value of 0 to 0x3E2 in hopes that would cause my swaybar light (flashing fault because no communication at all) to go out but no dice so far. I am sending that as a standard frame with a length of one byte. Anyone know if that is correct?

Thanks so much
 

·
Registered
Joined
·
960 Posts
Discussion Starter #28
Hey guys I was SO glad to come across this thread. I am trying to do something somewhat similar. Difference is I am using an Arduino to control some other stuff and plan to control OEM motor and brake directly with some relays but I want to keep stock sway bar control and dash light.

So far I have been able to connect to and monitor CANbus "C" by tapping in where my (now dead) sway bar logic board went. I believe I have identified swaybar button signal relayed from interior bus as 0x348 and 0x392 (button press and button release). I tried sending a value of 0 to 0x3E2 in hopes that would cause my swaybar light (flashing fault because no communication at all) to go out but no dice so far. I am sending that as a standard frame with a length of one byte. Anyone know if that is correct?

Thanks so much
Vdl a few posts back gave the commands for the light. It is message ID 0x3E2 with the contents he provided to control the light. You need to send it repetitively, at least 1hz. It should be standard frame width 11-bit ID.

Unfortunately since it didn't matter to me (I was just forwarding commands), I'm not sure exactly what the codes for button press is, but indeed all the sway bar receives over CAN is 'button pressed'. There is no logic performed in the Jeep (which I found quite surprising), the sway bar itself performs the 18MPH re-lock logic based on speed which is also on the CAN bus.

Based on my original message, I can only assume this is for the button command, so probably message 0x325's 6th byte is the button state. Check and see if that looks right on whatever you have setup for monitoring when you press/release the button: "If CANj receives message ID 0x325, take its 6th-byte and replace the blank in 0xFD__1EE1C00F0C with that byte, and transmit that on CANs"
 

·
Registered
Joined
·
34 Posts
All,
Kinda sorta got it figured out through experimentation. Was able to disable the light successfully. On steady values seem to result in some flickering. Not sure if this is because the messages are supposed to be one some sort of clock so they arrive at a time when they are expected or if it's due to my occasional message sent error (not sure what's causing that yet.... For now I am just sending the message 10x/second so there is no attempt to synchronize with any other event at all).

I will keep playing with it now that I know I'm on the right track. My next mystery to figure out is what sort of voltage needs to go to the OEM motor and brake release so I can send it without worrying about burning it up and or breaking stuff.
 

·
Registered
Joined
·
34 Posts
Hey thanks Christensent... Yeah for some reason the values vdl dont match up on mine hence my initial confusion. Guess maybe it's a different year thing? Mines a 2012. Anyway values 4-7 actually give me an off state... Had to come back in the office and do some paying work for a little bit and I dont have the other states in front of me but it was the same basic idea just different values.

I was also surprised the thing reads speed and all that but its handy for us as far as giving us flexibility so I'm not gonna complain.
 

·
Registered
Joined
·
960 Posts
Discussion Starter #31
All,
Kinda sorta got it figured out through experimentation. Was able to disable the light successfully. On steady values seem to result in some flickering. Not sure if this is because the messages are supposed to be one some sort of clock so they arrive at a time when they are expected or if it's due to my occasional message sent error (not sure what's causing that yet.... For now I am just sending the message 10x/second so there is no attempt to synchronize with any other event at all).
I don't know specifically about LED control as I just forward messages for that, but there is some precise timing needs in parts of the system so it is quite plausible that it'll take some work to get the timing just right. At first I tried just open-loop transmitting the bogus speed and transfer-case messages to my sway bar at approximately the right frequency as I measured and it didn't work, sway bar wouldn't unlock. I had to actually send the bogus message triggered by the Jeep's real speed and case messages to get the messages to go in either at the exact right speed, order, or something along those lines.
 

·
Registered
Joined
·
34 Posts
Yeah... Kind of wish I could just get my stock board working. Seems like there should be hope for because it does have a good clock and processor takes some initial actions but never get coms on CANbus and earlier when I did it would fault after 60 seconds exactly (even though it functioned normally and everything worked until it faulted). Unfortunately its just too water damaged... I can't even read some of the PNs on the board and the board has internal layers I can't see... Plus my scope isn't fancy enough to trigger right to get much useful data on content of any data moving around.

I was adding the Arduino anyway and the ability to use swaybar at any speed will be nice but its getting to be a bigger project than I was hoping.
 

·
Registered
Joined
·
960 Posts
Discussion Starter #33
You might be able to just get a motor/electronics module from someone. Ask around local Jeep groups, where I'm at people pass around the motors for $100-200 when they get fed up with the mechanical half being such a bad design on water tightness and switch to antirocks.
 

·
Registered
Joined
·
34 Posts
Yep... But its got to be one of those things now. ... At this stage I'm gonna stick with it just so I don't feel like the stupid thing beat me. Plus I got the wiring done up really nice and routed to the interior today and got the mechanical assembly working great on the bench with a a spare Arduino (too cold to work in the jeep once I left the heated shop at work).


Not having the stupid light blinking the whole way home was awesome... Though at this point I'm just sending the code to shut it off. hopefully real functionality later today.
 

·
Registered
Joined
·
301 Posts
I know that some have done it with a PLC.
If I had any electrical/programming knowledge at all, I would try it with an Arduino, but you still need to get it to 9 volts.
Arduino puts out 5v if I'm not mistaking.
Mine is stand alone with switch and relay which is fine for me, but not so much for the wife and kid, as you can't hold the button too long.




On another note, christensent, your photos on your flickr page are AWESOME!!! No other way to put it.
 

·
Registered
Joined
·
34 Posts
Yeah Arduino is 5V plus each pin is only rated to supply a tiny amount of current whereas sway bar requires like 10A. also vehicles large reactive loads (starter, winch, etc) cause transients that will fry Arduino. My set up uses TVS diodes and some filter capacitors on power supply rail with first stage voltage regulation handled by an LM317... I say first stage cause the board itself has some regulation built in but I didn't know anything about it so I put the 317 in in case 13.8V was too much for onboard circuit.

I run outputs to control devices to a little modular relay board designed to be driven by this type of device. if the load is small that relay controls it directly. for larger loads it drives the coil of larger automotive relays in an auxiliary relay/fuse I put under the hood.
 

·
Registered
Joined
·
34 Posts
So looking at the way this "smartbar" thing as they call it is put together I noticed something that may cause issues if it works the way I now think it works.
So in perfect conditions the system is pretty simple... Start with bar connected, motor turns on driving a worm gear through a small planetary gearset which pushes the disengager out by about a half inch which in turn pushes on a collar attached to one half of the splined/keyed swaybar end moving it enough so it no longer engages the other half... Sway bar is now disconnected and the brake is turned on and the motor turned off so everything stays how it was left. Since the worm gear portion and swaybar disengager collar are spring loaded so they "want" to return to engaged so in theory cut the power to the brake and the force of the springs spins the motor backwards the and the two halfs of the swaybar reconnect. Even if they dont line up immediately the springs ensure they come back together as soon as the key ways line up (hence you might have to be moving or at least rock the jeep from side to side a bit to speed up reconnection).

This is the part where things get trickier. I noticed two things about my stock system when it was working:
1. The light on the dash is ACCURATE. Meaning it's not a timer or anything... The light flashes during transitions and goes either on of off once the state had ACTUALLY changed. As if the system were reading the actual position of the engager piece.
2. The system DOES NOT actually read the position of the engager. There is a sort of plunger one end of which physically touches the collar which moves the one end of the swaybar and follows it and the other end extends into the electronics housing where its position can be read by a sensor allowing the system to know the state of the swaybar definitely. The catch? It just DOESN'T. I have gone through the entire thing and NOWHERE is there a sensor that reads the plunger position... Its just not there. My only assumption is that they had intended to use the plunger and changed their mind after mechanic design was complete... Now the plunger does nothing.
So... This means the plunger isn't used but we've already established that the smart bar KNOWS the actual state of the swaybar. A little investigation is tion reveals how: hall effect sensors. These sensors provide feedback to the motor driver about how many rotations the motor has turned both actively during disengaging and passively during reengaging. Sure enough some of the parts on the board have to do with reading these sensors.

This creates a problem for people like me. I dont have a hall effect sensor system like that and will instead use the plunger they helpfully provided but dont use to sense swaybar state. This will work perfectly while reengaging... Release the brake, flash dashlight, once the sensor comes on indicating the engager has moved, turn the dash light off... System is now engaged. While DISENGAGING it's another story... I can't just leave the motor on if the system is bound up and doesnt disengage right away (will burn up or blow the 10A fuse), but if I shut it off and turn the brake on it wont finish disengaging when it frees up... It will be stuck in a sport of halfway state. My hope was that the motor would rotate enough and even if the collar didn't follow ot would preload a spring somewhere in there so once it was free it would finish its movement. This does NOT appear to be the case (otherwise since motor rotations are counted to tell the stock system what the bar state is it would falsely indicate being disengaged even if it hadn't yet finished disengaging... Something my experiments prove it does not do). So how does the stock system accomplish this? Fancy analog control of the so it essentially becomes a constant torque system is my guess... If the motor stalls during disengagement they cut back the voltage so the motor is still "trying" to move but its keep at a safe current so it will complete its movement when it can but not burn up if it takes awhile. The brake never engages until movement is complete... Only way it could work like it does in stock form.

So... Lacking the ability to control the motor in this manner (and not really feeling like adding the ability which sounds like a massive PITA). How can I safely ensure my system disengages even if bound up at the moment the switch is pressed? Clearly I can't just leave the motor on until the plunger state changes... It could burn up in seconds. Pulse it maybe? .2 sec on .8 off until state change? It's not ideal cause it's still gonna be hard on the motor and it may miss the moment of free movement by chance a few times making transitions take longer. Plus switching the motor on and off a bunch of times while stalled is gonna absolutely kill relays contact and the like. Any ideas?
 

·
Registered
Joined
·
34 Posts
Some sort of constant current device would be perfect... Supply the motor with a continuous 5A for 10 sec or so regardless if if its stalled or not... Should be pretty safe and if state still hasn't switched by then I shut it off and wait a few seconds before trying again or just do nothing and require another button push to try for another 10 seconds.

Just dont wanna have to build the circuit myself if I can avoid it. I will look around and see what's other there...
 

·
Registered
Joined
·
301 Posts
I was under the impression that there was a magnet in the sensor and a chip on the board that detects the position of the magnet.
 

·
Registered
Joined
·
960 Posts
Discussion Starter #40
I'm 99.9% sure the following is true:

The plunger does get read, I'm basically 100% sure of this from my detailed characterization of the system. There's a magnet on the end of it, and a hall sensor on the board that reads its position. This controls the dash light directly. There's no motor spin counting etc., it's all about the plunger.

  • If user wants swaybar connected, and plunger says the dog clutch is physically connected, then light is off
  • If user wants swaybar connected and plunger says it's disconnected, or if the user wants it disconnected and plunger says it's connected, then it's flashing (in both cases, just rock the Jeep side-to-side and it should complete the action).
  • If user wants it disconnected and plunger says it is disconnected, the light is on.
There's nothing more to it on the operation of the light. There's no fancy algorithms to determine state, no motor spin counting, it's all about the desired state versus the plunger state.


Now on the operation of the motor, there is indeed a spring preload system in the electronics side so that the motor operates briefly and couldn't care less about the state of the sway bar dog clutch. If it's bound, then the spring preloads in the motor and then when you rock it side to side it mechanically completes the unlock, motor doesn't do anything. The same is true in reverse, if you try to lock it when off-camber the motor pulls the motor-plunger back in, and when you level the jeep out the weaker spring in the mechanical side of the sway bar returns it to a locked position as the dog clutch passes through a flat sway bar. The sway bar takes no electrical action about the state-of-engagement other than controlling the dash LED. You do not need to worry about reading position to control the motor or anything, it's all spring loaded in both directions.


So basically, in both cases it's what you assumed must be true, then somehow determined isn't the case. But actually, it is the case! It's honestly a pretty clever design, it just sucks they actually executed the engineering poorly especially in water-tightness, but the design is pretty good in concept.


If you had a working one this can all be determined easily in the shop by listening to the motor operating, watching the led, and pushing the jeep off-camber to lock it out. The plunger also controls the light even when just the electronics box is running by itself, and you can also observe the motor run and the spring preload system this way. Yours doesn't work so you'll have to take my word for it.
 
21 - 40 of 65 Posts
Top