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 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.
|Bitmap ||What happened ||Anticipated|
|200ml cold in ~55s (slow)||200ml speed 1|
|200ml cold in ~55s (slow)||200ml speed 2|
|40ml cold||200ml speed 4|
|300ml cold (was not timed)||200ml speed 7|
|40ml cold (seemed faster)||Speed 4 dose |
|75ml cold (faster?)||Speed 4 dose |
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.
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:
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.
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
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?
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.
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|
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.
(Felicity? Marte? Find out!)
List all b.log entries
Return to the site index
PS: Don't try to be clever.
It's a simple substring match.
Last read at 23:54 on 2023/11/28.
© 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.