I am not sure what the terminology is, but I cannot seem to get a clean signal for either my clock or data channels with my scope. There seems to be some "bleed" or whatever it is called. The weird "ticks" seem to be when the signal on the other channel transitions.
I just wanted to know why it is happening, and how I can avoid it. Is it a result of needed decoupling caps on VDD and GND? Or is it a grounding issue? Is it my probes/scope, maybe a setting?
There are two images here, one with more zoom to show the "tick" detail.
If anyone can elaborate, clarify, help I would appreciate it. And correct my terminology too. Thanks!!!
What you're seeing is usually called crosstalk. It can be from your board, the setup, the scope, or all of the above. It can be difficult to figure out if what you're seeing is real or if it's just your setup. Many times it's both.
Bypass caps on VDD are important... they're not optional. Also, the trace routing on the board affects the signal integrity of the edges, and the worse the integrity the more the crosstalk you get. 2 layer board or multi layer? 2 layers are much worse. If multi-layer, are the signals routed over a continuous plane? Are there any breaks in the plane? Do the signals change layers?
If you have any jumper wires/cables involved that will make things worse. Connect the scope probe directly to the signal, and see if it improves. Also, the scope grounding is important. That 4-6" "ground" clip on the scope probe is nothing more than an inductor/antenna and masks what the true signal looks like. You want that connection to be as short as possible. Scopes usually come with a series of small adapters that most people never use/throw away.
Usually there's a small paper-clip like thingy that clips onto the probe ground. It's small and inconvienient as hell since you have to have ground within about 1/4" of the signal, but it makes a world of difference.
OMG THANK YOU JERRY!!! I figured it was my connections and yeah I'm using a bread board. Jumpers from the probes to the testing points. I just did not want to short any pins. I never knew what that little spring thing was! I could not find it anywhere in the manual but I'm sure I overlooked it.
And most of all... thank you guys for being patient with me as I grow. Everyone knows I am not an Electrical Engineer. Believe me, if I could rewind time back to when I was in high school, the path I would have taken would have been much different!!
I did watch an EEVBLOG video about signals and why they look the way they do across generations of scopes. Very interesting video by David Jones! It explains a lot about the 10x, 1x, cheap probes, why digital scopes show more noise on a signal.
"Eh. It's a bit fuzzy. Look at the noise in there. EH!" I love this guy!!
EDIT: This is for MSO scopes I guess. It also explains how the signals get parsed and into the scope. There is a logic input for the channels on the front of the scope. This would have been a great feature for what I do. Live and learn I guess. I still love my Rigol 1054Z though.
A bit off topic, would be nice if Graham created an oscilloscope topic group here!, but I still do not understand my scope's features when it comes to 4 analog channels AND 16 digital channels. I looked quite a bit on this but apparently in the wrong places. I probably have it all wrong, but wouldn't a digital channel versus an analog one show just the logic transitions without the slew? This is important to me because I am more concerned with the logic than the slew rate at this point. And an analog sample has a lot of data when I am only looking at transitions and timing. If my scope has that ability, not only would that save memory, but it would keep my pulled file sizes way down in size and much easier to process!!
Thanks again Jerry for clearing that up for me!! Everything is working as it should which is why I neglected my hard-learned lesson about decoupling caps. It's because I am dealing with modules, not devices, as I did when I was tooling around with PIC's. Every module I use has that built into their board design. But then I am using a breadboard to connect them all for prototyping. I have to consider them as devices... correct?
You've basically got it right. The analog channels come into play when you want to look at the signal itself to make sure it's a good representation of a digital signal, like looking for those glitches. If your signals look good, then it's usually a lot easier debugging comms channels, etc using the digital side.
It's always best to keep in mind there's really no such thing as "digital electronics". Digital is just a representation of signals in the analog world.
Breadboards and jumper wires are hell on signals. They're easy to use but you probably couldn't have a worse setup if you tried. Try to keep the interconnects as short as possible. Sometimes adding a small series resistor (~100 ohms) at the source can help, but if you're using a breadboard it might not help much.
I had a an idea that might help a little, at least with my prototyping. That is the only reason for the bread board. I was considering using CAT5e cable for connections. I have a giant box of it and for things like my OLED display, instead of using jumper ribbon cable, I could make a connector cable out of ethernet cable. I will have to look at this and use the scope to see my results. Also, maybe solder some test points that my probes can clip onto. Now that I think about it, I do not have any spooled heavy gauge solid wire at all, like what is used in large capacitors should do nicely. Again, I am just looking at making my test bed as noise-less and capacitance free as possible.
Then of course there is the possibility of looking at common occurrences with my prototyping with these common systems and having a board made that serves as a host to these modules and boards. Some nice observations have been made about that too... are the signals crossing layers, is the board dual layer or multi-layer (more than 2)? Something was said about how the ground plane was designed... I could include some signal protection and conditioning and buffering to help with the prototyping.
I know it was not asked or info inquired at all, but my goal is to add support to every idea I have in the form of a debian linux headless system with wifi, interactive features like a display and controls, and quick connections with a standard to the actual embedded project. Then I can standardize the software and focus on the project design with this feature support group in place. I already picked a case. It's the Old Spice 3oz deodorant antiperspirant container. It's perfect for this! The RPI Zero Wifi and STM32F103C8T6 Blue Pill boards AND 128x64 OLED fit perfectly in it. An I2C connector (or SPI if I feel bold) to the project board is perfect. I already wrote some code so at least one of my project board MCU's (the ATMEGA 328P - Pro Mini) can act as a I2C slave. Then it is plug-n-play with a web interface on the home server that acts as the communications hub for all my projects.
Ethernet cable all by itself probably won't make much of a difference.
If you're using ribbon cable then make every other wire a GND connection ie GND all the even numbered pins, leaving the odd numbered pins for signals. That will help with the impedance and also crosstalk.
This really cuts down on the number of signals, so if you must then you can cheat for the "unimportant"/slowly changing signals. Try not to cheat around anything that's a clock or a latch signal.
You can do the same with the CAT5 cable, but there the cable is twisted pairs and the pairs aren't all in order (1-2, 3-6, 4-5, and 7-8 ). Pair each signal with a GND. If you actually have a differential pair (usb, RS485, ethernet) then pair them together instead.