Reverse Engineering Wireless Temperature Probes

[bhunting] lives right up against the Rockies, and for a while he’s wanted to measure the temperature variations against the inside of his house against the temperature swings outside. The sensible way to do this would be to put a few wireless temperature-logging probes around the house, and log all that data with a computer. A temperature sensor, microcontroller, wireless module, battery, case, and miscellaneous parts meant each node in the sensor grid would cost about $10. The other day, [bhunting] came across the exact same thing in the clearance bin of Walmart – $10 for a wireless temperature sensor, and the only thing he would have to do is reverse engineer the protocol.

These wireless temperature sensors are exactly what you would expect for a cheap piece of Chinese electronics found in the clearance bin at Walmart. There’s a small radio operating at 433MHz, a temperature sensor, and a microcontroller under a blob of epoxy. The microcontroller and transmitter board in the temperature sensor were only attached by a ribbon cable, and each of the lines were labeled. After finding power and ground, [bhunting] took a scope to the wires that provided the data to the radio and took a look at it with a logic analyzer.

After a bit of work, [bhunting] was able to figure out how the temperature sensor sent data back to the base station, and with a bit of surgery to one of these base stations, he had a way to read the temperature data with an Arduino. From there, it’s just a data logging problem that’s easily solved with Excel, and [bhunting] has exactly what he originally wanted, thanks to a find in the Walmart clearance bin.

Using MATLAB and SDR to Reverse Engineer 433MHz Messages

Hackers everywhere are having a lot of fun with SDR – as is obvious from the amount of related posts here on Hackaday. And why not, the hardware is cheap and easily available. There are all kinds of software tools you can use to dig in and explore, such as SDR# , Audacity, HDSDR and so on. [illias] has been following SDR projects for a while, which piqued his interest enough for him to start playing with it. He didn’t have any real project in mind so he focused on studying the methodology and the tools available for analyzing 433MHz RF transmission. He describes the process of using MATLAB to recover the transmissions being received by the SDR

He started off by studying the existing tools available to uncover the details of the protocol. The test rig uses an Arduino UNO with the rc-switch library to transmit via a common and inexpensive 433MHz module. SDR# is used to record the transmissions and Audacity allows [illias] to visualize the resulting .wav files. But the really interesting part is where he documents the signal analysis using MATLAB.

He used the RTL-SDR package in conjunction with the Communications System Toolbox to perform spectrum analysis, noise filtering and envelope extraction. MATLAB may not be the easiest to work with, nor the cheapest, but its powerful features and the fact that it can easily read data coming from the SDR makes it an interesting tool. For the full skinny on what this SDR thing is all about, check out Why you should care about Software Defined Radio.

Reverse Engineer then Drive LCD with FPGA

Fans of [Ben Heck] know that he has a soft spot for pinball machines and his projects that revolve around that topic tend to be pretty epic. This is a good example. At a trade show he saw an extra-wide format LCD screen which he thought would be perfect on a pinball build. He found out it’s a special module made for attaching to your car’s sun visor. The problem is that it only takes composite-in and he wanted higher quality video than that offers. The solution: reverse engineer the LCD protocol and implement it in an FPGA.

This project is a soup to nuts demonstration of replacing electronics drivers; the skill is certainly not limited to LCD modules. He starts by disassembling the hardware to find what look like differential signaling lines. With that in mind he hit the Internet looking for common video protocols which will help him figure out what he’s looking for. A four-channel oscilloscope sniffs the signal as the unit shows a blue screen with red words “NO SIGNAL”. That pattern is easy to spot since the pixels are mostly repeated except when red letters need to be displayed. Turns out the protocol is much like VGA with front porch, blanking, etc.

With copious notes about the timings [Ben] switches over to working with a Cyclone III FPGA to replace the screen’s stock controller. The product claims 800×234 resolution but when driving it using those parameters it doesn’t fill the entire screen. A bit more tweaking and he discovers the display actually has 1024×310 pixels. Bonus!

It’s going to take us a bit more study to figure out exactly how he boiled down the sniffed data to his single color-coded protocol sheet. But that’s half the fun! If you need a few more resources to understand how those signals work, check out one of our other favorite FPGA-LCD hacks.

Continue reading “Reverse Engineer then Drive LCD with FPGA”

Reverse-Engineering a Superior Chinese Product

It makes an Arduino look like a 555.  A 364 Mhz, 32 bit processor. 8 MB RAM. GSM. Bluetooth. LCD controller. PWM. USB and dozens more. Smaller than a Zippo and thinner than corrugated cardboard. And here is the kicker: $3. So why isn’t everyone using it? They can’t.

