I love DIY/soldering kits, and thanks to online marketplaces like eBay I’ve been able to purchase and assemble a number of them for the past few months.
One of the last ones I got was a very basic but useful function/signal generator, whose only problem was that it required a power supply with +12V/+5V/-12V rails (it also arrived already assembled despite being sold as a DIY kit, which was disappointing in a way).
My firsts tests of the kit were with a PC power supply (the only source of -12V I had in my lab) until I got a “proper” alternative in the form of another kit, which is sometimes advertised as a “Hiland USB Dual Power Multiple Output Supply”. I will call it HL supply during this post (Mine says “Hyland” on the PCB, so assuming an original version exists mine is probably a cheap clone). This one actually required assembly (yay!) and worked fine in my limited tests, but it was still a hassle to have the two boards dangling around connected whenever I wanted to use the signal generator, so after some time I decided to make a (temporary) enclosure for the whole thing.
Function generator and power supply inside a temporary hand-made enclosure.
Left module: Signal generator. Right board: HL supply.
In my neverending quest of improving my homemade PCBs, I discovered that adding a soldermask to my boards is actually not a hard task, thanks to a relatively simple process that involves UV-curable paint. Now, while using the sunlight as a UV source should work just fine, I decided that it was time to build a proper UV exposure box. Winter is quickly approaching and I’m not too fond of the idea of having a variable-intensity light source (the sun) that would make the process (and end result) completely dependent on how good was my estimation of the time required to properly cure the paint given the weather of that particular day.
A UV Box would also allow me to experiment with UV-based transfer methods for the PCB etching process as well, so it was definitely time to build one.
UV Exposure Box. Closed.
Pocket C.H.I.P + USB Analyzer
So a time ago I purchased a cheap USB Logic Analyzer from eBay that works great with a PC, and it’s been really helpful to debug several projects to date. It uses the Logic software from Saleae as hinted by the label on it, although I am not sure if the device is supposed to be a cheap knockoff of one of the (pricier) genuine Saleae analyzers, or it was just designed to be “Saleae-compatible” and use their software. Read More
So recently I had to design a relatively convoluted system with a database that communicates with a hardware controller board and a RFID reader. Among other things, the system has to respond to several commands issued from a web frontend over HTTP, and report the status of each sub-system, sensor, etc hopefully in JSON or similar web-friendly format.
For this task I picked a Raspberry Pi as the platform, and made a program in C that talks directly to the hardware and handles everything including the HTTP requests. Now, this is definitely not the first time that I need to write a program that has to listen for requests and reply with simple data over HTTP, so I thought that perhaps it would be useful to encapsulate this functionality in a small module that I could later re-use in other projects.
So I ended up doing exactly that, and uploaded the code to my GIT-Hub Repository, so you’ll find the result from that here: https://github.com/battlecoder/httpdpi.
Before you dive into the code, please bear in mind that it’s an extremely simple service that will only respond to GET requests, but has all it needs to reply with different status codes, text, and binary data. It only uses sockets and POSIX threads, so it’s very fast, doesn’t depend on a huge framework, and can run in parallel with your code. It’s also really easy to expand if you want to support other types of requests.
Since it doesn’t have obscure dependencies, it should also compile on most linux boxes including other small computers like C.H.I.P, Beaglebone, etc.
Cutting PCBs down to size for each project has always been a problem for me. I don’t have a bench saw, so I’ve been doing this by hand until now. Despite the number of boards I’ve made, I still lack the dexterity to do perfectly straight cuts with a regular hacksaw, and my success with other manual methods has been equally limited. Like a year ago I stumbled upon a small a table saw on dealXtreme which I was tempted to buy but was kinda too expensive for me. My search continued until a few months ago, when I realized that I could make one myself, using a small motor I salvaged from a cheap $10 dremel-like tool that I once had. I wasn’t sure this was going to work, but decided to give it a go nonetheless.
At least looks like a table saw. That’s always a good sign.
A while ago -and after a couple of trips to our local “flea market”- I managed to get my hands on a fully working vintage Atari 800XL. It took some tests and soldering work, but I ended up with a fully working 800XL with a XC12 cassette deck (I even got a defective cassette deck that it’s mostly working now after some repairs). I also built a video cable to have the “vastly superior” RCA video output instead of the noisy “TV” RF signal.
The tape deck loads and saves to cassette perfectly, but every read/write operation takes ages. Not that I mind waiting, to be fair, but since there seems to be better alternatives (like the floppy disk drive) it makes no sense to just stick to this, especially since I intend to do some development on the device.
Yes, this picture was taken with a potato.
So in the sort of tutorial I wrote about ORC-KIT I mentioned that it was possible to use other boards instead of Adafruit’s friendly motor shield, and in fact, there was space in the board for a couple of very cheap and widely available L9110S Dual H-Bridges, which should give you more control over the build, and “free” some precious Arduino pins that you can use for extra sensors and actuators. You can actually change the Arduino for something else, but that’s beyond the scope of this post.
H-Bridges are simple circuits that allow you to control the flow of current through a “load” with 2 control signals (A and B). When the load is a motor, you can make it spin forward, reverse or stop completely by changing the digital values on A and B. H-Bridges normally have an ENABLE line as well, which you can toggle yourself or leave permanently “ON”. Controlling the speed of the motors is easier if you can turn each bridge on and off quickly using PWM pulses applied to the enable lines, but that’s not always possible. The L9110S boards don’t have an enable pin, for instance, so we will need to manipulate only the 2 basic control signals to drive our motors if we use this controller.
Each of these Dual H-Bridge modules can drive 2 motors and has a 6 pin header for the 4 control signals plus power.
You may remember the small soldering fume extractor I designed a while ago. It has worked really well since I built it, and it’s made my soldering work a much more pleasant experience.
However, during the time I’ve been using it, I’ve discovered a small aspect that could definitely be improved. Because of the way it works, when the fan start working it “sucks” the carbon filter a bit towards the blades. As the distance between the filter and the fan blades is no more than 2mm and the filter itself is not rigid, the carbon surface “bends” and touches the spinning fan, which causes the blades to pull and cut fibers from the filter. You can actually hear this happening when you turn the unit on with a reasonably new filter.
This stops after some uses, as the filter becomes thinner and less dense from all the fibers it has lost. This doesn’t prevent the extractor from working, but it certainly reduces both the efficiency and the lifespan of the filter.
To solve this I designed a small plastic “grill” that would hold the carbon filter in place, separating it from the fan.
Carbon filter holder for my soldering fume extractor.
Earlier this year I embarked on the journey of designing a simple but expandable robot that any electronics enthusiast could build. I knew several nice kits from brands like Lego, Makeblock, OWI Robotics, etc, but I considered them to be normally either too expensive or too simple and limited. There are also many generic unbranded kits on eBay which suspiciously have all pretty much the same design but vary mostly in their debatable choices for hardware and layout.
I wanted to do something flexible but not too expensive nor flashy, much like the unbranded kits, but with better design practices in mind, and engineered to be heavily customizable.
Fully assembled Vanilla ORC-KIT with some extras.
Continuing from my previous post on randomness, I’d like to talk about non-uniform distributions, which certainly don’t get all the love they deserve. When people talk or think about randomness in games, they commonly think about fair distributions. And I know we spent a lot of time in Part 1 actually trying to achieve perfect uniformity because it brings “fairness” to games, but in reality, there are cases where you don’t want your random events to be ruled by a “fair” distribution at all.
Reality Check #4: Sometimes uniformity is bad
Fun fact: For a lot of “random” events in nature, every possible outcome rarely has the same chance of occurring, so perhaps trying to achieve that uniformity in games could be a mistake to begin with.
Let’s take rabbits for instance.
If you observe the population of rabbits of a given area, you’ll notice that they’ll have a”typical average size”. Let’s call that size X. You’ll find that most rabbits in the area will be around that size. There will be a rare few that are either considerably smaller than X or considerable bigger (outliers), but for the most of it, rabbits will be “just around” X in size. Same goes for any other quantifiable trait that depends on enough factors to be considered random.
They will most-likely follow what is called a Normal (or Gaussian) distribution, which is said to appear in nature all the time. The function that defines this distribution is also called the Gaussian Bell, due to the shape of the curve.