You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The device needs WiFi solely to maintain an accurate clock via NTP (Network Time Protocol), which is essential for correctly time-stamping multiple stored sessions. Believe me, I didn't want to introduce this extra setup step, but it’s necessary to ensure reliable session tracking.
I originally hoped to pull clock information from the Omni console (which does have a built-in clock), but unfortunately, that clock is only for display purposes. When the LifeSpan Fit app retrieves session data from the console, it only provides session durations, not actual start/end timestamps. To integrate with Apple HealthKit, the LifeSpan fit app estimates these times by setting the end time as the moment you press "End and Sync", then subtracting the session duration to determine the start time.
Are there alternatives to using WiFi?
In theory, yes—but each alternative has significant drawbacks:
1. Track elapsed time since startup
The device could count seconds since power-on and store this in EEPROM. Upon syncing, the mobile app could then estimate session times.
Issues: If power is lost, all stored session timestamps are effectively useless. Additionally, microcontrollers experience clock drift (minutes per day), leading to inaccurate timestamps. This could result in treadmill sessions overlapping with other tracked activities (e.g., walks recorded by your smartwatch).
2. Sync time via the mobile app
The app could periodically set the device’s clock.
Issues: This would require users to open the app before logging sessions, adding unnecessary friction.
3. Use a real-time clock (RTC) module with a battery
This would keep time reliably, even if power is lost.
Issues: It would require additional hardware which means novices need to solder or breadboard to make connections! Additionally, it requires an initial time sync to seed the time (similar to WiFi).
Why not implement one of these alternatives?
The main reason is accuracy and complexity. These alternatives introduce potential errors or require significant programming effort to make them stable and reliable. I'd rather focus my time on improving other aspects of the project.
That said, if someone finds a better approach and wants to contribute, I'd be happy to accept a pull request!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Why does the device require WiFi?
The device needs WiFi solely to maintain an accurate clock via NTP (Network Time Protocol), which is essential for correctly time-stamping multiple stored sessions. Believe me, I didn't want to introduce this extra setup step, but it’s necessary to ensure reliable session tracking.
I originally hoped to pull clock information from the Omni console (which does have a built-in clock), but unfortunately, that clock is only for display purposes. When the LifeSpan Fit app retrieves session data from the console, it only provides session durations, not actual start/end timestamps. To integrate with Apple HealthKit, the LifeSpan fit app estimates these times by setting the end time as the moment you press "End and Sync", then subtracting the session duration to determine the start time.
Are there alternatives to using WiFi?
In theory, yes—but each alternative has significant drawbacks:
1. Track elapsed time since startup
2. Sync time via the mobile app
3. Use a real-time clock (RTC) module with a battery
Why not implement one of these alternatives?
The main reason is accuracy and complexity. These alternatives introduce potential errors or require significant programming effort to make them stable and reliable. I'd rather focus my time on improving other aspects of the project.
That said, if someone finds a better approach and wants to contribute, I'd be happy to accept a pull request!
Beta Was this translation helpful? Give feedback.
All reactions