We’ve had a few folks send us info about their vehicle display hacks after seeing [Will O’Brien’s] motorcycle computer a few days ago.
On the left we have a display for an electric vehicle. [S1axter] is using a 4.3″ TFT screen to display charge information for each battery cell in the car. An ATmega88 collects the data and sends it to a breakout board with an LCD controller on it.
To the right is a display from a Formula Student project. a Matrix Orbital GLK19264-7T-1U LCD display provides a lot of real estate for displaying data. Right now [Alan] is still in the early prototyping stages, but the video after the break demonstrates the RPM readout using a function generator. It’s not shown in the video, but he tells us that he’s since tried it out with the engine and has a PIC 16f877 reading temperate data from the electronic control transmission sensors in addition to the RPM data.
Correction: Thanks to [j] for correcting our mistake. This is a Formula Student car.
Continue reading “Vehicle information display hacks”
Above is a new demo video called Phasor developed by [Lft]. It is run from an AVR ATmega88 and a few passive components, and the result is pretty amazing. [Lft] goes into detail about the tricks he used to get this up and running. The chip is clocked at 17.73447 MHz which is exactly four times the frequency of the PAL color carrier wave which allows him to fake a smooth signal. He also uses a timer trick to get the voltages that he needs. The work done here is beyond hardcore and quite frankly we can’t believe he managed to fit all of this into 8.5 KB of program space with just 1 KB or RAM. We wonder if there’s enough room there to add sound and color to the AVR Tetris project.
[Sprite_tm] dusted off his assembly skills and managed to emulate a Z80 computer using an AVR ATmega88. He’s using an SD card in place of the floppy and a 128 KB DRAM chip to handle the memory for the emulated machine. An FT232 board gives him terminal access which he uses for input and display. As you can see, the hardware is much simpler than building the original would have been. He makes up for this with complicated firmware. In the end, the emulated core occupies about 2 KB of programming space after he followed the Z80 Propeller project’s idea of dividing the instructions into different modules and using a lookup table to access them.
The headphone remote for the third generation iPod shuffle has a special chip that identifies it to the iPod itself. [David Carne] posted an in-depth report about the process he used to reverse engineering that protocol. He’s discovered that the remote uses a peculiar signal to identify it as authentic when the device powers up. We’ve talked about Apple’s use of peripheral authorization before and it seems this is no different. [David] did manage to emulate the authentication using an ATmega88. If you’ve got a shuffle 3G sitting around this info will allow you to operate it with a microcontroller in your next project.
In a previous job, [sprite_tm] was responsible for wrangling many different LED text ad marquees. The hardware was fairly simple and he always figured they could be pushed much further with a little work. He recently acquired ten 32×16 LED displays a decided to see what he could do with them. By the end of the project, he had full motion video running on the display. This is a great project to read up on if you’ve ever wondered about LED matrix displays. He starts by reverse engineering the electronics on the board. He then attached an ATmega88 to drive the display module. Multiple display modules were daisy chained together over serial. The article covers PWM control and refresh timing as well. Check out one of a few demo videos below. Continue reading “Overhauling LED marquees”
If you are an Atmel fan, you may enjoy this webserver built around the ATmega88. Since it has full TCP and HTTP support, communication can be done using a standard web browser on any system. We also noticed that the code uses AVR Libc and the processor can be replaced with an ATmega168, both used on the Arduino platform. Honestly, we think the most interesting part about this project is the firmware. The author has assumed that the webserver will only be sending one packet per request and the code is optimized for this setup. This leaves around 50% of the memory for the web application.