This is a project in progress.

Videos:

http://www.youtube.com/watch?v=RE18gHRUR40&feature=related
http://www.youtube.com/watch?v=NrI9Z3c4_jw

Code + Hardware:

http://code.google.com/p/super-osd/

An On Screen Display for PAL and NTSC video signals. Software and hardware are both open source.

Please let me know what you think!

 

Hello,

I moved it to the embedded section of the forum, as it is a work in progress.
The project collection is for completed, well documented projects.

Bertus

 

Thanks,

I wonder if anyone has any comment on this. I was going to put it on my model plane and gather data using GPS.

Here is a video of a HUD I have designed:
http://www.youtube.com/watch?v=z-XPvLYYHSI&feature=related

 

I would like to see a little more of this project.

You should consider posting more of it here.

GoogleCode is nice and all, but I prefer to stay "on-site".

I would really like to see some pics of your circuit. The connection to your video source and such.

So far, I like it. Very interesting.

What type of graphics format(s) can you use for overlays?

 

I think its just ascii. You can order some boards prefabed for this for a couple dollars and get the code off sorceforge. Its really big in the UAV world. I suggest you poke around some of the RC flying sites to see what they have done as a community. They have already tied in GPS, Alt, speed, etc....

I would like to see a little more of this project.

You should consider posting more of it here.

GoogleCode is nice and all, but I prefer to stay "on-site".

I would really like to see some pics of your circuit. The connection to your video source and such.

So far, I like it. Very interesting.

What type of graphics format(s) can you use for overlays?

 

I would prefer to see one of our members projects rather than hunt down one. Thanks though.

I am interested in a peek at the code. I have been looking ar the dsPIC and other uCs for video processing and I like the fact that it is one of our members that is producing it.

I can get a little education without having to chase down an unknown on a new forum.

SO, get to work tom66!

 

I think its just ascii. You can order some boards prefabed for this for a couple dollars and get the code off sorceforge. Its really big in the UAV world. I suggest you poke around some of the RC flying sites to see what they have done as a community. They have already tied in GPS, Alt, speed, etc....

Nope! Not limited to ASCII! It's fully graphic - each pixel can be set or cleared, and there are 256x192 pixels. Also, it's double buffered, so you can update the screen without it flickering (*cough* unlike competitor OSDs which sell for $200+)

The core of this is not a dedicated OSD chip. It is a microcontroller, a dsPIC33FJ128GP802, from Microchip Technology. The amazing thing is, for very little money ($5) you can have something more powerful (in terms of overall capabilities) than the MAX7456 text OSD with only a few components, less than the MAX7456 requires, which is about $18 in small quantities!

The external components it requires are an LM1881, a few resistors, a few capacitors, a +3.3V supply, and a +5V supply. In total it takes up more board space than the MAX, and maybe in large quantities is more expensive (however, if your system already has the +3.3V and +5V regulators you can save.) But, it is so much more powerful!

Here is a schematic. Again, it is open source, Creative Commons v3.0 BY-SA: http://super-osd.googlecode.com/hg/hardware/Basic%20Main%20Board%20Schematic.png

Since the software is open source, here is a link to graphics core of the code. It is written in dsPIC assembler (for speed, and it actually makes programming easier.) The core weighs in at a massive 1,500 lines and plans exist to extend this further with more optimisations and further drawing operations, for example circles are not yet implemented. It is licensed under the GPL v2, being open source:
http://code.google.com/p/super-osd/source/browse/src/osd_core.s

Also, here is an explanation of how I managed to draw horizontal lines on the screen using a very fast operation (around 11 cycles for the algorithm, ~90 cycles when overhead is considered):
http://code.google.com/p/super-osd/wiki/FastHorizontalLines

Despite such a complex operation (drawing to the screen) it manages 32 fps with uncluttered scenes and the lowest I've ever seen was about 22 fps. Drawing just a compass, I've seen upwards of 120 fps; which is stupid fast, because the TV signal isn't fast enough to represent it.

As the DSP's function is two-fold (manipulating the screen and handling the drawing calculations), less processing time is available for dedicated applications like datalogging. It is for this reason that in the latest version a helper chip is included in the design for FPV / model RC applications. This chip handles sensor readings: 10x ADC (all 10 of which are used), GPS, UART, is the I²C bus master and does datalogging to an SD card. The graphics processor draws the widgets, such as the flight altitude, but the secondary processor gathers the data from the GPS (which is usually updating 5 or 10 times per second, perhaps more) and sends it to the DSP for processing.

