OpenHaldex - HPA touchmotion.. but cheaper

[A Banging Donk]

I've been working on this for quite a while now.. but I think it's now time to put this out to a wider audience.

It's basically a DIY touch motion.

https://github.com/ABangingDonk/OpenHaldex

Figured you lot might be interested

A quick demo:

 

[Zans]

Great work! I'll try this when my car is back on the road

 

[A Banging Donk]

Thanks, interested to hear how you get on

 

[mattyy]

This may be a stupid question but here goes...

May I ask why have the master unit at all? I see you have a commit that only requires the interceptor unit and some kind of switch for the digital inputs to the Arduino, this sounds like the 'master' is only interfacing with the app. Seems a lot of work and fiddling when you could add either bluetooth or wifi to the interceptor for the interfacing and get rid of the 'master'.

I have briefly looked through the source as I understand the interceptor will pick up frames intended for the haldex (on 1 can bus) and manipulate them to do what the user wants and then spit it out to the haldex to tell it what to do ( the other can bus ).
The master interfaces with the app and pulls the frames from the haldex, presuamably as error checking agasint the state the interceptor thinks its in rather than to display the current state in the app, chucks any changes made in the app to the interceptor.

Just trying to get my head around it and whether I could perhaps make this work on a single Rpi - I don't have much experience with Arduino so I am unsure if its due to memory etc to have the two.

Good work though & cheers.

 

[A Banging Donk]

Two main reasons:

There is a crap load of traffic on the bus and the interceptor passes all of it through to the Haldex. This takes a lot of CPU time and I'm not certain how much is left. I'm sure that there are at least one or two IDs I can ignore but haven't gone through trying to remove any yet.

Master was there originally to do FISblocks stuff.. the end goal is to have modes selectable via DIS and the display showing pretty much what the app shows, with custom mode definition confined to the app most likely.

Thanks for looking through, hope my awful code wasn't too vomit inducing.. I'm paid to write pretty code, I vent crap in my spare time

Should certainly be possible to do everything with a single Rpi, not used one myself but they're certainly beefy enough. I have done a bit of experimentation with ESP32 to do the same thing - combine the roles and cut complexity.. but I have other unrelated things to work on at the moment!

 

[desertstorm]

My hat goes off to you very impressive. Does the Haldex still stay engaged when you brake? Very useful when used on the track. The HPA is configureable in different modes to keep the haldex locked when braking. I have a HPA and mostly use it in dynamic mode. Switching between sport and competition mode . Sport being an emulation of a blue haldex and competition an orange haldex. The haldex engagement is more related to the engine torque request , steering angle and vechicle speed .

 

[A Banging Donk]

Thanks!

It does disengage during braking, preventing it from doing so is a case of disconnecting a single wire going down to the Haldex (in the same place you'd splice into the CAN lines). I'll need to experiment with this because it would be awesome to be able to turn this on & off at will.

The HPA is a fantastic bit of kit and looks to be well worth the money. It set the bar so high that I only spent about half a day thinking about commercialising this