Thursday, December 20, 2012

Suunto ambit on Linux - log file

As requested in the comments of a previous post, here's a link to a comms log between the suunto and a PC. This is only part 1 of 6 of a session where waypoints are uploaded from the watch, followed by the upload of a move.

Hopefully this is useful for someone.

Thursday, December 13, 2012

suunto ambit on linux - part 4

Thought I posted a screenshot of the first reply I could get from the ambit:

The ambit replies with the firmware version "bluebird". Converting the hex to char on the ambit's reply gives:

?>]6 � Ù� �    ���0���Bluebird��������00000000�������� � �E J ãO

 Next step try to understand the protocol...

Wednesday, December 12, 2012

how to reload optware usb stick on asus oplay

Sometime ago one of my dogs decided to eat my asus o'play remote control. Without the remote the unit is pretty much useless. At the same time, I was looking for a way to have a always on machine serving 2 HD on my home network and for that I was using my linux machine but it was bugging me that I had so much power for so little needs.

So I thought that maybe I could turn the asus media player into a samba server. I'd heard that the asus was a linux machine and it's true. Not only that but root access is as easy as telnet to the machine and login with username root and no password.

So I went through the processes described here to install moservices on the machine and this way install samba. It works well and my machines on the network can all see and access the two harddisks.

The other requirement I had was to have one of the HD as the main and the other as the backup. Put everything onto HD1 and then, every day at night to a backup with rsync. Thing is rsync is not installed on the asus o'play and it does not come with moservices, so the next option was to install optware (package management for embebbed linux). Trouble is the asus o'play doesn't have enough space to install it. So I followed these instructions to get it running again. For aht's coming to work, do not follow the steps of cleaning up the USB tmp files. It worked well but there's a few things to note:

1. There's a program that loads the USD HD on the o'play. That program comes with the o'play and you either delete and replace it by your own or you are a slave of how the o'play decides to call your USB HD. For me this is not a big problem because it is enough for me to plug them in at the correct sequence for them to be available in the right sequence on samba. I.e. it doesn't matter how they get mounted on the o'play because the first disk is always going to be called disk1 on the samba share and the second is going to be called disk2 on the sahre, no matter is they are automatically mounted as /mnt/usbmounts/sdb1 or /mnt/usbmounts/sdc1 or whatever.

2. I do have a problem with reloading my optware USB stick though, because that one I need to be loaded to the same mount point other wise it will not work. So, instead of making it a persistent mount point, I'm lazy and follow this steps after each reboot (that only really happens every 3 months anyway):

a) plug the USB stick in and find out where it mounted with df:

BusyBox v1.1.3 (2010.09.07-08:50+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/root                76288     75212      1076  99% /
/dev/mtdblock/2          61440      8608     52832  14% /usr/local/etc
/dev/rd/0                   40        40         0 100% /mnt/rd
/dev/scsi/host5/bus0/target0/lun0/part1 976521568 924004192  52517376  95% /tmp/usbmounts/sdb1
/dev/scsi/host6/bus0/target0/lun0/part1 975592816 921977600  53615216  95% /tmp/usbmounts/sdf1
/dev/scsi/host8/bus0/target0/lun0/part1   7861696    180928   7281412   2% /tmp/usbmounts/sdg1

You  can see my two harddisks and the USB stick above. The HD are the image of each other so they are both used up by 95%. The optware USB stick is the last one (around 8GB with 1.8GB used up).

b) mount / as rw and a few more:

~ # mount / -o rw, remount
~ # mkdir /opt
~ # ln - s /tmp/usbmounts/sdg1 /opt

c) cd to /opt/tmp and run

/opt/tmp/ipkg-cl install uclibc-opt_0.9.28-13_mipsel.ipk
/opt/tmp/ipkg-cl install ipkg-opt_0.99.163-10_mipsel.ipk
d) Update optware to the latest version

/opt/bin/ipkg update

e) Find rsync (you may have to install it with optware)

