Apologies for the multitude of photos, but it may help if someone desires to check my conclusions (below):
Power and ground pins are spliced into the existing circuit. The others appear to be a case of diverting the 4 x sensor inputs into the controller and then sending the (modified) values into the Soarer's suspension controller.
* PIN B2 (Purple wire) - SHFR = Suspension Height Front Right ? * PIN B3 (Pink wire) - SHRR = Suspension Height Rear Right ? * PIN B10 (Green wire) - SHFL = Suspension Height Front Left ? * PIN B11 (Blue wire) - SHRL = Suspension Height Rear Left ? * PIN A14 (Black wire) - assumed to be earth but does not seem to match with diagram * PIN A8 (Red wire) - assumed to be ignition but does not seem to match with diagram
All other wires appear to be straight pass-through for connectors A and B, except for the handful of pins (A7, A18, A19, A21 and ••) that are not used. Connectors C and D are not used at all by this controller.
Incidentally, I never use the factory height adjustment as it only makes such a small (15mm?) difference, so if there is an easy way of, eg, applying the adjusted height only when that switch is pressed that would be neat.
Something else that may be worth considering is that the factory suspension test mode (on UZZ32 at least) cycles through the various positions in pairs, ie it raises or lowers (front or rear) or (left or right) pairs, but never all 4 at a time. I wonder whether this is to avoid stressing the system by making large changes for all 4 wheel heights at the same time. If so, it may be desirable to build in some sort of timing delay so that the changes occur over something longer than "immediately".
Another thing to consider (again, at least on UZZ32s) is that the factory height adjustments do not normally occur until the gearbox has moved from Park (or Neutral) to a "Drive" (or Reverse) gear. Is this also the case on the UZZ31?
Sunday, April 05, 2015 - 07:13 pm, by: Paul Tonkin(Kiwicarver)
Hi Michael,
Great information thanks. I will reply via PM regarding an arrangement with the height controller.
A couple of things -
In your photo of the controller, what is the part number of the ICs U2 (NEC...) and U3 in your photo of the controller? That could give a quick indication on what method it utilises.
Does the wiring loom fit into the 32 height computer? if so, what response do you get?
I believe your interpretation of the pin names 'SHRR' etc are correct, that is the assumption I have been using on my prototype and is seems to be working ok.
With regards to only two wheels changing height at a time, I'm not sure what the reason for the 32 is, but i know the 31 does front and rear separately because there is a single pump, and significantly different weight on the front and the back. If it was to happen together the front would probably sink and the back would raise. Using a controller that interrupts the sensors (including the one i am making) still allows the factory computer to make the decision on where to apply or remove height.
Incidentally this is one of the reasons why I have the yet un-implemented requirement 4 in place (indication of when height is changing)- as the 31 height response is quite slow, it can be difficult to see what is happening. Currently if i make a change to a sensor value that is outside the achievable range, the rear may move to its limit and stop before the new set point is reached. The front then may not move, I assume because the computer is not allowing it because its 'not it's turn'. Anyway I think this one may be solved with the current software.
With regards to when height changes - on the 31 it definitely happens at standstill in park, and I'm quite sure it also happens while driving. It does need the engine running, maybe because of the power requirements of the pump.
Sunday, April 05, 2015 - 08:07 pm, by: Paul Tonkin(Kiwicarver)
PC interface application.
This application is written in LabView, which is a graphical based programming language. i.e. no lines of code, functions appear as blocks, and they are wired to each other in the development environment. It’s quite simple to get a user interface up and running that interfaces to a serial port. Note that it displays information only, and the controller can be run independently.
To understand what it displays:
Where ever ADC is displayed – this stands for analogue to digital converter. What the Adruino actually reads on each input appears in the code as a number from 0 to 1023, depending on the value of the input. This is then scaled where necessary, and converted into an equivalent voltage.
DAC – Digital to analogue converter. The Arduino takes a number from 0 to 255, and sets an output that is equivalent to that number. This is a pulse width modulated (PWM) output, and is converted to a steady voltage by the filter. Like the ADC, this number can also be scaled, and displayed as a voltage.
The red bar graphs are a graphical representation of where the suspension is actually sitting. It’s quite sensitive, when I drove over a judder bar a bounce in the bar graphs can be seen as each wheel crosses.
The application is only just up and running, and still has some features to implement. This is the process of how it has been used so far.
1) Set up system so its running and the height can be controlled. 2) Adjust height control Pot slowly until both the front and rear heights are at their maximum. 3) Note the ‘Height control scaled’ value, and update the Arduino firmware so this is the maximum 4) Adjust the height control Pot slowly until both the front and rear heights are at their minimum. 5) Note the ‘Height control scaled value, and update the Arduino firmware so this is the minimum.
Although this is where testing has ended to date, it does appear that Requirement 2 can be met – the full range of the height control pot can be tuned to be the full range of the suspension. The guard clearance values will be set in a similar way.
What I have also learnt (with limited testing on un-even ground) is that the front and rear heights may not respond the same way, with the same adjusting input. This may result with some work to achieve requirement 1.
So this is the conclusion of the main features of the height controller system. The next posts will probably be progress updates as I adjust the system in order to meet the Requirements listed in my earlier post - Monday, March 30, 2015 - 07:05 pm.
IC numbers are in email as the photos are slightly too large for this site and I don't know how to resize them on the tablet.
I've not yet tried the AH-5 controller in the UZZ32 but believe it would physically fit and could be made to work by rewiring the connectors so that they match the different pin layout.
Monday, April 06, 2015 - 06:00 pm, by: Paul Tonkin(Kiwicarver)
Michael Brogefjord wrote on Sunday, April 05, 2015 - 09:09 pm:
IC numbers are in email
Got them thanks Michael. Interesting that the IC U2 is a different manufacturer but exactly the same series as the one I was using for my second trial solution 2. Looking forward to seeing how they have done it.
Wednesday, April 08, 2015 - 06:43 pm, by: Paul Tonkin(Kiwicarver)
A Quick update on the height controller.
Today set the car up on some flat ground and cycled the suspension a few times though the range that had been previously defined.
Its looking quite good, though the car is not balancing the height perfectly on all four wheels. It looks like small changes in the height control pot are not detected or translated into suspension movement.
To figure out what is happening my next plan is to:
1) wire the solenoid valves from each wheel, pump and the lowering valve to the Arduino so it can monitor when the suspension height is being changed.
2) create monitor points from each of the sensor inputs and outputs on the Arduino so they can be monitored and verified with a scope or multimeter.
Tuesday, April 21, 2015 - 06:15 pm, by: Paul Tonkin(Kiwicarver)
Progress update -
The height controller now monitors the suspension valves and pump, and displays on the PC application when they are active. These are the small green indicators in the middle of the wheels in the image of the application. The Arduino is connected to the test connector shown here http://soarercentral.com/cgi-bin/sc-forum/discus.cgi?pg=next&topic=30604&page=308222
This is quite useful as its not always easy to tell when the height is adjusting. Of interest or not, this also shows that the ECU adjusts height in three stages - both back wheels, then one front wheel, then the other.
A set of sensor test points have been created, and the PC application has been updated to include a graph of the wheel height. Two interesting things from this: 1) one of the wheels occasionally settles at a slightly different height to the others. The chart shows this wheel sensor to have some noise on it. (shown by the red arrow) 2) The chart very clearly displays the position of the sensors - everything from small bumps in the road, suspension height changes or even acceleration / breaking is logged.
The next step is to incorporate the LCD display. The intention of this is to display the status of the valve and pumps, and the suspension height information. It was ordered some time ago, but is yet to be delivered. The Arduino programming to support it can still start now.
Friday, May 01, 2015 - 07:07 pm, by: Paul Tonkin(Kiwicarver)
The prototype is complete.
From the last post I have incorporated an LCD screen, which shows the height and if the suspension is being adjusted. This was a bigger task than expected, as I ran out of pins on the microcontroller. The solution was to install a multiplexer, which connects between all the sensor inputs, and a single analogue input on the microcontroller.
The following image shows the LCD screen though its different displays.
First start up screen, on for 1 second
Second start up screen, on for 2 seconds
Static Height displayed
Rear of car raising
Rear of car lowering
So requirements #1 to #6 are now complete. These are: 1. A single potentiometer shall be used to control both front and back height equally. - Done 2. The minimum and maximum settings on the Pot shall allow full travel of the suspension range, but not exceeded it, to prevent damage. - Done 3. There shall be indication of the actual height presented to the driver. - Done 4. There shall be indication of when the car is raising, or lowering. - Done 5. There shall be a method to connect a computer for tuning and viewing all parameters. – Done 6. There shall be the ability to simulate the car sensors, so development can happen out of the car. - Done 7. The final solution shall be reliable, integrate cleanly into the car, and have the ability to be replicated. – Next
From here I will - leave the prototype installed for a while to run it through its paces, fine tune the software, while developing the final solution which will meet requirement #7.
Here are some images of the prototype as it is today. Don’t judge me on the cardboard box it is mounted in, this is only prototype!
Box closed, in car
Inside box
Arduino and shield separated
The final solution will incorporate the following. This will take a few weeks so it may go a bit quiet here for a while. • A professional enclosure to hold all parts, maybe 3D printed. • An Arduino PCB • A custom PCB to plug into the Arduino with all additional electronics • Removal of as many wires as possible. • A single connector to interface to the car
A concept drawing of what it might look like is below.
Saturday, May 02, 2015 - 12:27 am, by: Roland Elliott(Aussie2013)
Great work Paul, you have me motivated to go and check the connector on my 32 to see if it has the same connections as the air ride units. I am thinking the axis/gyro control units may interfear, but these could be bypassed for height control for static/service use.
Mike Beck Goo Roo New Zealand UZZ32 No.32 & JZZ31 3.0GT
Monday, July 25, 2016 - 09:03 pm, by: Paul Tonkin(Kiwicarver)
Hi Dan, still running cardboard box.. Its been in and running well for a year now. The project is still inching along, currently there is a schematic diagram for the final solution drafted, and the PCB design is in progress. It has scope creeped a few times which doesn't help getting it finished!
Previous
Closed: New threads not accepted on this page
