It’s probably fair to say that anyone reading these words understands conceptually how physically connected devices communicate with each other. In the most basic configuration, one wire establishes a common ground as a shared reference point and then the “signal” is sent over a second wire. But what actually is a signal, how do the devices stay synchronized, and what happens when a dodgy link causes some data to go missing?
All of these questions, and more, are addressed by [Ben Eater] in his fascinating series on data transmission. He takes a very low-level approach to explaining the basics of communication, starting with the concept of non-return-to-zero encoding and working his way to a shared clock signal to make sure all of the devices in the network are in step. Most of us are familiar with the data and clock wires used in serial communications protocols like I2C, but rarely do you get to see such a clear and detailed explanation of how it all works.
He demonstrates the challenge of getting two independent devices to communicate, trying in vain to adjust the delays on the receiving and transmitting Arduinos to try to establish a reliable link at a leisurely five bits per second. But even at this digital snail’s pace, errors pop up within a few seconds. [Ben] goes on to show that the oscillators used in consumer electronics simply aren’t consistent enough between devices to stay synchronized for more than a few hundred bits. Until atomic clocks come standard on the Arduino, it’s just not an option.
[Ben] then explains the concept of a dedicated clock signal, and how it can be used to make sure the devices are in sync even if their local clocks drift around. As he shows, as long as the data signal and the clock signal are hitting at the same time, the actual timing doesn’t matter much. Even within the confines of this basic demo, some drift in the clock signal is observed, but it has no detrimental effect on communication.
In the next part of the series, [Ben] will tackle error correction techniques. Until then, you might want to check out the fantastic piece [Elliot Williams] put together on I2C.
[Thanks to George Graves for the tip.]
Woah Woah Woah. I was super interested in this but needed to stop at only two minutes in. He didn’t snap the arduino into the center and symmetrically on the breadboard!!! What a monster!
Bwa ha ha ha!!! Best ever comment!!
facepalm…
You do that and let me know how it went.
The first time an IBM rep used the term “NRZI” I was a bit startled, until he explained the acronym.
The first of MANY, MANY acronyms I encountered when dealing with IBM.
You didn’t encounter the acronym ‘IBM’ first? Remarkable.
“I’ve Been Moved”
It’s pronounced “Ibbum”.
Nice to see somebody actually going over the basics. Seems like so much stuff anymore just assumes the viewer/reader already understands the low level stuff. Or even worse, doesn’t bother with the basics because they don’t think they are important. Just hook up some wires and hope for the best.
Interested to see about the error correction stuff. That’s something I’ve never really “got” personally.
Agreed, and I’ll voice my support for more of these kinds of articles. I’ve actually been logging these sorts of HaD articles for just some future time when I can become Tony Stark and make my own stuff, to go learn all the basics required. In the meantime, I will brute force through instructables/youtube/blogs to GSD, but a more complete understanding is always the best way. Thanks to Nardi for this and other articles.
Wouldn’t Manchester encoding be an option for comms without clock lines?
Well, Start Bits have been used for syncing without clock lines since teletype days.
There are a variety of clock-recovery schemes, but you have to pay an overhead penalty. Manchester encoding halves your data rate and apparently has problems at higher frequencies.
Well, that goes hand in hand with losing half the data rate. The clock will be twice as high. Still, is your requirements are not high Manchester is a good protocol that allows a very big clock error
What’s the fascination with videos? They’re good for showing how to replace the broken screen on your phone, but fall short when compared to a blog post in most cases. In a blog post, you can easily show code inline, and provide links. Re-reading a complex paragraph in a blog is easy. Pause, re-wind, re-play in a video is much more cumbersome. Maybe kids these days can only learn having their information stream fed to them…
+1
Was having a conversation with the CEO of a company last night (while drinking Tequila, so take this with a grain of salt…and a lime) about the current young generation. His expectation was that they would have awesome computer (understanding folders, excel, etc) skills. Turns out all they know how to do with technology is post selfies on Instagram.
The analogy with literacy and literary criticism comes to mind. Most modern youngsters are literate, in that they can read and write in some fashion, enough to do what they need to do. Can they explain the subtext in, say, Dune without it being spoonfed? Probably not. Hell, I love the series and it took someone pointing out its roots in the American and Russian involvement in Afghanistan and how that is still impacting politics to this day.
If one doesn’t need a skill, one doesn’t develop or remember it. If those members of the “young generation” were interested in modding Skyrim or Minecraft, they probably have experience with folders, scripting languages and so on, otherwise they wouldn’t have much use for such a skill.
Perhaps people chasing “views” because you get paid for them once you get enough.
I dislike the shift towards video-based articles as I find them time consuming and disposable, and some people are just bad at making videos. They would be akin to a load of spelling errors and slurs in a written article i suppose.
Or if I’m being more honest it’s partly because I can’t pretend to be doing something else when watching a video.
I think this video does a good job of explaining the difference between async and sync.
Also why you should NOT try to use software and clock cycles for serial communications. The absolute cheapest 8-bit parts already have UART hardware peripherals built-in that deal with all these problems and zero code overhead. Just load data into a register.
You might want to read my earlier article on communications.
https://hackaday.com/2016/06/28/serially-are-you-syncing-or-asyncing/#more-211164