Alarm failing to go off

I think I know what happened in ascii256's case

And Garmin will continue to claim they can't reproduce it.

Just to be clear, are you insinuating that Garmin lied about that?

This topic pops up about once a month. Still no admittance of a problem by Garmin.

Because this makes it sounds as though you are. Logically, if Garmin cannot reproduce the problem and therefore has not observed it, then of course it is not going to admit, pretend or even assume that such a problem actually exists. No matter what you say you saw, because the company cannot just take your word and based its official position on it; and no matter how frustrated you are, because emotions have no bearing on objective facts.

I performed a search across the FR230, FR235 and FR630 sections of the forum for the keyword ‘alarm’ (since ‘off’ is too short and ignored), and found these other threads:

• “Clock alarms missed” (started by you)
  
• “Alarm doesn't go off while device is locked?”
  
• “Alarm not working”
  

Absolutely convinced this is a software bug but Indont know how to help them find it.

By isolating the user-observable variables (as opposed to variables in the source code, just to be clear) and their values that trigger the symptoms, so that Garmin staff who has access to the source code can reproduce the problem reliably, and use that as a starting point for a targeted code walk-through.

Whatever tests they are doing are not robust enough. I think if others played with it they'd find it too. Set 5 alarms. Let them run their course. See if they all fire. Then do it again. And again. And again. Eventually they'll start missing in spades.

Sorry, that's a ridiculous position to take. Do you expect Garmin to spend hours or even days trying again and again to chance upon the symptoms, just because you claim alarms are randomly missed with no discernible pattern, when you apparently cannot describe in sufficient detail even just one repeatable scenario in which active alarms will invariably fail to go off?

The only guess I have right now (this is a total wild guess) is that the alarms don't update their state correctly when they fire.

I don't think so. However, I think I know what the cause of ascii256's problem was – and it's not exactly as how he/she framed it.

Based on what ascii256 described above, I set a new alarm:

• for 23:14 (Repeat: Never), and returned to the watch face ✔
  
• for 23:15 (Repeat: Never), and scrolled to the Heart Rate widget
  about 20 seconds before alarm was due to go off ✔
  
• for 23:16 (Repeat: Never), and scrolled to the Controls widget
  about 20 seconds before alarm was due to go off ✔
  
• for 23:17 (Repeat: Daily), and scrolled to the Controls widget
  about 20 seconds before alarm was due to go off ✔
  
• for 23:18 (Repeat: Daily), and returned to the watch face ✔
  ✔ = alarm went off as expected at the specified time
  

So it's neither the Repeat setting of the alarm, nor a widget being active upon reaching the alarm time, that somehow suppresses it – at least not in isolation.

I then connected the USB cable/clip to the watch, and plugged the other end into a mobile phone charger. That's not something I would expect Garmin to test during troubleshooting, since in the Owner's Manual for the FR230/235, the only power source described for charging the device is the USB port on a computer, even though that is obviously not ascii256 was using. I then reset the alarm:

• for 23:19 (Repeat: Daily), and returned to the watch face ✔
  
• for 23:20 (Repeat: Daily), and scrolled to the Controls widget
  about 20 seconds before alarm was due to go off ✔
  
• for 23:21 (Repeat: Never), and scrolled to the Controls widget
  about 20 seconds before alarm was due to go off ✔
  

What was noticeably different, however, was that I didn't hear the watch beep, even though it was vibrating, and the display showed me that an alarm was going off.

I disconnected the charging clip, did some more tests, and the alarms were audible again. OK, so perhaps charging suppresses sounds on the watch, in the same way it disables the optical HR sensor. I went and enabled Key Tones (in Settings»System»Sounds), and checked that the watch beeped every time I pressed a button. However, when the watch is charging, pressing buttons on it does not make it beep.

I then set an alarm for 23:30 (Repeat: Never; Sounds: Tone only), and returned to the watch face while the watch was left charging. At 23:30, the display changed to show me that an alarm was going off, but the watch neither beeped not vibrated.

This morning I woke about 20 minutes early, so when 5:10 hit I was awake and sitting in my recliner watching local news.

