Can a phone handle the stress of a bike mount?


Recommended Posts


So I made a DIY cell phone mount for my bike, and someone mentioned that their phone broke after using a bike handlebar mount for a long bike trip.  Apparently tiny sensitive solder joints don't like to feel the impact of every sidewalk curb, railroad track, and tree root my bike hits.  So I decided to record the accelerometer data for a quick 4 minute ride, and it looks pretty high, but I don't actually know how high that is.  Acceleration values mean nothing to me.  But I can tell you that those green ones are peaking at around 20,000m/s2, and the green is the X axis, and that was the axis perpendicular to the ground (ie every time the phone went up and down).  The forward/backward/left/right axes didn't feel anywhere near as much force.  Does that mean my phone was experiencing over 2,000 G's of force (1G = 9.8m/s2) every time I hit one of those big bumps?  Is that something to worry about?

 

Is there anyone here with some experience in stress testing electronics that could tell me how long my phone would last if it experiences these kinds of impacts?

 

(note, the graph's y-axis is on a logarithmic scale)

 

en2w.png


 

Link to comment
Share on other sites

So I went for another 7 minute ride, this time with a 1" thick chunk of some good memory foam, placed as padding between the phone and the handlebars, and while the logarithmic graph may not show much difference, the maximum force the phone experienced was more than 50% smaller than having no padding at all, so it's an improvement.

 

l9dg.png

Link to comment
Share on other sites

Definitely not 2000 G's anyway. And it probably won't make much of a difference on your phone unless you do downhill offroad biking

Link to comment
Share on other sites

Cannot be nearly that much. It's insane.

 

Frankly, I don't think those accelerometers in phones and such are even designed and capable for more than detecting a presence and a rough estimate of motion vectors.

 

I will talk out of my ass now, but some distant grasps of logic might be involved and even appear.

 

First, you need to find the value range, sample rate and sensitivity (accuracy) of your device's accelerometer. Many system tools can do that, but values will be less in practice.

 

Because *no* accelerometer (that simple and small) can even measure such a large range of values. Consider that 2000 g is 19.6 km/s2. Registering a small bump lasting 1 millisecond would need to have thrown the device about 20 meters in one direction or another. That, obviously, didn't happen. In fact, it's an insane value - if we reduce time of that impact to 10 ?s, that's still 20 cm. If a small accelerometer (say, 0.1 cm for the actual ) were to measure such value, it should have 5 ns (20 MHz) sample rate and sensitivity of nearly an atomic level.

 

Also, interpretation of data must be wrong. Certainly cannot be logarithmic, for starters.

 

An accelerometer *must*:

* must be properly positioned so that motion in one direction is only reported on its respective axis. You have it mounted at an angle instead - that way vertical acceleration will be reduced and instead also register on whichever is forward/backward axis. You'd need at least Pythagorean theorem to find the actual, if still not correct, values

* as such, report X=0 g, Y=0 g, Z=+1 g (or 9.8 m/s2) when stationary (relative to Earth). All axes are alike, but whichever displays non-zero value must be the vertical one due to gravity

* display negative values on respective axis when slowing down (by definition - accelerating opposite to your present direction) or banking a (normally, left) turn, and <1 when falling towards the Earth

 

After that, to ensure at least some coherence of your data, you'd have to map (say, film) the terrain both (!) wheels run over and then correlate bumps with it.

 

But there's many more things to consider before any remotely definitive scientific conclusions can be made - temperature, air pressure and drag, height above the sea level, inertia and simple things such as pulling the handlebars upwards or doing rear wheel hop to minimize impacts, tire pressure and tread type, presence of shock absorbers and general bicycle condition leading to frame vibrations.

 

Now, of course, a phone or any device or anything that exists has operational limits. But this isn't the way to measure them, only to find them - when your mighty Atrix finally dies, you'll know it had too much of this testing and gave up before you did.

Link to comment
Share on other sites

You didnt say what your using the phone for but if your going off road your better off with an arm pouch if you must carry it, this will at least remove all the severe jarring impact

Link to comment
Share on other sites

You didnt say what your using the phone for but if your going off road your better off with an arm pouch if you must carry it, this will at least remove all the severe jarring impact

 

This x1000. My iPhone 5 goes in my bag when I'm mountain biking, on my back. It has never had an issue, and I've even gone over the bars and and landed on it. 

Strapping it straight to some metal handlebars, on the other hand, would probably beat it to death right quick. I killed an iPhone 3G by accidentally bouncing it off the edge of a table, that's the sort of impact phones really do not like.

Link to comment
Share on other sites

Cannot be nearly that much. It's insane.

 

Frankly, I don't think those accelerometers in phones and such are even designed and capable for more than detecting a presence and a rough estimate of motion vectors.

 

I will talk out of my ass now, but some distant grasps of logic might be involved and even appear.

 

First, you need to find the value range, sample rate and sensitivity (accuracy) of your device's accelerometer. Many system tools can do that, but values will be less in practice.

 

Because *no* accelerometer (that simple and small) can even measure such a large range of values. Consider that 2000 g is 19.6 km/s2. Registering a small bump lasting 1 millisecond would need to have thrown the device about 20 meters in one direction or another. That, obviously, didn't happen. In fact, it's an insane value - if we reduce time of that impact to 10 ?s, that's still 20 cm. If a small accelerometer (say, 0.1 cm for the actual ) were to measure such value, it should have 5 ns (20 MHz) sample rate and sensitivity of nearly an atomic level.

 

Also, interpretation of data must be wrong. Certainly cannot be logarithmic, for starters.

 

An accelerometer *must*:

* must be properly positioned so that motion in one direction is only reported on its respective axis. You have it mounted at an angle instead - that way vertical acceleration will be reduced and instead also register on whichever is forward/backward axis. You'd need at least Pythagorean theorem to find the actual, if still not correct, values

* as such, report X=0 g, Y=0 g, Z=+1 g (or 9.8 m/s2) when stationary (relative to Earth). All axes are alike, but whichever displays non-zero value must be the vertical one due to gravity

* display negative values on respective axis when slowing down (by definition - accelerating opposite to your present direction) or banking a (normally, left) turn, and <1 when falling towards the Earth

 

After that, to ensure at least some coherence of your data, you'd have to map (say, film) the terrain both (!) wheels run over and then correlate bumps with it.

 

But there's many more things to consider before any remotely definitive scientific conclusions can be made - temperature, air pressure and drag, height above the sea level, inertia and simple things such as pulling the handlebars upwards or doing rear wheel hop to minimize impacts, tire pressure and tread type, presence of shock absorbers and general bicycle condition leading to frame vibrations.

 

Now, of course, a phone or any device or anything that exists has operational limits. But this isn't the way to measure them, only to find them - when your mighty Atrix finally dies, you'll know it had too much of this testing and gave up before you did.

 

The graph was logarithmic so that you could see both the large values  and the small ones.  it has nothing to do with the data itself.

 

I was aware the accelerometer needs to be aligned with the axes of motion, i just forgot on the second ride :p

 

The accelerometer in my Atrix is a Kionix KXTF9, and the data was being recorded at 10hz which put it in "high resolution" mode.

 

Now there isn't a wealth of info on their website, but it says that the "G-Range" is "2g, 4g, 8g, and user selectable".  That doesn't sound like a lot.  It also says it can handle up to "5000G's for 0.5ms" or "10000G's for 0.2ms".  So if the reading were accurate, they would have broken the sensor.

 

Now what I can tell you, is that it accurately measures gravity.  When each axis is rotated to be pointed up, they all measure 9.8m/s^2 while the other two axes measure 0, so that's good.  And when I drop the phone (onto nice fluffy padding, of course) from a reasonable height, they all measure 0 when at terminal velocity.

 

I should also mention this ridiculously high readings only came from one app.  The app records sensor data at a predefined rate and nothing else, so while it was recording, I ran another sensor viewing app and watched my accelerometer.  It said the maximum never exceeded 50m/s^2 on the zenith axis (or on any axis), which seems much more reasonable, as thats 5Gs which is well within the 2,4,8 range previously mentioned.  I just assumed that app was incorrect and the other one was correct.  Apparently I need to find better sensor data logging software.  I'd still like to know where it got those values in the 10000's range though, when the other app didnt.

Link to comment
Share on other sites

Maybe the frequency between reads [sample rate] is a lot faster or the software is calibrated to a lesser quality on one compared with the other.

Link to comment
Share on other sites

  • 2 weeks later...
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.