Rick's b.log - 2022/12/29
It is the 21st of November 2024 You are 3.145.33.230, pleased to meet you!

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

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 2-of-5 barcode.

Sadly, the encoding used is not the same.

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

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)
       ------
      Quantity

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)
       ------
      Quantity

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.

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.

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
   \--/
   here?

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
    \--/
   here?

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.

Um...

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:

Rob, 29th December 2022, 17:15

I heartily support your dedication to this task!

David Pilling, 30th December 2022, 04:18

https://reverseengineering.stackexchange.com/questions/3919/reve 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.