I am trying to reverse engineer a serial communication between to microcontrollers (1 device & 1 microcontroller on a board). One MCU validates the other MCU and I want to crack the validation and mimic the validated MCU. I want to find out what protocol is being used to make sense of the data. I have captured the communication with a logic analyzer and here is a screenshot from PulseView: Logic Analyzer Signal

PulseView has decoding function but I don't know where to begin. The communication happens via 1 wire only. But I am not sure if the protocol is "one-wire". Are there any known standard methods to identify an unknown communication protocol? Or do I have to identify it by simply looking at it?

I wrote a script to convert the data into time required to change from one state to another (high-to-low or low-to-high) to compare repeated measurements and absence of the validated MCU. Each time the patterns look slightly different. It would have been great to know to decode this into byte array or whatever is intended for.

The first long low period of every cycle is sometimes 90μs sometimes 30μs. Every cycle has 14 switches in total. Long high periods between cycles may differ in length (~270-330μs).

PS: smallest time required for a change is 30μs as seen at the 3rd row on the image (120μs = 4 states).


Edit: Here are examples of signals, which doesn't obey the general rule. irregular signal pattern

Edit2: Distribution of high periods between cycles: high period duration distribution

Edit3: In the first phase (zoomed in on the top row), there are 4 frames starting with 90μs low, followed by 23 frames starting with 30μs low and finally a frame starting with 90μs low again.

Edit4: Here is the sigrok session file.

  • \$\begingroup\$ Looks like a 33Kbps synchronous protocol \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Jun 28 '18 at 21:36
  • \$\begingroup\$ @TonyStewartolderthandirt Is there any way to convert it into bytes, Ascii or hexadecimal? \$\endgroup\$ – Genom Jun 28 '18 at 21:39
  • \$\begingroup\$ Not without a bunch of patterns to find sync byte after clock sync and decode software DIY \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Jun 28 '18 at 22:02
  • 1
    \$\begingroup\$ The channel has classic ISI bitshift but primitive with 12 bit repeating 0101... then 12 “1”’s. before messages and repeating for primitive clock sync jitter reduction. One of a million old protocols. Are you going to make us guess where you stole this signal from? Pagers? For narcos? \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Jun 29 '18 at 0:07
  • 1
    \$\begingroup\$ @TonyStewartolderthandirt :) No no, I recorded this between my Nikon camera and it's battery. The camera verifies the battery over one pin. I am trying to decode the verification, hack and mimic with constant power supply. If it works out, put online. It is a way of protesting Nikon's expensive accessories and learning electronics on a different level. I will do some research on the terms you brought up. \$\endgroup\$ – Genom Jun 29 '18 at 6:38

Given the number of toggles, I suspect that this is some kind of unusual line coding. I think we'd need to see more close-ups of each frame (what you're calling a "cycle") to make a guess. In the meantime, here are some tips for figuring out the coding.

Common line codings such as NRZ and Manchester represent bits as level transitions, not levels themselves. In some codings (like Manchester), the direction of the transition is significant:

  • High to low
  • Low to high

In others (like NRZ), the presence or absence of a transition is significant.

  • Transition present
  • Transition absent

Sometimes there are two transitions per bit time, sometimes only one. The line code article on Wikipedia has a lot more information with examples of several codings. Implementations of asynchronous protocols often use bit stuffing (e.g. CAN and USB), but that doesn't seem to be present here. Bit stuffing is typically done after a run of ~6 bits, but I don't see any runs longer than 3-4 bits in your data.

The fact that you always see 14 transitions per frame seems significant, but I'm not sure how to interpret it. It looks like there are 15 bit times per frame, so if one is a start bit you'd have 14 data bit times. In a Manchester-style encoding, that would be 7 bits, which could contain an ASCII character.

| improve this answer | |

update : it’s a cam battery protocol

some realization in simple hardware may be compatible with a UART maybe with parity after you correlate and sync to repeating patterns.

Here is a standard not necessarily Nikon’s


  • preamble All 1’s Idle Then 00 1010 1010 1010 Clock sync 33.0kHz
    1111 1111 1111 ignore.

  • xxxx xxxx report this back for each sequence.

Use 30us clock and centre sample in sync Ignore the jitter in histogram but correct x axis by /10. It appears to be 30us not 300 us.

The peaks of +40 -60 are caused by channel group delay distortion on different data patterns called Inter symbol interference (ISI) which can be avoided but not necessary for this short steady path. I could do a 3 hr lecture on this topic alone on how to identify sources of signal error and how it is corrected for high speed.

| improve this answer | |
  • \$\begingroup\$ What do you mean with xxxx xxxx report this back for each sequence? What is a sequence? What is reported back? Do you mean the histogram should have (10μs/10=)1μs steps? \$\endgroup\$ – Genom Jun 29 '18 at 7:38
  • \$\begingroup\$ Are the 1’s 30us or 300! us \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Jun 29 '18 at 14:16
  • \$\begingroup\$ Ahh, I created the histogram to answer Adam's question. Therefore it is around 300μs. To show distribution of the high sequences between frames. \$\endgroup\$ – Genom Jun 29 '18 at 18:22

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.