Weird data signal behavior

[DaveInPA]

I have existing 2 microcontrollers (MCUs) that talk to each other over a serial connection over a 1 meter ribbon cable. Its basically 2 lines - 1 with a clock and 1 with the data. One MCU is connected to a boiler control board - MASTER MCU. The other is connected to a keypad that displays different data from the boiler - SLAVE MCU. I want to replace the SLAVE MCU with a esp32 so I can interpret the data and use it on my home automation. I thought this would be as easy as just connecting the clock and data line to the esp32 and doing the programming. Problem I am having is that when I remove the ribbon cable from the SLAVE PCB board the data signal looks very different.

Here is the data and clock signal when I read the existing MCU serial in/clock pins on the SLAVE PCB board . Notice that the data line is pulled low unless its a 1 data bit. This snippet is all 1s btw.



Here is the data and clock signal when I connect my scope to the end of the 1m ribbon cable unplugged from the SLAVE PCB board. Notice its pulled high unless its a zero bit. This is the opposite of what i see when i scope the signal on the SLAVE MCU pin on the PCB board. Also it seems the signal is rising like a RC circuit after its pulled low instead of a regular square wave.



I'm new to this so please be kind. But i've been researching and i think this may have something to do with transmission line termination. I've also researched the circuit on the SLAVE PCB board which looks very typical with a resistor before the pin and a capacitor to ground for high frequency noise suppression. Here is the SLAVE PCB circuit for just the clock and data pins. Nothing about this explains how the signal would be so different between the cable by itself vs. connected to the SLAVE PCB board. Pin 15 / S1 is the data input pin in question.



Yes i want to understand this and what is happening but you may ask - so what just connect the ESP and read the highs and lows and you are all set. But i think i need to also have a resistor and capacitor or something before my ESP32 to clean the signal before i read it. Ideally i'd be working off the same scope signal as the existing microcontroller. I know the resistor value but there is no value for the cap on the PCB board. Here is the "transmission line" circuit i came up with for the end-to-end data signal including what i know about the microcontroller pin specs:




QUESTION: Can anyone shed light on how this simple series resistor with a capacitor to ground can cause the signal to change in this way? I'm new to using an oscilliscope so measurement error i guess could be part of it?

QUESTION: If i replace the microcontroller serial in side of this what should I also use the same resistor and capacitor on the ESP32 GPIO? If so any guess what size capacitor i should use here?










 


 

[Manul]

I will not comment much about your signal issue, because frankly I don't understand why the circuit is done that way or what is intention. Normally how you drive a simple single ended signal line is just a series termination resistor. No capacitors or any other weird stuff. If you need very high speed and high noise immunity, then it's the teritory of differential signaling like RS485.

For a ribbon cable, just add a series resistor of around 68R on the TX side. Drive with push-pull output. If you want it to be like I2C (open drain driver), add pullup resistor.

[jmelson]

I'm wondering if maybe you have your scope set to AC coupling on the input?  Otherwise, the slow rising curve in your picture is when the driver has gone to high-impedance mode.
Jon

[DaveInPA]

i'm pretty sure i have it set to DC coupling.

The driver being the transmission side of this? And "going into high-impedance mode" meaning the internal resistance of the transmission microcontroller pin increases? If so what would cause that?

[tooki]

Yeah, you drive the TX side.

High-impedance mode is when an IO pin is not being actively driven high or low. Most commonly, this is when a pin is set as an input, or when a driver of some kind is switched off (e.g. when on a bus, idling; it needs to step back and do nothing so that other devices can communicate). It’s not uncommon to set an MCU’s outputs to high-impedance (=changing them to inputs) when idle, as this saves power compared to driving them to a high or low state.

As others have already alluded to, it also depends on what kind of bus it is. You can have buses with open-collector/open-drain outputs (bus is pulled high by default using pull-up resistors, and only driven low by the outputs), or push-pull outputs (inactive devices go high-impedance, and the active device actively drives the signal to high or low; a pull-up or pull-down resistor is optional, to give the bus a default state).

