Mounting "vertically"
Moderators: JeffC, rdoherty, stieg, brentp
Mounting "vertically"
So, given that space is at a premium in my sports racer, I mounted my RCP flat to the firewall behind my head. It is slightly off vertical, and is ~1/8" aluminum. I wanted the unit near center, for optimum yaw sensitivity. The passenger seat was not installed when the picture was taken, but may need to be in the future.
I'm not sure my G force data is valid; seems too "stuttery" to be useful. I changed to 10Hz sampling, as I recall, hoping it would settle down. I believe my configuration is correct, but the orientation picture is not real helpful. I've got readings over 2.0G for acceleration (1000cc engine in 2nd gear?) and braking, as well as both lateral directions. Seems suspicious. And the yaw doesn't make sense to me.
Check out my data (please), say from ~5:00 to ~7:00, especially if you're familiar with Pacific Raceways. Ideas? Can the unit not be mounted vertically?
Thanks! James
Arghhh, I can't load such a large log file. Hmmm. Ideas?
I'm not sure my G force data is valid; seems too "stuttery" to be useful. I changed to 10Hz sampling, as I recall, hoping it would settle down. I believe my configuration is correct, but the orientation picture is not real helpful. I've got readings over 2.0G for acceleration (1000cc engine in 2nd gear?) and braking, as well as both lateral directions. Seems suspicious. And the yaw doesn't make sense to me.
Check out my data (please), say from ~5:00 to ~7:00, especially if you're familiar with Pacific Raceways. Ideas? Can the unit not be mounted vertically?
Thanks! James
Arghhh, I can't load such a large log file. Hmmm. Ideas?
-
- Posts: 101
- Joined: Tue Jan 15, 2013 1:37 pm
If you mounted the unit vertically, you won't be able to get yaw (or rather, you'll get roll yaw instead of slip angle yaw).
I don't know for sure, but I am willing to bet that the race capture doesn't have any noise suppression on the input channels. I'd log at a much higher rate than you need (say, 100Hz) and then average the points down to what you are interested in. This should smooth out the data a lot better. Over sampling is pretty common.
You probably are seeing 2G due to bumps, quick transients, or just noise. I'd look again after averaging.
I don't know for sure, but I am willing to bet that the race capture doesn't have any noise suppression on the input channels. I'd log at a much higher rate than you need (say, 100Hz) and then average the points down to what you are interested in. This should smooth out the data a lot better. Over sampling is pretty common.
You probably are seeing 2G due to bumps, quick transients, or just noise. I'd look again after averaging.
Mounting as designed is great if you're driving a sedan; this is in a sports racer. Think formula car, with a canopy roof. There's not many unoccupied areas 6" square in plan view, and certainly not near the center of the car. There is little I can reach wearing arm tethers, too. Finally, I needed to find a location reasonably protected from weather.
The install guide and other info did not explicitly state it could not be mounted "on edge". If I'm losing slip angle yaw, I guess I'll have to live with that.
How would I smooth the data?
How can I set the min/max values on the line chart display?
Off topic, how can I zoom in on an off-center location on the GPS display? I want to see what line I may have used on a given lap, but can only zoom in centered on the map...
The install guide and other info did not explicitly state it could not be mounted "on edge". If I'm losing slip angle yaw, I guess I'll have to live with that.
How would I smooth the data?
How can I set the min/max values on the line chart display?
Off topic, how can I zoom in on an off-center location on the GPS display? I want to see what line I may have used on a given lap, but can only zoom in centered on the map...
Hi,
In the firmware the accelerometer data is averaged over 10 samples. if this seems insufficient for most applications, the sample buffer could certainly be increased. We recommend limiting your accelerometer sample rate to 50Hz as well.
And yes, a flat surface is best for yaw sensor readings.
Let us know how it goes with your future testing!
In the firmware the accelerometer data is averaged over 10 samples. if this seems insufficient for most applications, the sample buffer could certainly be increased. We recommend limiting your accelerometer sample rate to 50Hz as well.
And yes, a flat surface is best for yaw sensor readings.
Let us know how it goes with your future testing!
Personally, I'd like to see a user configurable filter for all acquisition channels. Some users may have different filtering requirements than others, and some users may need to change their filtering based on different tracks/surfaces. I'd like to see this as a configuration setting rather than hard coded in the firmware.brentp wrote:Hi,
In the firmware the accelerometer data is averaged over 10 samples. if this seems insufficient for most applications, the sample buffer could certainly be increased.
-
- Posts: 101
- Joined: Tue Jan 15, 2013 1:37 pm
Interesting Brent.
So the software already over-samples and then averages? So if I'm sampling accelerometers at 10Hz, the system is actually reading at 100Hz? Or is it averaging across the 10Hz samples?
If it is actually recording at 100Hz, I need to change how I am interpreting data. I was planning to filter out a lot of data points from my data (logged at 5Hz) because I thought it was noise. I'm still probably getting bumps showing up, but even so, they were bumps that averaged over .2 seconds, which is quite a while.
As for zooming and moving the data around, I've found that while RA is still under development there are quite a few things that I still use Excel for, including overlaying the laps with the track map.
So the software already over-samples and then averages? So if I'm sampling accelerometers at 10Hz, the system is actually reading at 100Hz? Or is it averaging across the 10Hz samples?
If it is actually recording at 100Hz, I need to change how I am interpreting data. I was planning to filter out a lot of data points from my data (logged at 5Hz) because I thought it was noise. I'm still probably getting bumps showing up, but even so, they were bumps that averaged over .2 seconds, which is quite a while.
As for zooming and moving the data around, I've found that while RA is still under development there are quite a few things that I still use Excel for, including overlaying the laps with the track map.
If the issue is being able to reach it to turn it on, why not wire in an external input switch to use to turn it on/off. Or use the script to turn on/off at certain speed. Then locate the box in the correct orientation wherever you can find room. I assume that the correct orientation is probably more important than mounting in exact COG of the car. Ie, correct orientation is a necessity, correct COG is a nice to have.Projex wrote:Mounting as designed is great if you're driving a sedan; this is in a sports racer. Think formula car, with a canopy roof. There's not many unoccupied areas 6" square in plan view, and certainly not near the center of the car. There is little I can reach wearing arm tethers, too. Finally, I needed to find a location reasonably protected from weather.
The install guide and other info did not explicitly state it could not be mounted "on edge". If I'm losing slip angle yaw, I guess I'll have to live with that.
How would I smooth the data?
How can I set the min/max values on the line chart display?
Off topic, how can I zoom in on an off-center location on the GPS display? I want to see what line I may have used on a given lap, but can only zoom in centered on the map...
-Scott
Hi dimondjack,
Currently it logs an averaged value across 10 samples *at* the sample rate you're running- it does not over-sample.
Also: for sharing large files try dropcanvas.com if zipping up doesn't cut it.
Scott, a trigger could be wired into one of the digital I/O pins for a manual start, activated with scripting.
Currently it logs an averaged value across 10 samples *at* the sample rate you're running- it does not over-sample.
Also: for sharing large files try dropcanvas.com if zipping up doesn't cut it.
Scott, a trigger could be wired into one of the digital I/O pins for a manual start, activated with scripting.
-
- Posts: 101
- Joined: Tue Jan 15, 2013 1:37 pm
Brent, Interesting. So, to check for understanding, if I sample accelerometers at 1Hz while going in to a hard corner it will take 10 seconds of sustained cornering to show the "true" acceleration? Do any other channels have this feature? I'm assuming that GPS channels do not have this set up, which would mean that accelerometers will lag GPS speeds, with the phenomena being exacerbated at low sample rates.
It makes me wonder, as even sampling at 5Hz I still have a lot of samples that are ouside what I believe to "possible" by quite a bit. I wrote them off as bumps, but a bump lasting 2 seconds is a really BIG bump.
Was the driver for setting it up this way to remove noise? I think a future feature of the system would be to turn off this averaging feature and just log raw values. Then you can choose an appropriate filter or choose the right time period to average over.
It makes me wonder, as even sampling at 5Hz I still have a lot of samples that are ouside what I believe to "possible" by quite a bit. I wrote them off as bumps, but a bump lasting 2 seconds is a really BIG bump.
Was the driver for setting it up this way to remove noise? I think a future feature of the system would be to turn off this averaging feature and just log raw values. Then you can choose an appropriate filter or choose the right time period to average over.
Hi dimondjack,
That's correct. The goal was to smooth / average the response. Only the accelerometer channels have this smoothing; not the analog channels (the analog channels have some hardware filtering in terms of low pass R-C circuit)
Sounds like there's a desire to eliminate *or* make the smoothing / averaging configurable in the firmware? These are all certainly possible; we need feedback from the community to continuously improve / enhance the system.
That's correct. The goal was to smooth / average the response. Only the accelerometer channels have this smoothing; not the analog channels (the analog channels have some hardware filtering in terms of low pass R-C circuit)
Sounds like there's a desire to eliminate *or* make the smoothing / averaging configurable in the firmware? These are all certainly possible; we need feedback from the community to continuously improve / enhance the system.
-
- Posts: 43
- Joined: Tue Apr 30, 2013 10:35 am
I'd definitely like to see raw values and use a filter to process later on. If it's going to do averaging, I'd like to see that come from over-sampling rather than averaging the raw data you'd otherwise see. For example, if logging at 10Hz, I'd be happy if the data was sampled at 100Hz and an average of 10 written to the log file. Averaging 10 data points at 10Hz to get 10Hz data isn't so nice as you'll miss kerbs being hit, for example, and be unable to work out why there was a sudden spike in RPM.
Sprinting an ADR Sport 2
www.endurancelay.co.uk
www.endurancelay.co.uk
-
- Posts: 20
- Joined: Sat Jan 03, 2015 1:42 am