Hacker News new | ask | show | jobs
by brandon 5657 days ago
That's putting a lot of stock into the device itself.

Conjecture: I think it's more likely that the device is something of an accelerometer paired with a bluetooth radio that can nearly continuously feed the phone/app with movement data so that the app can decide whether or not to rouse you.

Rationale: The algorithm. Assuming they want to tweak their actigraphy parameters, if the algorithm is running on the wristband you're going to need to drop new firmware on the device. Field-flashing embedded devices is to be avoided at all reasonable costs.

1 comments

Field-flashing isn't that bad as long as it can safely be done over bluetooth, and I'd be willing to take that risk to have reasonable battery life.
So, again, I don't know anything about the device in question, so this is all conjecture... but:

Even given that OTA flashing is possible, why bother? The device has no means of waking the user without a phone in bluetooth range, so what's the upshot? I don't know that battery life falls into that category because the device would need some pretty serious upgrades, and cost would obviously increase:

- More RAM. Lots more. Enough to contain an entire firmware image during OTA and an entire night of sleep/movement history.

- More MIPS. Actigraphy isn't going to be as cheap as store-and-forward.

- A reliable RTC so that the device can ping the phone at the right wakeup time.

- etc.

If I was in their position, I'd build the device to be as dumb a peripheral as possible. Push the complexity out of expensive hardware and into software. I'd also probably have built in a sweet inductive charging pad, too, but I'm a sucker for shiny things.