Lexmark toner chip Ti046b1

[pixconfig]

I've made a pretty cool discovery :

Reading 2048 bytes of 01>00>00, then reading the following ones :

• 01>20>00  is 01>00>00 with a 32 bytes offset
• 01>40>00  is 01>00>00 with a 64 bytes offset
• 01>90>00  is 01>00>00 with a 144 bytes offset
• 01>00>06 is 01>00>00 with a 6 x 256 bytes offset
• 01>40>04 is 01>00>00 with a (4 x 256) + 64 bytes offset

Pretty logic, after all : The first byte after 01> indicates a [0 to 255 for 0x00 to 0xFF] byte offset so the following one indicates a multiple of 256 bytes offset !

[pixconfig]

EDIT : I made an error while reading back data, the reality is that I only succeeded to fill the first 1024 bytes with zeroes.

I (too much but successfully) zeroed an entire chips's eeprom by writing 2048 bytes of 0x00 to 02>00>00
It only remains "0xFB, 0x5F, 0x94, 0x54" for the last 4 bytes of the 2048 bytes buffer read


Now I should understand why some writes are successful, and why some others are not.
And I'm also able to restore back the 1024 first bytes to their initial value, but most of them were already set to 0x00

[pixconfig]

I confirm that toner cartridge that are emptied with the chip giving "0 pages left" are not fully locked

I have been able to set the 1024 first bytes to 0x00 and to read it back, then to restore the initial content.

But :

• When I restore the original, there is some differences at the beginning (32 first bytes) but I already had the problem this morning without writing anything : those 32 bytes were a series of 0x77 and 0x00 and it became just 0x00. Same here, it was a series of 0xB8 and 0x17, now it's just series of 0x00 and 0x00
• Also, when I try to write with incremental values the first 1024 bytes, there is only 336 bytes that are written : 0 to 32 is not written, 336 bytes are written and all that follow is kept to 0x00

Anyway it's still interesting to see all this
Sorry for multiple Editing, I realized that my interpretation was wrong because of some mistakes in my code !

[pixconfig]

So we are approaching the end, I'm on the verge of attempting something :

This is the 01>20>00 "register" of a brand new magenta cartridge (small capacity)

Code: [Select]

uint8_t RegisterRead_01_20_00[56] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x1F, 0x00, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x12, 0x75};
After some little magenta prints :

Code: [Select]

uint8_t RegisterRead_01_20_00[56] = {0xFF, 0x7F, 0xFF, 0xFF, 0xFF, 0x1F, 0x00, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x46, 0xBA};
Nothing else changed into the chip.
The visual indicator doesn't really show any missing bit of toner level but anyway... I would like to try applying this value to a Cyan cartridge that is pretty low, with the exclamation sign at side of it's toner level representation, just in order to see if it's the toner level... or not ! And I hope that the value I will put will not lock anything with the cartridge once into the printer.

Some more details I noticed by analyzing all the content :

The first 1024 bytes of information are completely organised that way :

• 32 bytes of strange volatile read only value repeating itself 2 by 2, that sometimes changes to 0x00 after some writes
• 56 bytes of what I believe is the toner level
• 56 bytes of what I believe is the toner level, a second time, same values - printer doesn't seems to read this field but it's into the chip
• 208 bytes of information that doesn't have changed since the cartridge is into the printer
• 6 first bytes of 01>00>04 (the 1024 bytes read only area) followed by zeros. But 16 bytes can be written and here
• After the 368 first bytes, the 656 following bytes are covered by 0x00 and seems to be read only

After the 32nd and up to the 368th byte, everything can be written by the data of your choice, and I'm not really sure of why sometimes it fails. But if you write the complete set of 1024 bytes it seems to work everytime.
When I try to observe the printer communicating with it's cartridge I only see some Writes into 0x05 EEPROM area and some exchange on 0x80/0x81/0x82 with all cartridge but impossible to guess what it does (apart from entering some kind of 0x08 or 0x09 modes, and writing random 14 bytes to get 16 random bytes in answer).

Also, I tried to read 3072 first bytes, but it does a cycle : the 1024 last bytes are the 1024 first ones.

