We should all be familiar with TV ambient lighting systems such as Philips’ Ambilight, a ring of LED lights around the periphery of a TV that extend the colors at the edge of the screen to the surrounding lighting. [Shiva Rajagopal] was inspired by his tutor to look at the mechanics of generating a more accurate color representation from video frames, and produced a project using an FPGA to perform the task in real-time. It’s not an Ambilight clone, instead it is intended to produce as accurate a color representation as possible to give the impression of a TV being on for security purposes in an otherwise empty house.
The concern was that simply averaging the pixel color values would deliver a color, but would not necessarily deliver the same color that a human eye would perceive. He goes into detail about the difference between RGB and HSL color spaces, and arrives at an equation that gives an importance rating to each pixel taking into account its saturation and thus how much the human eye perceives it. As a result, he can derive his final overall color by looking at these important pixels rather than the too-dark or too-saturated pixels whose color the user’s eye will not register.
The whole project was produced on an Altera DE2-115 FPGA development and education board, and makes use of its NTSC and VGA decoding example code. All his code is available for your perusal in his appendices, and he’s produced a demo video shown here below the break.
Continue reading “Using An FPGA To Generate Ambient Color From Video”
If we have to make a list of Projects that are insane and awesome at the same time, this would probably be among the top three right up there. For the past few years, [James Newman] has been busy building Megaprocessor – a huge micro-processor made out of transistors and LED’s, thousands of ’em. “I started by wanting to learn about transistors. Things got out of hand.” And quite appropriately, he’s based out of Cambridge – the “City of perspiring dreams“. The Why part is pretty simple – because he can. We posted about his build as recently as 10 months back, but he’s made a ton of progress since then and an update seemed in order.
How big is it ? For starters, the 8-bit adder module is about 300mm (a foot) long – and he’s using five of them. When fully complete, it will stretch 14m wide and stand 2m tall, filling a 30 sq.m room, consisting of seven individual frames that form the parts of the Megaprocessor.
The original plan was for nine frames but he’s managed to squeeze all parts in to seven, building three last year and adding the other four since then. Assembling the individual boards (gates), putting them together to form modules, then fitting it all on to the frames and putting in almost 10kms of cabling is a slow, painstaking job, but he’s been on fire last few months. He has managed to test and integrate the racks shown here and even run some code.
The Megaprocessor has a 16-bit architecture, seven registers, 256bytes of RAM and a questionable amount of PROM (depending on his soldering endurance, he says). It sips 500W, most of it going to light up all the LED’s. He guesses it weighs about half a ton. The processor uses up 15,300 transistors and 8,500 LED’s, while the RAM has 27,000 transistors and 2,048 LED’s. That puts it somewhere between the 8086 and the 68000 microprocessors in terms of number of transistors. He recently got around to calculating the money he’s spent on this to date, and it is notching up over 40,000 Quid (almost $60,000 USD)! You can read a lot of other interesting statistics on the Cost and Materials page.
Continue reading “Megaprocessor is a Macro Microprocessor”
[Tsvetan Usunov] has been Mr. Olimex for about twenty five years now, and since then, he’s been through a lot of laptops. Remember when power connectors were soldered directly to the motherboard? [Tsvetan] does, and he’s fixed his share of laptops. Sometimes, fixing a laptop doesn’t make any sense; vendors usually make laptops that are hard to repair, and things just inexplicably break. Every year, a few of [Tsvetan]’s laptops die, and the batteries of the rest lose capacity among other wear and tear. Despite some amazing progress from the major manufacturers, laptops are still throwaway devices.
Since [Tsvetan] makes ARM boards, boards with the ~duino suffix, and other electronic paraphernalia, it’s only natural that he would think about building his own laptop. It’s something he’s been working on for a while, but [Tsvetan] shared his progress on an Open Source, hacker’s laptop at the Hackaday | Belgrade conference.
Continue reading “The Open Source Hacker’s Laptop”
If you have a computer on your desk today, the chances are that it has an Intel architecture and is in some way a descendant of the IBM PC. It may have an Apple badge on the front, it may run Linux, or Windows, but in hardware terms the overwhelming probability is that it will be part of the Intel monoculture. A couple of decades ago though in the 16- and early 32-bit era you would have found a far greater diversity of architectures. Intel 3-, and 486s in PCs and clones, Macintosh, Commodore, and Atari platforms with the 68000 family, the WDC 65C816 in the Apple IIGS, and the Acorn Archimedes with an early ARM processor to name but a few.
In the tough environment of the 1990s most of these alternative platforms fell by the wayside. Apple survived to be revitalised under a returning Steve Jobs, Atari and Commodore withered under a bewildering succession of takeovers, and Acorn split up and lost its identity with its processor licensing subsidiary going on to power most of the mobile devices we take for granted today.
Surprisingly though some of the 16-bit platforms refused to die when their originators faded from view. In particular Commodore’s Amiga has lived on with new OS versions, new platforms, and community-supported hardware upgrades. News of just such a device came our way this morning, [Lukas Hartmann]’s MNT VA2000, a graphics card for the Amiga 2000 using a GPU implemented on an FPGA.
Continue reading “Bootstrapping an Amiga 2000 Graphics Card Because Vintage is Pricey”
Researchers at Binghamton University have built their own graphics processor unit (GPU) that can be flashed into an FGPA. While “graphics” is in the name, this GPU design aims to provide a general-purpose computing peripheral, a GPGPU testbed. Of course, that doesn’t mean that you can’t play Quake (slowly) on it.
The Binghamton crew’s design is not only open, but easily modifiable. It’s a GPGPU where you not only know what’s going on inside the silicon, but also have open-source drivers and interfaces. As Prof. [Timothy Miller] says,
It was bad for the open-source community that GPU manufacturers had all decided to keep their chip specifications secret. That prevented open source developers from writing software that could utilize that hardware. With contributions from the ‘open hardware’ community, we can incorporate more creative ideas and produce an increasingly better tool.
That’s where you come in. [Jeff Bush], a member of the team, has a great blog with a detailed walk-through of a known GPU design. All of the Verilog and C++ code is up on [Jeff]’s GitHub, including documentation.
If you’re interested in the deep magic that goes on inside GPUs, here’s a great way to peek inside the black box.
Have you ever started a project, run into an issue, started a new project to solve the issue, and completely forgot about the original project? [Andy] went down a rabbit hole of needing a tool to calibrate an MCU oscillator, but not having an accurate way to measure frequency. Most people would just buy a frequency counter and be done with it, but [Andy] decided to build his own.
The Nanocounter is an accurate, open source frequency counter that uses an Android phone as its display. It’s based on a high accuracy temperature compensated crystal oscillator (TCXO) fed into a phase locked loop (PLL) to create a high frequency, accurate reference clock.
This reference clock, along with the signal to be measured, are sent into a Xilinx FPGA which uses a method called equal precision measurement to determine the frequency. A STM32F072 microcontroller uses a SPI interface to get this data out of the FPGA, and controls the whole system. Finally, a cheap HC-06 Bluetooth module facilitates communication with an Android device.
The project achieves the goal of frequency counting, though [Andy] doesn’t remember what project sparked the idea to build it. (Classic yak shaving!) But the result is a great read of a detailed writeup, and you can watch a video of the Nanocounter in action after the break. That’s a win in our book.
Continue reading “Nanocounter: Frequency Counter with an Android UI”
We have talked about a whole slew of logic and interconnect technologies including TTL, CMOS and assorted low voltage versions. All of these technologies have in common the fact that they are single-ended, i.e. the signal is measured as a “high” or “low” level above ground.
This is great for simple uses. But when you start talking about speed, distance, or both, the single ended solutions don’t look so good. To step in and carry the torch we have Differential Signalling. This is the “DS” in LVDS, just one of the common standards throughout industry. Let’s take a look at how differential signaling is different from single ended, and what that means for engineers and for users.
Single Ended: TTL, CMOS, LVTTL, Etc.
Single Ended and Sources of Noise
Collectively, standards like TTL, CMOS, and LVTTL are known as Single Ended technologies and they have in common some undesirable attributes, namely that ground noise directly affects the noise margin (the budget for how much noise is tolerable) as well as any induced noise measured to ground directly adds to the overall noise as well.
By making the voltage swing to greater voltages we can make the noise look smaller in proportion but at the expense of speed as it takes more time to make larger voltage swings, especially with the kind of capacitance and inductance we sometimes see.
Enter Differential Signaling where we use two conductor instead of one. A differential transmitter produces an inverted version of the signal and a non-inverted version and we measure the desired signal strictly between the two instead of to ground. Now ground noise doesn’t count (mostly) and noise induced onto both signal lines gets canceled as we only amplify the difference between the two, we do not amplify anything that is in common such as the noise.
Continue reading “When Difference Matters: Differential Signaling”