A car is a rolling pile of hundreds of microcontrollers these days — just ask any greybeard mechanic and he’ll start his “carburetor” rant. All of these systems and sub-systems need to talk to each other in an electrically hostile environment, and it’s not an exaggeration to say that miscommunication, or even delayed communication, can have serious consequences. In-car networking is serious business. Mass production of cars makes many of the relevant transceiver ICs cheap for the non-automotive hardware hacker. So why don’t we see more hacker projects that leverage this tremendous resource base?
The backbone of a car’s network is the Controller Area Network (CAN). Hackaday’s own [Eric Evenchick] is a car-hacker extraordinaire, and wrote up most everything you’d want to know about the CAN bus in a multipart series that you’ll definitely want to bookmark for reading later. The engine, brakes, doors, and all instrumentation data goes over (differential) CAN. It’s fast and high reliability. It’s also complicated and a bit expensive to implement.
In the late 1990, many manufacturers had their own proprietary bus protocols running alongside CAN for the non-critical parts of the automotive network: how a door-mounted console speaks to the door-lock driver and window motors, for instance. It isn’t worth cluttering up the main CAN bus with non-critical and local communications like that, so sub-networks were spun off the main CAN. These didn’t need the speed or reliability guarantees of the main network, and for cost reasons they had to be simple to implement. The smallest microcontroller should suffice to roll a window up and down, right?
In the early 2000s, the Local Interconnect Network (LIN) specification standardized one approach to these sub-networks, focusing on low cost of implementation, medium speed, reconfigurability, and predictable behavior for communication between one master microcontroller and a small number of slaves in a cluster. Cheap, simple, implementable on small microcontrollers, and just right for medium-scale projects? A hacker’s dream! Why are you not using LIN in your multiple-micro projects? Let’s dig in and you can see if any of this is useful for you. Continue reading “Embed With Elliot: LIN is for Hackers”→
“Dammit Jim, I’m a hacker, not a musician!”, to paraphrase McCoy Scotty from the original Star Trek series. Well, some of us are also musicians, some, like me, are also hack-musicians, and some wouldn’t know a whole note from a treble clef. But every now and then the music you want is in the form of sheet music and you need to convert that to something your hack can play. If you’re lucky, you can find software that will read the sheet music for you and spit out a MIDI or WAV file. Or, as with my hand-cranked music player, you may have to read just enough of the music yourself to convert musical notes to frequencies for something like a 555 timer chip. We’ll dive into both cases here.
It is hard to get very far into electronics without knowing Ohm’s law. Named after [Georg Ohm] it describes current and voltage relationships in linear circuits. However, there are two laws that are even more basic that don’t get nearly the respect that Ohm’s law gets. Those are Kirchhoff’s laws.
In simple terms, Kirchhoff’s laws are really an expression of conservation of energy. Kirchhoff’s current law (KCL) says that the current going into a single point (a node) has to have exactly the same amount of current going out of it. If you are more mathematical, you can say that the sum of the current going in and the current going out will always be zero, since the current going out will have a negative sign compared to the current going in.
You know the current in a series circuit is always the same, right? For example, in a circuit with a battery, an LED, and a resistor, the LED and the resistor will have the same current in them. That’s KCL. The current going into the resistor better be the same as the current going out of it and into the LED.
This is mostly interesting when there are more than two wires going into one point. If a battery drives 3 magically-identical light bulbs, for instance, then each bulb will get one-third of the total current. The node where the battery’s wire joins with the leads to the 3 bulbs is the node. All the current coming in, has to equal all the current going out. Even if the bulbs are not identical, the totals will still be equal. So if you know any three values, you can compute the fourth.
The current from the battery has to equal the current going into the battery. The two resistors at the extreme left and right have the same current through them (1.56 mA). Within rounding error of the simulator, each branch of the split has its share of the total (note the bottom leg has 3K total resistance and, thus, carries less current).
If you happened to look up during a drive down a suburban street in the US anytime during the 60s or 70s, you’ll no doubt have noticed a forest of TV antennas. When over-the-air TV was the only option, people went to great lengths to haul in signals, with antennas of sometimes massive proportions flying over rooftops.
Outdoor antennas all but disappeared over the last third of the 20th century as cable providers became dominant, cast to the curb as unsightly relics of a sad and bygone era of limited choices and poor reception. But now cheapskates cable-cutters like yours truly are starting to regrow that once-thick forest, this time lofting antennas to receive digital programming over the air. Many of the new antennas make outrageous claims about performance or tout that they’re designed specifically for HDTV. It’s all marketing nonsense, of course, because then as now, almost every TV antenna is just some form of the classic Yagi design. The physics of this antenna are fascinating, as is the story of how the antenna was invented.
What’s on your bench? Mine’s mostly filled with electronic test equipment, soldering kit, and computers. I’m an electronic engineer by trade when I’m not writing for Hackaday, so that’s hardly surprising. Perhaps yours is like mine, or maybe you’ve added a 3D printer to the mix, a bunch of woodworking tools, or maybe power tools.
So that’s my bench. But is it my only bench? On the other side of the room from the electronics bench is a sturdy folding dining table that houses the tools and supplies of my other bench. I’m probably not alone in having more than one bench for different activities, indeed like many of you I also have a messy bench elsewhere for dismantling parts of 1960s cars, or making clay ovens.
The other bench in question though is not for messy work, in fact the diametric opposite. This is my textile bench, and it houses the various sewing machines and other equipment that allow me to tackle all sorts of projects involving fabric. On it I’ve made, modified, and repaired all sorts of clothing, I’ve made not-very-successful kites, passable sandals, and adventurous tent designs among countless other projects.
Some of you might wonder why my textile bench is Hackaday fodder, after all it’s probably safe to assume that few readers have ever considered fabricating their own taffeta ball gown. But to concentrate only on one aspect of textile work misses the point, because the potential is there for so much cross-over between these different threads of the maker world. So I’m going to take you through my textile bench and introduce you to its main tools. With luck this will demystify some of them, and maybe encourage you to have a go.
My apologies if you speak the Queen’s English since that title probably has a whole different meaning to you than I intended. In fact, I’m talking about Git, the version control system. Last time I talked about how the program came to be and offered you a few tutorials. If you are a dyed-in-the-wool software developer, you probably don’t need to be convinced to use Git. But even if you aren’t, there are a lot of things you can do with Git that don’t fit the usual mold.
Artificial Intelligence is playing an ever increasing role in the lives of civilized nations, though most citizens probably don’t realize it. It’s now commonplace to speak with a computer when calling a business. Facebook is becoming scary accurate at recognizing faces in uploaded photos. Physical interaction with smart phones is becoming a thing of the past… with Apple’s Siri and Google Speech, it’s slowly but surely becoming easier to simply talk to your phone and tell it what to do than typing or touching an icon. Try this if you haven’t before — if you have an Android phone, say “OK Google”, followed by “Lumos”. It’s magic!
Advertisements for products we’re interested in pop up on our social media accounts as if something is reading our minds. Truth is, something is reading our minds… though it’s hard to pin down exactly what that something is. An advertisement might pop up for something that we want, even though we never realized we wanted it until we see it. This is not coincidental, but stems from an AI algorithm.
At the heart of many of these AI applications lies a process known as Deep Learning. There has been a lot of talk about Deep Learning lately, not only here on Hackaday, but all over the interwebs. And like most things related to AI, it can be a bit complicated and difficult to understand without a strong background in computer science.
If you’re familiar with my quantum theory articles, you’ll know that I like to take complicated subjects, strip away the complication the best I can and explain it in a way that anyone can understand. It is the goal of this article to apply a similar approach to this idea of Deep Learning. If neural networks make you cross-eyed and machine learning gives you nightmares, read on. You’ll see that “Deep Learning” sounds like a daunting subject, but is really just a $20 term used to describe something whose underpinnings are relatively simple.