Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect Keiser bike version and set stats timeout accordingly. #63

Merged
merged 5 commits into from
Feb 24, 2021

Conversation

chriselsen
Copy link
Contributor

Keiser changed the broadcast interval in firmware revision 6.30 from ~ 2 seconds to ~ 0.3 seconds. As a result bikes before version 6.30 (old) need to use a higher stats timeout value of 7 seconds to detect a communication failure, while bikes starting with version 6.30 (new) can use a lower stats timeout value of 1 second.

This change determines the bikes firmware version on first discovery and sets the stats timeout value accordingly.
For unknown firmware versions (e.g. 5.12, which doesn't exist) a "safe" stats timeout value of 7 seconds is considered.

Copy link
Contributor Author

@chriselsen chriselsen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ptx2 This should be ready for merging

const major = data.readUInt8(KEISER_VALUE_IDX_VER_MAJOR);
const minor = data.readUInt8(KEISER_VALUE_IDX_VER_MINOR);
version = major.toString(16) + "." + minor.toString(16);
if ((major === 6) && (minor >= parseInt(KEISER_STATS_NEWVER_MINOR, 16))) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want FW 7.00+ to use the shorter timeout too -- it looks like it will go back to the longer timeout?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should only be a version 6.xx based on the Keiser Dev documentation. Some of their examples completely ignore any data packages that don't have a Major of 0x06.
Therefore just in case we ever encounter something like that, we treat it as unknown and play it safe with the 7 sec timeout. What do you think?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems reasonable to me :-)

@ptx2
Copy link
Owner

ptx2 commented Feb 24, 2021

Nice one!

@ptx2 ptx2 merged commit 75caf76 into ptx2:main Feb 24, 2021
@tompijls
Copy link

anything needing testing @chriselsen @ptx2 ?

@chriselsen
Copy link
Contributor Author

anything needing testing @chriselsen @ptx2 ?

Sure. More testing is always a good idea. Although here the hope is that you won't notice a functional difference. As this has been merged into 'main' now, you can try this via:

To try this out:

Start with current Gymnasticon Pi image

  • Setup build environment:
sudo apt-get install git
cd
git clone https://github.com/ptx2/gymnasticon.git
cd gymnasticon
sudo service gymnasticon stop
sudo setcap cap_net_raw+eip $(eval readlink -f $(which node))

  • Build it and test it
npm install
npm run build
npm link
NODE_DEBUG=gymnasticon:bike* gymnasticon --bike keiser

When your Keiser bike is detected, it should show the bike's version ID as well as the internally used stats timeout. Other than that, you should not see any changes.

@tompijls
Copy link

worked fine!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants