My heyday in programming was about five years ago, and I’ve really let my skills fade. I started finding myself making excuses for my lack of ability. I’d tackle harder ways to work around problems just so I wouldn’t have to code. Worst of all, I’d find myself shelving projects because I no longer enjoyed coding enough to do that portion. So I decided to put in the time and get back up to speed.
Normally, I’d get back into programming out of necessity. I’d go on a coding binge, read a lot of documentation, and cut and paste a lot of code. It works, but I’d end up with a really mixed understanding of what I did to get the working code. This time I wanted to structure my learning so I’d end up with a more, well, structured understanding.
However, there’s a problem. Programming books are universally boring. I own a really big pile of them, and that’s after I gave a bunch away. It’s not really the fault of the writer; it’s an awkward subject to teach. It usually starts off by torturing the reader with a chapter or two of painfully basic concepts with just enough arcana sprinkled in to massage a migraine into existence. Typically they also like to mention that the arcana will be demystified in another chapter. The next step is to make you play typist and transcribe a big block of code with new and interesting bits into an editor and run it. Presumably, the act of typing along leaves the reader with such a burning curiosity that the next seventeen pages of dry monologue about the thirteen lines of code are transformed into riveting prose within the reader’s mind. Maybe a structured understanding just isn’t worth it.
I wanted to find a new way to study programming. One where I could interact with the example code as I typed it. I wanted to end up with a full understanding before I pressed that run button for the first time, not after.
When I first read about literate programming, my very first instinct said: “nope, not doing that.” Donald Knuth, who is no small name in computing, proposes a new way of doing things in his Literate Programming. Rather than writing the code in the order the compiler likes to see it, write the code in the order you’d like to think about it along with a constant narrative about your thoughts while you’re developing it. The method by which he’d like people to achieve this feat is with the extensive use of macros. So, for example, a literate program would start with a section like this:
While we don’t think this qualifies as a “fail”, it’s certainly not a triumph. But that’s what happens when you notice something funny and start to investigate: if you’re lucky, it ends with “Eureka!”, but most of the time it’s just “oh”. Still, it’s good to record the “ohs”.
Gökberk [gkbrk] Yaltıraklı was staying in a hotel long enough that he got bored and started snooping around the network, like you do. Breaking out Wireshark, he noticed a lot of UDP traffic on a nonstandard port, so he thought he’d have a look.
A few years ago, Philip Peter started a little pet project. He wanted to build his own processor. This really isn’t out of the ordinary – every few months you’ll find someone with a new project to build a CPU out of relays, logic chips, or bare transistors. Philip is a software developer, though, and while the techniques and theory of building hardware haven’t changed much in decades, software development has made leaps and bounds in just the past few years. He’s on a quest to build a CPU out of discrete components.
Search the Internet for some tips and tricks for schematic capture programs like KiCad and Eagle, and you’ll find some terrible design choices. If you want more than one copy of a very specific circuit on your board, you have to copy and paste. Circuit simulation is completely separate from schematic capture and PCB design, and unit testing – making sure the circuit you designed does what it’s supposed to do – is a completely foreign concept. Schematic capture and EDA suites are decades behind the curve compared to even the most minimal software IDE. That’s where Philip comes in. By his own admission, he reinvented VHDL badly, but he does have a few ideas that are worth listening to.
A good first step in a project is knowing what you want to do. [Ben Fino] made it clear that his Raspberry Pi Sprinkler control system for his wife’s garden had one goal: keep the plants alive. The resulting project is doing just that and no more.
The circuitry, and plumbing, is straightforward and explained well in the Instructable. All the electronics consists of is the Pi and a MOSFET to take the 3.3v GPIO to 5v to control a relay. The valve controlling the water requires 28v AC which necessitated the relay to control it. There are also three LEDs: one is for power, one to indicate when the valve is opened, and one is an extra for some future purpose.
The intriguing part is the use of weather data from the web to determine if it’s rained recently. Python scripts provided by [Ben’s] friend [Mark Veillette] use a weather site API to get the rainfall data. The main script is set to run once every 24 hours. [Ben] set his system to water unless the previous day had sufficient rain. How much rain and the number of look-back days is programmable.
What a great application of the KISS principle: keep it simple, stupid – except for that third LED without a purpose.
Give some mundane, old gear to an artist with a liking for technology, and he can turn it into a mesmerizing piece of art. [dmitry] created “red, an optic-sound electronic object” which uses simple light sources and optical elements to create an audio-visual performance installation. The project was the result of his collaboration with the Prometheus Special Design Bureau in Kazan, Russia. The inspiration for this project was Crystall, a reconstruction of an earlier project dating back to 1966. The idea behind “red” was to recreate the ideas and concepts from the 60’s ~ 80’s using modern solutions and materials.
The main part of the art installation consists of a ruby red crystal glass and a large piece of flexible Fresnel lens, positioned in front of a bright LED light source. The light source, the crystal and the Fresnel lens all move linearly, constantly changing the optical properties of the system. A pair of servos flexes and distorts the Fresnel lens while another one flips the crystal glass. A lot of recycled materials were used for the actuators – CD-ROM drive, an old scanner mechanism and old electric motors. Its got a Raspberry-Pi running Pure Data and Python scripts, with an Arduino connected to the sensors and actuators. The sensors define the position of various mechanical elements in relation to the range of their movement. There’s a couple of big speakers, which means there’s a beefy amplifier thrown in too. The sounds are correlated to the movement of the various elements, the intensity of the light and probably the color. There’s two mechanical paddle levers hanging in there, if you folks want to hazard some guesses on what they do.
KiCAD remains a popular tool for designing PCBs and other circuits, and with good reason: it’s versatile and it’s got pretty much everything needed to build any type of circuit board you’d want. It also comes with a pretty steep learning curve, though, and [Jeff] was especially frustrated with the bill of materials (BOM) features in KiCAD. After applying some Python and Kivy, [Jeff] now has a BOM manager that makes up for some of KiCAD’s shortcomings.
Currently, the tool handles schematic import, like-component consolidation, and a user-managed parts database that can be used to store and retrieve commonly used parts for the future. All of the changes can be saved back to the original schematic. [Jeff] hopes that his tool will save some time for anyone who makes more than one PCB a year and has to deal with the lack of BOM features native to KiCAD.
[Jeff] still has some features he’d like to add such as unit tests, a user guide, and a cleaner user interface. What other features are you anxious to see added to KiCAD?
[Brainsmoke] had a simple plan. Make a quadcopter with lots of addressable LEDs.
Not just a normal quadcopter with ugly festoons of LED tape though. [Brainsmoke] wanted to put his LEDs in a ball. Thus was born the polyhedrone, the idea of a flying deltoidal hexecontahedron covered as you might expect with all those addressable LEDs.
A Catalan solid makes a good choice for the homebrew polyhedron builder because its faces are all identical. Thus if you are making PCBs to carry LEDs, for example, you need only create a single PCB design to use on all faces. A bit of work in KiCAD, and a single face design with interlocking edges was ready. The boards were tested, a wiring layout was worked out, and the polyhedron was assembled.
But [Brainsmoke] didn’t stop there. He produced a flight case for the polyhedron, in the form of a larger polyhedron from what looks like lasercut thin ply.
Having a finished polyhedron, the next thing was to hook up a Raspberry Pi and write some software. First in Python, then in Go.
The results are simply stunning. If the mathematics and construction of a polyhedron were not enough to make this project worth a second look, then the gallery of images should be enough. You’ll notice that this is ostensibly a quadcopter project, yet no mention of flying has been made on this page. That’s because this is still a work in progress at Tech Inc Amsterdam, and there is more to come. But it honestly doesn’t matter if this project never moves a millimeter off the ground, as far as we are concerned [Brainsmoke] has created a superbly built thing of beauty in its own right, and we like that.
As you might expect, this is just the latest of many projects featured here that have involved addressable LEDs or quadcopters. Of note among them is this LED polyhedron that cleverly closes in all its bits, and this LED-equipped quadcopter that generates very pleasing patterns with a hi-res cross of pixels.