In 2002 I reverse engineered the espon inteligid ink chip protocol in order to build a continuous inking system for my stylus 2100p. My original pages can be found here http://eddiem.com/photo/CIS/inkchip/chip.html
To defeat the anti-refill system I installed a small AVR2313 based PCB onto the carriage and later moved this inside the printer body. This board sensed when the printer was reading the ink levels and could pull the chip data lines low at the correct time to fool the printer into reading full levels.
The spoofing was not activated every cycle but only when the embedded software noticed the levels were getting low. This was to avoid having the printer do a charge cycle every time the printer powered up.
Most CIS systems use read only chips which always read full. I've never used these but would expect the printer does unnecessary ink charge cycles as a result.
This system worked fine but the printer was plagued with chips problems to do with bad contact alignment, dirt and corroded PCB pads in the carriage circuit board â€“ epson's PCB that is.
If I got rid of the ink chips all together and replace them with a single internal micro all these contact problems would go away.
I've often thought the read only chips could be improved upon. For starters there is no need for 7 chips. Even without hacking the printer internals two chips would be enough. The 2100p has the chips wired in two banks. One suitably programmed (I mean the micro firmware here not the level data) micro in each bank would be enough. In practice this could mean one chip on the black and another on light black and no chips on the other carts.
The chips should also only reset when needed not read full all the time.
I also wrote a PC program which could read and write ink chips using a trivial circuit on the printer port. This not only allowed the chips to be reset but also to be changed from one ID to another or from one printer type to another.
For the chip replacement hack (CRH) I have to decide on which micro to use. Fake chips are often based on AVR tiny series micros. I think this would probably work, I need one extra data line than a normal chip but there are enough pins. The T12/T15 is an eight pin device.
The negative is I don't have any on hand and I don't have any PCBs to take them. They are also not recommended for new designs.
Using a larger micro there is the advantage of being able to keep the programmer hooked up during tests and having spare pins for debugging. For example you can send serial data to the PC to help work out what is going on inside the micro.
Another decision is how to power it. Chips are normally only powered up during read and write times. Most of the time they are powered down. To use this switched power line the micro must be a 3 volt type and must be able to reset and start quickly.
Powering from the internal printer supply is a little easier all round but I'll aim to use the switched power and fall back to another power source if it turns out to be too difficult.
The existing 2313 based spoofer could be reprogrammed to emulate chips but it is a 5V device and would need level translation.
I have AVRmega8s on hand and a small PCB I designed for a model helicopter which should be suitable for the CRH.
Initially I will test the CRH using my PC chip programmer and I already have updated the hardware and ported the code from Delphi to C#. I also added a second data line so I can read two banks of (virtual) chips and emulate what the printer does.
The circuit above was made in 2002 and still works now in 2008. Many people have had trouble getting the design to work and some Russians came up with a complex circuit which does the same thing but is software incompatible. I've used my circuit on a half a dozen computers including a notebook running OSes from win98 through to XP.
I had to write some software to drive the hardware and did this little GUI in Delphi-5.
It isn't the flashiest bit of code around but does the job.
New 2008 reader.
|The is my latest interface along with the schematic. I think it is right but it hasn't been independently verified.|
How it works.The serial data line on the chip is bi-directional, standard printer ports have uni-directional lines. We could put a tri-state buffer on two in the right places and control this with one of the port output lines but a cheap crude and effective way is to use a single resistor.
When we communicate with the chip the data direction is initially always from PC to chip. After four bits are sent the direction may change.
Initially the chip data line will be a hi-impedance input. The port has no trouble driving the line via the resistor provided the speed is low and the line capacitance is low.
When the chip data line switches to output it can override the signal coming from the computer. I usually pull the printer line high at this point so it simply acts as a pull-up resistor. The port input is connected directly to the chip.
The other two signals are uni-directional and driven by the port along with three output pins which are driven high to supply power for the chip.
The biggest problem with the chip reader is getting reliable connections to the chip. I needed a more robust setup for testing my code. It is hard to debug software with an unreliable connector in one hand and typing with the other.
I made the above circuit today. It uses a Intellidge soldered to a 10 pin header and matching pins on a db25 connector. It is not intended to be a chip resetter but could be one if the Intellidge was replace by an adapter.
This circuit is identical to the old one with one exception - it has two resistors. The reason is I can now have two serial data lines just like the printer does. If only one data line is used it is compatible with the old software.
One reason I needed the new chip reader was to test the new version of the software which I just got working today. This is a straight port of the delphi program to C#. This has been quite difficult. I used TurnSharp and it made a big mess I had to clean up. It is reading chips OK but I still haven't finished it. When it is ready it will be online source and all.
C# requires .NET (or maybe mono) to be installed - both are free. The code was written using sharp-develop which is also free.
One reason for porting to .NET/mono is machine independence but unfortunately the port access in done through a window DLL. It also uses a DLL for accessing the hi-res timer. I doubt this binary is going to ever run on non-windows machines. If the target OS has method for mono to write to ports and good timer access then modifying the code should be fairly easy. The timing isn't critical so the .NET timer component would probably do.
|To make the chip and reader more robust I embedded them in polymorph AKA CAPA. This is a very tough plastic which melts in boiling water and can be moulded with bare hands. It is transparent when soft and turns translucent white when cooled|
This project is not for everyone. Ninety-nine point nine percent of people who want to reset chips should buy a resetter. This is for the handful of hackers who need to read or modify chip data.
6'st Sept 2008.
I successfully programmed a mega-8 to emulate the ink chip protocol. So far this has only been tested on the chip reader and not a real printer. The project is here - MakeaFake.
I also found another bug in the chip reader C# port and it now appears to be reliable.
|These were some of the ink chips in use in 2002. There is as least one new type not included here.|
I've never tried to decode the meaning of the data in the chips apart from the ink-level. Years ago one observant reader pointed out that the data I had on the site contained a 10 character plain text message. This is more obvious in the binary steam than in the hex dump because the characters straddle across byte boundaries. I don't think this is anything nefarious. The protocol is probably nibble orientated not byte orientated. The original chips may even by using 4-bit micros.
I added the code to de-scramble the message today.
This isn't how the code does it but to do it by hand you can do this.
Chip hex dump - 00 00 00 00 00 00 00 00 00 20 A0 A8 1E 99 50 82 2B 50 FE FE 30 93 E4 B4 24 96 57 04 35 F5 E4 14
Last 11 bytes - 93 E4 B4 24 96 57 04 35 F5 E4 14
swap nibbles - 39 4e 4b 42 69 75 40 53 5f 4e 41
move them so - 94 e4 b4 26 97 54 05 35 f4 e4
Swap again. - 49 4e 4b 62 79 45 50 53 4f 4e
The string is - INKbyEPSON
So of course I had to write the opposite so I could insert my own text. Now we can have useful messages.
32 00 00 98 00 00 00 00 00 20 98 71 A1 E8 30 C2 2A 50 F4 F4 30 83 14 34 B4 24 96 57 B4 D4 04 32
String - HACKbyEKM
32 00 00 98 00 00 00 00 00 20 98 71 A1 E8 30 C2 2A 50 F4 F4 30 53 46 46 96 56 D6 E6 32 F6 D6 36
String - eddiem.com
And for that person you fancy.
32 00 00 98 00 00 00 00 00 20 98 71 A1 E8 30 C2 2A 50 F4 F4 30 F3 04 52 05 22 05 12 04 12 45 35
String - O U R A QT
File write now works.
The program was also successfully run on Mono. Some minor things don't work properly but the important stuff does.
I've finished the file i/o code and just need to test it a little more before releasing it.
In the mean time there is a beta-binary and DLL in the file gallery
Added code to use the second data line.