While working on #76 I find myself flashing firmware repeatedly and getting annoyed at finding the reset button to double tap each time. Is there a way to reboot into UF2 mode with code in normal mode? That way you could extend the movement USB cli to have a reboot command, or do some other trick so that the programming computer could reset the sensorwatch into UF2 mode

Would be nice to have a V1.0.0 release in GitHub to make it clearer to see when there are major & minor releases.

Instructions on how to do this can be seen here

Looking at:

This line gives the segment addresses for character position 2 on the display.
Starting at segment 0, it specifies:

49: SLCD_SEGID(1, 9)
09: SLCD_SEGID(0, 9)
89: SLCD_SEGID(2, 9)
49: SLCD_SEGID(1, 9)
0a: SLCD_SEGID(0, 10)
c0: None
49: SLCD_SEGID(1, 9)

It makes sense that segment 5 is missing -- it's not present on that digit -- but why is (1,9) repeated three times? Shouldn't all the IDs be unique?

Or are they wired together in the hardware? Since this digit only ever shows blank, 0, 1, and 2, it makes sense that the original makers would have wired all the horizontal segments together.

Just confirming my understanding, thanks!

Would be helpful to add a description to the repository to help differentiate it from other repositories in your repository list.

Would suggest the following if you think it's a good idea

A board replacement for the classic Casio F-91W wristwatch

