undefined | Better HN

0 pointsKMag5y ago0 comments

The GP is complaining about the phone -> server -> phone data path of the wearable -> phone -> server -> phone workflow for generating a nice graph. Presumably they think uploading the data to the server should be optional for backup/social purposes and not a part of just viewing the collected data.

0 comments

chaostheory5y ago

Yes, I understand that and I've given some of the reasons why.

Another reason is that the alternative of syncing your device with a computer doesn't work with most of the population. They either aren't familiar with tech enough or they don't own a computer. The rest get annoyed with the lack of convenience vs automatically uploading everything via your phone's bluetooth

csours5y ago

Exactly. And even if it does eventually get uploaded, I might be using my devices not in a data connected area. It's just a lazy architecture.

Edit, may not be entirely laziness: see this response to my question - https://news.ycombinator.com/item?id=25787066

KMagOP5y ago

As I remember, my FitBit HR holds less than 10 days' worth of heartbeat data, and can't be uploaded to the phone without the phone having connectivity to FitBit's servers. Also, extracting large amounts of data from the FitBit tends to time out and require a full retry. On more than one occasion, I was on vacation with my wife in a foreign country and only got a local SIM card for her. This resulted in me turning off automatic sync (to avoid battery drain from all the failed attempts). This resulted in me relying on manually sync'ing my FitBit data when I had WiFi, which resulted in my forgetting. This resulted in data loss.

Also, I seem to remember long syncs timing out so many times in a row that I just had to factor-reset my FitBit HR to clear its data buffer. This happened more than once. It really needs an incremental sync.

When I got my FitBit HR, my wife was interested in using my original FitBit. I proceeded to update its firmware right before I gave it to her, but the firmware update seems to have timed out and broken the FitBit. I recovered once with a factory reset, but a second firmware update attempt bricked it.

Honestly, IoT devices need minimal firmware in non-brickable ROM that checksum the firmware in flash before jumping to the firmware in flash. If the checksum fails, then make a light blink and go into a recovery mode that implements a minimal Bluetooth or HTTP firmware update, preferably incremental, requiring minimal state, and recoverable/restartable if that minimal state gets corrupted. Back in the day, I bricked a WRT54G router by using Firefox to upload the firmware instead of Safari or I.E. (It was a known non-deterministic issue, apparently. I'm guessing a corner-case in the router's handling of chunked HTTP encoding.) Not even the trick of shorting two adjacent pins using an x-acto knife could get the recovery TFTP server to come up.

Also, during the first year warranty period, my FitBit HR died twice, presumably due to being splashed so much with salt water during dragon boat race practice. I know it says not to go swimming with it, but you should really avoid excessively splashing it with seawater. When my FitBit HR died a third time shortly after the warranty period, I gave up on FitBit for a while.

j / k navigate · click thread line to collapse