5
\$\begingroup\$

I am trying to understand a protocol (shown in figure 1)Figure 1 . For now this I have understood that data is transferred at high to low clock. as shown in figure. and the sync is for every 8-bit.

But then there is another data at the data line, as shown in figure 2Figure 2, that is changing in the low of the clock. This does not happens at a particular instance but some time at 3rd, 4th, 8th etc. bit with respect to sync. Also this data is different every time.

After this the data is transferred at every low to high clock, still with 8-bit sync (Figure 3). So, I am thinking this may be sort of change of direction of data from read cycle to write(or vice versa).enter image description here

Can somebody help me understand this.

Edit: Its a probably a memory chip, canon is using in the protocol in there printer chips (Printer iP7230) to communicate the printer levels.

I saw this some days back thought I can try this. http://www.instructables.com/id/Reverse-Engineering-to-Emulate-Ink-Cartridges-for-/

I just wanted to be pointed in the direction of what sort of protocol it can be.

\$\endgroup\$
  • \$\begingroup\$ It's probably worth adding a bit of background on what the device is. I don't suppose it happens to be the output of an RF module? \$\endgroup\$ – PeterJ Jul 14 '13 at 8:32
  • \$\begingroup\$ No, Its not and I have edited the question accordingly. \$\endgroup\$ – Navdepp Jul 14 '13 at 8:47
  • 2
    \$\begingroup\$ I think this won't be a simple memory chip, it will be a proprietary chip developed to make life hard for reverse engineers so that you have to buy their Canon printer cartridges so that they can recover the loss they made on selling the printer. You'll probably have to see how the data varies with cartridge conditions (as it's ink runs low) and work it out the hard way. \$\endgroup\$ – RedGrittyBrick Jul 15 '13 at 7:38
  • 2
    \$\begingroup\$ The areas of data changing rapidly is probably just a period of high impedance, a gap between writing (a read cmd?) and getting a response. \$\endgroup\$ – apalopohapa Sep 17 '13 at 9:20
  • 1
    \$\begingroup\$ Yes, I had already tried it this way meaning by ignoring it. It seems to work without any problem for now. Thank you \$\endgroup\$ – Navdepp Sep 30 '13 at 11:03
1
\$\begingroup\$

I would suggest to just bit bang the protocol. My interpretation of the shown pictures is:

Figure 1: This shows the protocol with a sync bit and a clock. A new bit is sent on every falling clock slope. (As you have figured out yourself)

Figure 2: The fast changing of the data lane might be just some noise. Maybe this is the end of the data sent from the printer to the cartridge

Figure 3: This could be the response from the cartridge. It takes a lot longer to send its bits after the clock. Probably its controller is a lot slower then the one in the printer. (This is only speculation for now, but it could make sense as the printer most likely requests data from the cartridge and not vise versa)

I would suggest to attach a micro controller to the lines and monitor the requests and answers that are sent. This would help to support the theory. And in the end maybe you can replicate it. Even without knowing the protocol.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Sorry, for replying late on it as @apalopohaba suggested it probably is period of high impedance, and data also sort of made sense with this. Though I sort of lost interest in this long time back and started something else, a friend of mine did analysed this a bit further though and he also came to similar conclusion. \$\endgroup\$ – Navdepp Nov 24 '15 at 6:27
0
\$\begingroup\$

Typically any protocol is either synchronous (separate clock signal) or asynchronous (the data itself has some sort of timing, and the clock is built in).

What's weird in this protocol is that the SYNC signal is at a lower period than the clock, meaning if the receiver uses the clock to sample the SYNC, it will never notice that the sync is changing. I can only guess that the SYNC is used as as an asynchronous reset for the receiver to restart the bit count (bad design, IMHO).

In figure 2 you see data at an even lower period. IF this is not a sampling issue (noise, bad connection, etc...), I'm inclined to believe that you actually have no clock at all or you're missing a signal:

  • SYNC - Is actually frame sync, specify the start of a frame/block (chunk of words).
  • CLK - Is actually word sync, specify the start of a word
  • DATA - Is data @ ~32MHz.

However, this is highly unlikely, otherwise it means you have many ones and zeros here.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Sorry, for coming late on it as @apalopohaba suggested it probably is period of high impedance, and data also sort of made sense with this. Though I sort of lost interest in this long time back and started something else, a friend of mine did analysed this a bit further though and he also came to similar conclusion. \$\endgroup\$ – Navdepp Nov 24 '15 at 6:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.