4. At 5:10 the alarm DID NOT FIRE as it should.

I'd happily wager that the alarm went off as expected at 5:10, but (whether or not the watch was set to vibrate) ascii256 simply didn't hear it or see it go off, because he/she wasn't looking at the watch at the time, and by electing to charge the watch in a non-canonical manner, he/she unwittingly suppressed audible tones.

If the problem presented to Garmin was that the alarm did not fire – which would be an incorrect conclusion, instead of a proper description of the observable symptom – then of course Garmin wouldn't be able to reproduce it. Here's a better description of the problem, from one of the other threads:

This issue of the alarm not sounding when set has happened to me a couple of times. …‹snip›… The next morning, my normal wake up alarm did not sound even though it was set to "on".

Obviously, my observations do not explain this:

After a few tests i see that the alarm will no longer sound/vibrate when the device is locked.

Sadly my alarm never went off again this morning. It was set correctly, which i double and triple checked: status on, set to 9:30AM, vibrations only, no repeat.

assuming that darrencroton was wearing the watch at the time. (How else would a vibration-only alarm be useful?) I'm not denying that sometimes an alarm truly does not go off at the set time; in fact, I've observed it several times (maybe four times in the three dozen trials I did earlier). I suspect it has something to do with my ‘submitting’ the alarm setting at just the wrong time; it seemed that if I finished setting the alarm 10–15 seconds before it was due to go off, it could get missed. However, I've also experienced finishing setting the alarm within 5 seconds of it going off successfully.

That said, I'm not really interested in setting alarms over and over again close to the specified time, just to see if I can nail the problem down to a particular interval; I don't expect Garmin would be all that interested either. On the other hand, you're of course welcome to go on that wild goose chase if you so wish.

I have also witnessed this problem. My morning alarm was failing to go off (while observing my watch). I needed to factory reset my watch to get it working.

I didn't read that whole thing, but I can confirm a few things:

I do charge my watch using a low amp mobile usb charger and not a PC USB connection.
I was not charging when the alarm was set to go off.
The alarm absolutely did not go off. The watch was stuck on the Bluetooth screen and I sat there and watched as 5:10 hit and then passed.

I wasn't actually troubleshooting anything at the time. I was just sitting in my chair thinking about how I had woken up early and then just sat there waiting for the alarm to ring/vibrate to trigger my morning rituals.

I can confirm that I had the same. Alarm is not reliable.

Hi

in order for Garmin to fix this they need to replicate the issue. They obviously can't. If you want the issue to be fixed I suggest you find a way to get the watch to fail every time an alarm is set so you can post precise instructions so Garmin can validate the problem. It looks to me like it will be an interaction issue, ie multiple things happen concurrently which causes the alarm to fail. All you need to do is work out what those things are! I'd start with CIQ as that has been know to cause issues. Are the people having issues using CIQ and if so what apps/watch faces? Do you still get failures when you have no CIQ running?

CW

Wow...... so from one sentence typed on my phone in response you inferred all this information about the problem, successfully diagnosed it, and summarily dismissed me and the rest of us eh? Gods gift to software developers eh?

Look.... ASmugDill...... I don't want to start a flame war here, and forums and email are exceptionally poor when it comes to transmitting emotion and attitude, but boy did you put your post in a very dismissive and aggressive way. Let me give you some context that you filled in and maybe we can have some constructive conversation moving forward.

1 - I did not insinuate that Garmin lied, but I am insinuating that their first level of tech support is not capable of diagnosing the problem. You don't have any of the "objective facts." I sent Garmin a very detailed list of steps that at the time I thought could help them reproduce the problem however even to this day, I can tell you this fact, there is NO REPETITIVE WAY of reproducing this problem.

2 - Let me tell you something about myself before you go off continuing to assume I'm clueless. I've spent over a decade of my life doing verification on software, ASICS, and FPGA's for some of the most safety critical systems on the planet. I've used advanced verification techniques on both hardware and software and I know a thing or two about crawling through code. I know software code and hardware pretty damned well. I will not make the same assumption that you don't know what you are talking about. I don't know what you've assumed about me from my one sentence, however you worded your response in a very belittling way. I've also worked for 5 years in tech support for an engineering firm and believe me I know how frustrating it can be on the other end of that phone line.

