HDMI Extender Reverse Engineered

June 9, 2016 by Elliot Williams 41 Comments

[danman] has been playing around with various HDMI video streaming options, and he’s hit on a great low-cost solution. A $40 “HDMI extender” turns out to actually be an HDMI-to-RTP converter under the hood.

He’d done work previously on a similar extender that turned out to use a quirky method to send the video, which he naturally reversed and made to do his bidding. But non-standard formats are a pain. So when he was given a newer version of the same device, and started peeking into the packets with Wireshark, he was pleasantly surprised to find that the output was just MPEG-encoded video over RTP. No hacking necessary.

Until now, streaming video over an IP network from an arbitrary HDMI output has been tricky, [danman] has been more than a little obsessed with getting it working on the cheap. In addition to the previous version of this extender, he also managed to get a stream out of a rooted Android set-top box. That costs a bit more, but can also record at the same time, should you need to.

None of this solves the HDMI HDCP encryption problem, though. You’re on your own for that one.

(Those of you Wireshark wizards out there will note that we just swiped the headline image from the previous version of the project. There were no good images for this one. Sorry about that.)

Gcc: Some Assembly Required

June 8, 2016 by Al Williams 51 Comments

There was a time when you pretty much had to be an assembly language programmer to work with embedded systems. Yes, there have always been high-level languages available, but it took improvements in tools and processors for that to make sense for anything but the simplest projects. Today, though, high-quality compilers are readily available for a lot of languages and even an inexpensive CPU is likely to outperform even desktop computers that many of us have used.

So assembly language is dead, right? Not exactly. There are several reasons people still want to use assembly. First, sometimes you need to get every clock cycle of performance out of a chip. It can be the case that a smart compiler will often produce better code than a person will write off the cuff. However, a smart person who is looking at performance can usually find a way to beat a compiler’s generated code. Besides, people can make value trades of speed versus space, for example, or pick entirely different algorithms. All a compiler can do is convert your code over as cleverly as possible.

Besides that, some people just like to program in assembly. Morse code, bows and arrows, and steam engines are all archaic, but there are still people who enjoy mastering them anyway. If you fall into that category, you might just want to write everything in assembly (and that’s fine). Most people, though, would prefer to work with something at a higher level and then slip into assembly just for that critical pieces. For example, a program might spend 5% of its time reading data, 5% of its time writing data, and 90% of the time crunching data. You probably don’t need to recreate the reading and writing parts. They won’t go to zero, after all, and so even if you could cut them in half (and you probably can’t) you get a 2.5% boost for each one. That 90% section is the big target.

The Profiler

Sometimes it is obvious what’s taking time in your programs. When it isn’t, you can actually turn on profiling. If you are running GCC under Linux, for example, you can use the -pg option to have GCC add profiling instrumentation to your code automatically. When you compile the code with -pg, it doesn’t appear to do anything different. You run your program as usual. However, the program will now silently write a file named gmon.out during execution. This file contains execution statistics you can display using gprof (see partial output below). The function b_fact takes up 65.9% of CPU time.

If you don’t have a profiling option for your environment, you might have to resort to toggling I/O pins or writing to a serial port to get an idea of how long your code spends doing different functions. However you do it, though, it is important to figure it out so you don’t waste time optimizing code that doesn’t really affect overall performance (this is good advice, by the way, for any kind of optimization).

Assembly

If you start with a C or C++ program, one thing you can do is ask the compiler to output assembly language for you. With GCC, use a file name like test.s with the -o option and then use -S to force assembly language output. The output isn’t great, but it is readable. You can also use the -ahl option to get assembly code mixed with source code in comments, which is useful.

You can use this trick with most, if not all, versions of GCC. Of course, the output will be a lot different, depending. A 32-bit Linux compiler, a 64-bit Linux compiler, a Raspberry Pi compiler, and an Arduino compiler are all going to have very different output. Also, you can’t always figure out how the compiler mangles your code, so that is another problem.