Your transmission line model is completely wrong. You show multiple capacitors in series, which is not correct. A transmission line has resistance and inductance in series, capacitance in parallel. And that’s just talking about the parasitics of the transmission line; any added capacitance to ground for filtering, series resistance, series inductance for filtering, or parallel resistance for termination, are in addition.*


It’s very unclear in your description what is doing what. Is the PCB circuit shown the transmitting or receiving MCU?


If I understand your original post, the second scope image is when you’re probing the same signals at the end of the ribbon cable, without the receiving MCU connected? Since you  cropped the screenshots  , and didn’t otherwise provide the scope settings, we have no idea what time base you are using, and thus how fast this signal is. But bear in mind that standard 28AWG, 0.05” ribbon cable has around 48pF of capacitance per meter, between adjacent conductors (in the typical alternating gnd-signal-gnd configuration). The conductor itself has about 0.24 ohms/m resistance and about 0.5μH series inductance. This gives a characteristic impedance of around 100 ohms. This is fast enough for extremely fast signals, provided the termination is correct. I can’t imagine your boiler is producing a signal anywhere near fast enough to exceed the cable’s capabilities.

For push-pull: A 100 ohm series resistor on the transmit side matches the 100ish ohm characteristic impedance well. Then you terminate the receiving end with two 200 ohm resistors: one to +3.3V, one to ground.

See also https://www.eevblog.com/forum/projects/how-many-mhz-can-a-1-27mm-ribbon-cable-handle/

*Series capacitors in a signal line are used to block DC, creating AC coupling. That’s common in e.g. analog audio, but not sensible with standard digital logic, which is normally 0V as the lowest voltage, and positive 3.3 or 5V as the highest. AC coupling shifts the voltages so that it’s centered around 0V, with equal excursion to positive and negative voltages. For example, a 0V/5V signal becomes -2.5V/+2.5V.

[DaveInPA]

Thank you for that detailed response! I should have shown more of the scope output for sure. My signal is indeed pretty slow with each bit pulse about 1us in width separated by 100us lows (the clock at least). The 8 bits are then separated by 200us seconds between them for a total of 6 bytes transmitted. Then it’s 100ms between those 6 byte frames. If my maths is correct that maxes out at about 10khz.

I think between your answer and more reading what I am seeing on the cable vs the pcb (the receiving microprocessor) is that the microprocessor on both the transmit and the receiving side are pulling (?) low or high depending on where it is in the data transmission. It’s like i2c and some other protocols I’ve been researching where the slave channel pulls low or something to signal its ready to receive or send.

This explains why the resistor and cap on the pcb pretty much have nothing to do with the different high to low and low to high behavior of the signal. Also the slow rise from low to high is also because without the receiving microprocessor being pulled low the ribbon is floating (or the transmit pin is floating) and the cable acts as a RC circuit. Until one of the 2 sides pulls the line low or high.

So I have some more scope work to do to figure out the timing of which side gets pulled high or low or left floating and when. But I think I have at least figured out the mystery….

[tooki]

The capacitance and resistance of the cable are way, way too small to explain the ramp you’re seeing.

You haven’t answered the clarification questions I asked. Could you please post a complete, fully-explained description and diagram of what you’re doing? The whole setup. Make it absolutely, unambiguously crystal clear which MCU you are referring to when you mention one. We cannot help you if you continue to withhold information.

[ArdWar]

What kind of protocol is this? Especially what kind of output drive the data lines are? Is it push-pull or open collector?

What the DO signal looks like if you probe it directly without 10K resistor in the way?

Anyway, use tri-state buffer if you want to create a half-duplex interface. Connecting the signals the way you do and expecting to drive the data line thru 10K resistor is just asking for signal integrity problem.

[DaveInPA]

Appreciate the help tooki....i updated my original post to clarify which side is the sending MCU (master) and which is the receiving (slave). For now I'm just trying to replace the downstream slave device with an ESP32. The PCB circuit I posted is the slave device and the 2 scope outputs is when I measure the data/clock signal from the MCU pins on the PCB and when I measure the end of the disconnected ribbon cable. I don't know the protocol or if it is open collector or push pull as I didn't build the circuit.

