libfitbit compatible with "Fitbit One"?

[gyhor]

The Fitbit One uses bluetooth 4.0 for the communication. Is it enough to get bluetooth 4.0 working in linux for using the Fitbit One?
Or does it use a completly different protocoll?

[qdot]

So I was curious about which radios are in the FB1. On their page, they show bluetooth to phones, "Wireless sync" to desktop. Is it possibly they're running two radios?

(Obviously since I'm asking this question, I don't have one :) )

[gyhor]

you get a bluetooth dongle for your computer. So i think the device has only a bluetooth connectivity.

[qdot]

Well crap. Good thing I know bluetooth now. :(

Will see about picking one up soon and starting work on this.,

On Wed, Nov 28, 2012 at 9:05 AM, gyhor [email protected] wrote:

you get a bluetooth dongle for your computer. So i think the device has
only a bluetooth connectivity.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/46#issuecomment-10810910.

[jonobacon]

Hey qdot,

I have a Fitbit One - is there anything I can do to capture bluetooth traffic to help you get a better understanding of how the device works. I did try to 'hcitool scan' for the device, but I didn't seething appear. I also scanned with blueman and see nothing.

I am not sure how to get more data that might be useful - I did post to http://askubuntu.com/questions/227393/how-to-get-data-from-a-bluetooth-device-that-is-not-visible to see if anyone can advise. Thanks!

[qdot]

Bluetooth doesn't work the same way as USB. Dumping logs might be a bit premature if the new fitbit conforms to HDP (health device profile) and we could discern things from the spec.

That said, reading and implementing yet another bluetooth spec is absolutely nowhere on my list of things I feel like doing with my spare time at the moment (I just finished helping implement bluetooth on FirefoxOS). If someone else wants to pick this up and run with it, be my guest.

[benallard]

So they stopped supporting the ANT protocol ?

Just out of curiosity, how do you reload the device then ?

[qdot]

Yeah, I think it's just bluetooth only now? Makes sense, cell phone manufacturers weren't really picking up ANT radios, which is what they're concerned with...

[n8willis]

Shouldn't be too hard to test if the device is using HDP; BlueZ supports the profile. There's a Python test tool called HDPy: http://gitorious.org/hdpy

[qdot]

Well if someone wants to dump the SDP records, we could just read the service UUIDs and go from there. I still don't have one. :)

[simcop2387]

It's possible that it's all over bluetooth, however the dongle that comes with the FB one reports itself as an HID device to the kernel. I haven't been able to contact it over bluetooth myself yet so I can't confirm anything of that nature yet.

[trtg]

If that's true, I have a hardware USB scanner I could use to sniff the traffic between the dongle and a windows machine.... it's just hard to justify getting another fitbit since I have the old ultra.

[n8willis]

Seems a little odd ... there is a HID-over-GATT (ie, LE) profile, but BlueZ only added support for it in 5.0 -- in Dec 2012. I'd think it might be a misidentification.

[simcop2387]

This is for the USB dongle itself, not the device over bluez (I haven't had any success at getting it to talk over bluetooth, it's apparently only supporting the iphone 5, and ipad 3 and the like that way at the moment).

Here's what it looks like in windows. I've attempted to get a sync captured with wireshark since I've got it working in an XP VM but I'm not sure I'm getting the proper data. Any advice on doing usb capture?

[theorbtwo]

The fitbit one itself may or may not be a bluetooth HID device, but the "bluetooth dongle" that comes with it doesn't show up over usb as being a bluetooth dongle at all -- rather, it shows as a hid device. I did, however, open up my dongle; it is a Texas Instruments cc2540 (http://www.ti.com/product/cc2540) plus a very little bit of supporting electronics.
lsusb -vvv output for the dongle is at http://pastie.org/5713106

[qdot]

Huh. Was just talking to someone about that a couple of days ago, wondering if they'd gone with a dual band chip. Guess they did. Wonder why they're keeping ANT on as well as bluetooth le though.

So, ok, there's a chance the ANT stuff (and therefore libfitbit in its current state) /could/ still work on desktop, though I'm betting some of the initialization stuff has changed.

[tornewuff]

It's possible (likely?) that the HID device is how the bluetooth dongle shows up by default. Lots of generic bluetooth dongles appear as two HID devices to do dumb keyboard and mouse emulation for non-bluetooth-aware OSes (and BIOSes and the like), and rely on being kicked in a certain special way to disable the HID interfaces and enable the HCI interface: see the manpages for hid2hci and similar tools.

[scotte]

I hope I'm wrong, but I suspect that all fitbits now are using BT and ANT has been deprecated. I just bought a "zip", and have been unable to get libfitbit to work. The USB device is 2687:fb01 just like the "one". See dmesg and lsusb output here if it helps: https://gist.github.com/4565123

[n8willis]

It's possible that the ANT chip is there so that one adapter can still sync multiple generations of tracker, even if the newer model trackers are BT only.

[iluetkeb]

I just did a capture of the USB data that was sent during the registration and synchronization process between the Fitbut USB dongle and a Fitbit One. Anybody interested in having a look at it?

[benallard]

Sure,

Would you mind putting it on a pastebin somewhere ?

On 19 jan. 2013, at 13:50, Ingo Lütkebohle [email protected] wrote:

I just did a capture of the USB data that was sent during the registration and synchronization process between the Fitbut USB dongle and a Fitbit One. Anybody interested in having a look at it?

—
Reply to this email directly or view it on GitHub.

[iluetkeb]

Okay. The setup is here http://pastebin.com/xVNFJuRn and the sync is http://pastebin.com/KZS2inpq

[ghost]

If anyone gets the Fitbit Zip working with Libfitbit let me know :) 👍