3 - This problem has been exceptionally frustrating for me to diagnose. The Computer and Electrical engineer in me says that computers do what they are told. I should be able to isolate this problem to a specific cause. Well let me tell you that I have tried just about everything and this problem is anything but reproducible. You have a nice little check list you built but I'll tell you this.

I tested with:

A - Heart rate monitor disabled
B - Bluetooth disabled
C - Plugged in via USB to a computer
D - Plugged in via USB to a power supply
E - In the low power state
F - Not in the low power state
G - With apps running
H - With apps not running
I - I even tested this nearly 25 times after doing FRESH REBOOTS before each alarm
J - Factory resets
K - Alarms out of sequential order, in sequential order
L - Watch face locked and unlocked

Should I keep going on? In EVERY ONE of these cases, you bet I can get alarms to fire. In EVERY ONE of these cases I also got misses.

I spent nearly 7 straight days of setting alarms under nearly every condition I could think of and in return I have ZERO substantive data that tells me what causes misses vs hits on the alarms.

Either the base routine for time keeping and alarm triggering is flawed or the hardware clock itself is glitching, I don't know. I eventually decided it was no longer worth my time as I can just set multiple alarms and usually I'm just fine. I didn't really have an interest in taking the time to mail my watch in for a new one because I didn't believe it would fix the problem, and I still believe I'm right.

Why did I even care to do this testing? First, this is what I do. I test things for a living, so I thought I'd give it a try, but I don't have any source code to look at. Second, I bought this watch as an upgrade from the 220, and I bought it for 2 reasons. 1 is the optical heart rate, and 2 was specifically the ability to set a vibrate only alarm to wake up in the morning. Guess how thrilled I was that both of these features have had issues!

Now, if you want to continue discussing this without assuming I'm an idiot, I'd love to continue talking it through. The engineer in me would love to find a solution or a reproducible way of recreating this issue. I'm not however interested enough to attempt working my way up to higher levels of Garmin support or trading in my watch. If there's one thing I've learned about this issue however it's that whatever it is, it has proven to be very random under every condition I've tested it under with no indication that it can be reliably reproduced. From that view point, I don't ever expect Garmin to diagnose this issue unless they stumble upon it out of dumb luck.

… but boy did you put your post in a very dismissive and aggressive way.

Well, I'm sorry you perceived and/or interpreted it that way. My goal was to present a brick wall that has no undue regard for all those who wish to slam their heads (aggressively, in frustration, or otherwise) against it; that's my view of how the outside world – inclusive of corporations, governments, fellow members of society, etc. as well as the technological landscape – ought to treat individuals in open/general discussion (as opposed to, say, commercial negotiations or relationship maintenance), not as people with whom to empathise or sympathise or who ought to be accommodated if possible.

I did not insinuate that Garmin lied, but I am insinuating that their first level of tech support is not capable of diagnosing the problem.

One cannot diagnose a problem he/she/it cannot observe or prove to exist.

You don't have any of the "objective facts."

I'm not privy to your correspondence with Garmin; that much is true.

I sent Garmin a very detailed list of steps that at the time I thought could help them reproduce the problem however even to this day, I can tell you this fact, there is NO REPETITIVE WAY of reproducing this problem.

OK, so if Garmin (at Level 1 Support or above) cannot reproduce the problem, and has insufficient cause to conclude the problem as described exists, it has no reason to admit or acknowledge that there is a problem. You (correctly or otherwise) claimed that there is a problem, and – I'm going out on a limb here – Garmin has a record in its IT systems of the ‘episode’ (whether they call it Incident, Problem, Fault, etc.) and interacted with you with regard to it, thus acknowledging you have made a report of a problem.

I don't know what you've assumed about me from my one sentence, however you worded your response in a very belittling way.

