Reverse Engineering The OWON SDS7102 Oscilloscope

It is something of a rite of passage for an electronics enthusiast, the acquisition of a first oscilloscope. In decades past that usually meant a relatively modest instrument, maybe a 20MHz bandwidth and dual trace if you were lucky. Higher spec devices were eye-wateringly expensive monsters, not for the Common People.

We are fortunate that like most other areas of technology the world of test equipment has benefited in the last few years both from developments in digital technology and from the growth in Chinese manufacturing. If your first ‘scope is that second-hand 20MHz CRT you will probably secure it for pennies, and the first ‘scope you buy new will probably have a spec closer to those unattainable super-scopes of yesteryear. Gone is the CRT and timebase generator, in its place a TFT, system-on-chip, and super-fast A to D converter.

[Christer Weinigel] has just such an entry-level modern digital ‘scope, an OWON SDS7102. He comments that it’s got an impressive spec for its price, though the input is noisier than you’d expect on a more expensive device, and the software has one or two annoying bugs. Having owned it for a while, he’s now subjected it to a lengthy teardown and reverse engineer, and he’s posted his findings in a succession of blog posts.

[Christer]’s interest lay mainly in the OWON’s digital section, it seems there is already a substantial community paying attention to its analog front end. He’s deduced how its internals are connected, ported Linux to its Samsung SoC in the scope, succeeded in getting its peripherals working, and set to work programming the Xilinx FPGA that’s responsible for signal processing.

The series of posts is a fascinating read as a run through the process of reverse engineering , but he points out that it’s quite a lot of information. If you are just interested in how a cheap modern oscilloscope works, he says, he suggests reading his post in which he recaps on all its different components.

He also makes a plea for help, he’s no slouch on the ‘scope’s software but admits he’s a bit out of his depth on some aspects of the FPGA. If you’re an FPGA wizard with an interest in ‘scopes, he’d like to hear from you.

This isn’t the first time we’ve featured ‘scope reverse engineering here at Hackaday, though it may be more in-depth than others. In the past we’ve seen a Uni-T screen grab protocol laid bare, and an investigation of a Rigol 1054Z.

Reverse Engineering Quadcopter Protocols

Necessity is the mother of invention, but cheap crap from China is the mother of reverse engineering. [Michael] found a very, very cheap toy quadcopter in his local shop, and issued a challenge to himself. He would reverse engineer this quadcopter’s radio protocol. His four-post series of exploits covers finding the right frequency for the radio, figuring out the protocol, and building his own remote for this cheap toy.

[Michael] was already familiar with the capabilities of these cheap toys after reading a Hackaday post, and the 75-page, four language manual cleared a few things up for him. The ‘Quadro-Copter’ operated on 2.4GHz, but did not give any further information. [Michael] didn’t know what channel the toy was receiving on, what data rate, or what the header for the transmission was. SDR would be a good tool for figuring this out, but thanks to Travis Goodspeed, there’s a really neat trick that will put a 2.4GHz nRF24L01+ radio into promiscuous mode, allowing [Michael] to read the transmissions between the transmitter and quadcopter. This code is available on [Michael]’s github.

A needle in an electromagnetic haystack was found and [Michael] could listen in on the quadcopter commands. The next step was interpreting the ones and zeros, and with the help of a small breakout board and soldering directly to the SPI bus on the transmitter, [Michael] was able to do just that. By going through the nRF24 documentation, he was able to suss out the pairing protocol and read the stream of bytes that commanded the quadcopter.

What [Michael] was left with is a series of eight bytes sent in a continuous stream from the transmitter to the toy. These bytes contained the throttle, yaw, pitch, roll, and a ‘flip’ settings, along with three bytes of ‘counters’ that didn’t seem to do anything.  With that info in hand, [Michael] took an Arduino Nano, an nRF04L01+ transceiver, and a Wii nunchuck to build his own transmitter. If you’re looking for a ‘how to reverse engineer’ guide, it generally doesn’t get better than this.