On the road map are a few additional features, but the hardware is mostly finished. The hardware schematic is very common to OSDs. What convinced me that microcontrollers were viable at all for OSDs was this: http://www.micro-examples.com/public/microex-navig/doc/081-pic-osd-superimposer.html. What I then spent a few months doing was tracking down a low cost, easy to program (ICSP or other serial interface) microcontroller with the aim of developing a higher resolution, high performance, non-text version of this. I thank Microchip for introducing this processor. It has been well over a year since I started my search. I initially considered the PIC24F series which, although it would have worked, it would not have had the resolution and performance this version has. In fact, the particular chip I used had not been introduced until mid-way through my search. I must also be extremely grateful for the free samples they sent me; don't worry, I am looking at buying some for the proper OSD.

The processor is so fast, 7 cycles are available for each of the 256 pixels which are displayed 15,625 times per second; only 4 cycles are used. The chip is natively designed to do word access to be faster, previous versions used byte access but this had too many issues.

What type of graphics format(s) can you use for overlays?

Pretty much any 256x192 pixel image. I even had animations working on it. The animations and the source image were RLE compressed (it turns out the processors' DO loops are immensely helpful for RLE decompression; decoding a string of 100 bytes for example takes exactly 103 cycles: 3 cycles setup and 100 cycles looping.) I only put this up as a technical demo, but I guess it can be re-enabled.

I have also cross posted (though not this exact post) on several other forums and I am in the process of developing PCBs for it. I already have an FPV version planned out, total parts cost <$50 for a pro-quality OSD which normally sells for $235 or more.

And you know what? As I'm still a student, this may well be my final grade. There you go, my project is already complete, it took two weeks of my spare time and electronics geekiness.

 

Well done. I would like to see you polish it with the animation and i2c but implementation of a GPS stream to update the screen with current coordinates. That would be VERY cool.

I guess you could have the OSD read from a text file, and the GPS could easily update the text file.

I have a few small cameras that place the time and date in the corner of the video. This time and date data is from a text file on the device. It simply reads the text file and puts it on screen.

TXTFILE:

12-21-2010/23:53:02

Thats it.

The camera has only 1 button operation so there is no way to set it from the camera, so when you plug it into the USB port to download the captured videos, you can change directories to the setup dir and edit the time/date text file.

If your code could read the text file every few thousand cycles (or tens-of thousands) then update the screen info, It would be pretty cool. Even if the GPS part was only updated every 2.5 or more seconds.

 

Well done. I would like to see you polish it with the animation and i2c but implementation of a GPS stream to update the screen with current coordinates. That would be VERY cool.

I guess you could have the OSD read from a text file, and the GPS could easily update the text file.

I have a few small cameras that place the time and date in the corner of the video. This time and date data is from a text file on the device. It simply reads the text file and puts it on screen.

TXTFILE:

12-21-2010/23:53:02

Thats it.

The camera has only 1 button operation so there is no way to set it from the camera, so when you plug it into the USB port to download the captured videos, you can change directories to the setup dir and edit the time/date text file.

If your code could read the text file every few thousand cycles (or tens-of thousands) then update the screen info, It would be pretty cool. Even if the GPS part was only updated every 2.5 or more seconds.

I intend to make this into some kind of jelly bean part that you can drop into a project with a few components and have an OSD working. Then you just send it some bytes over I2C to draw lines, shapes, text and set pixels. I later intend to figure out a way to remove the LM1881, using the dsPIC's timers to detect the vertical serration pulses.

NTSC support is still in development. I don't yet have an NTSC camera (though I do have a PS2 which outputs NTSC...) but this only requires changing some timing. I am thinking of whether to auto detect NTSC or PAL.

Also I would like to get up an 8x8 font, better than the basic 5x5 font. I found a public domain one I may use.

 

Thinking it over, I think I can implement a 192x128 OSD with black/white and double buffering in the same amount of memory as the 256x192 pixel OSD. Would people prefer a loss in resolution for the ability to make characters much more visible?

 

Good question.

But, I think the higher resolution would allow you to 'draw' bigger characters or graphics or using a larger font.

 

Yeah, that's what I was thinking, so I was considering making it a software setting where you can select the mode over say I²C.