I am new to analyzing logic traces.

Using a Salae Logic clone sampling at 8 MHz, I used PulseView to run a capture on two connected Radica Cube World figures. It looks like only one of the connections carries data. (The other one looks like it's always high when a cube is connected and low otherwise.)

Each of exchanges on what I think is the data line has the following form:

Radica Cube World Communication Trace

Then there is a ~66 ms delay until the other cube responds with a signal that looks very similar. Because the other line connecting the cubes didn't seem to be any sort of clock, seems to me the communications are asynchronous (as well as half-duplex). Looks to me like these aren't UART frames. (I also tried the UART decoder at various potential bit times I measured from the above, and all of them had a ton of framing errors.) The asynchronicity would rule out SPI and I2C.

What protocol (or, even simpler, what bit encoding) could this be? I do not know for sure what the MCU inside these is, as I don't have the expertise to remove the epoxy blob and image the die. (However, based on Natalie Silvanovich's work with the Tamagotchis, I wonder if they could be powered by a SunPlus/GeneralPlus MCU.)

Anyway, for the bit encoding part, I tried an NRZ decoder in PulseView and that gave bits, but I have no clue if this is correct for this signal:

enter image description here

These are the characteristics I have noticed thus far:

  • Each transmission starts with a ~230 us low pulse and then a ~53 us high pulse and then an ~90 us low pulse. (This kind of reminds me of IR protocols, but this is a physical connection.)
  • Each transmission ends with a similar pattern in reverse, though the low pulse is only about 175 us this time.
  • Between this prelude and postlude, the "short" pulses/spaces are about 100 us long and the "long" pulses/spaces are either 175 or 194 us long.
  • In many captured signals, I have noticed a pattern that there is a 194 us pulse every 7 transitions... but this pattern does not hold close to the start or end of the transmission.
  • The various pulse lengths have made it difficult to deduce any sort of bit time from this.

I have not been able to recognize encoding scheme or protocol "at sight", so I would like some advice on determining what it is.

I put my PulseView session that has records one figure "visiting" the other figure here. Thanks for whatever advice you can offer!

  • \$\begingroup\$ The designer may have purposely used a non-standard protocol so others couldn't create clones. If they used a non-standard checksum/CRC, it may be extremely difficult to decode. \$\endgroup\$
    – Mattman944
    Mar 25, 2023 at 21:16
  • \$\begingroup\$ Just a suggestion: There are 5 groups of 4 low pulses of different width, separated by longer high pulses, and a final group of 8 low pulses of different width. You could record more different transmissions and try to interpret the low pulses as bits. \$\endgroup\$ Mar 27, 2023 at 7:08
  • \$\begingroup\$ @thebusybee I believe you are correct. After more experimentation, I believe the long low pulses are 1s and the short low pulses are 0s (aside from some extra handshaking stuff at the start/end of the packet). Do you want to add this as a true answer? \$\endgroup\$ Jun 12, 2023 at 20:24

1 Answer 1


There are 5 groups of 4 low pulses of different width, separated by longer high pulses, and a final group of 8 low pulses of different width. This sequence is framed with a prefix and a suffix.

Given that the high pulses are so regularly, we can look at them as separators. Their length might not be relevant and can simply be a sign of the the execution time of underlying bit-banging software.

So let's look at the low pulses. I deliberately "decoded" their length as bits by "short = 0" and "long = 1", just because of the many zeroes.

  • The prefix consists of a 1 and a 0. Perhaps these just "synchronize" the receiver, giving an example of both lengths, or call for attention.
  • The following 5 groups are binary 0010, 0000, 0000, 0000, and 0000.
  • The last set of bits has 8 bits, perhaps a checksum: 11101001.
  • And with a suffix of a single 0 the message finishes.

You could record more different transmissions, try to interpret the contents, and verify or falsify this theory.

  • \$\begingroup\$ The data stream has a look similar to that used for infra-red protocols ( without the carrier frequency) - it could be a home-brewed protocol based on that? Digikey has something that looks useful to describe the protocol: digikey.co.uk/en/maker/blogs/2021/… \$\endgroup\$ Jun 13, 2023 at 18:12
  • 1
    \$\begingroup\$ I'm not sure about the exact content of the messages yet, but I believe you are definitely right on the bit level. In case you're curious, this is the repo where I will be continuing to record my findings: github.com/npjg/radica-cube-world-hack. \$\endgroup\$ Jun 13, 2023 at 22:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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