The original Weather Prognosticator worked well for several years, but the downside to relying on an external API is that it can get changed out from under you. Or removed entirely.
Last Fall, Weather Underground turned off the API that the Prognosticator had been using. I’d be tempted to ask for my money back, except that it was a free API. Oh, well.
Fortunately, other solutions exist, and OpenWeather’s API is still more or less what is needed. Their hourly data requires a subscription, but three-hour temperature forecasts are still free (within reason.) This means that, instead of displaying hourly temperature forecasts, data is available in three-hour increments — but is available several days out. So instead of displaying hourly data for the next ten hours, the display now shows three-hour temperatures for the next thirty.
The updated code is available here; you will need a free OpenWeatherMap API to be able to use the API.
Microcontrollers are deservedly a favorite component for many electronics hobbyists. They’re straightforward to use, cheap, powerful, and capable of doing any number of simple tasks well. The popularity of the Arduino ecosystem — not just the boards, but the IDE and the whole Arduino way of doing things — makes microcontroller-based prototyping easy, fast, and fun.
Although popular dev boards like Digilent‘s BASYS series do exist, FPGAs have been largely left out of this revolution. Programming even a low-end Spartan3E FPGA requires downloading, licensing, configuring, and installing ISE Webpack — a huge set of utilities from Xilinx. The download is several gigabytes, and it all unpacks to something like 10GB once installed.
Webpack, like the name would imply, is a suite of programs that work together to produce the final configuration bitstream for the FPGA. The IDE works with a synthesis tool as well as PlanAhead, where you plan out the inputs and outputs in terms of pins on the FPGA itself (not the board.) Once all that is done, you generally need an uploader program like Digilent‘s Adept. This is straightforward and reliable to use, but it’s an additional step.
Wouldn’t it be nice if something more like the Arduino IDE existed, with an option to quickly compile-and-upload to test code? Even better, what if you could use such an IDE with an inexpensive, breadboardable FPGA-on-a-stick?
The TinyFPGA BX board, wired up with some test peripherals.
The TinyFPGA BX board, plus the amazing ICEStudio IDE, makes this a reality. We finally have an open-source FPGA toolchain that makes getting up and prototyping with FPGAs almost as easy as programming an Arduino board.
FPGAs are, of course, fundamentally different from microcontrollers. Instead of having a fixed set of instructions to be executed, FPGAs are best thought of as a “sea of logic gates” which can be made into whatever sort of digital hardware you need for your task. You don’t tell them what to do — you tell them what to be.
If you’re used to thinking procedurally and writing programs in procedural languages such as C (and Python, and Java, and BASIC, and Fortran, and so on), this can take some getting used to. (One popular solution is to actually instantiate a microcontroller in the FPGA logic, and then program that in C, which sounds like cheating but works.)
The advantages to FPGAs, though, are that they’re inherently as parallel as you want them to be. FPGAs don’t have to just do one thing at a time; they can have hundreds or thousands of processes executing independently on different parts of the chip. They’re also fast. The TinyFPGA BX runs at 16MHz, which is pretty slow for an FPGA — but because the logic is so configurable, it can get a lot done in that one clock cycle. Simple Boolean logic and binary arithmetic can be done in real time, even if you need dozens or hundreds of calculations done in parallel.
ICEStudio tries to make this way of developing as intuitive as possible. FPGA-based design is often done with a mix of code and schematic capture, with data in the form of either single bits or buses representing binary numbers being carried from one module to another by lines.
For devices like FPGAs, which can be thought of as dataflow devices more than as procedural devices, it works. This approach is flexible enough to allow you to code what you like and connect the rest. Click on a module, edit the code, then press ctrl-u to compile and upload. Easy.
ICEStudio, showing a solution for a LED wave-of-light demo. (Click for larger)
A breadboardable, open-source FPGA toolchain — and one that can go from updated code to reprogrammed board in ten seconds or so (for simple solutions like the example above)?
Computers generally don’t solve problems the same way humans do.
Take Sudoku, for instance. A human Sudoku player will usually look for patterns in the existing numbers, looking for possible spots to place a 1, 2, 3, etc. Or maybe they will notice that a particular square has everything but a 7 and 8, with one in line with another 8, and will deduce what goes where based on that. We look for what makes sense, and try to piece together a rational solution based on logic and observation.
Such relatively sophisticated, creative, intuitive heuristics don’t always represent the easiest way to solve a problem using a computer. Sometimes a simple exhaustive search (one that my former Calculus teacher called the “Brute Force and Ignorance” approach) is best. After all, modern computers have a lot of brute force to bring to bear!
How could one most simply describe how to solve a Sudoku puzzle, given that the solver could follow instructions exactly — and was really, really fast at carrying them out? One method would be to try every single possible combination until something works, backtracking when you come across a dead end. Try to place a “1” in the first blank square, and check to see if there are any conflicts. If not, good — write it down and solve the remaining puzzle. If no such solution exists, or the “1” doesn’t fit, erase it and try a “2” there — and so on. This is the algorithm presented in an excellent recent Computerphile video about how to solve Sudoku in Python.
For some problems, like Chess, this kind of approach is untenable, since it won’t finish before the expected heat death of the Universe. Chess, while nowhere near as complex as Go, still has something like 10^120 possible games.
For Sudoku, however, this works surprisingly well. Most numbers that are tried are dead ends — but if so, they are usually found out quickly. If the algorithm successfully placed a “1,” for instance, it will still blindly try to place a “1” right next to it, since that’s the next step. This will fail, but it will fail quickly, allowing the algorithm to advance and try a “2” and then “3” until it finds something that sticks. No human would check all of these clearly-wrong branches — but they also take much longer to check the plausible ones.
How long would such a dumb, brute-force algorithm take to solve a Sudoku? I wasn’t sure — maybe years? So I tried programming it in C. (Here is the source file.) The example puzzle from the video was solved in about 120 milliseconds on my (ten-year-old but still modern-ish) PC, after having searched 37,652 possible number placements. Not bad!
Next, I looked for a real challenge, and came across what is said to be the world’s hardest Sudoku puzzle…
The “World’s hardest Sudoku,” by Arlo Irkala of AISudoku.com.
This is a nasty one! Nothing obvious jumps out at you, although in a few cases, you can narrow down the choices a bit and start to make progress. I entered in the data and re-ran the program.
This puzzle put up a good fight — there was actually a noticeable pause before the solution displayed — but roughly 1.65 seconds (and maybe something like five billion clock cycles) later, the unique solution popped up:
Nasty, but still solvable!
Lots of progress has been made on many fascinating, important problems by coming up with new algorithms. QuickSort, hashes, distributed computing, heuristics, and similar advancements have made efficient search engines possible. Clever branch-and-bound approaches have enabled Chess (and probably Go) engines to outplay any human.
But sometimes, all you really need is a big hammer.
While working on an electromagnetic project, I needed to control a series of solenoid coils. This sort of thing is usually handled by switching the low side — connect one terminal of each coil to a power rail, and use an NFET to connect the other side to ground when you want to fire it.
It’s great in theory — but the problem with inductive loads is that they react badly to having the current cut off, generating a potentially very large voltage across their terminals as the magnetic field collapses in response to a cutoff of the current to the coil. (Inductors are sometimes thought of as “mass” when comparing electronic oscillators to mechanical mass-and-spring systems. An inductor with current flowing through it is somewhat like a moving electrical mass. All that energy has to go somewhere!)
Many MOSFETs, including the IRF510s I was using, have a built-in flyback diode to address this problem. (You can see this on the datasheet as a diode with its anode connected to the source and its cathode connected to the drain.) This diode is reverse biased against the normal voltage present across the FET when it’s off, but allows current to continue flowing when the FET cuts off. Theoretically, roughly the same current should continue flowing in the coil since the diode would continue to conduct once the voltage became over 600mV or so.
An exploded IRF510 NMOSFET. Inductors can store quite a bit of energy!
Or, rather, that’s what was supposed to happen. What actually happened was a 100ms coil firing, followed by the FET turning into a small firecracker.
It’s pretty clear what happened — when the current was interrupted, the flyback diode couldn’t handle the inrush current from the coil. The datasheet claimed a pulse current rating of 20A and each coil has a resistance of roughly 2 ohms. So at 30V (the setting which caused the explosion), it should have seen a current of about 15A, even assuming a zero-ohm on resistance.
This actually worked out fine for the pulse itself (the coil did fire), but was apparently too much for the flyback diode. The preliminary postmortem is that it seems to have been basically vaporized by the current pulse, blowing the encapsulation in half and somehow even managing to kill the controlling Arduino in the process. (I’ll reuse what I can from it — maybe I can just swap out the chip.) Note to self: FETs can send killer pulses up the gate lead when caused to explode.
Oh, well. Beefier transistors and some large Schottky diodes should hopefully fix the issue. And some protection for the Arduino. I suppose I could just lower the rail voltage — but where’s the fun in that?
