So I recently came into the possession of an LG Watch W7, the WearOS hybrid watch with hands. It's a bizarre thing, and from using it for a few hours you really get the feeling that it had a troubled development.
The development time was quoted as something like 2.5 years, and I imagine that it was triggered by the first prototypes of screens with holes. The two years were probably spent aimlessly messing about with said prototypes, and the final thing then released in a panic to justify the experiments.
The watch lacks most of the standard sensors, the only thing of note being the compass. It seems to share its innards with the LG watch Style, which is a tiny, useless watch with few sensors and awful battery life. The W7 has mildly better battery life only because you don't have to turn on the screen to check the time.
The hands are apparently stolen from some Swiss watch and do not actually hinder usability too much. The more frustrating thing is the 3mm hole in the middle of the LCD (weirdly enough, LCD rather than OLED), which the system attempts to hide by keeping the middle of the screen black. They also make a light ticking noise when moving (due to the stepping nature of their motors), which ranges from annoying to pleasing.
The hands are actually quite independent from the watch. They have their own system for keeping time and keeping track of the battery, and if just the system is shut down, they will continue to keep time independently. However, a lot of control can also be had from userspace through sysfs thanks to the SOP716 driver. Apart from setting the time, you can also move either of the hands to any position, as the hands are not mechanically linked to each other. This is used in WearOS to show the compass, stopwatch (the stopwatch is where the pleasing mechanical sound comes in), altimeter, barometer and timer.
Here's a full listing of the directory:
aging_test driver eol_threshold motor_move position self_test tz_minutes update_sysclock
battery_check_interval dump_errors modalias motor_move_all power subsystem uevent version
battery_level eol_limit motor_init name reset time update_fw watch_mode
And a dip into some of the more interesting files:
-
time can be read or written to manipulate the sop716's internal time. The time is taken in a format such as
2023-03-29 15:38:00. This is local time, entering 3:15 will show 3:15 on the hands.
-
tz_minutes sets the current timezone offset in minutes. This doesn't affect the time that is displayed on the hands, it is only used by
update_sysclock.
-
update_sysclock is used in conjunction with
time and
tz_minutes to set system (linux) time from the hands controller. Writing 1 to this file will set the time at the kernel level, and the kernel internally calls this code during the boot process. Since the sop716 stores local time,
tz_minutes will be used to provide the necessary timezone offset.
-
motor_move takes
[hand number 0 or 1]:[position] while motor_move_all takes
[minute hand position]:[hour hand position] with the position ranging from 0 to 179, meaning that the hands can be set to 2 degree increments. When setting these, you are setting the target position, and the hands will go clockwise or counterclockwise, taking the shortest path to get there.
- If you manually set the position of the hands,
watch_mode will automatically become 0. If you set it to 1, the watch will return to timekeeping mode.
- If
watch_mode is 0 when the watch is powered off, the hands will also be completely powered off. When powered on, a position command needs to be set before you try to set watch_mode, otherwise setting watch_mode won't do anything.
- There's also the question of calibration, which will reset the zero point of the hands if they go out of wack. By writing something such as
0:0:1 to
motor_init, it is possible to nudge the hands' zero point. The first digit indicates the hand that you're working with (0 being minute hand, 1 being hour hand), the second indicates the direction (0 clockwise, 1 counterclockwise) and the last digit is the number of steps to compensate.
The need for manual calibration is bizarre, suggesting that there is zero feedback from the hands to the watch. I feel like some system could have been implemented to get rid of this, which just contributes to the general 'prototype' feel of this watch.
It seems that, whether due to friction or other effects, different W7 examples go out of calibration in different ways. My W7 seems to do pretty well, mostly staying within the bounds of a single step, but Magnefire reports that his goes wack much faster. In any case, no matter how well calibrated, the hands will never be perfectly aligned due to backlash in the motors.
The disadvantages do continue. One can ignore the lack of a heartrate sensor, GPS or other niceties, because it's obviously intended as a fashion smartwatch. A really useful addition would have been a speaker, which would have made taking wrist-calls easier. But all that can be ignored, because what truly cripples it is the awful battery life. It really is disappointing, as the watch can fail to make it through an 8-hour day, even when doing absolutely nothing and with only the hands showing the time. Repairability is also crippled by the glued back, and it doesn't seem implausible to have designed a screw-based system instead.
I love the W7 (now known to me under its strangely appropriate development codename of
narwhal), if not for its execution then for the bravery of those who made it. It seems like a prime example of LG's development model of 'throwing spaghetti at a wall and seeing what sticks'. It really is fascinating to watch the hands swoop around on top of the display, and, after all, the quiet clicking of the stepper motors is endearing. I wish they had tried a second time, but it seems that LG was living on borrowed time anyway. The W7 was their last smartwatch before the entire mobile division was closed down in 2021.
I ought to write something educational about the process of reverse engineering this one, but LG made it really easy.
The driver is entirely self-explanatory, and, unlike some
less honourable devices seems completely unbrickable. My advice would have been just 'go into sysfs with a sense of adventure and see what doesn't break', but the aforementioned
less honourable devices have reined in my hubris. Maybe read the kernel driver first.