Looking for a treadmill that supports ifit workouts? Check out HealthRider:
Save $100 on HealthRider H75t Treadmill – Now On Sale at $999
Update April 1, 2009:
Tom S wrote a program that works with the newer ifit SD card machines. So cool – thanks Tom! You can download his program from Tom’s Microsoft Live site. I think this is still a work in progress. Any problems with the programs can be reported to Tom S at tes5 at aol dot com, or post them back here as a comment.
The Markster has also written a program for the newer SD card machines. Visit his website for more info:
http://mwganson.fre...low.com/workoutgensd
Other Notes:
* There are so many comments on this post that Firefox chokes and does not show them all, and you can’t post a new comment. So, use Internet Explorer until I can upgrade this blog (coming soon!). Sorry!
* There are some issues with which brand or sizes of SD cards will work. You can read through the comments (#93,#94, and #97, maybe more) on this blog to learn more about that.
Original Posting
Someone emailed me saying they have a newer Nordic Track treadmill that uses Ifit cards. He was wondering if there’s a way to create your own workouts, the way you can customize the older ifit treadmill workouts.
So, anybody out there know what’s on the newer Ifit workout cards? They are basically SD memory cards that you can plug into some of the newer Nordic Track treadmills. I was wondering if you read the card from your computer, what files are on the card? Update Jan 22, ’08: Two readers commented that mp3 audio files containing the beep codes that is on the ifit cards. I uploaded a few mp3 files here in case someone wants to test it out.
Speaking of treadmills, I did my Cheetah Fast Runervals DVD today, for the third time since I got the DVD at Christmas. It gets a bit easier each time…except for the very last set, which still leaves me feeling like I am going to puke. I think next time I will bump up my base pace to 3.5 mph, except for the last set 
The thing I like about Coach Troy’s workouts is that they are really hard; but the amount of rest he gives you is perfect so you can just barely recover before going hard again.
Here are some Nordic Track treadmills that use the IFit cards:
* Nordic Track C2155 Treadmill
* Nordic Track A2550 Treadmill
* Nordic Track C2500 Treadmill
* Nordic Track C2350 Treadmill
I had some sample XML code in my previous post, but it looks like the blog software incorporated it into the post.
It was something like:
<card>
<workout>
<play> intro.wav </play>
…
</workout>
</card>
Cool deal, Tom. I was thinking of writing something in Visual C# Express, which I just downloaded a few days ago from Microsoft. I have no experience with C# (or .NET), but I have a bit of background in C, Visual C++ 6.0 using MFC, and Java, so I figured C# wouldn’t be too hard to learn and this might be a good project for that purpose. It will take me a while to get up to speed with the language (and the .NET framework) before I can start tackling the actual project, though. This is not to mention nailing down the process of creating the binary file and other .fit files.
Just a few thoughts, if I may, on some general ideas I have about such a program and how it might be designed.
One way to design the program would be to have a module that takes a user-created text (perhaps in XML format) file and from it generates the binary (and text) .fit file(s). The GUI module could be a front end for generating the XML file, which can simply be created with a text editor in the interim while the GUI is being developed. The actual generator could be a command line console application working behind the scenes using something like:
type myscript.xml | ifitgen.exe
or maybe
ifitgen.exe /in=myscript.xml /outdir = c:\iFit
The general flow would be:
GUI Front End –> intermediate XML script file –> .fit files.
This does add some complexity to the program, but based upon admittedly limited reading I’ve done, it appears both VB and VC# support something called LINQ (new to .NET version 3.5, I think?) that makes working with XML files (and other databases) simpler. Again, my knowledge is very limited at this point, not only with C# and .NET, but also with XML.
The hierarchy of such an XML file might be something like:
0
intro.wav
2.0
3.5
…
…
Another design concern is leaving room for expanding the program to incorporate other workout equipment besides treadmills, with minimal fuss.
Anyway, these are just some general thoughts on the idea. I have a book on VC# that I plan to read and go through, taking my time creating the example applications in the book along the way, as I have spare time for it.
Hello Mark,
I just created this very small routine. It only runs for 1 minute. It starts off at 2MPH, 0% incline. At 30 seconds it increases to 2.5MPH and 2% incline. At 1 minute it stops and returns to 0% incline. Here are the hex bytes:
00 17 04 03 F9 05 09 F2 0C 01 F3 0F F1 0D 00 05
DC 12 06 22 00 D8 07 00 00 F9 08 46 B2 1C 01 E3
12 01 ED 22 02 DC 13 01 EC 2D 01 D2 14 14 00 D8
23 00 DD 24 00 DC 51 FF FB 01 B4 14 14 00 D8 5D
00 00 00 14 00 00 F7 98 15 14 00 D7 5D 00 00 1E
19 00 14 F7 61 5D 00 00 3C 00 00 00 F7 70 01 FF
I’m probably going to write a VB program to generate workouts now.
Nice job, guys. Kevin, I’d be interested in seeing your 5 minute workout files. I’m sure others would, too. Could you put them in a .zip file and post it to rapidshare.com?
Hi Kevin,
Very good work.
I think I know how byte 8 in the 0x5d blocks work.
I believe the 0x5d blocks are part of a larger group of commands that include the previous 0×60 commands.
The first 0x5d command in the file does not have a 0×60 command preceeding it, so the size of this 0x5d block is 9 bytes total.
0×100 – 0xF7 = 0×09 = 9 — 9 bytes in this block
All the 0x5d lines that have two 0×60 lines preceeding them have a 0xe5 for the 8th byte. The total number of bytes in this block would be 27 (9 bytes for a 0×60 + 9 bytes for another 0×60 + 9 bytes for the 0x5d).
0×100 – 0xe5 = 0x1b = 27 — 27 bytes in this block
The 0x5d line that has a 0xdc for the 8th byte has 3
0×60 lines preceeding it. Three 0×60′s (9 bytes each) + 9 bytes for the 0x5d is a total of 36 bytes.
0×100 – 0xdc = 0×24 = 36 — 36 bytes in this block.
I have not tried to verify this by putting just one 0×60 before a 0x5d and calculating the value of the 8th byte, but I’m going to do this today.
Here is a summary of my research on the encoding. With this information I’ve be able to hand-craft some fully functional workouts e.g., the 5 minute test workout
Since the information in this thread already discusses the general file structure (header followed by repetitive treadmill commands), I’ve written this more like a command reference. I’ve listed the command byte, the command name, and a description of the fields in the command. The byte numbering starts with byte1 being the command byte.
First two bytes in file: Command Count
Example: 00 93
1-2 total number of commands in file minus 1
5d: Adjust Treadmill command, 9 bytes
Example: 5d 00 00 3c 19 00 00 e5 69
1 5d (constant)
2 00 (constant)
3-4 time at which the treadmill settings should be changed, in seconds
5 speed x 10 (e.g., 5.3 becomes 53)
6 00 (constant)
7 incline x 10 (e.g., 5.3% becomes 53)
8 Uncertain. At time 00:00 the value is F7. For every other minute it is e5 except at 4 minutes and 16 minutes when it is dc. Substituting a dc value for an e5 value causes a failure, but changing a dc value to an e5 value seems to work in the case I tried. Any ideas on this field would be appreciated.
9 checksum
5a: Fetch wave file. Just retrieves the file, doesn’t play it. 6 bytes.
Example: 5a 02 fa fa 00 b0
1 5a (constant)
2 file number, indexes into the corresponding line in the sound index file e.g., S000023c.fit
3-5 fa fa 00 (constant)
6 checksum
See also “Play Previously Fetched Wave file”
5b: Play Previously Fetched Wave file immediately. 5 bytes.
Example: 5b ff fb 01 aa
1 5b (constant)
2-4 ff fb 01 (constant)
5 checksum
See also “Fetch wave file”
60: Play Wave file at specified time. 9 bytes.
Example: 60 00 00 35 08 fa fa 00 6f
1 60 (constant)
2 00 (constant)
3-4 start time in seconds
5 file number, indexes into the corresponding line in the sound index file e.g., S000023c.fit
6-8 fa fa 00 (constant)
9 checksum
08: Show incline on Display prior to start. 3 bytes.
Example: 08 46 b2
1 08 (constant)
2 incline x 10
3 checksum
06: Show Speed on Display prior to start. 4 bytes.
Example: 06 22 00 d8
1 06 (constant)
2 speed x 10
3 00 (constant)
4 checksum
0c: Show Time on Display prior to start. 3 bytes.
Example: 0c 14 e0
1 0c (constant)
2 time in minutes
3 checksum
51: Pause program for start button to be pressed. Omitting this starts treadmill without waiting for user input. 5 bytes.
Example: 51 ff fb 01 b4
1 51 (constant)
2-4 ff fb 01 (constant)
5 checksum
15: (uncertain) May be command to initially start treadmill movement. Changes to the 14 value caused the time clock to stop. Appears to be required. 4 bytes.
Example: 15 14 00 d7
1 15 (constant)
2-3 14 00 (constant)
4 checksum
01: End program, 2 bytes
Example: 01 ff
1 01 (constant)
2 checksum
0d (uncertain) time code. 5 bytes. Seems to be a time code that resolves to 1500 sec (25 min) – can be removed for Nordictrack A2550
Example: 0d 00 05 dc 12
1 0d (constant)
2 00 (constant)
3-4 may be time in seconds
5 checksum
The remaining command codes appear once in the file and can be removed for Nordictrack A2550 with no obvious problems.
05 09 f2
04 03 f9
0f f1
07 00 00 f9
1c 01 e3
12 01 ed
22 02 dc
13 01 ec
2d 01 d2
14 14 00 d8
23 00 dd
24 00 dc
14 14 00 d8
Tom and Mark,
Please keep the updates coming! I was trying to create a custom ifit treadmill workout for my wife and stumbled across this thread. You guys are farther along than I was and I have learned a lot catching up. I’ll be sure and post if I figure out anything that hasn’t been posted yet. Thanks!
Just an update for anyone who’s still following this:
The second byte in the file (0×93) is an indication of how many blocks of data are in the file. The blocks have various sizes and this number seems to include the header blocks. I can now remove commands and the program still works…almost.
The 0x5A commands (the ones that “play an audio now”) can be removed with no apparent change to the program. The 0×60 and 0x5d commands (the ones that “play an audio at a specific time” and “change the speed or incline at a specific time”) cannot be added or removed by simply changing the second file size byte. When you remove a 0×60 or 0x5d command and alter the second byte appropriately the program appears to start properly but runs into problems around the area where a change was made. This implies that there is some other information in the header about the 0×60 and 0x5d commands that includes their order.
I’m still working on it…
Hello Mark,
A few revelations:
What I thought were line numbers are not line numbers at all. They are the audio file listed in the S000023.fit file. If you look at the first occurance of the 0x5A you will see:
5A 01 FA FA 00 B1 5B FF FB 01 AA
I believe 0x5A simply means play an audio file now. The file it plays is indicated by the next Hex byte in the line (0×01). This means play the first audio file listed in the S000023.fit file. the 6th byte is used to make the lowest byte of the checksum 0×00.
I changed the line to read
5A 02 FA FA 00 B0 5B FF FB 01 AA
and I did not hear the two “clicks”, instead I heard the 2nd audio file play twice.
When a line begins with 0×60 it means an audio file will be played but at a specific time.
When a line begins with 0x5D it means a change in either speed or incline should be made at a specfic time. It looks like when the next to last byte of a 0x5D line is E5, only one value will be changed. When the next to the last byte is 0xDC then both the speed and incline will be changed.
I still do not understand everything about what happens when you get to the point where the start button should be pressed and I have not figured out all of the header portion, but I’m still working on this.
I think a way to figure out the value needed for that last byte (or 6th byte, whichever one we need to fix in order for the sum of bytes to have 0×00 in the lower byte) in a computer program would be as follows:
sum the bytes
find the remainder of the sum divided by 256
subtract this remainder from 256
Note that saying the low order byte of the sum = 0×00 is the same as saying the sum is evenly divisible by 256. In order to make it evenly divisible by 256 we subtract the remainder from 256 and that gives us the value we need to set what I’ve been calling the checksum byte to.
That would be easy enough to do, provided we know exactly which bytes need to be summed and which is the checksum byte for those summed bytes.
Hello Mark,
Actually, the values 111 and 052 are not the checksum, they are a value used to make the lowest byte of the checksum = 0×00.
I don’t think you can consider instruction 0×08 independant of instructions 0×06 and 0×07 because the 0x5A occurs before instruction 0×06 and you don’t see another 0x5A until before instruction 0×09. To me this means that instructions 0×06, 0×07, and 0×08 are all grouped together like this:
5A 06 FA FA 00 AC 5B FF FB 01 AA 60 00 00 1E 07 FA FA 00 87 60 00 00 35 08 FA FA 00 6F 5D 00 00 3C 19 00 00 E5 69
All these characters should be on one line…
These values are all in hex obviously. When you add them all together you get the value 0x0E00. Notice that the lowest byte of the summation is 0×00. This, I believe, is the checksum. The value 0×69 is only used to make sure that the lowest byte of the checksum ends up being 0×00. So, if you were to change the hex value 0×19 (decimal 25 for the speed) in instruction 0×08 to 0x1e (decimal 30 for the speed) then you would have added 5 to the total summation. In order for the summation to still have 0×00 in the lowest byte you would need to reduce 0×69 by 5 making it 0×64. I tried this and it worked.
Another way of saying this is to sum everything in instructions 0×06,0×07, and 0×08 except for the last byte (0×69). You get 0xD97. The next value greater than 0xD97 that has 0 in the lowest byte is 0xE00. To calculate the value of the last byte you would calculate it like this:
0xE00 – 0xD97 = 0×69
So, when you want to create a new instruction you would sum all the bytes except for the last one and then you would determine what it needs to be for the summation of the entire line to have 0×00 as the lowest byte of the summation.
I know this is confusing to explain. Hopefully this make sense.
I have not experimented with the first few lines that only cause audio to play, but it’s interesting to notice that the byte which makes the checksum 0 is not the last one in each instruction. It looks like it is the 6th byte.
I’ll keep experimenting with the instructions as time permits and post my results.
Great bit of detective work, Tom. I was wondering whether the initial values were computed by the treadmill by looking at the code strings or whether it got them from the file header, which latter seems to be the case. I wonder about the little image that gets show, the one that shows the graph of difficulty? That must be computed from the code strings I would think. Or else the graph is part of the header, too.
You mentioned you were able to modify one of the code strings (and fixing the checksum) and still the workout played normally (voice files and all). This would indicate to me that there is no global checksum for the entire file, only individual checksums for each code string.
The 00 93 pair of bytes might just be a means of identifying the file type as a binary .fit file.
It makes sense that 0x5a marks the beginning of each code string rather than the end. It explains why the final code string didn’t end in 0x5a.
I’ve been looking at the code string checksums. It appears the checksum depends on the bytes beginnging with what I was calling Byte 6, 0x5d (dec 90) and ends with the last byte in the code string (the one right before 0x5a, which we now know begins the next line). In other words, if we take my former representation of line #8:
08 fa fa 00 6f 5d 00 00 3c 19 00 00 e5 69 5a (speed = 2.5)
We should now see this line as:
5a 08 fa fa 00 6f 5d 00 00 3c 19 00 00 e5 69 (speed = 2.5)
Anyway, these 8 bytes:
5d 00 00 3c 19 00 00 e5
are used to calculate the checksum byte:
0×69
However, there is also some sort of a checksum being done for the first few bytes of the codestring, too. Compare code string lines 08 and 67 (decimal). Notice that both lines have the same checksum (105). This is because all of the attribute changes are the same (speed = 2.5, incline = 0 for both lines). The time stamp is different, but the same (00 60 compared to 04 56).
Now, look at the first few bytes of lines 8 and 67:
08 250 250 0 111 (decimal values)
67 250 250 0 052 (decimal values)
Clearly, 111-52 = 59 = 67 – 8, so 111 and 052 are both checksums, too, but how are they being calculated?
Here are a few more things I know believe I understand:
The 5A is actually the beginning of a sequence. If you sum the bytes starting with 5A up until the next occurrence of 5A the lowest byte will be 00. The last value is used to make the checksum lowest byte 00.
The header is organized into blocks. Ignore the first two bytes:
00 93
The first block has three bytes: 04 03 F9. When you sum these bytes the lowest byte is 00. The last value in each block is used to make the lowest byte of the checksum 00.
Here are the blocks (I think…):
00 93 – Does not follow the check sum rule
04 03 F9 – Don’t know what this block does
05 09 F2 – Don’t know what this block does
0C 14 E0 – 2nd value sets time initial time (20 minutes)
0F F1 – Don’t know what this block does
0D 00 05 DC 12 – Don’t know what this block does
06 22 00 D8 – 2nd value sets initial speed (3.4)
07 00 00 F9 – Don’t know what this block does
08 46 B2 – 2nd value sets initial incline (7.0)
1C 01 E3 – Don’t know what this block does
12 01 ED – Don’t know what this block does
22 02 DC – Don’t know what this block does
13 01 EC – Don’t know what this block does
2D 01 D2 – Don’t know what this block does
14 14 00 D8 – Don’t know what this block does
23 00 DD – Don’t know what this block does
24 00 DC – Don’t know what this block does
When I say the above sets the initial value, I mean the value that is displayed before you press the start button. Obviously there are some instructions that change the initial incline and speed to values other than 3.4 and 7.0 before the belt starts moving.
Remember if you change the initial time, speed, or incline, you must change the last byte in the block so the lowest byte of the sum of the block is 00 or the program will not run.
I will keep working through the file as I have time. If anybody figures anything else out please post.
I have at least part of the checksum algorithm figured out.
Each complete instruction in this file needs to end with the byte 5A. So if you look at line 0×06, 0×07, and 0×08 they actually are one complete instruction (because 0×06 and 0×07 don’t end in 5A). If you sum the bytes in this block you get E00. It turns out that the lowest byte of any complete instruction is 00. The next to the last byte in line 0×08 is 69 and this is the value you modify to insure that the sum of lines 0×06, 0×07, and 0×08 has a value with the lowest byte equal to 0.
I changed the speed in line 8 from 0×19 to 0x1e (or 2.5 to 3.0 as Markster figured out). Because I added 5 to the sum of the block I changed the value 69 to 64. When I inserted the card I could hear the audio and when the program ran the audio announced the speed was going to 2.5, but it actually went to 3.0 because of the change I made.
I think we are very close now.
Markster, nice work.
On the topic of the checksum I have an additional observation. I tried to swap the contents of instruction 0×08 and 0x0B and as I mentioned previously it did not work. This implies that there is either a checksum included in each instruction, or the checksum for the entire file is order dependant…so it won’t be a simple summation. It’s also possible that they are using a checksum within each instruciton and one for the entire file. I’ve been playing with the next to last byte of each instruction to see if I can come up with a checksum algorithm but I’ve had no success yet. In order to have more data to work with I took a look at the sample workouts for the eliptical machine and bike. This way you can look at three seperate cases for the same instruction number. It may be a wild goose chase, but I’ll work on it for a while.
Good news and bad news. First, the good news. I’ve figured out the timer bytes. Bytes 8 and 9 do work in tandem. Only, it’s not minutes and seconds, it’s just seconds. Byte 9 gives us the number of seconds and Byte 8 give us the number of seconds times 256. For example, if we wanted a code string to get executed 15 minutes into the workout, we’d have to figure out how many seconds there were in 15 minutes. 15 * 60 = 900 seconds in 15 minutes. Next, we have to divide 900 by 256 in order to come up with a value for Byte 8. The remainder would be our value for Byte 9.
900 / 256 = 3 with a remainder of 132, so Byte 8 would be 03 and Byte 9 would be 132 or 0×84.
Now, the bad news. My first attempt to modify the code seems to have broken the workout. I don’t even hear Heather saying anything at all. It seems there might be some kind of checksum in each control code after all. The checksum could be there to try to prevent somebody from doing exactly what we’re trying to do right now, or it might simply be a way to validate that the workout hasn’t been corrupted somehow. It makes sense to have a safety check to ensure the data is valid. We really wouldn’t want a corrupted file to suddenly kick us into 12 miles per hour mode unexpectedly and without warning.
The question now becomes where is the checksum located? Probably somewhere in the file header at the start of the file. I doubt if each control string has its own checksum byte(s). That would be good for us because it would probably be not as difficult to figure out the checksum if we have all those samples to work with rather than just the one checksum sample for the whole file.
There are still a few bytes to figure out, but the most important ones (speed and incline) are already in the bag. If we can figure out the timer bytes, then the others won’t matter. They won’t matter so long as they’re not checksum bytes. If a byte or set of bytes work as a checksum, we’d have to figure out how the checksum is calculated.
Moving on to Byte 10 we see that it is always either 0×19, 0x1e, 0×22, 0×14, or 0×00. Most are 0×22. I doubt if this Byte has anything to do with the timer (used as a 3rd byte, for example) because of the seemingly nonrandom values. It’s never 0×22 when there is a speed adjustment. In all cases where Byte 10 = 0×22 we are dealing with an incline adjustment, BUT we also have incline adjustments where Byte 10 does NOT equal 0×22. The 2 exceptions are where Byte 10 = 0x1e. Alas, 0x1e is also used for a speed adjustment, so I don’t think Byte 10 is necessarily telling us whether we’re doing a speed adjustment or an incline adjustment.
Byte 11 is always 0×00. Let’s ignore it for the time being and move on.
Byte 12 is VERY interesting. It seems to correlate quite nicely with the incline adjustments. Luckily for us, this sample workout moved the incline up at the beginning and then moved it back down at the end. Thus, we have 2 sets of code strings for the same incline settings — once on the way up and again on the way down the virtual hill we’re supposed to be climbing.
This is one of those cases where base 10 decimals will serve us better than base 16 hexadecimals.
08 250 250 0 111 93 0 0 060 25 0 00 229 105 90 (speed = 2.5)
11 250 250 0 047 93 0 0 120 30 0 00 229 040 90 (speed = 3.0)
14 250 250 0 240 93 0 0 180 30 0 30 229 206 90 (incline = 3.0)
18 250 250 0 178 93 0 0 240 34 0 35 220 146 90 (incline = 3.5)
21 250 250 0 112 93 0 1 044 34 0 40 229 071 90 (incline = 4.0)
25 250 250 0 050 93 0 1 104 34 0 45 229 006 90 (incline = 4.5)
29 250 250 0 240 93 0 1 164 34 0 50 229 197 90 (incline = 5.0)
33 250 250 0 176 93 0 1 224 34 0 60 229 127 90 (incline = 6.0)
36 250 250 0 112 93 0 2 028 34 0 65 229 061 90 (incline = 6.5)
39 250 250 0 049 93 0 2 088 34 0 70 229 252 90 (incline = 7.0)
42 250 250 0 243 93 0 2 148 34 0 65 229 197 90 (incline = 6.5)
45 250 250 0 179 93 0 2 208 34 0 60 229 142 90 (incline = 6.0)
48 250 250 0 116 93 0 3 012 34 0 55 229 086 90 (incline = 5.5)
52 250 250 0 053 93 0 3 072 34 0 45 229 036 90 (incline = 4.5)
56 250 250 0 243 93 0 3 132 34 0 40 229 237 90 (incline = 4.0)
61 250 250 0 178 93 0 3 192 30 0 30 220 200 90 (incline = 3.0)
64 250 250 0 116 93 0 3 252 30 0 00 229 161 90 (incline = 0.0)
67 250 250 0 052 93 0 4 056 25 0 00 229 105 90 (speed = 2.5)
70 250 250 0 244 93 0 4 116 20 0 00 229 050 90 (speed = 2.0)
73 250 250 0 180 93 0 4 176 00 0 00 229 010 90 (speed = 0)
Wow, that really spells out exactly what’s happening for speed and incline, doesn’t it? 0×22 = 34 and 3.4 is our speed for much of the workout! And, for the inclines, 70 decimal just means the incline is 7.0! Nothing could be simpler. Each of these control strings is resetting both the speed and the incline, only sometimes the new setting matches the current setting, and so Heather ignores it. I think I’m ready now to start experimenting with a few changes.
Hello everybody,
I’ve been experimenting with this too. I have been modifying the binary file and the results are not good…
You cannot simply swap lines. For instance, I basically swapped lines 08 and 0B and the program does not run properly. Something does run, but there is no audio and things are just not “right”. For instance with the un-modified file the timer sets to 20 minutes after you insert the card. Once I change anything in the file the initial time is 30 minutes…
At any rate, I think they are using a checksum of some kind. My guess is that the 2nd byte in the file (93) is the checksum and I wrote some code to try AND’ing and then XOR’ing all the bytes after the 93, but I’m not getting 93 (I tried two’s complement too).
I could be completely wrong about 93 being the checksum too…
I think we will have to figure out a the checksum algorithm so we can begin modifying a byte at a time to see the result. Until we figure out the checksum algorithm we cannot see the result of these changes.
This is an interesting puzzle, but given the infinite number of ways they could be computing a checksum, I’m not sure it’s realistic to think we’ll be able to crack it, especially since we only have one file to work with. I’ve looked at the free Eliptical and Bike files and they may yield some clue to the checksum algorithm.
My only other observation based on your work is that I think every line in the file must end with 5A. So when one of your lines did not end with 5A, I added the following line. I think multiple instructions can be grouped on one line, but it makes sense to me that they would have a standard end of line indicator (5A). When you group the lines this way you see some patterns emerge.
But, as I said before, this is all for nothing if we cannot figure out how to create a new file that will play properly.
I’ll keep checking to see how you are coming along and if I have any break through I’ll post it.
Good luck.
I haven’t tried modifying the binary file yet. I’m not sure I even know enough to begin that process. I have been examining the file a bit more, though, and I’ve discovered a few things.
Let’s call the string of bytes that perform some action (talk, speed adjust, incline adjust, etc.) a code string. In this sample binary there are [Hex] 4a code strings.
Each code string has a number of bytes, which we will call byte 1, byte 2, etc. Byte 1 is the first byte in the code string. This byte is the one that always gets incremented in the next code string. For example, the first code string has byte 1 = 1, the second has byte 1 = 2, the third code string the file has byte 1 = 3, and so on.
Byte 2 always = Hex fa. Byte 3 always = Hex fa. Byte 4 always = 0. Byte 5 is, well, I haven’t figured that one out yet.
Byte 6 is interesting. It is always either Hex 5b, Hex 5d, or Hex 60. (From here on I’ll refer to Hex values as 0x5d, 0×60, etc. If it’s not preceded by 0x, then the value is a decimal value and not a hexadecimal value.) It seems to be indicative of the number of bytes in the code string. That, or perhaps it is indicative somehow of the type of code string we are dealing with, which might amount to the same thing.
The code strings can be either 9, 11, 14, or 15 bytes in length, with the exception of the last code string, which is 12 bytes long and with the exception of the 4th code string, which is 33 bytes long. For all of the code strings of length 9, Byte 6 = 0×60. For all code strings of length 14, 15, 33, or 12 Byte 6 = 0x5b. For all code strings of length 15 Byte 6 = 0x5d.
The vast majority of code strings that do something other than play a talk file, the length of the code string is 15. There are a few exceptions, but most of the interesting code strings are 15 bytes long and have Byte 6 = 0x5d. What’s more, all of the 15 byte code strings perform an interesting function (not just talk) and all of these 15 byte code strings end in Byte 15 = 0x5a.
I think, therefore, the 15 byte code strings are the most interesting ones to study. If we can map what each byte is used for, then we might be able to crack the code. 15 bytes might seem like a lot, but we already know the purposes of Bytes 1, 2, 3, and 4. These are always NN, 0xfa, 0xfa, 0×00 (where NN is the sequential number of the code string as it appears in the binary file). Also, we know byte 6 is always going to be 0x5d for these 15 byte code strings. Furthermore, Byte 7 = 0×00 in all cases where Byte 6 = 0x5d. And, we know that Byte 15 = 0x5a in all cases.
More on Byte 7. Byte 7 can be 0×00 or 0xff and nothing else, regardless of the length of the code string, and it’s always 0×00 when Byte 6 = 0x5d. Perhaps Bytes 6 and 7 are being used in tandem to represent the code string length or type. In either case, sense it’s always 0×00, we can ignore it for now.
Byte 8 is another interesting byte. It’s values are either 0×00, 0×01, 0×02, 0×03, or 0×4. (It can also be 0xfb, but only for code strings of lengths other than 15.) The really interesting thing about Byte 8 is it’s values are slowly incrementing as we get further into the workout. I strongly suspect that Byte 8 relates to the timer. It could be the upper (more significant) byte in a 2-byte timer. If this is the case, Byte 9, the next byte, would be the likely candidate for the lower (less significant) timer byte.
Here is a listing of all of the 15-byte length code strings:
08 fa fa 00 6f 5d 00 00 3c 19 00 00 e5 69 5a (speed = 2.5)
0b fa fa 00 2f 5d 00 00 78 1e 00 00 e5 28 5a (speed = 3.0)
0e fa fa 00 f0 5d 00 00 b4 1e 00 1e e5 ce 5a (incline = 3)
12 fa fa 00 b2 5d 00 00 f0 22 00 23 dc 92 5a (incline = 3.5)
15 fa fa 00 70 5d 00 01 2c 22 00 28 e5 47 5a (incline = 4)
19 fa fa 00 32 5d 00 01 68 22 00 2d e5 06 5a (incline = 4.5)
1d fa fa 00 f0 5d 00 01 a4 22 00 32 e5 c5 5a (incline = 5)
21 fa fa 00 b0 5d 00 01 e0 22 00 3c e5 7f 5a (incline = 6)
24 fa fa 00 70 5d 00 02 1c 22 00 41 e5 3d 5a (incline = 6.5)
27 fa fa 00 31 5d 00 02 58 22 00 46 e5 fc 5a (incline = 7)
2a fa fa 00 f3 5d 00 02 94 22 00 41 e5 c5 5a (incline = 6.5)
2d fa fa 00 b3 5d 00 02 d0 22 00 3c e5 8e 5a (incline = 6)
30 fa fa 00 74 5d 00 03 0c 22 00 37 e5 56 5a (incline = 5.5)
34 fa fa 00 35 5d 00 03 48 22 00 2d e5 24 5a (incline = 4.5)
38 fa fa 00 f3 5d 00 03 84 22 00 28 e5 ed 5a (incline = 4)
40 fa fa 00 74 5d 00 03 fc 1e 00 00 e5 a1 5a (incline = 0)
43 fa fa 00 34 5d 00 04 38 19 00 00 e5 69 5a (speed = 2.5)
46 fa fa 00 f4 5d 00 04 74 14 00 00 e5 32 5a (speed = 2)
49 fa fa 00 b4 5d 00 04 b0 00 00 00 e5 0a 5a (stop treadmill)
Notice how Bytes 8 and 9, when viewed as a pair, are in ever slowly increasing succession. That is, the pair in one code string is always smaller than the pair in the next code string. This is to be expected if this Byte Pair is being used as the timer. I suspect it works something like this: You multiply Byte 8 by some number representing the minutes that have elapsed from the beginning of the workout and you multiply Byte 9 by some number representing the seconds since the beginning of the workout. Add those 2 products together to get the mile marker where this code string gets executed. Someone have to go through the workout and make a note of exactly when these code strings get executed in order for us to try to figure out the exact formula in use. Volunteers?
Let me go ahead and submit this comment before moving on to some of the next Bytes.
Good idea, Ed H. It would be a bummer if the file contained some kind of a checksum.
Nice Work! Have you tried removing or rearranging some of the lines to see if it keeps working as expected?
I wonder what the clicking sound is? Maybe resetting incline to zero?
Error correction. The line where (speed = 4) is listed above should be (speed = 3).
Okay, I’ve put together a text file with all the presumed code strings and what is happening during the workout (talk, change speed, etc.)
01 fa fa 00 b1 5b ff fb 01 aa 5a (does nothing? makes clicking sound)
02 fa fa 00 b0 5b ff fb 01 aa 5a (talk)
03 fa fa 00 af 5b ff fb 01 aa 5a (talk)
04 fa fa 00 ae 5b ff fb 01 aa 51 ff fb 01 b4 14 14 00 d8 5d 00 00 00 14 00 00 f7 98 15 14 00 d7 5a (are you ready? press start button)
05 fa fa 00 ad 5b ff fb 01 aa 5a (speed = 2.0)
06 fa fa 00 ac 5b ff fb 01 aa 60 00 00 1e (talk)
07 fa fa 00 87 60 00 00 35 (talk)
08 fa fa 00 6f 5d 00 00 3c 19 00 00 e5 69 5a (speed = 2.5)
09 fa fa 00 a9 5b ff fb 01 aa 60 00 00 5a (talk)
0a fa fa 00 48 60 00 00 72 (talk)
0b fa fa 00 2f 5d 00 00 78 1e 00 00 e5 28 5a (speed = 3.0)
0c fa fa 00 a6 5b ff fb 01 aa 60 00 00 96 (talk)
0d fa fa 00 09 60 00 00 ae (talk)
0e fa fa 00 f0 5d 00 00 b4 1e 00 1e e5 ce 5a (incline = 3)
0f fa fa 00 a3 5b ff fb 01 aa 60 00 00 d2 (talk)
10 fa fa 00 ca 60 00 00 e3 (talk)
11 fa fa 00 b8 60 00 00 e8 (speed = 3.4)
12 fa fa 00 b2 5d 00 00 f0 22 00 23 dc 92 5a (incline = 3.5)
13 fa fa 00 9f 5b ff fb 01 aa 60 00 01 0e (talk)
14 fa fa 00 89 60 00 01 26 (talk)
15 fa fa 00 70 5d 00 01 2c 22 00 28 e5 47 5a (incline = 4)
16 fa fa 00 9c 5b ff fb 01 aa 5a (talk)
17 fa fa 00 9b 5b ff fb 01 aa 60 00 01 4a (talk)
18 fa fa 00 49 60 00 01 60 (talk)
19 fa fa 00 32 5d 00 01 68 22 00 2d e5 06 5a (incline = 4.5)
1a fa fa 00 98 5b ff fb 01 aa 5a (talk)
1b fa fa 00 97 5b ff fb 01 aa 60 00 01 86 (talk)
1c fa fa 00 09 60 00 01 9e (talk)
1d fa fa 00 f0 5d 00 01 a4 22 00 32 e5 c5 5a (incline = 5)
1e fa fa 00 94 5b ff fb 01 aa 5a (talk)
1f fa fa 00 93 5b ff fb 01 aa 60 00 01 c2 (talk)
20 fa fa 00 c9 60 00 01 da (talk)
21 fa fa 00 b0 5d 00 01 e0 22 00 3c e5 7f 5a (incline = 6)
22 fa fa 00 90 5b ff fb 01 aa 60 00 01 fe (talk)
23 fa fa 00 8a 60 00 02 16 (talk)
24 fa fa 00 70 5d 00 02 1c 22 00 41 e5 3d 5a (incline = 6.5)
25 fa fa 00 8d 5b ff fb 01 aa 60 00 02 3a (talk)
26 fa fa 00 4a 60 00 02 52 (talk)
27 fa fa 00 31 5d 00 02 58 22 00 46 e5 fc 5a (incline = 7)
28 fa fa 00 8a 5b ff fb 01 aa 60 00 02 76 (talk)
29 fa fa 00 0b 60 00 02 8d (talk)
2a fa fa 00 f3 5d 00 02 94 22 00 41 e5 c5 5a (incline = 6.5)
2b fa fa 00 87 5b ff fb 01 aa 60 00 02 b2 (talk)
2c fa fa 00 cc 60 00 02 ca (talk)
2d fa fa 00 b3 5d 00 02 d0 22 00 3c e5 8e 5a (incline = 6)
2e fa fa 00 84 5b ff fb 01 aa 60 00 02 ee (talk)
2f fa fa 00 8d 60 00 03 05 (talk)
30 fa fa 00 74 5d 00 03 0c 22 00 37 e5 56 5a (incline = 5.5)
31 fa fa 00 81 5b ff fb 01 aa 5a (talk)
32 fa fa 00 80 5b ff fb 01 aa 60 00 03 2a (talk)
33 fa fa 00 4c 60 00 03 40 (talk)
34 fa fa 00 35 5d 00 03 48 22 00 2d e5 24 5a (incline = 4.5)
35 fa fa 00 7d 5b ff fb 01 aa 5a (talk)
36 fa fa 00 7c 5b ff fb 01 aa 60 00 03 66 (talk)
37 fa fa 00 0c 60 00 03 7e (talk)
38 fa fa 00 f3 5d 00 03 84 22 00 28 e5 ed 5a (incline = 4)
39 fa fa 00 79 5b ff fb 01 aa 5a (talk)
3a fa fa 00 78 5b ff fb 01 aa 60 00 03 a2 (talk)
3b fa fa 00 cc 60 00 03 b5 (talk)
3c fa fa 00 b8 60 00 03 ba (speed = 4)
3d fa fa 00 b2 5d 00 03 c0 1e 00 1e dc c8 5a (incline = 3)
3e fa fa 00 74 5b ff fb 01 aa 60 00 03 de (talk)
3f fa fa 00 8c 60 00 03 f5 (talk)
40 fa fa 00 74 5d 00 03 fc 1e 00 00 e5 a1 5a (incline = 0)
41 fa fa 00 71 5b ff fb 01 aa 60 00 04 1a (talk)
42 fa fa 00 4c 60 00 04 31 (talk)
43 fa fa 00 34 5d 00 04 38 19 00 00 e5 69 5a (speed = 2.5)
44 fa fa 00 6e 5b ff fb 01 aa 60 00 04 56 (talk)
45 fa fa 00 0d 60 00 04 6e (talk)
46 fa fa 00 f4 5d 00 04 74 14 00 00 e5 32 5a (speed = 2)
47 fa fa 00 6b 5b ff fb 01 aa 60 00 04 92 (talk)
48 fa fa 00 ce 60 00 04 ab (talk)
49 fa fa 00 b4 5d 00 04 b0 00 00 00 e5 0a 5a (stop treadmill)
4a fa fa 00 68 5b ff fb 01 aa 01 ff (talk)
The following is the header that goes at the beginning of the file:
00 93 04 03 f9 05 09 f2 0c 14 e0 0f f1 0d 00 05 dc 12 06 22 00 d8 07 00 00 f9 08 46 b2 1c 01 e3 12 01 ed 22 02 dc 13 01 ec 2d 01 d2 14 14 00 d8 23 00 dd 24 00 dc 5a
and what a journey it will be, bring the aleve or tylenol pm cause i forsee many headaches
Well we are certainlystarting to get somewhere with this. Even if we have a long way to go, at least the journey has officially begun…
Also here’s an ascii code table, it actually helps understand some of the hex controls, http://www.interfacebus.com/ASCII_Table.html
Also opening the w000023c.fit file in a ascii notepad program u see the actual hex characters such as Nul Acks Sync commands
LOL just got finished going through sequences myself in a playlist lol here goes
********,*****
00000E0Q,***** blank
000005P6,***** talk
00000HW2,***** week 1 day one
000003L4,***** ready press start
00000E61,***** spd 2 mph
000003Y3,***** talk
000005OT,***** talk
00000F2X,***** spd 2.5 mph
0000047W,***** talk
000004KM,***** talk
00000E9J,***** spd 3.0 mph
000008T0,***** talk
000008RC,***** incline 3%
0000040Y,***** talk
00000E95,***** spd 3.4
00000FWX,***** incline 3.5%
000003US,***** talk
000005EN,***** talk
00000E7V,***** inc 4%
00000435,***** talk
000003P5,***** talk
00000131,***** talk
00000FZC,***** incl 4.5%
000003AU,***** talk
00000G1D,***** talk
000001AF,***** drink water
000008Q1,***** incl 5%
000003W2,***** talk
000003JN,***** talk
000008O5,***** incl 6%
00000421,***** talk
00000H0S,***** incl 6.5
00000G2O,***** talk gonna increase intensity
00000EC5,***** incl 7%
000003ZW,***** talk
000003YS,***** talk
00000G1N,***** incline goes down
000008T2,***** talk
000003RT,***** drink water
000008NA,***** incl 6%
00000418,***** talk
000005DR,***** talk
00000G1R,***** Incl will now decrease
0000042S,***** talk
00000G1F,***** talk
000003ZO,***** talk
00000FCG,***** incl decrease 4.5%
00000G1A,***** talk
000005B8,***** talk
00000G20,***** incl will now come down
000005D7,***** talk
00000G1C,***** talk
0000015X,***** talk
000008Q9,***** spd 3mph
000008P2,***** Lowering incline 3%
000003XI,***** talk
000003NQ,***** talk
0000045I,***** advertising
0000040U,***** talk
00000F7U,***** spd 2.5mph
000005OR,***** advertising
000003HJ,***** pace yourself
00000F85,***** spd 2.0 mph
000003HE,***** talk
000003DX,***** talk
000003O0,***** stopping tread
000001AM,***** we will see u next time
********,*****
I’m happy to spend some time hacking this as well.
Not sure if it is relevent, but there are other free downloads (for other machine types) at the link above. Doing diffs on the control file may show a pattern. I’ll try to look tonight.
I made a playlist for Windows Media Player 10, which is the version I have installed on my PC. The playlist contains all the .wav files in the sequence they appear in the s000023c.fit file. There are 74 (dec 74 = hex 4a) files in the playlist, which corresponds exactly to the number of control sequences in the binary .fit file and to the number of .wav files in the Tread folder.
Some control codes tell the treadmill to play a .wav file, but other control codes tell it not only to play the next file, but also to make some adjustment to either the incline or to the speed or to stop altogether. Each line of code must also contain a code for the time for it to be invoked, probably the number of seconds from the beginning of the workout. The short lines of control codes are probably the ones that only play the .wav files. The longer ones will both play a .wav file and do some adjustment to speed or incline.
My next step will be to create a text file with all the control code sequences on a line each, similar to what I did in my previous post for the first 12 code strings. Then I will play through the playlist and make a notation on each line showing what was done for that code (i.e. played .wav, changed incline, changed speed, stopped treadmill). That will be a project for another day.
I don’t understand why this is top secret. I would think they would want everyone to be out there creating workouts making their ifit program more popular.
Aww man this is crazy, got a headache going over hex codes, tryna sort out what’s controlling the treadmill, and what’s calling a wave file,ok there are 69 calls or really 67 specific wave files, so there has to be a call function that shows at least 67 times throughout s000023c.fit Maybe i need to actually run through the workout, and note specific changes and actions, then that may make things easier. Wish we had another ifit program that we can decipher at the same time. And even if we can totally decipher what the calls are, they may use some strange hex strings that make the actual adjustments on the treamill.
They really screwed up by going to this card system. It was sop much better when you could put a PDA on your treadmill, have it connected to your home network through WiFi, and drop audio files (or videos) onto it that you either bought or created yourself.
I’m thinking the s000023c.fit file just plays the .wav files, which don’t appear to contain any control codes like what were used in the earlier models. I had to try 3 different SD cards before I could get one that would work with my Reebok S 9.80 treadmill. The one that finally did work was a Kodak 512MB card. The w000023c.fit file is probably where the control action is. This is probably the file that actually manipulates the treadmill, such as adjusting the incline, speed, etc.
Looking at w000023c.fit in a hex editor, you will see that certain hex values tend to repeat. In particular, xx fa fa 00 (where xx is a value that increments each time a new string of xx fa fa 00 is encountered) appears over and over. I’m thinking this series of values acts as the delimiter in between the actual control codes, which vary in length.
To see what I mean, here are the first 12 strings of control codes in the w000023c.fit file:
01 fa fa 00 b1 5b ff fb 01 aa 5a
02 fa fa 00 b0 5b ff fb 01 aa 5a
03 fa fa 00 af 5b ff fb 01 aa 5a
04 fa fa 00 ae 5b ff fb 01 aa 51 ff fb 01 b4 14 14 00 d8 5d 00 00 00 14 00 00 f7 98 15 14 00 d7 5a
05 fa fa 00 ad 5b ff fb 01 aa 5a
06 fa fa 00 ac 5b ff fb 01 aa 60 00 00 1e
07 fa fa 00 87 60 00 00 35
08 fa fa 00 6f 5d 00 00 3c 19 00 00 e5 69 5a
09 fa fa 00 a9 5b ff fb 01 aa 60 00 00 5a
0a fa fa 00 48 60 00 00 72
0b fa fa 00 2f 5d 00 00 78 1e 00 00 e5 28 5a
0c fa fa 00 a6 5b ff fb 01 aa 60 00 00 96
Notice how most, but not all, control strings end in 5a. It could mean that 5a is also part of the delimiter, the thing that separates one set of control codes from the next, but I have my doubts on that. What does seem clear, however, is that xx fa fa 00 tells the treadmill that this is where the xxth control code begins (or maybe ends). By collating what happens in the workout in sequence (e.g. setting speed to 3.0 mph) with the hex values for that operation, and then experimenting with different hex values, it might be possible to figure out how the control strings work. Why couldn’t they have just made it a simple text file? Each line could be as follows: time=00:05:00, play=00001.wav, speed=5.0, incline=2.5; [sigh]
looking for ifit cards for mp3 player my treadmill only uses the ifit program with mp3 player
Oh no, Does anyone in here work with hexediting? Seems out of the 3 non audio (wav) files, 1 is created in hex coding, the other two seem to be more or less a layout of the routine from start to finish, such as 000003o0,***** is the last entry in s000023c.fit file, which corresponds and calls the last wave to be played which says “see you next time”. The layout.fit file seems to just invoke the s000023c and the w000023c. Oh boy…
I’ve been page hoping today hoping that i can somehow create my own custom workouts for my C2400 Nordi Treadmill. And BAM! there just may be hope, so eventhough the ifit demo that came with it is unreadable obviously the dataflash (demo) and sd are almost one and the same. <Cracks Knuckles) something in them files is controlling the treadmill, I’m sure they moved on from Audio chirps to digital “chirps” or signals read from the card to push people to buy the ifit cards and not be able to outsmart them this time with embedding the chirps yourself. It’s a money thing
as if we havent payed enough… But there is hope, i’ll spend a day seeing what i can come up with from that download. And also sidenote, With the dataflash(ifit) cards and sd cards being of the same “species” of beasts, it may be possible to read the cards someway, somehow.
No, it is just a beginner / sample iFit workout
So does that download let you create your own workouts, or what does it do?
The iFit site has a free download that can be copied to a standard SD card and run. I just confirmed it works on my NordicTrac Commercial ZS with an iFit card slot.
Download is here:
http://www.ifit.com/workouts/downloads/
The program contains 67 standard .Wav files and 3 files with .Fit exts. 2 of the .fit are text files, one looks to be binary they are under 2kb each.
The .Wav files do not play any beep codes that I hear when playing them from a PC.
I always thought the beeps were simple audio cues to let you know that either the pace or incline was changing, nothing more.
Here’s the latest info I received from one of my blog readers…
I’ve spoken to the tech support people and it’s bad news on the Ifit workout cards. Although they look the same they aren’t SD cards they’re DataFlash cards.
The card contains a control programme rather than audio chirps so unless someone fancies getting stuck in and reverse engineering the binaries it looks like DIY workouts are a no go.
I’ve just given it a go and no joy.
Plug in the card, the blue light comes on and then a couple of seconds later it beeps at me and the light goes off.
I was going to ring the NordicTrack people tomorrow anyway so I’ll ask about the card and file format required. I’m fairly sure the slip of paper that came with the demo card said the workouts could be customized but I won’t hold my breath.
What if you put that 10K Interval mp3 file on n SD card? Do you think it would respond to it then?
I’ve got a NordicTrack C2000 that used the SD cards. As others have said I have tried reading the SD card on my PC but they are not recognised.
I’ve tried playing back the 10K Interval mp3 through the jack socket but it does nothing in response to the chirps.
Has anyone tried putting an older ifit mp3 workout on a SD card and trying it?
The ifit demo card that came with my treadmill isn’t readable either. It doesn’t even get recognized by my computer card slot/explorer. I assume it’s the copyprotection.
I was hoping to edit the workouts or create my own…
Chris – Thanks for taking the time to try reading one of the Nordic SD cards. Excellent point about the copyright protection! …Carol
I tried reading an iFit card from my NordicTrack and it is unreadable. It makes sense though, Secure Digital (SD) cards have a copyright protection which makes it hard to copy files off the SD card if it has content on it.
I believe they have the same functionality as the older models. Not positive but almost.
I was under the impression that the newer ifit cards were the same as the older ifit videos/audio files- only they are stored on an SD card instead of a disk/VHS. I could be wrong about that though…