[Dave Jones] got his hands on a really wide, 2-row Vacuum Fluorescent Display. We’ve come across these units in old equipment before and you can get them from the usual sources, both new and used, but you need to know how to drive them. This recent installment of the EEVblog reverse engineers this VFD.
The function of these displays is pretty easy to understand, and [Dave] covers that early in the video after the break. There is a cathode wire and phosphorescent coated anodes. When current is applied the anodes glow. To add control of which anodes are glowing a mesh grid is placed between the anodes and the cathode wire. Applying negative potential to the grid prevents the electrons from traveling to the anode so that area will not be lit.
Now driving this low-level stuff is not easy, but rest assured that most VFDs you find are going to have a driver attached to them. The reverse engineering is to figure out the protocol used to control that driver. On this board there is a 2-pin connector with a big electrolytic filtering cap which is a dead giveaway for power rails. Looking at the on-board processor which connects directly he ascertains that the input will be 5V regulated since this is what that chip will expect. Connecting his bench supply yields a blinking cursor! [Dave] goes on to pump parallel data and test out the control pins all using an Arduino. He finds success, sharing many great reverse engineering tips along the way.
We often call this type of thing a dark art, but that’s really just because there aren’t a lot of people who feel totally comfortable giving it a try. We think that needs to change, so follow this example and also go look at [Ben Heckendorn’s] recent LCD reverse engineering, then grab some equipment and give it a try for yourself. We want to hear about your accomplishments!
Continue reading “Reverse Engineer a VFD after Exploring How They Work”
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”
If you want to take a photograph with a professional look, proper lighting is going to be critical. [Richard] has been using a commercial lighting solution in his studio. His Lencarta UltraPro 300 studio strobes provide adequate lighting and also have the ability to have various settings adjusted remotely. A single remote can control different lights setting each to its own parameters. [Richard] likes to automate as much as possible in his studio, so he thought that maybe he would be able to reverse engineer the remote control so he can more easily control his lighting.
[Richard] started by opening up the remote and taking a look at the radio circuitry. He discovered the circuit uses a nRF24L01+ chip. He had previously picked up a couple of these on eBay, so his first thought was to just promiscuously snoop on the communications over the air. Unfortunately the chips can only listen in on up to six addresses at a time, and with a 40-bit address, this approach may have taken a while.
Not one to give up easily, [Richard] chose a new method of attack. First, he knew that the radio chip communicates to a master microcontroller via SPI. Second, he knew that the radio chip had no built-in memory. Therefore, the microcontroller must save the address in its own memory and then send it to the radio chip via the SPI bus. [Richard] figured if he could snoop on the SPI bus, he could find the address of the remote. With that information, he would be able to build another radio circuit to listen in over the air.
Using an Open Logic Sniffer, [Richard] was able to capture some of the SPI communications. Then, using the datasheet as a reference, he was able to isolate the communications that stored information int the radio chip’s address register. This same technique was used to decipher the radio channel. There was a bit more trial and error involved, as [Richard] later discovered that there were a few other important registers. He also discovered that the remote changed the address when actually transmitting data, so he had to update his receiver code to reflect this.
The receiver was built using another nRF24L01+ chip and an Arduino. Once the address and other registers were configured properly, [Richard’s] custom radio was able to pick up the radio commands being sent from the lighting remote. All [Richard] had to do at this point was press each button and record the communications data which resulted. The Arduino code for the receiver is available on the project page.
[Richard] took it an extra step and wrote his own library to talk to the flashes. He has made his library available on github for anyone who is interested.
In a fit of desperation, I turned to data mining tools and algorithms, but stepped back from the horror of that unspeakable knowledge before my mind was shattered. That way madness lies.
Wise words. Wise words, indeed. Who among us hasn’t sat staring into the abyss of seemingly endless data without the slightest clue to what it means or even how to go about figuring out what it means? To literally feel the brain damage seeping in as you start to see ‘ones’ and ‘zeros’ reach out to you from every day electronic devices…like some ghost in the wires. But do not fear, wise hacker! For we have good news to report! [Rory O’hare] has dived into this very abyss, and has emerged successful.
While others were out and about playing games and doing whatever non-hackers do to entertain themselves, [Rory O’hare] decided to reach out and grab some random wireless signals for a little fun and excitement. And what he found was not just a strong, repeating signal at 433Mhz. Not just a signal that oozed with evidence of ASK. What he found was a challenge…a mystery that was begging to be solved. A way to test his skill set. Could he reverse engineer a signal by just looking at the signal alone? Read on, and find out.
When a Lexmark inkjet printer stopped working, [Mojobobo] was able to claim it as his own. He quickly realized that the machine was flooded with ink and not worth repairing, but that didn’t mean he couldn’t still find a use for it. When he learned that the printer’s firmware was not only upgradable but also unprotected, he knew he should be able to get the printer to do his own bidding.
[Mojobobo] started his journey with the motherboard. The unit still powered up, but it was asking to insert a “duplex module” before it would boot any further. [Mojobobo] first tried to find a way to trick the duplex module sensor, but was unsuccessful. His next step was to search for some kind of serial communications port. He didn’t have an oscilloscope, so instead he used a speaker with a wire probe. In theory, if the wire was pressed against an active serial port, he would be able to hear varying tones through the speaker. Sure enough, he found some interesting tones after probing around some ports next to a “JTAG” label. He looked up some information about the nearby chip and found that it included an SPI bus.
After some internet research, [Mojobobo] learned enough about SPI to have a rough idea of how to use it. Having limited tools available to him, he decided to use his Arduino to try to communicate with the motherboard. After wiring up a simple circuit, (and then re-wiring it) he was able to dump the first 4096 bytes of the motherboard’s boot loader to the Arduino via the SPI interface.
[Mojobobo’s] next steps will be to find a faster way to dump the boot loader. At 9600 baud, he grew tired of waiting after three hours. Once he has the full boot loader he intends to search for a way to bypass the duplex sensor and get the board to finish booting. Then he may just use the printer for its scanning functions, or he might find other interesting uses for it.
Can you spot the serial port in the pic above? You can probably see the potential pads, but how do you figure out which ones to connect to? [Craig] over at devttys0 put together an excellent tutorial on how to find serial ports. Using some extreme close-ups, [Craig] guides us through his thought process as he examines a board. He discusses some of the basics every hobbyist should know, such as how to make an educated guess about which ports are ground and VCC. He also explains the process to guessing the transmit/receive pins, although that is less straightforward.
Once you’ve identified the pins, you need to actually communicate with the device. Although there’s no easy way to guess the data, parity, and stop bits except for using the standard 8N1 and hoping for the best, [Craig] simplifies the process a bit with some software that helps to quickly identify the baud rate. Hopefully you’ll share [Craig’s] good fortune if you reach this point, greeted by boot messages that allow you further access.
Cyber Monday may be behind us, but there are always some hackable, inexpensive electronics to be had. [Stephen’s] wireless Android/Arduino outlet hack may be the perfect holiday project on the cheap, especially considering you can once again snag the right remote controlled outlets from Home Depot. This project is similar to other remote control outlet builds we’ve seen here, but for around $6 per outlet: a tough price to beat.
[Stephen] Frankenstein’d an inexpensive RF device from Amazon into his build, hooking the Arduino up to the 4 pins on the transmitter. The first step was to reverse engineer the communication for the outlet, which was accomplished through some down and dirty Arduino logic analyzing. The final circuit included a standard Arduino Ethernet shield, which [Stephen] hooked up to his router and configured to run as a web server. Most of the code was borrowed from the RC-Switch outlet project, but the protocols from that build are based on US standards and did not quite fit [Stephen’s] needs, so he turned to a similar Instructables project to work out the finer details.
Stick around after the break for a quick video demonstration, then check out another wireless outlet hack for inspiration.
Continue reading “Android and Arduino RF Outlet Selector”