Odd Differential Protocol - Page 1
Forum section: electronics / projects

author: Shay
author_rank: Regular Contributor
timestamp: August 10, 2024, 08:05:07 pm
content: Hello,I am trying to decode the differential signal coming from the SN75176B transceiver. The input signal originates from a control board, and the output is through an RJ-45 connector connected to a brushless motor, as shown in attachments #1 and #3.The issue I am facing is that the protocol data packets are not occurring at a constant frequency. There is some jitter, and it seems like the enable signal associated with the protocol signal is constantly altering the start time of the data packet. This makes decoding impossible, as the scope cannot capture the signal in a stable manner. Please see attachment #2.The blue trace is the data-enable pin. It is about ~100Hz. The yellow is the constantly changing data signal.I am wondering what could be causing this. Could it be some sophisticated tamper-proof mechanism?Would appreciate your suggestions. Thanks.

author: glenenglish
author_rank: Frequent Contributor
timestamp: August 10, 2024, 09:58:04 pm
content: the trace on the scope is a bit jumbledcan you just display a single trace for us ? IE Ch2 - Ch1 etc.considered NRZI etc differential encoding ?

author: Doctorandus_P
author_rank: Super Contributor
timestamp: August 10, 2024, 10:06:46 pm
content: I agree with glenenglish. Learn to use your scope first.You have multiple overlaid traces on your oscilloscope and this makes an attempt to look at the data futile. It does look like valid date because of the neat flans without gibberish around the flanks, but you have to use single (normal) trigger mode to have a chance of capturing real data.Also, a scope is nice for verifying signal integrity, but for capturing data, I much prefer an EUR 7 Logic analyzer combined with Sigrok / Pulseview and a PC (monitor, keyboard, mouse). With their 8 channels these things are a true gem for debugging all sorts of uC projects too.

author: Shay
author_rank: Regular Contributor
timestamp: August 11, 2024, 08:46:18 pm
content: I should've been more clear that I am well aware that the scope picture is useless - what I tried to describe is that the data packets have a lot of jitter. Thus, the scope can't decode it. It triggers on the rising edge of the data enable signal, but the second and third packet are constantly changing in their time. Maybe I am making some errors while measuring the signal. It does not matter IMO since I am now using a proper logic analyzer.I do notice different consistent data between low/high/on/off states, which is very good.I am not sure if I am decoding it correctly. It seems like the shortest bit is 26us, which means the baud rate is 1/26us which is exactly 38400. Attached is the extracted files from KingstVIS software.The measured data that is coming into the data pin of the transceiver is labeled D_fControl.

author: moffy
author_rank: Super Contributor
timestamp: August 11, 2024, 09:19:49 pm
content: The timing jitter suggests an asynchronous protocol and 26us bit width suggests 38400 baud, which you have already noted, which is one of the standard UART baud rates:https://lucidar.me/en/serialib/most-used-baud-rates-table/

author: Shay
author_rank: Regular Contributor
timestamp: August 12, 2024, 09:21:16 pm
content: Good news, I have managed to find and emulate the exact packet on my Arduino, and it runs the motor well.After some playing, I found that the last 2 bytes were CRC-16-IBM. Not really important but good to know.I noticed when the motor was off, one of the packets had 0x00 in it. And while it was on, it had 0x49. So I measured with my logic analyzer the exact timing of the protocol and bit-banged it on the arduino through the same transceiver hoping I would get lucky, and I did.Thanks everyone for helping. This was a great lesson from me in protocols.