You can check out a video of [Michael] flying his Wiimoted quadcopter below.

Continue reading “Reverse Engineering Quadcopter Protocols”

An Improved WiFi Connected E-Ink Display

[David] created a great looking e-ink WiFi display project that works a little like a network-connected picture frame with a few improvements over other similar projects. With the help of an ESP8266 it boots up, grabs an 800×600 image over the network, updates the screen, then goes back to sleep. Thanks to some reverse engineering, he was able to make his own firmware for the onboard controller to handle the low-level driving of the display. Since e-ink displays require no power to hold an image and the rest of the unit spends most of the time either asleep or off, power use is extremely low. [David] hopes to go months without needing to recharge the internal lithium-polymer battery.

eink_back
Lithium-polymer charger (top left); Single-cell lithium-polymer battery (center); pullups and power cutoff for nonessential electronics (green board, lower right); ESP866 (lower left).

We previously featured another WiFi-connected e-ink display project that was in fact also the inspiration for this version. [David] uses a 4.3″ 800×600 GDE043A e-ink display and wrote his own firmware for the STM32F103ZE ARM CortexM3 SoC used as a display controller, a process that required some reverse engineering but was aided by the manufacturer providing a closed-source driver for him to use. [David] writes that some reverse-engineering work for this display had already been done, but he had such a hard time getting a clear understanding from it that he reverse engineered the firmware anyway and used the documents mainly for validation and guidance.

As a result, [David] was able to make use of the low-level driver electronics already present on the board instead of having to make and interface his own. E-ink displays have some unusual driving requirements which include generating relatively high positive and negative voltages, and rapidly switching them when updating the display. Taking advantage of the board’s existing low-level driver electronics was a big benefit.

eink_apThe ESP8266 rounds out the project by taking care of periodically booting things up, connecting to the wireless network and downloading an image, feeding the image data to the STM32 to update the display, then disconnecting power from all non-essential electronics and going back to sleep. We especially like how the unit automatically creates a WiFi access point to allow easy (re)configuring.

There’s one more nice touch. [David] goes the extra mile with server software (in the form of PHP scripts) to design screens for the display with data like weather forecasts, stock prices, and exchange rates. Check it out in the project’s github repository.

Reverse Engineer Your Robot Lawnmower

Your home is your castle, and you are king or queen of all you survey. You’ve built your own home-automation system from scratch. Why would you possibly settle for the stock firmware in your robotic lawnmower? [Daniel Wiegert] wouldn’t either, so in Project Landlord he has started to reverse-engineer it.

You can hardly blame him. The Worx Landroid‘s controller board uses an NXP LPC1768 ARM Cortex-M3, and the debug pins are labelled on the backside. The manufacturer didn’t protect the flash memory. It’s just begging to have its firmware dumped. So far, [Daniel] has managed to both brick and unbrick the device, and has completely mapped the controller’s pinout, so he’s on his way to complete control.

Right now, he’s got a working proof-of-concept firmware on his GitHub that’s able to drive the machine around a little bit and set the brakes. It’s running FreeRTOS, and [Daniel] is looking for other people to get in on the project. He’s done the hard initial work, so get in there and reap the rewards! Just don’t neglect to remove the blade before custom firmware.

Will custom firmware in a robotic lawnmower change the world? Probably not. But it is awesome, and will certainly make a difference in the lives of people whose robot mowers continually get stuck behind the hydrangeas.

The HackadayPrize2016 is Sponsored by:

Reverse-Engineering debugWire

Has this ever happened to you? You start out on a reverse-engineering project, start digging in, and then get stumped. Then you go looking on the Internet for help, and stumble across someone who’s already done exactly what you’re trying to do?

