Reading/writing the values for shifterPosition via BLE

[urb4nc4rl]

Apart from Zwift, my secondary use case for the SS2K is to use it with a Peloton Digital subscription so that I have an easy and reproducible way to

• Set a precise resistance calibrated from 0-100 when doing classes
• Tell at a glance what the current resistance is

To achieve this, I set about writing a SS2K companion app for iPhone - the idea is that it would have:

• A clear readout of the current shifterPosition. (Calibrated as a percentage)
• 2 buttons to replicate ’Shift Down’ and ’Shift Up’
• (optionally) buttons to set an absolute shifterPosition

Having dug into the GATT specs, my initial thought was to achieve this using the FTMS ‘control point’ characteristic that is currently implemented.

I’ve got a POC of this working and the iPhone can now correctly set the gradient percentage via indoor bike simulation parameter.

But, of course, I now realise that incline is not really what I want here, since it doesn’t relate in any way to shifterPosition:

targetPosition = shifterPosition + (userConfig.getIncline() * userConfig.getInclineMultiplier());

Is there any way in which I can read stepperPosition and write shifterPosition via BLE?

One approach might be for SS2K’s BLE server to implement the ‘Fitness Machine Status’ characteristic more fully; there is an Op Code (0x07) for Target Resistance Level Changed that could do the job nicely. I'm not too sure what the best-practice way to write shifterPosition values might be? And perhaps also send relative position commands, such as shiftUp and shiftDown.

On a side-note, does the concept of current stepperPosition and/or shifterPosition survive a device reboot? I guess this affects our approach, as presumably I will need to include a calibration UX if the values are not persisted between power cycles.

@doudar if you were willing to implement the characteristics, I'd certainly be happy to release the iPhone companion app as Open Source; it might be pretty basic but could be a useful addition to the overall codebase for SmartSpin2K.

[doudar]

Exposing a custom characteristic that you could read from and write to is actually pretty simple. I'll try to get a branch going this week for you to test.

If you could, please think about exactly what data you think you'll ever need and propose a characteristic data format for me to follow. I believe we get around 20 bytes max before we have to try fancy stuff.

[urb4nc4rl]

Great! I'll have a think, but we may not need a custom characteristic unless that's your strong preference?

My initial thinking is that the FTMS Fitness Machine Control Point & Fitness Machine Status characteristics probably have what we need.. ..the former has Op Code 0x04 to write resistance, and the latter has 0x07 to notify target resistance changed. (The status characteristic also has op code 0x12 indoor Bike Simulation Parameters changed - if you'd like to implement that I'll be happy to display the incline in the app too)

We might be best working using absolute values of shifterPosition to represent 'resistance', with the caller (i.e. the central) converting any 'shiftUp' command to set a new absolute value based on its knowledge of the latest value.

I also need to dig through your code a bit more to understand if the values of the stepper position survive a reboot, unless you are around to confirm/point me in the right direction?

[doudar]

Currently they do not survive a reboot as I think any method of doing that is hard on the flash based memory (every write would have to be saved). We really need to implement a homing routine on powerup to help with that sort of thing, especially since our stepper drivers are capable of sensor less homing.

I'll look into the specs for 0x04 and 0x07 FTMS control point and see what I can do.

[urb4nc4rl]

Cheers, let me know what else I can do and will work on the client end of things.. (Target Resistance Level is UINT8, unitless with a resolution of 0.1 but it sounds like you have the specs.)

For completeness, it might make sense to make it truly async, i.e. when SS2K code changes the shifterPosition for any reason at all then send that change out via the FTMS Status as a notification -- that way, any manual changes with the hardware should be reflected too.

I'll program the client not to make any assumptions that the value has changed just because it's written it.

If you want further discussion/me to do any additional work please shout. My C++ is too rusty to be useful right now I'm afraid.

Noted on the reboot. The easiest workaround for me is to manually calibrate to 'zero' resistance before powerup each time.

[urb4nc4rl]

@doudar Project update: Very rough-and-ready POC iOS app is almost ready for testing. (screenshots attached)

It current searches for SmartSpin2K devices via BLE peripheral enumeration, then connects and reads updated values from the characteristics for heart rate and cycle power measurement. Once the new 'resistance' characteristics are in place to read/write values of shifterPosition I'll extend to support these.

Next step will be to add UX & code to write resistance values back to the SmartSpin2K. (exposed as 'shift up' and 'shift down' controls) Once code is a little more stable and tidy will push to GitHub.

Finally, plan is to add a calibration screen to allow a user to designate a certain resistance level as 'minimum' and another as 'maximum', with the app then displaying resistance from 0-100 based upon this calibration.

Let me know how the other side of things is going on when you get a chance!

[urb4nc4rl]

Hi @doudar I noticed the new FTMS-Server-fillout branch with excitement! 🙂

One quick comment on the first commit of this:

