Update (6/19, 10:28am):

The SSL certificate issues seem to have been resolved. Everything is working again. Note, I reserve the right to screw it up again as I keep tinkering :)

---

Just a quick note that I am adjusting some of the TrendWeight server settings. As a result, you may get an SSL error from your browser saying that the name of ther server does not match the name of the web site. Example error dialog boxes are below (these are only a couple examples, your specific browser may look different). This is a benign error and should be resolved soon. You can safely ignore these errors.

I’ll post again when things are back to normal. Sorry for the inconvenience.

So, a TrendWeight user contacted me this week to let me know he was getting an error about the FitBit website not working. It happened right after he loaded 10 years worth of historical data into FitBit and changed his TrendWeight start date to a date in 2013. At the same time that the email from this user arrived in my inbox, I also received an automated email from FitBit telling me that a user had exceeded the API request limits and had been temporarily blocked for 1 hour. Oops.

There are two “rules” that FitBit enforces on their API that are the heart of this problem:

• No single request for data can retrieve more than 1 month of data at a time.
• No single user can make more than 150 requests in a single hour (or they get blocked temporarily).

Add in that the API requires separate requests for weight and body fat data. Now, let’s do the math on how many requests are required to load 10 years worth of data:

10 years * 12 months/year * 2 requests/month = 240 requests

So, 240 requests are needed to load 10 years worth of data, but FitBit blocks requests after 150. What it boils down it is that, current, it is not possible to tell TrendWeight to use a start date 10 years in the past.

I have looked more carefully at the FitBit API and there are basically two options that I can think of to resolve this:

Option 1: I could create a queuing system so that when you need to load 10 years worth of data, it doesn’t do it all right away. Instead it would do a few years, wait and hour, do another few years, wait an hour, etc, until all the data was loaded.

Option 2: I could use a different API for “old” data. FitBit has an alternate API that allows me to request up to 3 years of weight or body fat data in a single request. The catch is that they only return a single data point per day. If you weight yourself multiple times in a single day, the FitBit API appears to return the last weight of the day. This is different than what TrendWeight does right now. Currently, if you weigh yourself multiple times in a single day, TrendWeight uses the first weight of the day because if you weigh yourself right after you wake up, the weight readings tend to be more consistent. My approach would probably be to use the existing API for any data in the past 12 months and to use the less-precise bulk API for data older than 1 year.

Neither option is really very good, in my opinion. Option 1 is a pain for users. I wouldn’t want to have to wait several hours just to see my data. This delay would happen not only when you first setup your account, but it happens any time TrendWeight has to do a full resync: when you change your start date, when you change your time zone, when you change your weight units, when you click the ‘Resync All Data’ button.

Option 2 is a little better because it means you can get all your data pretty much instantaneously, but it isn’t perfect either. The biggest issue would be that your weight for any given day might subtly change after 1 year. For example, let’s say I weigh myself today (June 8, 2013) in the morning and weigh 220 lbs. Then I weigh myself in the evening after a large meal and weigh 224 lbs. For the next few months, TrendWeight will use 220 lbs as my scale reading for the day. However, if I need to do a resync 13 months from now, TrendWeight will suddenly start using 224 lbs as my scale reading for June 8, 2013.

In the grand scheme of things, maybe this doesn’t matter all that much. It won’t affect the trend weight calculations for July 2014 because the trend weight math is generally unaffected by weight readings older than 20 days or so. Mostly, the graph will have a slightly different shape than it did before if I happen to look back in time at that older-than-one-year data.

My inclination is to go ahead and program Option 2 because having approximately correct old data is better than not having old data at all, but what do you guys think? Would Option 1’s queuing system be better even if it meant that you you have to wait an hour or two to see your data anytime TrendWeight decides it needs to do a full resync?

I admit it. I have been a closet Bitcoin geek for more than two years. Yes, the unfinished portion of my basement is full of GPUs running at full bore 24/7. My wife used to be annoyed by the noise, but that was when Bitcoins were worth $5 each. Now, she asks if we should add more. :)

Anyway, my interactions with Butterfly Labs started in January, 2012 when I ordered two BFL Single FPGA miners from them. And then I waited. And waited. But after a frustratingly long time, my FPGA miners actually arrived, and even better, worked (and have kept working for more than a year).

Fast forward to June, 2012. Butterfly Labs announces they are going to develop and sell the BFL SC Single, an ASIC miner for Bitcoin that will hash at almost 100x the speed of a typical GPU for about the same amount of electricity. Has to be a scam, right? Then they announce that they are going to let current FPGA owners trade up to an ASIC miner and get full credit for the price they paid for their FPGA miner. Oh, and they will also be developing and selling a tiny little USB miner called the Jalapeno for about $150 that will double as a coffee cup warmer. For whatever reason, I decided to place an order to upgrade my two FPGA miners, and what the heck, I ordered one Jalapeno miner also for the fun of it.

