6
\$\begingroup\$

Has anyone seen a sync serial bus communication like this?

Repeated Pattern : enter image description here

Detail of beginning : enter image description here

Personally, I haven't been able to figure it out myself...

It seems like I2C, however:

  • The clock is running at 2 MHz (as it ought to be in HS-I2C at minimum)
  • The line seems to be pulled down (I2C is usually pulled up)
  • I can't seem to set any START conditions: The first piece of data seems to move after 2 clock cycles...

It also seems like SPI, but:

  • If the data line is MOSI, the pattern repeats after 5 words of 9 bits each (while a normal SPI word is 8 bits). Later, another pattern seems to be repeated: 4 words of 6 bits each... I have never seen a SPI communication where word length changes for the same master/device pair. The smaller word length could be a common denominator, but then this should give me word lengths of 3 bits...
  • If I disconnect the device from the bus, the master still sends the exact same signals, even though it knows that the device is not present, and there is no other data line, so it look like this data line is bidirectional (as is I2C) and there is some sort of handshake (ACKnowledge) occurring somewhere.

I'm thinking that this might be a standardized bus/protocol that I simply haven't heard of and that perhaps someone here might have seen it somewhere.

\$\endgroup\$
  • 2
    \$\begingroup\$ What is the context (audio, video, ethernet, etc.)? Are there pull-ups on one or both of the lines? Are you sure the aren't more lines than these two? (My first idea would be I2S, but that requires at least one additional line.) \$\endgroup\$ – Wouter van Ooijen Mar 27 '13 at 7:04
  • 1
    \$\begingroup\$ it is how a printer is controling its ink cartidge. The master is the motherboard of the printer. The slave is the small PCB behind the ink cartidge. Other signal on the plat cable are for suspend, or other sensing signal (analog) the only 2 digital signal are these 2, and it look like communiating... So the purpose of this bus should be to give order like : expulse some ink,... \$\endgroup\$ – GPTechinno Mar 27 '13 at 8:08
  • \$\begingroup\$ So far I think you've answered your own question - it's a serial link between printer and cartridge. Serial links come in all shapes and sizes and some are simple to fathom out and some are difficult - try working out a link that has been encrypted or contains ADC data from fast moving analogue sensors. Try working one out where you don't have a clock too. Don't be too surprised about the potential variety of what you can find. \$\endgroup\$ – Andy aka Mar 27 '13 at 8:41
  • 1
    \$\begingroup\$ @moquette31 knowing printer manufacturers, everything is proprietary, trade secret and patented. I wouldn't be surprised if this protocol is undocumented and only used with that specific manufacturer. \$\endgroup\$ – Passerby Mar 27 '13 at 13:27
  • \$\begingroup\$ "So the purpose of this bus should be to give order like..." - That may be. But this may also be some kind of authentication protocol performed by the printer to verify the cartrige is 'genuine'(TM) and/or to exchange other parameters like current ink level etc. \$\endgroup\$ – JimmyB Mar 29 '13 at 14:58
1
\$\begingroup\$

Those 2 lines are probably not related

My guess is that these two lines aren't a serial "data" bus at all, given that it's really unlikely that the data line would be sampled on both clock edges. At least, they aren't part of the same communication scheme.

The clock-like trace is likely the "step" command. It's purpose is to inform the ink carriage motherboard that the stepper motor has stepped the carriage to the next position across the page.

Some alternatives?

The data-like trace is possibly a limit switch or other sensor of some kind that indicates home position, beginning of row, end of row, etc.

Or alternatively, it might be an asynchronous (no transferred clock signal) serial data link. The long idle periods between bytes might be necessary to prevent inter-symbol interference and promote clock-recovery.

\$\endgroup\$
0
\$\begingroup\$

The top signal appears to be a UART signal. Visually, it appears there are 11 bits transmitted in each character. This likely corresponds to 1 start bit, 9 data bits, and 1 stop bits for 1 character. Its possible that one of the data bits is a parity bit, apparently as XNOR of the other 8 data bits. Additionally, it appears that only two characters occur in the screenshot you provided (0 1000 0110 and 1 1111 1111). It is likely that this is a shared bus and what you are seeing is (command from dev1), (ack from dev2), (command from dev1), (ack from dev2), etc. It is probably a master-slave handshake configuration.

The second signal shows obvious drifting from the first signal, even in the short time it was recorded. This means that not only is the signal unrelated, but its probably not even on the same clock domain as the first signal.

There are some ways to test this. Disconnect the device you think is the master and spoof the master by sending the 0 1000 0110 command. If you receive 1 1111 1111 from the slave, then you will know the bus is shared.

If that works, you can also test if one of the bits is a parity bit. Just change any single bit from the original command and again spoof the master by driving the bus with the altered character. If you receive a different character in return, it is likely the error handshake character.

\$\endgroup\$

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.