case 0x04:{  // Resistance level setting --NEED TO ADD SHIFT FEEDBACK IN USERCONFIG
        port = rxValue[1];
        port *= userConfig.getShiftStep();
        userConfig.setIncline(port);

I noticed that you're currently treating an incoming change to resistance level as the same as setting the incline.

But I also noticed your comment!

So I guess the idea is to create a new value in userParameters to represent the shifterPosition, and then this method will directly set that instead. Have I got that right?

[doudar]

Yep, it's just preliminary. @kadaan has been playing around with a custom characteristic for shifting and step feedback also.

I'll be a bit time limited again this week but we're working on it.

[urb4nc4rl]

No worries! I decided to try and help on the project, so I dived in and created a Pull Request to move the shifterPosition variable inside userConfig; feel free to do with it what you will! If it conflicts with the other work then we can just delete it. Carl Partridge CEO, UrbanThings T: +44 (0) 0 7043 1680 | M: +44 (0) 7494 496 891 <http://urbanthings.co/> <http://www.facebook.com/urbanthingsco> <https://twitter.com/urbanthingsco/> <https://www.linkedin.com/company/3216912/> 20 St Thomas St, London Check out Ticketless <http://www.ticketless.travel/>™, our government-backed transport ticketing solution… without the tickets.

…

On 17 May 2021, at 17:20, Anthony Doud ***@***.***> wrote: Yep, it's just preliminary. @kadaan <https://github.com/kadaan> has been playing around with a custom characteristic for shifting and step feedback also. I'll be a bit time limited again this week but we're working on it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#208 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APRJUEZLEWQQ3H4QAONJVK3TOE66PANCNFSM44PRSVPA>.

[doudar]

@kadaan , any updates about your secret squirrel custom characteristic branch?

[urb4nc4rl]

Project update:
I'm pleased to say that the iPhone companion app for SmartSpin2K is now taking shape, thanks to @doudar for adding in the necessary BLE characteristics on the FTMS_Server-fillout branch.

It currently support both reading of basic characteristics (currently heart rate and cycle power) and also manual adjustment of the shifters (i.e. resistance). In other words, if you lose your manual shifters, or forget to pack them in your luggage, you can still use the companion app as a replacement. Subject to PR #218 it should also update the resistance display when you use the manual shifters.

I'll be open sourcing the project once it's stable: in a couple of weeks it should be ready to upload to GitHub.

Screenshot of current alpha test version:

[doudar]

Thanks for the PR's and looking good on the app!

I'm still thinking that exposing the whole userConfig variable as an custom indicate BLE characteristics might be the way to go with this eventually.

Say something like an op code 0x01 (read) or 0x02 (write) then the variable identifier (0x01-~0x13) (one per variable in userConfig, in order of initialization), then the optional uint16 parameter.

Example write of 0x67, 0x0A to variable #6:

Client:
0x02, 0x06, 0x67, 0x0A
Server indicate:
0x06, 0x67, 0x0A

Example read from variable #6
Client:
0x01, 0x06
Server indicate:
0x06, 0x67, 0x0A

Probably would omit SSID & Password since we're not using and BLE security.

Thoughts?

[urb4nc4rl]

I think that's a good idea and would be happy to support some sort of UX on the iPhone side to read/write as many of these parameters as practicable.

Probably worth checking UInt16 is the most appropriate (are you certain none of them can be negative?) - or we could decide on a different number type per variable, similar to the FTMS spec itself.

Ahead of that, I wonder if it might be worth a small refactoring on the SS2K side to separate out the variables that are truly 'config' from those that preserve state and are already catered for (in terms of BLE writing/reading) elsewhere

e.g.: Config: Shifter Motor Power, Shifter Stepper Size, Enable stealth chop, etc.
State: Incline, Stepper Position, etc.

[urb4nc4rl]

Just to clarify, by 'separating out' I mean something like having a userConfig class and a currentState class. Or if that's too much effort for now, it's no biggie we can just ignore the refactoring for now and only expose the config variables we care about via the new characteristic.

[doudar]

check out the new code in BLE_Server.cpp :)

[doudar]

@urb4nc4rl Just wondering if you've had any additional time to look at the custom characteristic?

[urb4nc4rl]

Hi Anthony I haven’t unfortunately, work has been crazy. I did get an iPhone app working successfully with most of it though which I am happy to open source when I get time. (Source attached just in case it’s useful in any way) Carl Carl Partridge CEO @ UrbanThings T: +44 (0) 20 7043 1680 | M: +44 (0) 7494 496 891 <http://urbanthings.co/> <http://www.facebook.com/urbanthingsco> <https://twitter.com/urbanthingsco/> <https://www.linkedin.com/company/3216912/> 20 St. Thomas St, London, SE1 9RS <https://jump.urbanthings.io/id/email-sig-2021-06>

…

On 2 Dec 2021, at 22:35, Anthony Doud ***@***.***> wrote: @urb4nc4rl <https://github.com/urb4nc4rl> Just wondering if you've had any additional time to look at the custom characteristic? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#208 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APRJUEZUGE32ILY3QK3OCCLUO7YC7ANCNFSM44PRSVPA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.