Create a On Screen Display - alternatives to MAX7456 wanted

[sgofferj]

Hi,

I'd like to collect some ideas. I'm very active in the UAV scene and many of you probably know the good old MAX7456 monochrome On Screen Display chip. From what I hear, this thing is/will be soon EOL/EOP and - well - it's text only and monochrome.

I would like to create a new OSD system to run with the MAVLink protocol. I have been googling my fingers bloody and reading for about half a year now but I didn't find a really good solution. What I do NOT want to do is create the whole video signal "manually" like a whole bunch of Arduino experiments do. I would like to use some kind of dedicated circuitry. I did come across the ADI Blackfin DSPs but they are maybe a bit oversized... Even the smallest one which can handle video has more punch than the actual flight controller. Besides that, those things are way out of my league, from an EE design point of view (BGA with hundreds of pins  ) and also probably a bit over my head from a software development point of view.

So, what shall I use? Is maybe anybody aware of a multicolor and graphics capable OSD chip that I missed? Or what other alternatives do I have? The final solution must be as small and lightweight as possible (UAV!) and should also be not significantly more expensive than $80-$100.

-Stefan

[NiHaoMike]

There were a few projects that did overlay with a PIC, Propeller, or other microcontroller. Another solution is to embed the serial data in the VBI and then use a system on the ground to do the actual overlay.

[Wilksey]

Yes, unfortunately it is EOL, reason being "nobody uses analog video any more", A Maxim Field Apps Engineer here in the UK, nothing else like it in the offering from Maxim.

I tried it once, but ended up with all sorts of weird timing and sync issues, better experiment results were gained with a LM1881 sync separator IC and a MUX chip, but never fully worked as I wanted so I put it aside.  I have used the BOB4 in the past which is a fairly decent module, albeit expensive!

I would be interested in others' responses as I may start looking at it again.

[NiHaoMike]

What about using the (presumably unused) audio channel to send data via a one way modem? No need to lock to the video timing that way, even though that could be done with a comparator and the capture peripheral on a microcontroller.

[sgofferj]

I do have a telemetry link. That's not an issue. The demand is explicitly to overlay data on the video stream in realtime to be able to e.g. fly with video goggles and also for documentation purposes. it generally doesn't matter if the overlay is created onboard or in the GCS, although an onboard OSD has the advantage of serving as some kind of backup in case the telemetry link drops out.

[NiHaoMike]

Use a Raspberry Pi in the ground station hardware. No change to the aircraft needed.

[FrankenPC]

This is really interesting to me.  I'm an amateur quad copter builder and would also like color OSD capabilities that are universal.  I did see this example of some custom color OSD hardware. 

Video demo:

Link to more info:
http://www.eagletreesystems.com/index.php?route=product/product&product_id=136

[sgofferj]

This is really interesting to me.  I'm an amateur quad copter builder and would also like color OSD capabilities that are universal.  I did see this example of some custom color OSD hardware.

Yup, something like that I had in mind...

Use a Raspberry Pi in the ground station hardware. No change to the aircraft needed.

Now you lost me. The RasPi AFAIK doesn't have video input capabilities.

[Marco]

Did you try a search for OSD PAL generator or something similar? First page of google results has multiple microcontroller projects.

[Wilksey]

Yeah, unfortunately with the Google results they either don't work or the chips are no longer available.
The PICO OSD does not work, there is an AVR (Arduino) that might work, but the clock has to be synchronised to get a good V/HSync count, so it would be pure trial and error to see if it worked on multiple video signals.

[NiHaoMike]

Now you lost me. The RasPi AFAIK doesn't have video input capabilities.

There's USB and MIPI CSI. You can also look into other low cost embedded Linux platforms.

[sgofferj]

There's USB and MIPI CSI. You can also look into other low cost embedded Linux platforms.

That's gonna be too bulky in the end. What I'm looking to have in the end is a relatively small and light single board solution. As I said - onboard...

Did you try a search for OSD PAL generator or something similar? First page of google results has multiple microcontroller projects.

Yeah and I wrote in my first post that I don't want to start creating signals "by hand" with µCs . It should be based on components that speak "Composite" natively.

[sgofferj]

Well, it should be very good. I don't only want a replacement for the MAX7456 but an improvement too. 5.8GHz links nowadays have a pretty reasonable quality.

[Jeroen3]

If you get a fast mcu and sync with the signal you can create overlay with a dac (or gpio with some analogs to do rgb).
It's shouldn't be that complex, just "play" an array through to your dac or gpio using the dma triggered by interrupt.
Then you have the CPU free to actually change the shadow copy image based on your data.

[Psi]

There's a reason all the current OSD products are using either a MAX7456 or a MCU, they're the only cost effective options.

And even then, the MAX7456 is only cost effective for RC because there's a china knockoff version available.
The real ones cost like $20 each.
(If you unsolder the MAX7456 in RC OSDs products and get your DMM out you may notice that the metal pad under the package is not internally connected to GND like its supposed to be. The knockoff chips have it not connected.

At least it means that the MAX7456 wont die when maxim EOLs it. As long as there's demand it should be stay around.

[xavier60]

When the STV5730a became difficult to source, I used the UPD6464 instead. It needs extra circuitry to be added for sync separation and sync tip clamping.