Ohm? Don’t Forget Kirchhoff!

May 25, 2017 by Al Williams 52 Comments

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.

If you want to play with it yourself, you can simulate the circuit below.

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).

Continue reading “Ohm? Don’t Forget Kirchhoff!” →

On Point: The Yagi Antenna

May 24, 2017 by Dan Maloney 86 Comments

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.

Continue reading “On Point: The Yagi Antenna” →

Stupid Git Tricks

May 23, 2017 by Al Williams 25 Comments

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.

Continue reading “Stupid Git Tricks” →

Wrap Your Mind Around Neural Networks

May 22, 2017 by Will Sweatman 18 Comments

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.

Continue reading “Wrap Your Mind Around Neural Networks” →

Don’t Be A Code Tyrant, Be A Mentor

May 16, 2017 by Adam Fabio 168 Comments

Hardware hacking is a way of life here at Hackaday. We celebrate projects every day with hot glue, duct tape, upcycled parts, and everything in between. It’s open season to hack hardware. Out in the world, for some reason software doesn’t receive the same laissez-faire treatment. “Too many lines in that file” “bad habits” “bad variable names” the comments often rain down. Even the ~~unsafest~~ silliest of projects isn’t safe. Building a robot to shine lasers into a person’s eyes? Better make sure you have less than 500 lines of code per file!

Why is this? What makes readers and commenters hold software to a higher standard than the hardware it happens to be running on? The reasons are many and varied, and it’s a trend I’d like to see stopped.

Software engineering is a relatively young and fast evolving science. Every few months there is a new hot language on the block, with forums, user groups, and articles galore. Even the way software engineers work is constantly changing. Waterfall to agile, V-Model, Spiral model. Even software design methodologies change — from pseudo code to UML to test driven development, the list goes on and on.

Terms like “clean code” get thrown around. It’s not good enough to have software that works. Software must be well commented, maintainable, elegant, and of course, follow the best coding practices. Most of these are good ideas… in the work environment. Work is what a lot of this boils down to. Software engineers have to stay up to date with new trends to be employable.

There is a certain amount of “born again” mentality among professional software developers. Coders generally hate having change forced upon them. But when they find a tool or system they like, they embrace it both professionally, and in their personal projects. Then they’re out spreading the word of this new method or tool; on Reddit, in forums, to anyone who will listen. The classic example of this is, of course, editors like the vi vs emacs debate.

Continue reading “Don’t Be A Code Tyrant, Be A Mentor” →

Automate The Freight: Medical Deliveries By Drone

May 12, 2017 by Dan Maloney 26 Comments

Being a cop’s kid leaves you with a lot of vivid memories. My dad was a Connecticut State Trooper for over twenty years, and because of the small size of the state, he was essentially on duty at all times. His cruiser was very much the family vehicle, and like all police vehicles, it was loaded with the tools of the trade. Chief among them was the VHF two-way radio, which I’d listen to during long car rides, hearing troopers dispatched to this accident or calling in that traffic stop.

One very common call was the blood relay — Greenwich Hospital might have had an urgent need for Type B+ blood, but the nearest supply was perhaps at Yale-New Haven Hospital. The State Police would be called, a trooper would pick up the blood in a cooler, drive like hell down I-95, and hand deliver the blood to waiting OR personnel. On a good day, a sufficiently motivated and skilled trooper could cover that 45-mile stretch in about half an hour. On a bad day, the trooper might end up in an accident and in need of blood himself.

Continue reading “Automate The Freight: Medical Deliveries By Drone” →

History Of Git

May 11, 2017 by Al Williams 89 Comments

Git is one of those tools that is so simple to use, that you often don’t learn a lot of nuance to it. You wind up cloning a repository from the Internet and that’s about it. If you make changes, maybe you track them and if you are really polite you might create a pull request to give back to the project. But there’s a lot more you can do. For example, did you know that Git can track collaborative Word documents? Or manage your startup files across multiple Linux boxes?

Git belongs to a family of software products that do revision (or version) control. The idea is that you can develop software (for example) and keep track of each revision. Good systems have provisions for allowing multiple people to work on a project at one time. There is also usually some way to split a project into different parts. For example, you might split off to develop a version of the product for a different market or to try an experimental feature without breaking the normal development. In some cases, you’ll eventually bring that split back into the main line.

Although in the next installment, I’ll give you some odd uses for Git you might find useful, this post is mostly the story of how Git came to be. Open source development is known for flame wars and there’s at least a few in this tale. And in true hacker fashion, the hero of the story decides he doesn’t like the tools he’s using so… well, what would you do?

Continue reading “History Of Git” →