[kelnos]

I just gave hid2hci a try (using each of the 3 supported methods) and it failed each time. It shows up as 2 different hidraw devices, tried on both. Also tried on (what I assume is) the root device "hiddev0", but that didn't do anything either.

[thre3eye]

Hey, this ain't about connectivity but since many crafty folks are playing with the Fitbit One here I thought I might ask... I picked up a used One and it doesn't have the charger. Can I just charge it with 5V on the electrodes? Does anyone have a volt meter and charging cable and could quickly measure if it just passes through the USB 5V? Thanks!

[simcop2387]

I'll check when I get home but that's what I'd assume. I'll get you the
polarity too.

On Thu, Mar 28, 2013 at 12:26 PM, enalposi [email protected] wrote:

Hey, this ain't about connectivity but since many crafty folks are playing
with the Fitbit One here I thought I might ask... I picked up a used One
and it doesn't have the charger. Can I just charge it with 5V on the
electrodes? Does anyone have a volt meter and charging cable and could
quickly measure if it just passes through the USB 5V? Thanks!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/46#issuecomment-15609192
.

[thre3eye]

@simcop2387 Thanks man, you rock.

[simcop2387]

5V directly, negative on the left side of the device looking from the
back. So hold the device with the screen facing away from you and the
pads down then the negative pole is on the left.

On 03/28/2013 02:05 PM, enalposi wrote:

@simcop2387 https://github.com/simcop2387 Thanks man, you rock.

—
Reply to this email directly or view it on GitHub
#46 (comment).

[thre3eye]

@simcop2387 Thank you very much! I still have to concoct a holder to maintain the contact for a while but it definitely didn't fry the device after an initial 30 sec test :-)

[thre3eye]

Ok, this actually worked and its charged now - see pic :)
The One is also recognized by my PC and connecting on Bluetooth without any fuss and shows in Device Manager (Windows 8 here...). But the rotten FitBit app seems to demand the FitBit dongle and refuses to pair.

[Hofi2010]

If the FB1 has a TI cc2540 radio/processor than this is a Bluetooth Low Energy setup, which makes sense. So you cannot directly connect from your PC to this type of connection you need a dongle which comes with the FB1 as described above. If you have an iPhone 4S or later you can download the TI SensorTag App from iTunes and should be able to connect with the FB1. You can download the complete source code of this App from the TI website, just search in google for "TI SensorTag". I also wrote an iPhone app connecting this processor and accelerometer https://itunes.apple.com/us/app/weight-training-genie/id650541393?mt=8, this app is designed for weight training and I would be interested to also utilize the FB1 as it is much nicer than the SensorTag which is a prototyping platform. It should already connect to the sensortag. The ANT connection will no longer work with the FB1, this is a completely different technology. On the other hand the iPhone radio would probably be able to from a frequency perspective they all use 2.4 GHz, but you would need to alter the bluetooth stack and the BTServer. You cannot not do this easily even on a jailbroken iPhone. Interestingly the current bluetooth stack on the iPhone has some special code in for the Nike+ sensor that makes the proprietary Nike+ protocol based on NRF24L01 (so not bluetooth in anyway) available as a bluetooth device in iOS, so it should be possible to do the same with ANT.But for FB1 don;t waste your time it will not work with ANT.

[benallard]

