rogerpgvg said:

How about a long-press button for moving to the next screen?

Unfortunately, it's technically impossible to write a watch face that, when in timekeeping mode, would respond to touches/swipes on the screen or physical buttons. Garmin only provides the ability to process long presses on the screen.

rogerpgvg said:

The colored sun and moon progress bars are very neat!

Colored Sun bar displays additional information about dawn, dusk and noon, that would be tricky to have with only background and data colors alone. Both Moon bars display exactly the same information, and the colored version was added to have some visual symmetry when displaying both bars next to each other.

Thank you, that's fine. It's great to have multiple screens. Few watches faces have it.

I hope it's OK to give you some more feedback. When I display the 2nd screen and then scroll to my glances (without opening one), then scroll back to the watch face, it shows the 2nd screen again. But when I display the 2nd screen, scroll to my glances and open one, then it shows the 1st screen when I go back to the watch face. Similarly, when I open a glance and let the watch (FR955) auto-return to the watch face, it shows the 1st screen. A minor thing, but it would be nicer if it consistently goes back to the 2nd screen.

rogerpgvg said:

I hope it's OK to give you some more feedback.

Sure.

I'm aware of this behavior you described (and it bothers me too) and have tried many options to work around it, but have come to the conclusion that there's no way to fix it within the watch face code.

The problem is that when swiping away from watch face to glances list, or when opening some glance by long pressing on the data field (that is, when the watch face disappears from the screen), system sends the same event "user has turned wrist away", and when closing glance or glances list (watch face appears on the screen), system sends "user looks at watch" event, and there's no way to distinguish between actual wrist moving events and these artificial hide/show events, so the watch face triggers unwanted screens switchings.

I think the only way to reduce the likelihood of this happening is by using two-gesture switching. I have it on ToDo and maybe someday will figure out how to solve this problem programmatically.

Thanks, I see. It seems that Garmin IQ didn't accommodate for multiple watch screens so well.

Two questions about the Zambretti forecast. Does it matter whether I set the pressure sensor mode on my watch to "barometer only" or "auto"? And does the forecast deal with pressure changes that are due to changes in elevation (e.g., when I run or drive up a hill)?

rogerpgvg said:

Does it matter whether I set the pressure sensor mode on my watch to "barometer only" or "auto"?

This mode doesn't directly affect the result. The main thing is to have the correct pressure value for your altitude. Therefore, if this mode is set to "barometer only" but you change the altitude, the forecast will give an incorrect result due to the incorrect pressure value since it uses mean sea level pressure value (which only changes due to weather), and not ambient pressure value (which is affected by both altitude and weather). You can use any mode, just make sure the altitude is set correctly (either automatically in "auto" mode, or manually in "barometer only"/"altimeter only" with a calibrated altitude).

rogerpgvg said:

And does the forecast deal with pressure changes that are due to changes in elevation (e.g., when I run or drive up a hill)?

The algorithm solves this problem by using sea level pressure that changes accordingly with the altitude. If the current altitude after all your movements is correct (a difference of a few meters won't significantly affect the result), the forecast is also correct.

Pressure sensor is calibrated at the factory and has built-in conversion formulas for converting pressure to altitude. Unless you change these formulas by simultaneously calibrating both pressure and altitude to incorrect values, the pressure (and the forecast) will be correct, if the altitude is correct.

Thank you, that's useful to know. I'd better calibrate the altitude regularly because the auto mode often changes it even if I don't move.

Related question: What is the time period that the Zambretti forecaster uses for its forecast? I mean, how far back does it look in the pressure record?

My implementation uses 3-hour pressure history to calculate the trend for the forecast. The pressure trend arrow in system ABC glance uses a 6-hour interval divided into two 3-hour sections, so I basically take the last one.

Great, thanks. (It means that I should calibrate the elevation at least 3 hours before I want an accurate forecast.) Thanks a lot for all your answers.

rogerpgvg said:

It means that I should calibrate the elevation at least 3 hours before I want an accurate forecast.

Not quite so. You can, but you don't have to, since the forecast is correct at any time (provided the current altitude is correct, and therefore the pressure). One of the key features of this watch face is that it can work reasonably well with altitude and pressure calibrations. You may notice that after calibration pressure graph in system ABC and Barometer glances may have one or more sharp changes, but you won't likely see them on the watch face since everything will be recalculated, and the pressure graph data field will remain as smooth as if no calibration had been performed. The same applies to all pressure-related calculations, including forecasting. In other words, make sure the altitude is more or less consistent with your current location, and the watch face will do the rest to always display the correct values.

rogerpgvg said:

Thanks a lot for all your answers.

You're welcome!