Any maker worth their bits will look for new ways to challenge themselves. [Robert Fotino], a computer science student at the University of California, is doing just that: designing and building his own lightweight hobbyist game console that he has appropriately named Consolite.
[Fotino] wrote his own compiler in C++ that converts from C-like languages to a custom-designed assembler that he has dubbed Consolite Assembly. To test his code, he also wrote an emulator before loading it onto the Mimas V2 FPGA board. Presently, Consolite uses 64KiB of main memory and 48 KiB of video memory; a future version will have 32 bit support to make better use of the Mimas’ 64 MiB of on board ram, but the current 16-bit version is a functional proof of concept.
An SD card functions as persistent storage for up to 256 programs, which can be accessed using the hardware switches on the Mimas, with plans to add user access in the form of saving game progress, storage outside of main memory, etc. — also in a future update that will include audio support.
As it stands, [Fotino] has written his own versions of Breakout, Tetris, and Tron to show off his project.
Not wanting for diligence, [Fotino] has provided thorough documentation of nearly every step along the way in his blog posts and on GitHub if you are looking for guidelines for any similar projects you might have on the back burner — like an even tinier game console.
One day [Andy] was cruising around eBay and spotted something interesting. Forty Virtex-E FPGAs for two quid each. These are the big boys of the FPGA world, with 512 user IO pins, almost 200,000 logic gates, packed into a 676-ball BGA package. These are not chips designed for the hobbyist. These chips are not designed for boards with less than six layers. These chips aren’t even designed for boards with 6/6mil tolerances from the usual suspects in China. By any account, a 676-ball package is not like a big keep out sign for hobbyists. You don’t turn down a £2 class in advanced PCB design, though, leading to one of the most impressive ‘I just bought some crap on eBay’ projects we’ve seen.
The project [Andy] had in mind for these chips was a generic dev board, which meant breaking out the IO pins and connecting some SRAM, SDRAM, and Flash memory. The first issue with this project is escape routing all the balls. Xilinx published a handy application note that recommends specific design parameters for the traces of copper under the chip. Unfortunately, this was a six-layer board, and the design rules in the application note were for 5/5mil traces. [Andy]’s board house can’t do six-layer boards, and their design rules are for 6/6mil traces. To solve this problem, [Andy] just didn’t route the inner balls, and hoped the 5mil traces would work out.
With 676 tiny little pads on a PCB, the clocks routed, power supply implemented, too many decoupling caps on the back, differential pairs, static RAM, a few LEDs placed just for fun, [Andy] had to solder this thing up. Since the FPGA was oddly one of the less expensive items on the BOM, he soldered that first, just to see if it would work. It did, which meant it was time to place the RAM, Flash, and dozens of decoupling caps. Everything went relatively smoothly – the only problem was the tiny 0402 decoupling caps on the back of the board. This was, by far, the hardest part of the board to solder. [Andy] only managed to get most of the decoupling caps on with a hot air gun. That was good enough to bring the board up, but he’ll have to figure some other way of soldering those caps for the other 30 or so boards.
Slowly, very slowly, the time when we don’t subject embedded beginners to AVRs and PICs is coming. At a glacial pace, FPGA development platforms are becoming ever more capable and less expensive. [Eric Brombaugh] has been playing around with both ARMs and FPGAs for a while now and decided to combine these two loves into a single board that’s capable of a lot.
This board is fittingly called an STM32F303 + ice5 development board, and does exactly what it says on the tin. There’s an STM32F303 on board providing a 32-bit CPU running at 72 MHz, 48 kB of SRAM, a quarter meg of Flash, and enough peripherals to keep anyone happy. The FPGA side of this board is a Lattice iCE5 with about 3k Look Up Tables (LUTs), and one time programmable non-volatile config memory.
The connections between the ARM and FPGA include a dedicated SPI port, and enough GPIOs to implement full-duplex I2S and a USART. Like all good projects, [Eric] has shared all the files, schematics, and BOMs required to make this board your very own reality, and has provided a few links to the development toolchains. While the FPGA is from Lattice’s ice40 family, it’s not supported by the Open Source Project Icestorm toolchain. Still, it’s a very capable board for ARM and FPGA development.
It’s not surprising that Analog to Digital Converters (ADC’s) now employ several techniques to accomplish higher speeds and resolutions than their simpler counterparts. Enter the Delta-Sigma (Δ∑) ADC which combines a couple of techniques including oversampling, noise shaping and digital filtering. That’s not to say that you need several chips to accomplish this, these days single chip Delta-Sigma ADCs and very small and available for a few dollars. Sometimes they are called Sigma-Delta (∑Δ) just to confuse things, a measure I applaud as there aren’t enough sources of confusion in the engineering world already.
I’m making this a two-parter. I will be talking about some theory and show the builds that demonstrate Delta-Sigma properties and when you might want to use them.
To decode the device’s packets he reached for his RTL-SDR receiver and took a look at it in software. GQRX confirmed the presence of the carrier and allowed him to record a raw I/Q file, which he could then supply to Inspectrum to analyse the packet structure. He found it to be a simple on-off keying scheme, with bits expressed through differing pulse widths. He was then able to create a Gnu Radio project to read and decode them in real time.
Emulating the transmitter was then a fairly straightforward process of generating a 350MHz clock using the on-board PLL and gating it with his generated data stream to provide modulation. The result was able to control his fan with a short wire antenna, indeed he was worried that it might also be doing so for other similar fans in his apartment complex. You can take a look at his source code on GitHub if you would like to try something similar.
It’s worth pointing out that a transmitter like this will radiate a significant amount of harmonics at multiples of its base frequency, and thus without a filter on its output is likely to cause interference. It will also be breaking all the rules set out by whoever the spectrum regulator is where you live, despite its low power. However it’s an interesting project to read, with its reverse engineering and slightly novel use of an FPGA.
A few years ago, [Artem] learned about ways to focus sound in an issue of Popular Mechanics. If sound can be focused, he reasoned, it could be focused onto a plane of microphones. Get enough microphones, and you have a ‘sound camera’, with each microphone a single pixel.
Movies and TV shows about comic books are now the height of culture, so a device using an array of microphones to produce an image isn’t an interesting demonstration of FFT, signal processing, and high-speed electronic design. It’s a Daredevil camera, and it’s one of the greatest builds we’ve ever seen.
[Artem]’s build log isn’t a step-by-step process on how to make a sound camera. Instead, he went through the entire process of building this array of microphones, and like all amazing builds the first step never works. The first prototype was based on a flatbed scanner camera, simply a flatbed scanner in a lightproof box with a pinhole. The idea was, by scanning a microphone back and forth, using the pinhole as a ‘lens’, [Artem] could detect where a sound was coming from. He pulled out his scanner, a signal generator, and ran the experiment. It didn’t work. The box was not soundproof, the inner chamber should have been anechoic, and even if it worked, this camera would only be able to produce an image or two a minute.
The idea sat in the shelf of [Artem]’s mind for a while, and along the way he learned about FFT and how the gigantic Duga over the horizon radar actually worked. Math was the answer, and by using FFT to transform a microphones signals from up-and-down to buckets of frequency and intensity, he could build this camera.
That was the theory, anyway. Practicality has a way of getting in the way, and to build this gigantic sound camera he would need dozens of microphones, dozens of amplifiers, and a controller with enough analog pins, DACs, and processing power to make sense of all of this.
This complexity collapsed when [Artem] realized there was an off-the-shelf part that was a perfect microphone camera pixel. MEMS microphones, like the kind found in smartphones, take analog sound and turn it into a digital signal. Feed this into a fast enough microcontroller, and you can perform FFT on the signal and repeat the same process on the next pixel. This was the answer, and the only thing left to do was to build a board with an array of microphones.
[Artem]’s camera microphone is constructed out of several modules, each of them consisting of an 8×8 array of MEMS microphones, controlled via FPGA. These individual modules can be chained together, and the ‘big build’ is a 32×32 array. After a few problems with manufacturing, the board actually worked. He was recording 64 channels of audio from a single panel. Turning on the FFT visualization and pointing it at a speaker revealed that yes, he had indeed made a sound camera.
The result is a terribly crude movie with blobs of color, but that’s the reality of a camera that only has 32×32 resolution. Right now the sound camera works, the images are crude, and [Artem] has a few ideas of where to go next. A cheap PC is fast enough to record and process all the data, but now it’s an issue of bandwidth; 30 sounds per second is a total of 64 Mbps of data. That’s doable, but it would need another FPGA implementation.
Is this sonic vision? Yes, technically the board works. No, in that the project is stalled, and it’s expensive by any electronic hobbyist standards. Still, it’s one of the best to grace our front page.
It always surprises us that magnetic levitation seems to have two main purposes: trains and toys. It is reasonably inexpensive to get floating Bluetooth speakers, globes, or just floating platforms for display. The idea is reasonably simple, especially if you only care about levitation in two dimensions. You let an electromagnet pull the levitating object (which is, of course, ferrous). A sensor detects when the object is at a certain height and shuts off the magnet. The object falls, which turns the magnet back on, repeating the process. If you do it right, the object will reach equilibrium and hover near the sensor.
Some students at Cornell University decided to implement the control loop to produce levitation using an Altera FPGA. An inductive sensor determined the position of an iron ball. The device uses a standard proportional integral derivative (PID) control loop. The control loop and PWM generation occur in the FPGA hardware. You can see a video of their result, below.