Keep you informed !

EDIT 1 : well, it does not work  printer says that the cartridge isn't recognized. The I2C spy shows nothing abnormal. Now I will try to copy the content of another cartridge of the same reference, delivered with the printer

[pixconfig]

Suceeded 

I copied the Yellow level (~40%) of the same cartridge reference into the Cyan toner chip (was almost empty) with the following code :

Code: [Select]

uint8_t Register56[56+4] = {0x00, 0x00, 0x00, 0x00,      0xFF, 0x01, 0xFF, 0xFF, 0xFF, 0x0F, 0x0A, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xAD, 0x00, 0x00, 0xA0, 0x0D, 0x00, 0x63, 0x7F, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0xFF, 0xFF, 0x02, 0x00, 0x00, 0x04, 0xC3, 0x00, 0x00, 0x00, 0x2D, 0x87};

void playOnce()
{
  write_TI046B1_register(0x002, 0x02, 0x20, 0x00, Register56, 56);
  write_TI046B1_register(0x002, 0x02, 0x58, 0x00, Register56, 56);
 
  //Check :
  read_TI046B1_register(0x002, 0x01, 0x00, 0x00, Buffer, 512);
  read_TI046B1_register(0x002, 0x01, 0x00, 0x02, Buffer, 512);
  read_TI046B1_register(0x002, 0x01, 0x00, 0x04, Buffer, 512);
  read_TI046B1_register(0x002, 0x01, 0x00, 0x06, Buffer, 512);
}
Of course it doesn't add real toner inside the cartridge so it's just for technical comprehension of our printer, as it's written on the cartridge's box : "By opening this package you agree to use this cartridge only once" so of course I'm going to put back the real toner remaining amount into the chip, and use it only once, and I encourage you to do the same.

I would love to know what is the "full" level for this reference !
I'm gonna analyze a little bit what contains this 56 bytes buffer, may be I would be able to fully understand it.

There's still many areas of shadows about what the chip contains and does.

[pixconfig]

Hi,

Another good news for people who have "empty" cartridge with 0 pages left : it's possible to reload the chip, it's not locked (at least, not with the "starter cartridge" delivered with the printer). For this example, we successfully put the "40% left" level of the Yellow toner chip into the "0% left" magenta toner chip, and now, there is "40% magenta left" and it works.

A good idea would be to share, here, the different values of 01>20>00[56] for differents kind of cartridges, with differents levels, and to make a summary here.


Let's begin :

Magenta, 71B20M0, still not used :

Code: [Select]

uint8_t RegisterRead_01_20_00[56] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x1F, 0x00, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x12, 0x75};
Magenta, 71B20M0, after just little uses

Code: [Select]

uint8_t RegisterRead_01_20_00[56] = {0xFF, 0x7F, 0xFF, 0xFF, 0xFF, 0x1F, 0x00, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x46, 0xBA};
Magenta, 802HME High Yield (CX410 / 510), not used because not compatible with our printer :

Code: [Select]

uint8_t RegisterRead_01_20_00[56] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x1F, 0x00, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xCD, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xA6, 0xFF};
CS417, CX417 Starter Return Program : Black ~30%, Blue ~10%, Magenta 0%, Yellow ~40%)

Code: [Select]

uint8_t RegisterRead_01_20_00[56] = {0xFF, 0x00, 0xFF  1111 0xFF, 0xFF, 0x0F, 0x0A, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x11, 0x00, 0x01, 0x20, 0x13, 0x00, 0x61, 0x7F, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0xFF, 0xFF, 0x02, 0x00, 0x00, 0x05, 0x05, 0x00, 0x00, 0x00, 0x30, 0x3B};

uint8_t RegisterRead_01_20_00[56] = {0xFF, 0x00, 0x7F 0111 0xFF, 0xFF, 0x8D, 0x0A, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xEF, 0x00, 0x00, 0x60, 0x04, 0x00, 0x69, 0x7F, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x01, 0x1D, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0xFF, 0xFF, 0x03, 0x00, 0x00, 0x04, 0xC0, 0x00, 0x00, 0x00, 0x9D, 0x9B};

