Making something of the “failed” SKEA Kickstarter: History of the SKEA Kickstarter and delving into the SKEA API

This is the first of three posts focusing on the SKEA, a Kegel exercise product I backed last year on Kickstarter. This post concerns the history of the  SKEA Kickstarter and the reverse engineering of the SKEA API. The other posts in this series are: –


History of the “failed” SKEA Kickstarter

Last year I backed the SKEA Kickstarter. The SKEA is a smart biofeedback device designed to help women practise pelvic floor muscle exercises or as they’re known Kegels. We were pretty much sold on the device after watching the Kickstarter video which was literally bursting with enthusiasm for the product. After doing some due diligence on Linkcube Studio (Nb. NSFW), the company behind the SKEA, e.g. have they made similar products, we were satisfied that if we backed the product there was a good chance they would deliver.

All was going well until last February when the SKEA was ready for delivery. First off, there was significant confusion over the delivery process, some backers were given the wrong delivery information (myself included), some backers received multiple units and others never received their SKEA (which still appears to be the case for a number of backers). And then there was the release of the SKEA app itself which was and still is a cluster fuck.

When the SKEA was shipped, the accompanying software was provided via a QR code. The QR code pointed to a website that didn’t work, nor has ever worked as far as I can tell. So backers who were lucky enough to receive a SKEA had essentially bought an expensive paper weight. While it’s true the SKEA doesn’t require a phone to work, i.e. by default the device provides muscle contraction feedback via vibration, the SKEA was backed on the premise of making Kegel exercises more fun  which the app was supposed to fulfil. Eventually, in March, the iOS version of the app was released with the Android version to follow within days.

It’s now October. There’s still no Android app, and I’ve not heard good things about the iOS version. Linkcube hasn’t provided any updates since May and none of the backers appear to have had any luck contacting the company, it’s pretty much a given that there aren’t going to be any further updates for this product.

Something is amiss in the SKEA API

It’s bitterly disappointing to see a good concept, full of enthusiasm, die such an ignoble death.  I backed the SKEA based on its Android support (I don’t have an iOS device) which was advertised as the primary release platform during the Kickstarter. Conveniently, I’ve a background in developing biofeedback technologies and the SKEA covers an area of biofeedback therapy I’ve not taken a look at yet, sooo… okay, okay I always intended to get my hand on the API and create my own app, even if the Kickstarter was a complete success. What can I say? It’s what I do.

First things first, in order to develop an app we need access to the SKEA API. I contacted Linkcube back in August about getting access to the API but I didn’t get a response which I pretty much expected, so I decided to reverse engineer the API. Based on the material available about the SKEA I figured out the packet format the device uses to transmit data over Bluetooth. I’m not going to describe the format in detail here (feel free to contact me if you’re interested, e-mail at gilleade(@)gmail.com), what I do want to talk about though is how the pressure value is encoded.

The SKEA is supposed to measure the level of pressure which is applied to the surface of the device. Originally the device was only going to detect if pressure was being applied or not but after the Kickstarter the company decided to change the design of the SKEA and include a variable sensitive pressure sensor. Having recently read Arnold Kegel’s original paper (Kegel 1948) on pelvic floor muscle exercises this was actually a good thing as pressure readings where used as an outcome measure in the exercise he developed (it also made me curious as to why a pressure switch was to be used in the first place – for one not all muscle contractions are created equal).

After connecting my SKEA to a PC I quickly identified where the pressure value was being stored in the data transmission.  I was expecting pressure to be encoded in two bytes of information representing a 10 bit number (or any bit size up to 16). The bit size dictates how sensitive the pressure sensor can be, the higher the bit number the more sensitive the pressure sensor is likely to be. For example a 10 bit number can store 2^10 (1024) different pressure readings while a 16 bit number can store 2^16 (65536). However what I found was that the SKEA had a redundant pressure reading in its packet format.

Figure 1- Value of "pressure" bytes as force is applied to SKEA
Figure 1- Value of “pressure” bytes as force is applied to SKEA

This is illustrated in Figure 1 which shows how the “pressure” bytes changed as force was applied to the sensor.  While I did identify the expected two bytes,  as I manipulated the pressure sensor they didn’t change in the way I expected. Instead the first and second byte reported the same pressure reading but with a fixed offset between them. If they were storing a 10 bit or higher number only 1 byte would have been used for values between 0 and 255 but this was not the case. Due to the redundancy, pressure can only be reported between 0 and 255.  A little quirky but fine otherwise.

That was of course until I noticed something strange when I maxed out the pressure sensor. If you apply a significant level of pressure to the SKEA the pressure reading should max out at 255. This is not the case and is indicative of a major design flaw in the SKEA. When the byte containing the pressure reading maxes out it rolls over back to zero and starts increasing again. What this means is that you can’t guarantee that the pressure reading being reported is correct because you don’t know if the reading has rolled over, e.g. is a reading of 200, actually a reading of 200 or is it a reading of 255 plus 200. If you take a look a closer look at Figure 1 you’ll see what I mean. Notice when I apply pressure to the sensor around the 5 second mark the byte values suddenly drop to zero and start increasing again. I’ve not stopped applying pressure, the byte value has just rolled over. It’s my opinion that the pressure encoding and roll-over flaws are related and due to a coding mistake on the part of the developers.

In practice, it’s more than likely no one will ever apply that level of pressure to the SKEA but you would need real-world data from many users to confirm this.

This post is continued in Designing a Kegel exercise programme

References

Kegel AH (1948) Progressive resistance exercise in the functional restoration of the perineal muscles. American Journal of Obstetrics and Gynecology 56:2.

Leave a Reply

Your email address will not be published. Required fields are marked *