mailto: blog -at- heyrick -dot- eu

You are not reading my b.log using HTTPS. You can switch to HTTPS by clicking here.

Tassimo hacking - one step forward and one step back...

Turns out that the service guide didn't help that much. You see, the example barcode in the service guide is an EAN-13 style barcode, looking like this:
Example EAN13 barcode
Example EAN-13 barcode.

First up, this is complete crap. Actual T-Discs don't use EAN-13. As you can see, the above encodes 7680415570362. EAN-13 barcodes encode thirteen numbers (there's no A-F), thus the largest number 9,999,999,999,999 is 10010001100001001110011100101001111111111111 (if I copied it correctly).

There are actually two barcodes on many Tassimo T-Discs, a UPC_E code near the little lip part (presumably for older machines), and a smaller ITF 2-of-5 90 degrees offset (for the newer machines).
The 2-of-5 barcode looks like this:

Example 2of5 barcode
Example 2-of-5 barcode.

Sadly, the encoding used is not the same.

Which means my speed and size tests... failed.

Test results
Bitmap What happened Anticipated
0000110011000100200ml cold in ~55s (slow)200ml speed 1
0001010011000100200ml cold in ~55s (slow)200ml speed 2
001001001100010040ml cold200ml speed 4
0011110011000100300ml cold (was not timed)200ml speed 7
001000000010010040ml cold (seemed faster)Speed 4 dose 000001
001001111110010075ml cold (faster?)Speed 4 dose 111111

Now, if we invert the bits, then the first two that appeared to be materially the same outcome would become:

00 100 011001 10 0 00    (200ml cold, slow)
00 100 011001 01 0 00    (200ml cold, slow)

The only difference here would be the precharge duration, so this could tie up with behaviour, except...

The final three results were 40ml, 300ml and 75ml respectively. So let's try that:

00 100 011001 11 1 00    ( 40ml)
00 100 111111 00 1 00    (300ml)
00 100 100000 00 1 00    ( 75ml)

Well, a value of 25 would mean 40ml, 63 would be 75ml, and 32 would be 300ml. This is gibberish.

Final suggestion. Maybe the bits are inverted? Let's try that with the 40, 75, and 300ml.

 40ml 0010010011000100 --> 1101101100111011
 75ml 0010011111100100 --> 1101100000011011
300ml 0011110011000100 --> 1100001100111011

There doesn't seem to be any clear indication of a value "growing" as one would expect for 40 to 75 to 300. It's possible that there is a predefined table of quantities which isn't necessarily in order, and what is actually given here are table entry offsets?


The next thing I tried was looking at an actual T-Disc and comparing the two barcodes.

An example T-Disc.
An example T-Disc.

On the left, the older UPC_E code 11945994.
On the right, the newer ITF 2-of-5 code 409193.

But here, we already run into problems. The UPC code, when scanned with my mobile phone, is 11945994 (which can expand to a regular UPC code of 119459000094), but generating a UPC-E code with that same value leads to this:

UPC-E barcode
UPC-E barcode.

I've tried multiple on-line barcode generators, and nothing I can do gets a matching barcode. However, looking at it in raw form, the first digit specifies the number system (0 or 1), and the last digit specifies the checksum. In between are six digits of data, 194599.
In the ITF barcode, the final digit is a checksum. The data is therefore 40919.

Let's compare:

10 1111100000100111  - UPC
   1001111111010111  - ITF

Which, also, cannot be correct. The UPC code is providing eighteen bits where sixteen are expected. There's also no obvious correspondance between the two. Possibly due to the UPC-E actually being something else that's being misread by my Android software? After all, if it's private to Tassimo, there's no requirement for the code to resemble anything.


I came across an old wiki that suggested that the values to be used were actually stuffed into 13 bits, with no mention made of what the remaining three bits might be for.

Okay, this is a last ditch attempt. Can the 300ml dose be tied up with this shorter layout in any way?

Forwards:  001 11 100 1100 01 00
Backwards: 001 00 011 0011 11 00 ...
FwdInvert: 110 00 100 0011 01 11 ...
BckInvert: 110 11 100 1100 00 11 ...
Forward2:  ... 00 111 1001 10 00 100
Backward2: ... 00 100 0110 01 11 100
Fwd2Invrt: ... 11 000 0110 01 11 011
Bck2Invrt: ... 11 011 1001 10 00 100
           |   |  |   |    |  |  |
           |   |  |   |    |  |  '- Usused?
           |   |  |   |    |  |
           |   |  |   |    |  '---- Temperature
           |   |  |   |    | 
           |   |  |   |    '------- Precharge
           |   |  |   |
           |   |  |   '------------ Amount of liquid
           |   |  |
           |   |  '---------------- Fill speed
           |   |
           |   '------------------- Purge
           '----------------------- Unused?

Okay, last ditch here. The amount for 300ml, or maximum, is supposed to be %1111. It therefore corresponds that the minimum would be %0000.

So are there four bits set for 300ml that are clear for 40ml?

0010000000100100  40ml
0011110011000100  300ml

It's actually saying %1110, so maybe there's a larger setting? Let's add in the 75ml and the 200ml, which ought to be somewhere in the middle of these values.

001 0000 000100100   40ml
001 0011 111100100   75ml
000 1010 011000100  200ml
001 1110 011000100  300ml

Alright then. Now it looks like we may (finally!) be on to something. So let's try setting all four bits. What happens then?

Answer? Well... 200ml of cold water with a discharge of steam at the end.


Now, I could believe that maybe there were only three bits used, giving a selection of seven different dose volumes, but why was the all-ones not treated as 300ml?

Clearly... <sigh> ...there's a lot more experimentation needed.


Today I'm supposed to be bagging up the rubbish (not done) and defrosting the fridge (partially done), so if you'll excuse me, I'll bring it to a close here and go do other things.



Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

Rob, 29th December 2022, 17:15
I heartily support your dedication to this task!
David Pilling, 30th December 2022, 04:18 rse-engineering-t-disk-barcodes-for-tassimo-coffee-makers 
HTH or Hope This is Not Too Irritating
Rick, 30th December 2022, 09:33
Argh! Infinite recursion! ;) 
(the final entry links to this blog) 
As the guy doing the bit twiddle tests discovered, the bits to set the amount are "non obvious", there is some sort of interaction with other parts of the encoding, so it doesn't necessarily appear that there are individual bits that can be tweaked to alter the volume, for example. 

Add a comment (v0.11) [help?] . . . try the comment feed!
Your name
Your email (optional)
Validation Are you real? Please type 56013 backwards.
Your comment
French flagSpanish flagJapanese flag
«   December 2022   »

(Felicity? Marte? Find out!)

Last 5 entries

List all b.log entries

Return to the site index



Search Rick's b.log!

PS: Don't try to be clever.
It's a simple substring match.


Last read at 01:16 on 2024/04/23.

QR code

Valid HTML 4.01 Transitional
Valid CSS
Valid RSS 2.0


© 2022 Rick Murray
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.


Have you noticed the watermarks on pictures?
Next entry - 2022/12/30
Return to top of page