I placed my order on the afternoon of June 23, 2012. My order numbers were 1662 and 1666.

And then the waiting. And waiting. I should have learned my lesson with the FPGAs, right?

Imagine my surprise when, two weeks ago, I arrive home to find a notice on my door that the postman had tried to deliver a package from Butterfly Labs that required a signature. You’d think I would have received an email ahead of time letting me know that it had shipped. Nah.

I had heard of a few others getting their Jalapenos. I assumed, then, that this package contained my Jalapeno, and the next day I confirmed my suspicions were correct.

The packaging was decent (you can find unboxing videos on YouTube), and the device was easy to setup. I had already compiled a version of cgminer with support for the Jalapeno and so all I really had to do was plug my Jalapeno in to USB and power and start up the miner. Sadly, my package did not include a PCIx power adapter (as some of the early development units apparently did) and so I am powering mine with the standard power brick.

It’s been running non-stop without any problems now for two weeks. Here are the relevant statistics:

• Hashrate: 5.59 GH/s
• Reject Rate (using stratum/btcguild): 0.57%
• Hardware Error Rate (yay, cgminer): 0.00038%
• Power Usage (while mining): 43.6 watts
• Power Usage (while idle): 29.6 watts

Of special note is the fact that my Jalapeno seems to use more power that most other reports I’ve read from others who have received their early Jalapeno. There seems to be some variation in power usage with early units, but most others were around 30 watts while mine is at 43.6 watts. Interestingly, my idle power usage is 29.6 watts which is also higher than the reports I have seen from others.

I’m not at all sure what the difference is, nor am I going to complain (too much). In the two weeks I have had it, the Jalapeno has earned more than enough BTC to cover the $150 I paid for it. Yes, I paid for it in BTC, but I used BTC that I had purchased that weekend for the purpose, so I choose not to dwell on what would have happened if I bought the BTC and just held on to it until today.

Now, I guess it is time to return to waiting for my BFL SC Singles. Maybe this time, I’ll get a shipment notification in advance so that I know to have someone at the house to sign for the packages…

Obligatory pictures…

It’s been a while since I posted about TrendWeight and wanted to give you a quick update of what’s been happening and what’s on my todo list…

It’s been a busy winter with my primary focus, outside of my day job, has been on staying healthy. As such, I haven’t gotten much done with TrendWeight in a few months. That said, I am probably going to spend a little time doing some work on it in the next month or two and here’s what’s on tap:

Arrows for Lean Mass

Right now, the arrow shown when you are gaining lean mass is red and the arrow for losing lean mass is green. This is backwards of what most people expect, so I’ll be flipping the color scheme when in lean mass mode.

Data Export

I’ll be adding a way to download your data from TrendWeight as a CSV file that can be opened in Excel or any other spreadsheet to do your own analysis or to make your own charts.

Actually, this functionality is already there, but not publicized. If you visit https://trendweight.com/export/ you’ll get a CSV version of your TrendWeight data including Scale and Trend values for total weight as well as fat %, fat mass, and lean mass.

That said, I’ll be adding a button to do this data download to the TrendWeight web site so that it is easier to find in the future.

Account Management

Finally, I’ll be adding a couple minor features: a way to change your email address and a way to completely delete your account if don’t want it anymore. Mostly I am adding these features to reduce the time I spend manually doing these things when people email me asking for help.

Then What?

Well, I’m not sure. There certainly have been many suggestions. Some are significant changes (or additions) to the site. Others are probably doable in a single weekend. But before I decide what I want to do next, I thought it would be interesting to get your feedback. To that end, I created a UserVoice site for TrendWeight where you can add your own suggestions and vote on suggestions that others have already made:

http://support.trendweight.com

I pre-populated the site with most of the suggestions I have received by email over the past few months, but feel free to add your own if you have an idea that is not already there.

Remember that this is a free-time project for me and so I make no promises about when any suggestion from that site will get done. But when I do have some time to work on TrendWeight, I’d just assume spend time working on the things that users want the most.

I just noticed that there is another WiFi scale on the market from iHealth. In fact, it may have been on the market for a while. Actually, they have two scales: a low cost bluetooth only, weight-only scale and a $110 wifi + bluetooth scale that does weight and various other measurements like body fat.

Does anyone have one of these scales? Do you like it?

They appear to have an open API similar to FitBit and Withings and so I could add support to TrendWeight for these devices. I can do the programming with just their API documentation, but I don’t have one of their scales to test with.

If you have one of these scales and would like to help me try it with TrendWeight, let me know by emailing me at support@trendweight.com.