Can we expect a project with CC2540 / CC2640 in the future? (The BeetleBle uses a CC2540 with ATmega328, but it's a huge size 6 x 6 mm)
CC2640 size is 4 × 4 mm RSM VQFN32 (10 GPIOs)
Add a vibration motor from junk mobile phone and you have a great smartwatch (actually still need e-inc screen)

It's a bit difficult to navigate the PCB design files, especially the 'Sensor Boards' folder. For example, there are three different motion sensor boards and the differences / working statuses are not clear.
Could you add a small markdown index file listing filenames and short descriptions?

Second, my version of EAGLE CAD is too old to open most of the design files. It would be really helpful if you could add PDF exports of the schematic and board design files.
If you want to avoid cluttering the repository, you could consider bundling them in a release (#136)

Thanks for your consideration!

My watch locked up today.

I asked for help on the discord and was asked to write a bug report, so the problem could be tracked. I'm going to put in all the information that I think might be relevant.

It got in this state when I long pressed the alarm button on the interval face. I think I was on the 5th default alarm, with the 25/5 pomodoro timer. This was about 10 hours ago, and it's currently still in that state.

It is only showing the starting time of the break period on the interval face. Not counting down, no way to move away from there. This was the first time I was attempting to use this face, so I'm unsure if this is a fluke. I'll open up the watch and see if I can reproduce if I restart the watch without changing the code. I'll update when I know more.

I think this is the relevant bit of my movement_config.h:

const watch_face_t watch_faces[] = {
    simple_clock_face,
    alarm_face,
    stopwatch_face,
    interval_face,
    countdown_face,
    totp_face,
    day_one_face,
    thermistor_logging_face,
    thermistor_readout_face,
    weeknumber_clock_face,
    preferences_face,
    set_time_face,
};

It was built on a friends computer on 21 Jan.

I've not been able to reproduce this behavior in the emulator

Now that I've played with the emulator (and understand better what the interval face is supposed to do) I think it is interesting that it's locked up on the starting time of the "break" period. So not on the "work" period where it is supposed to start. I'm including a photo because think the state it got stuck in might contain a hint for someone that knows the code 😅

Related to #62

I was trying to get the LSF-based TOTP face to work, but couldn't make it parse the .txt file. It would be nice to know how to place files on the LFS of the simulator, so issues related to file format can be debugged more easily.

Your license file is very detailed some people reading the readme may not see it.

May be helpful to add a License section to the readme with a link to the license file

Hello,

I would like to suggest a few updates to the Movement README.

1. Consider adding a section that details the need to add the new watch face file to the Makefile.
2. Consider explaining the purpose of the Boolean return in watch_face_loop.

These two items tripped me up when making my own watch face.

Thanks!

Looking at the docs, watch_enable_buttons() has this note attached:

The BTN_ALARM button runs off of an interrupt in the the RTC controller, not the EIC. If your application ONLY makes use of the alarm button, you do not need to call this method; you can save ~5µA by leaving the EIC disabled and only registering a callback for BTN_ALARM.

I wonder if we can disable the EIC when we don't need it. I'll describe the strategy I'm trying in my application below. I've implemented it successfully, but I can't measure current as low as this is so I don't know if the EIC is actually powered down.

The watch is idle most of the time which probably means we don't need all the buttons to work. In my app I have a 5 second timeout where if no buttons were pressed, the EIC is deinitialized (here) and reinitialized when the alarm button is preesed (here). There's a 250ms green LED flash on deinit and reinit that tells the user it's gone into/come out of idle.

If ext_irq_deinit() does actually power down the EIC, it'd be great if we could get a watch library function for this. It'd be nice if the library also stored our callbacks for us and reset them on reinit.

Hello!

I found link to this project from https://hackaday.com/2021/08/08/wristwatch-pcb-swaps-must-be-in-the-air/

Could you please add information about license of this repository — is it allowed to copy, change and use the code, images and PCB files in any purpose?
It would be great to see any popular open source license.

Anyway to get console output on to the emulator page? The filesystem.c file uses printf to get output but can't seem to figure out a way to get console output from my custom watch face.

Hi,
I love the project, but I have to admit that I don't really know how to start. It would be a great help if there was a small guide on how to get started 🙈

Thank you very much.

Hi,

When building the watch FW and got this error:

$ make

git submodule update --init
make: *** No rule to make target '../lib/TOTP-MCU/sha1.c', needed by 'build/sha1.o'.  Stop.
make: *** Waiting for unfinished jobs....

As the issue seemed to be a typo, I just created a symbolic link, TOTP-MCU, to TOTP, a build without trouble

Apologies if I am just missing this, but I don't see any documentation about how to set up the simulator to use locally for creating watch apps. Is there a document that covers this? Thank you!

My watch seems to gain about 30 seconds every couple of months. This makes the 2-factor authentication watch face useless unless I reset the time once or twice a month. The gain seems to be consistent but I haven't measured it.

Do others have the same issue?

• If yes it's probably due to the code.
• If not then the issue is likely due to manufacturing tolerances of the quartz resonator in which case (if it's a consistent gain for each resonator) we should create a calibration watch face or code.

I think the fabc6d2 commit broke the Doxygen setup on GitHub Pages. I don't have Doxygen on my local machine but I wanted to flag this up since the simulator PR moved some files around.

Steps: In a watch face, call watch_set_buzzer_period() and watch_set_buzzer_on() to sound the buzzer at a desired frequency.

Expected: Buzzer emits a clear sound at the desired frequency

Actual: Buzzer is erratic; some frequencies don't sound at all, and sound is garbled.

Reason: watch_set_buzzer_period() sets the PERBUF register but not CCBUF. This is different from what happens in watch_buzzer_play_note, which works correctly and sets both.

Hello! I'm having trouble building this. I have the correct toolchain installed, but I'm running into an issue when I build. Do y'all have any insight into the following errors? My Google-fu is coming up blank.

/usr/lib/gcc/arm-none-eabi/11.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/11.2.0/../../../../arm-none-eabi/lib/thumb/v6-m/nofp/libc.a(lib_a-writer.o): in function_write_r':
writer.c:(.text._write_r+0x10): undefined reference to _write' /usr/lib/gcc/arm-none-eabi/11.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/11.2.0/../../../../arm-none-eabi/lib/thumb/v6-m/nofp/libc.a(lib_a-readr.o): in function _read_r':
readr.c:(.text._read_r+0x10): undefined reference to _read' collect2: error: ld returned 1 exit status make: *** [Makefile:118: build/watch.elf] Error 1

Anyone observe this? Watch loses time and restarts. Loose battery perhaps?

EDIT: I can consistently reproduce this by pressing on the battery casing. The red LED will blink once, and the watch will reset and start again after a few seconds.

I couldn't find any sort of BOM for the sensor boards. Am I missing something, or is what specific component to use something I should figure out myself?

(I'm mainly interested in the hiking log board.)

Hi,

Hope this is the right place to post this!

I have four sensor watch boards and four of the temperature sensor breakout boards.

After (finally!) putting them all together, three of the watches show the correct temperature. The fourth is showing a temperature usually around -70 degrees Celcius. I've tried reseating the connections a couple of times to see if that's the problem, but it's not making any difference.

Is there any further debugging I can try to do to fix the problem? Or, is it likely the sensor is malfunctioning and will need replacing? Happy to buy another if so.

Thanks!

Chris.

https://www.sensorwatch.net/docs/firmware/simulate/the_stargazer/

To reproduce: Mode Mode Light Mode stuck!

It could be related to this line:

Summary

The timer face breaks after the second loop.

Steps to reproduce

1. set a timer for 15 minutes
2. set to loop

Result

After the second loop, the face turns into nonsense

Image by @TheOnePerson

Hello,

I was using my watch and pressed the side button to use the light and got some odd behavior.

For context, I did have the light set to mix the green and red colors to make a somewhat yellow color. This had worked previously, but I had noticed it was a little slower to respond, and then the attached video occurred. I was able to stop this but only by going into settings and turning off the red portion of the light.

Any ideas? I have since reflashed my board (to get the new tomato face!) and it has not occurred.

Hi Joey,

Do you think there space for tiny ble antena and ship ?

If I press L/M (on the keyboard) at the same time on the first face when running the emulator, it becomes unresponsive.

I've finished writing my first app for the sensor watch, witch displays the current Swatch Internet time. You can check out the code over here (tahnok@bd4626a) but before I open an PR with it, I'm curious to know you want to handle contributed apps / firmware.

I quite like the way that the Goodwatch handles this, which that there is a single firmware codebase. A user can configure what functionality they want at build time by changing a Makefile. App writers don't have to worry about code for the 'core' functionality of watch (like setting the time).

Basically, I would love if there was a way to have firmware with some normal watch functionality (like a stopwatch or a countdown timer) and some weird watch functionality (like a random number generator or weird time keeping systems) combined into a single codebase somehow, while still allowing someone to toss it all and use the (wonderful) framework you are putting together

Is the bootloader for the sensor watch available? What's the process for flashing from scratch?

Apologies if it's somewhere obvious.

Sorry for this issue, I'm sure we all grownups and can handle our secrets, but...

Please don't direct people with private things like TOTP to the web sites. It simply bad idea to teach bad behavior on the web.

The manual twice suggest to to the web https://www.sensorwatch.net/docs/watchfaces/complication/#totp-generator

1. Stefan Sundin’s web site
2. cryptii.com

For the TOTP secrets KeePssXC local application can be used.
converting base32 to C style bytes as simple as:

$ echo "KRUGKIDROVUWG2ZAMJZG653OEBTG66BANJ2W24DTEBXXMZLSEB2GQZJANRQXU6JAMRXWOLQ=" | base32 -d | xxd -i
  0x54, 0x68, 0x65, 0x20, 0x71, 0x75, 0x69, 0x63, 0x6b, 0x20, 0x62, 0x72,
  0x6f, 0x77, 0x6e, 0x20, 0x66, 0x6f, 0x78, 0x20, 0x6a, 0x75, 0x6d, 0x70,
  0x73, 0x20, 0x6f, 0x76, 0x65, 0x72, 0x20, 0x74, 0x68, 0x65, 0x20, 0x6c,
  0x61, 0x7a, 0x79, 0x20, 0x64, 0x6f, 0x67, 0x2e

Previously, faces (e.g. wake/countdown/tomato) used the WATCH_INDICATOR_BELL to say that there was an alarm coming up. The cool new alarm face (and the 'alarm_enabled' bit of simple_clock) now use WATCH_INDICATOR_SIGNAL.

I'm guessing that those faces should be changed to use WATCH_INDICATOR_SIGNAL.

On the other hand, I'm not sure I like the change. The thermistor/voltage/accelerometer faces use WATCH_INDICATOR_SIGNAL when they read data, and this fits better than the bell IMO. i.e. we're now overloading SIGNAL, and under-using BELL (which will be left with only the hourly chime?).

Thoughts - @TheOnePerson , @joeycastillo ?

Hello,

I've been wondering if it would be possible to create a script that runs at build time to automatically set a few things.

It could set lat/long, date, time + some offset to allow for reassembly of the watch, and some things like world clock timezones, timeout of the watch/light, etc.

Would this even be possible? I tried to find a place to set some of these, but I'm not sure where to look for everything.

A user could, for example, set their desired settings in JSON file and the initial setting could be inserted into the code where appropriate. Just something I've been thinking about.

If you hit the alarm button really fast to wake the watch up, the EVENT_ALARM_BUTTON_UP event won't fire.

From @josecastillo:
"when the watch is in low energy mode, the external interrupt controller isn't running, and the alarm pin is assigned to the RTC's external wake function. when that external wake happens, Movement has to re-enable the EIC and reassign that pin from the RTC to the EIC. and i'm seeing that it doesn't do that straight away, there's an unnecessary interaction with the (relatively slow) RTC peripheral happening first"

Having the hathach/tinyusb code checked out at this repo means you miss bug fixes and future features, or the burden of constantly updating the code.

I suggest removing the static code and adding back as a Git submodule, this is the proper way to add other repositories as dependencies to your code. Updates would be done semi-automatically and new clones would always bring the newest version.

References

• https://github.blog/2016-02-01-working-with-submodules/
• https://www.atlassian.com/git/tutorials/git-submodule

user@debian:~/Sensor-Watch/movement/make$ emmake make

make: make
git submodule update --init
HTML build-sim/watch.html
emcc: error: setting EXPORTED_FUNCTIONS expects <class 'list'> but got <class 'str'>
make: *** [../../rules.mk:19: build-sim/watch.html] Error 1

The firmware itself seems to build just fine

Hi,
Maybe this is a rookie question, but how can I get/build the PCB?

Thanks

Steps to reproduce on my computer:

0. Clone
1. cd movement/make
2. emmake make
3. On the emulator:
   1. m m (switch to sunrise/sunset face)
   2. long press a (enter edit mode)
   3. l l l l l (advance to LO)
   4. l (advance to first digit)
   5. a (set hundreds to 1)
   6. l l l l l (advance to sunrise/sunset)

On firefox, the last l causes the light to stay on and throws an index out of bounds error somewhere in the wasm.
On chromium, the webpage crashes and shows SIGSEGV.

Any thoughts?

It doesn't seem to crash on every latitude entered, just some values every time.

I also have this error, not sure if it's relevant:

../../littlefs/lfs.c:1229:error: Corrupted dir pair at {0x0, 0x1}
Ignore that error! Formatting filesystem...
Filesystem mounted with 7680 bytes free.

This is something that always bothered me about the stock f91w interface, and since we now are in control, it would be lovely to fix:

The problem: It's annoying that setting the time is it's own mode

Situation 1:
I have a number of faces that I really love. I cycle through them, and then all the sudden, I'm in the danger zone of changing the time!! My excitement and flow is broken.

Situation 2:
In the middle of the night, I futz around with my watch. It's dark. Where am I? I may need to wake the watch up with the "alarm set" button, but... if I'm on the wrong face, that might unwantedly set the time!

The potential solution:

The set_time_face is not implemented as it's own face, but instead is accessed via a long press of the mode button while on the simple_clock_face!

Why I think this would be an improvement:

1. You always want to have the set_time_face if you have the simple_clock_face. They should go together
2. long pressing the mode button is not utilized in simple_clock_face.
3. You don't end up with the annoying problems listed above

TBH - I'm not sure if this is difficult or not to implement, but if perhaps if the community feels how I feel, someone could take on this improvement! Or if people are really excited, but no one wants to take it on, I can try my luck at an implementation.

<3 Thanks again for this project, I love my watch so much!

First of all, thanks for this amazing project, it's high-key genius!

I wanted to ask if it's realistic to add a gps module, save gps data and offload it to a PC via usb(or somehow else)?

I am planning to make a timetable watchface, where it will display your current ongoing subject, and upcoming subject...
But I have no idea on how to implement it.

Drawing the letters "ST" in positions 0,1 like this:

    char buf[11];
    sprintf(buf, "ST  %2d%02d%02d", 0, 0, 0);
    watch_display_string(buf, 0);

gives the T without the vertical segments:

Perhaps some special cases could be made for Character_Set[] for positions 0 and 1?

I'm wanting to duplicate the original behavior with the LED. Specifically the LED comes on while BTN_LIGHT is pressed.

However I don't see a button release event? That is, doing this:

watch_register_button_callback(BTN_LIGHT, cb_light_pressed);

means that cb_light_pressed is pressed once when the button goes down.

Could the callback get an argument, 1 for pressed and 0 for released?

EVENT_LIGHT_LONG_UP should happen when you release the light button after an EVENT_LIGHT_LONG_PRESS.
However, if you call movement_illuminate_led() when processing EVENT_LIGHT_LONG_PRESS, then when you release the button, a EVENT_LIGHT_BUTTON_UP happens instead.

Here is an example loop:

 bool test_face_loop(movement_event_t event, movement_settings_t *settings, void *context) {
    (void) settings;
    (void) context;
switch(event.event_type) {
        case EVENT_MODE_LONG_PRESS:
            movement_move_to_next_face();
            break;
        case EVENT_LIGHT_LONG_PRESS:
            movement_illuminate_led(); // If you comment out this line everything works properly
            watch_display_character('L', 4);
            watch_display_character(' ', 6);
            watch_display_character(' ', 7);
            break;
        case EVENT_LIGHT_LONG_UP:
            watch_display_character('L', 5);
            break;
        case EVENT_LIGHT_BUTTON_DOWN:
            watch_display_character('S', 6);
            break;
        case EVENT_LIGHT_BUTTON_UP:
            watch_display_character('S', 7);
            break;
        case EVENT_ALARM_BUTTON_UP:
            watch_display_string("    ", 4);
            break;
    }
}

The first 90 Sensor Watch boards are going to be going out to the first backers later this month, and as such I would like to move the library toward something resembling a production quality release. There are a few changes I want to make that I don't think will break what anyone has done so far, but I want to announce them here just in case.

First: I plan to remove all deprecated functions from the library, including the Debug UART. I don't expect this to be an issue; as far as I can tell, no existing watch faces or apps use any deprecated functions at this time.

The bigger change for folks with early hardware: I plan to make the default board OSO-SWAT-A1-05 instead of OSO-SWAT-A1-04. This won't have any impact on builds once the watch is installed in a watch case. However: the USB serial console (which you print to with printf) will not function, as the pin for detecting a USB connection has changed. You will still be able to build firmware for the old boards by running make BOARD=OSO-SWAT-A1-04, but if you are not using printf to log things over USB, there should be no difference whatsoever if you just run make.

In addition, if anyone has suggestions for other things that we might want to do before this first milestone release, please let me know in this thread!

Hi all and hi @TheOnePerson,

I'm using my Sensor Watch since Jan/Feb '23 without any changes in the firmware and without battery replacements and I recognized today, that I can only scroll from preset 1 to 5. After 5 it jumps to 1 again. I remember that I scrolled through all 9 presets one or two weeks ago.
I tried to do some adjustments of the given presets, hoping this could bring back all 9 presets, but it didn't. Is there anything I can do/try?
Thanks and greetings

Following the quick start guide included with the board on my iMac, I'm unable to get make && make install to run and write code to the board. For example, I cd to the Sensor Watch BME280 Project/make directory and enter make && make install and it kicks back the following three lines.

CC build/app.o
make: arm-none-eabi-gcc: No such file or directory
make: *** [build/app.o] Error 1

I did run brew install gcc-arm-none-eabi to install what I think is the right support for the board. Am I missing something else?

movement.c uses read to grab something from the input, then processes it immediately, regardless of whether there's a newline in the buffer.

This means that if you use a normal terminal emulator (i.e. picocom), which sends characters immediately as they're typed - as opposed to Arduino's one, which sends a bunch of characters at once - every filesystem_process_command is called with a single character. And even using Arduino's, you can only send about 50 chars or so before the line is effectively broken at that point due to how fast the characters are transmitted (or some buffer size somewhere).

I believe the easiest fix is to implement an fgets-ish thing in the loop. Unfortunately, we can't use normal fgets at the moment (AFAIK), as it will block up the loop. Moreover, even if we were prepared to be a bit hacky by calling fgets only once there was input to read, AFAIK because select/poll isn't implemented there's no way to detect if there's something is there without actually calling read(), and one is not supposed to mix read() with the normal stdio functions.

Note that from messing around with serial I/O I suspect there are also underlying issues with the serial implementation in TinyUSB, but this is the issue I'm 99% certain exists and is easily fixable.

if we round up the hours:minutes to x:60, the watch will display x:60 instead of x+1:0.

the relevant code to fix this is:
https://github.com/joeycastillo/Sensor-Watch/blob/main/movement/watch_faces/complication/sunrise_sunset_face.c#L93
https://github.com/joeycastillo/Sensor-Watch/blob/main/movement/watch_faces/complication/sunrise_sunset_face.c#L119

some special check is needed for this case

I've been thinking on and off how to implement some kind of countdown timer and I wanted to start a discussion around it.

From what I understand, the SAM L22 only has the one RTC. The alarm is being used to fire the once a minute wake up in low power mode. Movement apps can hook into background task callbacks if they want, but the 'granularity' is limited to once a minute.

Given the above, I don't see a way to make a timer that runs in the background that can fire at a granularity of more than a minute. I think that could be fine for some use cases (I'm thinking a pomodoro app would be neat) but I like to make tea using a 3 minute timer.

The best I can come up with at the moment is to have 2 kinds of timers, a short accurate one that must run in the foreground so it can receive 1Hz updates and a long / low power one that is limited to firing on the minute