uint8_t RegisterRead_01_20_00[56] = {0xFF, 0x00, 0x3F  0011 0xFF, 0xFF, 0x8C, 0x0A, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x23, 0x00, 0x00, 0x40, 0x03, 0x00, 0x6D, 0x7F, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0xFF, 0xFF, 0x03, 0x00, 0x00, 0x04, 0xC4, 0x00, 0x00, 0x00, 0x67, 0x68};

uint8_t RegisterRead_01_20_00[56] = {0xFF, 0x01, 0xFF  1111 0xFF, 0xFF, 0x0F, 0x0A, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xAD, 0x00, 0x00, 0xA0, 0x0D, 0x00, 0x63, 0x7F, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0xFF, 0xFF, 0x02, 0x00, 0x00, 0x04, 0xC3, 0x00, 0x00, 0x00, 0x2D, 0x87};

Please read before doing : Of course it doesn't add real toner inside the cartridge so it's just for technical comprehension of our printer, as it's written on the cartridge's box : "By opening this package you agree to use this cartridge only once" so of course I'm going to put back the real toner remaining amount into the chip, and use it only once, and I encourage you to do the same.

[driver_x]

Hi, here's my hypothesis: toner level might be stored in the second and third bytes:

The levels might be:

Code: [Select]

  %     dec     hex
____________________
0 %     63     00 3f
10%    127     00 7f
20%    255     00 ff
30%    511     01 ff
40%    1023    03 ff
50%    2047    07 ff
60%    4095    0f ff   
70%    8191    1f ff
80%    16383   3f ff
90%    32767   7f ff
100%   65535   ff ff

Now we go to your cartridges:

Magenta, 71B20M0, still not used : bytes 2 and 3 = ff ff = 100%
Magenta, 71B20M0, after just little uses: bytes 2 and 3 = 7f ff = 90%
Magenta, 802HME High Yield (CX410 / 510), not used: bytes 2 and 3 = ff ff = 100%
Black ~30%, bytes 2 and 3 = 00 ff = 20%
Blue ~10%, bytes 2 and 3 = 00 7f = 10%
Magenta 0%, bytes 2 and 3 =00 3f = 0%
Yellow ~40%, bytes 2 and 3 = 01 ff = 30%

Bytes 15 and 16 might hold the number of printed pages or some measure of toner consumed, because it seems proportional with the filling percentage, the emptiest has the biggest value, the fullest has the smallest value. Black cartridge always has more toner than the others.
Black ~30% = 0x 0111 = 273
Blue ~10%  = 0x00ef = 239
Magenta 0% = 0x 00123 = 291
Yellow ~40% = 0x 00AD = 173

I printed a report with device statistics. What information might be stored on the cartridge:
Install date (?)
Supply level (bytes 2 and 3?)
Sides on cart (bytes 15 and 16?)
Return program Genuine(??)
Printer Liftime(??)

Try to print more pages and put here the dump and the report, maybe we can map all the bytes

[JacquesBBB]

Hi,

Another good news for people who have "empty" cartridge with 0 pages left : it's possible to reload the chip, it's not locked (at least, not with the "starter cartridge" delivered with the printer). For this example, we successfully put the "40% left" level of the Yellow toner chip into the "0% left" magenta toner chip, and now, there is "40% magenta left" and it works.

Bonjour pixconfig !

I am following your progress  with great interest.

As I understand, you have developed two way of communicating :

- intercepting the signal on the printer with a dsPIC33EP512MC502 and the associated c program

- reading and writing  to the chip with an arduino program on an atmega 2560

Which one are you using for the latest  reading and writing you mention ?
I assume it is the arduino. Can you confirm ?

What is the wiring  you used ?

Bien amicalement,

Jacques

[driver_x]

Very interesting information: https://caselaw.findlaw.com/us-6th-circuit/1211276.html

[pixconfig]

Salut JacquesBBB, and driver_x !

JacquesBBB : We are using the pin description you discovered in the first page of this topic : First one (longer) is GND, second one is SCL, 3rd one is 3.3V power supply, last one is SDA.