I wrote this script to analyse the logs from galileo.

I use it this way:

copy past the interesting bit from the log, ad call the script with analysedyump.py < log.txt

https://gist.github.com/benallard/7163277

[emnullfuenf]

I tried your script with a Fitbit Flex megadump and got this error:

m$ python analysedump.py < megadump.txt
Greetings: '??R??????C'
Cheering
'#?F?7+VB3?'
'?3?`?v;'
'W?c]:????'
66 04 6A 12 AF A6 82 EE F2 E0 2E 8B
Traceback (most recent call last):
File "analysedump.py", line 153, in
main()
File "analysedump.py", line 124, in main
assert(data[index:index+4] == [0xc0, 0xdb, 0xdc, 0xdd])
AssertionError

[benallard]

Then it looks like our dumps are quite different. Mine is from a Fitbit One, starts with "2602", and is not ciphered.

On 26 Oct 2013, at 19:46, emnullfuenf [email protected] wrote:

I tried your script with a Fitbit Flex megadump and got this error:

m$ python analysedump.py < megadump.txt
Greetings: '??R??????C'
Cheering
'#?F?7+VB3?'
'?3?`?v;'
'W?c]:????'
66 04 6A 12 AF A6 82 EE F2 E0 2E 8B
Traceback (most recent call last):
File "analysedump.py", line 153, in
main()
File "analysedump.py", line 124, in main
assert(data[index:index+4] == [0xc0, 0xdb, 0xdc, 0xdd])
AssertionError

—
Reply to this email directly or view it on GitHub.

[emnullfuenf]

Interesting. Fitbit Flex starts with "2802":
2802000001005C0100009ED92A2D1407
D10665459340705A319EDEA6774F4C45
...

[ghost]

I just received my Force two days ago and have started digging in a little.
The megadumps from the Force also begin with "2802":
2802000001002600000051C2BE2D1908
F92AFD3260716D8BE4D9195C035C1BB5

[benallard]

Thanks to everyone over there, I was able to write a script to synchronise my fitbit under linux.

I didn't found a way to get the USB traces on my mac, so I had to extensively study the documentation from @sansneural, and the trace from @iluetkeb. Special thanks to you both !

The script is there: https://bitbucket.org/benallard/galileo/src/tip/galileo.py

It works for me, I download the megadump from the tracker to the fitbit server, and upload the response to the tracker back.

To be completely honest, it sometimes fails (the server complains about "INVALID_TRACKER_DATA"). I think it could be due to some conversion issue in the data format (list of integer to string to base64 string). When this happen, the next time might work just fine.

Try it, and tell me if you found some issues !

[gyhor]

Hi Benallard,
thanks for your script.
unfortunately i don't get it syncing. I tried it the last 4 days and the server always complains about INVALID_TRACKER_DATA
I have a fitbit one and ubuntu 12.04

My megadump starts always with "26 02 00"

[benallard]

I'm sorry to read that as I have yet to understand what is causing this issue ...

At first, I thought about an encoding error, but it looks like the original Galileo daemon is using the same kind of base64 encoding (the original one with + and /). So my best guess at the moment is that I should do some kind of processing (sometimes) on the dump of the tracker before being able to upload to to the Fitbit server. But as I can't read the USB trace from my original Galileo daemon, I'm guessing by far.

As a matter of fact, I did not get the error once this week, making it even more difficult for me to dig into it ... As I said, retrying (immediately or some hours later, it did not matter) solved it for me in most of the cases.

Thanks for trying !

On 28 Nov 2013, at 12:17, gyhor [email protected] wrote:

Hi Benallard,
thanks for your script.
unfortunatly i don't get it syncing. I tried it the last 4 days and the server always complains about INVALID_TRACKER_DATA
I have a fitbit one and ubuntu 12.04

—
Reply to this email directly or view it on GitHub.

[vincemarsters]

Thanks benallard. I have it working although I have found I am getting errors (below) if I try and sync again quite quickly after a successful sync. I need to 'play' a little more to see if I can find out any requirements I need to satisfy to stop this and will post back if I find anything. To me it looks like there is a problem establishing a link to the tracker so I wonder if there is a timeout built in that needs to reset itself. If it helps I am using Ubuntu 13.10 x64 and a Fitbit Flex.

<-- 20 01 GAP_LINK_ESTABLISHED_EVENT
<-- 02 07 00 (30 times)
--> 03 08 01
Traceback (most recent call last):
File "galileo.py", line 391, in
main()
File "galileo.py", line 362, in main
fitbit.enableTxPipe()
File "galileo.py", line 203, in enableTxPipe
self.dongle.data_read(5000)
File "galileo.py", line 128, in data_read
raise TimeoutError
main.TimeoutError

