Interest in NHW20 brake pause?

It is not my practice to try an speculate about repairs to a vehicle I don't own nor have any technical documentation. But now that the ZVW30 brake pause fix, A0B, is out and seems to be effective, I have some time to share with the NHW20 community if there is any interest in my help (actually I'm just sharing the technique.)

I can't fix any 'brake pause' but I can help others document what is going on ... to quantify the effect. Having engineering units in a complaint with backing data converts a vague concern into something a little harder to dismiss. But I don't have an NHW20 to experiment with and renting one doesn't make a whole lot of sense.

METHODOLOGY

Volunteers with NHW20s who have experience the 'brake pause' will:

1. Find a way to reproduce the effect at will - this may take some time to find a combination of speed-bump, uneven road, or climate conditions such as rain or drizzle. This takes experimentation but without out it, we'll never know if a fix actually worked.
2. Buy, beg, borrow or ... an accelerometer - this allows the experimenter to quantify the effect. That means using acceleration to derive velocities, displacements and measuring the duration of a brake pause. This can be either a Gulf Coast Data Concepts unit or something as simple as an iPhone or iPod Touch application.
3. Alternate instrumentation - Hobbit's four-wheel sensor tap would provide another way to measure exactly what the car is doing during the brake pause.

But the first step is being able to reproduce the effect at will, step 1. If you can't recreate it, there is nothing to measure. It doesn't have to be every time but practice allows folks to define the entry conditions in terms of speed, braking force and weather.

Any interest?

Bob Wilson

 

Excellent! I was beginning to think no one cared.

I bought "Accelerometer Data," an application for the iPhone and iPod Touch (I have a Touch.) I'm not really happy with it because it doesn't seem to have much of a data recording capability. But it was cheap enough.

I need to get some allergy medication so I'll use it to gather speed bump data coming back to the house and post the methodology here. But IF you can survey similar applications, perhaps something in the performance car applications, maybe we can find something better.

Bob Wilson

 

That is going to be important.

You might try what works with the ZVW30:

1. approach at ~20 mph.
2. establish a regeneration braking, mild, approaching bump.
3. hold brake through bump.
4. see what happens AFTER the bump with brake pedal held constant.
5. it may only happen when the far side of the bump is slippery say from a rain, drizzle, leaves, or other slidable debris.

Bob Wilson

 

I tested it Wednesday night and it looks about perfect:

• quality data - in fact it recorded vibrations at 100 Hz sampling rate
• GPS and accelerometer data - if you have an iPhone, this is a nice feature
• wifi e-mail transfer - allows sending the data to a receiving e-mail account
• 12 minutes @100 Hz - plenty of time to investigate specific problems
• excel import - provides a wide range of formats

This is my first choice.

Bob Wilson

 

I started testing the iPod accelerometer today and the quality of data suggests something isn't quite right. When I integrated the acceleration to get the velocity, I got unrealistic velocities. This suggests there may be some non-linear effects. Not to worry, I have a solution.

I have a Gulf Coast Concepts unit that is linear and gives accurate numbers. What I'll have to do is compare the iPod acceleration data in a 1 G field across different angles for all three axis. This will let me develop calibration curves ... at least for my unit. Then I can go back and adjust the integrating and see if I get accurate velocity data.

Folks who have an iPhone will also have GPS data. This provides a standard that can be used to minimize accelerator drift. The accelerometer can be corrected. Sad to say, the iPod Touch does not have a GPS receiver.

The other workaround is to have frequent, zero references in the data. Since reproducing the brake pause often is coming to a stop, the ~10 seconds should provide an accurate velocity profile.

CONCLUSION

We'll still be able to use iPod and iPhone recorded accelerometer data. The math will be a little tricky but not that bad ... easier than taxes.

Bob Wilson

 

After running the iPod Touch accelerometer software and the GCDC X6-2 in parallel, I was about to sync the times and evaluate the axis. The first requirement is mounting:

• iPod Touch - face down, connector towards rear. The bottom of the arm rest is perfect but be sure to secure it with sticky tape. No sliding allowed for usable data.
• X6-2 - flat side down, connector towards rear. The upper try in the arm rest is perfect but be sure to secure it with sticky tape.

The vehicle axis and resulting iPod and X6-2 axis are:

	Column 1	Column 2	Column 3
0	axis	iPod	X6-2
1	accel/brake	Y	Ax
2	yaw	X	Ay
3	vertical	Z	Az

X6-2 reports counts; iPod 0-1 units

There are some scaling constants needed and it is important to use a low-pass filter, iPod, or deadband, X6-2, to avoid recording vibration. However, both appear to be linear within the operational range.

NOTE: I've been running some tests this weekend and I'm seeing a problem with linearity for the iPod runs. Using vehicle stops, I'm seeing significant drift that makes data analysis difficult. I've posting comments in the Dynolicious forum. Right now, I'm not sure this is a good accelerometer solution.

NOTE2: I ran a more extensive set of tests on Monday of the iPod Touch:

• turn off WiFi - in an attempt to improve linearity, no luck. The data is still as drifty as before. Within very short intervals between stops, say about 60 seconds, the drift can be found and quantified. But otherwise, the values continue to wander.
• turn off display (upper ON/OFF button) - turned off the data capture too.
• using power/signal cord - thinking the vehicle power supply would stabilize the values, no luck.

Based upon my testing, I can not recommend the iPod Touch solution except to capture short duration events. Beyond 5 minutes, the drift is too much and sad to say not in a linear fashion.

My second GCDC accelerometer, X6-1A, is loaned out. When it comes back, we can try to find a volunteer to test an NHW20. But this won't be for at least another couple of weeks.

Bob Wilson

 

Let me make it clear:

• iPod Touch software - either software or hardware suffers from too much drift. The rate is OK but the values drift too much.
• GCC X6-2 / X6-1A - either one of these dedicated accelerometers records data accurately with excellent linearity. I have one on loan, the other is available but I don't have an NHW20.

If someone wants to volunteer to repeat the NHW20 brake pause or sag (or whatever you want to call it,) send me a PM. But you need to be able to recreate the braking anomaly.

Bob Wilson