If you find a function or section of code you want to rewrite, you can still use GCC and just stick the assembly language inline. Exactly how that works depends on what platform you use, but in general, GCC will send a string inside asm() or __asm__() to the system assembler. There are rules about how to interact with the rest of the C program, too. Here’s a simple example from the a GCC HOWTO document (from a PC program):

__asm__ ("movl %eax, %ebx\n\t"
"movl $56, %esi\n\t"
"movl %ecx, $label(%edx,%ebx,$4)\n\t"
"movb %ah, (%ebx)");

You can also use extended assembly that lets you use placeholders for parts of the C code. You can read more about that in the HOWTO document. If you prefer Arduino, there’s a document for that, too. If you are on ARM (like a Raspberry Pi) you might prefer to start with this document.

So?

You may never need to mix assembly language with C code. But if you do, it is good to know it is possible and maybe not even too difficult. You do need to find what parts of your program can benefit from the effort. Even if you aren’t using GCC, there is probably a way to mix assembly and your language, you just have to learn how. You also have to learn the particulars of your platform.

On the other hand, what if you want to write an entire program in assembly? That’s even more platform-specific, but we’ll look at that next time.

High Voltage Please, But Don’t Forget The Current

June 8, 2016 by Steven Dufresne 30 Comments

In high voltage applications involving tens of thousands of volts, too often people think about the high voltage needed but don’t consider the current. This is especially so when part of the circuit that the charge travels through is an air gap, and the charge is in the form of ions. That’s a far cry from electrons flowing in copper wire or moving through resistors.

Consider the lifter. The lifter is a fun, lightweight flying machine. It consists of a thin wire and an aluminum foil skirt separated by an air gap. Apply 25kV volts across that air gap and it lifts into the air.

Lifter flying with high voltage power supply

Lifter parts

So you’d think that the small handheld Van de Graaff generator pictured below, that’s capable of 80kV, could power the lifter. However, like many high voltage applications, the lifter works by ionizing air, in this case ionizing air surrounding the thin wire resulting in a bluish corona. That sets off a chain of events that produces a downward flowing jet of air, commonly called ion wind, lifting the lifter upward.

Continue reading “High Voltage Please, But Don’t Forget The Current” →

One Man’s Awesome Collection Of Projects Done Over A Lifetime

June 7, 2016 by Gerrit Coetzee 21 Comments

[Robert Glaser] kept all his projects, all of them, from the 1960s to now. What results is a collection so pure we feel an historian should stop by his house, if anything, to investigate the long-term effects of the knack.

He starts with an opaque projector he built in the third grade, which puts it at 1963. Next is an, “idiot box,” which looks suspiciously like “the Internet”, but is actually a few relaxation oscillators lighting up neon bulbs. After that, the condition really sets in, but luckily he’s gone as far as to catalog them all chronologically.

We especially enjoyed the computer projects. It starts with his experiences with punch cards in high school. He would hand-write his code and then give it to the punch card ladies who would punch them out. Once a week, a school-bus would take the class to the county’s computer, and they’d get to run their code. In university he got to experience the onset of UNIX, C, and even used an analog computer for actual work.

There’s so much to read, and it’s all good. There’s a section on Ham radio, and a very interesting section on the start-up and eventual demise of a telecom business. Thanks to reader, [Itay Ramot], for the tip!

Stay Scrappy, Hackers! Hardware Startups Versus Goliath

June 7, 2016 by Bob Baddeley 64 Comments

A toast to all the hackers out there who like to do it scrappy, who fight hard to get your products to work, who make your own tools and testing jigs and assembly lines in your basement, and who pound the pavement (and the keyboards) to get your product out there. Here’s to you (*clink*).

I had the fortune of a job interview recently in a big faceless company that you may have never heard of but probably use their stuff all the time. They make billions. And it was surreal. This article is about what it’s like for a scrappy start-up engineer to walk into the belly of the beast of an organization that counts its engineers in the tens of thousands. For obvious reasons, I can’t go into specific details, but let me paint for you in broad strokes what you, the hacker and entrepreneur, are up against.