When the SLAVE MCU isn't connected and the ribbon cable is floating it seems the data line from the MASTER serial out is floating until a zero gets sent. Also seems like when a 1 is sent the pin goes from a float state to a solid 5V for the duration of the clock pulse (as expected). After the MASTER serial pin goes low it then rises back up as if its a capacitor charging. Here is another picture of just the data line measured at the end of the disconnected ribbon cable - or said another way the signal from where it leaves the MASTER PCB board.

[ Attachment Invalid Or Does Not Exist ]

The SLAVE MCU serial in pin is using a 470 ohm resistor and a capacitor to ground before the serial in pin. It seems that I would also need to use a similar resistor in series with my ESP32 GPIO input pin. It also seems that the existing SLAVE MCU serial in has an internal pull down resistor since the data line is held low based on what I see on my scope when I measure the data line from the SLAVE MCU pin.

Not sure what is causing that slow rise in my floating ribbon cable and not sure if it matters (although i'd like to understand it). My next step is to connect the ESP32 to the ribbon cable with a GPIO setup with internal pull down configured. Reading the ESP32 data sheet the internal resistance and capacitance values are similar to these 8-bit fujitsu MCUs from 2008...

[tooki]

It looks to me like that’s likely a three-wire SPI bus. The 10K resistor between MISO and MOSI is typical for that. The 470R resistor is just current limiting. Very common on SPI. The caps indeed likely just filter out some noise.

There is no such thing as a “closed collector” bus. Don’t invent terminology. As explained to you already, a bidirectional bus uses either open-collector/open-drain outputs, or uses tri-state outputs (high/low/high-z).

Your new image did not appear. After posting, always review your post to make sure formatting and attachments worked as expected, and go back and edit if needed.

You haven’t added much information that we have asked for. If you have the schematics for the whole thing, share them.

[radiolistener]

try to play with GPIO configuratiom

[DaveInPA]

I’m going to have to do some disassembly on the master side to capture what that circuit looks like. I did realize last night that the 10k resistor on the slave serial in pin is probably acting like a programmable pull up or pull down resistor. It could be used as part of the protocol to indicate when the slave is ready to receive vs send data. That would explain why the data line shows pulled low when I read the slave pcb signal but shows floating when I read the ribbon cable disconnected from the slave. I am only interested in receiving data so I’m going to see about using a 10k resistor to ground on the ribbon cable end and see if that helps the circuit look more like what I am expecting.

Besides clarifying the MCUs and posting a circuit diagram of the sending master MCU pcb I’m sorry but I don’t see any other questions or information you asked for?

[Gyro]

OT: I'm surprised that nobody else has picked up on this, but having your email address as your forum username is a really bad idea. This forum is regularly trawled by every bot out there. I recommend that you contact the mods and ask to change it, this is one of the few circumstances where they allow changing. Hit the 'Report to Moderator' on one of your posts and ask nicely.

[DaveInPA]

OP here…solve my mystery…

The data line is expected to be pulled low by the receiving circuit. So when I measure it disconnected from its PCB the data line was floating. Looking at the PCB of the slave I realized the serial out of the MCU is connected to a 10k resistor. I put my scope on that pin and I can see it pulls the output low which grounds the 10k resistor which then acts as a pull down resistor for the serial in pin. So simply putting a 10k resistor on the data line to ground fixes the data line signal and it matches what I would see on the slave PCB board.

Now I know all about open collectors and push pull pins…

[BennoG]

Is this not the openTherm protocol.
Where you have 2 way communication over 1 line depending the value of the pull down / or up resistor.

https://en.wikipedia.org/wiki/OpenTherm

Benno

[DaveInPA]

You got me very excited there for a moment until i looked a bit at the protocol and don't think its this. What i'm seeing is 6 byte messages and the OpenTherm is 32 bit and also includes power for the controller. In my case my controller/keypad both reads and sends data. The manufacturer of the control board and keypad is a member of OpenTherm howerver so it was close!