Diy osd (Arduino and opensource)
As this project is almost finish, I think it's time for a little update/summary here in post #1.
Lets start with a little video-clip showing the OSD in action
The main purpose of this project was to make a DIY OSD that can be made with;
It's not intended to be a graphic-heavy OSD, but an easy readable OSD with the most important info. But it's opensource and you can do whatever you want with it.
Quite a few updates and features have been added by request from users - and I hope to continue this. Feel free to post suggestions - but be reasonable. I don't mind to implement a feature - but I'm not gonna rewrite it all for another purpose etc.
I decided to make this project freely available and opensource - and I don't plan to earn anything on my work. Neither do I intend to sell or produce anything - but others are welcome to use it as they want.
If you don't want to make the hardware yourself the software also supports SimpleOSD OPEN (16 mhz with arduino bootloader and LM1881 sync seperator). It's should be available from here:
The OSD support theses features at the moment:
This is the schematic I use at the moment (Please note, AIN0 and AIN1 is NOT pin A0 and A1 on Arduino).
Same schematic but with a bit further explanation/text by Enthlapy (Dimming/brightness resistor value is a bit different, but you can just change these to what you prefer).
Fritzing-drawing, made by thnilsen
Old first post:
A work in progress. This post will be updated with more pictures text etc. Please be patient
A few weeks ago i started to play with a DIY-OSD. There is a lot of commercial OSD's available, but I figured it would be fun to make one myself. I wanted to make the hardware as simple and cheap as possible, so everything has been made using only an atmega micro-controller and a few standard components (resistors, capacitors and diodes). This makes it possible, to build an OSD for less than 10 $ (without GPS and current sensor).
I have chosen to make it all compatible with Arduino – so the code can be used directly with a simple arduino board, atmega with bootloader etc. This makes it pretty easy and cheap for everyone who wants to try it out. No SMD components or extra chips are needed.
At the moment it works just fine, and only LOS and an arrow home needs to be added (this is now done).
So far it has been made for a PAL video signal, but it shouldn’t be very difficult to make it compatible with NTFS.
A normal analog video-signal can be seen here;
The start indicates that a new line is starting and the variation in voltage is simply a way to express the color. A high voltage (about 1 volt) equals white and lower voltage is darker. Please see Wikipedia for further info on PAL/NTSC video signal.
The trick is to detect a new line, count the lines and show the pixels at the right time.
And off course reset the linecount when a new frame is detected.
The hardware is based on an atmega micro-controller and only a few normal components. New line and frames are detected with the analog comparator in the atmega mikro-controller.
As the sync pulse in the video-signal can have a little DC-offset, a few components is needed. To control this offset, the video-signal is AC-coupled. The sync-pulse will then be a negative voltage. To change this, you can add some DC-offset with a positive biased clamping circuit;
It's now possible to get a positive video-signal where the sync-pulse is very close to ground. The voltage reference should match the biased video-signal’s synch pulse.
In theory you can bias the video-signal so the sync-pulse goes a bit below ground. This makes it possible to use ground as reference voltage. I have tried and it seems to work fine, but I wouldn’t recommend it.
To show the pixels you can use SPI or USART to shift out pixels very fast. The USART in SPI mode works perfect as it is double buffered. The problem is that you probably want to use the USART for communication with a GPS module. I don’t think the USART pixel generation is of any interest, but I have the code if anyone wants to see it. The SPI is only single buffered (8 bit) so you will have about 2 clock cycles (1 ekstra pixel) that will be the same as the last one, but this is only a minor issue.
The brightness is simply adjusted with a resistor. To avoid the pin from draining a simple diode should be used as well.
First test with Arduino duemilanove
A breadboard test;
An early test from the breadboard;
Another example. Can't decide if I want to use small or large numbers. Any preferences?
Might add a smaller resistor to make the text brighter.
Later breadboard version.
I plan to use this little arduino pro board. That should make a really small and simple OSD.
The circuit at the moment;
C1 = 0.1 uF
R1 = 50 K pot
It might be a good idea to lower R2.
Made so far:
Should be finish soon
Ideas for improvement:
Notes to the code;
The code for writing characters, numbers etc. is currently not very flexible if you want to re-arrange the text, numbers etc. As I don't plan to re-arrange the text I don't really care, but a "cleaner" solution could probably be implemented.
The main problem is, that timing is very critical. Even the use of while-loops instead of repeating makes a big difference. While-loops takes quite a few clock-cycles, which is clearly visible.
The code can be opened with notepad++ or Arduino IDE. Please rename to .pde instead of .txt when using with Arduino.
use of the code;
The code can be used as you want. Feel free to change, update delete etc.
Use of the code in a commercial product is welcome as well - but it would be great to know.
The software have been written and tested with a MTK GPS and 2 GPS-simulation programs. The software should more or less work with all GPS'es, but I don't guarantee anything. It's recommended not to use lower than 1 hz update rate, and it's preferable to configure the GPS to only send RMC and GGA NMEA strings.
"look" changed - and some minor changes.
Small bug fixes from version 0.07
The menu will allow you to change these settings:
Exit must be chosen to save data. All data will be saved to eeprom, so they will stay until new data is written.
First time you load the new firmware the settings will be saved to the eeprom.
Even if you reload/flash the software the old values will be saved. If you want to update the values there is an option in the file to overwrite previously data. Just be sure to change the value back to 0, otherwise settings will be reloaded everytime.
ImagesView all Images in thread
FilesView all Files in thread
Code has been attached. I haven't done any cleaning yet, but feel free to take a look
New image attached as well.
Should I go for small or large numbers?
United States, CO, Durango
Joined Sep 2001
Tom66 is working on an OSD as well and I started working on some sudo code to take the IMU data from the IC2 on a MultiWii and generate a AHI line for his code base.
What I like about the OP's solution is that it's Arduino based and so is MultiWii. So, we might finally have an open source AHI OSD solution for Wii based flight controllers!
Joined Aug 2009
Maybe you would also be interested in this opensource, Arduino RC hardware
|Category||Thread||Thread Starter||Forum||Replies||Last Post|
|Discussion||Diy osd||karl k||FPV Talk||2||May 03, 2011 01:31 AM|
|Idea||New DIY OSD?||atari7202||FPV Talk||1||Mar 25, 2011 01:08 AM|
|Discussion||see my own diy OSD video||Passion||Aerial Photography||7||May 27, 2010 02:28 AM|
|Discussion||REAL homebrew DIY OSD - Check it out!||jafoca||FPV Talk||8||Jun 29, 2009 07:52 PM|
|Discussion||picoOSD DIY PIC12F683 based OSD in C||kbosak||FPV Talk||6||Jan 31, 2008 08:47 AM|