Adoption would mandate tier after tier of hacks just to figure out what exact hardware is there. Try to buy one and find that suppliers close their doors to foreigners. Try to use one, and only hints of incomplete documentation will be found. Is the problem patents? No, not really.

[Bunnie] has dubbed the phenomenon “Gongkai”, a type of institutionalized, collaborative, infringementesque knowledge-exchange that occupies an IP equivalent of bartering. Not quite open source, not quite proprietary. Legally, this sharing is only grey-market on paper, but widespread and quasi-accepted in practice – even among the rights holders. [Bunnie] figures it is just the way business is done in the East and it is a way that is encouraging innovation by knocking down barriers to entry. Chinese startups can churn out gimmicky trash almost on whim, using hardware most of us could only dream about for a serious project.

Continue reading “Reverse-Engineering a Superior Chinese Product”

Counting Transistors In The Playstation

Over in Russia there are a few people doing extremely in-depth technical teardowns, and the latest is one of the most ambitious ever seen. The PSXDEV team is tearing into the heart of the original PlayStation (Google translatrix), looking at 300,000 transistors, and re-implementing the entire console in a logic level simulator.

While the CPU in the PSX is unique to that specific piece of hardware, a lot of this custom silicon can be found in other places. The core – a RISC LSI LR33300 – is documented in a few rare tomes that are somehow available for free on the Internet. Other parts of this chip are a little stranger. There is a bizarre register that isn’t documented anywhere, a Bus Unit that handles the access between various devices and peripherals, and a motion picture decompressor.

The reverse engineering process begins by de-encapsulating the CPU, GPU, sound processing unit, and CD-ROM controller, taking very high magnification photos of the dies, and slowly mapping out the semiconductors and metals to figure out what cells do what function, how they’re connected, and what the big picture is. It’s a painstaking process that requires combing through gigabytes of die shots and apparently highlight gates, wires, and busses with MS Paint.

The end result of all this squinting at a monitor is turning tracings of chips into logic elements with Logisim. From there, the function of the CPU can be understood, studied, and yes, eventually emulated down to the gate level. It’s an astonishing undertaking, really.

If this sort of thing sounds familiar, you’re right: the same team behind PSXDEV is also responsible for a similar effort focused on the Nintendo Entertainment System. There, the CPU inside the NES – the Ricoh 2A03 – was torn down, revealing the 6502 core, APU, DMA, and all the extra bits that made this a custom chip.

Thanks [Rasz] for the tip.

Reverse Engineering a Robotic Arm

Not too many people will argue that Robot Arms aren’t cool. [Dan] thinks they are cool and purchased a LabVolt Armdroid robotic arm on eBay for a mere $150. Unfortunately, he did not get the power supply or the control unit. To most, this would a serious hurdle to overcome, but not for [Dan]. He opened up the robot and started probing around the circuit board to figure out what was going on.

Since there was a DB9 connector on the outside of the robot arm, he assumed it was a standard RS-232 controlled device. Good thing he checked the internal circuitry because this was not the case at all. There was no mircocontroller or microprocessor found inside.  [Dan] painstakingly reversed engineered the circuit board and documented his results. He found that there were SN76537A chips that drove the 6 unipolar stepper motors and SN75HC259 latches to address each individual motor.

Now knowing how the robot works, [Dan] had to figure out how to control the robot from his computer. He started by making a custom Parallel Port to DB9 cable to connect the computer to the arm. After a series of several programs, starting with simply moving just one arm joint, the latest iteration allows manual control of all joints using the computer keyboard. A big ‘Thanks’ goes out to [Dan] for all his work and documentation.

 

Reverse Engineering Super Animal Cards

If you don’t have a niece or nephew we encourage you to get one because they provide a great excuse to take apart kids’ toys.

[Sam] had just bought some animal-themed trading cards. These particular cards accompany a card-reader that uses barcodes to play some audio specific to each animal when swiped. So [Sam] convinces her niece that they should draw their own bar codes. Of course it’s not that easy: the barcodes end up having even and odd parity bits tacked on to verify a valid read. But after some solid reasoning plus trial-and-error, [Sam] convinces her niece that the world runs on science rather than magic.

But it can’t end there; [Sam] wants to hear all the animals. Printing out a bunch of cards is tedious, so [Sam] opens up the card reader and programs and Arduino to press a button and blink an IR LED to simulate a card swipe. (Kudos!) Now she can easily go through all 1023 possible values for the animal cards and play all the audio tracks, and her niece gets to hear more animal sounds than any child could desire.

Along the way, [Sam] found some interesting non-animal sounds that she thinks are Easter eggs but we would wager are for future use in a contest or promotional drawing or something similar. Either way, its great fun to get to listen in on more than you’re supposed to. And what better way to educate the next generation of little hackers than by spending some quality time together spoofing bar codes with pen and paper?