I would like to thank you as we probably wouldn't have done all this without all the information that was already available in this thread. I wasn't even aware about 10 bit addressing existence.


As you saw, yes, for manual read/writes we are using an Arduino (Mega2560, equipped with 8192 bytes of RAM) for directly writing/reading were we want into the chip. We used the dsPIC only as read only, with a self made program for in-situ spying of I2C communication inside the printer, with 3 wires (GND/SDA/SCL) connected on the imaging drum electronic card (that is easily removable, its just like a big toner chip with 4 slots and 1 connector).

https://image.noelshack.com/fichiers/2018/17/7/1525016623-sans-titre2.png
We firstly tried to solder some wires on the chip's contact before putting the cartridge in place, but it was a bad idea since the cartridge was unable to fully take it's place into the printer (toner leaks !)

I would like to add some detail about the wiring with Arduino 2560 :
Atmel AtMega2560 has internal pullup on the RD0 and RD1 port used for I²C, connected to 5v, that cannot be disabled for these pins on this model.

We used, both for SDA and SCL, some 18 kOhms resistor mount for reducing the voltage on the toner chip pins. With this, we have ~3.3v when the bus is high and 0v when the bus is low


driver_x :
Your hypothesis is interesting, I won't have the printer this week but I will do some more test as soon as possible. I also see that there is some others bytes changing everywhere; putting all the data into an Excel helped me to see some similar points but also a lot of questions remaining !

