Project Logs

Collapse

• I was wrong.

  alpha_ninja • 09/04/2015 at 23:47 • 2 comments

  Hi there! Long time no see!

  Here's what I just found out.

  All cartridges share one bus.

  This makes sense.

  So, I tested inserting one cartridge after the other.

  Magenta is doing the sensing, I'm inserting black, then cyan, then pigment black, then yellow.

  Magenta only
  

  0xdef800 0x000000 0xdefc00 0x000000 0xdee400 0x000000 0xdef200 0x000000 0xdeec00 0x000000

  Magenta & Black

  0xdef800 0x000000 0xdefc00 0x000000 0xdee400 0x000000 0xdef200 0x000000 0xdeec00 0xdc0000

  0xdf2c64
  

  Magenta & Black & Cyan

  0xdef800 0x000000 0xdefc00 0x000000 0xdee400 0xbc0000 0xdef200 0x000000 0xdeec00 0xdc0000

  0xdf2432 0xdf2c64

  Magenta & Black & Cyan & Pigment Black

  0xdef800 0x000000 0xdefc00 0xef0000 0xdee400 0xbc0000 0xdef200 0x000000 0xdeec00 0xdc0000

  0xdf3c32 0xdf2432 0xdf2c64

  Magenta & Black & Cyan & Pigment Black & Yellow

  0xdef800 0xcf0000 0xdefc00 0xef0000 0xdee400 0xbc0000 0xdef200 0x000000 0xdeec00 0xdc0000

  0xdf3832 0xdf3c32 0xdf2432 0xdf2c64

  I don't know why I didn't test for this.

  Anyway, these are the conclusions I can make from this:

  1. The read protocol is as follows:

  0xdef800 (Yellow) 0x*****

  0xdefc00 (Pigment Black) 0x*****

  0xdee400 (Cyan) 0x*****

  0xdef200 (Magenta) 0x*****

  0xdeec00 (Black) 0x*****

  2. The write protocol is as follows:

  0xdf2c64 (Black)
  0xdf2432 (Cyan)
  0xdf3c32 (PgBk)
  0xdf3832 (Yellow)
  0xdf3232 (Magenta)

  ---

  Edit:

  Turns out the cartridge I used for testing had the traces cut. Oops :P

  I've added the values I got from another test, but won't be retesting the values I measured above :)
  

• More protocol analysis

  alpha_ninja • 08/31/2015 at 15:28 • 0 comments

  This is old information

  For newer information, see the project log "I was wrong."
  

  I've found that the following pattern is used:

  (Part 1 of protocol—call/response: 16 - 8 bits.)

  0xdef800:

  Is always sent.

  0xcf0000 or 0x000000:

  Might have different values too, haven't done enough testing

  0xdefc00:

  Is always sent.

  0xef0000:

  Is always sent.

  0xdee400:

  Is always sent.

  0xbc0000 or 0x000000:

  Might have different values too, haven't done enough testing.

  0xdef200:

  Is always sent.

  0x9b0000 or 0x000000:

  Seems to be remaining ink pages or something—this is the same for every cartridge no matter in what slot it is.

  0xdeec200:

  Is always sent.

  Then one of the following:

  0xdeec00

  0xdc0000

  ---

  Part 2 of the protocol - 24 bit packages

  Sometimes: 0xdf38 32

  Always: 0xdf3c 32

  Sometimes: 0xdf24 32

  Sometimes: either 0xdf2c 64 or 0xdf32 32

  ---

  In conclusion, the first part of xmissions is made up of 16-bit packages that start with 0xde and are replied to with some other 8-bit value (can also be 0). This is probably the read command—I'll have to test this hypothesis.

  The second part of xmissions is made up of 24-bit packages that start with 0xdf and in the next two bytes most likely have the address and value after them. I haven't yet seen values other than 0x32 and 0x64. Thus, this is probably the read command—I'll have to test this hypothesis, too.
  

• The PCB

  alpha_ninja • 08/31/2015 at 06:01 • 0 comments

  Here's the pin assignment for the PCB:
  1 - Clock
  2 - Ground
  3 - Data
  4 - VCC (?)
  5 - LED (When this is LOW and 4 is HIGH, the LED is on.)

  I'd like to point out that the LED pin might have some other connections since it seems to be pulled high/low without an electrical connection to the printer. However, I haven't been able to confirm this.
  

• The Protocol

  alpha_ninja • 08/31/2015 at 05:50 • 0 comments

  I'm still working on figuring out the protocol that's used for communication between the printer and the cartridge.

  This is what I know so far:

  There is a clock signal—it runs at 100KHz. It doesn't stop. Ever. It's also falling-edge triggered.

  There is a data signal.

  This is a xmission:

  These xmissions have a delay of about 76ms in between them.

  There's 2 parts. I don't know the significance of this, nor what part pulls data high when for what reason.

  This is the first part of an xmission:

  I'm also not sure what this is. I think it might be the printer reading from the cartridge's EEPROM—sending a 16 byte address and receiving an 8 byte value. Notably, the fourth value seems to be zero.

  This is the second part of an xmission:

  Considering the previous part, the logical conclusion is that this is writing to the EEPROM—the packets sent each have 24 bits, so that's probably the address and then the data.

  I've extracted all this information from csv dumps via Python. You can see it here.

  The xmissions I have recorded, so far, are from when the printer is open. I haven't yet recorded xmissions while printing a page, but this is necessary because that is most likely a time at which the printer will write to the EEPROM. I'll have to do this sometime later.
  

View all 4 project logs