Pre-processing is pretty normal. If you want something cheap, use the RCTimer $6 i2c to nav board. It has one serial and one i2c interface on a standard 328mcu. I use it for different devices, from GPS to SD card reader.

Originally Posted by dziedrius

Do you plan selling this board? The most interesting thing for me is audio out thing, which I guess works as a modem, have you working software for it?

The audio-output is normally just an AC-coupling and a few resistors to change signal-level and perhaps impedance.

I have a sketch to send and receive chars "somewhere", but ask Jalves as he is the one who have continued to work on it.

Originally Posted by RickEis

Dennis,
I don't know enough about this.... but what if the sensor is already running on another mini pro which is running the stabilization system for the copter?
Thanks again Dennis for your awesome project.
Rick

The main problem is not the data-processing, but receiving. The Serial-port is used by GPS, SPI by pixel-output and furthermore the timing is quite critical.

If you use a processor for signal-processing and send the processed data over serial-port. If you want a lot of extra stuff, the best idea is to use one controller as dedicated OSD-chip and another as master/control/signal-processor. It's the same principle when using MAX7456 as OSD chip - the Amega328 suddenly have plenty of CPU-time left. Don't even know what to do with all the extra cpu-time

Originally Posted by Dennis Frie

The audio-output is normally just an AC-coupling and a few resistors to change signal-level and perhaps impedance.

I have a sketch to send and receive chars "somewhere", but ask Jalves as he is the one who have continued to work on it.

I'm complete beginner in arduino/electronics, but I've seen Jalves code - it is quite simple(fits into single screen, interestingly enough it has header line "/* This TAB has code from Melih Karakelle, adapted by Dennis Frie*/
", but it needs timing, so question is if it still possible to add it to current osd code, because if I'm understanding correctly you would need mix modem and video signal processing code into single routine to fit timings, or not?
Using MAX7456 would help a lot, problem is that breakout board with it is quite expensive (40$) + quite bulky (though you could remove video connectors).

dziedrius,

You are not as complete a beginner as me

I am even having trouble compiling DIY OSD v0.18

Attached are the errors I'm getting.

Maybe someone could see what I'm doing wrong ?

Thank you in advance
Rick

Originally Posted by dziedrius

I'm complete beginner in arduino/electronics, but I've seen Jalves code - it is quite simple(fits into single screen, interestingly enough it has header line "/* This TAB has code from Melih Karakelle, adapted by Dennis Frie*/
", but it needs timing, so question is if it still possible to add it to current osd code, because if I'm understanding correctly you would need mix modem and video signal processing code into single routine to fit timings, or not?
Using MAX7456 would help a lot, problem is that breakout board with it is quite expensive (40$) + quite bulky (though you could remove video connectors).

I modified the audio-modem code from Melih, in order to run other tasks simultaneously. Mainly to run OSD, and audio-modem at the same time. While I never got it implemented with the OSD-code, I believe it's possible even with the short cpu-time left.

Originally Posted by RickEis

dziedrius,

You are not as complete a beginner as me

I am even having trouble compiling DIY OSD v0.18

Attached are the errors I'm getting.

Maybe someone could see what I'm doing wrong ?

Thank you in advance
Rick

A bit more information would be nice

- What version of Arduino do you use?
- Do you use windows/Linux/Mac?

You should be able to open DIY_OSD_v0_18.ino and press upload without modifying anything

But it looks to me like you have copied the project to Arduino libraries? Please remove all the DIY-OSD stuff from Arduino library first, as this seems to be causing problems.
C:\Documents and Settings\Fred\My Documents\Home\Arduino\libraries\DIY_OSD_v0_18

The files are being read both from library and the compiling project, perhaps?

You were right !

My Arduino file structure was all screwed up.... cleaned things up according to Arduino's web site and it compiled first time !!

My camera and video transmitter is 12 volts. The DIYOSD is 5 volts. Is there a problem tying the 5v DIYOSD ground and video line with the the 12 volt ground and video line from the camera?

Thanks again Dennis.

Rick

Originally Posted by RickEis

You were right !

My Arduino file structure was all screwed up.... cleaned things up according to Arduino's web site and it compiled first time !!

My camera and video transmitter is 12 volts. The DIYOSD is 5 volts. Is there a problem tying the 5v DIYOSD ground and video line with the the 12 volt ground and video line from the camera?

Thanks again Dennis.

Rick

Pretty sure you're referring to the devices input voltage. Often this is not equal to its output levels. Double check with a meter.

Originally Posted by RickEis

You were right !

My Arduino file structure was all screwed up.... cleaned things up according to Arduino's web site and it compiled first time !!

My camera and video transmitter is 12 volts. The DIYOSD is 5 volts. Is there a problem tying the 5v DIYOSD ground and video line with the the 12 volt ground and video line from the camera?

Thanks again Dennis.

Rick

They all need common ground regardless of their supply voltage, and the video line don't carry 12 V, just video signal level. So no problems at all.

It appears to me that I am creating a potential problem if I have one flight pack and am powering the camera, receiver and BEC.

If the BEC powers the 5 volt DIYOSD which then in turn is connected to the 12 volt camera system through the ground (and signal wire)....it appears that I am creating a ground loop....yes?

And if I understand that correctly (very limited understanding I might add , the danger is that the 12 volts may be passed through the 5 volt ground system and fry things.

So.....how messed up is this thinking?

Rick

The Arduino will only see 5 V from BEC in relation to ground and ~1 V peak in relation to ground from video line. So there's no risk for frying the Ardu. It will never see 12 V.

Originally Posted by RickEis

If the BEC powers the 5 volt DIYOSD which then in turn is connected to the 12 volt camera system through the ground (and signal wire)....it appears that I am creating a ground loop....yes?
Rick

Connecting all of the input grounds of the components directly to the battery's negative terminal will remove the groundloop problem. I drew a diagram in paint for you.

Hey thanks everyone for helping this novice -
Yes, the code did compile
No, nothing fried when I plugged it (see pict)
Yes, I did see some numbers ...not too pretty yet ...but hey I see numbers
see a little clip as I adjust the potentiometer -

114451 (1 min 29 sec)

So, now for some trouble shooting - ha I have no idea what I'm looking for Any suggestions ?
I suspect the capacitor because I had no idea what size it was other then "small" .
Thanks again,
Rick

got my osd running now did a mistake feeding the osd into the videostream. Now i am planning to use this without a gps so i want to strip down the code to FlightTime and Input voltage (G-Osd Style). Any hint where to start the best without messing everything up ?

Originally Posted by nabazul

got my osd running now did a mistake feeding the osd into the videostream. Now i am planning to use this without a gps so i want to strip down the code to FlightTime and Input voltage (G-Osd Style). Any hint where to start the best without messing everything up ?

I must say the output code is a big mess... Not hard to understand, just too "straight forward".

Look at output.cpp and start commenting out entire ifs in the detectline-method. For example, if you comment out this line (and the next 240 lines):

else if (line > toplinenumbers  && line < (toplinenumbers + 9)) {

...you will remove the speed and altitude numbers. Just continue doing the same thing for the other lines you don't want, but compile and test the code after each change.

I have done quite a lot of changes in the output code, but the code is still not looking good. Some major refactoring has to be done, but I don't know if the timing allows it.