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: 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. 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. 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
Hey Bob, I have an iPhone and can trust that we'll get some rain. I've already found places where I can create the "floating" sensation. I'll even compare it to how my Honda Odyssey behaves. I've already done some seat of the pants tests, as posted here:http://priuschat.com/forums/gen-ii-...r-gen-ii-has-brake-problem-please-vote-9.html post #90. - D
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
Hmm, my Droid has an accelorometer and there is free program that shows the x,y and z values. I am not sure it records them though And while I do believe that the Gen II brakes should be updated, I have not found a place to consistently duplicate the phenomenon.
That is going to be important. You might try what works with the ZVW30: approach at ~20 mph. establish a regeneration braking, mild, approaching bump. hold brake through bump. see what happens AFTER the bump with brake pedal held constant. 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
Would the dynolicious log box app for the iPhone work? URL: Dynolicious Log Box BunsenTech, LLC At $3 for the app, the price certainly seems right.
Biggest issue is pricing for the G-Tech. If one already has the G-Tech, it certainly would seem to be a candidate if it can do data logging.
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
Cool, I came back to the thread to see if Dynolicious log box might work. They have the more expensive Dynolicious ($12.99) as well. Usually I like free apps but I guess I can try a $2.99 one. - D
I think the log box app is more suited for what we are attempting to do - it has extensive logging and file writing facilities, where the Dynolicious performance app is focused on non-logged (certainly not the extensive data logging functions of the log box) performance measurement (hp, torque, lateral g, etc.). I could be mistaken, since I don't have an iPhone or iPod Touch and can't compare the two apps. So, who is going to be sending Bob some data?
Great to hear you are going to help out! :tea: Weather forecast for Medford (presumably you are near that part of Southern OR) is rain later next week: 10 Day Weather Forecast for Medford, OR - weather.com Hopefully, you have the log box app installed, working and ready to go when the conditions for replicating the brake drop-out are right. Thanking you and Bob in advance for your help on this matter.
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
ound: Way easier than taxes. Even CPAs who have spent their entire career can't agree on taxes.... Correcting accelerometer error would be trivial in comparison. No offense, but I have seen first hand how CPAs and Tax Attorneys differ in the interpretation of the tax code - it ain't pretty.
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