When you have a company that’s been around for decades and whose yearly sales volume has more digits than some countries, everything is a few orders of magnitude bigger in scale. People, resources, volumes, everything.

Continue reading “Stay Scrappy, Hackers! Hardware Startups Versus Goliath” →

Hacking A Fluke Multimeter To Serve Readings Over WiFi

June 7, 2016 by Jenny List 48 Comments

Your multimeter is probably your most useful instrument if you work regularly with electronics. It goes with you everywhere, and is your first port of call in most cases when you are presented with a piece of equipment. And when you think about it, it’s a pretty amazing instrument. Multimeter technology has advanced to the point at which even an inexpensive modern device has functions that would have required a hefty budget a few decades ago.

There is still one thing affordable multimeters remain unable to do: they can’t log their readings for analysis on a computer. They’re an instantaneous instrument, just as they always have been.

Lord of Hackaday [Sprite_TM] decided to hack his multimeter to serve its readings over Wi-Fi. Rather than start with a throwaway meter from the bargain bin, he did it with a Fluke. The meter he chose was a Fluke 15B+, the company’s budget offering for the Indian and Chinese markets, since he had one spare.

Opening up the 15B+, he was presented with its processor concealed under a blob of epoxy and thus unidentifiable. Armed with the knowledge that other similar Flukes contain Fortune Semiconductor parts, he investigated as many data sheets as he could find from the same company and finally identified it as an FS98O24 one-time-programmable microprocessor. Sadly this chip has no serial port, but he did find an I2C EEPROM which he correctly guessed held calibration settings. Removing this chip gave him a meter with slightly off calibration, but also gave him a serial port of sorts.

Further detective work allowed him to identify the baud rate, and supplying random commands delivered him some that returned data packets. Eventually he identified a packet containing the states of the LCD’s segments, from which he could derive its displayed value. Connecting an ESP8266 module with appropriate software left him with a Wi-Fi connected multimeter. There was a little more refinement to his hack, he created a power management board to activate the ESP when needed, and a neat hack to display its IP address on the screen.

Multimeter hacks have featured several times here at Hackaday. We’ve had another serial port hack, or how about a remote display for another Fluke on a Gameboy Advance?

Mining Platinum From The Road

June 6, 2016 by Jenny List 94 Comments

For several decades now all petrol-driven motor vehicles have had to feature a catalytic converter in their exhaust systems to meet the requirements of emissions legislation. These feature a high surface area coated with platinum, palladium, and rhodium, which catalyses the high-temperature breakdown of the exhaust gasses.

When a vehicle reaches the end of its life its catalytic converter is recycled and those metals are recovered, but this recovery does not account for all the metal. [Cody Reeder] noticed that the weight of platinum in a catalytic converter taken from a scrap vehicle is significantly less than that of a new one. Some of that metal has escaped, so where has it gone?

The answer to that question is that it has become detached from the converter and blown out through the rear of the exhaust pipe. Therefore in the area around a busy highway with many thousands of cars passing there must be a reasonable concentration of platinum. The video below the break details [Cody]’s quest to verify that theory, and it opens with him and a friend sweeping dust from beside a freeway in the early hours. The resulting bags contain a lot of gravel and bits of tire, plus a few cigarette butts and a large amount of very fine dust. He sieves away the debris, and heats a sample of dust in a furnace with a flux mixture containing lead oxide. He hopes that as this oxide degrades to metallic lead it will dissolve any platinum and settle in the bottom of his crucible, and indeed when he pours out the resulting slag there is a bead of lead. Taking away the lead reveals a speck of impure platinum, which he further purifies and assays to determine the percentage of platinum and to detect the other catalyst metals.

He finally arrives at a figure of 6.7 g per ton of his fine-sifted roadside dirt “ore”, a figure which as he points out would be considered quite valuable were it to be encountered in a mine. His process might be a little difficult for individuals with sweeping brushes to hit pay dirt and a modern gold rush to descend on their local Interstate, but it’s not impossible that a highways agency equipped with sweeper trucks could have the metal extracted at a more profitable level.

Continue reading “Mining Platinum From The Road” →