Here I will unfold all the precious knowledge I will get from my SlackCell. I'm using Python with pandas, NumPy, scikit-learn and Matplotlib to analyze and visualize my data. Here on the website the plots are displayed with Plotly to add interactivity to the charts.
|Stretch||3.2% @ 5kN|
|Detension rate||1.5 N/s|
|Position||20m from SlackCell anchor|
In case you're interested download the data to play with it on your own.
The scan rate is with 5.2Hz (193ms) a bit underwhelming right now. The HX711 is reading 10Hz (100ms) so probably the LED takes the rest of the 193ms. It's possible to let the HX711 run with 80Hz (12.5ms) (But I haven't jumped the pin by then). Furthermore I will try to shutdown the display while recording or get it way faster. 93ms for something you don't really need because you're using your phone anyway is not worth it.
After doing some highly sophisticated profiling (printing the duration for different program parts to the serial monitor) I get some interesting results.
|Program Part||Time [ms]|
|Looking for bluetooth command||1|
|Time during readings [10Hz]||104|
|Sending data via bluetooth||3|
|Display one character||47|
The main loop, looking for bluetooth commands and reading the loadcell basically don't need any time. The time during readings of the loadcell is a bit slower than expected but the readings are not steady and can go below 100ms. Luckily sending data barely cost anything. The problem is as expected the OLED. Every character costs 47ms. The force is displayed in Newton so I expect to update 4 digits every time because I was bouncing in the test data. Which gives us 188ms plus some of this and that end up in 193ms. I also display the max force but it gets only updated on the display if there is a new maximum.
The slow update of the OLED was caused by a programming error. I put the update in a for loop instead of after it so that the update got called up to 4 times per update of one line on the display. I have to look into the update times of the display now.
I'm running the HX711 module with 80Hz (12.5ms). For recording I disable the display so I have an actual read interval of the load cell of 12ms.
The above detensioning rate of 1.5N/s is approximated with start and end tension while assuming the line is not elongating without bouncing. Another approach could be to use linear regression for the bouncing data and determine the detensioning rate with the slope of the linear regression. This gives us a rate of 1.44N/s a good result.
For the bounce time I use the FFT which gives us a spike in the spectrum at 2.24s which was surprisingly high for me. I expected something around half of it. Probably this is because when you're freestyling you can only use the bounce around highest point. The forces on the bottom of the bounce are too strong to control while doing tricks (at least for me). There are also some peaks at double and triple the bounce frequency. The analysis is limited at 2.59Hz due to the slow scan rate. But there is not much going on anyway at the higher frequencies.
It's nice to see, that everything works nicely and that it is quite easy to get some interesting results. I'm really looking forward to testing more especially different line configurations.