ls -la /opt/bin

f) To make rsync backup your files from the main HD to the backup HD issue the command I spoke about on a previous post

rsync -avh --delete /path/to/main/drive /path/to/backup/drive

suunto ambit on linux part 3

Investigation is my favourite part of any project and especially the part where I start making things happen.

So on part 2 I got to check the protocol between the computer and the ambit. It's not not 100% clear how it operates. Just for fun, I decided to change the HDI program to send some of the packages that I can see my windows machine is sending to the ambit.

See below the screenshot of me sending a command I took from the windows sniffer. I don't get a response from the ambit BUT it reacts to that command because the lock icon disappears and the battery icon also disappears and turns into the little circles that indicate what ambit screen you are on. After briefly changing to the above, it goes back to the lock and battery icon.


Just for records, here's the full HDI package including my modified write to the ambit program on the hidtest folder. There's a lot of files you will not need in this package if you are running linux but I thought I'd leave exactly as I currently have it (see my first post on this series for other packages you require to be able to run this).

Suunto Ambit on Linux part 2

ok, on the windows side of things, I'm also learning quite a lot. I downloaded the usblyzer program. It's a 30 day free trial tool that does wonders. I also downloaded the free snoopy pro. It does the same thing and it's free, but the usblyzer interface is better. If I take more than 30 days with this project,I will switch to snoopy pro.

Here's a screen shot at some of the info I can get for the communication between the suunto ambit and my computer:

See the selected item. It's a packet sent to the computer (in). I still can't understand the data exhange but there are some packets that correspond to my set waypoints because they are in plain text. I'm assuming there's a request for data of a certain type, say for example waypoints and ambit replies with all the waypoints following some protocol I now need to determine.

The goal is to send a request and receive something back. I will try to send a request for battery level and see what comes back. But what (if any) is the command for battery level. I suppose that once the data exchange is complete and the watch is only connected to the computer the only major thing going on is the battery level information coming from the watch to the computer, perhaps after a request from the computer...

Another thing to note is accomplished by leaving the sniffer on while you disconnect and reconnect the watch. From this you can see the exchange of data where the manufacturer name (Suunto) is transmitted and the model number as well as the serial number. You can also see that the watch will declare what seems to be the current firmware name "Bluebird". See below:

 The last interesting thing to note is a transaction of a route I created on a recent visit to Dubai. There's an entry from the ambit back to the computer with each of the way points on the route. See below:

If only I can find out more of the structure, we will have a little more...
Note also the record ID for the device which is decimal 63 or hex 3F. This is needed because all transactions need to start with this value.

Suunto Ambit on linux

I am a suunto user. I am a linux user. I would love both to work together and there's nothing on the internet. That means I have to make my suunto ambit talk to my ubuntu.

;-) So today I spent some time looking and sniffing data on windows to try to see what was going on and eventually take some of what I learn over to linux. So I found the following:

1. suunto vendor ID: 0x1493 Product ID: 0x0010

2. After hours looking for some kind of USB to serial bridge driver, around the CP201x driver, I think that this is probably not the way to go and the suunto uses a generix HID driver. At least it seems to be recognized as such by windows and it definitely gets recognized as such on linux.

The reason why I went on looking for a CP201x driver was because I found a folder on the suunto installation files on windows that references that chip. I gave it up for now, but this may still be the way.

3. On linux, I downloaded the HID API for Linux, Mac OS X, and Windows and managed to compile and run the test program (you need the following two packages to start):

sudo apt-get install libusb-1.0-0-dev
sudo apt-get install libudev-dev

So far I go the following info on linux (note that the watch gets recognized automatically as a general HID device - type dmesg to verify after plugging in the watch to your linux machine). I edited the hditest that comes with the hdi library to point to the proper vendor ID (i.e. 0x1493) and product ID (i.e. 0x10).

So I can detect and I can open the device. I can't read or write to it yet, but I'm off to my windows computer to analyze the communication protocol. Wish me luck!