[Geekabit] wrote us with a version of this tale of woe. In his case, the protocol to be reversed was Atmel’s debugWire protocol for debugging on low-pin-count parts. There are a number of websites claiming it’s “secret” or whatever, but it actually looks like it’s just poorly documented. Anyway, [RikusW] seems to have captured all of the signals way back in 2011. Good job!

The best part of [geekabit]’s story is that he had created the Wikipedia page on debugWire himself to inspire collaboration on reverse-engineering the protocol, and someone linked in [RiskusW]’s work. When [geekabit] picked up the problem again a bit later, he did a bit of web research and found it solved — on the page that he started.

Maybe it’s not a tale of woe after all, but a tale of unintentional collaboration. Anyway, it serves as a reminder that if you’re interested in the destination more than the voyage of discovery, it never hurts to do your research beforehand. And now we all know about the low-level details of the debugWire protocol. Anyone written up a driver yet?

Thanks [geekabit] for the tip and the story! Image from ATmega32-AVR, which explains nicely how to use the Dragon in debugWire mode.

Take the Long Road to a Precise Laser PCB Exposer

According to [diyouware], inside of every HD-DVD player is a gem of laser engineering with the designation of PHR-803T, and it’s just begging to be converted into a PCB exposer. Following along similar hacks which tore the laser diode out of Blu-ray players to expose PCBs, they wanted to use the whole PHR-803T unit without disassembling it, and to try to enable all of its unique features.

They envisioned something simple like a scanner for their machine. Just place the PCB on top of a glass sheet, close the lid, and click print. Unfortunately, moving the laser itself just caused too much vibration. So they switched to an inverted delta robot and named it TwinTeeth. In this design, the laser would stay still and the PCB would move.

What follows next is a seriously impressive journey in reverse engineering and design. The PHR-803T had no data sheet, but a ton of features. For example, it can autofocus, and has three different laser diodes. So many interesting problems were found and solved. For example, the halo from the laser caused the surrounding photoresist to cure. They solved it by adding a glass plate with a UV filtering film on it. Only the most focused point of the laser could punch through.

Another adventure was the autofocus. They wanted to autofocus on all four corners of the board. The PHR-803T was designed to read HD-DVDs so can focus a beam to far below 0.01 mm. They got autofocus working with the UV laser, but couldn’t use it on the PCB without curing the photoresist. So they put a piece of aluminum foil at a known level to start. Then they realized they could use the red or infrared diodes to focus instead. Now they can level the PCB in software, and focus the diode without curing the photoresist.

In the end they have an inverted-delta mini PCB factory. It can produce boards around the size of an Arduino shield with a resolution of 600 DPI. Their machine also has attachments for drilling and solder paste dispensing. Check out the video of it in action.
Continue reading “Take the Long Road to a Precise Laser PCB Exposer”

Game Boy Camera Cartridge Reversed, Photos Dumped

There’s something magical and nostalgic about extremely low resolution in this era of mega-megapixels on every cell phone. And the Game Boy’s big bulbous camera module just looks so cool. [Robson Couto] didn’t stop at simply using the camera — that’s been done before — but actually reversed the card’s protocol so that he could leave it entirely intact. As you can see from the banner image, it was a success.

A project like this doesn’t get done overnight, and [Robson] drew on a lot of his own previous work as well as the work of others. For instance, he’d already made a board that interfaces Game Boy Paks to his PC through an ATmega32 and a serial port. He’d also written software that understands the card header format on the PC side. So dumping the ROMs contents should be no problem. But of course, it was.

[Robson] could read one bank of memory, but not any of the others. It turns out that the camera pack uses a clock signal that not many other cards use. It took [Robson] some serious work — a lot of it false starts and dead ends — to get this particular part working.

Success!
Success!

If you’re into Game Boy hacking, give [Robson]’s writeup a good read. Also note that he’s got fantastic links to previous research in all of his posts. If you couldn’t care less about keeping the cartridge intact, you can simply interface the camera with a TI calculator, use the camera to transmit Morse code, or simply add a thermal printer for a low-res instant camera with style.