SlackCell Data Analysis

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.


Parameter Value
Webbing Bluewing
Weblock 2x SeaHorse
Length 65m
Stretch 3.2% @ 5kN
Tension Start 4.75kN
Tension End 4.4kN
Min Tension 4.3kN
Max Tension 7.3kN
Duration 250s
Detension rate 1.5 N/s
Slackliner 80kg
Position 20m from SlackCell anchor
Activity sit freestyling


In case you're interested download the data to play with it on your own.


Scan Rate

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
Main loop 1
Reading loadcell 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.

Detensioning Rate

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.

Forces while bouncing and approximation of the detensioning rate with linear regression
Activate JavaScript for interactive chart.

Bounce Time

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.

Magnitude Spectrum
Activate JavaScript for interactive chart.


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.