[n5rgn]

@ benallard

I'm very pleased that you were able to create a working megadump/upload/download/minidump script working and I'm glad that the info I provided helped.

I am remiss in that I have logs of many complete transactions (timestamps on each) that I could have easily zipped up and shared to the community. I will do that soon, because it sounds like some of the comms timing built into the products may need to be followed in client-side solutions.

From my scant inspection of the logs: FitbitConnect application checks often (every 2 minutes, maybe less? don't have the logs in front of me) for a tracker. If my tracker connects, it says "no, I've updated recently" or (change of one or two bits in the reply) "yes, it's been at least 15 minutes, I'll send an update". So a tracker will connect and reply to base station requests any time (at least within whatever minute interval the base station software uses) but will refuse a dump request until ~15 minutes after the last dump, regardless of what data it may have gathered during that interval.

I do not know how the tracker may respond if the base station attempts to start a megadump after the tracker says "no, I've done that already" because the FitbitConnect application never forces a megadump if the tracker says it's up to date.

[benallard]

I've made few small progress, and so far those are no good news ...

I tend to believe that the data downloaded from the tracker is not 1:1 the one that should be sent to the server : definitively, the bigger the dump, the bigger the chance to get the INVALID_TRACKER_DATA error. If I synchronise every half hour / hour, it almost always go fine. If I let the data accumulate itself in the tracker, and after few days try to synchronise again, the chance is big that I will get trouble (and never recover unless I use the original galileo again). This should point at some transmission errors, but so far I have yet to see the original galileo ask for another dump because of corrupted data.

Three possibilities:

• There are indeed communication errors, and I should correct the dump on the fly during download (think auto-correcting protocol), which seems overkill for such an application
• There is a mandatory post-processing before uploading the dump to the server, but sometime, this post-processing doesn't need to perform anything (as it sometimes work in my case). This is quite risky as we've seen there are at least two kind of dumps: clear and encrypted.
• By tweaking some parameters during the communication, I could setup the link so that what the tracker send is exactly what I should upload to the fitbit server. There I need to understand every single byte I send and receive from the tracker during connection establishment.

It would help to be able to compare the USB communication with the network communication performed by the original galileo, and see if there are differences.

[n5rgn]

I have collected quite a few full-transfer logs with FitbitConnect (galileo?) that I could share with you, if that would help.

[killua99]

I'm trying to use my fitbit one with ubuntu precise but is quite imposible I also try some vm with Win7 but without success any clue how I can see the fitbit base on my Win7 ?

[benallard]

I've got a good news ! I believe I just fixed the most annoying issue about the INVALID_TRACKER_DATA trouble. For the interested people, the fix is there: https://bitbucket.org/benallard/galileo/commits/c43395913ee49542ec01e8b2a5cced97ef6ed28c#Lgalileo.pyT71

Some special patterns have to be replaced in the dump between the download (from the tracker) and the upload (to the server) of the dump. I honesty don't believed that I caught all the magic dark patterns, so there might still be issues, but in my case, it is now running 100%.

Please report if this is also the case for you.

code is still here: https://bitbucket.org/benallard/galileo

[benallard]

Ok, I got it, the protocol used is "SLIP", which, according to Wikipedia : "SLIP is also currently used in the BlueCore Serial Protocol for communication between Bluetooth modules and host computers.[1]", which also explain those black magic with DB, DD, C0, ... And might even with its CSLIP variant help us decipher the "enciphered" dumps.

[mithro]

Thanks for all your work trying to decode the FitBit One protocol! Do you have any idea if the Force / Flex use the same protocol? I'd be happy to send some data dumps if that would help.

Would you be interested in working on these devices if someone was to donate you one?

[hickinbottoms]

Just another note of success -- with benallard's tool (bitbucket.org repo) I'm successfully syncing my One. I've now got it running as a background job on my Raspberry Pi running a flavour of Debian.

I had to update some of the timeouts in the script -- not sure whether that's just due to the slowness of the Pi or not.

Many thanks for all the hard work -- very much appreciated.

[benallard]

@hickinbottoms, @mitro: Thanks for the nice words!

@hickinbottoms: Feel free to share your tweaking on the timeout values, as they could benefit others. I am pretty sure there is some improvement to be done in this area, and I wouldn't blame your raspberry too quickly on this one.

@mithro: I do think they all use a similar protocol, as I've been able to spot similarities between the One and the Zip (If those both one are not completely different, chances are big that other ones are not very different either.).

[killua99]

Where I can send my log? Because it's looks like galileo it's not working well for me. Done sudo service udev restart and done ... it's working! awesome guys you're awesome! :D

[benallard]

@killua99: I'm sorry to hear that you're having troubles with it, If you think it's not working, best you can do is open a new issue on the related bug tracker and explain there what makes you think that it's not working.

[killua99]

I'll take a look to that bug tracker.

Now galileo looks like is working I can sync and so ... but need to sometime unplug and plug the USBthing to work.

[rysaunders]

@hickinbottoms - care to share how you've gotten the Raspberry Pi running this as a background job? May be a trivial question, but I'd love to replicate that functionality myself.

[hickinbottoms]

@itchytag -- I'll look into that but at the moment it's not working too well. I get lots of timeout errors so it doesn't successfully complete very often. I thought it might be a matter of just increasing the timeouts but that doesn't seem to be enough to make it work as the comms seems to stall and never restart.

As for basically getting the galileo.py script running on the pi that was pretty simple on a raspan-based system -- from memory I think I just had to install python-usb and it would run as-is, timeouts aside.

[benallard]

Maybe it would make sense not to try a megadump if the power of the signal is too weak, sort of like the original galileo does ...

On 14 Jan 2014, at 01:37, Stuart Hickinbottom [email protected] wrote:

@itchytag -- I'll look into that but at the moment it's not working too well. I get lots of timeout errors so it doesn't successfully complete very often. I thought it might be a matter of just increasing the timeouts but that doesn't seem to be enough to make it work as the comms seems to stall and never restart.

As for basically getting the galileo.py script running on the pi that was pretty simple on a raspan-based system -- from memory I think I just had to install python-usb and it would run as-is, timeouts aside.

—
Reply to this email directly or view it on GitHub.

[oprs]

Hey there, thanks for the impressive work.

Sorry if this particular piece of information was posted before (I came across this project just a few hours ago), but I just realized that I might very well have run galileo.py before my FitBit One was even registered with FitBit Connect (but after I walked back from work with it).

So fwiw, here's a megadump from what I believe to be a brand new device. As it's not been clogged with multiple synchronization cycles yet, maybe it will help shed some light on some of the remaining dark spots: http://pastebin.com/iiHSpjNC

Oh, and here's another one from my friend's too: http://pastebin.com/pkMsBfZT (different device but also a new FitBit One, this one was dumped ~3mn later).

[jonobacon]

On an Ubuntu 14.04 system I am trying to install galileo and I get this:

jono@forge:~$ pip install galileo
Downloading/unpacking galileo
Downloading galileo-0.3.1.tar.gz
Running setup.py egg_info for package galileo

Requirement already satisfied (use --upgrade to upgrade): requests in /usr/lib/python2.7/dist-packages (from galileo)
Downloading/unpacking pyusb (from galileo)
Could not find a version that satisfies the requirement pyusb (from galileo) (from versions: 1.0.0a2, 1.0.0a2, 1.0.0a3, 1.0.0a3, 1.0.0b1)
Cleaning up...
No distributions matching the version for pyusb (from galileo)
Storing complete log in /home/jono/.pip/pip.log
jono@forge:~$

[benallard]

Just created issue49 with this information. Let's continue the discussion there ...

[mrquincle]

I've been trying to get grips on the fitbit at https://github.com/mrquincle/fitbit-fatbat, but the encryption is a too tough nut to crack for me. What are potential ways to get it? According to https://www.ifixit.com/Teardown/Fitbit+One+Teardown/19889 there is a nRF8001 BLE chip on-board, but probably the encryption/decryption is done on the STMicroelectronics STM32L 151 ARM. It seems the STM32L151 can be read through the stlink programmer (see https://github.com/texane/stlink). This has a Cortex M3. There is quite some work out there to disassemble (IDA, Disarm, GNU), as well as decompile (desquirr). Anyone willing to get the firmware? 🍻

[moyix]

One thing that may possibly help others trying to reverse engineer this: if you edit /Library/Preferences/galileo_config.xml and add the line

<encryptLogs value="false" />

Detailed traces will be written to /var/log/com.fitbit.galileo.logs. Here's an example of one of these logs.

It's hard for me to tell at this point whether the communications shown are with the dongle or the actual tracker, or where the encryption/decryption is done...