Well, that's a shame. I wanted to convey a lack of undue regard – as a fellow customer and an equal – for your views and feelings, because they don't matter to me personally and I don't expect them to matter to Garmin as such, but I don't see that as belittling. It doesn't make me feel less of a person (or an IT professional, for that matter) just because others don't care unduly when I have no leverage and they're not trying to get something out of me.

The Computer and Electrical engineer in me says that computers do what they are told.

With that I agree. However, you cannot see what the watch is told by the application to do, when you don't have access to the source code. (Me neither; that goes without saying.)

I should be able to isolate this problem to a specific cause.

If you're talking about triggers, yes, perhaps. In my experience with computer systems and application code, sometimes the triggers of a symptom are far removed from the root cause of a problem or vice versa, e.g. heat-damaged CPU that ‘randomly’ fails upon no particular operation or instruction, and memory corruption caused by software defects that doesn't manifest in a crash until hours or days later. Of course, I would guess that alarms not firing is likely to be caused by something more straightforward than that, but I wouldn't say that you “should be able to” diagnose the problem or isolate the triggers, because to me that would be belittling when you've said you couldn't do so. I don't think less of anyone – including Garmin's technical staff – for not being able to reproduce the problem or isolate the triggers.

Well let me tell you that I have tried just about everything and this problem is anything but reproducible. You have a nice little check list you built but I'll tell you this.

I tested with:
⋮

Personally I'd be inclined to try to be reductive and limit the number of variables, but only change the other parameters to validate a hypothesis – when I've arrived at one – by trying to disprove it.

Now, ascii256 has replied to me and claimed that he/she was looking at the watch at 5:10AM when the alarm definitely failed to go off. I'm more than happy to take his/her word for it, no worries. So my hypothesis is now disproven, and it's time for a new hypothesis if I care to put in the time and effort.

Should I feel offended or belittled that my hypothesis is disproven, or that I was openly disagreed with sans any sugar-coating, or that someone may replied with a perceived aggressive tone (irrespective of whether they perceive me as being aggressive or belittling towards them in the first place)? Well, in any case, I don't. I just do what I do, and have no reason to let someone else's views or feelings sway me from my approach.

If there's one thing I've learned about this issue however it's that whatever it is, it has proven to be very random under every condition I've tested it under with no indication that it can be reliably reproduced. From that view point, I don't ever expect Garmin to diagnose this issue unless they stumble upon it out of dumb luck.

So, would you say it is appropriate for Garmin to advise it is unable to reproduce the problem, and refrain from admitting that there is actually a problem with the watch and/or in the application code?

So, would you say it is appropriate for Garmin to advise it is unable to reproduce the problem, and refrain from admitting that there is actually a problem with the watch and/or in the application code?

Did I ever state it was inappropriate for Garmin to advise such or did I simply state that Garmin would continue to do exactly that?

One cannot diagnose a problem he/she/it cannot observe or prove to exist.

A big reason why I do not escalate the issue.

Should I feel offended or belittled that my hypothesis is disproven, or that I was openly disagreed with sans any sugar-coating, or that someone may replied with a perceived aggressive tone (irrespective of whether they perceive me as being aggressive or belittling towards them in the first place)?

Absolutely not. You quoted me five times in your original response. The first three times involved taking simplistic and true statements and inferring from them enough to lecture on Garmins principles and how I could better help them. The fourth time you said my position was ridiculous when in fact my statement was again true. Garmins tests aren't robust enough to find this issue. In verifying their own code they should be conducting randomized testing. Whether that's a team of humans doing that or automated randomized testing, the fact is it's not robust enough to catch this issue. The last time you took something that by my own admission was a complete guess and simply said "I don't think so" based on what? Some knowledge you have as to the operation of alarm states? Or simply my lack of any concrete supporting data? It was a guess.


If you want to keep this to the facts that's great. I agree with much of what you say actually. I find the delivery a bit questionable.

My 5 a.m. weekday alarm failed to go off this morning. I've had this happen once before, so I continue to set my alarm clock to wake me in the morning.
I was awake and alert as my 235 went past 5:00 a.m. without going off.