For the lawsuit, I saw a similar document in this thread (2nd page, https://www.eff.org/document/sixth-circuit-opinion), if I understood, it's a case where some company was duplicating a lexmark obfuscated protocol program chip by simply copying the program inside the chip instead of doing its own, which caused some copyright issue.

[driver_x]

Salut pixconfig
From the lawsuit we find interesting things (I don't know if it still applies to current cartridges, but is interesting to know):

[...]
The first program at issue is Lexmark's “Toner Loading Program,” which measures the amount of toner remaining in the cartridge based on the amount of torque (rotational force) sensed on the toner cartridge wheel.   Maggs Aff. ¶ 24, JA 709.   The Toner Loading Program relies upon eight program commands-“add,” “sub” (an abbreviation for subtract), “mul” (multiply), “pct” (take a percent), “jump,” “if,” “load,” and “exit”-to execute one of several mathematical equations that convert the torque reading into an approximation of toner level.   Goldberg Aff. ¶ 21, JA 578;  Maggs Aff. ¶ 24, JA 709.   If the torque is less than a certain threshold value, the program executes one equation to calculate the toner level, and if the torque equals or exceeds that threshold, the program executes a different equation to calculate the toner level.   Goldberg Aff. ¶ 19, JA 576-77.   The exact code of the Toner Loading Program varies slightly for each printer model, and this case involves two versions of the program-one for Lexmark's T520 and T522 printer models and another for Lexmark's T620 and T622 printer models.   The Toner Loading Program for the T520/522 printers comprises 33 program instructions and occupies 37 bytes of memory, while the Toner Loading Program for the T620/622 printers comprises 45 program commands and uses 55 bytes of memory.   To illustrate the modest size of this computer program, the phrase “Lexmark International, Inc. vs.   Static Control Components, Inc.” in ASCII format would occupy more memory than either version of the Toner Loading Program.   Burchette Aff. ¶ 13, JA 106.   The Toner Loading Program is located on a microchip contained in Lexmark's toner cartridges.
[...]
To ensure that consumers adhere to the Prebate agreement, Lexmark uses an “authentication sequence” that performs a “secret handshake” between each Lexmark printer and a microchip on each Lexmark toner cartridge.   Both the printer and the chip employ a publicly available encryption algorithm known as “Secure Hash Algorigthm-1” or “SHA-1,” which calculates a “Message Authentication Code” based on data in the microchip's memory.   If the code calculated by the microchip matches the code calculated by the printer, the printer functions normally.   If the two values do not match, the printer returns an error message and will not operate, blocking consumers from using toner cartridges that Lexmark has not authorized
[...]
The parties agree that Lexmark's printers perform a second calculation independent of the authentication sequence.   After the authentication sequence concludes, the Printer Engine Program downloads a copy of the Toner Loading Program from the toner cartridge chip onto the printer in order to measure toner levels.   Before the printer runs the Toner Loading Program, it performs a “checksum operation,” a “commonly used technique” to ensure the “integrity” of the data downloaded from the toner cartridge microchip.   D. Ct. Op. ¶ 77, at 14.   Under this operation, the printer compares the result of a calculation performed on the data bytes of the transferred copy of the Toner Loading Program with the “checksum value” located elsewhere on the toner cartridge microchip.   If the two values do not match, the printer assumes that the data was corrupted in the program download, displays an error message and ceases functioning.   If the two values do match, the printer continues to operate.
[...]

[JacquesBBB]

Salut JacquesBBB, and driver_x !

JacquesBBB : We are using the pin description you discovered in the first page of this topic : First one (longer) is GND, second one is SCL, 3rd one is 3.3V power supply, last one is SDA.

I would like to thank you as we probably wouldn't have done all this without all the information that was already available in this thread. I wasn't even aware about 10 bit addressing existence.

Thanks, Its good to know that this effort was useful.

I am trying to implement your arduino file,  but cannot find the following libraries

#include <avr/io.h>
#include <avr/interrupt.h>
#include <compat/twi.h>

where are they ?

Thanks

update : OK,  I see that if I use an AVR chip, there is no problem and the libraries are automatically loaded.

[driver_x]

Hi again,

From my cs310dn:

Code: [Select]

Cyan, high yeld few pages printed (the chip is not original, "compatible" cartridge)
uint8_t destinationBuffer[56] = {0xFF, 0x7F, 0xFF, 0xFF, 0xFF, 0x1F, 0x0, 0xFF, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0xD7, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x65, 0xDA};

Yellow, 60% (normal yeld)
uint8_t destinationBuffer[56] = {0xFF, 0x7, 0xFF, 0xFF, 0xFF, 0xF, 0x0, 0xFF, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x5B, 0x0, 0x0, 0x50, 0x10, 0x0, 0x52, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x0, 0x0, 0x0, 0xAF, 0x0, 0x0, 0x0, 0xAD, 0x27};

Magenta(starter) (10%)
uint8_t destinationBuffer[56] = {0xFF, 0x0, 0x7F, 0xFF, 0xFF, 0x8D, 0xA, 0xFF, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xEE, 0x0, 0x0, 0x20, 0xA, 0x0, 0x6D, 0x7F, 0xFF, 0x0, 0x0, 0x0, 0x0, 0x1, 0x90, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xFF, 0xFF, 0x0, 0x0, 0xFF, 0xFF, 0x3, 0x0, 0x0, 0x3, 0xB, 0x0, 0x0, 0x0, 0x4C, 0xB5};

Cyan, starter, (empty)
uint8_t destinationBuffer[56] = {0xFF, 0x0, 0x3F, 0xFF, 0xFF, 0x8C, 0xA, 0xFF, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x19, 0x0, 0x0, 0x20, 0xF, 0x0, 0x69, 0x7F, 0xFF, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xFF, 0xFF, 0x0, 0x0, 0xFF, 0xFF, 0x3, 0x0, 0x0, 0x3, 0xC, 0x0, 0x0, 0x0, 0x9A, 0x5B};

[pixconfig]

Hi folks, working back on the printer today

Figuring out that a 2 bytes sized checksum is likely to be CRC 16, and based on the work of qub1n into https://stackoverflow.com/questions/10564491/function-to-calculate-a-crc16-checksum

We successfully implemented the checksum used for 2 last bytes. Enjoy !
https://www.pixconfig.fr/Lexmark-I2C-TI046B1/QtChecksumI2C.zip

Now we are gonna modify all that we can, based of driver_x suggestions and discoveries and test what we can.

There is some last issue, after few prints, it's like if cartridge is finding back it's previous level (magenta is empty again, cyan is in "warning almost empty status" again, even with a cartridge full of toner so it's not likely to be due to a physical sensor). May be another place to modify ?

PS : JacquesBBB, in fact I included and modified (buffer sizes) twi.h without using wire.h so I place the file "twi-all-included.h" at side of the "I2C_TI046B1_Read.ino" file.

[amyk]

There is some last issue, after few prints, it's like if cartridge is finding back it's previous level (magenta is empty again, cyan is in "warning almost empty status" again, even with a cartridge full of toner so it's not likely to be due to a physical sensor). May be another place to modify ?

It might not be this exact printer/model but I remember there being mentions of printers storing the data from the last X cartridges in its own EEPROM. You should try changing the serial number since that's what it uses to detect "simple" reset attempts like these.

[pixconfig]

It will be a good idea to check this ! Il will try to print and check.

Based on some test and analysis, and a big thank you to driver_x, here is the Full toner level for starter kits cartridge

Code: [Select]

uint8_t Register56Cyan[56+4] =  {0x00, 0x00, 0x00, 0x00,    0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x1F, 0x0A, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x69, 0x7F, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xD3, 0xA2};
uint8_t Register56Mage[56+4] =  {0x00, 0x00, 0x00, 0x00,    0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x1F, 0x0A, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x6D, 0x7F, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC4, 0x90};

It based on the following analysis of the different toner chip contents listed on this forum, so you can build your own 56 bytes register depending on which kind of cartridge you are using.

Code: [Select]

Byte 1 : 0xFF everywhere

Bytes 2 and 3 : 0xFFFF is full, 0x7FFF after 2 or 3 pages, 0x003F : 0%, 0x007F : 10~20%, 0x01FF for 40%, 0x07FF for 60%,

Bytes 4 and 5 : 0xFF everywhere

Byte 6 : 0x1F for Full or almost full, 0x8C for empty, 0x8D for almost empty with warning sign, 0x0F seen for 30% 40% and 60%.

Byte 7 : 0x0A for starter kits, 0x00 for others

Bytes 8 to 14 : 0xFF then 0x00, 0x00... everywhere

Byte 15 and 16 : printed pages : 0x0000 for new

Bytes 17 18 19 20 : 0x00 for the first byte everywhere, then 0x??, 0x??, 0x?? depending on cartridge. Non proportionnal. 0x00000000 when new or almost new

Bytes 21 22 23 24 : 0x00 then 3 bytes depending on the cartridge model
back starter : 0x00 61 7F FF
cyan starter : 0x00 69 7F FF
magenta starter: 0x00 6D 7F FF
yellow starter: 0x00 63 7F FF

magenta 71B20M0 : 0x00 C0 00 00
magenta 802HME : 0x00 CD 00 00
cyan high yield for CS310dn : 0x00 D7 00 00
yellow normal yield for CS310dn : 0x00 52 00 00
don't forget to double check when you can, and add new ones when you have !

Bytes 25 26 27 28 : 0x00 00 00 00 everywhere

Bytes 29 and 30 : 0x0000 when new or >= 30%, 0x01 90 (=400) or 0x011D (=285) when warning low level. Final count down rising as approaching the end ?

Bytes 31 32 33 34 35 36 37 38 39 40 : 0x 00000... everywhere

Byte 41 and 42 : 0xFFFF for starter kits, 0x0000 if not starter kit

Byte 43 and 44 : 0x0000 everywhere

Byte 45 and 46 : 0xFFFF for starter kits, 0x0000 if not starter kit

Byte 47 : 0x00 if not used, seen at 0x01 on 2 pages printed, seen as 0x02 if >3 pages, seen at 0x03 when almost (or completely empty)

Byte 48 and 49 : 0x0000 everywhere

Byte 50 and 51 : 0x0000 = new, 0x0001 = few usage, 00AF = ~60%, 0x04C3 = ~40%, 0x0505 = ~30%, 030B and 04C0 = low,  0x04C4 and 0x030C : empty... so when level is low, it's imprevisible

Byte 52 53 54 : 0x00 00 00 everywhere

Byte 55 and 56 : CRC16 Checksum of the 54 previous bytes
So if I'm not wrong, the full level of starter black and starter yellow would be :

Code: [Select]

uint8_t Register56Black[56+4] =  {0x00, 0x00, 0x00, 0x00,    0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x1F, 0x0A, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x61, 0x7F, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFD, 0xC6};

uint8_t Register56Yellow[56+4] =  {0x00, 0x00, 0x00, 0x00,    0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x1F, 0x0A, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x63, 0x7F, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF6, 0x5F};
But it should be tested; if it does not work, then we should check the checksum or the cartridge type bytes.

Let's check if the level is changing normally when we print some big pictures ! If not, then it's probably because of what amyk describes. I will watch how the reference number of the cartridge can be changed, probably into the 208 bytes field.

[driver_x]

Hi again
I have made the same analysis with similar result.
Now, after I've read some patents (for example this: https://patentimages.storage.googleapis.com/32/30/7a/832cd3e5de56ed/US5995774.pdf ), my question is : do we have or not lockout bits (bits that, once written, cannot be modified)? Only 1 write once bit is needed to mark that the cartridge is depleted and all our work is for nothing.

[driver_x]

Now, of course the printer it's checking the toner level using it's mechanical parts (wheels, torque sensors etc) so if you write 100% toner on the chip and the printer is sensing something else, probably it will tell you that the cartridge is defective and needs to be replaced. My opinion is that first you must fill the cartridge with toner, write the new information to the chip and after this to try inserting it in the printer.

I have two new readings, for the balck cartridges:

Code: [Select]

Black starter - empty:
uint8_t destinationBuffer[56] = {0xFF, 0x0, 0x3F, 0xFF, 0xFF, 0xC, 0x0, 0xFF, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xF5, 0x0, 0x0, 0x60, 0x15, 0x0, 0x48, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x3, 0x0, 0x0, 0x3, 0x88, 0x0, 0x0, 0x0, 0x0, 0x67};

Black- High Yeld ~90%:
uint8_t destinationBuffer[56] = {0xFF, 0x1F, 0xFF, 0xFF, 0xFF, 0xF, 0x0, 0xFF, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xB0, 0x0, 0x0, 0xD0, 0xB, 0x0, 0xD1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x0, 0x0, 0x2, 0x5, 0x0, 0x0, 0x0, 0xBC, 0x15};


[pixconfig]

Hi,
In fact there is good news, even with an almost empty cartridge, the system is working fine when we put the correct 100% values, we successfully consumed some toner and had the cyan toner level slightly reduced (from 100% to 90%) after some big pictures prints.

And the 56 bytes register values of full start Black and full starter Yellow are good too :


We will probably see some missing colors soon or late into the prints, once the cartridge will be completely emptied, even when the "toner level" will be indicating some remaining amount of toner. I would not be surprised if the printer is unable to see if toner is really here or not : the only things that connects the imaging drums and cartridge to the printer are mechanical gears and I2C bus for toner chips. The laser probably "touch" the imaging drums without having to connect anything else but photons, and if there is missing toner powder, then may be nothing can see it, but our eyes once the document is printed.


The fact that, few days ago, the toner chip previous level was restored by the printer, is probably due to the fact that the "Yellow" cartridge type was copied into the others (our first try) and it was probably not a completely good idea, of course, since every cartridge has it own type bytes into the 56 bytes register (then it should probably be respected - it's what we dit yesterday and it seems better).

Also, may be the fact that the 56 bytes register is written 2 times is a way to give a second chance to read the data when it's corrupted or abnormal. Then, if it's not enough, then the printer probably keeps a local copy of those register in order to restore it (probably what happened).

And a final good thing to know, at least for starter kit : the chip was indicating "empty", "0 pages left", no print possible, and we succeeded in putting "100%" level into it.

[driver_x]

So they calculate the remaining toner only by estimating how much powder has been used based on the number of pages printed (or maybe based on how many rotations the mirror has made) I thought that the motor that is turning the cartridge's wheels had some kind of torque sensor, so in case that the number stored in the cartridge becames "corrupt", the printer to be able to estimate again the quantity of remained toner, as stated in their patent:

"The sensor S may take the form of a mechanical sensor that detects torque required to turn an auger positioned in the reservoir, an optical sensor that uses light to measure the amount of toner, or any other sensor configuration that provides feedback regarding the amount of toner remaining in the reservoir."

https://patents.google.com/patent/US7747180?oq=lexmark+toner+level

Anyway, thank you for all the hard work 

[pixconfig]

Hi everybody !

We still had some issues, sometimes, with the cartridge emptying a little bit too fast (sometimes way too fast, after less than 50 pages), even when full of toner into the cartridge.
So we tried to figure out what is into the 208 bytes register at 0x01 > 0x90

There is a 30 bytes UUID around the end of this 208 bytes register, that finishes with the famous CRC16 (the one that we are now, of course, able to check/complete). All the rest is completely fulfilled with 0x00 for a brand new cartridge.
Here is the analysis :
https://www.pixconfig.fr/Lexmark-I2C-TI046B1/208byte-analysis.ods

And after a lot of uses, we finally see some changes into this register, so it should be reset too.

We updated the Arduino code in order to auto-reset the connected cartridges, keeping the information that should be kept, and recalculating the CRC16 automatically at the end for both 56 and 208 bytes registers.

It firstly reads the content of every register before changing the values that should be changed, automatically.

Enjoy ! https://www.pixconfig.fr/Lexmark-I2C-TI046B1/Arduino/I2C_TI046B1_Reset.zip

May be at the end it would be nice to try to modify the 30 bytes UUID, but let's first try to see if it works without changing it.

[AndreiKenig]

I know exactly where to store the cartridge capacity for Lexmark MS\MX. I ask to lay out a chain of 448 bytes starting from 02_40_04 for Lexmark CS order in  to verify in the same place the capacity of the cartridge is stored in the Lexmark of the CS or not.

[pixconfig]

Hi,

Thank you much for this information ! Do you succeeded to write this area ? I didn't succeeded.
01>40>04 is located at (4x256 + 64) bytes and is read during 448 bytes, so from 1024+64 to 1536 bytes (it's like if the printer reads from 1024 to 1024+512 but without the 64 first bytes).

Did you guess some interpretation of what's inside this register ? I see there is some ASCII strings but also some binary datas and lot of "0x00".

Here is the content of a brand new chip I have :

But it's not compatible with my printer... anyway it's still interesting to watch what is inside and compare with others.


My persistent problem of today is :  the printer says my magenta cartridge reached end of life at each print.
So I finally tried to change the 30 bytes UUID inside the 02>90>00 register but after any print, it says "end of life" for the magenta cartridge, again.

No problem with the others, that's pretty strange, may be there is a real physical problem with the magenta but it is completely new and full, I just changed the chip to play a little bit and understand how those chips works, and because the original chip of this cartridge says "not compatible with this printer". I also checked if the cartridge is, physically, the same, and yes obviously. I have no more idea for the moment ! 

I guess the 12 first bytes of 01>40>04 (that contains the same barcode stuck on the cartridge sticker) should be changed too; It may have som key procedure to write this area (starting to a precise byte during a precise length for having the chip accepting the written value ?)

[Arturo2511]

hello,
from my research, the problem comes from the fact that the chip retains the number of copies made since the beginning. When the cartridge is reset to 0, that if it is 100% but the copy number remains unchanged. The printer will check if the number of copies is less than or equal to the maximum capacity of the printer. After resetting a chip with 80% remaining but the number of copies unchanged (1538 copies / 1500 max) that if automatically becomes empty after the first impressions while he had 80% of free (it went from 100% - > 0). I did not manage to dump the memory of the chip to compare the data before and after. If you had an arduino program to read the whole of the chip, I'm interested. I communicate with the chip by i2c but 10-bit registers are difficult to read with an arduino.

[driver_x]

Hi, you can find the program and instructions for reading/writing the chip with arduino in the previous posts. We managed to find where on the chip is stored the number of printed pages and also where is stored the actual toner level, so the problem is not here.
Maybe the printer is also storing into its internal memory(not on the cartridge) the serial number of the cartridge along with a timestamp and probably more information about the cartridge.